The payment Card Industry (PCI) is a set of requirements that organizations are required to be audited against to accept, process, or store any payment card information. This standard is designed to help the brand label cards (AMEX, Discovery, Visa, etc.) reduce fraud risk through the loss or compromise of credit cards.
As part of this, an organization must implement appropriate logging for their cardholder environment (CDE) to help with detection, investigations, and monitoring. PCI DSS Requirement 10 has many components to it, and while it has been a core requirement from the beginning, many organizations still struggle with meeting it adequately.
This article will take a deep look into PCI compliance logging requirements, address some common mistakes that organizations can make, and provide guidance on how to manage logging compliance efficiently.
What is PCI Compliance Logging?
The concept of logging serves multiple purposes for an organization’s security. The first is that logging provides the ability to baseline user behaviors, actions, and systems performance (through error logging or system metrics).
With baseline behavior logged, it is possible to build a robust monitoring and alerting system, either with a traditional SIEM (security information event management) tool or through a centralized logging system. With a monitoring system implemented that is built on a solid source of logs, it is possible to detect attacks, breaches, or events earlier to prevent the loss or destruction of data.
Another use case for a robust logging system is to have a controlled system of records across the full environment. This is because many breaches are not always detected at the time of the attack and may take several weeks, if not months, to detect. By having logs that can be reviewed and searched through, the organization can rebuild the actions taken, and the data affected, and know the true extent of the event.
Logs can come from multiple sources. They can include network switches, firewalls, servers, and user endpoints but can also entail audit logs or application logs. All these sources provide valuable data to help with detection, prevention, and investigations. Choosing which logs to include is one of the most common mistakes an organization can make, which will be covered in more depth later in this article.
(NOTE: If you’re looking for advice on your PCI Logging requirements, our free tool below matches your firm with a top-rated PCI consultant that can meet your needs and budget.)
What Are The PCI Logging Requirements?
While many organizations may already have logging and a log source within their environment, these systems may not meet PCI requirements in section 10. Logging itself is an easy requirement to implement in a deficient manner, and because it is a capture of a point in time action, it is impossible to recreate or capture that specific evidence after that point in time.
Within PCI DSS requirement 10 (including the updates in PCI v4.0), several key components need to be considered when an organization is setting up its logging policy and controls.
Central Log Management
This means that there is a central logging location to which all logs relevant to PCI are sent. Consider this to be the source of truth for the organization. It is required that this service is monitored with file integrity monitoring (for in-house managed systems) that allows for alerting the security team and logging server owners.
The goal of FIM is to detect any system-level changes that could affect the quality, availability, or integrity of the logs retained in the system. Some key items that will need to be monitored for this system are as follows:
- All administrative access, changes, or actions taken on the server or the logging system itself
- Any changes or deletions to stored logs on the service
- Clock synchronization changes, this requirement is to ensure that malicious actors are not able to modify the time stamps of the logs to evade detection or incident research
- System performance, including appropriate warnings for resource consumption issues like memory, CPU, or storage to allow for proactive scaling as needed
- Backup of log system, again if managed on-premise by the organization, in the event of a disaster recovery event
Log Monitoring
While it is a first step for an organization to have centralized logging and the appropriate logs, it does not meet the PCI DSS requirement, unless there is active monitoring.
This is not a one-size-fits-all for an organization. This can mean eyes on glass reviewing key actions, events, or dashboards but can also entail an automated system that generates alerts for triaging.
The key consideration for this control is what is being monitored or alerted on. The purpose of this control is for an organization to take log data and be able to turn it into actionable results. Log monitoring will entail reviewing key events within the environment and cardholder environment.
Key Event Logging
This list of key events is not meant to be exhaustive but is meant to help your organization think about what key events would be of interest to you. Not every organization is the same, nor trying to protect the same types of resources or systems. It is critical to spend some time deciding what key events are of concern for your organization as you build your logging environment.
Some of the key events that are required to be logged and monitored are as follows:
- Administrative, root, or elevated access actions taken within the Cardholder Data Environment.
- Logging system audit log of actions taken
- File integrity monitoring tools events
- Login attempts to network and applications in scope for PCI, this includes valid and invalid attempts
- All access to the Cardholder Data Environment at the individual level
- Access logs including physical
- Backup configuration changes including the modification, access, or deletion of stored backups
- Firewall activity including denied and successful connections to the environment
- Network intrusion detection and prevention system warnings, alarms, and blocks
Log Retention
Per PCI, all logs related to the in-scope PCI environment and supporting systems are required to be retained for 12 months. In more detail, the requirement states that the logs must be stored with three months of readily searchable and available logs, with another nine months of logs that can be restored from an offline state.
Log Protection & Security
This entails making sure that the central log source and all remote logging agents or systems are properly secured to protect the logs from deletion, modification, or interception by a malicious actor.
It is important to not only protect the central log server but to think in terms of log forwarders that may be installed in the environment. These systems need to have file integrity monitoring implemented to detect system file changes or configuration changes. Further, they need to be installed in the environment in such a way that it limits direct access from non-authorized users.
Additional aspects of protection and security that should be considered are as follows:
- Limit administrative or root access to the system
- Only approved changes are implemented after testing
- Monitoring with alerting within the central log resource for loss of data or changes in data quantities being sent
- Installation in a protected VLAN
- Backups and redundancies built to account for disaster events
The Benefits of PCI Logging
While adhering to PCI DSS Logging and Monitoring Requirements is essential for compliance, there are other significant advantages to implementing robust logging practices in your organization. For example:
- Better Defense: The detection and prevention of security threats are made more manageable by maintaining comprehensive logs. By tracking user activities and system events, organizations can swiftly identify and address suspicious behavior or patterns that may indicate a potential risk.
- Better System Performance: Efficient log management aids in system performance and stability, as it enables businesses to identify and rectify underlying issues. By examining log records, companies can detect, diagnose, and resolve technical difficulties, potentially preventing costly downtime.
- Better Incident Response: An essential aspect of digital forensics and incident response is effective log management. In the event of a security breach, thorough logs can serve as critical evidence to determine the extent of the compromise, identify affected systems or users, and facilitate swift recovery of operations. Such insights also contribute to the refinement of existing security measures, reducing the likelihood of incidents in the future.
Maintaining comprehensive logs also improves efficiency by granting businesses the ability to monitor and evaluate system performance over time. By regularly analyzing log data, organizations can identify trends and patterns, optimize resource utilization, and make informed decisions based on accurate information.
What Are Audit Trails for PCI?
It is critical to understand what audit trails include and their purpose. Audit trails provide an organization with a detailed event-based log of actions taken by users within a given system.
This can be the modification of data and deletion of data but also includes any configuration changes that have been implemented on the system. Further, this also includes modification to user access and passwords to allow for detection of potential account compromise or escalation of privileges.
Audit trails across systems, applications, and network gear are critical in helping determine the actions taken by a malicious actor. These actions can be alerted on to help prevent further exploitation within the environment but also provide the ability to thoroughly research and scope the extent of a breach.
With these audit logs, an organization can reliably communicate what happened, how it happened, and why it happened. The final reason why audit trails are important is they provide the ability to restore a system to a previous good state by understanding what actions were taken.
Common PCI Logging Mistakes
While it may seem straightforward to implement a logging platform, it can be quite difficult, due to the nuances of the PCI DSS compliance requirements. The following are some common mistakes of organizations implementing logging:
Missing Logging Sources
Simply put, this is missing components that are required for logging. This can happen for a lot of reasons, but the most common is a misconception that only resources directly in the Cardholder Data Environment need to be logged under this requirement. This is not true; any control, software, system components, or other supporting resource is required to be logged under this requirement.
A great example of this is a Cardholder Data Environment that is air-gapped from the corporate network and other data center resources. In this case, the organization utilizes a VPN to access the CDE, but that VPN is only accessible via the corporate VPN or VLAN. In this case, while the corporate VLAN does not have cardholder data and is not directly in scope, it is a supporting control that must be logged.
The same can apply to EDR consoles, FIM tools, vulnerability scanning consoles, and many other controls that may never touch cardholders’ data but provide critical resources or controls for the secure operation of the CDE.
Improper Central Logging Management
Another common mistake is not properly managing the central logging system to allow for secure and reliable operation. This can take place through improper patch management, as in not applying or failing to test patches before applying. This can also be related to not providing enough operation resources for reliable or usable performance. Do not under the provision of the central log system as this can create a denial attack to prevent logs and alerts from being processed.
Overly Complex Logging Architecture
Because there is a desire to limit the overall scope of the PCI environment, some organizations can create a complex logging architecture. This can create a headache for maintenance and performance.
While the scope for PCI DSS compliance may be limited, the effort to continue to maintain the architecture can far outweigh the benefits. Sometimes a simple architecture where the resources send directly to the logging system is the best implementation to allow for quick ingestion and management of logs.
How to Meet PCI Logging Requirements Efficiently
When it comes to meeting the PCI DSS logging requirements, it does not need to be difficult or expensive. There are many tradeoffs to be considered to assist your organization in meeting this requirement while keeping everything manageable.
Below are some tips to consider when designing your logging approach.
Consider SaaS Logging
While this may not be an option for every organization, for those that can, it should be. There are multiple benefits to utilizing a SaaS logging solution which can include the elimination of operating costs related to patching and maintenance for your central log system.
Further, this can eliminate the concern or need for consideration for redundancy, resource management, and availability for your log system.
When looking for a vendor with whom to offload your logs, review that the vendor has their AOC, as their platform will be in scope for PCI.
One other benefit of using a SaaS solution is that it can also simplify logging architecture. Many of these vendors provide logging agents or direct ingestion from top cloud providers. By being accessible over the internet, pending your organization configuration, it is possible to ingest without concern about where the resource is located.
Hot Log Retention
When considering your architecture and logging requirements, a way to lower the cost for a SaaS or cloud-based logging solution is to consider your hot log retention.
The minimum is 3 months of logs readily available for searching. If your organization does not need anything further to be active, you can consider moving the logs to cold storage to be ingested, if needed, again back into the logging platform. This can create additional logistics if you need to go back further than 3 months, and the risk should be weighed before making the final decision.
Scope Limitation
As is always the case with PCI DSS compliance, scope limitations should be considered when looking at your logging. This will serve multiple purposes for your organization. Some of the benefits can be that you can have a shorter retention period for logs that are not relevant to PCI.
The log monitoring for a non-PCI environment will be dictated by your organization, contractual requirements, or other regulatory requirements, which may mean fewer required eyes on glass monitoring checks. And lastly, this will limit the locations that FIM and other controls are required for your log forwards, simplifying some of your architecture.
