This is the thirteenth post in the long, long series (part 1, part 2, part 3, part 4, part 5, part 6, part 7, part 8, Part 9, part 10, part 11, part 12). 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.
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
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
c. Application name
d. IP address(s)
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, mitigation (if needed)
Cross-posted from Security Warrior