IBM Security Z Security

 View Only

  • 1.  zSecure Trusted Report

    Posted Fri October 16, 2020 06:27 AM
    Hi there,
    My Query is about the zSecure Trusted report and the reported var of Audit Priority.

    The Report is generating values of 1 to 10, 10 being the highest.
    1. How are these Values calculated ?
        It would seem that the RACF Attributes are used (Systems Special GSpecial etc ) and also
    the access to Sensitive Data set resources (APF/LINK Libraries) and general RACF permission authorities 
    to all resources in all RACF Classes ?
    2. Are these values generated as part of the Shipment of zSecure as Default values ?
    3  I am thinking of using Priority values of >= 5 as the definitive list of zOS Privi UserIds.
    Is this a reliable method in that this would contain UserIds with Higher RACF Attributes and/or 
    elevated privilege to all Classes / Resources known to RACF ?
    4. Is there any Documentation on these values, in that there dies not seem to be any in the zSecure reference manuals,
    and 'mixed data' from Google (or Yahoo :-)). 
    5. Can these values be adjusted by a User, as there may be audit implications if that is the case.

    Need to establish a definitive list of Privileged UserIds as 'targets' for a PAM solution.
    There is a bit of a debate going on as to whether to use a partially implemented RBAC structure (Role based),
    or the zSecure Trusted report(s) as the definitive method. 
    Grateful for your answer(s)
    Peter


     




    ------------------------------
    peter leaper
    ------------------------------


  • 2.  RE: zSecure Trusted Report

    Posted Fri October 16, 2020 07:25 AM
    Hi Peter,

    As to your query about the TRUSTED report type, I will observe that the AUDITPRIORITY fields across the various report types try to use the same "scale" of priorities. For this particular report type we only document in the CARLa Command Reference: "Contains the audit priority that measures the risk the privilege poses. The value is 40 or higher if the privilege is a major exposure. For example, the user ID value represents some default user anybody can use."

    [Possibly your query was meant more specifically about the report selection called TRUSTED in AU.S RACF user. This is one way of summarizing the generated trust relations.]

    If you press PF1 on the column for context sensitive field help, you should see:

    This numerical field indicates the relative audit priority. Higher values
    indicate a higher relative audit priority. Across all NEWLIST types, the
    value of the audit priority has the following meaning:

    40 and up Immediate attention required; system security can be
              circumvented easily.
    20 to 39  Review is required; serious security threats may exist.
    10 to 19  Worthy of attention, should time permit.
    1 to 9    Informational warnings.
    0         No audit concerns identified.

    It is definitely possible to get values higher than 10 (and indeed, higher than 40).

    In some report types, there will be a particular priority for a concern, and if there are multiple concerns, then the priority might be a simple addition of the separate priorities. In other cases, there might be multiple priorities for a concern depending on additional factors. As an example, in the CLASS report type the priorities might be reduced for a class that is not currently active. In some report types the concerns are rather assigned to a band, so that the occurrence of multiple lower ranking concerns does not do a simple addition, so that, say, the occurrence of a lot of priority 5s does not constitute a priority 25, but gets bounded to a maximum of 10 together or something like that. Besides the "zSecure default" policy, you can also instruct the program to follow a particular "Audit policy", meaning that if a setting does not comply with, say, the "C2" protection profile mandates, you will get at least a priority of 40 on account of noncompliance. (There is a checkbox for this on the AU.S panel.)

    This option allows you to select the audit policy used to determine the
    audit concerns and priorities. The zSecure default policy will raise a
    concern's priority to 40 or more if the system could almost certainly be
    compromised because of it. The C1 , C2 and B1 selections refer to the DoD
    orange book standards; these will also set priorities to 40 or more when a
    violation of the selected policy is noticed. It is not implied that any
    violation will be noted. In addition, B1 will generate more audit
    concerns.

    This will result in a SIMULATE POLICY statement being added to the generated query.

    There is also a SIMULATE sub-command to add resources to sensitive resource reporting. For those you can also indicate the desired audit priority.

    To get back to your original query, we do not document explicitly which attributes in RACF [and ACF2] in combination with what other factors lead to which particular audit priority in TRUSTED; so at that level of detail I have to say that this is not an intended programming interface.

    The purpose of the audit priorities is to direct the attention of auditors to the most likely problem areas in the protection of your system. In general, you have to look into the details to ascertain exactly what is going on and if that is appropriate.

    The meaning of a user being TRUSTED is that they have--or can get--access to the Trusted Computing Base in some fashion. So arguably any user that shows up is a rather highly privileged id, regardless of the audit priority. If this report produces a very large amount of output, there might be something the matter with the general protection stance of your system. I will note that in the CARLa book, the title of the report type is "TRUSTED: Users that can bypass security".

    I do not understand enough about your real business requirement to comment on that directly. :-)

    Regards,

    --Jeroen

    P.S. Orange Book profiles might be a little dated. Besides the status audit approach embedded in AU.S, which tries to give you an overview of all vulnerabilities in your system so that you can look at the most easily exploitable ones first, another modern approach is to implement compliance with a standard. The AU.R option is designed for that. This uses compliance or noncompliance with specific defined rules directly rather than audit priorities to help you find in which areas you might not be where you want to be. If you want you can write your own compliance standard with the power of all the >100 different report types in CARLa to back it. The product also comes with some predefined standards out of the box, and capabilities to extend these with more rules or suppress some in a controlled fashion.

    ------------------------------
    Jeroen Tiggelman
    Software Development and Level 3 Support Manager IBM Security zSecure Suite
    IBM
    Delft
    ------------------------------

    Original Message


  • 3.  RE: zSecure Trusted Report

    Posted Fri October 16, 2020 07:46 AM
    Hi Peter, 

    besides the elaborate explaining of Jeroen, I would also like to point out that when you use F1, for Help, after generating the TRUSTUSR report, zSecure Audit documents the following when you pick option 2 for Audit priority from the presented helppanel:

    Sensitive data trustees - Audit priority

    The amount of work a hacker has to do before he is able to bypass security may
    vary. This is reflected in the audit priority. For 'normal' userids, this
    varies between 1 and 10.

    10 means no work needed (i.e. direct user privilege)
    9 means can copy existing program
    5-8 may involve programming of additional complexity or other factors
    2-4 means hacker really needs to work to create an exploit (e.g. write a
    program that scans for passwords or does brute force attacks)
    1 means it may be difficult to exploit, depending on additional factors

    In case exploitation is possible without authentication, the audit priorities
    are increased by 40 (NJE undefined user, UACC, warning mode). In case the
    exploitation is available to every RACF defined user, the priorities are
    increased by 39 (permit to *).

    I myself find this explanation very helpful to understand what the audit priority in the TRUSTED analysis report indicates.
    Hth

    Tom




    ------------------------------
    Tom Zeehandelaar
    z/OS Security Enablement Specialist - zSecure developer
    IBM
    Delft
    +31643351728
    ------------------------------

    Original Message


  • 4.  RE: zSecure Trusted Report

    Posted Fri October 16, 2020 09:53 AM
    Hi Tom And Jeroen, 
    Thank you for your prompt and detailed replies: 
    This information however raises my concerns in that (This is from the zSecure Trusted Report) ... that the values for the PRI field are only numbered 1-10 in the Trusted Report we generate..
    The Trusted report shows:
    10 PLEX42 134 ENF CA 90:S ENF
    10 PLEX42 136 HZS Z/OS HEALTH CHECKER
    10 PLEX42 139 TCPIP TCPIP
    These are zOS Started tasks of course that require elevated privileges to say the least, So my issue is that my assertion that we should user the zSecure
    Trusted Report as a the definitive source for identifying Human Privileged UserIds is looking decidedly shaky. There are many Human Userids who have the PRI value of 10.
    I must be interpreting something incorrectly ?  Perhaps these values have been Changed by the Client ?
    Best regards
    Peter

    ------------------------------
    peter leaper
    ------------------------------

    Original Message


  • 5.  RE: zSecure Trusted Report

    Posted Fri October 16, 2020 11:09 AM

    Hi Peter,

    To be honest, I cannot quite follow your thinking. Let me try to approach it from my side.

    The "Pri" column shows the value of the AUDITPRIORITY field in TYPE=TRUSTED. I doubt that it is possible for the client to change that.

    The CARLa Command Reference explains what the records in the report type mean in this way:
    "Each record in this NEWLIST represents a privilege that allows a specific user on a specific complex to ultimately bypass the security for z/OS and your security system software on the indicated complex and system, which can be the same system or another system."

    By a "specific user" we mean a specific user ID, not a human user necessarily.

    I assume that the report you generate is a SUMMARY that shows the highest priority for any of the privilege relations for that ID.

    That is certainly the way that the TRUSTUSR report in AU.S works.

    You can zoom in to the details to see which relations apply.

    I could see that the thing to do if you want to only provision human users would be to make a list of user IDs that are known to be started tasks and exclude them from the report.

    Regards,



    ------------------------------
    Jeroen Tiggelman
    Software Development and Level 3 Support Manager IBM Security zSecure Suite
    IBM
    Delft
    ------------------------------

    Original Message


  • 6.  RE: zSecure Trusted Report

    Posted Sun October 18, 2020 11:39 AM

    Hi Jeroen, apologies if I was not clear, realizing you must get a vast array of differing questions, not easy....
    To rewind:

    In Summary I need to identify all Privileged Human UserIds (Those with an elevated RACF Attribute (Special, Gspecial etc) and/or UserIds with Elevated permissions (e.g. Alter access to APF Libraries). The zSecure Trusted report seemed to be a reliable way of drawing up a list of such UserIds. However the PRI Fields in the generated reports are limited to ONLY 1 to 10.

    I raised the query here as to what and how exactly does zSecure make a decision to allocate a Priority Value.

    Remember,     óur´ generated Trusted Reports only have values of 1-10, '10 is High. After seeing Tomś Post (below), Something is clearly going badly wrong here as we are only seeing values 1-10, and UserIds with the RACF System Special Attribute as an example, are assigned a value of 10, which means according to the scale below, "Means no work needed". .
    From Toms reply above
    10 means no work needed (i.e. direct user privilege)
    9 means can copy existing program
    5-8 may involve programming of additional complexity or other factors
    2-4 means hacker really needs to work to create an exploit (e.g. write a
    program that scans for passwords or does brute force attacks)
    1 means it may be difficult to exploit, depending on ....

    I am an advocate of using the Trusted Report as it is relatively Easy to generate and the ´System´ makes the decision rather than a Human,

    I cannot  assert that the  zSecure Trusted Report should be used as a source to extract Privileged Human UserIds when (our) Priority Fields are reversed and restricted to 1 through 10, and  the values seem reversed to the documentation forwarded in this post .. that is In the generated Trusted Reports, 10 is high, whereas in the documentation forwarded about this query it is the reverse, 10 is low.

    Hope you can clear this up,

    Thanks

    Peter



    ------------------------------
    peter leaper
    ------------------------------

    Original Message


  • 7.  RE: zSecure Trusted Report
    Best Answer

    Posted Sun October 18, 2020 12:47 PM
    Edited by peter leaper Mon October 19, 2020 06:06 AM
    Hi Peter,

    The program looks at the user IDs in the system. It has no definitive way of knowing which IDs are for human users and which are not, so you will need to take care of that aspect separately. (If you can define in a programmatic way what qualifies a user as a human user--or the opposite--then perhaps something can be done in CARLa, but I suggest that the normal way of taking care of this is having a list of user IDs that are allowed to have a certain privilege or whatever.)

    If the highest audit priority you get out of the TRUSTED report is 10, then you appear to have a relatively well protected system. Well done.

    10 is "low" in the context of "apparent holes in your system", which is the overarching view that AU.S offers. Since it is normal that at least some user IDs have SPECIAL, it should not by itself draw a ton of attention from a first-level auditing point of view. However, of course a direct privilege is a direct privilege and you need to take care of who can use those within the organization.

    I will reiterate that I am not going to detail the algorithm that zSecure uses to assign the priorities.  A keyword in the description of the records for this newlist type is "ultimately". So there can be an indirect way by which someone can use a certain authority. For example, one step might be to use SURROGAT authority to then use the abilities of another user ID and there might be multiple indirections.

    I do not see anything like a reversal in the above and it isn't clear to me what gives you the impression there is one.

    10 is relatively high, in that it is higher than 2. Having SPECIAL is more authority than having a READ permit on the RACF database and therefore the ability to brute-force attack the passwords in the database and thereby perhaps be able to log on to a user ID with SPECIAL, to give a rough example.

    I would say that if you want to analyze which user IDs have SPECIAL, you can do a query for user IDs with SPECIAL rather than look for 10s in the output of TRUSTED. Of course, only doing one query and interpret some values as indicating that something is relevant is easier than a lot detail queries.. but it really depends on what you are eventually trying to achieve to what level of accuracy to begin to think about whether it makes sense to do so.

    Regards,

    --Jeroen

    P.S. FTR, in the compliance framework, SPECIAL is covered by STIG rule RACF0710 (member CKAGR710 in SCKRCARL).

    ------------------------------
    Jeroen Tiggelman
    Software Development and Level 3 Support Manager IBM Security zSecure Suite
    IBM
    Delft
    ------------------------------

    Original Message


  • 8.  RE: zSecure Trusted Report

    Posted Mon October 19, 2020 06:05 AM
    Many thanks Jerome, 
    That is a definitive answer, I was mistaken about the reversal, thanks for pointing this out.
    I can see that 10 is high now, in context of
    10 means no work needed (i.e. direct user privilege)
    9 means can copy existing program
    5-8 may involve programming of additional complexity or other factors
    2-4 means hacker really needs to work to create an exploit (e.g. write a
    program that scans for passwords or does brute force attacks)
    1 means it may be difficult to exploit, depending on ....

    Thanks for your time on this 
    Best regards
    Peter

    ------------------------------
    peter leaper
    ------------------------------

    Original Message