A security manager needs a philosophy about how to address security issues, and I find that many elements of mine can be reduced to a few words that almost amount to mantras: “Obey the rule of least privilege,” “A company is only as strong as its weakest link,” “Security is a process, not a point solution” and “Trust but verify.”
This week I added a new mantra: “Compliance does not equal security.”
This truth has come home to me over the past several months as we have worked to obtain Level 1 PCI compliance. This effort is quite different from achieving other PCI levels, which merely required completing a self-assessment questionnaire and passing quarterly security scans. Instead, we must provide excruciating amounts of evidence to a third-party qualified assessor.
The process is exhausting, with more than 400 controls, many of which require the submission of evidence. For example, it isn’t enough to simply check the box stating, “I encrypt credit cards at rest.” Evidence must be submitted proving that the data is really encrypted. In the case of encryption at rest, we simply provide a screenshot of the encrypted value in the database or file system. To prove encryption in transit, we have to show a sample of network traffic (for instance, from a sniffer) that demonstrates that data is truly encrypted.
And yet, despite the tremendous effort to meet the compliance requirements, I have learned that compliance does not equal security. I will explain how I came to realize this.
One of the requirements is that companies must prove that they are logging certain activities and regularly reviewing the logs. Some companies will spend hundreds of thousands of dollars deploying state-of-the-art security incident event management infrastructure and hiring a team of security analysts to provide 24/7 monitoring. Others may hire a third party and offload the collection, correlation and analysis of events on a 24/7 basis. Such round-the-clock coverage is ideal for detecting indicators of compromise, because hacking activity can occur at any hour of the day, but my company can’t meet that standard. What we do is to log all events and use scripts to search for a few suspicious types of log entries — and if we don’t have a script for a particular type of suspicious log entry, we won’t see it. If an event is flagged, an email is sent to a distribution list, which we monitor every day, but not 24/7. I know — it’s a pathetic situation, and I plan to change it. But the thing is that our pathetic, patchwork monitoring passes PCI. That doesn’t mean, though, that it properly protects our organization. Compliance does not equal security.
Another example involves our VPN deployment. We use strong encryption in transit, with a requirement for multifactor authentication for access to our corporate network, and that is enough to pass PCI, no problem. But what PCI doesn’t uncover is the fact that a user with knowledge of VPN configuration settings can obtain VPN software and install it on any computer in the world, placing that untrusted device on our network. We can overcome that problem with Network Admissions Control or other forms of controls that restrict VPN access to only authorized, corporate-owned devices, and I do intend to address this shortcoming in that way sometime soon. The point is, though, that as far as Level 1 PCI is concerned, we’re good to go.
I have hardly exhausted the examples, but here is just one more, involving the requirements for antivirus and patch management. Most compliance activities represent a point-in-time state: We demonstrate to the auditor that at the time of the audit, all our PCs and servers were up to date with patches and endpoint protection. It would be far better if the auditor had us prove, via metrics, that we maintained a certain level of compliance throughout the year. Many companies rush to get all devices up to snuff for the auditor, and then relax until the next yearly audit.
Compliance is not mere window dressing, but it’s far from a guarantee of security. I will drive that point home as I seek additional budget and head count so that our organization can become more secure, and not merely compliant.
This week's journal is written by a real security manager, "Mathias Thurman," whose name and employer have been disguised for obvious reasons. Contact him at firstname.lastname@example.org.
Click here for more security articles.