Repository navigation
Conversation
|
Skipping CI for Draft Pull Request. |
| - sl2 | ||
| - sl3 | ||
| - sl4 |
There was a problem hiding this comment.
I think that if you have the inheritance defined, you only need to set the lowest level, otherwise the inheritance becomes redundant.
In this case, defining only sl2 would be enough, since sl3 inherits from sl2 and sl3 inherits from sl4, so every three levels will select this control by inheritance
| - sl2 | |
| - sl3 | |
| - sl4 | |
| - sl2 |
I think this can be applied to the whole control file
|
In general, I believe control files with well defined sections can be broken down into multiple files for better maintenance and legibility, see how nist 800 53 is defined: https://github.com/ComplianceAsCode/content/blob/master/products/rhel8/controls/nist_800_53 and https://github.com/ComplianceAsCode/content/blob/master/products/rhel8/controls/nist_800_53.yml |
| - id: CR 1.1 RE(1) | ||
| title: Unique identification and authentication | ||
| levels: | ||
| - sl2 | ||
| - sl3 | ||
| - sl4 | ||
| status: pending | ||
| rules: [] | ||
|
|
||
| - id: CR 1.1 RE(2) | ||
| title: Multifactor authentication for all interfaces | ||
| levels: | ||
| - sl3 | ||
| - sl4 | ||
| status: pending | ||
| rules: [] |
There was a problem hiding this comment.
If these requirements are extensions of CR 1.1, I would group them under the main control for better legibility the same as done for the nist 800 53 here:
content/products/rhel8/controls/nist_800_53/ac.yml
Lines 9 to 99 in 8eb5076
So you basically create a controls key under a controls:
I won't automatically inherit/select in the profiles, you still have to manually select the extended controls. But it helps with the control legibility. This is optional though.
There was a problem hiding this comment.
The CR 1.1 RE(1) and CR 1.1 RE(2) aren't Component Requirements (CR) but they are Requirement Enhancements (RE) of the Component requirement. Now, different security levels (SL) might contain different combination of CR and RE. In this example, the document specifies the SLs this way:
5.3.4 Security levels
The requirements for the four security levels that relate to CR 1.1 are:
• SL-C(IAC,component) 1: CR 1.1
• SL-C(IAC,component) 2: CR 1.1 (1)
• SL-C(IAC,component) 3: CR 1.1 (1) (2)
• SL-C(IAC,component) 4: CR 1.1 (1) (2)
Now the question is how we we will map these two concepts (CR and RE) to our "controls" concept and how we will assign them to the security levels.
In this example, to be able to create a profile that corresponds to the security level SL 1, we need to have a control in our control file that:
- corresponds to the Component requirement CR 1.1,
- contain rules needed for implementing the CR 1.1, but at the same time
- doesn't contain rules needed for the requirement enhancements.
IIUC, if we do the nested controls in our control file as Becker proposes, we can specify different levels on the parent and child controls. That will bring more clarity to the control file. This important context from the policy document will be preserved also in our control file.
Description:
Rationale: