Requirement 10.1
Implement audit trails to link all access to system components to each individual user.
Testing Procedure
10.1
Verify, through observation and interviewing the system administrator, that:
- Audit trails are enabled and active for system components.
- Access to system components is linked to individual users.
Guidance
It is critical to have a process or system that links user access to system components accessed. This system generates audit logs and provides the ability to trace back suspicious activity to a specific user.
Requirement 10.2
Implement automated audit trails for all system components to reconstruct the following events:
Testing Procedure
10.2
Through interviews of responsible personnel, observation of audit logs, and examination of audit log settings, perform the following:
Guidance
Generating audit trails of suspect activities alerts the system administrator, sends data to other monitoring mechanisms (like intrusion detection systems), and provides a history trail for post-incident follow-up. Logging of the following events enables an organization to identify and trace potentially malicious activities.
Requirement 10.2.1
All individual user accesses to cardholder data
Testing Procedure
10.2.1
Verify all individual access to cardholder data is logged.
Guidance
Malicious individuals could obtain knowledge of a user account with access to systems in the CDE, or they could create a new, unauthorized account in order to access cardholder data. A record of all individual accesses to cardholder data can identify which accounts may have been compromised or misused.
Requirement 10.2.2
All actions taken by any individual with root or administrative privileges
Testing Procedure
10.2.2
Verify all actions taken by any individual with root or administrative privileges are logged.
Guidance
Accounts with increased privileges, such as the “administrator” or “root” account, have the potential to greatly impact the security or operational functionality of a system. Without a log of the activities performed, an organization is unable to trace any issues resulting from an administrative mistake or misuse of privilege back to the specific action and individual.
Requirement 10.2.3
Access to all audit trails
Testing Procedure
10.2.3
Verify access to all audit trails is logged.
Guidance
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 steps made by unauthorized personnel.
Requirement 10.2.4
Invalid logical access attempts
Testing Procedure
10.2.4
Verify invalid logical access attempts are logged.
Guidance
Malicious individuals will often perform multiple access attempts on targeted systems. Multiple invalid login attempts may be an indication of an unauthorized user’s attempts to “brute force” or guess a password.
Requirement 10.2.5
Use of and changes to identification and authentication mechanisms—including but not limited to creation of new accounts and elevation of privileges—and all changes, additions, or deletions to accounts with root or administrative privileges
Testing Procedure
10.2.5.a
Verify use of identification and authentication mechanisms is logged.
10.2.5.b
Verify all elevation of privileges is logged.
10.2.5.c
Verify all changes, additions, or deletions to any account with root or administrative privileges are logged.
Guidance
Without knowing who was logged on at the time of an incident, it is impossible to identify the accounts that may have been used. Additionally, malicious users may attempt to manipulate the authentication controls with the intent of bypassing them or impersonating a valid account.
Requirement 10.2.6
Initialization, stopping, or pausing of the audit logs
Testing Procedure
10.2.6
Verify the following are logged:
- Initialization of audit logs
- Stopping or pausing of audit logs.
Guidance
Turning the audit logs off (or pausing them) prior to performing illicit activities is a common practice for malicious users wishing to avoid detection. Initialization of audit logs could indicate that the log function was disabled by a user to hide their actions.
Requirement 10.2.7
Creation and deletion of system-level objects
Testing Procedure
10.2.7
Verify creation and deletion of system level objects are logged.
Guidance
Malicious software, such as malware, often creates or replaces system level objects on the target system in order to control a particular function or operation on that system. By logging when system-level objects, such as database tables or stored procedures, are created or deleted, it will be easier to determine whether such modifications were authorized.
Requirement 10.3
Record at least the following audit trail entries for all system components for each event: (See 10.3.1 through 10.3.6)
Testing Procedure
10.3
Through interviews and observation of audit logs, for each auditable event (from 10.2), perform the following: (See 10.3.1 through 10.3.6)
Guidance for 10.3 through 10.3.6
By recording these details for the auditable events at 10.2, a potential compromise can be quickly identified, and with sufficient detail to know who, what, where, when, and how.
Requirement 10.3.1
User identification
Testing Procedure
10.3.1
Verify user identification is included in log entries.
Guidance for 10.3 through 10.3.6
By recording these details for the auditable events at 10.2, a potential compromise can be quickly identified, and with sufficient detail to know who, what, where, when, and how.
Requirement 10.3.2
Type of event
Testing Procedure
10.3.2
Verify type of event is included in log entries.
Guidance for 10.3 through 10.3.6
By recording these details for the auditable events at 10.2, a potential compromise can be quickly identified, and with sufficient detail to know who, what, where, when, and how.
Requirement 10.3.3
Date and time
Testing Procedure
10.3.3
Verify date and time stamp is included in log entries.
Guidance for 10.3 through 10.3.6
By recording these details for the auditable events at 10.2, a potential compromise can be quickly identified, and with sufficient detail to know who, what, where, when, and how.
Requirement 10.3.4
Success or failure indication
Testing Procedure
10.3.4
Verify success or failure indication is included in log entries.
Guidance for 10.3 through 10.3.6
By recording these details for the auditable events at 10.2, a potential compromise can be quickly identified, and with sufficient detail to know who, what, where, when, and how.
Requirement 10.3.5
Origination of event
Testing Procedure
10.3.5
Verify origination of event is included in log entries.
Guidance for 10.3 through 10.3.6
By recording these details for the auditable events at 10.2, a potential compromise can be quickly identified, and with sufficient detail to know who, what, where, when, and how.
Requirement 10.3.6
Identity or name of affected data, system component, or resource.
Testing Procedure
10.3.6
Verify identity or name of affected data, system component, or resources is included in log entries.
Guidance for 10.3 through 10.3.6
By recording these details for the auditable events at 10.2, a potential compromise can be quickly identified, and with sufficient detail to know who, what, where, when, and how.
Requirement 10.4
Using time-synchronization technology, synchronize all critical system clocks and times and ensure that the following is implemented for acquiring, distributing, and storing time.
Note: One example of time synchronization technology is Network Time Protocol (NTP).
Testing Procedure
10.4
Examine configuration standards and processes to verify that time-synchronization technology is implemented and kept current per PCI DSS Requirements 6.1 and 6.2.
Guidance for 10.4 through 10.4.3
Time synchronization technology is used to synchronize clocks on multiple systems. When clocks are not properly synchronized, it can be difficult, if not impossible, to compare log files from different systems and establish an exact sequence of event (crucial for forensic analysis in the event of a breach). For post-incident forensics teams, the accuracy and consistency of time across all systems and the time of each activity is critical in determining how the systems were compromised.
Requirement 10.4.1
Critical systems have the correct and consistent time.
Testing Procedure
10.4.1.a
Examine the process for acquiring, distributing and storing the correct time within the organization to verify that
- Only the designated central time server(s) receives time signals from external sources, and time signals from external sources are based on International Atomic Time or UTC.
- Where there is more than one designated time server, the time servers peer with one another to keep accurate time,
- Systems receive time information only from designated central time server(s).
10.4.1.b
Observe the time-related system-parameter settings for a sample of system components to verify:
- Only the designated central time server(s) receives time signals from external sources, and time signals from external sources are based on International Atomic Time or UTC.
- Where there is more than one designated time server, the designated central time server(s) peer with one another to keep accurate time.
- Systems receive time only from designated central time server(s).
Guidance for 10.4 through 10.4.3
Time synchronization technology is used to synchronize clocks on multiple systems. When clocks are not properly synchronized, it can be difficult, if not impossible, to compare log files from different systems and establish an exact sequence of event (crucial for forensic analysis in the event of a breach). For post-incident forensics teams, the accuracy and consistency of time across all systems and the time of each activity is critical in determining how the systems were compromised.
Requirement 10.4.2
Time data is protected.
Testing Procedure
10.4.2.a
Examine system configurations and time-synchronization settings to verify that access to time data is restricted to only personnel with a business need to access time data.
10.4.2.b
Examine system configurations, time synchronization settings and logs, and processes to verify that any changes to time settings on critical systems are logged, monitored, and reviewed.
Guidance for 10.4 through 10.4.3
Time synchronization technology is used to synchronize clocks on multiple systems. When clocks are not properly synchronized, it can be difficult, if not impossible, to compare log files from different systems and establish an exact sequence of event (crucial for forensic analysis in the event of a breach). For post-incident forensics teams, the accuracy and consistency of time across all systems and the time of each activity is critical in determining how the systems were compromised.
Requirement 10.4.3
Time settings are received from industry-accepted time sources.
Testing Procedure
10.4.3
Examine systems configurations to verify that the time server(s) accept time updates from specific, industry-accepted external sources (to prevent a malicious individual from changing the clock). Optionally, those updates can be encrypted with a symmetric key, and access control lists can be created that specify the IP addresses of client machines that will be provided with the time updates (to prevent unauthorized use of internal time servers).
Guidance for 10.4 through 10.4.3
Time synchronization technology is used to synchronize clocks on multiple systems. When clocks are not properly synchronized, it can be difficult, if not impossible, to compare log files from different systems and establish an exact sequence of event (crucial for forensic analysis in the event of a breach). For post-incident forensics teams, the accuracy and consistency of time across all systems and the time of each activity is critical in determining how the systems were compromised.
Requirement 10.5
Secure audit trails so they cannot be altered.
Testing Procedure
10.5
Interview system administrators and examine system configurations and permissions to verify that audit trails are secured so that they cannot be altered as follows:
Guidance
Often a malicious individual who has entered the network will attempt to edit the audit logs in order to hide their activity. Without adequate protection of audit logs, their completeness, accuracy, and integrity cannot be guaranteed, and the audit logs can be rendered useless as an investigation tool after a compromise.
Requirement 10.5.1
Limit viewing of audit trails to those with a job-related need.
Testing Procedure
10.5.1
Only individuals who have a job-related need can view audit trail files.
Guidance for 10.5.1 through 10.5.3
Adequate protection of the audit logs includes strong access control (limit access to logs based on “need to know” only), and use of physical or network segregation to make the logs harder to find and modify. Promptly backing up the logs to a centralized log server or media that is difficult to alter keeps the logs protected even if the system generating the logs becomes compromised.
Requirement 10.5.2
Protect audit trail files from unauthorized modifications.
Testing Procedure
10.5.2
Current audit trail files are protected from unauthorized modifications via access control mechanisms, physical segregation, and/or network segregation.
Guidance for 10.5.1 through 10.5.3
Adequate protection of the audit logs includes strong access control (limit access to logs based on “need to know” only), and use of physical or network segregation to make the logs harder to find and modify. Promptly backing up the logs to a centralized log server or media that is difficult to alter keeps the logs protected even if the system generating the logs becomes compromised.
Requirement 10.5.3
Promptly back up audit trail files to a centralized log server or media that is difficult to alter.
Testing Procedure
10.5.3
Current audit trail files are promptly backed up to a centralized log server or media that is difficult to alter.
Guidance for 10.5.1 through 10.5.3
Adequate protection of the audit logs includes strong access control (limit access to logs based on “need to know” only), and use of physical or network segregation to make the logs harder to find and modify. Promptly backing up the logs to a centralized log server or media that is difficult to alter keeps the logs protected even if the system generating the logs becomes compromised.
Requirement 10.5.4
Write logs for external-facing technologies onto a secure, centralized, internal log server or media device.
Testing Procedure
10.5.4
Logs for external-facing technologies (for example, wireless, firewalls, DNS, mail) are written onto a secure, centralized, internal log server or media.
Guidance
By writing logs from external-facing technologies such as wireless, firewalls, DNS, and mail servers, the risk of those logs being lost or altered is lowered, as they are more secure within the internal network.
Logs may be written directly, or offloaded or copied from external systems, to the secure internal system or media.
Requirement 10.5.5
Use file-integrity monitoring or change-detection software on logs to ensure that existing log data cannot be changed without generating alerts (although new data being added should not cause an alert).
Testing Procedure
10.5.5
Examine system settings, monitored files, and results from monitoring activities to verify the use of file-integrity monitoring or change-detection software on logs.
Guidance
File-integrity monitoring or change-detection systems check for changes to critical files, and notify when such changes are noted. For file-integrity monitoring purposes, an entity usually monitors files that don’t regularly change, but when changed indicate a possible compromise.
Requirement 10.6
Review logs and security events for all system components to identify anomalies or suspicious activity.
Note: Log harvesting, parsing, and alerting tools may be used to meet this Requirement.
Testing Procedure
10.6
Perform the following: (See 10.6.1 through 10.6.3)
Guidance
Many breaches occur over days or months before being detected. Regular log reviews by personnel or automated means can identify and proactively address unauthorized access to the cardholder data environment.
The log review process does not have to be manual. The use of log harvesting, parsing, and alerting tools can help facilitate the process by identifying log events that need to be reviewed.
Requirement 10.6.1
Review the following at least daily:
- All security events
- Logs of all system components that store, process, or transmit CHD and/or SAD
- Logs of all critical system components
- Logs of all servers and system components that perform security functions (for example, firewalls, intrusion-detection systems/intrusion-prevention systems (IDS/IPS), authentication servers, e-commerce redirection servers, etc.).
Testing Procedure
10.6.1.a
Examine security policies and procedures to verify that procedures are defined for reviewing the following at least daily, either manually or via log tools:
- All security events
- Logs of all system components that store, process, or transmit CHD and/or SAD
- Logs of all critical system components
- Logs of all servers and system components that perform security functions (for example, firewalls, intrusion-detection systems/intrusion-prevention systems (IDS/IPS), authentication servers, e-commerce redirection servers, etc.)
10.6.1.b
Observe processes and interview personnel to verify that the following are reviewed at least daily:
- All security events
- Logs of all system components that store, process, or transmit CHD and/or SAD
- Logs of all critical system components
- Logs of all servers and system components that perform security functions (for example, firewalls, intrusion-detection systems/intrusion-prevention systems (IDS/IPS), authentication servers, e-commerce redirection servers, etc.).
Guidance
Checking logs daily minimizes the amount of time and exposure of a potential breach.
Daily review of security events—for example, notifications or alerts that identify suspicious or anomalous activities—as well as logs from critical system components, and logs from systems that perform security functions, such as firewalls, IDS/IPS, file-integrity monitoring (FIM) systems, etc. is necessary to identify potential issues. Note that the determination of “security event” will vary for each organization and may include consideration for the type of technology, location, and function of the device. Organizations may also wish to maintain a baseline of “normal” traffic to help identify anomalous behavior.
Requirement 10.6.2
Review logs of all other system components periodically based on the organization’s policies and risk management strategy, as determined by the organization’s annual risk assessment.
Testing Procedure
10.6.2.a
Examine security policies and procedures to verify that procedures are defined for reviewing logs of all other system components periodically—either manually or via log tools—based on the organization’s policies and risk management strategy.
10.6.2.b
Examine the organization’s risk-assessment documentation and interview personnel to verify that reviews are performed in accordance with organization’s policies and risk management strategy.
Guidance
Logs for all other system components should also be periodically reviewed to identify indications of potential issues or attempts to gain access to sensitive systems via less-sensitive systems. The frequency of the reviews should be determined by an entity’s annual risk assessment.
Requirement 10.6.3
Follow up exceptions and anomalies identified during the review process.
Testing Procedure
10.6.3.a
Examine security policies and procedures to verify that procedures are defined for following up on exceptions and anomalies identified during the review process.
10.6.3.b
Observe processes and interview personnel to verify that follow-up to exceptions and anomalies is performed.
Guidance
If exceptions and anomalies identified during the log-review process are not investigated, the entity may be unaware of unauthorized and potentially malicious activities that are occurring within their own network.
Requirement 10.7
Retain audit trail history for at least one year, with a minimum of three months immediately available for analysis (for example, online, archived, or restorable from backup).
Testing Procedure
10.7.a
Examine security policies and procedures to verify that they define the following:
- Audit log retention policies
- Procedures for retaining audit logs for at least one year, with a minimum of three months immediately available online.
10.7.b
Interview personnel and examine audit logs to verify that audit logs are retained for at least one year.
10.7.c
Interview personnel and observe processes to verify that at least the last three months’ logs are immediately available for analysis.
Guidance
Retaining logs for at least a year allows for the fact that it often takes a while to notice that a compromise has occurred or is occurring, and allows investigators sufficient log history to better determine the length of time of a potential breach and potential system(s) impacted. By having three months of logs immediately available, an entity can quickly identify and minimize impact of a data breach. 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.
Requirement 10.8
Ensure that security policies and operational procedures for monitoring all access to network resources and cardholder data are documented, in use, and known to all affected parties.
Testing Procedure
10.8
Examine documentation and interview personnel to verify that security policies and operational procedures for monitoring all access to network resources and cardholder data are:
- Documented,
- In use, and
- Known to all affected parties.
Guidance
Personnel need to be aware of and following security policies and daily operational procedures for monitoring all access to network resources and cardholder data on a continuous basis.
Goal: Regularly Monitor and Test Networks
Requirement 10.0
Track and monitor all access to network resources and cardholder data
Logging mechanisms and the ability to track user activities are critical in preventing, detecting, or minimizing the impact of a data compromise. The presence of logs in all environments allows thorough tracking, alerting, and analysis when something does go wrong. Determining the cause of a compromise is very difficult, if not impossible, without system activity logs.