A Conceptual Approach to the PCI Software Security Framework

Comprised of both the PCI Secure Software Lifecycle (Secure SLC) Standard and PCI Secure Software Standard, the PCI Software Security Framework (SSF) is intended to help secure the design, development, and maintenance of software in payment environments. And while secure coding can be difficult, taking a conceptual approach to software development may make it—and PCI SSF compliance—a little easier.

It may even be a better way. When it comes to standards, it’s common to read a short blurb on each’s intent before considering each control in sequential order. But regarding the PCI SSF, dividing the security of your software development into concepts can set you up well for SSF validation.

Think of it like building a house. A home requires key elements like framing, electrical, plumbing, and ductwork, but these elements aren’t placed in the abstract—your contractor will know where outlets will be placed and drains will run before putting up the walls that hold those items.

The PCI SSF can be approached similarly, and as assessors with experience in software security and secure coding, we will break down the core concepts for secure coding and PCI SSF compliance so that you’ll have a baseline to use when moving forward with this framework.

The 7 Core Concepts of Secure Software Development

1. Data Identification

End users of your software will expect it to be secure, preventing their data from being exposed. While not a small task, the first core concept of secure development is discovering and understanding your sensitive data, sensitive functions, and sensitive resources before you can get started in protecting it all.

The SSF framework is clear about what these parts include—you can find more details in the PCI SSF glossary—though the most common examples comprise things like:

• Passwords
• Cardholder data
• Encryption keys
• Session tokens

For example, here’s a common path of data (e.g., cardholder name, 16-digit card, expiry, card verification value) during a card-not-present transaction that is received by a web server for processing.

1. WEB SERVER receives all data elements.
2. WEB SERVER parses the last four of the 16-digit card number to show the CARDHOLDER, and passes the full data on to the APPLICATION SERVER.
3. The APPLICATION SERVER transmits the full data to an ACQUIRER.
4. The APPLICATION SERVER parses the data and sends the cardholder name, last four of the card, and expiry to the DATABASE.
5. The APPLICATION SERVER receives transaction confirmation or denial and a reusable token for recurring transactions from the ACQUIRER.
6. The APPLICATION SERVER sends the token to the DATABASE.

In this example, each of the sensitive data elements traveling within these cited systems should be identified to better understand interactions.

2. Data Interactions

For data to really be secure, you can’t simply identify which information you handle is at risk or in scope for the standards—you also need to understand and secure how it travels within your environment. You don’t just have data—your systems interact with data, parse data, pass data, or store data.

Determining your data interactions will likely be your most difficult lift, as this can take many forms from a processing unit parsing data that will only live in volatile memory to performing hash functions on authentication credentials for comparison to a stored value. That’s why it’s so key to know what data is handled first before you can discern how that data flows through an application and thus, which points of interaction must be accounted for in your compliance.

Data Interaction Example #1

To better illustrate, here’s an example of cardholder data flowing through an application for authorization (which does not store said data).

1. Data is received by the terminal, where it is written to volatile memory.
2. The initial function executes, which parses the card-present or card-not-present data in two operations:
   1. The last four and cardholder name for transactional records and receipts are pulled
   2. The data is put into the appropriate JSON format for sending to processors.
3. The secondary function executes, which establishes a secure channel to the processor API and then transmits the data in JSON format.
4. The tertiary function overwrites the sensitive data in memory and frees it up for use.

In this example, each operation will need to be documented, and each reception point and individual function must be accounted for (it may be that the same function performs multiple steps, which is fine).

Data Interaction Example #2

Moving onto a slightly more complex situation, let’s look at authentication by an application via a web portal and then via an application interface.

1. Browser establishes an encrypted channel.
2. Brower pulls data from the web server.
3. Credentials are entered on a web page.
4. Local web page writes credentials to volatile memory.
5. Application sends credentials to the API.

Now via an application interface:

1. API establishes an encrypted channel.
2. API receives a string of data, parses credentials.
3. Credentials are written to volatile memory.
4. Application hashes password and overwrites cleartext password.
5. Application verifies the hash.
6. Access is granted.

In this example, the use of protocols, authentication credentials, and the resources used for authentication management need to be defined and documented.

It’s also important to keep in mind that while both these flows are common, they’re not the most complex for sensitive data, and your other processes may require more involved discernment—especially regarding PII or encryption operations where key management involves cleartext entry. The number of steps and sensitive functions involved will increase with complexity.

Dedicating the required time to this concept will initially seem like a burden, but the insight you’ll gain into how an application functions will notably simplify the other concepts of software security.

3. Threat Modeling

Threat modeling—or the pinpointing of security threats or possibilities vulnerabilities—is another part of the logical progression toward writing secure software.

Business continuity demands that denial of service must be avoided, but maintaining the security of data is paramount, and that means essentially asking, “What can break [my software]?”

While most developers remain more interested in creation, performing threat modeling is critical to maintaining secure data and requires taking the perspective of an attacker to discover ways to compromise the created software by considering how an adversary would breach your software to get at data, execute malicious code, or to escalate privileges?

The vectors you discover should be documented as potential attack scenarios and you must account for all of the implicated inputs/outputs and sensitive data elements from your inventory, including:

• The parts of the software could be attacked;
• The potential data exposure;
• The impact of an attack; and
• Actions taken to mitigate those threats.

In recording all these details, you’ll create a composite view of the weak points in your software and your plan to address them.

To facilitate more comprehensive threat modeling, you can create processes that align with popular methodologies (i.e. STRIDE, VAST, DREAD) that are grounded in reason and whose functions and resources that interact with the data are also enumerated.

An approach like that might look something like this for a RESTful API of a banking application:

This table is meant to highlight the concepts from a basic perspective; however, creating a table for each scenario can be unwieldy and many of the controls that mitigate one vector may be used in others, so your development teams may and can find other, more direct means to create a structured model that identifies the threats to your software and mitigation controls.

4. Testing

As a software developer, you likely already understand the danger of assuming something built will work great the first time. Testing must be done on the code—regardless of the PCI SSF—and automated tools exist that can perform static and dynamic testing:

• Static Testing: Looks at how the code is written and identifies flaws that may not be caught during code reviews - like logic flaws or incomplete variables
• Dynamic Testing: Tests code in action by assessing how the application behaves – such as memory handling and the result of extraneous inputs

5. Documentation

While often considered in the same bucket as flossing twice a day—i.e., not essential—the value of comprehensive documentation is difficult to deny in software security because clear directions will always save the day. Look no further than the loss of foundational knowledge when a long-term developer moves to another company—in such situations, good documentation will bring your new staff up to speed much faster than any other method.

Moreover, to comply with the Secure Software Standard (SSS), the process of defining how software is written, reviewed, tested, and pushed into production must meet a series of controls. The good news is that—in our experience with software developers—most already check a number of those needed documentation boxes to demonstrate SSF compliance (with few exceptions), but there are a few challenges to stay wary of:

• Steps that are not documented
• Documentation that does not align with actions
• Shortcomings in testing

Start by having a detailed conversation with the development team and confirming that documentation aligns with the processes currently in place. After making any updates to ensure that what’s being done aligns with documented procedures, look at how this aligns with the Secure Software Framework (SSF) Control Objectives.

6. Maintenance

Just like a new house, it’s not enough to get everything in place and functioning—software security will require maintenance and upkeep to ensure the original structure holds up well. Were patches for dependencies released? Review and apply. A customer identified a fault or shortcoming? Troubleshoot, update and apply.

Insofar as compliance, the relevant requirements include:

• Secure Delivery of Updates: Strong encryption like TLS v1.2 is likely already being deployed and fits the bill.

• Installation of the Updates: Most frameworks provide a built-in means to verify the integrity of code before updating, most commonly through signing code with a digital signature, though some more seasoned developers may also understand that this can be met by running and comparing a checksum.

7. Communications

This should be a gimme, but don’t let that take away from the importance to both software security and compliance.

Within the SSF, the PCI SSC removed what were several parties that required communication—customers, clients, integrators, resellers, and the like. Now, all those have been lumped into “stakeholders,” or any person or organization using the software, and they all need to be considered for communications.

In terms of what all you need to say, we can categorize that into three categories that require the necessary processes defined, created, and supported (though some overlap is clear):

PCI SSF and Validation of Software Development Core Concepts

Tackling each of those foundational concepts of your software development in this way will prepare you for the PCI SSF-required validation process.

If you’ve ever attempted to buy or sell a house, you know that a home inspection is the part of the routine where someone knowledgeable goes through the house and identifies areas that do not meet code, areas of improvement, and provides these details to you in a report—the SSF validation assessment is similar.

Phase 1: Evidence Requests

To start, a Secure Software Framework Assessor will work with you to understand what the software does, including reading the documentation behind how development occurs. Evidence requests will include inventories of:

• Sensitive data
• Critical assets
• Threat modeling
• Change control tickets

If you’ve addressed all the aforementioned concepts, your assessor should become confident you’re doing your job to create and deploy secure software, and testing should further demonstrate this to be true.

Phase 2: Testing

Following your guidance documentation, your assessor will install the software in a manner that emulates a real-world deployment and execute test transactions. While monitoring the application state and communications, they’ll review the application and perform testing relative to the application functions.

Ideally, your previously performed threat modeling will have already accounted for the attack paths, but if issues are found, you’ll address them before retesting occurs.

Phase 3: Reporting

At this point, your validation assessment will be coming to a close. Your assessor will create your Report on Validation to document how the software was securely developed and tested, and you’ll confirm the accuracy of the report before all the necessary documentation is sent to the PCI SSC for review.

Moving Forward with Secure Software Development

Writing and maintaining secure software is not easy, but—as we’ve just explained—the core concepts behind the process aren’t complicated, and they boil down to:

1. Data Identification: Identification and understanding of sensitive data and resources that need protection, such as passwords, cardholder data, encryption keys, and session tokens.
2. Data Interactions: Recognition of how data flows through an application and securing its interactions, which can be complex and involve various operations.
3. Threat Modeling: Taking an attacker's perspective to identify potential security threats and vulnerabilities, documentation of attack scenarios, and mitigation of discovered risks.
4. Testing: Implementation of both static and dynamic testing of the code to identify and address flaws and vulnerabilities.
5. Documentation: Creation of comprehensive documentation that aligns with processes, actions, and controls, ensuring clarity and continuity, especially in the context of software security.
6. Maintenance: Performance of ongoing maintenance and updates to the software to address vulnerabilities, patches, and customer feedback.
7. Communications: Establishment of effective communication with stakeholders, including providing guidance documentation, release notes for updates, and channels for troubleshooting and customer support.

As the SSF provides a structured approach to securing the design, development, and maintenance to ensure the security and integrity of software in payment environments, taking this conceptual approach to software development can help organizations enhance their software security and streamline their compliance with the PCI SSF.

Should you have any further questions on the standard or compliance, contact us today to be connected with one of our experts. In the meantime, be sure to check out our other articles on the PCI SSF that can help ease your validation process:

• 5 Major Gaps to Avoid When Transitioning from PA-DSS to PCI SSF
• Manage Open-Source Software Vulnerabilities Within The New PCI SSF
• 6 Potential Problems with Your PCI SSF Assessment and How to Avoid That Liability