Guest View: The Ultimate Security Conundrum
Written by Evan SchumanMost merchants are so focused on protecting credit card and social security numbers that they forget the very process of securing their environment creates a risk. All of the alerts and log data from all of the various network, application and database monitoring tools must be promptly reviewed and acted upon.
When these alerts and log files are allowed to "sit around" without being processed, the data and the lack of action become "evidence" that could be used to show negligence, in the event of a breach.
Over the past few weeks, I’ve been interviewing merchants and a Panel of Experts for the PCI Knowledge Base, which the PCI Alliance is building. Both the merchants and PCI Experts agree that security managers are often overwhelmed by the volume of data coming in from access control logs, network and application monitoring tools and intrusion detection systems.
For example, we interviewed a forensic technologist who stated that in more than 90 percent of the cases when he’s brought in after a breach, there are several unprocessed "threat alerts" that could have been used to prevent the breach, but they were ignored, usually because the security manager was overwhelmed by the volume of security logs and alert data that had to be reviewed on a daily or weekly basis, often manually.
The threat data is not centralized. The PCI security standards require the implementation of many different tools that generate alerts about both external and internal threats to confidential data. However, the question of how, and how often to monitor this data is left to the merchant. Many of the merchants we’ve interviewed report that they are using a number of manual procedures to review this data, and that alerts are "coming in from all over the place" and are only centralized in that it falls upon the security manager or CISO to review all this log data, across dozens of different tools, across multiple systems, each with its own user interface, of course.
Threat criteria is not consistent. One of the hardest tasks that security managers face is properly configuring and "tuning" the various logging, monitoring and alerting functions, so that the proper files and activities are being monitored, the volume of alerts is manageable, and there is enough intelligence in the system to sort out "false positives" so that they don’t waste the security manager’s time.
One problem is that PCI doesn’t require what is called "event correlation" or the automation of threat management across systems. It requires "regular" monitoring, leaving it up to the merchant to decide what that means. Such flexibility is appropriate and makes achieving compliance easier, but we’ve interviewed a number of merchants who have achieved compliance, but are having difficulty with identifying and managing threats across their various systems, and the manual review process is quite burdensome.
Evidence of potential breaches exists on many systems. One of the major security and financial risks to merchants, apart from security breaches themselves, is the fact that large volumes of these monitoring and access control logs exist on many different systems, and this data is "discoverable" by a plaintiff or forensic technologist, should a security breach occur.
PCI compliance has brought about an increase in the volume of this data by causing merchants to add new types monitoring and alerting functionality, and not requiring the management of this data be centralized or automated.
Don’t blame PCI or the card brands. A couple of managers I’ve interviewed suggested they were better off before PCI, because they weren’t so overwhelmed by this audit log data. But I’m pretty sure they were joking. The real problem is that upper management still needs to be "sold" on the need for Security Event Management (SEM) and "event correlation" solutions.
They aren’t on the PCI "checklist," so many merchants still haven’t implemented them. But the implementation of the monitoring and alerting tools does cause a major increase in the "level of pain" felt by the security manager or team, as they attempt to analyze the alert data across the many different security tools.
Centralize and Automate Log Review – PCI DSS 10.7 requires merchants to retain audit logs for at least a year. Your policies should require the same thing. But since this data could potentially be used as evidence against you in the event of a breach, it’s very important that you put into place the systems and procedures to centralize and automate (to the extent possible) the review of the various types of logs. No one knows this better than security managers who are faced with the burdensome task of manual log review and analysis.
Find out log review best practices and tools from your peers. One of the purposes of the interviews the PCI Alliance is conducting is to create a "PCI Knowledge Base" which is a website where merchants can go to find out what their peers are going, and get advice from a Panel of Experts. To find out more, and participate in the creation of this PCI Knowledge base, click here.
February 1st, 2008 at 2:11 pm
This is sort of like the 3 mile island nuclear incident. You can get to a point where there are so many alarms that you don’t know what’s going on when they all go off. The problem with PCI in general is that it does not mean that a system is secure, only that the system passed some general idiot checks. Take a small business owner who can just barely operate their cash register and ask them to identify when their system is compromised, good luck getting a accurate result from that.