When you go through the PCI-DSS standard, while in most part, the sections are clear, there are some that just annoys the heck out of me, for good reasons.
Stateful inspection and Anti-spoofing in firewalls – I know these are useful features, but it is extremely rare these days to encounter clients going for PCI-DSS that own firewalls without these capabilities inbuilt. Even the humble ScreenOS running on your tiny SGs (Juniper) are enabled by default. While this isn’t an issue, we’ve faced vexing times when our clients are sometimes asked by their QSA, to show the firewall rules that prove that Stateful inspection and anti-spoofing is turned on. We have to come in and explain to them that its already enabled by default, and they insist on us testing and showing them traffic captures. Sometimes, I just show them the manual and entitle my email “RTFM: Stateful Inspection was first introduced in 1994.” You would think that PCI would do something better than to ask this question.
AntiVirus and AntiMalware – the researchers at Imperva, a couple of years back, did a study of effectiveness of antiviruses.They collected 82 new computer viruses and ran the malware against antiviruses from some of the largest companies like Symantec, Kaspersky, McAfee. The results: initial threat detection rate was 5 percent. That’s detection. This means 95% of malware is undetected. I don’t know how strong this hypothesis is, but frankly, we have known for years antiviruses, while there are limited uses, presents to us a false sense of security. Just because the antivirus says, “ALL IS SECURED” doesn’t really mean anything. The annoyance here is not that PCI has antivirus as part of their controls, they dedicated an entire requirement to it. It’s not effective – move on!
Confusion of application testing – Requirement 6.6 states:
For public-facing web applications, address new threats and vulnerabilities on an ongoing basis and ensure these applications are protected against known attacks by either of the following methods:
a) Reviewing public-facing web applications via manual or automated application vulnerability security assessment tools or methods, at least annually and after any changes
b) Installing an automated technical solution that detects and prevents web-based attacks (for example, a web-application firewall) in front of public-facing web applications, to continually check all traffic.
Note: This assessment is not the same as the vulnerability scans performed for Requirement 11.2.
Now, we need to clarify this because this is obfuscation. Note the nice caveat they put into 11.2. Now, if you go to 11.2, you get a whole bunch of requirements for vulnerability scans, quarterly ASV etc.This is understood, right
So the above, you would surmise this: if I have a WAF (web application firewall), I do not need to do any web applications review, correct? What IS a web application review anyway? In a lot of instance, QSA will interpret it as web application testing, covering OWASP top 10. In pentest world this is called WEB APP PENTEST. This tests issues like cross site scripting, validation etc. You can find more here
https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project
A web app PT can set you back around RM10 – 25K depending on your web app and the provider. I’ve seen web applications go into the RM50 – 80K regions before for massive applications, but in general for a web application payment system, you would get that range (unless the provider is looking to rip you off, in which case I suggest you give us a buzz).
So if you have 10 – 20 Web App, that would set you back a mile, so the suggestion is to “Let’s invest in WAF”, where you pay a license and every year you don’t have that WEB APPLICATION testing headache siting on your books. In the long run, it makes more sense if you have a lot of web applications to test.
Now, here is the PCI problem.
Requirement 11.3 – Implement a methodology for penetration testing that includes the following:
blah blah blah
– Defines application-layer penetration tests to include, at a minimum, the vulnerabilities listed in Requirement 6.5
Unfortunately the presence of 11.3 renders the earlier requirement choice useless, because now QSA interprets at despite having invested in WAF, they are still insisting on getting 11.3 passed, which requires this application layer PT!
My question to the PCI-SSC, why don’t you include this 11.3 caveat in the earlier 6.6 requirement instead of the useless 11.2 caveat which anyone knows how to read? And if my interpretation is wrong, I am going to war against some of these QSAs because they basically said, it’s nice to have WAF, but you still need to do App PT. In fact, one of them actually said: “Well, the advantage is that you are more secure.” Yes – but our client’s goal was to pass PCI. If they wanted financial modelling and investment advise from you, they would ask it, if not, just do our job and interpret the standards properly! Will someone from PCI-SSC actually clarify this because I’ve talked to some QSAs on either side of this opinion – some say WAF OR APP PT, some say, APP PT regardless of WAF.
To be safe – get your QSA to interpret this before making a decision to invest in WAF, because this is a major roadblock in a lot of cases we are in.
