Inspired by the panels we did on PCI (here, here), I decided to start a series of posts with tips on harnessing the amazing motivating power of PCI DSS for meaningful security improvements. These tips are most useful for those in the trenches who are required to comply with PCI DSS while keeping the systems running and secure but maybe do not know how, and not to those who whine, bitch, blog and twitter their way to infamy…
So, got a nice heavy PCI hammer? Where do you hit for security?
![image_thumb2[2]](file:///C:/Documents%20and%20Settings/achuvakin/Local%20Settings/Temp/WindowsLiveWriter-429641856/supfilesFBFA59/image2.png "image_thumb2[2]")
Tip #3 will again focus on something very basic, non-controversial and, again, spelled out relatively clearly in PCI DSS: namely, vulnerability scanning, which is itself part of vulnerability management. Basic? Hell yeah! So then, pray tell me, why is it one of the most common PCI assessment failures (see Branden for evidence)?
First, where does PCI DSS guidance talks about vulnerability scanning? In Req 6 and 11, namely:
“6.6 For public-facing web applications, address new threats and vulnerabilities on an ongoing basis and ensure these applications are protected against known attacks” [and vulnerability scanning is one of the options]
and
“11.2 Run internal and external network vulnerability scans at least quarterly and after any significant change in the network (such as new system component installations, changes in network topology, firewall rule modifications, product upgrades).”
So, when you see the above what questions pop up first? My tip will be in answering them!
Q: What systems must I scan for PCI DSS compliance?
A:
- External: “all Internet-facing Internet Protocol (IP) addresses and/or ranges, including all network components and devices that are involved in e-commerce transactions or retail transactions that use IP to transmit data over the Internet” (source: “Technical and Operational Requirements for Approved Scanning Vendors (ASVs)”[PDF] by PCI Council). The answer can be “none” if your business has no connection to the Internet (duh!)
- Internal: all systems which are considered “in-scope” for PCI, which is either those involved with card processing or “directly connected” to them (source: PCI DSS[PDF]). The answer can also “none” if you have no systems insider your perimeter which are in-scope for PCI DSS.
Q: Is there a pass/fail criteria for scans?
A:
| PCI DSS ASV Scan Criteria |
| Vulnerabilities with a CVSS v2.0 base score of either 4.0 or higher will cause PCI compliance to fail on the scanned systems (excluding vulnerabilities leading only to denial-of-service issues) |
| A system will be considered non-compliant if the SSL version installed on it is limited to 2.0 or older. |
| Vulnerabilities that may lead to SQL injection attacks and cross-site scripting will result in a non-compliant status on the corresponding system. |
These are derived from the same “Technical and Operational Requirements for Approved Scanning Vendors (ASVs)”[PDF] document by PCI Council.
- Internal: there is no explicitly spelled-out pass/fail criteria. The decision is thus based on your idea of risk; there is nothing wrong with using the same criteria as above, of course, if you think that it matches your view of risks to card data in your environment. However, most QSAs will not accept a scan report with high-severity vulnerabilities present in the card holder data environment. For example, assuming a 1-5 scale with 5 being the most severe, 3s,4s and 5s are likely to be a "deal-breaker" (this section is UPDATED!)
Q: How do I pass?
A:
- External: you satisfy the above criteria. If you don’t, you need to fix the vulnerabilities that are causing you to fail and the rescan. And then you pass and get a “passing report,” that you can submit to your acquiring bank.
- Internal: there is no pass/fail criteria. You don’t get to to pass – or to fail. You just need to do it to reduce risk to cardholder data, based on your own view of such risk. You can do it right or wrong in that regard, BUT “not doing it” is unambiguously wrong! So, actually, you do get to fail – if you don’t do it at all.
Q: Am I “PCI compliant” if I get a passing scan for my external systems?
A: No. No. No. No. No. You only satisfied one of the PCI DSS requirements; namely, PCI DSS validation via an external Approved Scanning Vendor (ASV) scan. This is NOT the end. Likely, this is the beginning…
Q: If I scan my website using my ASV and get a passing scan, am I also OK in regards to Requirement 6.6 “For public-facing web applications… address new threats and vulnerabilities on an ongoing basis?”
A: No, most definitely not. This is a different story; and the subject of another tip.
Enjoy!
P.S. There are some of you who would read this and say “Give us sexy security stuff! Give us clouds! Give us bleeding edge! Or at least give us the results of your CVSS vector factor analysis..” To those I say, all in due course :-)
Possibly related posts:
