At NSF we had panels for the routine stuff and anything else came to me. I was required to notify my management of what I did and why, but otherwise had a free hand. We were too small to justify a dedicated security admin.
________________________________________ From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> on behalf of Wayne Bickerdike <wayn...@gmail.com> Sent: Saturday, August 5, 2023 11:36 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Separation of Duties RACF Security Admins/Systems Programmers - Sarbanes-Oxley At Australian Defence we heavily used GROUP SPECIAL. That relieved sysprogs from daily BAU tasks such as password resets or resume for IDs where people were inactive due to vacations or active service. Other shops I've worked at had a dumbed down RACF administrative function. That often proved to be a bottleneck for new hires getting the profiles right for their workload, that's why role based models work well if they are designed correctly for incumbents. On Sun, Aug 6, 2023 at 7:52 AM Seymour J Metz <sme...@gmu.edu> wrote: > From a SysProg perspective, a well trained security administrator can > relieve a lot of burden. OTOH, a poorly trained or uncooperative security > administrator can be a nightmare, and may leave you less secure, As usual, > the Devil is in the details. > > ________________________________________ > From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> on behalf > of Jack Zukt <jzuk...@gmail.com> > Sent: Saturday, August 5, 2023 6:07 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Separation of Duties RACF Security Admins/Systems Programmers > - Sarbanes-Oxley > > 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 <mike.a.sch...@gmail.com> 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 <ste...@wkyr.net> 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 < > bigironp...@gmail.com > > > > > > > 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 lists...@listserv.ua.edu with the message: INFO > > IBM-MAIN > > > >> > > > > > > > > > > ---------------------------------------------------------------------- > > > For IBM-MAIN subscribe / signoff / archive access instructions, > > > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > > > > > > ---------------------------------------------------------------------- > > For IBM-MAIN subscribe / signoff / archive access instructions, > > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- Wayne V. Bickerdike ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
