Description

The goal for this epic is to provide an initial PCI-DSS compliance profile for use with the Compliance Operator. This initial profile will not necessarily provide complete coverage for PCI-DSS.  As much of PCI-DSS can be mapped to NIST SP800-53 controls that we have already worked on, the goal is to have the initial profile include rules that are already implemented in the ComplianceAsCode project.  Implementing new rules is out of scope.

An analysis to map NIST SP800-53 controls to PCI-DSS was already conducted, which is summarized in the following spreadsheet:

https://docs.google.com/spreadsheets/d/17tijEH57XvFKGR9DWbbfmH-7BVnFtiZjZzxlGebVBwA/edit?usp=sharing

List of checks and remediation for PCI-DSS https://docs.google.com/spreadsheets/d/1YujTrDp-f2YHni5n1ssyJdsMrbkiTAgb5iqSp49dBPg/edit#gid=1070290052

Why is this important?

The Payment Card Industry (PCI) Data Security Standards (DSS) is a global information security standard designed to prevent fraud through increased control of credit card data. The PCI Security Standards Council (PCI SSC) is a global forum that brings together payments industry stakeholders to develop and drive the adoption of data security standards, including PCI DSS.

Compliance with PCI DSS is required for any organization that stores, processes, or transmits cardholder data, which, at a minimum, consists of the full primary account number (PAN) - a unique payment card number that identifies the issuer and the particular cardholder account. Cardholder data may also appear in the form of a full PAN plus additional information such as cardholder name, expiration date, and service codes. Sensitive authentication data that may be transmitted or processed (but not stored) as part of a payment transaction contains additional data elements that must also be protected, including track data from card chip or magnetic stripe, PINs, PIN blocks, etc. For more information, see PCI DSS glossary.

The PCI DSS designates four levels of compliance based on transaction volume, with Service Provider Level 1 corresponding to the highest volume of transactions at more than 6 million a year. The assessment results in an Attestation of Compliance (AoC), which is available to customers, and Report on Compliance (RoC) issued by an approved Qualified Security Assessor (QSA). The effective period for compliance begins upon passing the audit and receiving the AoC from the QSA and ends one year from the date the AoC is signed.

This epic covers the controls and profile to support our customers and manage services to maintain compliance for PCI-DSS.

We are not intent to cover and non technical controls.

Acceptance Criteria

• The Compliance Operator ships with a PCI-DSS profile.
• The profile contains the appropriate existing implemented OpenSCAP checks from NIST SP800-53 as defined in the mapping spreadsheet
• We have the appropriate Remediations for checks that can be auto-remediated (where already implemented).
• Added controls based on the following list https://docs.google.com/spreadsheets/d/1YujTrDp-f2YHni5n1ssyJdsMrbkiTAgb5iqSp49dBPg/edit#gid=1070290052
• We have successfully running automated testing / CI for the profile
• Compliance Operator documentation is updated to indicate that we provide a profile for PCI-DSS, along with a basic description of the profile.
• Progress tracking tooling is created to track coverage for profile development

Documentation Needs

This epic will be addressed by adding a new SCAP profile that is used by compliance-operator.  SCAP content already includes human-readable guidance documentation that explains all of the rules and remediations that are contained in a profile.  Engineering will be developing this detailed guidance as a part of the profile development.  As such, the documentation needs in our official OpenShift docs for this should be minimal.

The Compliance Operator documentation needs to list the "PCI-DSS" profile in the list of provided profiles in the "Understanding the Compliance Operator" section (adding this table is described in CMP-888). The profile name, human-readable title/description, and reference link to be used in the table should all be obtained using "oc get compliance.profile" once development for this epic is complete.

Testing Needs

This epic concerns the addition of a large set of rules and remediations to the "moderate" profile that is used by the compliance operator. As such, this profile must be tested to ensure the following:

• The rules are able to get the necessary information
• The rules generate appropriate remediations
• The remediations indeed address the found gaps (defines by the rules)
• The cluster is in a working state after the remediations have been applied

A proposed test is as follows:

• In a clean cluster, install the compliance-operator
• Run a scan for the moderate profile. This will be both a Platform scan and a Node scan which are the ocp4 and rhcos4 profiles respectively.
• Apply all the suggested remediations
• Apply manual fixes as suggested by the results (e.g. configure a relevant IdP, use signed images only, etc.)
• Re-scan
• Verify that the rules which had issues were fixed and are now in a compliant state
• Run a smoke test to verify that the cluster is still usable

References

The full list of security controls for PCI-DSS is tracked here https://docs.google.com/spreadsheets/d/17tijEH57XvFKGR9DWbbfmH-7BVnFtiZjZzxlGebVBwA/edit?usp=sharing