Update: Nothing I've read in the updated PCI DSS or those who commented have said the text has been watered down. PCI DSS is well thought out, balanced, and comprehensive. Substitute "carholder information" for any type of sensitive information and it immediately useful elsewhere (banking?). What counts is enforcement. This is where are a lot of questionr emain about PCI DSS.1) How strongly will the standard be enforced? Fines, higher fees, suspensions?
2) What vulnerabilities are ASV's going to be capable of finding?
3) How strongly will ASV's and QSA's be vetted to get on the lists? And what happens if they water down their processes and provide poor service?
4) How does a merchant know what vendors specialize in web application security?
5) What is considered an application layer firewall?
It's the day we've all be waiting for! *queue the drums* A year and a half we waited wondering what the mega payment card brands were going to decree about the Payment Card Industry Data Security Standard (PCI DSS). The infosec industry speculated, raised concerns, and purported rumors. Yet, we had only a vague idea of what the future of PCI would hold for its subordinates. Then yesterday, the PCI DSS v1.1 was finally released! *sound the trumpets* It's time!
One Committee to rule them all
Announced is the formation of the PCI Security Standards Council (SSC). A fellowship of 5 with representatives from AMEX, Discover, JCB, MasterCard, and Visa. They serve as central authority overseeing updates to the PCI DSS, as well as training and certification of Qualified Security Assessors (QSA) and Approved Scanning Vendors (ASV). The payment card brands individually, and further to the acquiring banks, are responsible for enforcement of PCI DSS amongst merchants and service providers.
What does the Committee command?
PCI DSS commands compliance with 12 core requirements. Simple enough since it’s the same 12 from before. Changes to the standard are mostly for cosmetics, consistency, and clarity. The OWASP Top Ten remains the recommended best practice for software development, despite its creators saying this is not what it's meant for. The significant change in PCI DSS is the addition of section 6.6:
6.6 Ensure that all web-facing applications are protected against known attacks by applying either of the following methods:
• Having all custom application code reviewed for common vulnerabilities by an organization that specializes in application security
• Installing an application layer firewall in front of web-facing applications.
Note: This method is considered a best practice until June 30, 2008, after which it becomes a requirement.
Hoowah! Assemble the troops for battle.
This will take an army of thousands
Lets attempt to estimate the nation-wide monetary cost to merchants and workload required of "organization that specializes in application security". Netcraft says there are 96,854,877 sites and 497,833* SSL certificates in circulation. Assuming the vast majority of websites potentially accepting credit cards (CC) use SSL, we'll round up to 500,000 total certs in circulation. Assuming only 10% of websites using SSL accept CC's, that leaves a world of 50,000 websites needing source code reviews. Keep in mind we're only counting SSL/CC websites. PCI DSS section 6.6 says "all web-facing applications" from merchants need source code reviews, so the world may in fact be exponentially larger.
* Total Certs = 358,938 / 72.1%
(Sum of SSL certs and market shares of Verisign and GeoTrust)
A common source code review performed by the average reviewer on the average small-mid-sized web application costs about $40,000. At $150 per hour (bill rate), that’s 267 man-hours per review. Let's try some of my gorilla math.
To source code review all 50,000 websites each year requires:
- 13,350,000 total man-hours (50,000 * 267 hours)
- 6,675 qualified source code reviewers (13,350,000 / 2000 full-time hours per year)
- $2,000,000,000 annual economic burden on merchants! ($40,000 * 50,000)
Fall back behind the web application firewalls!
ModSecurity, an open source intrusion detection and prevention engine for web applications, may be just what organizations need to fulfill PCI DSS compliance obligations without the sticker shock. According to a recent Forrester Research report on Web Application Firewalls (Q2 June 2006), "...ModSecurity is by far the most extensively deployed Web application firewall, with more than 10,000 customers." and "ModSecurity's stringent implementation standards — build nothing unless you approach the highest level of security — will push the entire Web application firewall market toward higher-quality products." I've been recommending ModSecurity for a long time and my bet is we'll see huge surge in installations. Especially since commercial licensing, support, and a soon-to-be-released ModSecurity Console is on the horizon.
Weaknesses in the defenses
Validation of Compliance is an instrumental part of PCI DSS otherwise merchants and service providers could simply pay lip service to the payment brands. Approved Scanning Vendors (ASV) like WhiteHat Security ensure there are no high-level vulnerabilities in the web-facing networks and websites. PCI DSS and the Security Scanning Procedures documents provide guidance as to the scope of everything we’re supposed to scan, how, and how often. We’re instructed to do no harm, what reports must contain, and how results are to be interpreted.
"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).
Note: Quarterly external vulnerability scans must be performed by a scan vendor qualified by the payment card industry. Scans conducted after network changes may be performed by the company’s internal staff.
11.3 Perform penetration testing at least once a year and after any significant infrastructure or application upgrade or modification (such as an operating system upgrade, a sub-network added to the environment, or a web server added to the environment). These penetration tests must include the following:
11.3.1 Network-layer penetration tests
11.3.2 Application-layer penetration tests."
ASV's are informed of just about everything, EXCEPT WHAT VULNERABILITIES WE NEED TO BE ABLE TO FIND! I’ve not been able to find anything documented about the vulnerabilities, checks, or classes of attack capabilities required for ASV acceptance. Though to become an ASV, you need to pass the test.
“How to Become an Approved Scanning Vendor
For the actual test, each applicant runs its test tool(s) against the Council's test Web perimeter and submits its results. After remotely scanning the test infrastructure, the vendor must identify the vulnerabilities and misconfigurations found, and report its findings in both executive and detailed test reports.”
As I said, WhiteHat Security is an ASV and hence passed the test. We strongly believe being able to find all vulnerabilities all the time (the goal) is the only way to achieve adequate security. Since we go above and beyond, the minimum bar for passing didn’t matter much. However, without a solid minimum bar, any script-kiddy with a check-for-nothing-scanner could become an ASV and start providing insanely cheap PCI compliance reports complete with false sense of security at no extra charge. I’m also unable to do the same math for quarterly scans (as for source code review) because there is no way to gauge price per website.
Goes to show compliance and security are two different things.
4 comments:
Well that's exactly what is happening. We see it all the time, some useless "consultant" gets a copy of Nessus and is suddenly a "security guru." It saddens me what is passing for "secure" these days. We just underwent the PCI test and it was seriously a joke, most vulnerabilities were low hanging fruit and even the "difficult" ones weren't so much. It seems to me that requiring a web application firewall or code reviews is a good step but I would like to see it require both.
To poster of first comment:
Your PCI test was a joke because of the vendor you chose to perform the test. There are some PCI certified companies that have a more hands on approach and treat PCI as a black box application test more than a network level vulnerability assessment. There are still a lot of vendors that perform the PCI test with a set of slightly modified nasls. You can tell which companies do that based upon their PCI test pricing. Hopefully there will be new certifications requirements that will weed out the weak.
Anway, it was only a matter of time for PCI to differentiate betwixt Network and Application testing. Although, I find it funny they're calling it a penetration test. I doubt they'll allow or require actual penetration to occur.
We also just underwent a PCI test and I can't fathom what the biggest joke was: the test or the reactions.
The test was weak, the testers constantly asked the same things, and inconsistently called the same things by different names, some of which don't even make sense to the administrators of some section they tested.
Some tests they made had incoherent (and very likely the result of of copy and paste) contents, etc...
AFAIK the tester is a reputed auditory company.
The reactions... were... enlightening. A few minor problems had histerical reactions, and most major problems were faced with the "let's see how to curb this" mentality.
The choice of methods to meet 6.6 is a very interesting debate. On the one hand, you want to encourage the sound SDLC practices that come with code review. On the other, you want to achieve compliance as simply as possible. I recently wrote about the reasons you may wish to consider as your solution.
Post a Comment