Top Secret

  • 1.  Securing CEMT SET/PERFORM/DISCARD

    Posted Nov 21, 2018 03:54 PM

    My CICS administrator wants to qualify access to CEMT, allowing everyone to do INQUIRY but restricting SET, PERFORM and DISCARD to herself.  I'm experimenting in the test region (let's name it CICSTEST), aiming to limit my own access in the desired way before trying to make the definition general.  But I'm not seeing the results I want; I think I could use some expert input.  Here's the current status:

     

    1) Before I started, I saw that INQUIRE and SET were in each region's BYPLIST:

     

    TSS9570I BYPASS TABLE DISPLAY FOR FACILITY  <CICSTEST>
    TSS9571I RESOURCE=CEMT     BYPASS  NAMES:   INQUIRE  SET

     

    So I removed SET from the BYPLIST using the following comMand: "TSS MODIFY FAC(CICSTEST=BYPREM(CEMT=SET))".  At least I think that was the command I used; it was a while ago.  At any rate, now INQUIRE but not SET is shown in the BYPLIST.  Then I refreshed my ID.

     

    2) In the SPI class, two permissions:the CICS administrator's profile has SPI(**) ACCESS(ALL), and the ALL record has SPI(**) ACC(INQUIRE).

     

    3) In my own ID, OTRAN(CEMT) ACC(EXECUTE) FAC(CICSTEST)

     

    This works to the extent that I cannot execute CEMT in the prod region, and can in test.  But I'm nevertheless able to use SET to enable and disable a transaction, so I'm not being limited to ACC(INQUIRE) as I desire.  What am I missing?  I've never done this before—perhaps it's obvious—so I'm floundering a little.



  • 2.  Re: Securing CEMT SET/PERFORM/DISCARD
    Best Answer

    Broadcom Employee
    Posted Nov 21, 2018 04:32 PM

    Hi Bob,

     

    Knowledge document KB000027201 explains how to implementing SPI and secondary resource checking in CA-Top Secret. Below is a snippet from the document for SPI resource checking. 

     

    **

     

    To implement SPI resource checking:

    1. For CEMT commands, define OTRAN(CEMT) and permit ACCESS(EXECUTE) to the users that should be allowed to use CEMT. NOTE: Most users will not need access to CEMT.
    a. Own OTRAN(CEMT) via TSS ADD(dept) OTRAN(CEMT). To see if this is already owned, issue TSS WHOOWNS OTRAN(CEMT).
    b. Permit access to OTRAN(CEMT) via TSS PERMIT(acid) OTRAN(CEMT) ACCESS(EXECUTE).


    2. Turn on SPI resource checking:
    a. If FACMATRX=YES is set on the CICS facility in CA-Top Secret, set XCMD=YES on the facility. No recycle of CICS should be required to pick up this change.
    b. If FACMATRX=NO is set on the CICS facility in CA-Top Secret, set XCMD=YES in the CICS System Initialization Table (SIT). A recycle of the CICS region is required to pick up this change.

     

    3. Own and permit the SPI resources to be protected. (KB000027201 has a list of SPI resources that can be protected.)
    a. TSS ADD(dept) SPI(xxxxxxxx)
    b. TSS PERMIT(acid) SPI(xxxxxxx) ACCESS(yyyyyyyyy)

     

    **

     

    So for example, if you want CEMT SET TRANSACT(xxxx) protected, follow steps 1 and 2 above and step 3 would look like this:

     

    a. TSS ADD(dept) SPI(TRANSACT)
    b. TSS PERMIT(acid) SPI(TRANSACT) ACCESS(INQUIRE) for the acids that should be allowed to INQUIRE on transactions. 

    TSS PERMIT(acid) SPI(TRANSACT) ACCESS(ALL) to the CICS administrator. 

     

    On a side note, the SPI resource class is distributed as non maskable, so when owning and permitting SPI(**) ACC(ALL), the '**' is a literal and not a mask. You can issue TSS LIST(RDT) RESCLASS(SPI) to see if the resource is maskable or not. Even if the SPI resource class is maskable, doing a TSS ADD(dept) SPI(**) does not protect every SPI resource. It only allows you to permit SPI(**), which will allow access to all SPI resources. You will still have to own each SPI resource you want protected.

     

    Best regards,

    Bob Boerum



  • 3.  Re: Securing CEMT SET/PERFORM/DISCARD

    Posted Nov 27, 2018 02:03 PM

    Thanks, Bob.  I'm off now to look up the consequences of changing the FACMTRX setting, and/or to discuss with the CICS admin changing the CICS SIT entry.  No doubt I'll come up with more questions as I go.

    I think I understand the issue with using '**' in ownership, but I'll come back to that after I think I have SPI checking turned on.  All for now.

     

    (I used to teach end users about writing their own queries in DYL-280II, and I remember in particular one old lady who claimed to be stupid in such matters but was actually one of my brightest.  (This seems to be typical of old ladies taking programming classes, if my experience is any guide.  Most folks really are smarter than they give themselves credit for.)  She'd ask a question, and I'd start to answer—but after just a sentence or two she often cut me short.  "That's enough, that's enough!", she'd exclaim; she'd had her hint and now she was off following the trail on her own, just the way she wanted it.)