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 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 on behalf > of Jack Zukt > 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 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 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
Re: Separation of Duties RACF Security Admins/Systems Programmers - Sarbanes-Oxley
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 on behalf of Jack Zukt 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 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 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 > > > > 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
Re: The ultimate (another one!) definition of mainframe
+1, Radoslaw DJ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Channelized I/O WAS
> From Parwez: My mistake, the 370/195 had 2 MB, this customer's 360/75 had 1 MB In those ancient days an MB of memory was $$expensive$$ and fairly rare. In the very early 70s I worked in an installation that had two 360/75s, each with 3 MB (1 MB normal memory and 2 MB LCS). The second 75 was just for backup! I was impressed -- the largest systems I had touched before that were two 360/65s with large (256KB) memory and even these were impressive. Times have changed. (My primary laptop has 64 GB memory.) Bill Ogden -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
The ultimate (another one!) definition of mainframe
There is NO DEFINITION. Dot. Yes, there is no single definition of mainframe. Everyone may use it's own imagination. Of course some definition may be less popular than other. IMHO (note - this is OPINION), the most commonly used definition NOWADAYS is: IBM System Z. Note, there is nothing about security, capacity, etc. Just family of computers, like POWER or Sun, or (former) VAX, etc. Etymology of mainframe (This is excerpt from my book, manual for "Introduction to z/OS and mainframe" course) In the old days computers were very big, occupied many cabinets. Those cabinets were also called frames. There were no "single chip CPU", instead we had Central Processing Complex or just MAIN frame. The word does not contain any suggestions to advantages like performance, capacity, reliability, etc. Former mainframe world In the old days there were several mainframe suppliers, however in most cases the machines were not compatible. Different hardware, different OS, different channels, different communications. Examples were Burroughs, ICL, Siemens, Bull, Honeywell, RCA, etc. Former classification of computers Microcomputers - PC, Apple Mac (usually) RISC machines (Sun, HP, AS/400, RS/6000, ICL K-server, Escala) - minicomputers (big) computers - ICL 1900, IBM S/390 (with predecessors and successors), UNIVAC, GCOS, etc. supercomputers - quite different from mainframes/big computers and quite different uses. Yes, every sentence can be corrected or complemented. No, it doesn't matter. Because THERE IS NO DEFINITION of mainframe. :-) -- Radoslaw Skorupka Lodz, Poland -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Automount (was USS Features)
W dniu 04.08.2023 o 22:04, Jon Perryman pisze: > On Monday, July 31, 2023 at 08:29:07 AM PDT, Radoslaw Skorupka wrote: Regarding automount feature: IMHO it is less than useless. While there is truth to what you say about automount, there are uses where people find it useful because it provides features that some customers need. Most notably, everything in a filesystem is randomly placed within that filesystem without any controls. Ask a z/OS storage admin if he could tolerate the same situation where all z/OS datasets are placed randomly (no SMS nor disk esoterics). I asked storage admin (myself) and heard NO. Automount changes nothing to what you described (and what is IMHO disputable, but this is different thread). Oh, BTW: I met many other storage admins in my career. No one liked automount feature, usually they didn't express any opinion, but sometimes they complain on that. However it is not reality show or beauty contest, rather I'd like to see some real advantages of automount. On Monday, July 31, 2023 at 08:29:07 AM PDT, Radoslaw Skorupka <0471ebeac275-dmarc-requ...@listserv.ua.edu> wrote: Regarding automount feature: IMHO it is less than useless. - It require some effort to establish and manage (including storage adm.) - It wastes space, because even smallest empty home directory occupies first extent of the ZFS/HFS. - Space (extents) taken by some large files and then deleted is still occupied by the user. - Tools like find may omit currently unmounted directories, sometimes making the search ineffective. - I vaguely remember the z/OS Unix does not like excessive filesystems being mounted. - Automount/demount consume some resources. - Last, but not least: I observed the are more active TSO users than USS users. The same apply to CICS, etc. Sometimes one may enter TSO OMVS just out of curiosity. In case of automount yet another filesystem is created. From the other hand one can create common filesystems for all home directories. When needed it can be divided among multiple filesystems. Users with large needs may have dedicated filesystems. Empty user directory does not consume resources. Even "touched". My €0.02 Regards -- Radoslaw Skorupka Lodz, Poland -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Separation of Duties RACF Security Admins/Systems Programmers - Sarbanes-Oxley
At most installations, I think, they start out with the sysprogs doing security, and in the first months or even a year or two that makes sense, while things are getting set up and the kinks worked out. But at every installation I've worked at, the security function has evolved sooner or later into a separate area. Usually much later than it should, but what the heck, they always get it done eventually. But at those same shops, when I come aboard as a sec analyst I'm very often given the keys not just to the security kingdom but to the system kingdom as well. They know that security jocks aren't sysprogs, but by tradition they nevertheless give me the sysprog access, logon procs, ISPF menus and everything. And as a security jock that makes me uncomfortable; I'm afraid I'll accidentally trash something important while I was just trying to explore. And believe me, security jocks like to explore :). --- Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313 /* I don't have to attend every argument I'm invited to. */ -Original Message- From: IBM Mainframe Discussion List On Behalf Of Jack Zukt Sent: Saturday, August 5, 2023 06:08 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. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
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 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 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 > > > > 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
Re: Mainframe Makers.... WAS: Ars Technica: The IBM mainframe: How it runs and why it survives
I have been using ISPF workplace extensively for years now but, for some reason, I cannot convince anyone else to use it. It is very useful when you have to work with different systems that use different conventions for the same type of files, like SMF, SMPE, DCOLLECT reports, SYSLOG, to name a few. You can create lists with the same name on each system so you will not have to remember which is the dataset name on that particular system. It is a very useful feature, for a few of us at least. Best wishes Jack On Fri, Aug 4, 2023, 19:16 Schmitt, Michael wrote: > You, sir, win the 100 points I have been waiting to award anyone who can > figure out how to effectively use the ISPF Workplace. > > Now explain it to the rest of us. > > -Original Message- > From: IBM Mainframe Discussion List On Behalf > Of Tom Marchant > Sent: Friday, August 4, 2023 12:36 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Mainframe Makers WAS: Ars Technica: The IBM mainframe: > How it runs and why it survives > > I use data set lists in the ISPF workplace (option 11) for similar reasons. > I have rarely used 3.4 for decades. > > -- > Tom Marchant > > On Fri, 4 Aug 2023 13:14:54 -0400, Bob Bridges > wrote: > > >No, sorry, what I really mean is that instead of going to ISPF option 2 > and typing in a DSN, I generally type "tso ed " on the ISPF command > line. Same for VW and BR, and a few other REXX execs. > > > >The ED, BR and VW commands run the DSN I give it through RENDSN, a > routine that checks the string against a list I maintain. So if I say "tso > ed jg", it'll look up JG and return the name of whatever PDS I'm using at > the current installation for general JCL. The RENDSN list has a few dozen > DSNs in it that I use often enough to bother recording them; that way I > don't have to remember the name of the production CFILE, or where the > SuperSession parms are stored, or whether at this client the common REXX > library for the security team is this or that. So most of my most commonly > used "DSNs" are really two- or three-char shortcuts. Saves me some > thinking and a lot of typing. > > -- > 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
