Understanding PCI DSS Logging Requirements

Every block has one – a Mrs. Jenkins who has designated herself as your Neighborhood Watch and spends hours peering out from behind her curtains. When you see her at the mailbox, she is quick to let you know that last night at 10:05, a blue car drove slowly past your house, not once, but twice, and they were acting “really suspicious”. You generally find yourself secretly rolling your eyes with a quick thanks, and letting her know you will watch for them, and proceed on with your day without a second thought. But, you do rest a little easier at night knowing she is keeping tabs on everything, and if you ever did find yourself in the situation of your property being vandalized or your home being broken in to, Mrs. Jenkins would definitely be your first call!

Detailed logging of your network systems can be compared to your neighborhood watch – you sometimes take it for granted and it may even seem a bit over the top at times, but when a potential event is prevented or an actual data breach or incident occurs, it can be a lifesaver.

Organizations often struggle to find the right balance between the amount of logging required to meet their needs and the amount needed to achieve PCI compliance. Many have implemented system logging with storage for later retrieval, but only look at them after an event that requires attention has occurred, such as a data breach or a network issue. While it is good that the organizations are documenting system activity and have that information available to them; from a security perspective, logs should be utilized as more of a prevention tool and configured to alert staff of potential suspicious activities to be investigated before too much damage is done.

Requirement 10 of the PCI DSS requires organizations to track and monitor all access to network resources and cardholder data. Logging is a critical component in preventing, detecting, and minimizing the impact of a cardholder data breach. By implementing logs for all systems within your cardholder data environment (CDE), you will have both thorough tracking and alerting, as well as the documented audit history to provide a comprehensive analysis in the event something bad does happen.

What information needs to be logged for PCI-compliance?

Requirement 10 begins by necessitating that you have logs in place providing a documented audit trail for:

1. All individual access to cardholder data (Requirement 10.2.1)
2. All actions taken by any individual with root or administrative privileges within the CDE (Requirement 10.2.2)If a malicious individual were to gain access to a user account or create a new, unauthorized account with access to sensitive information within your CDE, the log files can provide you with a record of which accounts may have been compromised. And administrator accounts clearly have more rights and a greater potential to impact the security or functionality of a system. By logging the activities of these accounts, organizations can trace issues back to a specific individual and determine if it was an administrative mistake or misuse of privileges. Remember, the PCI DSS dictates that you must never allow group, shared, or generic IDs, passwords, or other authentication methods for any systems or applications within the CDE, as this will make it impossible to trace system access and activities back to an individual. Other actions to log include:
3. Documenting all attempts to access the audit log in order to monitor potential tampering attempts (Requirement 10.2.3)
4. Failed login attempts that may signal an unauthorized user attempting to login by guessing the account password (Requirement 10.2.4)
5. Use of and changes to identification and authentication methods, and all changes, additions, and deletions to accounts with root or administrative privileges (Requirement 10.2.5)
6. Verify all actions to initialize, pause, or stop the audit logs are tracked so that you can identify a user attempting to disable logging during the time they were compromising a system (Requirement 10.2.6)
7. Creation or deletion of system-level objects, such as database tables or stored procedures (Requirement 10.2.7)

Some other event types you may want to consider including are:

1. Password changes
2. First-time logins with new accounts
3. Irregular scans on your firewalls’ open and closed ports
4. Errors on network devices
5. File name changes
6. Data being exported from the system
7. New applications launching or running; processes stopping or failing
8. New service installations or system changes, including installation of patches and updates

A good way to determine which activities you want logged is to think about what information you would want to know if there was a system failure or a payment card breach.

What type of information should be included within the logs?

1. User identification – who performed the activity
2. Type of event – what activity was performed
3. Date and time – when exactly the activity occurred
4. Outcome of the activity/task – success or failure to complete
5. Origination of the event
6. Name of affected data, system component, or resource

You should implement file-integrity monitoring or change-detection software on all logs to ensure existing data cannot be changed without generating an alert. Limit viewing of the audit trails to only those with a job-related need, and protect log files from unauthorized modifications via access control mechanisms.

Implementing Logging Controls

1. As with most PCI requirements, the first step in logging is to identify and inventory all systems within your CDE. Really any system within your organization that handles confidential information, accepts network connections, or controls access rights should have logging implemented.
2. Decide how and when to generate the logs for each system. Most systems will have logging capabilities, but they might not be automatically enabled, so verify systems have the logs turned on.
3. Configure all log management and rules for alert generation.
4. Make sure all systems have the correct and consistent time configured. If the time is not accurate, it will be impossible to compare log files from different systems and establish an exact sequence of events. You should also make sure access to the time data is restricted and any changes to the time settings are logged, monitored, and reviewed.
5. Configure the devices to send logs to the central log server.
6. Estimate the volume of log data generated and then designate more storage than you estimate.
7. Secure your stored logs. Back up all audit trails to a centralized log server that is difficult to alter. Any logs for external-facing technologies (wireless network, firewalls, DNS, e-mail, etc.) should be written to a secure, centralized, internal log server.
8. Retain audit trail history for at least one year, with a minimum of three months immediately available.

The logs are in place, now what?

The most important piece of all of this is to actually review your logs! Often, data breaches are not detected for days or even months following an initial compromise. The 2017 Verizon Data Breach Investigations Report stated that the time for a breach to be discovered continues to increase and, sadly, 27% of breaches are discovered by third parties. If organizations regularly review system logs they can proactively identify and address any unauthorized access, and more accurately, and more quickly, pinpoint system compromises.

According to the PCI DSS, the following should be reviewed at least daily:

1. All security events
2. Logs of all system components that store, process or transmit cardholder data
3. Logs of all critical system components
4. Logs of all servers and system components that perform security functions, like firewalls, intrusion detection systems, authentication servers, e-commerce re-direction servers, etc.

The timeframe for which you review logs of other system components should be determined during your annual risk assessment. Some review efforts may be manual, but you can and should implement automated log review tools that will monitor actions and alert you to any changes or irregular activities. Work with your IT team to execute a review and reporting process that requires logs to be viewed regularly and automatically delivers scheduled reports to those assigned individuals that need to see them. Document the plan for reviewing the alerts or suspicious activities in your organizational procedures.

Logging system activities is a critical component in your overall information security program, as well as a requirement for PCI compliance. Reach out to us if you have any questions or would like to review your current logging processes.

Some additional guidance from our Security Advisor team below:

[Burt]: As a former Information Security Analyst within the Health Care and Higher Education verticals, I can’t stress enough how important the basic words of “logging” and “monitoring” are to an institution (e.g. HIPAA, SOX, FERPA, and PCI compliance). From the above article, you quickly realize how involved and detailed this process can become (Note: also not inexpensive by any means). Generally speaking, obtaining the logs is the easy part. Most sophisticated systems these days can generate what is necessary from a logging perspective. In addition, the next step of storing the logs in a centrally managed repository can also be accomplished with co-operation of all Information Technology departments involved. However, it’s the final steps of monitoring and alerting, where most institutions hit a wall. In other words, we have all this great data that meets our requirements, but now what?

It’s great to have all the required data in one accessible location. But speaking from past experience, this only assists for general researching and accomplishes half of the task. In regards to the PCI DSS specifically, the trap that institutions easily fall into is merely “checking the box on the SAQ” as we like to say. Keep in mind that institutions are required to monitor and alert daily on certain logging categories. My advice is to choose a logging, aggregating, correlating, monitoring, and alerting platform that can ease the pain of possibly spreading an Information Security or Networking department too thin. Then, be sure to spend the time configuring the platform to assist in your security and compliance needs. This may take a significant amount of time. But, ask yourself, “Do I want be the institution that is informed of a breach by someone else or do I want to find it myself?” Remember, don’t just be a “requirement box checker!”