Friday, December 24, 2010

Complete PCI DSS Log Review Procedures, Part 12

Once upon a time, I was retained to create a comprehensive PCI DSS-focused log review policies, procedures and practices for a large company.  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. It can be performed manually (at small log volumes), using free open source log analysis tools or using commercial log management or SIEM tools.
This is the 12th post in the long, long series (part 1, part 2, part 3all 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 (please consider reading from Part 1 – at this stage we are deep in the details and these pieces might seem out of context without reading earlier parts):

Validation of Log Review

Final and critical part of compliance-motivated log review is making sure that there is sufficient evidence of the process, its real-world implementation and diligence in following the log review process. The good news here is that the same data can be used for management reporting about the logging and log review processes, so you are not doing just for PCI DSS compliance.
Let’s determine what documentation should be produced as proof of log review.
First, the common misconception is that having the actual logs provides that. That is not really true: ”having logs” and “having logs reviewed” are completely different and sometime years of maturing the security and compliance program separates one and the other. Please make sure that your team members keep that in mind.
Just as a reminder, we have several major pieces that we need to prove for PCI DSS compliance validation. Here is the master-list of all compliance proof we will assemble. Unlike other sections, here we will cover proof of logging and not just proof of log review since the latter is so dependent on the former:
· Presence and adequacy of logging
· Presence of log review processes and its implementation
· Exception handling process and its implementation.
Now we can organize the proof around those areas and then build processes to collect such proof.
Proof of Logging
The first category is: proof of presence and adequacy of logging. This section is the easiest to prove out of the three.
The following items serve as proof of logging:
1. Documented logging policy, covering both logged events and details logged for each event
2. System / application configuration files implementing the above policy
3. Logs produced by the above applications while following the policy.
As stated previously, your QSA is the ultimate judge of what proof of compliance will be adequate for your organization. These tips has been known to be found adequate, but see disclaimers in earlier parts for details.
Proof of Log Review
The second category: proof of log review processes and its implementation. This section is harder to prove compared to the previous one.
The following items serve as proof of log review:
1. Documented logging policy, covering log review
2. Documented operational procedures, detailing the exact steps taken to review the logs
3. Records of log review tasks being executed by the appropriate personnel (some log management products create an audit log of reviewed reports and events; such audit trail should cover it – the case of manual review is covered below) – think about this item as “log review log”
4. Also, records of exceptions being investigated (next section) indirectly proves that log review is taken place as well.
Proof of Exception Handling
The third category: proof of exception handling process and its implementation. This section is by far the hardest to prove out of these three.
The following items serve as proof of log exception process:
1. Documented logging policy, covering exceptions and their handling
2. Documented operational procedures, detailing the exact steps taken to investigate exceptions found during log review (this document)
3. A log of all exceptions investigated with actions taken (“logbook”)

The above evidence should provide ample proof that the organization follows PCI DSS guidance with diligence. Let’s focus on producing this proof – the table has the details.
PCI Compliance Logging Sub-Domain Proof of Compliance How to Obtain Proof?
Proof of presence and adequacy of logging Documented logging policy Create policy, if not present
Proof of presence and adequacy of logging System / application configuration files After deployment, preserve the configuration files as a master copy
Proof of presence and adequacy of logging Logs produced by the above applications Collect sample logs and save as proof of compliance
Proof of log review Documented logging policy Create policy, if not present
Proof of log review Documented operational procedures <this document!>
Proof of log review Records of log review tasks being executed Either use the tool or create a “logbook” (format below)
Proof of log review Records of exceptions being investigated Create a “logbook” of investigations
Proof of exception handling Documented logging policy Create policy, if not present
Proof of exception handling Documented operational procedures <this document!>
Proof of exception handling A log of all exceptions investigated Create a “logbook” of investigations or “knowledge base”
These items directly map to PCI DSS Requirements 10 and PCI DSS validation procedures.
The critical item from the above list is “a logbook” that is used to record exception follow-up and investigation, thus creating powerful evidence of compliance with PCI DSS requirements. In a more advanced form, the logbook can even grow into an investigative “knowledge base” that contains all past exception analysis cases.
To be continued.
Follow PCI_Log_Review to see all posts.
Possibly related posts:

Dr Anton Chuvakin