Complete PCI DSS Log Review Procedures Part 6

Sunday, January 02, 2011

Anton Chuvakin

Ebb72d4bfba370aecb29bc7519c9dac2

This is the sixth post in the long, long series (part 1, part 2, part 3, part 4, part 5). 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:

Creating Log Message Types

It is important to note that explicit event types might not be available for some log types. For example, some Java application logs and some Unix logs don’t have explicit log or event types recorded in logs.

Thus, what is needed is to create an implicit event type. The procedure for this case is as follows:

1. Review the log message – either review and identify what application or device produced  it (if multiple logs are collected together)

2. Identify which part of the log message identifies what it is about

3. Determine whether this part of the message is unique

4. Create an event ID from this part of the message

Even though log management tools perform the process automatically, it makes sense to go through an example of doing it manually in case manual log review procedure is utilized. For example:

Example 1

1. Review the log message

The log message is:

[Mon Jan 26 22:55:37 2010] [notice] Digest: generating secret for digest authentication..

2. Identify which part of the log message identifies what it is about

It is very likely that the key part of the message is “generating secret for digest authentication” or even “generating secret”

3. Determine whether this part of the message is unique

A review of other messages in the log indicates that no other messages contain the same phase and thus this phrase can be used to classify a message as a particular type.

4. Create an event ID from this part of the message

We can create a message ID or message type as “generating_secret.” Now we can update our baseline that this type of message was observed today.

Let’s go through another example using Java-based payment application logs.

[A.C. – sorry, sanitized]

Initial baseline can be quickly built using the following process, presented below for two situations: with automated log management tools and without them.

In addition to this “event type”, it makes sense to perform a quick assessment of the overlap log entry volume for the past day (past 24 hr period). Significant differences in log volume should also be investigated using the procedures define below.

In particular, loss of logging (often recognized from a dramatic decrease in log entry volume) needs to be investigated and escalated as a security incident.

Cross-posted from Security Warrior

Possibly Related Articles:
4534
PCI DSS
Data Loss PCI DSS Compliance Log Management Assessments
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.