Based on some of the mail I am getting these days, there is a lot of confusion regarding secure coding standards and application vulnerability scanning, that is, requirements 6.5 and 6.6.
First, let us talk about the intent of these requirements. The overall intent of both of these standards is to stop insecure applications from being placed in production. The intent of requirement 6.5 is to ensure that secure coding techniques are part of the system development lifecycle (SDLC) and that the most obvious errors, at the moment those are the OWASP Top 10, have been addressed during development. The intent of requirement 6.6 is to ensure that either code reviews are conducted or an application firewall is used to protect applications.
The most common question I get regarding requirement 6.6 is that since it does not specify what should be tested, does that imply that only the OWASP Top 10 needs to be looked for when conducting the code review?
When will you people learn? When the PCI DSS does not specify something, you always assume that you need to test everything. In the case of requirement 6.6, you need to conduct application vulnerability scanning for all potential vulnerabilities, not just the OWASP Top 10. This will become more important under PCI DSS v2.0 when they add other application vulnerability standards into the mix. The bottom line is that if all you are testing for is the OWASP Top 10, you are not doing enough testing.
Another area where people get things wrong is that they conduct application vulnerability testing just like they do network vulnerability testing, which is after the application is in production. Wrong! Unfortunately, the PCI SSC has only trained the QSAs to understand this fact and only merchants and service providers that have been through ISA training likely know about this requirement. Because of this, QSAs get beat up all of the time by merchants and service providers when they mandate application vulnerability testing and remediation before an application goes into production. However, if you think about it, it has always been implicit in these requirements. Remember, the intent of these requirements is to avoid putting vulnerable applications in production. That is why you need to conduct your scanning as part of your QA processes before the application goes into production. If any high, critical or severe vulnerabilities are discovered as part of the testing, those need to be either remediated or compensated for before the application is placed into production.
The final issue we consistently see is that secure coding techniques and code reviews are nowhere to be found in the SDLC. A lot of organizations point QSAs to various coding Web sites for their SDLC. They assume that these sites have already embedded secure coding techniques in their SDLC and that may or may not be the case. A lot of SDLCs document how to create application security, but say little or nothing regarding secure coding techniques. As a result, they are shocked when the QSA comes back and says that secure coding techniques are not in place. But what this points out is that the organization does not use the SDLC because had they used it, they would have known that the SDLC did not address secure coding and code reviews.
The lessons you should have learned are as follows.
- While requirement 6.5 only calls out the OWASP Top10, you need to also be worrying about all the other application vulnerabilities that could exist.
- SDLCs are meant to be used, not just offered as a way to meet a requirement.
- Secure coding techniques need to be documented as part of the SDLC and need to be followed.
- Requirement 6.6 requires you to scan for all application vulnerabilities, not just the OWASP Top 10.
- Application vulnerability scanning is performed before an application goes into production.
- If high, critical or severe application vulnerabilities are identified by scanning, those vulnerabilities must be fixed before the application goes into production.
PCI Guru 