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 allAnnounced 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 thousandsLets 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)
If anyone wants to help adjust my numbers based on better figures, by all means let me know.
My thinking is there’s no way merchants are going to endure even close that much cost for source code reviews even if there were over 6,000 qualified source code reviewers read to go. That means 2008 might actually come in 2007.
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 defensesValidation 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 tests11.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 VendorFor 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.