Wow, that was a while ago! Thanks, Joseph.
Let's see, four years ago I was probably at Comerica Bank on their big RBAC project. I'm working on audit issues for an insurance company now, and I haven't looked at the BYPLIST in a couple years, but unless I've forgotten something important here's what I think I know:
IBM divides the IBM-supplied transactions into three categories (see
https://www.ibm.com/docs/en/cics-ts/5.4?topic=transactions-categories-cics-supplied):Cat-1 transactions are never to be used by end users; they're to be called only by CICS itself. These should never by on the BYPLIST. Or I guess they could be on the BYPLIST set to prevent access, rather than allow it; that can be done, right?
Cat-2 are extra powerful and generally should be restricted to specific users, such as the CICS systems programmer. It's up to the individual installation, of course; some of them want all CICS developers to have additional power, at least in the non-prod LPARs. But the BYPLIST is exactly the place they probably shouldn't be, since then any permissions written to restrict access to (for example) CEMT will be ignored.
Cat-3 transactions are always available to all users. These transactions DO NOT ASK the security product before executing -- they just do what they do -- so no installation rule against access to them will be honored or even noticed, and any of them in the BYPLIST is simply a waste of space.
If the BYPLIST were set up to restrict some access, then I think I could see some sense to your explanation: It would be cutting off access to sensitive transactions for more than one release of CICS. (It still wouldn’t be smart -- it would prevent admins from allowing access even to powerful users.) But since the default BYPLIST bypasses the permissions and ~allows~ access, this explanation doesn't make sense to me: Broadcom is including transactions as they change from one implementation to the next, sure, but they're mostly transactions that should ~not~ be universally permitted. It feels more like whoever set up the default BYPLIST, back in the dim mists of time, misunderstood the purpose and put in exactly the wrong ones.
What TSS needs is not that the BYPLIST be examined and split up (so to speak) among different CICS versions, but that it be scrapped entirely and repopulated from the beginning.
---
Bob Bridges,
robhbridges@gmail.com, cell 336 382-7313
/* Miss Manners has also observed that when children are truly allowed to express their preferences, uninfluenced by the dreary adult expectation that they must all be artistic and original little noble savages, they come out resoundingly in favor of rigid traditionalism. The devotion to ritual exhibited by the average toddler in regard to his bedtime routine would make a nineteenth-century English butler look like a free spirit. -from "Miss Manners' Guide to Rearing Perfect Children" by Judith Martin */
Original Message:
Sent: 12/21/2021 4:20:00 PM
From: Joseph Porto
Subject: RE: Re: Why are there cat-1 and -2 transactions in our CICS BYPLIST?
Bob,
Looked further into your question with Level 2.
Top Secret currently supports multiple release of CICS. Throughout the years, IBM keeps changes what transactions should be bypassed and protected. Since Top Secret supports multiple CICS releases, we tried to construct a bypass list for all of the releases. In a perfect world, everyone would be running on the latest z/OS release and CICS, but reality we have to support multiple releases of z/OS and CICS. Fortunately, the bypass list can be modified to meet security requirements.
Please submit an enhancement request that multiple bypass lists be supported depending on the CICS release, so it can be considered by the community and Broadcom for a future release of TSS.
Regards,
Joseph Porto - Broadcom Level 1 Support
Original Message:
Sent: Jan 04, 2018 03:22 PM
From: Robert Bridges
Subject: Re: Why are there cat-1 and -2 transactions in our CICS BYPLIST?
Josef, I may have misunderstood you but I think I haven't made myself clear yet. I'm not planning to move any transactions from the BYPLIST to the ALL record; I agree with you and Brian that it would slow the system down without providing much benefit.
My complaint here is that almost 100 of the transactions in the BYPLIST shouldn't be allowed to users at all; they're in the standard BYLIST by error, and should be removed. Well, about 75 shouldn't be allowed to users; another 20 or so should be permitted only to selected users.