New sle 12/15 rule ensure_updates_are_installed

[rumch-se]

Description:

• _New SLE 12/15 rule which covers 1.9 Ensure updates, patches, and additional security software are
  installed _

Rationale:

• At the moment CIS profile for SLE 12/15 does not include this recommendation. The control cannot be automated,
  and should be addressed manually.

[openshift-ci]

Hi @rumch-se. Thanks for your PR.

I'm waiting for a ComplianceAsCode member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

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/test-infra repository.

[github-actions]

Start a new ephemeral environment with changes proposed in this pull request:

sle12 (from CTF) Environment (using Fedora as testing environment)

Fedora Testing Environment

Oracle Linux 8 Environment

[codeclimate]

Code Climate has analyzed commit c3cd477 and detected 0 issues on this pull request.

The test coverage on the diff in this pull request is 100.0% (50% is the threshold).

This pull request will bring the total coverage in the repository to 49.7% (0.0% change).

View more on Code Climate.

[marcusburghardt]

@rumch-se , I believe your can use this existing rule instead:
https://github.com/ComplianceAsCode/content/blob/master/linux_os/guide/system/software/updating/security_patches_up_to_date/rule.yml

It is for the same purpose and is more complete.

[rumch-se]

Hello @marcusburghardt
Thank you for your feedback and your proposal.
The main difference is the following - according to the rule "security_patches_up_to_date" - we have
1)automatic remediation and 2)execution of the following script for SLE - zypper patch -g security -y
In this new rule we don't have automatic remediation because we do check zypper list-updates and after we do update according to site policy.
In general updates can impact business processes in real business environment, and when we do automatic updates without validation in advance there is a risk some of business processes to be stopped. Because of that site policy can stop some of the updates and put in place some additional security controls. I saw in my practice how 1/after an update 70000 serves was impacted in an international banking institution - and the bank needed 3 days to restore all business services and 2/how TELCO operator in my country after an update to set up Television over IP - was impacted 3/4 of network infrastructure of the country (including network infrastructure of 12 banks) . - the operator needed 5 days to restore the services.
Have a nice day
Rumen

[marcusburghardt]

Hello @marcusburghardt Thank you for your feedback and your proposal. The main difference is the following - according to the rule "security_patches_up_to_date" - we have 1)automatic remediation and 2)execution of the following script for SLE - zypper patch -g security -y In this new rule we don't have automatic remediation because we do check zypper list-updates and after we do update according to site policy. In general updates can impact business processes in real business environment, and when we do automatic updates without validation in advance there is a risk some of business processes to be stopped. Because of that site policy can stop some of the updates and put in place some additional security controls. I saw in my practice how 1/after an update 70000 serves was impacted in an international banking institution - and the bank needed 3 days to restore all business services and 2/how TELCO operator in my country after an update to set up Television over IP - was impacted 3/4 of network infrastructure of the country (including network infrastructure of 12 banks) . - the operator needed 5 days to restore the services. Have a nice day Rumen

It brings a point to discuss. For example, in CIS for RHEL there is also a similar requirement. Since it is a manual requirement, we don't include any rule in the controlfile rules section, even if we have a good candidate. But we included the rule in related_rules section, just for reference.
It helps us to know a rule exists and could be useful to somehow automate the requirement or to create a tailored file.
However, the down-side of this is that rules in related_rules doesn't appear in the guides.
So, I see value on having just the rule description in the guide. But I don't see much value in creating new rules when there is already a existing one for the same purpose.

@yuumasato , @Mab879 , @vojtapolasek , @ggbecker , what do you think?

[vojtapolasek]

I think I agree. I don't think we should create new rules which are supposed to NOT have any automation associated - I mean in case we know it from the begining. I think the correct way would be to mark such a control as "manual" and possibly add related_rules.
In the future, it might be worth investigating a possibility to render some parts of a control file in the final HTML guide.

[rumch-se]

Hello @vojtapolasek - I have a question about automation of the rules. In general we have audit and remediation part which a subject of automation. But there are some cases when one of the parts is not possible to be automatized (usually audit when OVAL is not applicable). According to the controls definitions what is the correct status for these rules?
Have a nice day
Rumen

[vojtapolasek]

Hello @rumch-se could you give me some example please? If the OVAL is not applicable in all cases, I don't see a reason for having it there at all...
I can imagine there are rules which do not have remediation part, because it is for example dependent on user's choice, such as grub2_uefi_password rule.

[rumch-se]

Hello @vojtapolasek
For example this PR #10128.

According to the this CIS rule nftables creates a table in the memory of the OS, and when the OS is restarted this information will be not in the memory any more. I don't know how to check with OVAL that the object exist into memory - to make audit. During the remediation we can check if there is a table or not, but if I want to make an automatic audit only I don't know how to make it.

Have a nice day
Rumen

[marcusburghardt]

This should fit better in the fixtext instead of ocil.

[marcusburghardt]

@rumch-se , I have checked this proposed new rule and compared to the existing security_patches_up_to_date. The second is more complete and also used by SUSE. It is preferable that you use it instead of creating a new rule to do almost the same. This increases project maintenance and similar rules for the same purpose cause confusion to the users. Regarding the remediation, you can edit the platform header and this would make it to be skipped for SLE products. You can also update the ocil and fixtext in the existing rule to make it conditional to SLE products.

[marcusburghardt]

ld make it to be skipped for SLE products.

Here are the definitions of the current available statuses:
https://complianceascode.readthedocs.io/en/latest/manual/developer/03_creating_content.html#reporting-status

[marcusburghardt]

Hello @vojtapolasek For example this PR #10128.

According to the this CIS rule nftables creates a table in the memory of the OS, and when the OS is restarted this information will be not in the memory any more. I don't know how to check with OVAL that the object exist into memory - to make audit. During the remediation we can check if there is a table or not, but if I want to make an automatic audit only I don't know how to make it.

Have a nice day Rumen

Like mentioned by @Mab879 in the #10128 the check can be done via OVAL or SCE (script check engine). But the SCE is not SCAP compliant. Here is an example of rule using SCE: https://github.com/ComplianceAsCode/content/tree/master/linux_os/guide/system/accounts/accounts-session/accounts_users_own_home_directories

[marcusburghardt]

@rumch-se , I have checked this proposed new rule and compared to the existing security_patches_up_to_date. The second is more complete and also used by SUSE. It is preferable that you use it instead of creating a new rule to do almost the same. This increases project maintenance and similar rules for the same purpose cause confusion to the users. Regarding the remediation, you can edit the platform header and this would make it to be skipped for SLE products. You can also update the ocil and fixtext in the existing rule to make it conditional to SLE products.

@rumch-se are you ok to close this PR and use the security_patches_up_to_date rule instead?

[rumch-se]

Hello @marcusburghardt
I am OK to close this PR and to use security_patches_up_to_date.
Have a nice day
Rumen

[marcusburghardt]

Base on #10089 (comment) and confirmation from @rumch-se in #10089 (comment), I am closing this PR in favor of security_patches_up_to_date rule. Thanks @rumch-se