SDLC Compliance: The Benefits to PCI SSLC

Let’s say you’re riding an ATV. For the more indoors-minded, that’s an all-terrain vehicle with four wheels that you straddle as you cruise.

You’re at a fork in the road—on your right, there’s a paved road down into a valley—great scenery, but what’s great is you’ve driven that way before, so maybe you’re a little more comfortable with that route. On the other hand, to your left there’s a dirt path that climbs a mountain. And it does look fun with promising great views, but since you’ve never gone that way before you’re worried about hitting bumps that will make you feel straight out of an action film.

The Payment Application Data Security Standard (PA-DSS) is being replaced this October, and its successor—the new PCI Software Security Framework (PCI SSF)—will also give you a similar choice. Because under the SSF will be two different standards.

The first—called the PCI Secure Software Standard—will address payment applications that qualify under the requirements specified by the PA-DSS Program Guide. If you’re on that ATV, this is your paved, more familiar road.

The other standard—this one called the PCI Secure Software Lifecycle (PCI SSLC)—is actually new and unique. It represents that untrodden fork in the road, but like the dirt path promised great views, getting listed under the PCI SSLC can help you demonstrate the strength and tenacity of your software development lifecycle (SDLC).

As a PCI Qualified Security Assessor that served on the taskforce that developed the SSF, let us explain how. Read on so that afterwards, knowing how it can work for you, you’ll be more sure whether or not this direction is right for you.

Getting SDLC Compliant: Then and Now

If the Secure Software Standard (SSS) standard focuses on your specific software itself, PCI SSLC is an assessment geared toward examining the security of your SDLC processes for that product or software. That’s why, if you’re a vendor with multiple products all developed under the same SDLC, this new framework should be of particular interest to you.

Until now, organizations looking to demonstrate compliance of their software development had to look to Requirement 6 of the current standard of PCI DSS 3.2.1. But because PCI DSS is particularly concerned with cardholder data, the requirement only included the development of those secure applications that would be in-scope for that environment.

As assessors, we see a lot of companies that provide software development services for our clients that are required to undergo PCI DSS. We know that compliance for most everyone is a pain, but SDLC compliance is a particularly sticky widget under PCI DSS.

That’s because you, as these vendors, have had two options with PCI DSS:

• You could get your own Attestation of Compliance (AOC).
  • While not a bad route, going this way means that you have to undergo the entire PCI DSS assessment with a QSA. Of course, you’re only responsible for software development—nothing to do with actual live cardholder data—so there’s a high likelihood that a good portion of the requirements get marked as ‘Not Applicable’ by the assessor.
• On the other hand, you could instead be included within the assessment of the merchant or service provider actually responsible for cardholder data.
  • This second option is often far less amenable. If you’re included in-scope for others’ PCI assessments, the assessor requires you to provide evidence each time that one of your customers undergoes an assessment.

But now, with the advent of the new PCI SSLC standard and the upcoming release of PCI 4.0, those of you who provide SDLC services to customers may be able to instead leverage a PCI SSLC AOC as validation to your customers. Essentially, instead of performing a PCI DSS assessment where most of the standard is not applicable to the services you are providing—i.e., software development—the PCI SSLC is more targeted to your needs.

Even still, a question remains.

What about companies whose SDLC is only in-scope for their environment, as their software is not actually eligible for PCI SSS?

If that sounds familiar, there’s still a way forward after the transition to the PCI SSF.

• You always can continue with those aforementioned PCI DSS assessments annually, including testing out those requirements that are not applicable to you.
• Or you can a different way and undergo a PCI SSLC assessment. Not only will you be able to potentially leverage this new standard for reduced testing during yours or your customers’ annual PCI assessment, but you’ll also have something new and more definitive to demonstrate to your customers.

What are the Benefits of PCI SSLC?

Leaving it at that, the value may seem insignificant. But if there are applications in-scope or residing within your cardholder data environment, it would benefit you to undergo PCI SSLC so that you can demonstrate to customers that you utilize an industry-accepted and independently validated SDLC.

Earning compliance through PCI SSLC is good for 3 years, and would also position you for some other, less obvious advantages:

• Not only will you have public assurances to wield, you also may be able to leverage the standard to develop a “tone at the top” SDLC model. In other words, you could use it as an opportunity to bring disparate or otherwise ad hoc processes under one unified umbrella, which would help streamline your processes internally as well.
• If you currently have multiple products all developed under the same SDLC, you can utilize the PCI SSLC standard to get listed on the PCI SSC website.
  
  
• In addition, you would have the ability to work with PCI SSC directly if your product(s) undergo Low-Impact or Administrative changes. Otherwise, you’d have to contract with an assessor who would need to reassess and reperform testing against elements of the standard depending on the change. As it’s likely that those of you with multiple products all developed under the same SDLC may undergo frequent Low-Impact changes, this change is a huge benefit.

Who Needs PCI SSLC?

Given all that, who actually should move toward getting PCI SSLC compliant?

• You need PCI SSLC compliance if you’re a software vendor looking to adopt the PCI Secure Software Standard and have multiple products that were developed under the same SDLC.
  
  
• You should consider PCI SSLC compliance if you’re a third-party vendor that provides software development services for your customers that undergo PCI validation. You stand to benefit from possibly abbreviating your own process for a similar compliance result that you can provide your customers.
  
  
• You should also consider PCI SSLC compliance if you’re an organization that currently undergoes an annual PCI assessment and are looking to reduce the work of that annual validation as well as provide additional value to your customers and organization.

Next Steps for PCI SSLC

Of course, even if you aren’t one of the above, the benefit of an independently validated SDLC is inherent—as we said, it could help streamline your internal methodology and help you sleep better at night.

But there are definitely those out there that will benefit from adopting PCI SSLC, and now you understand better whether it’s particularly pertinent for you, or if not, how its benefits can still level up your organization.

As the transition to the full PCI SSF grows closer, please feel free to reach out to us here at Schellman. We’re happy to set up a conversation so that we can answer any lingering questions you have. In the meantime, read our articles on the new standard so that you’re even more prepared for its arrival:

• 5 Major Gaps to Avoid When Transitioning from PA-DSS to PCI SSF (and How to Avoid Them)
• How to Manage Open-Source Software Vulnerabilities: Understanding the PCI SSF’s Approach
• What is Considered “Sensitive Data” Within the PCI SSF?