I think the first thing to understand is that there are two levels of output when we talk about STANDARDs. There is the final output as in the report output you get, which comes from the COMPLIANCE* report types. This is the result from doing the comparisons/checks specified in the controls of your standard, that a certain something has a certain value, or exists, etc. The compliance controls specify these checks in terms of underlying basic report types, of which there are more than a hundred, RACF_ACCESS being one of them. When you read about the output from RACF_ACCESS, that does not refer to the final output, but to the "virtual database table" that is the result of applying what we can call the "RACF_ACCESS function", if you like, to the relevant input files.
As Tom pointed out, the "explosion" that the documentation talks about here, is trying to convey that there will be separate "database table rows" to report on the various permits etc. in the RACF database, as opposed to talking about the values of a repeated ACL field contained within a single record. And this is therefore an explosion on the level of the _input_ to the "COMPLIANCE function". (And I am going to assume that at this level, the SIMULATE works as it should; which I think is unrelated to what you are really looking for here.)
Furthermore, it is my understanding that the STIG has been written to verify access on the user ID level. If you put in a group on the allowlist, then that will be recognized as a valid ID by the way the process is implemented, too, but then you probably additionally need to have a process in place to assure that no user IDs ever get added to those groups that should not have the kind of access being checked--there are no compliance controls in the standard for that. There is no support for doing an explosion of the groups on the allowlist to the user ids connected to them.
Regards,
Original Message:
Sent: Wed January 24, 2024 01:50 PM
From: Michael Nielsen
Subject: How fieldnames function in carla STANDARD command TEST statements
Thanks Jeroen. I also reviewed the indirect reference/lookup section of the manual. I won't be offering to teach anyone about it, but I believe I get the general concepts behind it now.
I am now trying to tell the racf_access() function (is 'function' the correct term here?) to explode groups. The carla command manual v2.5.0 explains SIMULATE RACF_ACCESS paired with a NEWLIST TYPE=RACF_ACCESS accomplishes this on pate 928.
If you use the RACF_ACCESS NEWLIST in combination with the SIMULATE_RACF_ACCESS option, the
report provides information on the permits and connects allowed based on the RACF database profile
definitions. The output is an exploded view of all permits and connects defined in the RACF database,
including the effect of RACLIST merge processing.
I tried inserting a SIMULATE RACF_ACCESS command before the IMBED MEMBER= command that invokes CKAGCI10 and ran the job. It completed successfully but did not explode the groups (meaning the report still listed groups which it determined compliant/non-compliant).
Is it possible to force the racf_access() function to explode groups so that the comparisons for the STIG check are done specifically by userid? (Assume in this scenario any groups in the config files are already being exploded)
------------------------------
Michael Nielsen
Original Message:
Sent: Tue January 23, 2024 04:07 PM
From: Jeroen Tiggelman
Subject: How fieldnames function in carla STANDARD command TEST statements
Hi Michael,
Indeed you should look at the lookup documentation for the syntax.
Line 85 says: take the ID value from the RACF_ACCESS record, then find this value in the TYPE=ID newlist in the field ID, and then look aside on that "row" (record in the NEWLIST, interpreting the NEWLIST type as providing a virtual database table) to ID_STC_SUBSYS_TYPE and see if that contains the value CICS.
Line 89 says to take the same ID value, and then lookup to the DEFTYPE newlist type POPULATE_STIG_CICBAUDT and try to find the value in the field ID... and then "look aside" to ID and check that that value exists.... that is to say, check if the ID occurs in that configuration member.
The configuration newlist type is defined in C2RH@DEF, like this:
VIEW CRMA.D.GKR310.$TEST.SCKRCARL(C2RH@DEF) - 01.02 Columns 00001 00072
Command ===> ________________________________________________ Scroll ===> CSR
000324 deftype type=POPULATE_STIG_CICBAUDT nowarn col1com='*'
000325 alloc type=POPULATE_STIG_CICBAUDT dd=CKA@CUST(CICBAUDT)
000326 define type=POPULATE_STIG_CICBAUDT id as substr(record,1,8)
So the IDs are simply whatever is in the first 8 characters of a line in the configuration member, unless the line starts with '*'.
Regards,
------------------------------
Jeroen Tiggelman
IBM - Software Development Manager IBM Security zSecure Suite
Delft
Original Message:
Sent: Tue January 23, 2024 11:37 AM
From: Michael Nielsen
Subject: How fieldnames function in carla STANDARD command TEST statements
I am working with the zSecure Audit compliance features for zos_stig (v8) and trying to understand how the underlying CARLa is comparing IDs entered into the appropriate config file(s) with IDs listed on resource profile(s) access list.
I think a relevant piece of this puzzle is the use of racf_access() statements in the TEST field.
For example, SCKRCARL(CKAGCI10) has these (fieldname reloper complaintvalue) on lines 85 and 89.
000084 TEST 3.uca_access_cics,
000085 racf_access(id:id.id.id_stc_subsys_type=CICS),
000086 DESC("User ID is a CICS STC; UPDATE and higher access allowed."),
000087 OTHERWISE(,
000088 TEST 3.uca_access_cicb,
000089 racf_access(id:populate_stig_cicbaudt.id.id<>" "),
000090 DESC("User ID is a CICS batch program; UPDATE and higher access allo
000091 wed."),
000092 OTHERWISE(,
RACF_ACCESS is a NEWLIST TYPE= value. I'm inferring that this is generating a type=racf_access report to obtain the relevant access list(s).
But what is the difference between the placement of the 'id' statements in
id:id.id.id_stc_subsys_type
and
id:populate_stig_cicbaudt.id.id ?
The CARLAa command reference manual v2.5.0 discusses syntax for the TEST statement under the STANDARD command syntax. Unfortunately it doesn't detail acceptable inputs for the (fieldname reloper complaintvalue) statements. Are the 'id' statements indirect lookups? How is the CARLa interpreting lines 85 and 89?
------------------------------
Michael Nielsen
------------------------------