Top Secret

In my previous question, Joe Porto turned me on to the existence of the BYPLIST in TSS, a list of transactions defined in a CICS facility that are to be allowed without consulting TSS.  Thanks to Joe and to Josef Thaler for pointing me to this.

Now I've examined the sample listing in the TSS manual, and I see that it includes many CICS-supplied transactions that IBM defines as category 1 or category 2.  If I were to believe the documentation I should immediately remove those transactions.  I'd rather check, though.  Can anyone explain why these transactions are in the bypass list?

The cat-1 transactions included in the r15 manual are CATA CATD CDBD CDBF CDBO CDBQ CDTS CEPD CEPM CESC CEX2 CFCL CFOR CFQR CFQS CFTL CFTS CGRP CIOD CIOF CIOR CIRR CIS4 CISB CISC CISD CISE CISM CISQ CISR CISS CIST CISU CISX CITS CJGC CJPI CJSR CJTR CMTS COVR CPIR CPIS CPLT CRLR CRMD CRMF CRSQ CRSY CRTP CSFR CSFU CSHA CSHQ CSKP CSNC CSNE CSOL CSPQ CSQC CSSY CSTE CSTP CSZI CTSD CWBG CWXN CWXU CXCU CXRE.  IBM says these transactions are never to be allowed to any user; they're for the use of the region itself.

The cat-2 transactions included in the r15 manual's sample BYPLIST are CDBT CECS CEHP CEHS CEPT CKAM CKTI CPIH CPIL CPIQ CPMI CRTE CSGM CSHR CSM1 CSM2 CSM3 CSM5 CSMI CVMI.  These transactions, also according to IBM, are powerful transactions for the use of some users but not all.

As I understand the TSS CICS BYPLIST, it's to bypass security checking for the named transactions.  Should I not remove from it all of the above?

Bob,

The requirement to have them on the bypass list is not a TSS requirement but an IBM. Need to find the where this is  documented in the IBM doc and get back to you.

These transactions are used by CICS and not users at terminals. If you look at the link in your post, it states that. It also says that unpredictable results can occur if users attempt to use those transactions.

Regards,

Joseph Porto - CA Level 1 Support

Interesting.  I'm aware of the IBM documents I linked to above (you saw those links, right?), but they contradict putting cat-1 and cat-2 transactions in a bypass list.  If IBM says otherwise in other documents, and you can find those other documents, I have a question to bring to the IBM documentation team.  They're a lot slower to respond than your guys :-), but they do usually respond eventually.

(You say "These transactions are used by CICS and not users at terminals", but don't mix them up:  I spoke of both category 1 and 2 above, and it's the cat-1 transactions that are for CICS usage only.  The cat-2 transactions are for users, according to IBM.)

Bob,

I vaguely remember looking into this question once an long time ago. Its not a question we get too often.

I did a quick search and didn't come up with anything. Need to dig deeper. Will let you know once I find something.

Regards,

Joseph Porto - CA Level 1 Support

Bob,

Spoke with Bob Boerum who has looked into the catergory 1, 2 and 3 transactions on the bypass list and referred me to the following guidelines for them.

Here are guidelines regarding category 1, 2, and 3 transactions in CICS.

  
(TSS does not have a say into what category a CICS transaction is         
classified.)                                                              
                                                                          
Category 1 transactions are system transactions that should never                       
be initiated from a terminal. If a Category 1 transaction               
is associated with a terminal, it will fail with an AEY7 abend.         
These transactions seem to only be used by the CICS region acid and     
DFLTUSER. TSS is distributed with the Category 1 transactions in the    
bypass list. Since an AEY7 abend occurs if these transactions are       
associated with a terminal, users won't be able to execute them.        
If these transactions are removed from the bypass list, they should     
be permitted to the CICS region acid and DFLTUSER.                      
                                                                        
Category 2 transactions are system transactions that CAN be initiated   
from a terminal. These transactions are not in the bypass list          
and can be protected at the site's discretion.                          
                                                                        
Category 3 transactions are either initiated by the terminal user or    
associated with a terminal. All CICS terminal users, whether they are   
signed on or not, require access to transactions in this category.      
For this reason, category 3 transactions are exempt from any security   
check, and CICS permits any terminal user to initiate these             
transactions.        

                                                                                 
For category 3 transactions, sites are recommended to specify                    
RESSEC(NO) and CMDSEC(NO) on the CICS transactions resource definition.          
These transactions should be defined to RACF, but this definition does           
not affect actual task attach-time processing. It is used only for               
QUERY SECURITY purposes.                                                         
                                                                                 
Here is a list of the category 1 transactions from IBM's website:                
                                                                                 
http://pic.dhe.ibm.com/infocenter/cicsts/v5r1/index.jsp?topic=%2Fcom.ibm.cics    
.ts.doc%2Fdfht5%2Ftopics%2Fdfht56s.html                                          
                                                                                 
The transactions that have operator interfaces are marked by an asterisk (*).    
The remainder therefore have no operator interface.                              
                                                                                 
Transaction   Description                                                        
-----------   -----------                                                                                     
CATA          Defines autoinstall automatic terminal                            
CATD          Deletes autoinstall terminal                                      
CDBD          DBCTL disable function                                            
CDBF          CICS DB2  attachment facility shutdown force transaction          
CDBO          DBCTL control function                                            
CDBQ          CICS DB2 attachment facility shutdown quiesce transaction         
CDTS          Provides remote single delete transaction                         
CEPD          Event processing dispatcher                                       
CEPF          Event processing deferred filtering task                          
CEPM          Event processing queue manager                                    
CESC*         Processes timeout and signoff for idle terminals                  
CEX2          CICS DB2 protected thread purge mechanism and other CICS DB2      
              services                                                          
CFCL          CFDT load                                                         
CFOR          RLS offsite recovery                                              
CFQR          RLS quiesce receive                                               
CFQS          RLS quiesce send                                                  
CFTL          Shared DT load                                                      
CFTS          Provides remote mass flag transaction                                      
CGRP          Provides z/OS Communications Server (previously called VTAM )              
              persistent sessions                                                        
CIS4          IPIC External Security Interface (ESI) transaction                         
CISB          IPIC release IPCONN on the server side of a connection (BIS                
              processing                                                                                     
CISD          IPIC release IPCONN on the client side of a connection                     
CISE          IPIC error and message program                                             
CISM          IPIC remote scheduler                                                      
CISP          IPIC connection heartbeat control transaction                              
CISQ          IPIC local queue processing                                                
CISR          IPIC request/response receiver                                             
CISS          IPIC acquire IPCONN on the server side of a connection                     
CIST          IPIC terminate IPCONN                                                      
CISU          IPIC recovery transaction                                                  
CISX          IPCONN recovery and resynchronization transaction for XA                   
              clients                                                                        
CIS1          IPIC connection heartbeat requester transaction               
CITS          Provides remote autoinstall transaction                       
CJSL          JVM server listener (autoinstalled by CICS)                   
CJSR          CICS JVM server resolution transaction                        
CJTR          Object Transaction Services (OTS) resynchronization transaction
CMTS          Remote mass delete transaction                                
COVR          Provides open z/OS Communications Server retry transaction    
CPIR          Pipeline resolution transaction                               
CPIS          WS-AT transaction that is attached when resynchronization is  
              required                                                      
CPLT          Initializes PLT processing                                    
CRLR          Bundle resource resolution transaction                        
CRMD          Provides remote mass delete transaction                       
CRMF          Provides remote mass flag transaction                         
CRSQ          Remote schedule purging (ISC)                                 
CRST          Region Status long running task                               
CRSY          Resource manager resynchronization                            
CRTP          Persistent sessions restart timer transaction                 
CSFR          RLS cleanup                 
CSFR          RLS cleanup                                                   
CSFU          File open utility                                             
CSHA          Scheduler services (autoinstalled by CICS)                    
CSHQ          Scheduler services domain long running task                   
CSKP          Writes system log activity keypoint                           
CSNC          Interregion control program (MRO)                             
CSNE          Provides z/OS Communications Server (previously called VTAM)  
              node error recovery                                           
CSOL          TCP/IP listener (autoinstalled by CICS)                       
CSPQ          Terminal page cleanup (BMS)                                   
CSQC          CICS quiesce after system log failure                         
CSSY          Provides entry point attach                                   
CSTE          Processes terminal abnormal conditions                        
CSTP          Provides terminal control transaction                         
CSZI          Front End Programming Interface (FEPI), only active if FEPI   
              installed                                                     
CTSD          Temporary storage delete recoverable queue                    
CWBG          CICS web support cleanup transaction                          
CWXN          CICS Web support attach transaction       
CWXU          CICS Web support USER protocol attach transaction              
CXCU          Performs XRF tracing catchup                                   
CXRE          Reconnects terminals following XRF takeover                    
                                                                             
The signon and signoff transactions are CESN and CESF. (CSSN and CSSF        
are signon and signoff transactions for the old CICS releases but remain     
in the default bypass list.)      

Please let us know  if there are any questions.

Regards,

Joseph Porto - CA Level 1 Support

Right, the information you provide above is found at the IBM links that I cited in my first post.  They list each CICS-supplied transaction, group each into one of three categories, and describe each category.

...Which brings me back to my original question:  There are many cat-1 and cat-2 transactions in the standard CICS BYPLIST as described in the TSS manuals.  But given that IBM says cat-2 transactions are to be handed out to users only carefully, and cat-1 never, why would any of them be in the BYPLIST?  Should I not remove them at my installation, and shouldn't CA remove them from TSS as shipped?  Joe, you said "The requirement to have them on the bypass list is not a TSS requirement but an IBM", but where is that documented?  The IBM web pages you and I are both looking at say the opposite.

I think too, that the provided bypass list could be reworked, at least could be reviewed and confirmed, that it is up to date! 

Bob,

One additional note to add to Joe's comment. In TSS R16 one can specify on the facility matrix entry for CICS BYPLIST(NO). This will disable the TSS BYPLIST. Remember if you specify BYPLIST(NO) one must authority these transactions and resources  that are needed.  Inorder to help one remove the byplist one can set the BYPLIST facility option to AUDIT.

This option will allow one to still use the BYPLIST and see which ACIDs are using the transactions and resources. Then one can permit the ACIDs the transactions or resources and set the BYPLIST(NO).

When one reviews the TSSUTIL report when specifying AUDIT. One will see a '+' sign in front of the transaction or resource that need to be permitted to the ACID.

Sample entry from the TSSUTIL:

12/27/17 11:15:49 XE58 CICSDEF CTS520T CICSPROD FAIL DFHGMM OK+A LCF S880029
RESOURCE TYPE & NAME : XACTION +CSGM CSGM

Brian Luger TSS SE Level Two  

Ah, I didn't know that.  Thanks, Brian.  The client I'm thinking about just now is using r15, but I don't plan to disable the BYPLIST in any case.  What I may find useful is this AUDIT feature; it'll help me figure out whether any of the cat-1 and -2 transactions that I envision removing from the bypass list (because I think they never belonged there in the first place) are being used.

I'd like to emphasize, that BYPLIST(AUDIT) activates audit only for TRANIDs in the BYPLIST. This was clearified in a CA support case by that time. Bypasses caused by TRAN(S) or probably other entries of the bypass list do not result in an audit record. 

In the context of this question, I'd like to ask:

What is the advantage of a byplist over security-admin by the *ALL*-record?

Joesf,

The bypass list  has a shorter path length, then using the *ALL* record. One does not need to issue security call

if the transaction is in the TRANID bypass list. 

Many thanks, Brian for your indication!

Are the savings of cpu cycles when using the bypass list still relevant? Or, in other words: how many k instructions can be saved per „avoided“ security call?

Are there same points of reference about the pathlength of a BYPLIST-bypass and the pathlength of a regular security call? Or how to determine it on site? 

Josef (and maybe Brian too), you may be missing something more fundamental, here.  Both the BYPLIST and the ALL record have the effect of permitting all users to use a transaction.  But what I'm proposing is not that I should move some transactions from the BYPLIST to the ALL record, but that I should remove access to them entirely.  According to IBM's documentation, many of the transactions listed in the standard bypass list ought not be permitted to any user—and many others should be permitted to only a few.  The bypass list, as far as I can see, contains many, many transactions that should not be there at all.

Many thanks Bob for your statement. I see what you mean! There is a kind of „price“ to be payed, when you continue to use the bypass list versus conventional security administration.

And that’s why I’m asking for the gain of using the bypass list.

Of course just to move the bypass trans to the all record would not yet result in a proper security admin, which has to be according to the cics categories and to the policies of the installation.

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.

Bob, 

I really would like to learn the benefit (in pathlength - cpu) of the bypass-list compared to "regular" security-admin, because I perceive the bypass list as somehow "disturbing" proper security. (Effective permissions do not appear as such in the security set of a user, TSSSIM ?, Audit ?, SECPRFX-compliant ? etc. ...)

In either case the BYPLIST should be reworked, if the performance impact is not that relevant could be renounced.

btw.: Do you know the CICS SIT parameter SECPRFX ? In my understanding it could make security-admin clearer, easier and more flexible ...

Kind regards,

Josef

In that case—not conflating it with my question about the actual contents of the BYPLIST—I would have to assume it's more efficient than normal OTRAN permissions in TSS because it bypasses the normal TSS algorithm.  I gather than if transaction ABCD is in the BYPLIST, then when a user invokes ABCD, CICS won't even ask TSS about it, it'll just allow the access.

This can be good or bad.  If you really want anyone to be able to run a transaction, no matter what ID he used to log on or even if he's not logged on at all, then it seems to me the BYPLIST is the place for it.  Off-hand that might be a transaction that displays the time of day, or your company's current price on the NYSE.  (At least, it is right up until some ill-natured person uses such transactions to launch a DoS attack, slowing your system with lots of such invocations.)

You wouldn't want to use it for very many transactions, in my opinion.

You mention "the CICS SIT parameter SECPRFX", but I'm a RACF/ACF2/TSS jock; I've sort of looked at CICS parms, a little, but I'm not familiar with any of them.

SECPRFX is a CICS SIT (system initialization table) parameter-option. By definition it prefixes the CICS-Region-Id or a site specified string (could correspond to "facility") to the resnames being checked in security calls done by/within CICS.

I have to take note from a clearifying support case, that top secret does not support this CICS option, resp. neutralizes the effect of this CICS-parameter-option. I'm awaiting a technote about this with some explanations and reasons.

Resnames with such prefixes would offer a single-system-scope of CICS-ressources and could be used advantageously by powerful and standard features like best-match-algorithm, masking, auditing and so on.

Dealing with SECPRFX I had to take note, that Top Secret nullifies the SECPRFX. 

This has also been cleared in a support case.

As a result of this support case a technote was written. 

https://comm.support.ca.com/kb/how-ca-top-secret-manages-the-cics-secprfx-initialization-parameter/kb000072692 

Because I consider SECPRFX as a real enhancement for CICS security-administration, I submitted

https://communities.ca.com/ideas/235738957-make-top-secret-cics-obey-cics-system-initialization-parameter-secprfx

You might want to share your opinion there.

Many thanks to those of you who replied to my questions.  For anyone still interested, I just had a phone call with two CA guys who answered my questions definitively — and, I hope and believe, accurately :-) — and I thought I'd pass along what I learned:

1) All category-1 transactions, as defined by IBM, must not be invoked from a terminal.  (CICS gurus among you should forgive my inexact terminology.)  I gather CICS calls TSS about some of these cat-1 transactions; others it does not.  All 70 cat-1 transactions are in the TSS BYPLIST.  But: Each transaction in the BYPLIST is accompanied by an internal flag that we as TSS admins cannot see; it indicates whether the transaction can be invoked from a terminal.  All the cat-1 transactions that trigger a call to TSS have that flag set to forbid connection by a terminal.  So (according to the CA guru who called me this morning) even though the BYPLIST appears to allow users to call CFCL, for example, an invisible flag would cause the code to check whether the caller is attached to a terminal and then respond to CICS "not allowed".  So for my part, I intend to leave all the cat-1 transactions in the list.

2) Category-2 transactions should be handed out to humans on a restricted basis.  Some are appropriate for the systems programmers who support CICS, some for applications developers, and so on, but none of them are for just anyone.  The two CA guys, when we started looking at the 20 cat-2 transactions in the BYPLIST, seemed surprised and puzzled; I expect they're currently writing notes for a change.  But meanwhile they assure me that I can remove them from the BYPLIST in favor of more explicit TSS rules, which is what I intend to do.