Prepared by
Adam Perella, Senior Security Consultant, NCC Group
Introduction
The Software Security Framework (SSF) was created by the PCI Software Security Council as an evolution of the Payment Application Data Security Standard (PA-DSS). The framework is a more functional approach to evaluating the security of vendors and payment software, as it provides an objective-based approach with modular standards for the assessment of software development practices and products. This differs from the requirement-based approach where vendors are required to provide evidence and build documentation for meeting an inflexible list of standards.
The shift to an objective-based standard allows vendors to assess their payment application and how security controls and configurations can be used to meet the intent of the control. The broader approach accounts for a more descriptive assessment instead of prescriptive while demonstrating the secure operations of software and secure coding. The new standards are also more inclusive of the types of applications that can be assessed and listed.
Before initiating such a vendor assessment or payment application review, it is important to understand the differences in the two standards, the amount of review involved, and the assessment process. Vendors should understand the relationship between the two standards in the framework, how the content applies to their development practices, and what is performed during testing. In doing so, organizations will be better prepared to go through the framework as a vendor or have their payment software validated.
A tale of two standards
A new element to those familiar with PA-DSS is the use of two standards, one for the vendor's software development lifecycle, and another for the payment software. The Secure Software Lifecycle (SLC) standard consists of a set of security objectives that provide common requirements across software development organizations. The Secure Software Standard (SSS) is further divided into Core requirements, with a module specific to applications that store, process, or transmit cardholder data.
A software vendor may select to be assessed against one or both of the standards to fit their organization's needs. One major advantage is that development organizations that deploy a variety of applications (which may not actually be sold or licensed to other companies) can demonstrate their abilities by validating solely to the SLC standard, as long as the result is an application that fits a broad range of product categories. The choice of what to validate and comply with should not be taken lightly because of the time and resources required to demonstrate compliance with the standard.
Additionally, if an organization is assessed against both, they can self-assess delta or low-impact changes. If an organization has an application assessed but is not an SLC vendor, then the company that performed the software assessment will need to review the change and likely perform a subset of testing before providing a redlined report on validation to the PCI SSC for review. This is a significant change from PA-DSS, as it permits greater autonomy for organizations that undergo a review of standards.
The process flow diagrams below, included in the Software Security Framework Program guide, provides a visual depiction of how these two standards relate.
Determining which applications can be assessed against the SSF
Section 5.1 of the Secure Software Program Guide, found in the PCI SSC’s Documentation Library, defines the two
conditions for eligibility. It states that software products must be:
• Involved in or directly supporting or facilitating payment transactions that store, process, or transmit clear-text
account data
• Developed by the vendor and commercially available for sale to multiple organizations
Software products must be involved in or directly supporting or facilitating payment transactions that store, process, or transmit clear-text account data.
Simple enough, but let’s investigate these two points: Regarding the storage, processing, or transmission of cleartext cardholder data, this means that a point-of-sale (POS) system which includes an attached P2PE terminal would not be eligible because it would not have access to cleartext cardholder data and unable to impact the security of cardholder data. Conversely, it means that software which performs a partial function can be assessed as middleware.
Software products must be developed by the vendor and commercially available for sale to multiple organizations.
The software must be developed for commercial sale and cannot be a bespoke application or only used internally by the vendor. If it could be sold off the shelf to a general customer, it fits the bill here.
This is why the SSF is more inclusive than the PA-DSS. While the focus is largely the same, the Software Security Framework accounts for a larger array of software and the PCI SSC plans to include more over time. Future modules may be added to the Software Security Standard that may apply to other types of payment application areas.
Application types
While the Secure Software Program Guide defines 12 unique types of payment applications (which will be a part of the PCI SSC’s listing), the four most common are POS Suite/General, Face-to-face POS/POI, payment middleware, and payment gateway/switch. Under the PA-DSS, these four types make up almost 65% of payment applications acceptable for new deployments.
- POS Suite or General. The most common type of payment application, POS Suite/General serves multiple payment channels including (but not limited to) in-person transactions, manually entered ecommerce, and those used by call centers.
- Face-to-face POS or POI. This type is meant only for in-person transactions on a hardware terminal or system.
- Payment middleware. This type applies to software which facilitates the transmission and/or processing of transactions and is most often sold to customers who will include the middleware within their own software or payment application. It is important to note that a payment application can utilize PA-DSS validated middleware as a part of its own validation.
- Payment gateway/switch. This type is intended for third parties to facilitate transactions between merchants and processors
Understanding assessment processes
Software Security
1. Scoping a payment application for validation
A validation process starts by determining what will be reviewed, in other words, determining the scope of the project. This is a collaborative step involving the software vendor and the Secure Software Assessor, and includes a review of data flows, operating systems, dependencies, customer communications, the vendor software development process, and details which can impact the security of cardholder data.
Next, a review of the supported data flows and communications will provide valuable details for how the software functions, in addition to identifying dependencies and software components. The review should be detailed and identify how different elements of cardholder data are handled. The following examples highlight the level of detail necessary.
Web API
A web API that receives card-not-present data will include the 16-digit PAN and likely include the printed card value (CVC, CVV2, CID). If no cardholder data is stored, the data flow will describe how the card data is handled in memory, potentially parsed, and transmitted to processors. The scope would include the web server, internal communications, dependencies, and transmission to the processor.
Point-of-sale kiosk
An unattended point-of-sale kiosk with a built-in card reader that supports chip, swipe, and contactless and stores cardholder data until batch authorization. Consider this a standalone POS where users can perform transactions without their own staff being involved. Common examples are parking terminals or bill pay kiosks found in government buildings. The review would include elements of data received by the application, how that data is handled, parsed, encrypted, and stored in a database. The scope would include the card reader, hardware housing the kiosk, the database, internal communications between those elements, and transmission to the processor.
2. Providing written guidance for customers
This is the step referred to as an Implementation Guide under PA-DSS. The documentation provided to customers will need to include any details for the secure installation and operation of the software and its dependencies. The intent of the written guidance is for customers to have comprehensive information to configure and maintain the payment application, even if it is the responsibility of the customer and not the vendor. This does not mean that vendors must account for individual scenarios, but they do need to explain authentication, logging, updates, remote access, and other details necessary to correctly use the software in a manner that supports the end-user’s compliance with the PCI DSS.
3. Reviewing software development processes
Outside of the payment application, software development processes are reviewed. The review includes the policies and procedures used to perform threat management, secure coding, developer training, change control, application testing, and application updates. An effective software development process demonstrates that a vendor incorporates secure coding practices into the creation of the payment software and performs testing to identify and address vulnerabilities. While a comparatively shorter section in the standard, there is a lot of ground to cover for a vendor that identifies the ongoing measures performed in keeping the software secure and current.
4. Keeping the customer informed
Customers must be informed of updates, threats to the software (including dependencies), and how to report issues back to the vendor. A fairly direct section within the standard identifies how vendors interact with their customers, troubleshoot issues raised, and actively disseminate details relevant to the secure operation of the payment software.
5. Identifying vulnerabilities within the software
The testing by the Secure Software Assessor will emulate real-world scenarios. This involves the installation of the payment application in the laboratory following the written guidance and testing against that system for vulnerabilities.
This phase sets to identify vulnerabilities present within or presented by the payment software. Apart of the testing, a forensic image is acquired to identify the exposure of sensitive data, including credit card data, authentication credentials, or key material. A testing report with findings and recommended fix actions is provided back to the vendor. Retesting is performed until issues are corrected.
The PCI SSC’s listing will only include the systems which were included as a part of the testing process. While additional operating systems – even similar ones - can be supported by the software, the review of customer-facing guidance and testing must include those that the vendor wants listed by the PCI SSC. This consideration also pertains to client-server or database-application configurations where multiple systems will be present in the environment.
Software Development Lifecycle vendors
The assessment of a vendor’s software development lifecycle is rooted in documentation and demonstrated in practices. For each of the areas below, vendor personnel must understand the responsibilities assigned and follow the procedures provided. Change control must be applied throughout this process, not only for the development of software but to document the threats, risk management, and testing performed.
1. Threat identification and management
The objective of threat identification and management is for vendors to take a proactive approach to security. From a high-level perspective, the aim is for organizations to manage threats and maintain active process to apply security controls. By defining the critical assets and understanding data flows within the developed software, an organization can monitor guidance from third-party vendors and apply corrective actions in a timely manner. This step includes a review of the threats, assigning a risk ranking commensurate to the threat, and the ongoing application of updates to both code and dependencies.
2. Vulnerability management
Quite similar to the previous area, vulnerability management is an internal process for testing the application against known attack vectors. Vendors should incorporate routine testing into the development process and address vulnerabilities before releasing updates. Documentation will include the details obtained as a result of testing and subsequent retesting, providing evidence of the vulnerability management program in action.
3. Software and data management
A formal system or methodology needs to be applied to the code developed. The documented policies and procedures governing software development should include how changes to code are made and tracked, including:
• Decision points
• Impact of the changes
• Approval by authorized parties
• Incrementing the version for functionality changes
The software development lifecycle should be robust enough to clearly explain the development process and demonstrate how security is included throughout.
4. Deployment
The integrity of the payment software must be maintained from development through installation. The assessment will include a review of the code repository, the ability to identify unauthorized changes to code, the secure delivery of the software, and integrity checks prior to installation at customer locations.
5. Keeping the customer informed
Guidance must be provided to customers and stakeholders. The intent is for active communications to exist between the vendor and users or integrators of the software. Vendors are able to support the secure usage of software by disseminating updates to written guidance, details on vulnerabilities, release notes, and providing a channel for feedback. The bi-directional communications between the vendor and users supports the identification of issues in software and the timely response needed for those implementing it.
Conclusion
The Software Security Framework is a shift in the assessment of software vendors and the validation of the payment software they create. The objective-based controls provide a broader option for having software listed and is more inclusive in an age where payment processing channels are as varied as the technologies used.
In providing two separate but related standards, organizations are able to consider the options available to have the application listed and what ongoing processes are necessary for software updates. At PSC, we believe the increased maturity of these security standards provide functional, secure guidance to those implementing security in their development processes.
Need more info on moving to PCI-SSF from PA-DSS?
Download the rest of the ebook to learn more about determining which applications can be assessed against the SSF, differentiating application types, and the Software Security and Software Development Lifecycle vendor assessment processes.
Senior Security Consultant, NCC Group