Skip to content

Commit

Permalink
Merge pull request #11825 from yuumasato/pcidss_4_req_2
Browse files Browse the repository at this point in the history 
CMP-2454: PCI-DSS  v4 Requirement 2
  • Loading branch information
@rhmdnd
rhmdnd committed Apr 23, 2024
2 parents 37bc1b9 + 9c9c71c commit d4f94de
Showing 1 changed file with 124 additions and 34 deletions.
158 changes: 124 additions & 34 deletions controls/pcidss_4_ocp4.yml
View file
Original file line number Diff line number Diff line change
Expand Up @@ -327,14 +327,14 @@ controls:
are defined and understood.
levels:
- base
status: pending
status: not applicable
controls:
- id: 2.1.1
title: All security policies and operational procedures that are identified in Requirement 2
are Documented, Kept up to date, In use and Known to all affected parties.
levels:
- base
status: pending
status: not applicable
notes: |-
Examine documentation and interview personnel to verify that security policies and
operational procedures identified in Requirement 2 are managed in accordance with all
Expand All @@ -349,17 +349,17 @@ controls:
requirements.
levels:
- base
status: pending
status: not applicable
notes: |-
Examine documentation and interview personnel to verify that day-to-day responsibilities
for performing all the activities in Requirement 2 are documented, assigned and understood
by the assigned personnel.
- id: '2.2'
title: 'System components are configured and managed securely.'
title: System components are configured and managed securely
levels:
- base
status: pending
status: partial
controls:
- id: 2.2.1
title: Configuration standards are developed, implemented, and maintained
Expand All @@ -374,33 +374,60 @@ controls:
immediately after a system component is connected to a production environment.
levels:
- base
status: pending
status: partial
notes: |-
Interestingly this requirement recommends other standards, such as Center for Internet
Security (CIS), International Organization for Standardization (ISO), National Institute
of Standards and Technology (NIST), Cloud Security Alliance, and product vendors. So, the
rules included here are very generic in terms of hardening.
rules: []
The Compliance Operator provides an automated way of checking for a secure configuration
of OpenShift according to known security standards, as well as automatically remediating
deviations from the target configuration.
Its usage is recommended to ensure appropriate configuration and is set and prevent drift.
System components outside of OpenShift cannot be checked by the Compliance Operator.
This control is also addressed by applying the OpenShift CIS recommendations.
rules:
- scansettingbinding_exists

- id: 2.2.2
title: Vendor default accounts are managed.
title: Vendor default accounts are managed
description: |-
Vendor default accounts are managed as follows:
- If the vendor default account(s) will be used, the default password is changed per
Requirement 8.3.6.
- If the vendor default account(s) will not be used, the account is removed or disabled.
levels:
- base
status: pending
status: automated
notes: |-
Also related to requirement 8.2.6 and 8.3.5.
rules: []
The Openshift Platform doesn't come with any hardcoded credentials or passwords.
Authenticators are uniquely created at deployment-time, including credentials
for an admin user (called `kubeadmin`) which is meant for bootstrapping purposes.
It is recommended for deployers to delete this account in favor of using an IdP
and setting up appropriate permissions via RBAC roles.
rules:
- kubeadmin_removed

- id: 2.2.3
title: 'Primary functions requiring different security levels are managed'
title: Primary functions requiring different security levels are managed
description: |-
Primary functions requiring different security levels are managed as follows:
- Only one primary function exists on a system component
OR
- Primary functions with differing security levels that exist on the same system component
are isolated from each other
OR
- Primary functions with differing security levels on the same system component are all
secured to the level required by the function with the highest security need.
levels:
- base
status: pending
status: inherently met
notes: |-
OpenShift nodes run RHEL CoreOS by default, which contains only the
necessary services, protocols and daemons needed to run OpenShift and
containers. OpenShift provides the means to separate application
workloads within the cluster onto separate hosts and containers. It
is the responsibility of the organization to appropriately separate
their applications into relevant containers to meet this control.
rules: []

- id: 2.2.4
title: Only necessary services, protocols, daemons, and functions are enabled, and all
Expand All @@ -410,7 +437,12 @@ controls:
the system component.
levels:
- base
status: pending
status: inherently met
notes: |-
The OpenShift Container Platform uses RHEL CoreOS by default. In itself, it's
a minimal operating system with the sole purpose of running OpenShift. Therefore
it doesn't contain extra packages or functionality; only the minimal that's meant
to run OpenShift. RHCOS is the recommended operating system for OpenShift.
rules: []

- id: 2.2.5
Expand All @@ -423,11 +455,33 @@ controls:
using insecure services, protocols, or daemons.
levels:
- base
status: pending
status: automated
notes: |-
Known insecure services are removed or disabled by 2.2.4
General security measures are covered by 1.2.6
This requirement is more about checking exceptions and their respective documentation.
OpenShift does not require any insecure services, protocols or daemons for
proper functioning. The deployment comes with TLS enabled by default with
strong ciphers and an appropriate version enabled.
rules:
- api_server_bind_address
- api_server_client_ca
- api_server_etcd_ca
- api_server_etcd_cert
- api_server_etcd_key
- api_server_kubelet_certificate_authority
- api_server_oauth_https_serving_cert
- api_server_openshift_https_serving_cert
- api_server_service_account_public_key
- api_server_tls_cert
- api_server_tls_cipher_suites
- api_server_tls_private_key
- controller_service_account_private_key
- etcd_cert_file
- etcd_client_cert_auth
- etcd_key_file
- etcd_peer_cert_file
- etcd_peer_client_cert_auth
- etcd_peer_key_file
- kubelet_configure_tls_cert
- kubelet_configure_tls_key

- id: 2.2.6
title: System security parameters are configured to prevent misuse.
Expand All @@ -436,12 +490,19 @@ controls:
configuration.
levels:
- base
status: pending
status: automated
notes: |-
This requirement is not specific but also points to 2.2.1, where other policies are
referenced. Therefore, the most common rules related to system configuration in order to
prevent misuse and selected in main profiles are also selected here.
rules: []
While it's possible to manually configure the security settings
in the Openshift Container Platform, the Compliance Operator provides
an automated way of checking for a secure configuration and automatically
remediating issues according to known security standards. Its usage
is recommended to ensure appropriate configuration is set and prevent
drift.
Additionaly, as part of 2.2.1, the CIS recommendations for OpenShift are applied in order
to prevent system misconfiguration and misuse.
rules:
- scansettingbinding_exists

- id: 2.2.7
title: All non-console administrative access is encrypted using strong cryptography.
Expand All @@ -451,16 +512,40 @@ controls:
and application programming interfaces (APIs).
levels:
- base
status: pending
status: automated
notes: |-
Related to requirement 12.3.3.
rules: []
rules:
- api_server_bind_address
- api_server_client_ca
- api_server_etcd_ca
- api_server_etcd_cert
- api_server_etcd_key
- api_server_https_for_kubelet_conn
- api_server_insecure_port
- api_server_kubelet_certificate_authority
- api_server_oauth_https_serving_cert
- api_server_openshift_https_serving_cert
- api_server_service_account_public_key
- api_server_tls_cert
- api_server_tls_cipher_suites
- api_server_tls_private_key
- controller_service_account_private_key
- etcd_cert_file
- etcd_client_cert_auth
- etcd_key_file
- etcd_peer_cert_file
- etcd_peer_client_cert_auth
- etcd_peer_key_file
- kubelet_configure_tls_cert
- kubelet_configure_tls_key
- ocp_no_ldap_insecure

- id: '2.3'
title: Wireless environments are configured and managed securely.
levels:
- base
status: pending
status: not applicable
controls:
- id: 2.3.1
title: For wireless environments connected to the CDE or transmitting account data, all
Expand All @@ -475,9 +560,13 @@ controls:
- Any other security-related wireless vendor defaults.
levels:
- base
status: pending
status: not applicable
notes: |-
Wireless interfaces are disabled by 1.3.3.
The OpenShift Container Platform doesn't manage wireless encryptions keys nor wireless
access points passwords.
related_rules:
# NOTE: (yuumasato): the node OS can explicitly disable wireless interfaces
- wireless_disable_interfaces

- id: 2.3.2
title: For wireless environments connected to the CDE or transmitting account data, wireless
Expand All @@ -487,9 +576,10 @@ controls:
data, wireless encryption keys are changed
levels:
- base
status: pending
status: not applicable
notes: |-
Wireless interfaces are disabled by 1.3.3.
The OpenShift Container Platform doesn't manage wireless encryptions keys nor wireless
access points passwords.
- id: '3.1'
title: Processes and mechanisms for protecting stored account data are defined and understood.
Expand Down

0 comments on commit d4f94de

Please sign in to comment.