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 fifth 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:
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:
- automated tools (which is explicitly allowed in PCI DSS), or
- 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.
Follow PCI_Log_Review to see all posts.
P.S. Today is my birthday – gifts and congrats are accepted anytime
Possibly related posts:
- Incident Log Review Checklist
- All posts tagged PCI_Log_Review