PCI DSS 3.0 – Requirement 6.6 (WAF): Monitoring Only – “Is configured to either block web-based attacks, or generate an alert.”

Today I was working on a presentation about PCI DSS 3.0. Since a major client of me is an international payment service provider doing credit card transaction, I am quite familiar with PCI DSS 2.0. I have already read the new Standard a few months ago, but today I stumbled about an interesting sentence in the Testing Procedure for PCI Requirement 6.6 (WAF) that makes me wonder about PCI DSS 3.0.

PCI DSS Requirement 6.6 forces companies to either use a Web Application Firewall (or some technical equivalent) or forces companies to perform manual or automated application vulnerability security assessments after every change:

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 by either of the following methods:
[..]
– 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.

Doing automated application vulnerability security assessment is a little bit tricky and needs a software development team and process on a high maturity level. I assume that most companies comply with Requirement 6.6 by using a Web Application Firewall (WAF). Companies can write their own rule sets for a WAF, use a rule set from the WAF’s vendor or use some rule set from OWASP (OWASP CRS Core Rule Set). Anyway it is useful to activate the blocking / enforcing mode of the WAF to actually prevent attacks. That is industry best practice and is or better maybe was required by PCI DSS when companies deployed a WAF to comply with Requirement 6.6

Despite a lot other changes there is a new sentence in the Testing Procedure of PCI Requirement 6.6, which seems a little awkward. Pay attention to the last sentence:

6.6 For public-facing web applications, ensure that either of the following methods is in place as follows:
[..]
Examine the system configuration settings and interview responsible personnel to verify that an automated technical solution that detects and prevents web-based attacks (for example, a web-application firewall) is in place as follows:
– Is situated in front of public-facing web applications to detect and prevent web-based attacks.
– Is actively running and up to date as applicable.
– Is generating audit logs.
Is configured to either block web-based attacks, or generate an alert.

So, I want to repeat it: WAF “Is configured to either block web-based attacks, or generate an alert.” Sorry, but what the fuck? After years of PCI DSS now it is okay to deploy a WAF in monitoring mode. At least it needs to generate alerts…

If found two links on the web, which also states this as a problem. Someone in a high position at Gartner[1] and some slides about PCI 3.0[2]. I tried to clarify this with our QSA Company, but just did a short answer, that a WAF needs to block attacks and no comment to this last sentence in Testing Procedure of 6.6. I decided to write an E-Mail to the PCI DSS Council and hope to get an answer that explains it. I will post the answer, if and once I get one.

For the security of customers’ credit card information I really hope this is some sort of mistake or typing error. Anyway I assume there will be some QSAs out in the world, which will accept a WAF in monitoring mode – It doesn’t matter if it was an error, if PCI DSS is treated like a law text and not correctly interpreted. And if this is no error and done on purpose, I wouldn’t really understand that change of mind in the PCI Council.

[1] http://blogs.gartner.com/anton-chuvakin/2013/11/08/briefly-on-pci-dss-3-0/
[2] https://www.netspi.com/blog/entryid/207/things-not-to-overlook-in-the-new-pci-dss-3-0

10/30/2014: The Council’s response.

The little HOB-Brandstätter shitstorm against OpenSSL/Open Source

I usually write my blog posts in German. Due to the great effort of Mr. Klaus Brandstätter (HOB’s CEO) I decided to write a post in English. As you may have already read in the Wall Street Journal or online (http://www.hobsoft.com/news/news220414.jsp) Mr. Brandstätter is advertising his company’s products by fighting a very old war against Open Source Software.

Mr. Brandstätter put his very bad example of an advertisement in various major German newspapers, too. After launching his little shitstorm against Open Source and OpenSSL he is already getting a very bad response in the German Open Source Community. Last month only few people knew HOB or Brandstätter, now he is getting famous in way he may not want to.

We all know that Heartbleed was a very bad bug and that there were some mistakes made. But this is no reason to personally attack the developers of OpenSSL and to claim that Open Source is written by unqualified people who aren’t adults. While big companies are starting financial support for OpenSSL and other critical products, HOB is attacking OpenSSL, Open Source and its developer.

We learned so far: Klaus Brandstätter dislikes Open Source very much. But instead of using commercial products for his website, the URL https://www.hobsoft.com is powered by Open Source.

Apache/2.0.52 (Unix) mod_ssl/2.0.52 OpenSSL/0.9.7k mod_jk/1.2.6 PHP/5.2.0 Server at www.hobsoft.com Port 443

You may ask, why aren’t they using their own HOB SSL? Don’t know. Maybe OpenSSL is still much more secure than HOB SSL? Or HOB SSL is too expensive and OpenSSL is free?

And by the way, do not get confused about this stuff that Heartbleed can be used in a denial of service attack. Neither is that true under realistic circumstances nor is it the real problem of Heartbleed. But keep in mind: Someone who is turning 60 this year, learned how to program in high school, wrote a million lines of code and understands Heartbleed has to be right. ;-)