Complete PCI DSS Log Review Procedures Part 5

Sunday, December 26, 2010

Anton Chuvakin


This is the fourth post in the long, long series (part 1, part 2, part 3, part 4). A few tips on how you can use it in your organization can be found in Part 1. You can also retain me to customize or adapt it to your needs.

And so we continue with our Complete PCI DSS Log Review Procedures: Periodic Log Review Practices and Patterns

This section covers periodic log review procedures for applications in scope for this project. Such review is performed by either application administrator or security administrator (see section Roles and Responsibilities above).

Such review can be performed using:

  1. automated tools (which is explicitly allowed in PCI DSS), or
  2. manually, if such automated tools are not available or do not support log types from PCI DSS application.

Let’s build the entire end-to-end procedures for both cases and then illustrate it using examples from various log sources, commonly in scope for PCI DSS.

The basic principle of PCI DSS periodic log review (further referred to as “daily log review” even if it might not be performed daily for all the applications) is to accomplish the following:

  • Assure that card holder data has not been compromised by the attackers
  • Detect possible risks to cardholder data, as early as possible
  • Satisfy the explicit PCI DSS requirement for log review.

Even given that fact that PCI DSS is the motivation for daily log review, other goals are accomplished by performing daily log review:

  • Assure that systems that process cardholder data are operating securely and efficiently
  • Ensure that other regulations and frameworks prescribing log review are complied with
  • Reconcile all possible anomalies observed in logs with other systems activities (such as application code changes or patch deployments)

In light of the above goals, the daily log review is built around the concept of “baselining” or learning and documenting normal set of messages appearing in logs.

Baselining is then followed by the process of finding “exceptions” from the normal routine and investigating them to assure that no breach of cardholder data has occurred or imminent.

The process can be visualized as follows:


Let’s start from building a baseline for each application.

Before PCI daily log review is put into practice, it is critical to become familiar with normal activities logged on each of the applications.

The main baseline to be built around log message types. For example, in case of Windows OS event logs:


If the above message is seen the first time and we confirm that the message does not indicate a critical failure of cardholder data security, we can add it to the expected baseline of observed event log types.

To be continued...

Cross-posted from Security Warrior

Possibly Related Articles:
PCI DSS Windows Log Management Data Loss Prevention Operating Systems
Post Rating I Like this!
The views expressed in this post are the opinions of the Infosec Island member that posted this content. Infosec Island is not responsible for the content or messaging of this post.

Unauthorized reproduction of this article (in part or in whole) is prohibited without the express written permission of Infosec Island and the Infosec Island member that posted this content--this includes using our RSS feed for any purpose other than personal use.