PCI Software Security Framework

PCI Software Security Framework
(replaces PA-DSS)

PSC provides validation services for organizations that wish to comply with the PCI Software Security Framework.

Two standards make up the PCI Secure Software Framework (SSF) and combine the best features from the legacy Payment Application Data Security Standard (PA-DSS) along with real-world development methodologies, resulting in an effective compliance standard. Companies that design, develop and deploy payment application software can select either or both of these Standards:

Secure Software Life Cycle (Secure SLC) describes a baseline of requirements covering design, development and maintenance of best software development practices to enhance and deploy secure software.

Secure Software Standard (SSS) covers requirements related to the actual design and development of payment applications sold or licensed to other companies. This new, more efficient set of requirements replace the old PA-DSS.

How these standards differ from PA-DSS:

The PA-DSS is one large standard with 14 major requirement areas synchronized to the 3.2.1 version of the PCI Data Security Standard. Over time, advances in software frameworks and computing technology innovations made it difficult for modern development organizations to comply with “legacy” PA-DSS.

“Objective-Based” approach means one size does not fit all and software vendors can take a risk assessment strategy to fit solution to a security control objective.

The objective-based requirements of the Software Security Framework comprise a set of modular standards and it gives software vendors several options and advantages.

pci-ssf

The new standard is designed to allow software developers more flexibility and operate more in line with the way software applications are actually designed – specifically in the early application life cycle stages, where changes can be frequent. This chart illustrates the architecture of the SSF.

  • The Secure Software Standard (SSS) is further divided into Core requirements, with a module specific to applications that store, process or transmit cardholder data. Future modules may be added to the SSS that may apply to other types of payment application areas.
  • The Secure Software Lifecycle (SLC) standard consists of a set of security objectives that provide common requirements across software development organizations.

Why comply with Secure SLC?

For companies that develop, license, and deploy software into the payments industry, there are several advantages to being listed on the PCI Security Standards Council list of approved solutions as an SLC Vendor.

  • Upon completion of the initial assessment, the QSA will submit documents and the company will be identified on the PCI SSC as being a Secure SLC Qualified Vendor.
  • The listing identifies the company as being SLC compliant providing a product category.
  • SLC compliant companies can perform their own annual revalidation and designated change validations without involving an SLC security assessor.
  • SLC compliant companies can login and make administrative changes to their listing on the PCI SSC web site.
  • If an SLC company also has a product that is validated and listed according to the Secure Software Standard (SSS), those companies can perform their own delta assessments for any low impact changes without involvement of the SSS security assessor.

Why act now to comply with Secure Software Standard (SSS)?

If your company designs, builds, licenses, and deploys payment software for use by other companies, there are several reasons to begin work now to validate:

  • The standard is modular and objective-based. Unlike the old PA-DSS which was prescriptive and confused many software vendors on how to comply with the requirements, the SSS can fit many types of development companies and products.
  • Testing and validation processes have been streamlined for remote assessment.
  • Maintenance and validation of changes have been simplified. There are only Administrative, Low Impact, and High Impact types of changes; and the criteria for each are easily understood and incorporated into developer change management tracking systems.
  • Low impact changes qualify for a Delta Review.
  • If the software vendor is already validated and current on the PCI SSC list for Secure SLC, they can perform Administrative and Low Impact assessment and change work without involving the SSS assessor.

Contact us for more information