Sle16 base control

[teacup-on-rockingchair]

Description:

• Add SUSE SLE 16 platform

Rationale:

• Add SUSE SLE 16 platform to build procedure
• Add initial base profile for SLE16 platform
• Add skeleton implementation for PCI-DSS and ANSSI minimal profiles for SLES16

[openshift-ci]

Skipping CI for Draft Pull Request.
If you want CI signal for your change, please convert it to an actual PR.
You can still manually trigger a test run with /test all

[svet-se]

Looks good to me! The base control file will bring a lot of benefits, because the code will be DRY, which will improve the maintenance. IMHO, it will be great if this approach is accepted by the community.

[Mab879]

Looks good to me! The base control file will bring a lot of benefits, because the code will be DRY, which will improve the maintenance. IMHO, it will be great if this approach is accepted by the community.

Can you please explain these benefits so I better understand this PR?

Why not use the existing ANSSI and PCI controls?

[svet-se]

Looks good to me! The base control file will bring a lot of benefits, because the code will be DRY, which will improve the maintenance. IMHO, it will be great if this approach is accepted by the community.

Can you please explain these benefits so I better understand this PR?

Why not use the existing ANSSI and PCI controls?

The idea of using one product-based control file at some point is that you will not repeat some of the rules in all control files. For example, if you would like to change or remove some of the rules that are repeated in all control files, you should delete them everywhere; the second approach is to delete them from one place. IMHO, there will be challenges with the specific control IDs and titles. The second approach may be to use the control files for reference, but each product has its own base control file; in this way, if a specific product's rules are added, they should not be excluded from all other profiles. The idea is to keep the profile files clean from exclusions (which are also repeated)

[teacup-on-rockingchair]

Looks good to me! The base control file will bring a lot of benefits, because the code will be DRY, which will improve the maintenance. IMHO, it will be great if this approach is accepted by the community.

Can you please explain these benefits so I better understand this PR?

Why not use the existing ANSSI and PCI controls?

One thing that is obvious and left out of previous explanation is, that we are using the levels as selectors for the different standards requirements like PCIDSS, ANSSI etc. Hopefully having all the rules relevant for a platform would make also more visible cases of rules duplication, like having two or more rules performing the same thing but developed for different standards, and will push us to droping more duplicated rules/code.

[Mab879]

Can you please split this PR into two PRs? One for the new product, one for the new control file. I don't want hold up the new product based on the control file.

While new control file is an interesting idea. I have few questions and reservations about it.

[teacup-on-rockingchair]

Just created PR #14010 to extract the platform out of this PR. As soon as we have closed all unclear points here, will rebase it so it will have no conflicts.

[teacup-on-rockingchair]

Can you please split this PR into two PRs? One for the new product, one for the new control file. I don't want hold up the new product based on the control file.

While new control file is an interesting idea. I have few questions and reservations about it.

Hey @Mab879 can you share your concerns if still there are any. If none remained, let's move forward the PR.

[Mab879]

Yes, still I have a few concerns. Sorry for the late reply. While I do see some benefits that you mentioned I do have some comments listed below.

1. You will be losing auto rule references, for profiles like ANSSI. Currently, you cannot fix both in rules.yml references the automatic references.
2. Losing the connection to the policy. For example, SLES-16-16016025 does not have any reference back what part of ANSSI requires this.
3. The stated goal of controls file (better called a Policy file) is to follow a policy.
4. At least to me, this feels like an abuse of the current form of control files
5. You will be Losing access to shared updates on profiles like ANSSI.

I see the benefit of reducing duplication of a type of control (passwords must be X chars long) however, I do not think this out weights the above.

There might be other changes we can make to address your concerns.

[svet-se]

Yes, still I have a few concerns. Sorry for the late reply. While I do see some benefits that you mentioned I do have some comments listed below.

1. You will be losing auto rule references, for profiles like ANSSI. Currently, you cannot fix both in rules.yml references the automatic references.
2. Losing the connection to the policy. For example, SLES-16-16016025 does not have any reference back what part of ANSSI requires this.
3. The stated goal of controls file (better called a Policy file) is to follow a policy.
4. At least to me, this feels like an abuse of the current form of control files
5. You will be Losing access to shared updates on profiles like ANSSI.

I see the benefit of reducing duplication of a type of control (passwords must be X chars long) however, I do not think this out weights the above.

There might be other changes we can make to address your concerns.

If you build the product using the base control file approach and run eval with the ANSSI profile, for example, you can group rules by ANSSI and see the reference IDs
The other approach, not to have the SLES-16-16016025 ids, is to be able to add different profile ids as a subset of the control file ids (maybe this will require reviewing the build process), for example:

• id:
  • anssi: R1
  • stig: ...
    IF we have a common (base) control file for all vendors, with references could provide us with shared updates.
    The main target will be to make the code DRY and to stop adding or removing rules from the profile files (it does not relate these rules to a particular control). Another approach is to continue with this copy/paste approach and to create different control files per product, such as stig and cis, but this will increase more ot less the "spaghetti" code.
    Maybe it will be good to discuss the architecture and design of the CaC, and how to proceed further.

[teacup-on-rockingchair]

Yes, still I have a few concerns. Sorry for the late reply. While I do see some benefits that you mentioned I do have some comments listed below.

1. You will be losing auto rule references, for profiles like ANSSI. Currently, you cannot fix both in rules.yml references the automatic references.
2. Losing the connection to the policy. For example, SLES-16-16016025 does not have any reference back what part of ANSSI requires this.
3. The stated goal of controls file (better called a Policy file) is to follow a policy.
4. At least to me, this feels like an abuse of the current form of control files
5. You will be Losing access to shared updates on profiles like ANSSI.

I see the benefit of reducing duplication of a type of control (passwords must be X chars long) however, I do not think this out weights the above.

There might be other changes we can make to address your concerns.

I think main benefit is that platform developer controls via the base policy control file, which rules are relevant for the platform and will not force new rule developers to go and check it for each platform, rather stimulate platform teams to enhance/test existing rules if and when needed to adapt them for the relevant platform, rather than forcing people to either find a way to test rules on all possible platforms or exclude them from all possible platforms. The first down significantly may slow down developement, that is why we more often encounter the second approach which creates unneeded coupling and may slow down integration due to review process policy.

From my point of view on references, we still keep the reference ids per rule, and if we build a profile named ANSSI, using level anssi from the base control we will still keep the anssi id reference ids and since those contain href links the end user can check each rule ANSSI's motivation and description. Currently this problem is to some extend solvable if one hase base control with all rules for targeted platform say base_sle16, platform-specific policy control file like the ones we have now say anssi_sle, which for the relevant policy charters include the base_sle16 clauses, for example:

id: base_sle16

controls:
    - id: SLES-16-16016015
      levels:
          - anssi
          - stig
      title: SLES 16 must provide remote logging.
      rules:
          - rsyslog_remote_loghost
...

The platform specific policy control file looks like:

id: anssi_sle16
...
controls:
...
 - id: R71
      title: Implement a logging system
      controls:
          - base_sle16:SLES-16-16016015
          ...

but this require too much duplication of text description etc for each platform we will have all the policy control files. So we skipped the middle phase and decided that for now reference ids will be enough. And in future through improvements in the CaC framework or/and the openscap toolset to make it possible that we have in the control file either per level titles,notes, and thus eliminate any need for duplication and remain in control of what gets compiled for a platform.

I agree that the suggested usage of the policy control files does not match the current idea, but from my point of view policy control file's role is still work in progress, and we can see that even now we have for example separate CIS policy control for each platform, while we are trying to make a solution that will minimize code/text duplication and make it simpler to create and control polic development for each platform. Also it is very tempting to have the control files cover all the requirements of the policy in question, but our observation is that end the functionality of checks and remediations and even the policy specifications sometimes become more and more platform specific.

So we came to the conclusion that we might use the nice abstract functionality that the control files provide in order to revert the approach, and instead of starting by including all the rules for a new platform and catch up with possibly hundreds of failures for the new platform, gradually to include in the new platform all the rules that we verify are working and gradually to provide only working functionality, even if we partially cover one or another security policy specification.

[vojtapolasek]

Hello,
I must say that the idea is interesting, but at the same time I am not a big fan of it.
I understand that it decreases code duplication, but I think that this is actually true only at the begining.
My understanding is that you basically want to create one large control file which will contain all rules for your platform. Rules will be somehow tagged so that you could find out quickly to which security policies they belong. And also they would be selected in actual products/sle16/profiles/*.profile files by those tags.
Please correct me if I am wrong.
If my understanding is correct, I think that this will start falling apart as policies will be gradually updated by respective authorities. Requirements can start diverging, you might be forced to create more controls / rules, and everything will be placed in one huge file.
I think this is not a good approach, especially if you want some SME to review the policy.
Consider this please.

[svet-se]

Hey folks,

I understand your absolutely valid concerns, because I have the same.

The possible working solution could be to have the following:

1. A reference control file for every profile, for example, pcidss_4.xml, and it will contain all controls with ID, title, and status, but it will not contain any CaC rule.
2. A base control file for every product - for example, base_rhel10.yml. It will contain all the rules tagged by a profile, as the current example proposed by us. (yes, it could become a little larger, but we will have all product rules only in one place)
3. Every rule to have references (as it is now), for example: pcidss: Req-8.2.3.

When we build the product, the leading factor will be the reference control file, after that, the rules tagged in the product control file, and finally, to see in the openscap report the full profile references by controls and rules. Also, it will be great if we are able to see all controls and rules, even if their status is pending or manual.

What will be typical add/update/delete workflows? The most important will be the leading reference control file for every profile.

1. To add a new control, we should add it to the reference control file, then add the corresponding rules to the product base control file, and finally add a reference to a particular rule.
2. To update a control - it will follow the logic of 1. (Depending on the update, we will update the corresponding control files or rules)
3. To delete a control, it will be enough to delete the control from the reference control file.

In this way, our profiles will include only a control file. It will not be necessary to remove or add rules for a specific product in the profile files. Also, at the moment is not clear the relation between the removed rules and the profile controls.

The SME should be able to check/review the logic from the reference control files and the OpenSCAP reports.

Could you please let me know if the above makes sense to you?

Have a nice day!

[teacup-on-rockingchair]

Hello, I must say that the idea is interesting, but at the same time I am not a big fan of it. I understand that it decreases code duplication, but I think that this is actually true only at the begining. My understanding is that you basically want to create one large control file which will contain all rules for your platform. Rules will be somehow tagged so that you could find out quickly to which security policies they belong. And also they would be selected in actual products/sle16/profiles/*.profile files by those tags. Please correct me if I am wrong. If my understanding is correct, I think that this will start falling apart as policies will be gradually updated by respective authorities. Requirements can start diverging, you might be forced to create more controls / rules, and everything will be placed in one huge file. I think this is not a good approach, especially if you want some SME to review the policy. Consider this please.

Hi @vojtapolasek I think you concern about file getting huge is relevant and important. I agree that we should be careful about that indeed, but this is one of the reasons we decided to use the control file. Its design is so flexible we can use a directory instead of file and have the specification broken in sections, this way we can even break in levels(meaning policy controls) or by internal logic sections say users/software/services/audit/logging etc. Thus we can address both maintainability and readability.

Bottomline, I think we have huge potential in the control file that we can unfold if we start moving in new direction, be it in this PR or in futurre developments.

[vojtapolasek]

Thank you for your responses. I see that there is certain potential in usage of control files and that there is a space for improvements regarding their flexibility.
I suggest that we:

1. implement suggestion offered in Moving Product Specific Controls #14036 ; this should allow more place for experimentation
2. Consider implementing a feature which would allow a control file to include other control files. This can avoid handling of large control files, splitting them into smaller chunks.

Also note that I am very strongly against one point mentioned above, and that is defining references at rule.yaml level while using control files at the same time.
Trust me, we found out that this is very hard to maintain and actually this was one of reason for coming up with control files.
What do others think? @ggbecker @jan-cerny @Mab879

[svet-se]

Thank you for your responses. I see that there is certain potential in usage of control files and that there is a space for improvements regarding their flexibility. I suggest that we:

1. implement suggestion offered in Moving Product Specific Controls #14036 ; this should allow more place for experimentation
2. Consider implementing a feature which would allow a control file to include other control files. This can avoid handling of large control files, splitting them into smaller chunks.

Also note that I am very strongly against one point mentioned above, and that is defining references at rule.yaml level while using control files at the same time. Trust me, we found out that this is very hard to maintain and actually this was one of reason for coming up with control files. What do others think? @ggbecker @jan-cerny @Mab879

Hey @vojtapolasek ,
I agree with your points. IMHO, if we do not want to keep the references in the rules we may include and map them into the reference and base control files (better).
But let's go in the direction of being explicit rather than implicit, because, for example some of the rules are excluded twice in https://github.com/ComplianceAsCode/content/blob/master/products/rhel10/profiles/hipaa.profile

• '!package_ypbind_removed'
• '!package_xinetd_removed'

[openshift-ci]

@teacup-on-rockingchair: The following test failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name	Commit	Details	Required	Rerun command
ci/prow/e2e-aws-openshift-node-compliance	02c73ed	link	true	/test e2e-aws-openshift-node-compliance

Full PR test history. Your PR dashboard.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. I understand the commands that are listed here.