PCI DSS Requirement 10: Track and monitor all access to network resources and cardholder data
Logging mechanisms and the ability to track user activity are critical to preventing, detecting or minimizing the impact of data security.
Keeping logs in all environments allows extensive monitoring, warning and analysis when something goes wrong. Determining the cause of the attack is very difficult without logging the activity of the system.
The PCI DSS Requirement 10 relates to the monitoring and tracking of individual access to system components, applications, databases, or any other device where cardholder data can be stored, processed or transmitted.
PCI DSS Requirement 10.1: Apply audit trails to associate all access to system components with individual users.
It is essential to have a process or system that connects and associates user access to the system components that are accessed. This system creates audit logs and provides the ability to track suspicious activity back to a specific user.
- Audit trails must be effective and operational for system components.
- Access to system components must depend on individual users.
PCI DSS Requirement 10.2: Apply automatic audit trails for all system components to reproduce events
Creating audit trails for suspicious activities alerts the system administrator, sends data to other monitoring mechanisms and provides a history trail for post-incident tracking.
Logging suspicious events allow an organization to identify and track potentially malicious activities.
Automatic audit trails are required for all system components to reconfigure the following events:
- All individual access to cardholder data
- All transactions performed by any person with root or administrative privileges.
- Access to all audit trails
- Invalid logical access attempts
- Use of identification and authentication mechanisms
- Starting audit logs
- Creating and deleting objects at the system level
PCI DSS Requirement 10.2.1: All individual access to cardholder data
Malicious individuals can obtain information about a user account with access to systems in the cardholder data medium (CDE), or create a new, unauthorized account to access the cardholder data.
A record of all individual access to cardholder data can determine which accounts may have been hacked or misused.
PCI DSS Requirement 10.2.2: All transactions by root or any person with administrative privileges
Accounts with elevated privileges, such as the “administrator” or “root” account, may have a significant impact on the security or operational functionality of the system.
If the activities performed are not logged, any problems arising from an administrative error or privileges given to a specific action and individual cannot be monitored.
PCI DSS Requirement 10.2.3: Access to all audit log paths
Malicious users often try to change audit logs to hide their actions. Access logs allow an organization to track the inconsistencies or the possible tampering of records.
Access to logs that define changes, additions and deletions may help track the steps taken by unauthorized personnel.
PCI DSS Requirement 10.2.4: Invalid logical access attempts
Malicious people often run multiple access attempts to reach targeted systems. More than one invalid login attempt may be an indication of an unauthorized user’ brute force’ attack or attempts to guess a password.
PCI DSS Requirement 10.2.5: Use and modification of identification and authentication mechanisms and all changes, additions or deletions in accounts with root or administrator privileges
It is impossible to identify the accounts that could have been used at the time of the event without knowing who logged in. Also, malicious users may try to change their authentication checks to bypass or emulate a valid account.
PCI DSS Requirement 10.2.6: Starting, stopping, or pausing audit logs
It is common practice for malicious users who want to turn off or pause audit logs before carrying out illegal activities and avoid being spotted or spotted later.
Starting, stopping, or stopping audit logs may indicate that the log function is disabled or changed by the user to hide their actions.
PCI DSS Requirement 10.2.7: Creating and deleting system-level objects
Malware often creates or modifies system-level objects on the target system to control a specific function or process on the system.
It will be easier to determine whether such changes are allowed if system-level objects such as database tables or stored procedures are logged when they are created or deleted.
PCI DSS Requirement 10.3 1-6: Record at least the following audit trail entries for all system components under each event
- User ID
- Event type
- Date and time
- Indication of success or failure
- The source of the event
- The identity of the data, system component or resource that was affected.
When capturing this information for auditable events, it is possible to quickly identify a potential solution with sufficient detail to know who, when, where, where and how.
PCI DSS Requirement 10.4 1-3: Synchronize all critical system clocks and times using time synchronization technology.
Time synchronization technology is used in multiple systems to synchronize the clocks. When clocks are not properly synchronized, it can be challenging to compare log files from different systems and create an exact sequence of events.
Time synchronization and log sources show a consistent time for forensic analysis in the event of a violation. For post-incident forensics teams, the accuracy and consistency of time in all systems and the time of each activity are critical in determining how systems are handled.
An example of time synchronization technology is the Network Time Protocol (NTP).
Critical systems must have an accurate and consistent time. For this;
- Only designated central time servers should receive time signals from external sources and time signals from external sources should be based on International Atomic Clock or UTC.
- In case of more than one specified time server, the time servers must match and synchronize with each other to maintain the correct time.
- Systems should receive time information only from designated central time servers.
Time data should be preserved. For this;
- Access to time data should be limited only to personnel who need access to business time data.
- Changes to time settings in critical systems should be logged, monitored, and reviewed.
Time settings should be taken from industry-accepted time sources. For this;
- Accept time updates for time servers from external sources accepted by the industry.
- Optionally, these updates can be encrypted with a symmetric key, and access control lists can be created that specifies the IP addresses of client machines to be provided with time updates.
PCI DSS Requirement 10.5: Secure audit trails cannot be altered.
Usually, malicious people entering the network try to edit or change audit logs to hide their activity. If the audit logs are not adequately maintained, their accuracy and integrity cannot be guaranteed. Therefore, audit logs can be rendered useless as an investigation tool after an investigation.
PCI DSS Requirement 10.5.1: Limit the display of audit trails only to those with business needs.
Only people with a business need should be able to view audit trail files.
Adequate protection of audit logs includes robust access control and the use of physical or network separation to make logs challenging to find and replace.
PCI DSS Requirement 10.5.3: Back up audit trail files to a central log server or environment that is difficult to alter.
Backing logs to a central log server or medium that is difficult to modify without losing time provides log protection if the system that creates logs is compromised.
PCI DSS Requirement 10.5.4: Write logs for external technologies to a secure, central, internal log server or media device.
External-facing technology logs such as wireless devices, firewalls, DNS and mail servers will reduce the risk of loss or replacement as they are more secure on the internal network.
Logs can be written directly to related resources or uploaded or copied securely from external systems to the internal system or media.
PCI DSS Requirement 10.5.5: Use file integrity monitoring or change-detection software in logs to ensure that existing log data cannot be changed without generating an alert
Monitoring file integrity or change detection systems will check critical files for changes, and report when those changes are made.
Files that do not change regularly are monitored for file integrity monitoring purposes, which means that there is a potential attack attempt when such files are changed.
Newly added data should not cause an alert to prevent the generation of continuous alerts.
PCI DSS Requirement 10.6: Review logs and security events for all system components to identify abnormalities or suspicious activity.
Many violations occur days or months before they are detected. Regular daily reviews by staff or automated methods can identify and proactively address unauthorized access to the cardholder’s data environment.
The daily review does not have to be manual. Using daily collection, segregation, and alert tools can help streamline the process by identifying the daily events that need to be reviewed.
PCI DSS Requirement 10.6.1: Review logs of all system components that store, process, or transmit CHD or SAD at least daily
Checking logs regularly daily will minimize the exposure time for a possible violation.
In addition to security events, logs of critical system components are also required to identify potential problems. Determination of the safety incident may vary for each organization. In such cases, consideration should be given to the type, technology and function of the device. Organizations should also define “normal” traffic to help identify abnormal behaviour.
The following should be reviewed daily:
- All security incidents
- Logs of all system components that store, process, or transmit CHD or SAD.
- Logs of all critical system components
- Logs of all servers and system components that perform security functions
PCI DSS Requirement 10.6.2: Review the logs of all other system components according to organization policies and risk management strategy as determined by the organization’s annual risk assessment.
Logs for all other system components should be reviewed periodically to identify symptoms of potential problems or attempts to access sensitive systems through less sensitive systems. The annual business risk assessment should determine the frequency of the reviews.
Depending on the organization’s policies and risk management strategy, procedures for periodic review of logs of all other system components, either manually or automated, should be defined.
PCI DSS Requirement 10.6.3: Track exceptions and abnormalities detected during the review process.
If the exceptions and anomalies identified during the log review are not investigated, the organization may not be aware of any unauthorized and potentially malicious activity occurring within its network.
The procedures needed to track the exceptions and abnormalities identified in the review process should be defined.
PCI DSS Requirement 10.7: Retain audit trail history for at least one year and have at least three months of data ready for analysis
It usually takes some time to understand that an attack has reached its target or that the system has been exposed.
Keeping logs for at least one year allows a sufficient log history of researchers to determine the duration of a potential violation.
An entity can quickly identify and minimize the impact of a data breach by holding a quarterly journal. Storing logs in offline locations may prevent them from being available, and longer time may be required to restore log data, analyze and identify affected systems or data.
The following items should be included in the security policies and procedures regarding audit logs:
- Audit logging retention policies
- Procedures for keeping audit logs for at least one year
- Procedures that make audit logs immediately accessible for at least three months online
PCI DSS Requirement 10.8: Additional requirement for service providers only: Apply a process for timely detection and reporting of faults in critical security control systems
This requirement only applies when the assessed organization is a service provider.
Without formal processes to detect and alert critical security checks, failures cannot be seen for long periods. They can give attackers ample time to compromise systems and steal sensitive data from the cardholder data environment.
Certain types of malfunctions may vary depending on the functionality of the device and the technology used. Typical faults are a system that ceases to perform its safety function or does not function as intended. An example of this is a firewall that erases all of its rules or is offline.
Critical security control systems can include:
- IDS / IPS
- Physical access controls
- Logical access controls
- Audit logging mechanisms
- Segmentation controls
Requirement 10.8.1 Additional requirement only for service providers: Respond to faults of critical security controls promptly.
This requirement only applies when the assessed organization is a service provider.
Attackers can use this time to add malware, take control of the system, or steal data from the enterprise environment if critical security control error alerts do not respond quickly and effectively.
Documented evidence should support the availability of procedures and procedures for responding to security failures. Also, employees should be aware of their responsibilities in the event of a malfunction. Actions and responses to the error should be included in the documented evidence.
Processes to respond to errors in security audits should include:
- Restoring security functions
- Determining and documenting the duration (date and time start/end) of the security failure
- Identify and document the causes of errors, including the root cause, and write the necessary correction for the root cause.
- Identify and resolve security issues that arise during a malfunction.
- To conduct a risk assessment to determine whether other actions are required as a result of a security failure.
- Applying controls to prevent recurrence of the cause of the fault
- Continuing to monitor security controls
PCI DSS Requirement 10.9: Ensure that security policies and operational procedures are documented, in use, and known to all affected parties to monitor all access to network resources and cardholder data.
Staff should be aware of and follow security policies and day-to-day operational procedures to monitor all access to network resources and cardholder data on an ongoing basis.
For detailed information, see the PCI DSS Quick Reference Guide from the PCI SSC Documentation library.