Once upon a time, I was retained to create a comprehensive PCI DSS-focused log review policies, procedures and practices for a large company. They are focused on PCI DSS compliance, 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. The practices can be implemented with commercial log management or SIEM tools, open source log analysis tools or manually. As you undoubtfully know, tools alone don’t make anybody compliant!
This is the 13th 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 (please consider reading from Part 1 – at this stage we are deep in the details and these sections might seem out of context without reading earlier parts):
Logbook – Evidence of Exception of Investigations
How to create a logbook that proves that you are reviewing logs and following up with exception analysis, as prescribed by PCI DSS Requirement 10? The logbook is used to document everything related to analyzing and investigating the exceptions flagged during daily review. While the same logbook approach is used in the incident handling process (such as SANS Incident Response Workflow), in this document it is utilized as compliance evidence.
The logbook should record all systems involved, all people interviewed, all actions taken as well as their justifications, what outcome resulted, what tools and commands were used (with their results), etc.
Here is one recommendation for a logbook entry:
Recommended Logbook Format
Logbook entry:
1. Date/time/time zone this logbook entry was started
2. Name and role of the person starting the logbook entry
3. Reason it is started: log exception (copied from log aggregation tool or from the original log file), make sure that the entire log is copied, especially its time stamp (which is likely to be different from the time of this record) and system from which it came from (what/when/where, etc)
4. Detailed on why the log is not routine and why this analysis is undertaken
5. Information about the system that produced the exception log record or the one this log exception is about
a. Hostname
b. OS
c. Application name
d. IP address(s)
e. Location
f. Ownership (if known)
g. System criticality (if defined and applicable)
h. Under patch management, change management, FIM, etc.
6. Information about the user whose activity produced the log (if applicable)
7. Investigation procedure followed, tools used, screenshots, etc
8. Investigative actions taken
9. People contacted in the course of the log analysis
10. Impact determine during the course of the analysis
11. Recommendations for actions, mitigations (if needed)
To be continued.
Follow PCI_Log_Review to see all posts.
Possibly related posts:
- Incident Log Review Checklist
- All posts tagged PCI_Log_Review
