What is Buffer Overflow?

PCI Requirement 6.5 requires that your organization address common coding vulnerabilities in software development processes to ensure that applications are securely developed. One of the common coding vulnerabilities associated with secure application development is buffer overflow attacks, which is outlined in PCI Requirement 6.5.2. Although it’s a common coding vulnerability and widely understood, organizations still seem to struggle with how to protect themselves from buffer overflow attacks and how to comply with PCI Requirement 6.5.2.

PCI Requirement 6.5.2 requires that your organization protects its applications from buffer overflows. OWASP defines a buffer overflow as, “A buffer overflow condition exists when a program attempts to put more data in a buffer than it can hold or when a program attempts to put data in a memory area past a buffer. In this case, a buffer is a sequential section of memory allocated to contain anything from a character string to an array of integers. Writing outside the bounds of a block of allocated memory can corrupt data, crash the program, or cause the execution of malicious code.” A buffer overflow is a vicious cycle. When buffer overflows occur, according to the PCI DSS, “an attacker could insert malicious code at the end of the buffer and then push that malicious code into executable memory space by overflowing the buffer. The malicious code is then executed and often enables the attacker remote access to the application and/or infected system.”

To comply with PCI Requirement 6.5.2, we recommend that when your organization develops applications, there are defined lengths within your code, you’re truncating or you’re extracting only the data that you would need for processing, and ignoring any other data. During an assessment for PCI Requirement 6.5.2, an assessor will examine your policies and procedures related to application development and interview the responsible personnel to verify that you are validating buffer boundaries and truncating input data.

Buffer overflows within applications are pretty nasty vulnerabilities. Effectively what is happening is you’ve defined memory space within the application, and the application itself is taking data from another source (from a user input, file, etc.), and that data that it’s accepting exceeds the boundaries of the memory that you’ve allocated. Typically, when that happens and that memory gets dumped into your heap and you exceed that buffer, that information that you’ve installed into that buffer has to go somewhere. Regardless of the source (even a trusted user or trust file), it’s going to be really important to validate your input lengths. When you’re developing software, what we’re looking for from a testing perspective is that you have defined lengths within your code and that you’re truncating or you’re extracting only the data that you would need for processing, and the rest of that data is ignored.

What are Injection Flaws?

PCI Requirement 6.5 requires that your organization addresses common coding vulnerabilities in software-development processes to ensure that applications are securely developed. One of the common coding vulnerabilities associated with secure application development is injection flaws, which is outlined in PCI Requirement 6.5.1.

PCI Requirement 6.5.1 requires that your organization’s applications are immune from injection flaws, especially SQL injection. Injection flaws are commonly used by malicious individuals to compromise applications. Injection flaws are a type of security vulnerability that allow a user to “break out” of the application and, according to OWASP, “allow attackers to relay malicious code through an application to another system. These attacks include calls to the operating system via system calls, the use of external programs via shell commands, as well as calls to backend databases via SQL.” The PCI DSS says, “Injection occurs when user-supplied data is sent to an interpreter as part of a command or query. The attacker’s hostile data tricks the interpreter into executing unintended commands or changing data, and allows the attacker to attack components inside the network through the application, to initiate attacks such as buffer overflows, or to reveal both confidential information and server application functionality.”

Best practice recommends data coming into the application should be validated. To verify compliance with PCI Requirement 6.5.1 and protection from injection flaws, an assessor will examine your policies and procedures related to application development and interview the responsible personnel.

When developing applications, we need to make sure they are immune from any type of injection flaws; specifically, the PCI DSS calls out SQL injection. One of the things we look for is that you have some type of parameterized queries or you’re making sure the string of data that’s coming into the application is vetted before it’s run. Where you have a parameterized query, you’re not taking the data stream provided by the end-users and developing your query based on that. Make sure that when your team is developing software, they are not subject to SQL injection. As part of your secure code development testing, as part of your SDLC, make sure that you write test scripts, testing for SQL injection as part of this requirement.

Addressing Common Coding Vulnerabilities

PCI Requirement 6.5 is focused specifically on making sure that code is developed securely. PCI Requirement 6.5 requires that you address common coding vulnerabilities in software development processes by training developers on up-to-date secure coding techniques and developing applications based on secure coding guidelines. The application layer is high-risk and may be targeted by both internal and external threats.

We discuss training over and over again because it’s so crucial to your cardholder data environment’s security. Your development staff needs to be trained at least annually on up-to-date secure coding techniques, which should include how to avoid common coding vulnerabilities and how to solve issues related to common coding vulnerabilities. This could be an in-house or self-guided training, or something more formal. An assessor needs to see evidence of annual training on how to develop secure code. The intent behind this requirement is to build a knowledgeable staff to minimize the possibility of security vulnerabilities from poor coding practices.

The PCI DSS states, “As industry best practices for vulnerability management are updated, the current best practices must be used for these requirements.” The following requirements outline vulnerabilities associated with PCI DSS v3.2 and you are required to address these common coding vulnerabilities in the software development process:

• 5.1: Injection flaws
• 5.2: Buffer overflow
• 5.3: Insecure cryptographic storage
• 5.4: Insecure communications
• 5.5: Improper error handling
• 5.6: All “high risk” vulnerabilities
• 5.7: Cross-site scripting (XSS)
• 5.8: Improper access control
• 5.9: Cross-site request forgery

In order to verify that your organization is complying with PCI Requirement 6.5, an assessor will examine software development policies and procedures, training records, and processes that protect the vulnerabilities listed above.

PCI Requirement 6.5 is specifically focused on making sure that when code is developed, it’s going to be done securely. There’s a couple of things that we need to look at. One, is that your development staff has been trained at least annually. Now, the secure code development – we’re going to look for some artifact of that. This doesn’t mean that you need to send somebody off to class for a week to go to training. This training can be something that you deliver in-house, which is fine. It can be self-guided, there’s no issue with that. Effectively, what we’re looking for is that your staff has been trained at least annually on how to develop secure code.

One of the other important parts about this particular requirement is: we’ve seen a lot of vulnerabilities, as of late, with malware. This particular malware has been scraping memory for cardholder data. You can Google it, you can look at YouTube videos. Just with a few lines of code, individuals are able to scrape memory and get cardholder data out of the application or out of the memory. As part of this, we have a requirement that you as an organization train your staff so at least they have knowledge of how the application is handling this cardholder data while in memory. The test for this is simple. Your assessor is going to be asking your developers, “Talk to me about how this application interacts with cardholder data while it’s in memory.”

Follow Your Change Control Program

Most, if not all, security programs require that you have some type of Change Control Program. At the start of our PCI Demystified journey, we discussed Change Control Programs. In PCI Requirement 6.4, this point is reiterated. PCI Requirement 6.4 states, “Follow change control processes and procedures for all changes to system components.” Your organization should have the appropriate methods to control any changes in to and out of your environment. PCI Requirement 6.4 requires that your organization’s Change Control Program includes a documented roll-back plan, a testing phase, management’s approval, and updated documentation. The PCI DSS warns, “Without properly documented and implemented change controls, security features could be inadvertently or deliberately omitted or rendered inoperable, processing irregularities could occur, or malicious code could be introduced.”

• Roll-Back Plan – A documented roll-back plan is crucial to your Change Control Program. This documentation should outline exactly how to roll back changes in the event that something goes wrong or there’s a negative impact.
• Testing Phase – All changes need to be tested to ensure there is no negative impact on the cardholder data environment. Testing the roll-back plan shows an assessor your organization’s level of maturity.
• Management’s Approval – Management needs to approve all aspects of the Change Control Program.
• Updated Documentation – Any time there is a significant change within your environment, you must ensure that all documentation is updated, including network diagrams, data flow diagrams, and inventory lists. Until documentation is updated, the change control should be left open.

When determining your compliance with PCI Requirement 6.4, your auditor will examine policies and procedures related to your Change Control Program to verify that you’ve defined the following:

• Development and testing environments are separate from production environments, plus there are access controls in place to enforce this separation.
• A separation of duties between the employees assigned to the development and testing environments and those assigned to the production environment.
• Production data (live PANs) are not used for testing or development and, vice versa, test data is removed before a system or application goes into production.
• Change control procedures related to security patches and software modifications are documented.

It’s vital to follow change control processes and procedures for all changes to system components. If not, according to PCI Requirement 6.4, security features could be unintentionally or deliberately omitted or rendered inoperable, processing irregularities could occur, or malicious code could be introduced.

Most, if not all, security programs or audit programs require that you have some type of change control program. The PCI DSS is no stranger to this as well. PCI Requirement 6.4 specifically calls out that you have a change control program. I’m going to talk about all the change control requirements here within this one video. This change control program needs to have the following things documented. One, you need to have a documented roll-back plan. The level of narrative that you provide as part of this roll-back plan should be at that level that six months from now, you could roll-back that application in the event that something’s going wrong.

You need to test that particular change, making sure that there’s no negative impact to the environment. When we look to see if you tested the application, one of the things that shows us maturity within your program is that you’ve actually tested the roll-back plan to make sure that works and that it doesn’t negatively impact the cardholder data.

We want to make sure that management is approving these changes. As part of any significant change within your environment, we’ve mentioned this in some of the other videos, there might be the need to update your network diagram, there might be a need to update your dataflow diagram, and there might be a need to alter your inventory list. We recommend that you keep the change control open until such time that this documentation has been updated.

How to Review Custom Code Prior to Release

PCI Requirement 6 requires your organization to go through many phases of development before production to ensure that software applications are being securely developed. PCI Requirement 6.3.1 requires that any testing data being used in the development and testing phases is removed before the application goes into production. PCI Requirement 6.3.2 adds another level of information security to the application by requiring you to review custom code prior to release or production. PCI Requirement 6.3.2 states, “Review custom code prior to release to production or customers in order to identify any potential coding vulnerability.”

This review process should include the following elements, according to PCI Requirement 6.3.2:

• Code changes are reviewed by someone other than the original code author and who is knowledgeable about code review techniques and secure coding practices. Just because someone can develop code doesn’t mean that they can review code, so it’s vital that whoever is responsible for code review is properly trained in how to do this. It’s also important that code reviews are performed by someone other than the developer of the code to allow for an objective review.
• Code reviews ensure code is developed according to secure coding guidelines.
• Appropriate corrections are implemented prior to release. If a security vulnerability is discovered and is not corrected, this puts your application at risk. The PCI DSS also points out, “Faulty code is far more difficult and expensive to address after it has been deployed or released into production environments.”
• Code review results are reviewed and approved by management prior to production. This isn’t suggesting that management performs the code review, but rather, management signs off that the necessary corrections have been made and the development process is working as it’s defined.

So now in your development process, you’ve developed code, it’s been developed against an SDLC that contains all of the necessary security attributes that we’d like to see, you’ve developed the application to meet PCI DSS requirements, and met all the logging and authentication requirements. Now, we want to make sure that you have someone within your organization that’s going to review that source code for any vulnerabilities.

There’s several things we need to look at here. First of all, the person that’s reviewing the source code for any vulnerabilities should be trained in how to do that. Understand that just because you’re developing does not necessarily mean that you can develop secure code, and just because you’re developing secure code does not necessarily mean you can do code review. One of the things that we as assessors like to do is look at what those processes are. It’s not really called out within the PCI DSS, but some of the things that I look for in your development process is how you comment your code. It’s important to us for you to understand that when somebody else is looking at that code or if you should not be the one developing code anymore (if the application developer doesn’t exist at your organization two to three years from now), what is it that this part of the application is doing? While it’s not required, something that I recommend you do is use good commenting within your application. Understand that the person reviewing the code should not be the same person that’s developing the code. You need to have a separate person doing that. The code review needs to be done by someone that’s competent to perform that activity. After the code has been reviewed, where there is a security vulnerability or an issue that’s discovered, it’s expected that your organization actually goes back and corrects that code.

Lastly, as part of this particular requirement, management is going to be signing off that all of the necessary corrections have been made. It’s not suggesting that management is doing the code review. The expectation, from an assessment perspective, is that management is signing off that all of your SDLC, processes, and the things we’ve defined and have been talking about, have been followed and that the process is working as it’s been defined.