Role based security is the only kind that is manageable. Any other kind and you are playing at security, you are not managing it. Sysprogs and Secadmins really should be different persons. It is a very different role. It is a different mindset. I have worked both roles, sometimes both at the same time. From a security perspective, auditors, secadmins and sysprogs all should be different persons. But life can be much easier when you are a sysprog with the special attribute and you do know well the RACF structure. And the opposite is also true. You have a much easier life as a secadmins when you have a solid sysprog background. Best wishes Jack
On Fri, Aug 4, 2023, 23:07 Mike Schwab <[email protected]> wrote: > The goal is to assign application security to a group then add the group to > the user's definition. When a person transfers then you add and deleted > groups to the user while the user keeps access to personal datasets. > > On Fri, Aug 4, 2023, 15:51 Steve Thompson <[email protected]> wrote: > > > Don't know if TSS implements groups. But with groups, I can have > > access to certain DSNs read only, others update|delete|create. I > > can have access to console commands from TSO, but not have logon > > access to CICS. Just as examples. > > > > Having to change TSO IDs is problematic because one loses access > > to their private data sets... (tools you wrote for making > > ISPF/Roscoe or whatever better...). > > > > So role based using group definitions that give one authority > > until they don't need it (or can't justify it), is what I think > > you mean and need. > > > > Steve Thompson > > > > On 8/4/2023 4:25 PM, Wayne Bickerdike wrote: > > > To implement this would require systems that implement application > > > security. The idea that a systems programmer of any type would be able > to > > > perpetrate fraud is a stretch. > > > > > > I had access to everything mainframe (RACF, CICS, z/OS) in a top secret > > > installation. I wouldn't be able to place a purchase order but I could > > nuke > > > any dataset. I was also too damn busy doing my job to compromise the > > > systems. > > > > > > The worst case is where staff inherit privileges as they change roles. > > That > > > was a problem. Makes a case for role based security. Change roles > New > > > role based ID. > > > > > > On Fri, Aug 4, 2023 at 11:34 PM Michael Babcock <[email protected] > > > > > wrote: > > > > > >> I ran across this in a CICS security admin book (which should also > apply > > >> to z/OS sysprogs): > > >> > > >> Roles and separation of duties > > >> > > >> A key security principle is the separation of duties between > > >> different users so that no one person has sufficient access privilege > to > > >> perpetrate damaging fraud. *This configuration is required by various > > >> audit regulations such as the United States Federal Law known as the > > >> Sarbanes-Oxley Act of 2002 > > >> < > > >> > > > https://www.ibm.com/links?url=https%3A%2F%2Fwww.govinfo.gov%2Fcontent%2Fpkg%2FPLAW-107publ204%2Fpdf%2FPLAW-107publ204.pdf > > >>> .* > > >> An example of this separation of duties, is that someone with > the > > >> role of CICS System Programmer must not also have the role of RACF > > >> Security Administrator. > > >> > > >> > > >> Does anyone know exactly which section of SOX it's referring to? > > >> > > >> ---------------------------------------------------------------------- > > >> For IBM-MAIN subscribe / signoff / archive access instructions, > > >> send email to [email protected] with the message: INFO > IBM-MAIN > > >> > > > > > > > ---------------------------------------------------------------------- > > For IBM-MAIN subscribe / signoff / archive access instructions, > > send email to [email protected] with the message: INFO IBM-MAIN > > > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [email protected] with the message: INFO IBM-MAIN > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
