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 cannot and do not make anybody compliant!
This is the 14th 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):
Here is an example following the above pattern:
1. Date/time/time zone this logbook entry was started: November 23, 2009, 4:15PM PST
2. Name and role of the person starting the logbook entry: Anton Chuvakin, principal consultant.
3. Reason the logbook entry 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):
Time/date of log: 10/21/2009 10:01:23 PM PST
4. Detailed on why the log is not routine and why this analysis is undertaken: this event ID (Windows event ID 11) from this application event source (Source crypt32) was never seen before on any of the systems where logs are reviewed across our organization.
5. Information about the system that produced the exception log record or the one this log exception is about
a. Hostname: OLGA.example.com
b. OS: Windows XP SP 3
c. Application name: N/A
d. IP address(s): 10.1.1.1
e. Location: Home office
f. Ownership (if known): Olga Chuvakin, President and CEO
g. System criticality (if defined and applicable): critical, main laptop of the executive
h. Under patch management, change management, FIM, etc: yes
6. Information about the user whose activity produced the log: N/A, no user activity involved
7. Investigation procedure followed, tools used, screenshots, etc: procedure for “Initial Investigation” described above
8. Investigative actions taken: following the procedure for “Initial Investigation” described above, it was determined that this log entry is followed by a successful completion of the action logged. Specifically, on the same day, 1 second later the following log entry appeared:
This entry indicates the successful completion of the action referenced in our exception log entry and thus no adverse impact from the error/failure is present.
9. People contacted in the course of the log analysis: none
10. Impact determine during the course of the analysis: impact was determined to be low to non-existent; no functionality was adversely affected, no system was at risk.
11. Recommendations for actions, mitigations (if needed): no mitigation needed, added this log entry to baseline to be ignored in the future as long as the subsequent log entry exists.
The logbook of that sort is used as compliance evidence since it establishes log exceptions follow-up, required in item 10.6.a of PCI DSS validation procedure, which states “Obtain and examine security policies and procedures to verify that they include procedures to review security logs at least daily and that follow-up to exceptions is required.”
The logbook (whether in electronic or paper form) can be presented to a QSA or other auditor, if requested. I recommend retaining the log book for 3 years or at least 2x of the log retention period (1 year for PCI DSS)
To be continued.
Follow PCI_Log_Review to see all posts.
Possibly related posts: