Add support for PCI DSS v3.2.1 for SLE12

[teacup-on-rockingchair]

Description:

• Add PCI-DSS control for v.3.2.1 and SLE profiles to include it

Rationale:

• Add sle12 platform and missing CCE and PCIDSS references to rules related to PCIDSS effort for SLE platforms

[openshift-ci]

Hi @teacup-on-rockingchair. 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:

Fedora Environment

Oracle Linux 8 Environment

[ggbecker]

I have realized that maybe we could have a single pcidss_v3 that would contain both content for OCP4 and other products as well, since the controls file will include rules that are applicable to a given built product, so let's say you build a profile using this controls file, it will include only the rules that have prodtype set to that given product.

[teacup-on-rockingchair]

I have realized that maybe we could have a single pcidss_v3 that would contain both content for OCP4 and other products as well, since the controls file will include rules that are applicable to a given built product, so let's say you build a profile using this controls file, it will include only the rules that have prodtype set to that given product.

I thought about it also but what stopped me of reusing the existing control was not rules that were mostly OCP4 specific, but the notes in the pcidss_ocp4 control file which had a lot of references to Open Shift specific behaviour and OCP environment. If you think that it would be ok to put prodtype specific jinja clauses around those notes, then I guess we can easily aggregate both controls.

[ggbecker]

I have realized that maybe we could have a single pcidss_v3 that would contain both content for OCP4 and other products as well, since the controls file will include rules that are applicable to a given built product, so let's say you build a profile using this controls file, it will include only the rules that have prodtype set to that given product.

I thought about it also but what stopped me of reusing the existing control was not rules that were mostly OCP4 specific, but the notes in the pcidss_ocp4 control file which had a lot of references to Open Shift specific behaviour and OCP environment. If you think that it would be ok to put prodtype specific jinja clauses around those notes, then I guess we can easily aggregate both controls.

It's probably ok to have a separate file then. There is also the fact that it can create a misinterpretation of the status field depending on which rules are applicable to which product. So let's keep them separate, at least for now. Then this pcidss_3 can be used for the general linux distros.

[ggbecker]

3.2.1 instead?

[teacup-on-rockingchair]

Should be ok in 0e0c5db

[ggbecker]

Hi, I've run the profile diff tool and notice that the following rules that were previously in the pci-dss.profile are not present in the pci-dss controls file:

$ ./build-scripts/profile_tool.py sub --profile1 products/sle15/profiles/pci-dss-from-main-branch.profile --profile2 build/sle15/profiles/pci-dss.profile --product sle15 --build-config-yaml build/build_config.yml --ssg-root .

selections:
- accounts_minimum_age_login_defs
- accounts_no_uid_except_zero
- accounts_password_warn_age_login_defs
- accounts_tmout
- accounts_umask_etc_bashrc
- accounts_umask_etc_login_defs
- accounts_umask_etc_profile
- cracklib_accounts_password_pam_dcredit
- cracklib_accounts_password_pam_lcredit
- cracklib_accounts_password_pam_minlen
- cracklib_accounts_password_pam_ocredit
- cracklib_accounts_password_pam_retry
- cracklib_accounts_password_pam_ucredit
- file_permissions_sshd_private_key
- file_permissions_sshd_pub_key
- no_direct_root_logins
- package_audit_installed
- package_chrony_installed
- package_openldap-clients_removed
- package_sudo_installed
- package_telnet-server_removed
- package_vsftpd_removed
- package_ypserv_removed
- postfix_network_listening_disabled
- securetty_root_login_console_only
- sshd_disable_empty_passwords
- sshd_disable_root_login
- sshd_do_not_permit_user_env
- sshd_enable_warning_banner
- sshd_set_loglevel_verbose
- sudo_add_use_pty
- sudo_custom_logfile
- var_smartcard_drivers=cac

Maybe you would like to include these rule as well so you don't end up with a different profile, at least for the transition part.

[teacup-on-rockingchair]

Hi, I've run the profile diff tool and notice that the following rules that were previously in the pci-dss.profile are not present in the pci-dss controls file:

$ ./build-scripts/profile_tool.py sub --profile1 products/sle15/profiles/pci-dss-from-main-branch.profile --profile2 build/sle15/profiles/pci-dss.profile --product sle15 --build-config-yaml build/build_config.yml --ssg-root .

selections:
- accounts_minimum_age_login_defs
- accounts_no_uid_except_zero
- accounts_password_warn_age_login_defs
- accounts_tmout
- accounts_umask_etc_bashrc
- accounts_umask_etc_login_defs
- accounts_umask_etc_profile
- cracklib_accounts_password_pam_dcredit
- cracklib_accounts_password_pam_lcredit
- cracklib_accounts_password_pam_minlen
- cracklib_accounts_password_pam_ocredit
- cracklib_accounts_password_pam_retry
- cracklib_accounts_password_pam_ucredit
- file_permissions_sshd_private_key
- file_permissions_sshd_pub_key
- no_direct_root_logins
- package_audit_installed
- package_chrony_installed
- package_openldap-clients_removed
- package_sudo_installed
- package_telnet-server_removed
- package_vsftpd_removed
- package_ypserv_removed
- postfix_network_listening_disabled
- securetty_root_login_console_only
- sshd_disable_empty_passwords
- sshd_disable_root_login
- sshd_do_not_permit_user_env
- sshd_enable_warning_banner
- sshd_set_loglevel_verbose
- sudo_add_use_pty
- sudo_custom_logfile
- var_smartcard_drivers=cac

Maybe you would like to include these rule as well so you don't end up with a different profile, at least for the transition part.

Those rules were added in the context of PCIDSS v4 effort, thanks for the feedback. For now I think is best if I include them in the context of different profile file. Once I have built a control file for that version of the standard will include them and rework the profile file.

[ggbecker]

We should probably shift towards having version 4 as the default one. This basically means that the pci-dss.profile should point to the latest 4 version. Version 3 should eventually go away when there is the sunset and then we are left only with the pci-dss.profile identifier for example. The same for the pcidss reference identifier. We should update the URL links to the latest version and create a pcidss_3 reference URI to point to the older policy. But one problem might be that the already assigned references will be inconsistent with the v4 for example. What do you think?

[teacup-on-rockingchair]

We should probably shift towards having version 4 as the default one. This basically means that the pci-dss.profile should point to the latest 4 version. Version 3 should eventually go away when there is the sunset and then we are left only with the pci-dss.profile identifier for example. The same for the pcidss reference identifier. We should update the URL links to the latest version and create a pcidss_3 reference URI to point to the older policy. But one problem might be that the already assigned references will be inconsistent with the v4 for example. What do you think?

In general I agree, but would prefer to do that, in the context of another PR, once I generate the control file for v4 and then will be able to rename the profiles per product. Because the v4 for SLE platforms is WIP, and I am not really aware the state of the art for the other platforms.

[ggbecker]

We should probably shift towards having version 4 as the default one. This basically means that the pci-dss.profile should point to the latest 4 version. Version 3 should eventually go away when there is the sunset and then we are left only with the pci-dss.profile identifier for example. The same for the pcidss reference identifier. We should update the URL links to the latest version and create a pcidss_3 reference URI to point to the older policy. But one problem might be that the already assigned references will be inconsistent with the v4 for example. What do you think?

In general I agree, but would prefer to do that, in the context of another PR, once I generate the control file for v4 and then will be able to rename the profiles per product. Because the v4 for SLE platforms is WIP, and I am not really aware the state of the art for the other platforms.

That's true, ideally it would be good if we do this transition before the next release, otherwise shuffling profile IDs can cause some implications for people that already started using that specific profile ID for example. But we should be able to manage that.

[ggbecker]

Also, if you could please rebase on top of latest main branch to check if there is no conflict with the CCE assignment since rumch-se has been including a bunch of them, just to be sure that the test will be able to catch any duplicate. Thanks. Otherwise I think we can probably merge this one.

[teacup-on-rockingchair]

Also, if you could please rebase on top of latest main branch to check if there is no conflict with the CCE assignment since rumch-se has been including a bunch of them, just to be sure that the test will be able to catch any duplicate. Thanks. Otherwise I think we can probably merge this one.

Thanks for the reminder, I just did the rebase and run the uniqe and missing cce tests for sle platforms.

[codeclimate]

Code Climate has analyzed commit 0b7000e 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 41.2% (0.0% change).

View more on Code Climate.