Once upon a time, I was retained to create a comprehensive PCI DSS-focused log review policies, procedures and practices for a large company. As I am preparing to handle more of such engagements (including ones not focused on PCI DSS, but covering other compliance or purely security log reviews), I decided to publish a heavily sanitized version of that log review guidance as a long blog post series, tagged “PCI_Log_Review.” It was written to be a complete and self-contained guidance document that can be provided to people NOT yet skilled in the sublime art of logging and log analysis in order to enable them to do the job and then grow their skills. It is focused on PCI DSS, but based on generally useful log review practices that can be utilized by everybody and with any regulation or without any compliance flavor at all.
This is the sixth post in the long, long series (part 1, part 2, part 3 – all parts). 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.
To be continued.
Follow PCI_Log_Review to see all posts.
Possibly related posts:
- Incident Log Review Checklist
- All posts tagged PCI_Log_Review
