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 second post in the long, long series (part 1 is here)... prepare to see lots of process flow charts.
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:
Role and Responsibilities
The following roles are mentioned in the document and are involved in Log Review process.
| Role | Responsibility | Example Involvement in Log Review |
| Application administrator | Administers the application | Configured application logging settings, may perform daily log review for operational reasons |
| System or network administrator | Administers the underlying operating system or network | Configured logging settings, may perform daily log review for operational reasons |
| Application business owner | Business manager who is responsible for the application | Approves the changes to application configuration required for logging and log review |
| Security administrator | Administers security controls on one or more systems or applications | Configured security and logging settings, performs daily log review (not of his own activities!) |
| Security analyst | Deals with operational security processes | Accesses security systems and analyzes logs and other data, performs daily log review |
| Security director or manager | Oversees security policy, process and operation | Owns Log Review Procedures, updates the procedures as needed |
| Incident responder | Gets involved in security incident response | Deal with security incidents, reviews logs during the response process |
These roles and responsibilities are covered in depth throughout the document.
Introduction: PCI and Logging Basics
This background section covers the basics of PCI DSS logging and what is required by PCI DSS. It should be noted that logging and monitoring are not constrained to Requirement 10, but, in fact, pervades all 12 of the PCI DSS requirement. The key focus areas for this project are Requirement 10 and sections of Requirement 11.
Key Requirement 10
We will go through it line by line and then go into details, examples, and implementation guidance. [A.C. – this references PCI DSS 1.2.1 – I will mention where PCI DSS 2.0 differs for your convenience]
10.1
Specifically, Requirement 10.1 covers “establish[ing] a process for linking all access to system components (especially access done with administrative privileges such as root) to each individual user.” PCI DSS doesn’t just mandate for logs to be there or for a logging process to be set, but instead mentions that logs must be tied to individual persons (not computers or “devices” where they are produced). It is this requirement that often creates problems for PCI implementers, since many think of logs as “records of people actions,” while in reality they will only have the “records of computer actions.” By the way, PCI DSS requirement 8.1 which mandates that an organization “assigns all users a unique ID before allowing them to access system components or cardholder data” helps to make the logs more useful here.
10.2
Next, Section 10.2 defines a minimum list of system events to be logged (or, to allow “the events to be reconstructed”). Such requirements are motivated by the need to assess and monitor user actions as well as other events that can affect credit card data (such as system failures).
Following is the list from the requirements (events that must be logged) from PCI DSS (v. 1.2.1):
“10.2.1 All individual user accesses to cardholder data
10.2.2 All actions taken by any individual with root or administrative privileges
10.2.3 Access to all audit trails
10.2.4 Invalid logical access attempts
10.2 5 Use of identification and authentication mechanisms
10.2.6 Initialization of the audit logs
10.2.7 Creation and deletion of system-level objects”
As can be seen, this covers data access, privileged user actions, log access and initialization, failed and invalid access attempts, authentication and authorization decisions, and system object changes. It is important to note that such a list has its roots in IT governance “best practices,” which prescribe monitoring access, authentication, authorization change management, system availability, and suspicious activity.
10.3
Moreover, PCI DSS Requirement 10 goes into an even deeper level of detail and covers specific data fields or values that need to be logged for each event. They provide a healthy minimum requirement, which is commonly exceeded by logging mechanisms in various IT platforms.
Such fields are (quoted from PCI DSS):
“10.3.1 User identification
10.3.2 Type of event
10.3.3 Date and time
10.3.4 Success or failure indication
10.3.5 Origination of event
10.3.6 Identity or name of affected data, system component, or resource”
As can be seen, this minimum list contains all of the basic attributes needed for incident analysis and for answering the questions: when, who, where, what, and where from. For example, if trying to discover who modified a credit card database to copy all of the transactions with all the details into a hidden file (a typical insider privilege abuse), knowing all of the above records is useful.
10.4
The next requirement, 10.4, addresses a commonly overlooked but critical requirement: a need to have accurate and consistent time in all of the logs. It seems fairly straightforward that time and security event monitoring would go hand in hand as well. System time is frequently found to be arbitrary in a home or small office network. It’s whatever time your server was set at, or if you designed your network for some level of reliance, you’re systems are configured to obtain time synchronization from a reliable source, such as NTP service.
[A.C. – this section 10.4 is slightly different in PCI DSS 2.0, but the key point – you must have reliable time – is the same]
To be continued.
Follow PCI_Log_Review to see all posts.
Possibly related posts:
- Incident Log Review Checklist
- All posts tagged PCI_Log_Review
