Security Controls Are Useless If They're Not Turned On

Guest Columnist David Taylor is Research Director of the PCI Alliance, Founder of the PCI Knowledge Base, and a former E-Commerce and Security analyst with Gartner.

If you're thinking that the Hannaford security breach is a very isolated "blip" and that PCI compliance is the same as securing the enterprise against security breaches, you'd better think again. Why? It's not uncommon for merchants to turn on security controls shortly before an audit, and turn them off afterward.

In fact, one of the most surprising findings from the PCI Knowledge Base is that there are many security controls that spend most of their time "switched off" — and it turns out that they're not very effective when they're switched off. Seriously; it's true. Here are some examples of controls that are could be more effective than they are today:

  • Application Firewalls. The purpose of application firewalls is to monitor the content of communications, not just their source or the communication protocols, which is what a network firewall does. But because these firewalls do not intuitively know what is "legitimate" traffic, they have to "learn" this over time.

    So you can buy an application firewall, set it up and start "teaching" it about good and bad content, but while it's learning, it's not actually blocking any of the bad content. Here's the problem: the vast majority of companies leave their application firewalls in "learning" mode, for fear of pissing off the business units by stopping legitimate traffic. The business managers are fine with this "unobtrusive" security.

    The only problem is, you just wasted $30K to $100K on a security control that's adding zero benefit. Given that PCI DSS 6.6 will require either application firewalls or external code review as of this June, I'd have to vote for doing the external code review, since the application firewall is likely to be one of those "special needs" security tools, destined to repeat the fourth grade, over and over.

  • Network Firewalls. They've been around forever and they work just fine. No issue with that. The problem is that the effectiveness of network firewalls depends on a set of rules that are cryptic and highly customized and understood by very few people. But, hey, that's true of most security technology. The point is that PCI requires that these firewall rules be reviewed, which is great. But the standard allows for companies to provide a justification for "risky protocols" (such as FTP and Telnet, which are still pervasive) and that justification can be pretty cryptic.

    Over the years, companies have implemented many changes that require modifications to firewall rules (e.g., opening up ports, enabling special protocols) and the documentation on all this is often pretty weak. Companies cannot depend on relatively simple quarterly network scans and an annual review by an assessor—who is rarely a "firewall geek"—to catch all the problems. I recommend bringing in Certified Ethical Hackers who will go beyond standardized, automated penetration tests and actually find the problems with the network.

  • Database Access Controls. One of the major tenets of PCI is that you need to know who accessed what data, when and what they did with it or to it. The problem with most access control tools is that while they are very effective from the "outside in"—keeping out external bad folks—they are less effective at detecting what privileged users are doing. One of the things we've found when we have interviewed companies for the PCI Knowledge Base is that many companies have not yet tied data access controls into an identity management system.

    The closest thing most have is Microsoft Active Directory, which does not provide the level of security against privileged users exceeding their authority that is needed. Although PCI does require that access controls be managed outside of the directory system, it does not mandate the level of identity management/access control integration that would be needed to stop a privileged user from breaking into a database containing sensitive information and then using his/her permission level to cover his/her tracks. I recommend that readers investigate some of the access control tools specifically designed to control and monitor data access by privileged users.

    If you want to discuss this column or any other security or compliance issues, please send me an E-mail at [email protected] or visit to join the PCI Knowledge Base.