Topic
  • 21 replies
  • Latest Post - ‏2013-10-18T20:25:26Z by salami
salami
salami
44 Posts

Pinned topic Trusted Userid

‏2013-02-14T18:17:05Z |
I ran "audit concern overview" which flagged CICS Category 1 and 2 trancodes as a priority 42 because Trusted userid "????????" has access to it via " UACC/READ TCICSTRN *" profile.

2 questions: (1) does ???????? refer to started tasks running as trusted? (2) these trancodes are secured in GCICSTRN profiles with UACC/NONE but the audit says otherwise. I notice all the audit concerns defaults to "UACC/READ TCICSTRN.*" profile. is there a way to have zsecure include my gcicstrns profiles?

regards, bob
Updated on 2013-03-29T17:24:49Z at 2013-03-29T17:24:49Z by salami
  • HansSchoone
    HansSchoone
    39 Posts

    Re: Trusted Userid

    ‏2013-02-14T19:47:39Z  
    I would suggest you looke at the CICS region display RE.C.R and notice wether it indeed mentions GCICSTRN for transactino processing and shows the class as acctive.
    And then in RA.S check the GCICSTRN class shows 'RACLISTed by application only Yes'

    If the former is true but the latter is not, it may be that you miss a PTF. It would help to mention the zSecure release.
  • salami
    salami
    44 Posts

    Re: Trusted Userid

    ‏2013-02-14T21:03:34Z  
    I would suggest you looke at the CICS region display RE.C.R and notice wether it indeed mentions GCICSTRN for transactino processing and shows the class as acctive.
    And then in RA.S check the GCICSTRN class shows 'RACLISTed by application only Yes'

    If the former is true but the latter is not, it may be that you miss a PTF. It would help to mention the zSecure release.
    I see GCICSTRN active in RE.C.R.

    I have “RACLISTed by application only Yes” for tcicstrn but NO for gcicstrn.

    Product/Release
    5655-T01 IBM Security zSecure Admin 1.13.0
    5655-T02 IBM Security zSecure Audit for RACF 1.13.0
    CKRCARLA 1.13.0 10/26/11 04.57 HCKR1D0

    Regards, bob
  • Tom.Zeehandelaar
    Tom.Zeehandelaar
    144 Posts

    Re: Trusted Userid

    ‏2013-02-15T08:00:24Z  
    • salami
    • ‏2013-02-14T21:03:34Z
    I see GCICSTRN active in RE.C.R.

    I have “RACLISTed by application only Yes” for tcicstrn but NO for gcicstrn.

    Product/Release
    5655-T01 IBM Security zSecure Admin 1.13.0
    5655-T02 IBM Security zSecure Audit for RACF 1.13.0
    CKRCARLA 1.13.0 10/26/11 04.57 HCKR1D0

    Regards, bob
    Hi Bob,

    so this setting means that your GCICSTRN profiles are not RACLISTed and, therefore, ignored.
    You must change this settings for the GCICSTRN class, so that the GCICSTRN profiles are also RACLISTED. If you have defined the appropriate GCICSTRN profiles, this action should mitigate the risk that is reported by the audit concern.

    To see the effect of this change in your "audit concern overview", you must first refresh the CKFREEZE data set that you are using to process the audit concern overview. The audit concern for user ???????? that can use the CICS Category 1 and 2 trancodes must now have disappeared.

    BTW the user ???????? does not refer to a started task with the trusted attribute. Within the context of zSecure Audit, a trusted user is a user with (at least) one UPDATE access to a resource that is part of the TCB (Trusted Computing Base). This access allows the pertinent user to change certain (sub)system settings, or bypass RACF access verification. In this case, the user ???????? can use CICS OPERATOR transactions and CICS transactions that should only be used by CICS Region IDs.

    User ???????? refers to the "Default uid remote NJEUSERID", that is set in your SETROPTS. This userid is assigned to all remote users that access your JES environment with NJE (Network Job Entry) or RJE (Remote Job Entry) and do not have a userid defined in the local RACF database. You can review and, optionally, change the default NJEUSERID in RA.S.

    So what this audit concern tries to explain is that all remote NJE and RJE users can use CICS OPERATOR commands. This is probably not intentional.

    I hope this helps.
    Best regards, Tom Zeehandelaar
  • salami
    salami
    44 Posts

    Re: Trusted Userid

    ‏2013-02-15T21:07:41Z  
    Hi Bob,

    so this setting means that your GCICSTRN profiles are not RACLISTed and, therefore, ignored.
    You must change this settings for the GCICSTRN class, so that the GCICSTRN profiles are also RACLISTED. If you have defined the appropriate GCICSTRN profiles, this action should mitigate the risk that is reported by the audit concern.

    To see the effect of this change in your "audit concern overview", you must first refresh the CKFREEZE data set that you are using to process the audit concern overview. The audit concern for user ???????? that can use the CICS Category 1 and 2 trancodes must now have disappeared.

    BTW the user ???????? does not refer to a started task with the trusted attribute. Within the context of zSecure Audit, a trusted user is a user with (at least) one UPDATE access to a resource that is part of the TCB (Trusted Computing Base). This access allows the pertinent user to change certain (sub)system settings, or bypass RACF access verification. In this case, the user ???????? can use CICS OPERATOR transactions and CICS transactions that should only be used by CICS Region IDs.

    User ???????? refers to the "Default uid remote NJEUSERID", that is set in your SETROPTS. This userid is assigned to all remote users that access your JES environment with NJE (Network Job Entry) or RJE (Remote Job Entry) and do not have a userid defined in the local RACF database. You can review and, optionally, change the default NJEUSERID in RA.S.

    So what this audit concern tries to explain is that all remote NJE and RJE users can use CICS OPERATOR commands. This is probably not intentional.

    I hope this helps.
    Best regards, Tom Zeehandelaar
    Hi Tom, i don't see tcicstrn/gcicstrn raclisted in our setr opts. I tried to and get ICH14027I (not allowed by CDT), and yet when I make a change from cnr it automatically generates the "setr raclist(tcicstrn)refresh" which tells me it is raclisted?

    and thank you for info on ????????...i see that in our setr opts
  • SystemAdmin
    SystemAdmin
    310 Posts

    Re: Trusted Userid

    ‏2013-02-15T22:27:34Z  
    • salami
    • ‏2013-02-15T21:07:41Z
    Hi Tom, i don't see tcicstrn/gcicstrn raclisted in our setr opts. I tried to and get ICH14027I (not allowed by CDT), and yet when I make a change from cnr it automatically generates the "setr raclist(tcicstrn)refresh" which tells me it is raclisted?

    and thank you for info on ????????...i see that in our setr opts
    Hi Bob,
    CICS classes are raclisted by the application only. So the Class Descriptor Table is set up on purpose so that SETR RACLIST(class_name) won't work on these types of general resource classes.
    The reason is that the caller of RACF, CICS in this case, is in control of whether or not the data will be RACLISTed; so this is WAD (working as designed).
    So unless your CICS regions are up then you won't see them show up in GLOBAL=YES RACLIST ONLY= section of the SETROPTS LIST as well.

    Also, when you issue SETROPTS LIST you will only ever see member class profiles in the GLOBAL=YES RACLIST ONLY = section.
    Remember that grouping classes are information that is only ever stored in the RACF DB only and the grouping class shares the same POSIT value as the member class. When RACLIST processing occurs RACF takes the information from the member and grouping classes, performs a profile merge and then places the results dataspace for use by the application.

    Have you tried using RA.S instead of SETROPTS LIST?
    This is the Setropts, RRSF, and class settings menu. It provides much more robust information then SETROPTS LIST.

    Type =RA.S to jump to this menu.
    Then put an S next to "RACFCLAS"
    Now you should be at a screen that says "RACF class settings" at the top.

    From the command line you can issue a FIND command for your CICS class names.
    That will jump the cursor to that exact field that contains the class name, backwards tab or place the cursor on the "__" field to select additional information about that class.

    Now you should have a menu that is showing how the class is configured. It's the equivalent of what SETROPTS tells you but instead of by setting its by class and I think it's in a much more easy format to read for human beings.

    Note the "Profiles can be RACLISTed" setting is no for both member and grouping classes.

    Under the "Profile residency options" section you can find out if a class is RACLISTed,
    Hope that helps,
    Joel
  • SystemAdmin
    SystemAdmin
    310 Posts

    Re: Trusted Userid

    ‏2013-02-15T22:34:14Z  
    Hi Bob,
    CICS classes are raclisted by the application only. So the Class Descriptor Table is set up on purpose so that SETR RACLIST(class_name) won't work on these types of general resource classes.
    The reason is that the caller of RACF, CICS in this case, is in control of whether or not the data will be RACLISTed; so this is WAD (working as designed).
    So unless your CICS regions are up then you won't see them show up in GLOBAL=YES RACLIST ONLY= section of the SETROPTS LIST as well.

    Also, when you issue SETROPTS LIST you will only ever see member class profiles in the GLOBAL=YES RACLIST ONLY = section.
    Remember that grouping classes are information that is only ever stored in the RACF DB only and the grouping class shares the same POSIT value as the member class. When RACLIST processing occurs RACF takes the information from the member and grouping classes, performs a profile merge and then places the results dataspace for use by the application.

    Have you tried using RA.S instead of SETROPTS LIST?
    This is the Setropts, RRSF, and class settings menu. It provides much more robust information then SETROPTS LIST.

    Type =RA.S to jump to this menu.
    Then put an S next to "RACFCLAS"
    Now you should be at a screen that says "RACF class settings" at the top.

    From the command line you can issue a FIND command for your CICS class names.
    That will jump the cursor to that exact field that contains the class name, backwards tab or place the cursor on the "__" field to select additional information about that class.

    Now you should have a menu that is showing how the class is configured. It's the equivalent of what SETROPTS tells you but instead of by setting its by class and I think it's in a much more easy format to read for human beings.

    Note the "Profiles can be RACLISTed" setting is no for both member and grouping classes.

    Under the "Profile residency options" section you can find out if a class is RACLISTed,
    Hope that helps,
    Joel
    Hi again Bob,
    Replying to my own post because I hit a key on this new keyboard too soon and didn't mean to post just yet. Ugh!

    Under the "Profile residency options" section you can find out if a class is RACLISTed, if it is required to be RACLISTED, or if it is "RACLISTed by application only".

    So for CICS you should see:
    Profile residency options
    Profiles in dataspace No
    RACLIST required No
    RACLISTed by application only Yes

    Today the way zSecure works it isn't actually checking to see if profiles are in the dataspace for a class that's RACLISTED by the application only. This is not a bug but WAD in case you're wondering.

    Further you can place your cursor on any of these fields and press PF1 to get a detailed help explanation of what they mean.

    One last note on RA.S if you have a CKFREEZE selected in SE.1 then the information above from the RACFCLAS panel will come from the CKFREEZE dataset.
    If you want live information as of right this second then unselect your CKFREEZE before going to RA.S.

    Hope that helps,
    Joel
  • salami
    salami
    44 Posts

    Re: Trusted Userid

    ‏2013-02-15T23:20:40Z  
    Hi again Bob,
    Replying to my own post because I hit a key on this new keyboard too soon and didn't mean to post just yet. Ugh!

    Under the "Profile residency options" section you can find out if a class is RACLISTed, if it is required to be RACLISTED, or if it is "RACLISTed by application only".

    So for CICS you should see:
    Profile residency options
    Profiles in dataspace No
    RACLIST required No
    RACLISTed by application only Yes

    Today the way zSecure works it isn't actually checking to see if profiles are in the dataspace for a class that's RACLISTED by the application only. This is not a bug but WAD in case you're wondering.

    Further you can place your cursor on any of these fields and press PF1 to get a detailed help explanation of what they mean.

    One last note on RA.S if you have a CKFREEZE selected in SE.1 then the information above from the RACFCLAS panel will come from the CKFREEZE dataset.
    If you want live information as of right this second then unselect your CKFREEZE before going to RA.S.

    Hope that helps,
    Joel
    so bottom line is when zsecure lists my cat1 and cat2 trancodes as an audit concern, it will never find my corresponding GCICSTRN profile, instead, always listing it as TCICSTRN * profile because it doesn't check raclisted classes by the application? I also see that some of the cat1 and cat2 trancodes are secured in my gcicstrn, and others I have to add, I'm not sure of this descrepancy...regards, bob
  • SystemAdmin
    SystemAdmin
    310 Posts

    Re: Trusted Userid

    ‏2013-02-15T23:30:42Z  
    • salami
    • ‏2013-02-15T23:20:40Z
    so bottom line is when zsecure lists my cat1 and cat2 trancodes as an audit concern, it will never find my corresponding GCICSTRN profile, instead, always listing it as TCICSTRN * profile because it doesn't check raclisted classes by the application? I also see that some of the cat1 and cat2 trancodes are secured in my gcicstrn, and others I have to add, I'm not sure of this descrepancy...regards, bob
    No. We got off topic about what profiles RACF caches into central storage and how it caches them. This has nothing to do with zSecure's ability to determine if a cat1, cat2, or cat3 transaction is protected.

    Member and Grouping classes are used together to secure a resource. Have you chosen to use the member class or grouping class to secure your CICS transactions? Or both? Be careful if you use both as you might create a discrepancy.

    If it says there's an audit concern then I suggest you investigate it.

    Have you secured all of your transactions? If you're finding some cat1 and cat2 in the GCICSTRN class and no where else then you have work to do to protect more cat1 and cat2 transactions.

    Hope this helps,
    Joel
  • salami
    salami
    44 Posts

    Re: Trusted Userid

    ‏2013-02-20T21:30:30Z  
    No. We got off topic about what profiles RACF caches into central storage and how it caches them. This has nothing to do with zSecure's ability to determine if a cat1, cat2, or cat3 transaction is protected.

    Member and Grouping classes are used together to secure a resource. Have you chosen to use the member class or grouping class to secure your CICS transactions? Or both? Be careful if you use both as you might create a discrepancy.

    If it says there's an audit concern then I suggest you investigate it.

    Have you secured all of your transactions? If you're finding some cat1 and cat2 in the GCICSTRN class and no where else then you have work to do to protect more cat1 and cat2 transactions.

    Hope this helps,
    Joel
    Hi Joel, we have one TCICSTRN profile (TCICSTRN *) and the rest GCICSTRN which is probably creating the descrepancy as every profile says its protected in TCICSTRN *. what I did was get the trancode of each finding and searching thru GCICSTRN to see if it exist or not. the ones not defined i plan on defining to GCICSTRN. if you see any holes to this approach plz let me know...regards, bob
  • HansSchoone
    HansSchoone
    39 Posts

    Re: Trusted Userid

    ‏2013-02-21T09:33:22Z  
    • salami
    • ‏2013-02-20T21:30:30Z
    Hi Joel, we have one TCICSTRN profile (TCICSTRN *) and the rest GCICSTRN which is probably creating the descrepancy as every profile says its protected in TCICSTRN *. what I did was get the trancode of each finding and searching thru GCICSTRN to see if it exist or not. the ones not defined i plan on defining to GCICSTRN. if you see any holes to this approach plz let me know...regards, bob
    If the CKFREEZE file you are using was made while a CICS region was active that uses the GICSTRN class then it should not have reported the GCICSTRN as being not application RACLISTed, while it reports the TCICSTRN as being application-RACLISTed.
    There is a PTF for that problem on releases prior to 1.13, but 1.13 has that in the base level. So either the information you gave on using 1.13.0 for the failing display was incorrect, or we have a hitherto unknown problem. I suggest you open a PMR if it is really 1.13.0 or apply the PTF for APAR OA34307 if it is a lower release.
  • SystemAdmin
    SystemAdmin
    310 Posts

    Re: Trusted Userid

    ‏2013-02-27T21:39:41Z  
    • salami
    • ‏2013-02-20T21:30:30Z
    Hi Joel, we have one TCICSTRN profile (TCICSTRN *) and the rest GCICSTRN which is probably creating the descrepancy as every profile says its protected in TCICSTRN *. what I did was get the trancode of each finding and searching thru GCICSTRN to see if it exist or not. the ones not defined i plan on defining to GCICSTRN. if you see any holes to this approach plz let me know...regards, bob
    Hi Bob,
    Having a TCICSTRN profile of * makes sense. Hopefully it is not a UACC of READ or ID(*) READ on the ACL. If that is the case then you have another project looming and that's to make sure all of your CICS transactions are RACF protected.

    Are you running zSecure v1.13.0 or v1.13.1?
    If so then simply use the RE.C menu option and you can type in each trancode. zSecure will tell you what profile and class protects it. So you know with absolutely certainty how it is RACF protected. No guess work. No searching through the entire GCICSTRN list to see if it is defined.

    This is one of the best improvements I've seen in v1.13.0.

    Oh by the way, zSecure v1.13.0 does tha for IMS as well. :-)

    You don't have to define everything to GCICSTRN. Just keep in mind that if you define to both RACF will merge them and you might get unexpected results or open up access to a transaction to which you don't intend.

    If you're already using GCICSTRN heavily then stick with it but again keep in mind if you put a tran code in more than one GCICSTRN profile be mindful of if the UACC is READ or NONE. If there is a collision, say you have a uacc of READ on one GCICSTRN profile and NONE on another for the same trancode then that tran will actually be UACC of READ.

    question for zSecure development
    Is there a way in zSecure RE.C or AU.S perhaps for it to alert me when I've created a situation where the RACF profile merge results in such a collision?
    I know I can simulate the merge in a sense I think recalling an answer to a previous post but wasn't sure if it will just flag it in yellow as an audit concern.

    Hope that helps,
    Joel
  • Tom.Zeehandelaar
    Tom.Zeehandelaar
    144 Posts

    Re: Trusted Userid

    ‏2013-02-28T07:44:53Z  
    Hi Bob,
    Having a TCICSTRN profile of * makes sense. Hopefully it is not a UACC of READ or ID(*) READ on the ACL. If that is the case then you have another project looming and that's to make sure all of your CICS transactions are RACF protected.

    Are you running zSecure v1.13.0 or v1.13.1?
    If so then simply use the RE.C menu option and you can type in each trancode. zSecure will tell you what profile and class protects it. So you know with absolutely certainty how it is RACF protected. No guess work. No searching through the entire GCICSTRN list to see if it is defined.

    This is one of the best improvements I've seen in v1.13.0.

    Oh by the way, zSecure v1.13.0 does tha for IMS as well. :-)

    You don't have to define everything to GCICSTRN. Just keep in mind that if you define to both RACF will merge them and you might get unexpected results or open up access to a transaction to which you don't intend.

    If you're already using GCICSTRN heavily then stick with it but again keep in mind if you put a tran code in more than one GCICSTRN profile be mindful of if the UACC is READ or NONE. If there is a collision, say you have a uacc of READ on one GCICSTRN profile and NONE on another for the same trancode then that tran will actually be UACC of READ.

    question for zSecure development
    Is there a way in zSecure RE.C or AU.S perhaps for it to alert me when I've created a situation where the RACF profile merge results in such a collision?
    I know I can simulate the merge in a sense I think recalling an answer to a previous post but wasn't sure if it will just flag it in yellow as an audit concern.

    Hope that helps,
    Joel
    Hi Joel,

    I am glad to hear that you like the new CICS and IMS transaction feature on the RE.C.T and RE.M.T panels. On these panels, you can specify a CICS or IMS transaction name and get an overview of the profile or profiles in which classes are involved with the protection of the pertinent transaction.
    I agree with you that this feature is a great enhancement. Specifically if on your system both member (e.g. TCICSTRN) and grouping (e.g. GCICSTRN) class profiles are used to secure the same CICS transaction.
    However, according to me, the standard RACF RACLIST process does not merge profiles with UACC(NONE) and UACC(READ) resulting in a UACC(READ). As far as I know, by default, the RACLIST process always takes the lowest UACC value when merging profiles with different UACC values.
    Your scenario, however, does apply to ACL entries. If one of the profiles contains READ for GRPA and another protecting profile contains ALTER for GRPA, the merge result is GRPA with access ALTER for the pertinent CICS transaction.

    I hope that this explanation clarifies your question.
    Best regards, Tom Zeehandelaar
  • salami
    salami
    44 Posts

    Re: Trusted Userid

    ‏2013-03-22T03:04:22Z  
    Hi Bob,

    so this setting means that your GCICSTRN profiles are not RACLISTed and, therefore, ignored.
    You must change this settings for the GCICSTRN class, so that the GCICSTRN profiles are also RACLISTED. If you have defined the appropriate GCICSTRN profiles, this action should mitigate the risk that is reported by the audit concern.

    To see the effect of this change in your "audit concern overview", you must first refresh the CKFREEZE data set that you are using to process the audit concern overview. The audit concern for user ???????? that can use the CICS Category 1 and 2 trancodes must now have disappeared.

    BTW the user ???????? does not refer to a started task with the trusted attribute. Within the context of zSecure Audit, a trusted user is a user with (at least) one UPDATE access to a resource that is part of the TCB (Trusted Computing Base). This access allows the pertinent user to change certain (sub)system settings, or bypass RACF access verification. In this case, the user ???????? can use CICS OPERATOR transactions and CICS transactions that should only be used by CICS Region IDs.

    User ???????? refers to the "Default uid remote NJEUSERID", that is set in your SETROPTS. This userid is assigned to all remote users that access your JES environment with NJE (Network Job Entry) or RJE (Remote Job Entry) and do not have a userid defined in the local RACF database. You can review and, optionally, change the default NJEUSERID in RA.S.

    So what this audit concern tries to explain is that all remote NJE and RJE users can use CICS OPERATOR commands. This is probably not intentional.

    I hope this helps.
    Best regards, Tom Zeehandelaar
    Hi Tom, still a little vague on the ???????? njeuserid. I see this coded in my setr: USER-ID FOR JES NJEUSERID IS : ????????. when running my AU.S.RACF resource, many of my audit concerns is directed to the ????????, which it refers to as a "trusted userid", which to me bypasses RACF? how/where does it get its "trusted" authority?

    regards, bob
    Trusted user
    Trusted userid ????????
    Privilege on user's complex UACC
    Id associated with privilege
    Access level granted to user READ
  • Tom.Zeehandelaar
    Tom.Zeehandelaar
    144 Posts

    Re: Trusted Userid

    ‏2013-03-25T08:57:41Z  
    • salami
    • ‏2013-03-22T03:04:22Z
    Hi Tom, still a little vague on the ???????? njeuserid. I see this coded in my setr: USER-ID FOR JES NJEUSERID IS : ????????. when running my AU.S.RACF resource, many of my audit concerns is directed to the ????????, which it refers to as a "trusted userid", which to me bypasses RACF? how/where does it get its "trusted" authority?

    regards, bob
    Trusted user
    Trusted userid ????????
    Privilege on user's complex UACC
    Id associated with privilege
    Access level granted to user READ
    Hi Bob,

    OK, let my try to explain.
    In fact, the part of the to report that you pasted in your response, already contains the answer to your question.
    The report description Privilege on user's complex states UACC. This means that, in this case, user ID ???????? receives the access that is considered to be trusted via the UACC on the pertinent resource.
    The description Access level granted to user shows access level READ. This description means that this access READ is applicable to a resource profile where having READ access is considered to be a trusted access. For example, if the UACC access level on FACILITY class profile BPX.SUPERUSER is set to READ then anybody can switch to SUPERUSER in the UNIX System Services environment. If a user can switch to SUPERUSER mode, they can almost do anything in the USS environment. Therefore, zSecure Audit reports the pertinent user ID as a trusted user.

    Because you cannot permit to user ID ????????, the trusted access that is reported in your system for this user ID is always based on some kind of general access that is defined. For example, access via UACC, WARNING mode, Global Access Checking Table, or access because a resource that is part of the TCB (Trusted Computing Base) is not protected by a RACF resource profile at all. This is also the reason why, typically, the audit concern priority exceeds 30. This audit concern priority indicates that this access is considered to be a security exposure. Probably, your system must not report any trusted access to the user IDs ????????? or * (which indicates that trusted access is permitted to ID *).

    Hope this helps.
    Best regards, Tom Zeehandelaar
  • salami
    salami
    44 Posts

    Re: Trusted Userid

    ‏2013-03-26T18:52:23Z  
    Hi Bob,

    OK, let my try to explain.
    In fact, the part of the to report that you pasted in your response, already contains the answer to your question.
    The report description Privilege on user's complex states UACC. This means that, in this case, user ID ???????? receives the access that is considered to be trusted via the UACC on the pertinent resource.
    The description Access level granted to user shows access level READ. This description means that this access READ is applicable to a resource profile where having READ access is considered to be a trusted access. For example, if the UACC access level on FACILITY class profile BPX.SUPERUSER is set to READ then anybody can switch to SUPERUSER in the UNIX System Services environment. If a user can switch to SUPERUSER mode, they can almost do anything in the USS environment. Therefore, zSecure Audit reports the pertinent user ID as a trusted user.

    Because you cannot permit to user ID ????????, the trusted access that is reported in your system for this user ID is always based on some kind of general access that is defined. For example, access via UACC, WARNING mode, Global Access Checking Table, or access because a resource that is part of the TCB (Trusted Computing Base) is not protected by a RACF resource profile at all. This is also the reason why, typically, the audit concern priority exceeds 30. This audit concern priority indicates that this access is considered to be a security exposure. Probably, your system must not report any trusted access to the user IDs ????????? or * (which indicates that trusted access is permitted to ID *).

    Hope this helps.
    Best regards, Tom Zeehandelaar
    Hi Tom, I really appreciate your time and patience on this. As for ???????, it shows up as an audit concern for my cics category 1 and 2 trancodes via the TCICSTRN * UACC/READ profile. My understanding is access is determined by "closest fit" profile, which would be my GCICSTRN UACC/NONE profiles, except for ????????, which uses UACC, WARN, GLOBAL, etc, thus its flagged as an audit comment? We are in the midst of modifying our TCICSTRN * to UACC/NONE which as you know calls for a lot of upfront work. I'm going to close this as "pending TCICSTRN UACC/NONE" conversion. Let me know if I'm wrong on this.

    regards, bob
  • Tom.Zeehandelaar
    Tom.Zeehandelaar
    144 Posts

    Re: Trusted Userid

    ‏2013-03-27T07:54:36Z  
    • salami
    • ‏2013-03-26T18:52:23Z
    Hi Tom, I really appreciate your time and patience on this. As for ???????, it shows up as an audit concern for my cics category 1 and 2 trancodes via the TCICSTRN * UACC/READ profile. My understanding is access is determined by "closest fit" profile, which would be my GCICSTRN UACC/NONE profiles, except for ????????, which uses UACC, WARN, GLOBAL, etc, thus its flagged as an audit comment? We are in the midst of modifying our TCICSTRN * to UACC/NONE which as you know calls for a lot of upfront work. I'm going to close this as "pending TCICSTRN UACC/NONE" conversion. Let me know if I'm wrong on this.

    regards, bob
    Hi Bob,

    from what you describe, I conclude that zSecure Audit has discovered that one or more of the category 1 and 2 CICS transactions are not properly protected by a fitting GCICSTRN or TCICSTRN profile with a UACC of NONE. This implementation means that everybody with access to your JES environment can potentially execute the pertinent CICS category 1 or 2 transaction(s). These type of CICS transactions are not meant to be used by all users, and some of them might allow bypassing security measures.

    Indeed this risk is fixed by adjusting the UACC from READ to NONE on the TCICSTRN profile *. But it also means that until you finish this upfront work that you mention, this risk can be exploited by anyone with access to your company's JES environment.

    If this was my system, I would not wait for this to happen. My solution would be to build appropriate GCICSTRN or TCICSTRN profiles for the category 1 and 2 profiles that this risk pertains to, with UACC NONE. On the ACL of these profiles, you must only permit the applicable CICS Region user IDs and other user IDs (or preferably groups) that need to execute the pertinent CICS transactions as part of their job role. For example, CICS administrators, CICS operators, or CICS developers.

    Best regards, Tom Zeehandelaar
  • salami
    salami
    44 Posts

    Re: Trusted Userid

    ‏2013-03-27T18:44:10Z  
    Hi Bob,

    from what you describe, I conclude that zSecure Audit has discovered that one or more of the category 1 and 2 CICS transactions are not properly protected by a fitting GCICSTRN or TCICSTRN profile with a UACC of NONE. This implementation means that everybody with access to your JES environment can potentially execute the pertinent CICS category 1 or 2 transaction(s). These type of CICS transactions are not meant to be used by all users, and some of them might allow bypassing security measures.

    Indeed this risk is fixed by adjusting the UACC from READ to NONE on the TCICSTRN profile *. But it also means that until you finish this upfront work that you mention, this risk can be exploited by anyone with access to your company's JES environment.

    If this was my system, I would not wait for this to happen. My solution would be to build appropriate GCICSTRN or TCICSTRN profiles for the category 1 and 2 profiles that this risk pertains to, with UACC NONE. On the ACL of these profiles, you must only permit the applicable CICS Region user IDs and other user IDs (or preferably groups) that need to execute the pertinent CICS transactions as part of their job role. For example, CICS administrators, CICS operators, or CICS developers.

    Best regards, Tom Zeehandelaar
    Hi Tom, appreciate your patience on this. I tested one of the cat1 trancodes CDBF and the corresponding ICH408 msg shows its being secured in GCICSTRN under CICSGNR*.CDBF member, whch proves its not hitting my TCICSTRN * backstop, which is what zSecure reports as using. So this tells me my cat1 and 2's are secured in lieu of what zsecure says...somehow zSecure is not resolving my TCICSTRN and GCICSTRN profiles.

    regards, bob

    ICH408I USER(DFLTGNRT) GROUP(TESTDFLT) NAME(CICSGNRT DEFAULT UID) 499
    CICSGNRT.CDBF CL(TCICSTRN)
    INSUFFICIENT ACCESS AUTHORITY
    FROM CICSGNR*.CDBF (G)
    ACCESS INTENT(READ ) ACCESS ALLOWED(NONE )
  • Tom.Zeehandelaar
    Tom.Zeehandelaar
    144 Posts

    Re: Trusted Userid

    ‏2013-03-29T08:49:28Z  
    • salami
    • ‏2013-03-27T18:44:10Z
    Hi Tom, appreciate your patience on this. I tested one of the cat1 trancodes CDBF and the corresponding ICH408 msg shows its being secured in GCICSTRN under CICSGNR*.CDBF member, whch proves its not hitting my TCICSTRN * backstop, which is what zSecure reports as using. So this tells me my cat1 and 2's are secured in lieu of what zsecure says...somehow zSecure is not resolving my TCICSTRN and GCICSTRN profiles.

    regards, bob

    ICH408I USER(DFLTGNRT) GROUP(TESTDFLT) NAME(CICSGNRT DEFAULT UID) 499
    CICSGNRT.CDBF CL(TCICSTRN)
    INSUFFICIENT ACCESS AUTHORITY
    FROM CICSGNR*.CDBF (G)
    ACCESS INTENT(READ ) ACCESS ALLOWED(NONE )
    Hi Bob,

    according to what the zSecure Audit Trusted userids report states, this ICH408I response is an unexpected answer to get from RACF when you attempt to execute the CICS transaction CDBF. It seems that, for whatever reason, zSecure Audit does not detect that the CDBF transaction (and possibly other CICS category 1 and 2 transactions) is protected by an, in this case, GCICSTRN profile.

    There can be multiple causes for this mismatch. With the current information that you provided so far, it is impossible for me to further diagnose this issue.
    Further investigation of this issue probably requires that you provide us with more detailed information about your company's system. I do not think that this forum is the correct environment for further trouble shooting.
    I suggest that you open a PMR for this issue with our zSecure Support Team.

    Best regards,

    Tom Zeehandelaar
  • salami
    salami
    44 Posts

    Re: Trusted Userid

    ‏2013-03-29T17:24:49Z  
    Hi Bob,

    according to what the zSecure Audit Trusted userids report states, this ICH408I response is an unexpected answer to get from RACF when you attempt to execute the CICS transaction CDBF. It seems that, for whatever reason, zSecure Audit does not detect that the CDBF transaction (and possibly other CICS category 1 and 2 transactions) is protected by an, in this case, GCICSTRN profile.

    There can be multiple causes for this mismatch. With the current information that you provided so far, it is impossible for me to further diagnose this issue.
    Further investigation of this issue probably requires that you provide us with more detailed information about your company's system. I do not think that this forum is the correct environment for further trouble shooting.
    I suggest that you open a PMR for this issue with our zSecure Support Team.

    Best regards,

    Tom Zeehandelaar
    Tom, will do. I appreciate your time! bob
  • ChrisCorrin
    ChrisCorrin
    3 Posts

    Re: Trusted Userid

    ‏2013-10-18T15:30:42Z  

    Hi ,

    I was wondering if there is a solution to this issue as we are seeing the same problem with the Audit concerns report identifying multiple CAT1 and CAT2 level 41 issues which the related GCICSTRN member profiles are protecting , as proved by viewing the  RE.C.T transaction detail and checking Access monitor records to find the profile used for the access.

    Chris Corrin

    .

  • salami
    salami
    44 Posts

    Re: Trusted Userid

    ‏2013-10-18T20:25:26Z  

    Hi ,

    I was wondering if there is a solution to this issue as we are seeing the same problem with the Audit concerns report identifying multiple CAT1 and CAT2 level 41 issues which the related GCICSTRN member profiles are protecting , as proved by viewing the  RE.C.T transaction detail and checking Access monitor records to find the profile used for the access.

    Chris Corrin

    .

    Hi Chris, i was able to resolve my working to modify my lone TCICSTRN * from UACC/READ to UACC/NONE.   it took some up front work to do this, but eliminated 100+ zSecure audit concerns.    do you also have a TCICSTRN * UACC/READ?    i did report this to IBM but they could not recreate my problem.

    regards, bob