For PCI log monitoring compliance, a critical aspect of data protection is logging and tracking. Implementing logging mechanisms at a company provides the ability to track user activities, which is crucial in preventing, detecting, and minimizing the consequences of a data breach.
Audit trails for user access (Section 10.1.)
To comply with this requirement, organizations need to keep track of user access to all system components. Every user, particularly the administrators, should be monitored over the network and their activities should be checked. This allows organizations to track suspicious activity back to a specific user or administrator.
Automated audit trails for PCI logging (Section 10.2.)
It isn’t easy to keep track of all systems component access. Requirement 10.2 recommends organizations implement automated audit trails for system components for the following events:
All individual user accesses to cardholder data
All actions taken by any individual with root or administrative privileges
Access to all audit trails
Invalid logical access attempts
Use of, and changes to, identification and authentication mechanisms and all changes, additions, or deletions to accounts with root or administrative privileges
Initialization, stopping, or pausing of the audit logs
The creation and deletion of system-level objects
Log all accesses to cardholder data (Section 10.2.1.)
This requirement states that audit trails log all individual user accesses to cardholder data – pretty straightforward, right? PCI DSS guidance explains that malicious individuals could obtain knowledge of a user account with access to systems in the Cardholder Data Environment, or they could create a new, unauthorized account to access cardholder data.
A record of all individual accesses to cardholder data can identify which accounts may have been compromised or misused. Whenever someone accesses cardholder data, a log should be generated.
Log all root/admin user actions (Section 10.2.2.)
Accounts that have root or administrative privileges have a greater chance of impacting the security and functionality of a system, as these accounts have full control over a network and they can easily access all sensitive information related to cardholder data.
Requirement 10.2.2 mandates organizations to implement automated audit trails, to log all actions taken by an individual withroot or administrative privileges. Logging should record the administrator user name, the areas accessed, the changes made and the time spent.
Log access to audit trails (Section 10.2.3.)
Malicious users often attempt to alter audit logs to hide their actions, and a record of access allows an organization to trace any inconsistencies or potential tampering of the logs to an individual account. Having access to logs identifying changes, additions, and deletions can help retrace actions made by unauthorized users.
Invalid logical access attempts are often an indication of a malicious user attempting to gain unauthorized access. This PCI logging requirement requires that organizations implement automated audit trails to log invalid logical access attempts. You should log all of these events:
Incorrect password attempts
Attempts to view files without adequate permissions
Attempts to execute actions without adequate permissions
Any failed access attempts
Log all root/admin account usage (Section 10.2.5.)
Similarly to 10.2.2., organizations should implement automated audit trails to log the use of, and changes to, identification and authentication mechanisms, such as the creation of new accounts and elevation of privileges and all changes, additions, or deletions to accounts with root or administrative privileges.
You need to know who logged on and when. When there is a breach, visibility of the active accounts gives you a place to begin investigating.
Log the initialization, stopping, or pausing of the audit logs (Section 10.2.6.)
Stopping or pausing audit logs before performing malicious activities is common practice for users hoping to avoid detection. The initialization of audit logs or clearing of log data could indicate that the log function was disabled by a user. To comply with this requirement, audit trails should log the initialization, stopping, or pausing of audit logs.
PCI logging of the creation/deletion of system-level objects (Section 10.2.7.)
Requirement 10.2.7 requires audit trails to log the creation and deletion of system-level objects.
The PCI DSS defines a system-level object as anything on a system component that is required for its operation, including but not limited to database tables, stored procedures, application executables and configuration files, system configuration files, static and shared libraries and DLLs, system executables, device drivers and device configuration files, and third-party components. Malware often creates or replaces system-level objects on the target system to control a specific function. The purpose of this requirement is to make it easier to determine whether those modifications have been made to any system-level objects.
What should PCI logs contain? (Section 10.3.)
Requirement 10.3 states organizations should record the following audit trail entries for all system components for each event:
Type of event
Date and time
Success or failure indication
Origination of event
Identity or name of affected data, system component, or resource
These components will help quickly identify and provide details related to who, what, when, where, and how compromises occurred.
Time-synchronization technology (Section 10.4.)
Time-synchronization technology helps to synchronize clocks on multiple critical systems. If you do not synchronize these clocks correctly, comparing different log files in different systems to build a proper sequence of events and activity timings becomes very difficult.
Using Time-synchronization technology, such as Network Time Protocol (NTP) is recommended.
Immutable audit trails (Section 10.5.)
Audit trails contain all the correct information about events and incidents, so malicious individuals will often seek to alter log files to hide their actions.
To comply with 10.5., organizations must limit access to audit trails to personnel with business-related needs. They must also protect audit trails from unauthorized modifications, back up audit trail files on a centralized server, and write logs for external-facing technologies onto a centralized, internal log server.
The principle of least privilege (Section 10.5.1.)
Audit trails contain sensitive information that only some members of an organization should have access to. If a user does not have a business need to view log files, then don’t grant them access.
Protect PCI logging outputs (Section 10.5.2.)
Audit trails contain all the correct information about events and incidents in critical systems, so malicious individuals will often seek to modify log files to hide their actions. If an approved individual in an organization finds unencrypted cardholder data or sensitive data in a log, they may want to modify the log file to encrypt this data.
Back up the audit trail files to a centralized log server (Section 10.5.3.)
The purpose of this requirement is to prevent unauthorized modifications to audit trail files. Promptly backing up log files to a centralized log server or media that is difficult to alter keeps the logs protected even if the system generating log files becomes compromised.
Logs for external-facing technologies (Section 10.5.4.)
Organizations should write logs from external-facing technologies such as wireless, firewalls, DNS, and mail servers onto a secure device. This minimizes the risk of those log files being lost or compromised as they are more secure within the internal network.
Use file-integrity monitoring or change-detection software (Section 10.5.5.)
Organizations should use file-integrity monitoring or change-detection software on log files to ensure that existing log data cannot be changed without generating alerts (new data being added should not trigger an alert). Check for changes to critical files and provide notification when such changes are noted.
Centralize and review security events and logs (Section 10.6.)
Many security breaches occur over a period of time before being detected. How can anomalies or suspicious activity be identified if the logs are not reviewed?
Organizations could meet this requirement through manual reviews by training employees to review log data and identify suspicious activity. Other options are automated methods such as log harvesting, parsing, and alerting tools.
Daily review of all security events and critical system logs (Section 10.6.1.)
Organizations should review the following logs at least daily:
System component that store, process, or transmit cardholder data
Critical system components
Servers and system components that perform security functions
Review logs of all other system components periodically (Section 10.6.2.)
Based on the organization’s annual policies and risk management strategy, you should determine which system components should or should not be prioritized for log review.
Simply put, logs not covered in Requirement 10.6.1. should be reviewed periodically.
Act upon exceptions and anomalies (Section 10.6.3.)
Following a log review, an organization must follow up on any and all exceptions and anomalies identified. You must take appropriate actions to any incidents that might be impacting the cardholder data environment.
Keep audit trails for at least one year (Section 10.7.)
This PCI logging requirement expects organizations to retain audit trail history for at least one year, with a minimum of three months immediately available for analysis. The reasoning behind the recommended length of time is because it may take months to notice a security compromise. However, storing logs in off-line locations could prevent them from being readily available, resulting in longer time frames to restore log data, perform analysis, and identify impacted systems or data.
How do you detect failures of critical control systems? (Section 10.8.)
This is an additional requirement for service providers only.
Without formal processes in place to monitor when critical security controls have failed, failures could go undetected for long periods. This provides malicious individuals with opportunities to compromise your systems and obtain sensitive cardholder data.
Service providers must implement a process for the timely detection and reporting of failures of critical security control systems. This could be the failure of things like firewalls, anti-virus, physical access controls, logical access controls, or audit logging mechanisms.
Prompt response to the failure of critical systems (Section 10.8.1.)
This is an additional requirement for service providers only.
Service providers should respond to any failures of any critical security controls promptly.
The organization’s policies and procedures should outline the expected response to failures, which includes how to:
Restore security functions
Identify and document the duration of the security failure
Document cause(s) of failure including root cause, document remediation required to address the root cause
Identify and address any security issues that arose during the failure
Perform a risk assessment to determine whether further actions are required as a result of the security failure
Implement controls to prevent the cause of failure from reoccurring
Resume the monitoring of security controls
Are security policies documented, known, and in use? (Section 10.9.)
To comply with this final PCI logging requirement, organizations should ensure that all security policies and operational procedures, monitoring all access to the network resources and cardholder data, are documented, in use, and known by all affected parties.
Requirement 10 of the PCI Data Security Standard is directly concerned with network access and security, making it one of the most important requirements in the PCI DSS guidance.
Therefore, in order for an organization to comply, all the PCI logging policies, procedures, and standards described above must be implemented.