How to manage PCI DSS 3.1 Requirement 6.6 for your web applications
One of the PCI DSS 3.1 requirements is Requirement 6.6 dedicated to web application security. In this blog post we will try to understand how to comply with the requirement in cost-efficient manner.
PCI DSS Compliance for Web Applications
Cost-efficient maintenance of PCI DSS compliance certification is probably one of the most significant challenges faced by modern e-commerce businesses. Vulnerable websites and insecure web applications have become one of the easiest ways to compromise networks of small, medium and large companies – a fact backed up by the Payment Card Industry’s Data Security Standard (PCI DSS) guidance to Requirement 6.6, which deals with the security of websites and web applications.
It states that “Public-facing web applications are primary targets for attackers, and poorly coded web applications provide an easy path for attackers to gain access to sensitive data and systems”.
To gain a better understanding of the Requirement 6.6, we should refer to PCI DSS 3.1 standard which says that public-facing web applications shall “address new threats and vulnerabilities on an ongoing basis and ensure these applications are protected against known attacks.”
What is important here is the “on an ongoing basis” condition, which makes it very clear that web security is a permanent process and highlights the importance of continuous web security.
PCI DSS proposes two ways to achieve this requirement:
- “Reviewing public-facing web applications via manual or automated application vulnerability security assessment tools or methods, at least annually and after any changes.”
- “Installing an automated technical solution that detects and prevents web-based attacks (for example, a web-application firewall) in front of public-facing web applications, to continually check all traffic.”
Web Application Security Testing
PCI proposes manual and automated approaches to web application security assessment. Both methodologies have their strengths and weaknesses, so by combining both automated vulnerability scanning and manual penetration testing, you can achieve the highest level of application security possible.
Moreover, PCI explicitly says that one shall make sure that “at a minimum, all vulnerabilities in Requirement 6.5 are included in the assessment”. According to Requirement 6.5 those vulnerabilities are:
- Injection flaws, particularly SQL injection
- OS Command Injection, LDAP and XPath injection flaws, as well as other injection flaws
- Buffer overflows
- Insecure cryptographic storage
- Insecure [communications] channels
- Improper error handling
- Cross-Site Scripting (XSS)
- Cross-Site Request Forgery (CSRF)
- Broken authentication and session management
- Improper access control (insecure direct object references, failure to restrict URL access).
Many of the above-mentioned web vulnerabilities cannot be reliably detected with automated vulnerability scanning alone, and require manual testing by security professionals.
Another common question is how to select appropriate penetration testing providers. PCI DSS says that web application penetration testing shall be conducted by “an organization that specializes in application security”. Here is how they define such an organization:
“An organization can be either a third-party company or an internal organization, as long as the reviewers specialize in application security and can demonstrate independence from the development team.”
Probably the most important point here is independence. This is why we always recommended hiring vendor and product independent penetration testing companies, who do not resell, integrate, or install IT security solutions, thereby creating a potential conflict of interest during the audit.
Web Application Firewall
A Web Application Firewall (WAF) is another solution proposed by PCI to maintain web applications security. In our experience, a Web Application Firewall is a must-have solution, but it should never be used in isolation from other security solutions. Modern web applications change constantly, and updating existing WAF rulesets, or adding new ones, following the changes, made WAF management a time-consuming process, quite often leading to false-negatives (your WAF will stop blocking some of the attacks) or false-positives (your WAF will block legitimate users).
Theoretically, for a static web application or web application with dynamic yet simple architecture, an ideal, false-positive and false-negative free, configuration may exist. However, it will never consistently block some of the attacks against your web application, such as CSRF or application logic manipulation, authentication bypass or complex XSS inside of JS code, to name just a few.
In reality, even the most efficient modern WAFs from Gartner’s magic quadrant are usually installed in a very “silent” mode so as not to block legitimate traffic with false-positive alarms. The worst situation for online businesses is when a legitimate customer is blocked by WAF at the payment stage.
This is just one reason why the majority of businesses block only the most frequent and obvious attack patterns in their web traffic, which still leaves hackers with plenty of opportunities to by-pass the WAF. Therefore, a WAF should be always complemented by the above-mentioned web security scanning and web application penetration testing.
As you can see, it’s not so difficult to maintain PCI DSS Requirement 6.6, as it goes in line with all common information security best-practices.