CMP-2462: PCI-DSS v4 Requirement 10

controls/pcidss_4_ocp4.yml

@@ -2726,44 +2726,36 @@ controls:
       cardholder data are defined and documented.
     levels:
       - base
-    status: pending
+    status: not applicable
     controls:
     - id: 10.1.1
       title: All security policies and operational procedures that are identified in Requirement
         10 are Documented, Kept up to date, In use and Known to all affected parties.
       levels:
         - base
-      status: pending
-      notes: |-
-        Examine documentation and interview personnel to verify that security policies and
-        operational procedures identified in Requirement 10 are managed in accordance with all
-        elements specified in this requirement.
+      status: not applicable
 
     - id: 10.1.2
       title: Roles and responsibilities for performing activities in Requirement 10 are
         documented, assigned, and understood.
       levels:
         - base
-      status: pending
-      notes: |-
-        Examine documentation and interview personnel to verify that day-to-day responsibilities
-        for performing all the activities in Requirement 10 are documented, assigned and
-        understood by the assigned personnel.
+      status: not applicable
 
   - id: '10.2'
     title: Audit logs are implemented to support the detection of anomalies and suspicious
       activity, and the forensic analysis of events.
     levels:
       - base
-    status: pending
+    status: inherently met
     controls:
     - id: 10.2.1
       title: Audit logs are enabled and active for all system components and cardholder data.
       description: |-
         Records of all activities affecting system components and cardholder data are captured.
       levels:
         - base
-      status: pending
+      status: inherently met
       rules: []
       controls:
       - id: 10.2.1.1
@@ -2772,12 +2764,11 @@ controls:
           Records of all individual user access to cardholder data are captured.
         levels:
           - base
-        status: planned
-        notes: |-
-          Differently than 10.2.1.4, this requirement is about logginh successful access to
-          cardholder data. This kind of events can easily hit performance issues and are usually
-          not necessary if a good access policy is in place. More clarification is needed about
-          this requirement.
+        status: inherently met
+        notes: >-
+          All user and/or service account accesses to OpenShift components are logged.
+          However, the payment entity still is responsible for logging events for access to
+          applications within workloads hosted in containers in OpenShift.
 
       - id: 10.2.1.2
         title: Audit logs capture all actions taken by any individual with administrative access,
@@ -2786,46 +2777,60 @@ controls:
           Records of all actions performed by individuals with elevated privileges are captured.
         levels:
           - base
-        status: pending
-        notes: |-
-          Not all privileged commands have suid or sgid enabled. We probably want to include more
-          rules for this requirement.
-        rules: []
+        status: inherently met
+        notes: >-
+          All actions taken by individual with root or administrative privileges to OpenShift and
+          Red Hat CoreOS are logged.
+          However, the payment entity still is responsible for logging events for access to
+          applications within workloads hosted in containers in OpenShift.
 
       - id: 10.2.1.3
         title: Audit logs capture all access to audit logs.
         description: |-
           Records of all access to audit logs are captured.
         levels:
           - base
-        status: pending
-        rules: []
+        status: inherently met
+        notes: >-
+          Access to audit trails relative to OpenShift are made available at the OS level with
+          administrator accounts.
+          Red Hat CoreOS can be configured to log access to the journal or log file. For better
+          protection of audit trails, including improved access controls, it is recommended to
+          direct logs to an external log server or Security Information Event Management (SIEM)
+          solution.
+        rules:
+          - audit_logging_enabled
 
       - id: 10.2.1.4
         title: Audit logs capture all invalid logical access attempts.
         description: |-
           Records of all invalid access attempts are captured.
         levels:
           - base
-        status: pending
-        rules: []
+        status: inherently met
+        notes: |-
+          Unauthorized attempts to access system components or run unauthorized commands against
+          OpenShift are logged.
 
       - id: 10.2.1.5
         title: Audit logs capture all changes to identification and authentication credentials.
         levels:
           - base
-        status: pending
-        rules: []
+        status: inherently met
 
       - id: 10.2.1.6
         title: Audit logs capture the initialization of new audit logs, and starting, stopping, or
           pausing of the existing audit logs.
         levels:
           - base
-        status: planned
+        status: inherently met
         notes: |-
-          Ideally should exist rules specifically logging when audit configuration files are
-          modified and audit service state is changed.
+          Stopping the mechanisms for log creation in OpenShift requires stopping the OpenShift
+          Control Plane itself, which would have the effect of preventing any further access for
+          any users to the API, CLI, or Web UI.
+          Auditing within OpenShift cannot be reconfigured or stopped without reconfiguring
+          OpenShift.
+          Any attempt to reconfigure OpenShift will be logged.
 
       - id: 10.2.1.7
         title: Audit logs capture all creation and deletion of system-level objects.
@@ -2834,12 +2839,10 @@ controls:
           functionality are captured.
         levels:
           - base
-        status: pending
-        notes: |-
-          There are enough rules to capture deletion events but not for creation events.
-          This requirement needs to be better investigated to confirm which additional rules would
-          satistfy the requirement.
-        rules: []
+        status: inherently met
+        notes: >-
+          Creation and deletion of system levels objects is logged by OpenShift and by
+          Red Hat CoreOS.
 
     - id: 10.2.2
       title: Audit logs record sufficient details for each auditable event.
@@ -2853,34 +2856,55 @@ controls:
           name and protocol).
       levels:
         - base
-      status: pending
-      notes: |-
-        Standard settings for audit should be enough.
-      rules: []
+      status: inherently met
+      notes: >-
+        The logs generated by OpenShift and Red Hat CoreOS include all the data required.
 
   - id: '10.3'
     title: Audit logs are protected from destruction and unauthorized modifications.
     levels:
       - base
-    status: pending
+    status: partial
     controls:
     - id: 10.3.1
       title: Read access to audit logs files is limited to those with a job-related need.
       description: |-
         Stored activity records cannot be accessed by unauthorized personnel.
       levels:
         - base
-      status: pending
-      rules: []
+      status: manual
+      notes: |-
+        Access to audit logs is limited to the cluster-admin role. Ensure that only those
+        user with a job-related need have the cluster-admin role.
+      rules:
+        # This rule doesn't have an automated check
+        - rbac_limit_cluster_admin
 
     - id: 10.3.2
       title: Audit log files are protected to prevent modifications by individuals.
       description: |-
         Stored activity records cannot be modified by personnel.
       levels:
         - base
-      status: pending
-      rules: []
+      status: planned
+      notes: >-
+        Limited access to the audit trails on OpenShift hosts provides minimal protection from
+        unauthorized modification.
+        Use of an external log collector or SIEM solution may provide improved protections against
+        unauthorized modifications by adding additional features such as file integrity monitoring,
+        digital signing, or Write Once, Read Many (WORM) storage.
+      levels:
+      - base
+      rules:
+        - directory_permissions_var_log_kube_audit
+        - directory_permissions_var_log_oauth_audit
+        - directory_permissions_var_log_ocp_audit
+        - file_ownership_var_log_kube_audit
+        - file_ownership_var_log_oauth_audit
+        - file_ownership_var_log_ocp_audit
+        - file_permissions_var_log_kube_audit
+        - file_permissions_var_log_oauth_audit
+        - file_permissions_var_log_ocp_audit
 
     - id: 10.3.3
       title: Audit log files, including those for external-facing technologies, are promptly
@@ -2891,7 +2915,7 @@ controls:
         unauthorized modification.
       levels:
         - base
-      status: pending
+      status: manual
       notes: |-
         Although the technologies in general allow to send logs to a centralized server, some
         parameters for this configuration are specific to each site policy and therefore the
@@ -2905,14 +2929,16 @@ controls:
         Stored activity records cannot be modified without an alert being generated.
       levels:
         - base
-      status: pending
-      rules: []
+      status: partial
+      rules:
+        # TODO: Add FIO config to allow /var/log/... to extend in size but monitor perms.
+        - file_integrity_exists
 
   - id: '10.4'
     title: Audit logs are reviewed to identify anomalies or suspicious activity.
     levels:
       - base
-    status: pending
+    status: manual
     controls:
     - id: 10.4.1
       title: The audit logs are reviewed at least once daily.
@@ -2925,7 +2951,7 @@ controls:
           (IDS/IPS), authentication servers).
       levels:
         - base
-      status: pending
+      status: manual
       controls:
       - id: 10.4.1.1
         title: Automated mechanisms are used to perform audit log reviews.
@@ -2935,9 +2961,7 @@ controls:
           which it will be required and must be fully considered during a PCI DSS assessment.
         levels:
           - base
-        status: pending
-        notes: |-
-          Automation mechanisms, solutions and approaches vary for each organizarion.
+        status: not applicable
 
     - id: 10.4.2
       title: Logs of all other system components (those not specified in Requirement 10.4.1) are
@@ -2948,7 +2972,7 @@ controls:
         is applicable to all other in-scope system components not included in Requirement 10.4.1.
       levels:
         - base
-      status: pending
+      status: not applicable
       controls:
       - id: 10.4.2.1
         title: The frequency of periodic log reviews for all other system components (not defined
@@ -2960,21 +2984,21 @@ controls:
           it will be required and must be fully considered during a PCI DSS assessment.
         levels:
           - base
-        status: pending
+        status: not applicable
 
     - id: 10.4.3
       title: Exceptions and anomalies identified during the review process are addressed.
       description: |-
         Suspicious or anomalous activities are addressed.
       levels:
         - base
-      status: pending
+      status: not applicable
 
   - id: '10.5'
     title: Audit log history is retained and available for analysis.
     levels:
       - base
-    status: pending
+    status: supported
     controls:
     - id: 10.5.1
       title: Retain audit log history for at least 12 months, with at least the most recent three
@@ -2984,17 +3008,20 @@ controls:
         are retained for at least 12 months.
       levels:
         - base
-      status: pending
+      status: supported
       notes: |-
-        It is not simple to ensure 12 months history is present in each system but the rules in
-        this requirement ensures the logs are not lost without administrators awareness.
+        Log retention in OpenShift is not time based, the default configuration rotates 10 log
+        files of 100 MB each, allowing up to 1GB of retention.
+
+        To implement time based audit log retention configure log forwarding to a third party
+        storage, for example Elasticsearch or LokiStack.
       rules: []
 
   - id: '10.6'
     title: Time-synchronization mechanisms support consistent time settings across all systems.
     levels:
       - base
-    status: pending
+    status: planned
     controls:
     - id: 10.6.1
       title: System clocks and time are synchronized using time-synchronization technology.
@@ -3004,10 +3031,11 @@ controls:
         Requirements 6.3.1 and 6.3.3.
       levels:
         - base
-      status: pending
+      status: inherently met
       notes: |-
-        Maybe it is possible to optmize some similar rules related to ntp.
-      rules: []
+        By default OpenShift uses a public Network Time Protocol (NTP) server.
+        However, additional configuration is nedded to use a local enterprise NTP server,
+        or in disconnected environments.
 
     - id: 10.6.2
       title: Systems are configured to the correct and consistent time.
@@ -3023,11 +3051,20 @@ controls:
         - Internal systems receive time information only from designated central time server(s).
       levels:
         - base
-      status: pending
+      status: planned
       notes: |-
-        The selected rules might need updates in order to restrict their platform applicability
-        to avoid conflicts.
+        OpenShift is configured to use a public pool.ntp..org which is good and reliable, but
+        ultimatlely is not enterprise grade.
+        The notion of central time server implies that an exclusive NTP server is deployed to
+        serve the cluster.
+
+        NTP configuration is done at the node level, excpept when using Precison Time Procotol
+        (PTP), for which PTP Operator can be used. PTP can only be used on bare metal deployments.
+        https://docs.openshift.com/container-platform/latest/networking/ptp/about-ptp.html
       rules: []
+      related_rules:
+        - var_multiple_time_servers=generic
+        - chronyd_specify_remote_server
 
     - id: 10.6.3
       title: Time synchronization settings and data are protected.
@@ -3036,8 +3073,17 @@ controls:
         - Any changes to time settings on critical systems are logged, monitored, and reviewed.
       levels:
         - base
-      status: pending
+      status: planned
+      notes: |-
+        As NTP is configured directly on the node the audit should also be configured there.
       rules: []
+      related_rules:
+        - audit_rules_time_watch_localtime
+        - audit_rules_time_settimeofday
+        - audit_rules_time_clock_settime
+        - audit_rules_time_stime
+        - audit_rules_time_adjtimex
+        - chronyd_run_as_chrony_user
 
   - id: '10.7'
     title: Failures of critical security control systems are detected, reported, and responded to