PCI Software Security Framework (SSF)

What you need to know about the new PCI-SSF


PCI Software Security Framework OVERVIEW

What is PCI-SSF?


The Payment Application Data Security Standard Version 3.2 (PA-DSS v3.2) has been formally retired and replaced by the PCI-SSF (Secure Software Standard). 

The SSF provides vendors with security standards for developing and maintaining payment software so that it protects payment transactions and data, minimizes vulnerabilities, and defends against attacks. It includes a new methodology for validating software security and a separate secure software lifecycle qualification for vendors with robust security development practices. 

The SSF is comprised of the Secure Software Standard (SSS) and the Secure Software Lifecycle (Secure SLC) Standard. 

 

 

WHAT IS THE PCI-SSF PROGRAM TIMELINE?


The Payment Application Data Security Standard (PA-DSS) program is officially closed 


SSF Program Timeline:

  • Program Documentation Available: Program Guides, Qualification Requirements for SSF Assessors, Reporting Templates, and FAQs are now available on the PCI SSC website..

  • Programs Open for SSF Assessors: Programs Open for SSF Assessors: PCI SSC began accepting SSF Company applications in October 2019.

  • Training Available: Training began in early 2020, first for PA-QSAs and QSAs, and then for new assessors.

  • Programs Open for Vendors: Programs Open for Vendors: Assessments began in Q2 2020.

  • PA-DSS Program Closes: All PA-DSS v3.2 validations have been moves\d to the “Acceptable Only for Pre-Existing Deployments” tab on the PA-DSS listing. 

 

 

Related Resource: Why the Time is Now for CISOs to Advocate for Cybersecurity

 

Back to content menu  ^


Difference Between PCI-SSF vs. PA-DSS

What is PA-DSS? How does it differ from PCI-SSF?


PA-DSS or Payment Application Data Security Standard was developed explicitly to facilitate PCI DSS compliance for entities implementing payment applications in a cardholder data environment. The SSF was developed with broader applicability in mind and covers a broader range of security topics and data assets than PA-DSS and PCI DSS. The SSF is also intended to apply to payment software and software vendors regardless of whether PCI DSS applies to the environment in which the payment software is deployed. 

For these reasons, the security requirements in the SSF standards do not map directly to PCI DSS requirements like the PA-DSS requirements do. With that said, the SSF security standards still support an entity’s PCI DSS compliance by enabling entities who use qualified software vendors and/or validated payment software to potentially meet some PCI DSS requirements without the need for additional detailed testing. See the chart below for a breakout: 

 

ssf-ppt-8

ssf-ppt-7

 

Modules are groups of requirements that address specific use cases and will be a primary difference between the two standards. 

More modules will be released in the future, accommodating any necessary updates that may arise, but currently, there are two modules in the PCI Secure Software Standard:

  1. The “Core” module includes general security requirements applicable to all payment software

  2. The “Account Data Protection” module includes additional security requirements for payment software that stores, processes or transmits clear-text account data.

 

 

Why is the PCI-SSF update important?


The PCI Secure Software Standard expands on the key principles of protecting payment applications and data, that were first introduced in PA-DSS, and is designed to support a much larger set of payment software architectures, functions, and software development methodologies. For that reason, there are a host of additional benefits that are offered as a result. They include: 

  • Greater diversity of software that can be assessed than was previously available

  • More agility for modern development techniques and release cycles

  • Consistency in the use of software security across all PCI standards

  • Increased transparency of interim software updates

  • Increased flexibility and accountability for software vendors in the achievement of PCI software security objectives

  • More emphasis on education within the software development community on the importance of payment security 


Defining the Culture of Security

What security measures should a vendor have in place?


The SSS (Secure Software Standard) defines the security features and attributes that payment software must possess, and the SLC (Secure Software Lifecycle) defines the security processes and capabilities that a software vendor must have in place to ensure its software is developed securely.

  • Software Security Governance: A formal software security governance program is established to reflect the vendor’s commitment to building secure software and protecting any sensitive data and resources stored, processed, or transmitted by the software. 

  • Secure Software Engineering: Payment software is designed and developed to protect critical software assets and to be resistant to attacks. 

  • Secure Software and Data Management: The confidentiality and integrity of the software and its critical assets are maintained throughout the software lifecycle. 

  • Security Communications: The vendor provides timely information to its stakeholders—including customers, installers, and integrators— regarding security issues affecting its software, and thorough guidance on secure software implementation, configuration, operation, and updates. 

 

Related Resource: Why (and How) Company Leadership should create a culture of Security Collaboration

CMMC 2.0 LEVEL 1: FOUNDATIONAL
(PREVIOUSLY CMMC 1.0 LEVEL 1)

 

Total Controls: 17

CMMC Practices / Requirements: The minimum CMMC certification level requires basic cyber security measures and only requires that processes are performing, at least in the ad hoc manner. The 17 controls, or practice requirements, are equivalent to the 15 practices in Federal Acquisition Regulation (FAR) 48 CFR 52.204-21, and are also equivalent to 17 practices drawn from NIST SP 800-171 Rev 1.

CMMC 2.0 LEVEL 2: ADVANCED
(PREVIOUSLY CMMC 1.0 LEVEL 3)

 

Total Controls: 130

CMMC Practices / Requirements: A level 2 CMMC certification requires that an organization must maintain and resource a plan encompassing all stated activities.

There are a total of 130 controls at level 2, which includes the coverage of all practices from NIST SP 800-171 Rev 1, and 20 additional practices protecting controlled unclassified information (CUI) and ensuring cyber security methodologies are moderately resilient and comprehensive.  

CMMC 2.0 LEVEL 3: EXPERT
(PREVIOUSLY CMMC 1.0 LEVEL 5) 

 

Total Controls: 171

CMMC Practices / Requirements: Level 3 requires prioritized acquisitions that would require independent assessment and non-prioritized acquisitions that would require annual self-assessment and annual company affirmation”

CMMC Level 3 will only require the controls in NIST SP 800-172.

This aligns CMMC with other regulations which require NIST SP 800-171. For example, a Federal level notice from ISOO states that only NIST SP 800-171A will be used for the assessment of non-federal organizations holding CUI.


How Avertium Can Help with Your PCI Software Security Framework

Avertium is one of only 47 out of the 385 QSA companies certified to perform Secure Software Standard and Secure SLC Standard assessments. Our experts are Secure Software Assessors who have earned the PCI Council’s rigorous security, audit, and penetration testing certifications. 

Avertium offers two related services – Secure Software Standard assessment and Secure SLC Standard assessment:

  1. Secure Software Standard provides security requirements for building secure payment software to protect the integrity and confidentiality of sensitive data that is stored, processed, or transmitted in association with payment transactions. 

    Avertium builds a test environment and tests software against PCI defined and standardized best practices to ensure it is secure and well-documented from installation to operation. We follow published standards to complete reporting templates as dictated by PCI Council. 

  2. Secure SLC Standard is intended for vendors that are developing payment software that supports or facilitates payment transactions. The Secure SLC Standard provides security requirements for payment software vendors to integrate security throughout the entire software lifecycle, which results in software that is secure by design and able to withstand attacks. 

    Validation to the Secure SLC Standard illustrates that the software vendor has secure software lifecycle management practices in place to ensure its payment software is designed, developed, and maintained to protect payment transactions and data, minimize vulnerabilities, and defend against attacks. 

    Vendors who produce software that is ineligible for validation to the Secure Software Standard can demonstrate good software security hygiene through independent Secure SLC validation. 

    Range of in-house services to provide holistic PCI solutions. PCI Compliance as a Service, Penetration testing, ASV scanning, MSS, DFIR capabilities, etc. 

 

Why should you choose Avertium as your partner?

  • No Fines or Delays: Since Averitum is a Secure Software Assessor we are able to help transition organizations through the various compliance requirements, insuring certification and allowing them to continue to do business without fines or delay.

  • Your Peace of Mind: Our rigor ensures security and provides developer peace of mind. 

  • Your One-Stop-Shop: Our ability to be a one-stop-shop for services ranging from DFI to MDR, and from Threat Hunting as a Service to SLC assessment, provides us a competitive advantage our customers have come to expect. 

  • Your Trusted Experts: We are among the companies listed by PCI Counsel on PCI website as an approved software vendor. 

 

Back to content menu  ^

Find Out More About All Our Services 

CYBERSECURITY STRATEGY

THREAT DETECTION + RESPONSE

ATTACK SURFACE MANAGEMENT

GOVERNANCE, RISK, + COMPLIANCE