While PCI DSS requirements has been set for some time, it’s the clarification documentation and written interpretation that matters…and I’ve said it before, your QSA is key to supporting your interpretation/implementation. After all, it’s their credibility and they are the ones to answer to VISA, PCI, etc.
So, here’s the 6.6 clarification just in case you haven’t figured out the code review and application firewall topic (though the due date was June 30, 2008):
Taken straight from PCI standards:
Option 1 is Application Code Review--which can be done via 1 of the 4 options:
1. Manual review of application source code 2. Proper use of automated application source code analyzer (scanning) tools
3. Manual web application security vulnerability assessment
4. Proper use of automated web application security vulnerability assessment (scanning) tools
In other words, either a manual (qualified staff or independent firm) or tool-based inspection/injection of non-standard inputs; then analysis of the results—but the key being measures to protect against common types of malicious input. I stress this because interpretation of this is subject to vary as well.
Option 2: Application Firewall--and this is in addition to all other requirements including firewall, logging, etc.
Should go without saying that all other requirements are still requirements—including the compounding requirements that relate:
6.3 – SDLC and secure software development process
11.3.2 – application-layer penetration testing to ensure applications don’t have vulnerability
6.5 – common vulnerability testing which is primary OWASP including: input validation, least privileges, default deny, data sanitization, security policy design, quality assurance techniques, and once again, defense in depth.
Taken straight from PCI standards:
Option 1 is Application Code Review--which can be done via 1 of the 4 options:
1. Manual review of application source code 2. Proper use of automated application source code analyzer (scanning) tools
3. Manual web application security vulnerability assessment
4. Proper use of automated web application security vulnerability assessment (scanning) tools
In other words, either a manual (qualified staff or independent firm) or tool-based inspection/injection of non-standard inputs; then analysis of the results—but the key being measures to protect against common types of malicious input. I stress this because interpretation of this is subject to vary as well.
Option 2: Application Firewall--and this is in addition to all other requirements including firewall, logging, etc.
Should go without saying that all other requirements are still requirements—including the compounding requirements that relate:
6.3 – SDLC and secure software development process
11.3.2 – application-layer penetration testing to ensure applications don’t have vulnerability
6.5 – common vulnerability testing which is primary OWASP including: input validation, least privileges, default deny, data sanitization, security policy design, quality assurance techniques, and once again, defense in depth.
No comments:
Post a Comment