PCI Secure SLC v1.1 - Updates and Benefits to SSF

Early this year, the PCI Council released version 1.1 of the PCI Secure Software Lifecycle (SSLC) standard.  As one half of the Secure Software Framework (SSF) that expands vendor and software eligibility regarding PCI Secure Software assessments, it represents a fundamental change in how compliance for software in the Payment Card Industry will be vetted going forward.

Before the SSF, its predecessor, the Payment Application Data Security Standard (PA-DSS), was in place, but its application as a validation method was extremely limited as it left a large amount of software out of its scope.  When version 1.0 came out, the SSLC appeared to target organizations similar to what the more narrowly defined PA-DSS required, with some minor changes—it appeared that the new framework was written to be more inclusive to entities looking for a more robust assessment than what PA-DSS offers, with more targeted scrutiny given to software security.

Now, the PCI Security Standards Council (SSC) has come out with further guidance within the SSF Program Guides that expands program eligibility.  This sets the precedent that, over time, the program may continue to become more expansive and eventually include even broader categories of eligible software.  This will provide further benefits for entities looking to assess their payment software and provide added value to their customers.

As of March 2021, the PCI SSC has identified the following vendor Product Categories that can be listed under a company’s Secure Software Lifecycle processes.  Vendors may have one or many of the products listed under the program:

1. Automated Fuel Dispenser	7. POS Admin
2. Card-Not-Present	8. POS Face-to-Face/POI
3. Payment Back Office	9. POS Kiosk
4. Payment Component	10. POS Specialized
5. Payment Gateway/Switch	11. POS Suite/General
6. Payment Middleware	12. Shopping Cart and Store Front

If the PCI SSLC is the assessment geared toward more of a vendor certification that examines the vendor’s SDLC processes for that product or software, the other half of the SSF—the Secure Software Standard (SSS) assessment—differs in that it is focused on the specific software itself.  Though the SSS can seem very similar to its predecessor, PA-DSS, if organizations do choose to pursue an SSS assessment—should they qualify—they will see additional benefits of some autonomy to ‘self-assess’ for changes that are low-impacting.  Previously, any updates to be made required an organization to contract with a PA-QSA company, but that will no longer be the case unless the product undergoes a major change.

Given this update, software vendors now have more to think about—even more so when considering that the PA-DSS program ends in October 2022.  In preparation, organizations should already be looking to replace their current PA-DSS requirements and assess sooner rather than later to meet the needs of a ‘customized approach’ to the standards.  To help get started, the PCI SSS eligibility can be seen below, as well as within the respective Program Guides on the PCI SSC website.

Secure Software Standard Eligibility

1. Software products involved in or directly supporting or facilitating payment transactions that store, process, or transmit clear-text account data; and

2. Software products developed by the vendor that are commercially available for sale to multiple organizations.

Ineligible Products:

1. In-house developed Payment Software that is used only by the company that developed it.

2. Payment Software that operates on any consumer electronic mobile device that is not solely dedicated to payment acceptance for transaction processing.

3. Payment Software intended for use on hardware terminals (e.g., PTS POI devices).

4. Commercial operating systems onto which Payment Software may be installed, unless the operating system is an integrated component of the Payment Software itself.

5. Commercial database applications that Payment Software may utilize for storage of account data, unless the database is an integrated component of the Payment Software itself.

6. Other types of commercial software developed for purposes unrelated to transaction processing or Payment Software security characteristics, controls, features, and functionalities—for example, system monitoring or network management services—that may be in the same environment as the Payment Software but are not integrated components of the Payment Software.

In comparison, here are the disqualifying conditions for applications under PA-DSS:

1. If the application was a beta version;

2. If the application handled cardholder data but the application itself did not facilitate authorization or settlement;

3. The application handled authorization or settlement, but had no access to cardholder data or sensitive authentication data;

4. If the application required source code customization or significant configuration by the customer (as opposed to an “off-the-shelf” product”) that would impact one or more PA-DSS requirements;

5. If the application was a back-office system that stored cardholder data but did not facilitate authorization or settlement of credit card transactions.  Some examples would be:

   1. Reporting and CRM; or

   2. Reward or fraud scoring;

6. The application was developed in-house and only used by the company that developed it;

7. The application was developed and sold to a single customer for the sole use of that customer;

8. If the application functioned as a shared library that must be implemented with another software component in order to functions, but was not bundled (sold, licensed or distributed as a single package) with the supporting software components;

9. If the application depended on other software in order to meet one or more PA-DSS requirements, but was not bundled (sold, licensed or distributed as a single package) with the supporting software;

10. If the application was a single module that was not submitted as part of a suite, and did not facilitate authorization or settlement on its own;

11. If the application was offered only as a SaaS product and was not sold, distributed, or licensed to third parties;

12. If the application was an operating system, database or platform; even one that may store, process, or transmit cardholder data; or

13. If the application operated on any consumer electronic handheld device (e.g. smart phone, tablet, or PDA) that was not solely dedicated to payment acceptance for transaction processing.

The numbers tell the story here—a look at the requirements and products that are eligible under the two programs and you will notice that the Secure Software Framework encompasses much more, allowing application vendors to leverage the benefits of having an assessment specifically tailored to the security of the software they are developing.  Given that application-layer attacks are still one of the leading causes of security breaches across the landscape, as are the poor coding practices that lead to insecure software development, the Secure Software Lifecycle and Secure Software Standard are highly beneficial for the industry since they are built to directly address those issues.

As such, it’s likely that we will see more entities leveraging the benefits of the evolving Secure Software Framework over the next few years as the program grows and becomes more visible across different application vendors.  In fact, there’s already some evidence of that growing trend as of this writing—the PCI SSC has announced that there will be further changes to the Secure Software Standard that will add support for a more modular approach, including training for Terminal Software and updating the list of payment software eligibility.  Since the program was only introduced in 2020, the fact that there have already been changes seems to indicate the Council’s commitment to addressing software security concerns and evolving threat landscape.

Looking forward, we will keep our eye out for any more progress on this front, but if organizations would like to go ahead and get going in discussing their software security needs, please feel free to contact Schellman with any questions or concerns.