Documentation Requirements

PCI Requirement 6 pairs with PCI Requirement 5 to satisfy vulnerability management program expectations. PCI Requirement 6 states, “Develop and maintain secure systems and applications.” The purpose of this requirement is to build a process for securely managing the software within your environment. For this requirement, we’ve discussed the 18 sub-requirements and topics such as how to securely develop applications, common coding vulnerabilities, and how to ensure your applications are protected. Complying with PCI Requirement 6 will protect your organization’s applications from being susceptible to threats and vulnerabilities. But, as we’ve learned, it’s not enough just to learn and talk about these things. All policies, procedures, and standards must be implemented in order to comply with PCI Requirement 6.7.

PCI Requirement 6.7 states, “Ensure that security policies and operational procedures for developing and maintaining secure systems and applications are documented, in use, and known to all affected parties.” This is not only saying that your organization needs to maintain documented security policies and operational procedures; the policies and procedures need to be known and in use by all relevant parties. Your personnel must be implementing what the policies, procedures, and standards require of them. It is a requirement of this framework that the affected parties use the policies and procedures. It is not sufficient that you generate documentation just for the sake of the audit. Your assessor should be reading these documents, familiar with the policies and procedures, and interviewing staff to make sure that anybody who is subject to the policies and procedures understands what they are. If PCI Requirement 6.7 is not met, your systems and applications will be left vulnerable.

Once again, we come to the capstone for Requirement 6. You need to maintain a documentation program. The documentation must be fully documented, in use, and known to all affected parties. From an assessment perspective, we’re going to be looking at your paperwork, reviewing your SDLC and policies, and interviewing your staff to make sure that they understand and have applied the policies as you’ve defined them for your organization.

Address New Threats and Vulnerabilities for Web Applications

PCI Requirement 6.6 states, “For public-facing web applications, address new threats and vulnerabilities on an ongoing basis and ensure these applications are protected against known attacks.” You can comply with PCI Requirement 6.6 through two methods: by reviewing public-facing web applications via manual or automated application vulnerability security assessment, at least annually and after any changes, or by installing an automated technical solution that detects and prevents web-based attacks in front of public-facing web applications to continually check all traffic.

A web application security assessment is not a penetration test or a vulnerability scan; it’s a much more specific, directed assessment. During this assessment someone who is qualified, knowledgeable, and independent of the development process must identify and address new threats and vulnerabilities for web applications. All common coding vulnerabilities from PCI Requirement 6.5 should be addressed in this assessment. After a new threat or vulnerability is identified, the vulnerability must be corrected and re-evaluated. This assessment should take place annually or whenever a significant change occurs in your environment or to the application.

A technical solution to address new threats and vulnerabilities for web applications is to install a firewall in front of public-facing web applications, in order to detect and prevent web-based attacks. The PCI DSS describes this method as, “Web-application firewalls filter and block non-essential traffic at the application layer. Used in conjunction with a network-based firewall, a properly configured web-application firewall prevents application-layer attacks if applications are improperly coded or configured.” This firewall needs to be actively running and updated, generate audit logs, and be configured to blog web-based attacks or alert the organization of a new threat.

The intent behind PCI Requirement 6.6 is to create a continuous cycle of security. We want to make sure that before an application goes into production, there’s a process in place to ensure it will not be left vulnerable in the future.

Where your organization has a public-facing web application, PCI Requirement 6.6 would apply. This requirement is really intended to establish controls to protect applications that might later become vulnerable, or where your team might have developed an application with a vulnerability, however, they missed it. That does happen from time to time.

There’s two ways to meet this particular requirement. The first is that you have an application layer firewall that resides in front of your web application. Where this is the case, you need to have this web application firewall actively scanning, kept up-to-date and managed, and blocking. If it is not blocking these applications, what’s happening is your team is notified and alerts are immediately acted upon.

The second way to meet this requirement is, on an annual basis, you do a web application security assessment. A lot of organizations get this part wrong. Understand a web application security assessment is a very directed, very specific assessment. It’s not a pen testing, it’s not a vulnerability scan. However, those activities might occur as part of this assessment. In a web application security assessment, we expect that people will look at the source code, looking at the back-end, really trying to identify all issues that might exist within the application where there might be a vulnerability, as opposed to just scanning the application. Understand that a web application security assessment is a much more thorough activity than your normal quarterly scan. This web application security assessment would need to be done by somebody that qualified, somebody that’s competent, somebody that’s independent, or specializes in it. It needs to be done after any significant changes to these applications and at least annually. If you have somebody within your organization that’s specific to testing the vulnerabilities and testing applications, that are not developing applications, it’s okay to have them do this test for you. But, if this particular individual or team answers to your development department, there needs to be some type of organizational independence. We need to make sure that when the application goes into production, it’s not going to be left vulnerable.

What is Cross-Site Request Forgery?

PCI Requirement 6.5.9 states that your organization’s applications are protected from cross-site request forgery (CSRF). PCI Requirement 6.5.9 applies to all of your organization’s web applications, internal application interfaces, and external application interfaces. Web applications, the PCI DSS states, have unique security risks as well as relative ease and occurrence of compromise.

OWASP describes a CSRF as a type of attack that forces an end-user to execute unwanted actions on a web application in which they’re currently authenticated. The PCI DSS defines CSRF as, “…an attack forces a logged-on victim’s browser to send a pre-authenticated request to a vulnerable web application, which then enables the attacker to perform any state-changing operations the victim is authorized to perform (such as updating account details, making purchases, or even authenticating to the application).” You may be wondering what the difference is between cross-site scripting (XSS) and CSRF. While CSRF occurs in an authenticated session of a web application, XSS does not need authentication information to exploit a vulnerable web application.

Your policies and procedures related to application development should specifically address coding techniques that ensure applications do not rely on authorization credentials and tokens automatically submitted by browsers. To verify your compliance with PCI Requirement 6.5.9, an assessor will review your policies and procedures and interview the responsible personnel to ensure that your development process protects your applications from CSRF.

With cross-site request forgery, we have a malicious site that’s causing an end user’s browser to send a pre-authenticated request to send information to an attacker. As part of your development process, we need to test and make sure that your website is void of any cross-site request forgery.

What is Improper Access Control?

PCI Requirement 6.5.8 states that your organization’s applications are protected from improper access control, such as insecure direct object references, failure to restrict URL access, directory traversal, and failure to restrict user access to functions. PCI Requirement 6.5.8 applies to all of your organization’s web applications, internal application interfaces, and external application interfaces. Web applications, the PCI DSS states, have unique security risks as well as relative ease and occurrence of compromise.

The PCI DSS outlines four types of improper access control:

1. Insecure direct object references occur when a developer exposes a reference to an internal implementation object as a URL or form parameter. Attackers can manipulate those references to access other objects without authorization.
2. Failure to restrict URL access can prohibit an application from protecting sensitive functionality by preventing the display of links or URLs to unauthorized users. Attackers can use this weakness to access and perform unauthorized operations by accessing those URLs directly.
3. Directory traversal could be enumerated or navigated by an attacker, thus gaining access to unauthorized information as well as gaining further insight into the workings of the site for later exploitation.
4. Failure to restrict user access to functions permits access to unauthorized functions, which could result in unauthorized individuals gaining access to privileged credentials or cardholder data. Only authorized users should be permitted to access direct object references to sensitive resources.

In order to comply with PCI Requirement 6.5.8, your organization’s policies and procedures must address proper authentication of users, sanitizing input, not exposing internal object references to users, and user interfaces that do not permit access to unauthorized functions. To verify your compliance with PCI Requirement 6.5.8, an assessor will review these policies and procedures and interview the responsible personnel to ensure that your development process protects your applications from improper access control.

There will be opportunities within your application where either end-users or other applications will request access either into information or to view certain pages within your environment. PCI Requirement 6.5.8 requires that you have some type of validation to make sure that the data that’s being requested, before it’s being provided to that end-user, is validated to make sure they can actually view that.

What is Cross-Site Scripting?

Cross-site scripting (XSS) is another type of common coding vulnerability associated with application development. PCI Requirement 6.5.7 requires that you protect all of your organization’s web applications, internal application interfaces, and external application interfaces from XSS. Web applications, the PCI DSS states, have unique security risks as well as relative ease and occurrence of compromise.

How does an XSS attack work? XSS is a type of injection in which malicious scripts are injected to a trusted website. OWASP explains, “An attacker can use XSS to send a malicious script to an unsuspecting user. The end user’s browser has no way to know that the script should not be trusted, and will execute the script. Because it thinks the script came from a trusted source, the malicious script can access any cookies, session tokens, or other sensitive information retained by the browser and used with that site. These scripts can even rewrite the content of the HTML page.” There are three types of XSS: Stored XSS, Reflected XSS, and DOM Based XSS.

• Stored XXS takes place when user input is stored on a target server, and a victim is able to retrieve the stored data from the web application without that data being made safe to render in the browser.
• Reflected XSS happens when user input is immediately returned by a web application with a response that includes some or all of the input provided by the user as part of the request without that data being made safe to render in the browser, and without permanently storing the user provided data.

• DOM Based XSS occurs when the entire tainted data flow takes place in the browser.

In order to verify your compliance with PCI Requirement 6.5.7, an assessor will need to review your policies and procedures related to application development and interview the responsible personnel to ensure that your development process addresses validating all parameters and context-sensitive escaping.

Cross-site scripting typically happens one of multiple ways. What’s happening is the source code being displayed to the end-user has an escape character. Where this becomes an issue is when somebody can cause a webpage or something can be loaded from a third party’s website that might contain some malicious information. PCI Requirement 6.5.7 expects you to have a program in place to prevent cross-site scripting. From an assessment perspective, what we’re typically looking for is that you have some type of whitelisting or some type of character validation to make sure that all of those escape characters that would be noted as causing cross-site scripting are rendered neutral.