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 third post in the long, long series (part 1, part 2)... prepare to see lots of process flow charts. BTW, I will stop posting this intro starting from the next post in the series.
A few tips on how you can use it in your organization:
- If you need to establish log review practices to satisfy PCI DSS Requirement 10.6 “Review logs for all system components at least daily”, feel free to steal from this document and adapt it tor your environment. I can do that for you too.
- There is a slight bias towards application and OS logging in this document (as per client request) – an you do need to review network and security device logs as well. The methods and practices apply to them as well.
- This was created before PCI DSS 2.0 release, but has been checked to “comply” with the most recent standard (and Requirement 10 has not changed much in 2.0)
- A QSA looked at it and liked it– but YMMV. Your QSA is always the ultimate authority in regards to what will “make you compliant”
- Don’t forget to buy me a beer if you find it useful. Better – contract me to create something similar for your organization. Are you doing a good job with log review today?
And so we continue:
Next, one needs to address all of the confidentiality, integrity and availability (CIA) of logs. Section 10.5.1 of PCI DSS covers the confidentiality: “Limit viewing of audit trails to those with a job-related need.” This means that only those who need to see the logs to accomplish their jobs should be able to. For example, one of the reasons is that many los that record authentication decisions (such as Unix and Windows) will always contains usernames. While not truly secret, username information provides 50% of the information needed for successful password guessing (password being the other 50%). Moreover, due to users mistyping their credentials, it is not uncommon for passwords themselves to show up in logs. Also, poorly written payment applications might result in a password being logged together with the URL in web server logs.
Next comes “integrity.” As per section 10.5.2 of PCI DSS, one needs to “protect audit trail files from unauthorized modifications.” This one is obvious, since if logs can be modified by unauthorized parties (or by anybody) they stop being an objective record of system and user activities.
However, one needs to preserve the logs not only from malicious users, but also from system failures and consequences of system configuration errors. This touches upon both the “availability” and “integrity” of log data. Specifically, Section 10.5.3 of PCI DSS covers that one needs to “promptly back-up audit trail files to a centralized log server or media that is difficult to alter.” Indeed, centralizing logs to a server or a set of servers that can be used for log analysis is essential for both log protection as well as increasing log usefulness. Backing up logs to DVDs (or tapes, for that matter) is another consequence of this requirement. One should always keep in mind that logs on tape are not easily accessible and not searchable in case of an incident – and PCI DSS mandates immediate availability of 3 months of log data [A.C. – with a slight change in PCI DSS 2.0]
Many pieces of network infrastructure such as routers and switches are designed to log to an external server and only preserve a minimum (or none) of logs on the device itself. Thus, for those systems, centralizing logs is most critical. Also, requirement 10.5.4 of PCI DSS states the need to “copy logs for wireless networks onto a log server on the internal LAN.”
To further decrease the risk of log alteration as well as to enable proof that such alteration didn’t take place, Requirement 10.5.5 calls for the “use file integrity monitoring and change detection software on logs to ensure that existing log data cannot be changed without generating alerts.” At the same time, adding new log data to a log file should not generate an alert since log files tend to grow and not shrink on their own unless logs are rotated or archived to external storage. File integrity monitoring systems use cryptographic hashing algorithms to compare files to a known good copy. The issue with logs is that log files tend to grow due to new record addition, thus undermining the missing of integrity checking. To resolve this contradiction, one should note that integrity monitoring can only assure the integrity of logs that are not being actively written to by the logging components – some algorithms also exist to detect any change but addition.
10.6
The next requirement is truly one of the most important as well as one of the most often overlooked. Many PCI DSS control implementers simply “forget” that PCI Requirement 10 does not just call for “having logs,” but also for “having the logs AND looking at them.” Specifically, Section 10.6 states that the PCI organization must, as per PCI DSS, “review logs for all system components at least daily. Log reviews must include those servers that perform security functions like IDSes and AAA servers (e.g., RADIUS).” The rest of this document covers the detailed log review procedures and practices.
Thus the requirement covers the scope of log sources that need to be “reviewed daily” and not just configured to log, and have logs preserved or centralized. Given that a large IT environment might produce gigabytes of logs per day, it is humanly impossible to read all of the logs line by line. That is why a note is added to this requirement of PCI DSS that states that “Log harvesting, parsing, and alerting tools may be used to achieve compliance with Requirement 10.6.” This document will cover both manual and automated log review.
10.7
The final requirement (10.7) deals with another important logging question— log retention. It says: “retain audit trail history for at least one year, with a minimum of three months online availability.” [A.C. - as per PCI DSS 1.2.1] Thus, if you are not able to go back one year and look at the logs, you are in violation.
So, let us summarize what we learned so far on logging in PCI:
• PCI Requirement 10 calls for logging specific events with a pre-defined level of details from all in-scope systems
• PCI calls for tying the actual users to all logged actions
• All clocks and time on the in-scope systems should be synchronized
• The C-I-A of all collected logs should be protected
• Logs should be regularly reviewed; specific logs should be reviewed at least daily
• All in-scope logs should be retained for at least one year
Now we are ready to dig deeper to discover that logs and monitoring “live” not only within Requirement 10, but in all other PCI requirements. While many think that logs in PCI are represented only by Requirement 10, reality is more complicated: logs are in fact present, undercover, in all other sections.
To be continued.
Follow PCI_Log_Review to see all posts.
Possibly related posts:
- Incident Log Review Checklist
- All posts tagged PCI_Log_Review
