PCI S3: The Future of Payment Software Security
This month (Jan 2019) PCI released their long in the works Software Security Standards onto their website. I say ‘long in the works’ as an update to PCI software assessment standard has been coming for some time now .. it was initially mooted during 2017 prior to the Community Meetings, and so it’s arrival should not be a surprise to anyone in the payment industry. However, what may be of interest (to both the payment and software development communities at large) is that there are actually two documents that have been released – the Secure Software Lifecyle (Secure SLC) Requirements, and the Secure Software Requirements and Assessment Procedures – as part of an overall software assessment framework, and understanding how these documents interact and work together to drive secure software development into the future.
The Source Codes Apprentice
So how did one software standard become two? Both of these standards are written to create what is referred to as the PCI Software Security Framework (that is, individually they are standards, and collectively they are part of the framework), and they address two very distinct aspects of software security.
The Secure SLC Requirements (SSLC) are designed to provide an assessment of the vendors software development processes, to ensure that security is ‘baked in’ throughout the process from design to on-going maintenance. This is an over-arching standard, not designed to be assessed against individual software products, but instead against the policy, procedures, and processes that are used to develop all (in-scope) software within that company.
The Secure Software Requirements and Assessment Procedures (SSRAP) document, on the other hand, does put forward requirements for the security assessment of individual software products. This standard considers individual aspects of software security for such products, and outlines testing procedures to validate those aspects.
Both of these standards also address the specifics of risk; why it’s important to embed risk assessment into software development, what to include when you do this, and how the methodology used can be assessed. Expect ‘risk based approach’ to become the new hotness for PCI during 2019.
First, Know Thy Self
Unfortunately, secure software is not produced by accident – it requires diligence and expertise to ensure that the risks are understood and accommodated for. This is the purpose of the Secure SLC Requirements, to provide clear definitions around what processes a company must have to ensure they are able to produce secure software. The standard considers four high level aspects, with additional subordinate control objectives:
Software Security Governance
- Security Responsibility and Resources
- Software Security Policy and Strategy
Secure Software Engineering
- Threat Identification and Mitigation
- Vulnerability Detection and Mitigation
Secure Software and Data Management
- Change Management
- Software Integrity Protection
- Sensitive Data Protection
- Vendor Security Guidance
- Stakeholder Communications
- Software Update Information
By validating the items above, it can be confirmed that the software vendor has a sufficiently documented, thorough, and robust process for any software it develops. Although this does not speak to the specifics of any individual software product, it does allow for some leeway in the way in which software updates are managed and assessed (but more on that later).
When we start to look at individual software products, we need different requirements to outline the specific security controls and considerations that must be included; this is the intent of the Secure Software Requirements and Assessment Procedures. However, given the diverse nature of software that may be covered by this standard, how does one document provide for the full breadth and depth of security required? The simple answer is it does not! The current SSRAP document is considered the start of a broader set of requirements that may be created to cover new software under this standard – it outlines the ‘core’ requirements of payment software, but this may be added to over time as specific aspects or features of software need to be considered.
Currently the SSRAP document provides for four high level aspects, once again with subordinate control objectives (and this time also an Appendix!):
Minimizing the Attack Surface
- Critical Asset Identification
- Secure Defaults
- Sensitive Data Retention
Software Protection Mechanisms
- Critical Asset Protection
- Authentication and Access Control
- Sensitive Data Protection
- Use of Cryptography
Secure Software Operations
- Activity Tracking
- Attack Detection
Secure Software Lifecycle Management
- Threat and Vulnerability Management
- Secure Software Updates
- Vendor Security Guidance
Module A – Account Data Protection
A.1) Sensitive Authentication Data
A.2) Cardholder Data Protection
Looking at the above you can start to envisage the methodology the standard is taking; identify the assets and potential security issues, confirm that each of these items is mitigated or secured in some way through the software design, and then ensure there is an on-going program for maintaining the software over time as well as informing the users of the software on how to use it securely.
Interestingly, looking at the brief description above and the fact that there is then a separate module defining the specifics for “Account Data Protection” which defines the base assets in payment software, you may note that this standard is actually quite generic – in the sense that the requirements and tests could be applied to any software, not ‘just’ payment software.
Pay it Forward
This unbundling of the actual ‘payment’ aspect from the assessment standard itself is quite deliberate, and ensures that this standard can be modularized and applied to different types of software moving forward. Does this mean PCI is elbowing its way into non-payment areas? No, the intent is that we don’t really know what ‘payments’ will be like 5 or 10 years from now, and vulnerabilities that exist in payment software can often be exactly the same vulnerabilities that exist in non-payment software. So, it makes sense to create this generic, overarching assessment framework which can be bent to the will of specific areas as required.
This has two main implications:
- It can be expected that there will be new modules and contexts added to this standard as required over time, or that the standard itself will be leveraged by other PCI standards into the future.
- If you’re in the business of developing (or assessing) software, this remains a great tool to use to validate that you’re doing the right things from a security point of view – even if the software you are developing is not specifically (or at all) payment related.
If you look at the different PCI standards, you see that there has traditionally been a somewhat disharmonious approach to software security – there are software security requirements in PCI PTS, PCI DSS, and a whole software assessment module in PCI SPoC. Although it’s still early days, it’s reasonable to expect that this software security framework (and now I’m talking about one or both of the current standards under this framework) may be applied to these areas to provide a more harmonious and consistent approach to software assessment throughout the PCI landscape.
Get with the Program
So, what to expect into the future for the PCI Software Security Standards? Those of you familiar with PCI may notice that of the three documents currently released, there remains a lack of a ‘Program Guide’ which is generally used to outline the management and process aspects of any new PCI standard. This can be expected to appear in due course, but some indications of what this may have inside already exist. In the FAQ document that has been released, PCI state:
Q6 Who will be qualified to perform assessments to the Secure Software Standard?
A PCI-qualified Secure Software Assessor Companies and their employees. PCI Secure Software Assessor (SSA) Companies are independent security organizations that have been qualified by PCI SSC to validate payment software adherence to the Secure Software Standard. Secure Software Assessors are employees of SSA Companies that have satisfied and continue to satisfy all requirements of the SSA program.
So, another PCI program will be produced with its associated accreditations and requirements for assessors. It’s also noted in the FAQ that assessment of an organization against the SSLC requirements may be used to reduce the requirements for on-going delta assessments when changes are inevitably made to the software product over time – this is a great move, IMHO, and something that has been a point of discussion and contention in many of the other security programs I’ve worked in over the years. Full kudos to PCI for moving in this direction (although the first time this happened was actually in the PCI HSM standard … but that’s for another day).
What does this all mean if you have PA-DSS approved software right now? Well, right now it does not mean that much – the program is yet to be released as noted. However, PCI are talking about phasing out the PA DSS program sometime into the future, as also noted in the FAQs:
New PA-DSS validations will be accepted through mid-2020 and be valid through late 2022. Assessments against the PCI Software Security Framework are anticipated to begin in Q3 2019 and will have a three-year validity period, putting the expiry date of those validations at roughly the same expiry date as PA-DSS validations.
So, no reason to panic just yet. But given the general development times for software, PCI PA-DSS or PCI Software Security is something that you should be undertaking right now if you have something you’re working on but not yet released. Also, transition plans are worth considering as well at this point for existing software.
Needless to say, as one of the contributors to the standard and a member of the PCI Global Executive Assessor Roundtable (GEAR), UL can assist you with both understanding this new standard, as well as helping with your plans to accommodate for this in your development roadmaps.