How to Harness the Power of PCI DSS? Tip #3

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?

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:

• External: Yes, here is an example below from Qualys site:

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:

• How to Harness the Power of PCI DSS? Tip #1
• How to Harness the Power of PCI DSS? Tip #2
• On Scanning
• All tips on everything

On Scanning

This post is about PCI DSS and vulnerability scanning.  What can be simpler than that? :-)

Well, the illustrious Branden Williams reminds us that even the simplest, clearest, most painstakingly defined part of PCI DSS can cause .. you know … trouble. Since his post is so good, I’d quote more and comment less.

First, a quick and useful reminder:

“Requirement 11.2 mandates quarterly scans for all hosts in scope for PCI, both internal and external”

External scans are well-defined, internal scans are left to the discretion of merchant’s security team. The latter does NOT make them any less mandatory though.

Then Branden asks a perfectly reasonable question:

“In more than half of the PCI assessments we [=his team at VeriSign] did in 2008, Requirement 11.2 came up as an initial gap. If it's just scanning, why can't we get it right?”

And, yes, he has an answer. The first part of the answer makes me embarrassed to even mention it here; in fact, I feel ashamed of being part of the same humanity with folks who do it… Namely:

“Reason the First: You scanned, but you forgot to obtain CLEAN scans for every quarter. Remember, the testing procedure for Requirement 11.2 states that QSAs must "Verify that the scan process includes rescans until passing results are obtained." Just scanning is not enough, you have to scan, patch, and re-scan until you have a clean scan”

No, neither Branden nor I are joking; stuff like that really happens: “It mandates scanning? So, we are going to scan! Is there anything else?” He then explains it further, with YouTube video illustrations, of course :-) And now the second part:

“Reason the Second: You scanned externally, but forgot to scan INTERNALLY.”

So, please call me the f*cking broken record (modern version: a corrupted MP3 file? :-)), but:

Internal network scanning is just as mandatory as external, as per PCI DSS.

Internal network scanning is just as mandatory as external, as per PCI DSS.

Internal network scanning is just as mandatory as external, as per PCI DSS.

Internal network scanning is just as mandatory as external, as per PCI DSS.

Internal network scanning is just as mandatory as external, as per PCI DSS.

Did I mention … oh, never mind! In any case, read his whole post here.

P.S. Today was the day I really didn’t want to write about PCI since I realized that even though PCI DSS is definitely NOT the reason for scams, there are PCI-related scams out there nonetheless. And that makes me sad. Whether it is about “free PCI compliancy” or “guaranteed PCI compliance for $4.75/month”, such things are NOT the whole story – they are the exceptions and not the rule. I still believe that PCI DSS is a strong positive force for security; maybe the strongest we ever had so far.

Vulnerability Scanning and Clouds/SaaS/IaaS/PaaS

Here is a very fun post called “Vulnerability Scanning and Clouds: An Attempt to Move the Dialog On…” I loved it so much, I will just quote my favorite parts here with a few comments. It starts like this:

“Much has been said about public IaaS providers that expressly forbid customers from running network scans against their cloud hosted infrastructure.”

In other words, they host your server, but you cannot check it for vulnerabilities at all.

“As has been noted before, a blanket ban on legitimate scanning activity by customers of their own infrastructure (whether outsourced or not) undermines security assurance processes and can make regulatory compliance impossible; e.g. PCI DSS mandates network vulnerability scanning as a control”

Use PaaS – lose PCI DSS compliance status. Nice! Sadly, the above interpretation is correct as, I suspect, the IaaS/PaaS provider is not allowed to scan your boxes either. So, nobody does. And then you get 0wned.

Next the post highlights that the fact that vulnerability management challenges are magnified by using PaaS/IaaS. For example:

“Scanning may trigger automated or manual actions by the provider. A common automated response from a provider is to apply traffic shaping to slow down the scan, or simply block the client IP address via an ACL update.  This can lead to false negatives; i.e. vulnerabilities present are not discovered as the scanner IP was automagically identified as a noisy vulnerability scanner and auto-throttled/blocked.”

He then highlight somewhat obvious, but still key point:

“Even if spinning up copies of “known good/secure” virtual machine (VM), you still need to scan them.”

Further:

“So the bad guys get to scan because they don’t care and yet the customer, who wants to do the “right thing”, is not allowed to.  Is that rational?”

The solution is “easy” – if you need scanning (and everybody does!) and you PaaS doesn’t allow it, don’t use that PaaS. But is this a solution? The post the  suggests “ScanAuth API” which will allow controlled scanning:

“Something like an “ScanAuth” (Scan Authorize) API call offered by cloud providers that a customer can call with parameters for conveying source IP address(es) that will perform the scanning, and optionally a subset of their Cloud hosted IP addresses, scan start time and/or duration. This request would be signed by the customers API secret/private key as per other privileged API calls.”

I am not sure about you, but this sounds like an awesome idea! The original post calls for the start of discussion, and I am happy to continue it. Finally, as of today, I don’t think we can rely on “other security tools”  (software assurance, secure coding, etc) to supplant the need for vulnerability scanning. if you deploy an OS in the cloud, you’d need to scan it.

BTW, similarly to network vulnerability scanning, the situation is actually worse for web app scanning? If you have “doubts” about your blog provider, can you hit it with Qualys WAS?