When reviewing changes to the PCI DSS requirements in the 3.0 version of the standard, we noticed some interesting changes to the language in a couple of requirements that are addressed by our IDS, Alert Logic Threat Manager and our WAF, Alert Logic Web Security Manager. The language change talks about using “techniques” instead of or in addition to “systems.” Here’s the language from 11.4 as an example: 11.4 Use intrusion-detection and/or intrusion-prevention techniques to detect and/or prevent intrusions into the network. Monitor all traffic at the perimeter of the cardholder data environment as well as at critical points in the cardholder data environment, and alert personnel to suspected compromises. Whether you use our IDS and/or WAF or one from another vendor, you might be asking yourself if you no longer need to have a system in place. The test procedures language makes it clear that you do: 11.4.a Examine system configurations and network diagrams to verify that techniques (such as intrusion-detection systems and/or intrusion-prevention systems) are in place to monitor all traffic:
- At the perimeter of the cardholder data environment
- At critical points in the cardholder data environment.
Before I joined Alert Logic, I was a senior executive in a QSA firm and a QSA myself. From a QSA perspective, the language in the test procedure is more important than what’s described in the requirement itself. The test procedures are detailed and prescriptive, making it easy for the assessor to determine if a merchant/service provider is meeting PCI DSS requirements or not. And if you’re thinking you can sway the assessor’s option, I should also note that assessors are themselves audited by the PCI Security Standards Council so they tend to be understandably conservative in their approach. All that said, we like that some of the language in the PCI DSS standards is becoming more open. This has been a trend as PCI has evolved from the very first version of the Visa CISP standard. Back in those days, there were even references to specific vendors like Tripwire for file integrity monitoring. While that language was great for that vendor’s business (and they do offer a solid product), it’s good to see the PCI DSS updating language to be a bit broader. I also like the “techniques” language in that I hope it gets merchants thinking of additional ways they can detect and/or prevent intrusions. At re:Invent last year , for example, there were some interesting sessions on using techniques that monitoring your AWS billing and sending yourself alerts if there was an anomaly that might indicate someone was using your AWS account for their own purposes. They had several other interesting examples and if you’re interested, you can watch the session at https://reinvent.awsevents.com/recap2013.html. SIEM technologies such as Alert Logic’s Next Generation Expert System, which combine data from multiple sources such as log and more traditional intrusion detection systems can be very effective ‘intrusion detection techniques’ if properly implemented, maintained, and monitored. So there’s definitely room to complement your IDS systems with intrusion detection techniques. Alert Logic & Intersec Worldwide: PCI DSS 3.0 Webcast There’s much more to PCI DSS 3.0, as we’ve outlined in previous blog articles. We’re also hosting a webcast in a couple of weeks with one of our QSA Partners, Jeff Tutton from Intersec Worldwide. If you’d like to learn more about PCI DSS 3.0 changes and how they’ll affect you, please register and join us on March 4, 2014.