4. Cyber Security Standards – PCI DSS

Trust, but verify, and believe that Security is not a one-time event. It’s an ongoing process.

The Payment Card Industry Data Security Standard (PCI DSS) was developed to encourage and enhance payment account data security and facilitate the broad adoption of consistent data security measures globally. PCI DSS provides a baseline of technical and operational requirements designed to protect account data. While specifically designed to focus on environments with payment account data, PCI DSS can also be used to protect against threats and secure other elements in the payment ecosystem.

The first version of PCI DSS v1.2 was released in October 2008 while v4.0.1 is the current version. PCI DSS sets minimum requirements for protecting account data, which can be enhanced with extra controls, however, local laws and regulations may also mandate specific protection for personal information or other data elements.

1. Overview:

The Payment Card Industry Data Security Standard includes 12 principal requirements, detailed security criteria, testing procedures, and relevant information for each requirement. These sections offer guidelines and best practices to help entities prepare for, conduct, and report a PCI DSS assessment.

Build and Maintain a Secure Network and Systems

1.       Install and Maintain Network Security Controls.

2.       Apply Secure Configurations to All System Components.

Protect Account Data

3.       Protect Stored Account Data.

4.       Protect Cardholder Data with Strong Cryptography During Transmission Over Open, Public Networks.

Maintain a Vulnerability Management Program

5.       Protect All Systems and Networks from Malicious Software.

6.       Develop and Maintain Secure Systems and Software.

Implement Strong Access Control Measures

7.       Restrict Access to System Components and Cardholder Data by Business Need to Know.

8.       Identify Users and Authenticate Access to System Components.

9.       Restrict Physical Access to Cardholder Data.

Regularly Monitor and Test Networks

10.   Log and Monitor All Access to System Components and Cardholder Data.

11.   Test Security of Systems and Networks Regularly. Maintain an Information Security Policy

12.   Support Information Security with Organizational Policies and Programs.

Over 60 guidance documents and information supplements on the PCI SSC website offer specific advice for PCI DSS. The PCI Security Standards Council also provides additional resources to help organizations with their PCI DSS assessments and validations.

2. Applicability:

PCI DSS applies to all entities that handle cardholder data (CHD) and/or sensitive authentication data (SAD), including merchants, processors, acquirers, issuers, and service providers. It defines account data as cardholder data and sensitive authentication data.

1.       Cardholder Data: Primary Account Number (PAN), Cardholder Name, Expiration Date, Service Code.

·       PAN: Primary Account Number is a unique payment card number (credit, debit, or prepaid cards, etc.) that identifies the issuer and the cardholder account.

·       Cardholder: Customer to which a payment card is issued, or any individual authorized to use the payment card.

·       Service Code: Three-digit or four-digit value in the magnetic-stripe that follows the expiration date of the payment card on track data. It is used for various things, such as defining service attributes, differentiating between international and national interchange, or identifying usage restrictions.

2.       Sensitive Authentication Data: Full track data (magnetic-stripe data, Card verification code, PINs.

·       Full track data: Full track data is alternatively called full track, track, track 1, track 2, and magnetic-stripe data. Each track contains a few data elements, and this requirement specifies only those that may be retained post-authorization.

·       Card verification code: Also known as card security code, it is the three- or four-digit value printed on the front or back of a payment card and referred to as CAV2, CVC2, CVN2, CVV2, or CID according to the individual Participating Payment Brands.

·       PINs: Login and transaction validation code sometime referred as card pin.

3. PCI DSS and PCI SSC Software Standards:

PCI SSC promotes secure payment software through the Software Security Framework, which includes standards for Secure Software and the Secure Software Lifecycle. Validated software and vendors are listed as compliant with these standards.

·       Validated Software: Payment software listed on the PCI SSC website as a Validated Payment Application (PA-DSS) or Validated Payment Software (Secure Software Standard) has been assessed to meet security requirements. These standards focus on protecting payment transactions and account data.

·       Qualified Software Vendors: The Secure SLC Standard outlines security requirements for software vendors to incorporate secure software development practices throughout their entire software lifecycle. Software vendors that meet the Secure SLC Standard are listed on the PCI SSC website as Secure SLC Qualified Vendors.

Any software handling account data must undergo a PCI DSS assessment. Validated payment software helps with compliance but must be properly configured. Custom software, particularly, needs thorough review due to potential differences. Updating software is essential for security. Following PCI SSC’s standards during development helps prevent breaches and fraud.

·       Applicability to Payment Software Vendors:

PCI DSS applies to a payment software vendor if they store, process, transmit, or access account data as a service provider. This includes roles like payment service providers or those with remote access to customer environments. Relevant vendors include those offering payment services, cloud services, SaaS, e-commerce platforms, and other cloud-based payments.

·       Bespoke and Custom Software:

All bespoke and custom software handling account data or affecting the security of cardholders or sensitive authentication data must be included in a PCI DSS assessment.

Bespoke and custom software developed under PCI SSC’s Software Security Framework standards (Secure Software Standard or Secure SLC standard) helps meet PCI DSS Requirements.

4. Scope of PCI DSS Requirements:

PCI DSS requirements apply to the cardholder data environment (CDE), which is comprised of:

·       System components, people, and processes that store, process, or transmit cardholder data and/or sensitive authentication data.

·        System components that may not store, process, or transmit CHD/SAD but have unrestricted connectivity to system components that store, process, or transmit CHD/SAD.

AND

·       System components, people, and processes that could impact the security of cardholder data and/or sensitive authentication data.

·       System components” include network devices, servers, computing devices, virtual components, cloud components, and software. Examples of system components include but are not limited to:

Systems that are within the scope of PCI DSS requirements include those that store, process, or transmit account data, provide security services, facilitate segmentation, and could impact the security of account data. This includes various network components, virtualization components, cloud infrastructure, end-user devices, printers, and software applications. Additionally, tools for software configuration management and deployment are also covered.

5. Implementing into BAU Processes:

An entity using business-as-usual (BAU) processes in its security strategy ensures that data security controls are correctly implemented and function properly as part of routine operations.

Some PCI DSS requirements function as BAU processes to continually monitor security controls. This helps ensure ongoing compliance between assessments. Although the standard includes some BAU requirements, entities should implement additional processes tailored to their environment. These processes verify that controls work as expected and detect anomalies, alerting responsible individuals to address them promptly.

Examples of how PCI DSS should be incorporated into BAU activities include, but are not limited to:

Assign overall responsibility for PCI DSS compliance and regularly update executive management. Develop performance metrics, monitor security controls, and review logged data frequently. Quickly respond to security control failures with comprehensive processes. Evaluate security risks before implementing changes and review external connections periodically. Confirm third-party software development compliance. Regular reviews ensure ongoing PCI DSS compliance and adherence to processes. Communicate threats and organizational changes effectively. Annually review hardware and software for vendor support and compliance and have remediation plans for unsupported items.

6. Approaches for Implementing and Validating:

There are two ways to implement and validate PCI DSS, allowing flexibility in meeting security objectives. Choose the approach that fits your security implementation best and use it to validate controls. Entities can mix defined and customized approaches to meet different requirements. They might use the defined approach for one system component and the customized approach for another. Thus, a PCI DSS assessment could involve both testing procedures.

1.      Defined Approach:

The traditional PCI DSS method involves implementing security controls to meet requirements and having an assessor verify them using defined testing procedures. The defined approach supports entities with controls in place that meet PCI DSS requirements as stated. This method may benefit those seeking guidance on security goals, including newcomers to information security or PCI DSS.

Compensating Controls as part of the defined approach, entities that cannot meet a PCI DSS requirement as stated due to documented technical or business constraints may implement compensating controls that adequately mitigate the risk of not meeting the requirement. Each year, compensating controls must be documented by the entity, reviewed and validated by the assessor, and included with the Report on Compliance submission.

2.      Customized Approach:

Each PCI DSS requirement focuses on its Objective, allowing entities to meet this through customized controls. As implementations vary, assessors must create appropriate testing procedures to ensure these controls achieve the stated Objective.

The customized approach promotes innovation in security practices, giving entities flexibility to demonstrate how their controls meet PCI DSS objectives. It suits risk-mature entities with strong risk management, such as a dedicated risk department or an organization-wide strategy.

The controls implemented and validated through the customized approach are anticipated to meet or surpass the security standards outlined in the defined approach. Additionally, the level of documentation and effort required to validate these customized implementations will be more extensive compared to those required for the defined approach.

Most PCI DSS requirements can be met using either the defined or customized approach. However, some requirements do not have a Customized Approach Objective and must follow the defined approach.

7. Protecting Information by Security Posture:

The processes related to becoming and maintaining a PCI DSS compliant environment result in many artifacts that an entity may consider sensitive and may want to protect as such, including such items as the following:

·       Compliance Report or Self-Assessment Questionnaire (TPSPs should share their Attestation of Compliance with customers).

·       Network and data-flow diagrams, plus security configurations and rules.

·       System configuration standards.

·       Cryptography and key management methods.

Entities should review all the artifacts related to PCI DSS controls or the assessment and protect them in accordance with the entity’s security policies for this type of information. TPSPs are required to support their customers with the following:

·       Information for customers to monitor TPSPs' PCI DSS compliance status.

·       Evidence that TPSP meets relevant PCI DSS requirements, affecting customer's cardholder data and/or sensitive authentication data security.

8. Protection by QSA Companies

Each Qualified Security Assessor (QSA) Company signs an agreement with PCI SSC that they will adhere to the Qualification Requirements for QSAs. The Protection of Confidential and Sensitive Information section of that document includes the following:

“The QSA company must have and adhere to a documented process for protection of confidential and sensitive information. This must include adequate physical, electronic, and procedural safeguards consistent with industry-accepted practices to protect confidential and sensitive information against any threats or unauthorized access during storage, processing, and/or communicating of this information”.

“The QSA Company must maintain the privacy and confidentiality of information obtained while performing its duties and obligations as a QSA Company, unless (and to the extent) disclosure is required by legal authority”.

9. Testing Methods:

The testing methods specified in the Testing Procedures for each requirement delineate the actions that the assessor must undertake to determine if the entity has met the requirement. Each testing method's purpose is explained as follows:

·       Examine: The assessor evaluates evidence such as documents, screenshots, configuration files, audit logs, and data files.

·       Observe: The assessor watches an action or views something in the environment, such as personnel performing tasks, system functions, environmental conditions, and physical controls.

·       Interview: The assessor engages in a conversation with individual personnel. The objectives of the interview may include verifying whether an activity is performed, describing how an activity is performed, and assessing the knowledge or understanding of personnel.

The testing methods help the assessed entity show compliance with requirements and ensure mutual understanding between the entity and the assessor. The items reviewed or observed, and the personnel interviewed, should align with the specific requirements and the entity's implementation. The assessor must document the assessment activities and outcomes in detail.

10. Compliance:

Instructions and content for the Report on Compliance (ROC) are provided in the PCI DSS Report on Compliance (ROC) Template.

The PCI DSS Report on Compliance (ROC) Template must be used as the template for creating a PCI DSS Report on Compliance.

Compliance with PCI DSS is determined by payment brands and acquirers. Entities should contact these organizations to report requirements and instructions.

11. Assessment Process:

The PCI DSS assessment process includes the following high-level steps: 5

• Confirm the scope of the PCI DSS assessment.
• Perform the PCI DSS assessment of the environment.
• Complete the applicable report for the assessment according to PCI DSS guidance and instructions.
• Complete the Attestation of Compliance for Service Providers or Merchants, as applicable, in its entirety. Official Attestations of Compliance are only available on the PCI SSC website.
• Submit the applicable PCI SSC documentation and the Attestation of Compliance, along with any other requested documentation, such as ASV scan report to the requesting organization (those that manage compliance programs such as payment brands and acquirers (for merchants), or other requesters (for service providers).
• If required, perform remediation to address requirements that are not in place and provide an updated report.

12. Benefits:

PCI DSS compliance can benefit businesses in many ways, including:

• Protecting cardholder data: PCI DSS helps prevent unauthorized access to cardholder data by using strong cryptography to protect data in transit. 
• Reducing the risk of data breaches: PCI DSS helps organizations address common weaknesses that attackers exploit. 
• Building customer trust: Customers are more aware of data security issues and are more likely to prefer businesses that take data protection seriously. 
• Preventing regulatory errors: PCI DSS compliance can help organizations avoid regulatory errors and the consequences that come with them. 
• Increasing conversion rates and customer loyalty: PCI DSS compliance can help businesses build customer trust and confidence, which can lead to increased conversion rates and customer loyalty. 

• Maintaining an information security policy that guides employees, contractors, and partners on how to keep a secure payment environment.
• Restricting access to system components and cardholder data based on business need-to-know.
• Implementing strong access control measures, such as assigning a unique identifier to each person with computer access.
• Maintaining a vulnerability management program that includes regular updates and security patches.
• Regularly monitoring and testing networks to track and monitor all access to network resources and cardholder data.