Harnessing Log Data to Meet PCI DSS Requirements

The good news is that Payment Card Industry compliance has been on the rise. As of October 2009, 97% of Level 1 merchants and 94% of Level 2 merchants were already compliant, according to Visa.

The good news is that Payment Card Industry compliance has been on the rise. As of October 2009, 97% of Level 1 merchants and 94% of Level 2 merchants were already compliant, according to Visa.

However, this seems to have come at a significant and growing cost. The National Retail Federation (NRF) estimates that over a $1 billion has been spent on PCI compliance. Gartner reported a five-fold increase in the cost of PCI compliance over an 18-month period. When you factor in breaches, the cost swings upwards even faster. According to the Identity Theft Resource Center (ITRC), the number of data breaches has more than tripled between 2005 and 2009.

Study: Cost of data breach in U.S. is highest world wide

So what does this all mean? At some level the statistics suggest the cost of compliance outweighs the benefits. In other words, PCI compliance is still just a checkbox and doesn't actually equate to stronger security for cardholder data. That belief crops up time and again in compliance blogs and forums.

A Guide to Practical PCI Compliance

What is needed, it seems, is a technology based solutions that can:

* Streamline audits and reduce the cost of compliance.

* Deliver continuous visibility into threats and breaches rather than just satisfying lagging indicators of security that audits call for.

* Extend beyond cardholder data and beyond PCI to other compliance initiatives.

SIEMplifying PCI DSS compliance

That's where log data comes in. Logs are a source of readily available information that are relevant to PCI well beyond just Requirement 10, which explicitly discusses log analysis. Consider testing procedure 1.2, which calls for firewall configurations that deny traffic from "untrusted" networks and hosts into the CDE (Cardholder Data Environment). How do you monitor for compliance against that testing procedure today?

One option is to periodically and manually inspect firewall rules to ensure they adhere to testing procedure 1.2. However, that's a lagging indicator and the configuration may be inadvertently or maliciously altered between audits to allow unauthorized traffic.

Even if an altered rule is detected it would be after the fact. Repeat the exercise for other testing procedures and you'll find the same limitation is widespread. Simply put, manually monitoring individual infrastructure on a periodic basis is both ineffective and costly. It also limits visibility to the specific piece of infrastructure you are auditing. Most importantly, it's after the fact -- reactive rather than proactive.

If logs can help overcome that significant hurdle, the obvious question is why haven't logs been leveraged more widely? Well, the barrier for many organizations is that they attempt to tackle this in-house and hit a brick wall given the many associated challenges.

Commercial Security Information and Event Management (SIEM) tools can go a long way towards unleashing the power of logs for proactive compliance with PCI DSS as well as other mandates. However, commercial solutions vary significantly and log monitoring for PCI brings its own set of unique challenges. So as you turn to SIEM vendors to tackle PCI in a new and better way, consider solutions that can tackle the log monitoring challenges described below.

Log monitoring challenges in the context of PCI compliance

Log collection -- Most PCI merchants support an array of log sources ranging from firewalls and IDS/IPS systems to routers, databases, operating systems, hosts and applications. This makes out-of-the-box coverage and device support a critical requirement. Make sure the evaluated solutions support a wide range of device types while also delivering support for all leading vendors, those you have and those you plan to add. Compliance (for PCI or other mandates) will also require including commercial and home-grown applications. It is paramount for the solution to provide a way to collect logs from home-grown and legacy applications easily.

Log storage. Once collected, logs must be stored efficiently and effectively. Organizations that implement homegrown log infrastructures often end up with silos of distributed log servers that are very hard to manage. Given long-term log retention requirements from PCI and other mandates, storage can quickly exceed 10's or even 100's of terabytes. So look for solutions that can provide efficient storage through compression and through automation of retention policies. Ideally, the solution should also allow you to leverage external storage-area networks.

Log analysis. A basic problem with log analysis is that each log source relies on a different and often cryptic format, which is very difficult to analyze. Unless these formats are merged, the burden of familiarity with the hundreds of different formats or log "languages" falls on the user. Commercial solutions should convert the various native different formats into a unified format to simplify analysis.

Another significant challenge is that logs generally lack the asset and user context needed to enable effective analysis. For example, many logs contain IP addresses but not the host name, the role of the host, whether it stores cardholder data, where it's located, or what regulations it's subject to.

Log analysis is even harder when it comes to users. In fact, user information is often entirely missing. For example, router logs have IP addresses not user names. So you would have to translate the available IP address to a host name and in turn to the owner. You would also have to know their roles and privileges and be aware of the different identities of each user to create a composite picture of user activity.

SIEM solutions can overcome these challenges through an asset and user model that is dynamically referenced. However the solution also need to be session aware to successfully attribute log activity to users and must come with identity adapters that enable pulling in user roles and privileges from IDM systems.

PCI content. PCI DSS imposes considerable audit reporting requirements. Some log management or SIEM solutions provide out-of-the-box content but few clearly map reports and alerts to specific PCI DSS testing procedures. Ideally monitoring content should support audit reporting requirements and also deliver continuous visibility into threats to cardholder data through real-time log analysis rules. So make sure authoritative content is available to automate audit efforts for PCI as well as other regulations you are subject to.

2020 Vision in 2010

PCI DSS is at an important junction. Compliance levels are up but the rising cost of compliance suggests continued inefficiencies. At the same time the growing incidence, cost and sophistication of breaches remains unchecked. In the face of this contradiction, the solution certainly cannot lie in periodic audits and more point security tools that deliver silos of security context and limited visibility into actual threats.

Logs provide a readily available and largely untapped source of information that can be harnessed to introduce significant efficiencies into compliance projects for PCI and other mandates. Logs can also enable continuous visibility into threats to cardholder data. SIEM solutions have been widely used to unleash this value and overcome the many challenges of home-grown log infrastructures. Given the promise of efficiency and visibility -- 2010 seems like just year to prioritize a SIEM investment.

ArcSight is a global provider of security and compliance management solutions that protect enterprises and government agencies.

Read more about wide area network in Network World's Wide Area Network section.

This story, "Harnessing Log Data to Meet PCI DSS Requirements" was originally published by Network World.

Copyright © 2010 IDG Communications, Inc.

7 secrets of successful remote IT teams