What are the 12 Core Control Objectives of PCI SSF?

Many organizations that previously needed to comply with the PCI PA-DSS now need to comply with the PCI SSF. This compliance involves meeting twelve security control objectives, along with requirements for one or more modules depending on the specific kinds of payment software developed or sold.

Is your organization prepared for full PCI compliance? Schedule a consultation to find out.

 

Understanding Core Components of the PCI SSF

The Payment Card Industry Software Security Framework (PCI SSF) applies to developers, vendors, and other stakeholders involved in the development and deployment of payment software. It outlines specific security controls these organizations must follow to protect sensitive data and maintain software integrity.

The core controls and requirements for PCI SSF compliance differ depending on context:

• All PCI SSF-eligible organizations need to implement the 12 foundational Control Objectives
• Certain organizations must also implement Objectives from one or more Modules

Working with a quality PCI advisory organization is the best way to streamline the process.

 

The PCI SSF Core Control Objectives

The core of the PCI SSF is a set of 12 Control Objectives applicable to all software developers and vendors involved with payment software. PCI compliance for these organizations requires implementing these controls and assessing their efficacy with a PCI-approved audit provider.

The 12 Control Objectives are distributed across four overarching core requirements.

 

 

Core Requirement 1: Minimizing the Attack Surface

The first three PCI standards in the SSF break down as follows:

• Control Objective 1: Critical Asset Identification – 

• • • 1.1: Identify sensitive data stored, processed, or transmitted
    • 1.2: Identify sensitive functions used/provided by the software
    • 1.3: Classify all critical assets impacted by the software

• Control Objective 2: Secure Defaults – 

• • • 2.1: Only enable function exposure by default when needed
    • 2.2: Enable security features upon installation or first use
    • 2.3: Delete default authentication credentials after first use
    • 2.4: Limit privilege requests by operational necessity
    • 2.5: Limit default privileges for built-in accounts

• Control Objective 3: Sensitive Data Retention – 

• • 3.1: Limit data retention to the minimum necessary
  • 3.2: Retain transient data for the minimum duration necessary
  • 3.3: Protect confidentiality and integrity of retained data
  • 3.4: Securely delete data when it is no longer required
  • 3.5: Automatically delete data in temporary storage when not needed
  • 3.6: Prohibit disclosure of data through unintended channels

 

Core Requirement 2: Software Protection Mechanisms

The next set of controls stipulates more specific safeguards, including: 

• Control Objective 4: Critical Asset Protection – 

• • • 4.1: Identify attack scenarios applicable to the software
    • 4.2: Implement controls to mitigate software attacks

• Control Objective 5: Authentication and Access Control – 

• • • 5.1: Authenticate access to critical assets
    • 5.2: require unique identification for access
    • 5.3: Utilize strong auth protocols to prevent compromise
    • 5.4: Restrict access according to necessity by default

• Control Objective 6: Sensitive Data Protection – 

• • 6.1: Secure sensitive data wherever it is stored
  • 6.2: Secure sensitive data for transmission
  • 6.3: Use cryptography per Control Objective 7 specifications 
• Control Objective 7: Use of Cryptography – 
  • 7.1: Use industry-standard cryptographic methods to secure data
  • 7.2: Support industry-standard cryptography across software
  • 7.3: Use only industry-standard random number generation (RNG)
  • 7.4: Ensure RNG values have sufficient entropy per keys’ needs

 

Core Requirement 3: Secure Software Operations

These controls ensure safe operations with incident monitoring:

• Control Objective 8: Activity Tracking – 

• • • 8.1: Trace all access and use of critical access to unique users
    • 8.2: Capture relevant activity in sufficient descriptive detail
    • 8.3: Support secure retention of detailed activity records
    • 8.4: Preserve the integrity of records when addressing failures

• Control Objective 9: Attack Detection – 

• • 9.1: Detect and alert on anomalous behavior

 

 

Core Requirement 4: Secure Software Lifecycle Management

The last of the core controls cover the security development lifecycle with:

• Control Objective 10: Threat and Vulnerability Management – 

• • • 10.1: Identify, assess, and address threats and vulnerabilities
    • 10.2: Test for and fix vulnerabilities prior to release

• Control Objective 11: Secure Software Updates – 

• • • 11.1: Provide timely updates to fix known vulnerabilities
    • 11.2: Deliver updates securely to preserve code integrity

• Control Objective 12: Vendor Implementation Guidance – 

• • 12.1: Provide guidance on secure implementation and operation

Additional PCI SSF Module Objectives

Beyond the core objectives that apply to all organizations eligible for PCI SSF compliance, there are three modules applicable to specific kinds of payment software integrations. For developers and vendors involved in these kinds of software, these objectives are as fundamental as the 12 core objectives above. For others, they are still important to be aware of for future reference.

 

Module A: Account Data Protection Requirements

These requirements apply to software that comes into contact with specific protected data:

• Control Objective A.1: Sensitive Authentication Data (SAD) Protection – 

• • • A.1.1: Store SAD after auth only for issuer use in supported services

• Control Objective A.2: Cardholder Data (CHD) Protection – 

• • A.2.1: Provide guidance on secure deletion after required retention periods
  • A.2.2: Restrict display of primary account numbers (PAN) to the minimum
  • A.2.3: Render PAN unreadable via truncation, tokens, or cryptography

 

Module B: Terminal Software Requirements

The following requirements apply to developers and vendors of terminal software:

• Control Objective B.1: Terminal Software Documentation – 

• • • B.1.1: Maintain documentation describing components, interfaces, and services
    • B.1.2: Maintain documentation describing sensitive data flows and functions
    • B.1.3: Maintain documentation describing configurable options for sensitive data

• Control Objective B.2: Terminal Software Design – 

• • • B.2.1: Design software for operation on PCI-approved terminals
    • B.2.2: Limit communication by PIN transaction security (PTS) evaluation
    • B.2.3: Disallow bypass of encryption methods related to vendor policies
    • B.2.4: Use only RNG functions included in a terminal’s PTS evaluation
    • B.2.5: Disallow clear-text sharing of account data with other software
    • B.2.6: Use and integrate shared resources per vendor security policies
    • B.2.7: Disallow bypass of app segregation enforced by the terminal
    • B.2.8: Sign software files cryptographically for terminal authentication
    • B.2.9: Protect the integrity of prompt files per Control Objective B.2.8

• Control Objective B.3: Terminal Software Attack Mitigation – 

• • • B.3.1: Validate all user inputs and all other external inputs
    • B.3.2: Check return values and handle error corrections securely
    • B.3.3: Avoid race conditions across terminal software

• Control Objective B.4: Terminal Software Security Testing – 

• • • B.4.1: Systematically test for vulnerabilities prior to updates

• Control Objective B.5: Terminal Software Implementation Guidance – 

• • B.5.1: Provide implementation and operation guidance to adopters
  • B.5.2: Ensure guidance adheres to vendors’ own security policies

 

 

Module C: Web Software Requirements

These requirements apply to developers and vendors of web-based payment software:

• Control Objective C.1: Web Software Components and Services – 

• • • C.1.1: Document components and services in software bill of materials (SBOM)
    • C.1.2: Describe uses along with relationships, and dependencies in the SBOM
    • C.1.3: Describe all “as a service” (SaaS) dependencies to the extent possible
    • C.1.4: Include adequate detail to enable tracking across software supply chains
    • C.1.5: Generate a new SBOM each time the software is updated
    • C.1.6: Monitor and manage vulnerabilities per Control Objective 10
    • C.1.7: Verify the authenticity of third-party hosting components

• Control Objective C.2: Web Software Access Controls – 

• • • C.2.1: Authenticate access to sensitive functions through internet interfaces
    • C.2.2: Restrict access to internet interfaces to authorized users only
    • C.2.3: Restrict access to internet-exposed functions to authorized users only

• Control Objective C.3: Web Software Attack Mitigation – 

• • • C.3.1: Enforce or support the use of current HTTP Security Headers
    • C.3.2: Distrust and disallow input data from untrusted sources
    • C.3.3: Implement controls to prevent resource starvation attacks 
    • C.3.4: Implement controls to protect against malicious file content
    • C.3.5: Implement controls to protect against data tampering
    • C.3.6: Implement controls to prevent multi-origin resource sharing

• Control Objective C.4: Web Software Communications – 

• • C.4.1: Encrypt communications per Control Objectives 6.2 and 6.3

 

Optimize Your PCI SSF Compliance Today

If your organization is seeking PCI certification to develop or vend payment software, you’ll need to implement most or all of the controls specified above. Then, you’ll need to assess them. RSI Security is a Qualified Security Assessor (QSA) and Approved Scanning Vendor (ASV) with a long history of PCI advisory. We help organizations like yours optimize your compliance.

At RSI Security, we know that the right way is the only way to keep you, your clients, and their clients safe. To learn more about our PCI SSF services, contact RSI Security today!

 

Discover how RSI Security can help your organization. Request a complimentary consultation: