In 2020, the PCI SSC released the Software Security Framework. This post is a brief explanation of how the framework is structured, some key dates and pointers on how this will impact you, and how to prepare.
The Framework consists of two different and independent programs each of which has its own standard, validation criteria and SSC listing. These are:
- The Secure Software Lifecycle Program referred to as the Secure SLC
- The Secure Software Standard
Note that this Framework replaces the Payment Application Data Security Standards (PA-DSS) program. If you have PA-DSS validated applications, here are some key points to bear in mind.
- New PA-DSS submissions will be accepted until 30 June 2021The list of PA-DSS validated applications will be set to “Acceptable Only for Pre-Existing Deployments”, once the PA-DSS program is retired on 31 October 2022
If you are working on a new application or wish for an application’s compliance status to endure beyond October 2022, you should be validating the application to the requirements or security and control objectives within the Secure Software Standard.
What is the difference between the Secure SLC and the Secure Software Standard?
While both provide a three (3) year validation period they focus on different aspects of Software Security.
The Secure SLC Standard validates the security controls and practices with your software design and execution methodology. As such, we are validating processes, policies and procedures - this is not a technical review.
The Secure Software Standard, on the other hand, is a review of the overall security of a specific piece of software.
This means that, as an organization, you could be validated for having a Secure Software Lifecycle and you could have separate Secure Software Standard validations for each payment software you develop.
Does the company that validates a payment software under the Secure Software Standard also require validation against the Secure Software Lifecycle Standard?
Your organisation/company does not need to be validated under the Secure SLC Standard to have your software validated. Having the Secure SLC validation, however, can simplify the process of maintaining the validation of your payment software when making changes. I’ll explain this a little.
The Secure Software Framework does not allow the use of wildcards. Any changes made to payment software will be high impact (if affecting sensitive assets – i.e. data, functions or resources) or low impact.
If you are Secure SLC validated, you can make low impact changes and submit the relevant documentation to the SSC to update the software version listing, without paying fees.
If you are not Secure SLC validated, these low impact changes must be reviewed by an assessor who must complete associated documentation and submit to the SSC on your behalf and each change requires you to pay a fee.
All the above raises a couple of other questions
- What software can be assessed and validated under the Secure Software Standard?
- What does an assessment look like?
What software can be assessed and validated under the Secure Software Standard?
Payment software that stores, processes, or transmits clear-text Account Data, intended to be installed on customer systems as well as payment software deployed to customers ‘as a service’ over the Internet.
What does an assessment look like?
First, I’ll show you what the standard looks like. The standard is split into 4 security objectives, each of which have control objectives. Here we go…
Security Objective: Minimizing the Attack Surface
Control Objective 1: Critical Asset Identification
Control Objective 2: Secure Defaults
Control Objective 3: Sensitive Data Retention
Security Objective: Software Protection Mechanisms
Control Objective 4: Critical Asset Protection
Control Objective 5: Authentication and Access Control
Control Objective 6: Sensitive Data Protection
Control Objective 7: Use of Cryptography
Security Objective: Secure Software Operations
Control Objective 8: Activity Tracking
Control Objective 9: Attack Detection
Security Objective: Secure Software Lifecycle Management
Control Objective 10: Threat and Vulnerability Management
Control Objective 11: Secure Software Updates
Control Objective 12: Vendor Security Guidance
In addition to the above there are specific security modules. At present there is only the below but this will be increased:
Module A – Account Data Protection 2
Security Objective: Account Data Protection
Control Objective A.1: Sensitive Authentication Data
Control Objective A.2: Cardholder Data Protection
In order for an assessor to validate the above objectives, the business must demonstrate documentation, processes and evidence showing the scope of each subject area in relation to their software and show the processes involved in measuring exposure and mitigating risk. You may notice from the language used that this is very much a risk-focused exercise. If you’re used to the prescriptive nature of PA-DSS, you may be in for a surprise!
What’s next?
While there is not the space here to exhaustively cover the standards and validation methodologies, this post will be followed by a post which will illustrate the assessment process. This should provide some guidance so, if you’re reading through the objectives and validation process, you can consider how to demonstrate your implementation.
Also, consider reading our ‘The PCI Software Security Framework (SSF) is taking off!’ blog post.
Get in touch
Foregenix has developed an agile methodology to accelerate your transition from PA-DSS to SSF Standards validation. Discover the portfolio of solutions that we have prepared to help you certify your processes or your payment software.
Subscribe to our Blog
