Requirement 10: Log And Monitor All Access To Data

Log 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 on all system components and in the cardholder data environment (CDE) allows thorough tracking, alerting, and analysis when something does go wrong. Determining the cause of a compromise is difficult, if not impossible, without system activity logs.

Requirement 10: Log And Monitor All Access To Data

10.1 Processes And Mechanisms For Logging And Monitoring All Access To System Components And Cardholder Data Are Defined And Documented

10.1.1 All security policies and operational procedures are: • Documented • Kept up to date • In use • Known to all affected parties

It is important to update policies and procedures as needed to address changes in processes, technologies, and business objectives. For this reason, consider updating these documents as soon as possible after a change occurs and not only on a periodic cycle.

10.1.2 Roles and responsibilities for performing activities are documented, assigned, and understood

Roles and responsibilities may be documented within policies and procedures or maintained within separate documents.

As part of communicating roles and responsibilities, entities can consider having personnel acknowledge their acceptance and understanding of their assigned roles and responsibilities.

10.2 Audit Logs Are Implemented To Support The Detection Of Anomalies And Suspicious Activity, And The Forensic Analysis Of Events

10.2.1 Audit logs are enabled and active for all system components and cardholder data

When an entity considers which information to record in their logs, it is important to remember that information stored in audit logs is sensitive and should be protected per requirements in this standard. Care should be taken to only store essential information in the audit logs to minimize risk.

10.2.1.1 Audit logs capture all individual user access to cardholder data

A record of all individual access to cardholder data can identify which accounts may have been compromised or misused.

10.2.1.2 Audit logs capture all actions taken by any individual with administrative access, including any interactive use of application or system accounts

Accounts with increased access privileges, such as the “administrator” or “root” account, have the potential to significantly impact the security or operational functionality of a system. Without a log of the activities performed, an organization is cannot trace any issues resulting from an administrative mistake or misuse of privilege back to the specific action and account.

10.2.1.3 Audit logs capture all access to audit logs

Malicious users often attempt to alter audit logs to hide their actions. A record of access allows an organization to trace any inconsistencies or potential tampering of the logs to an individual account. Having logs identify changes, additions, and deletions to the audit logs can help retrace steps made by unauthorized personnel.

10.2.1.4 Audit logs capture all invalid logical access attempts

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.

10.2.1.5 Audit logs capture all changes to identification and authentication credentials including, but not limited to: • Creation of new accounts • Elevation of privileges • All changes, additions, or deletions to accounts with administrative access

Logging changes to authentication credentials (including elevation of privileges, additions, and deletions of accounts with administrative access) provides residual evidence of activities.

Malicious users may attempt to manipulate authentication credentials to bypass them or impersonate a valid account.

10.2.1.6 Audit logs capture the following: • All initialization of new audit logs, and • All starting, stopping, or pausing of the existing audit logs

Turning off or pausing audit logs before performing illicit activities is common practice for malicious users who want to avoid detection. Initialization of audit logs could indicate that that a user disabled the log function to hide their actions.

10.2.1.7 Audit logs capture all creation and deletion of system-level objects

Malicious software, such as malware, often creates or replaces system-level objects on the target system to control a particular function or operation on that system. By logging when system-level objects are created or deleted, it will be easier to determine whether such modifications were authorized.

10.2.2 Audit logs record the following details for each auditable event: • User identification • Type of event • Date and time • Success and failure indication • Origination of event • Identity or name of affected data, system component, resource, or service (for example, name and protocol)

By recording these details for the auditable events, a potential compromise can be quickly identified, with sufficient detail to facilitate following up on suspicious activities.

10.3 Audit Logs Are Protected From Destruction And Unauthorized Modifications

10.3.1 Read access to audit logs files is limited to those with a job-related need

Adequate protection of the audit logs includes strong access control that limits access to logs based on “need to know” only and the use of physical or network segregation to make the logs harder to find and modify.

10.3.2 Audit log files are protected to prevent modifications by individuals

Entities should attempt to prevent logs from being exposed in public-accessible locations.

10.3.3 Audit log files, including those for external-facing technologies, are promptly backed up to a secure, central, internal log server(s) or other media that is difficult to modify

Each entity determines the best way to back up log files, whether via one or more centralized log servers or other secure media. Logs may be written directly, offloaded, or copied from external systems to the secure internal system or media.

10.3.4 File integrity monitoring or change-detection mechanisms is used on audit logs to ensure that existing log data cannot be changed without generating alerts

Software used to monitor changes to audit logs should be configured to provide alerts when existing log data or files are changed or deleted. However, new log data being added to an audit log should not generate an alert.

10.4 Audit Logs Are Reviewed To Identify Anomalies Or Suspicious Activity

10.4.1 The following audit logs are reviewed at least once 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, network security controls, intrusion-detection systems/intrusion-prevention systems (IDS/IPS), authentication servers)

Checking logs daily (7 days a week, 365 days a year, including holidays) minimizes the amount of time and exposure of a potential breach. Log harvesting, parsing, and alerting tools, centralized log management systems, event log analyzers, and security information and event management (SIEM) solutions are examples of automated tools that can be used to meet this requirement.

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.

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.

An entity that uses third-party service providers to perform log review services is responsible to provide context about the entity’s environment to the service providers, so it understands the entity’s environment, has a baseline of “normal” traffic for the entity, and can detect potential security issues and provide accurate exceptions and anomaly notifications.

10.4.1.1 Automated mechanisms are used to perform audit log reviews

The entity should keep logging tools aligned with any changes in their environment by periodically reviewing tool settings and updating settings to reflect any changes.

10.4.2 Logs of all other system components are reviewed periodically

Periodic review of logs for all other system components helps to identify indications of potential issues or attempts to access critical systems via less-critical systems.

10.4.2.1 The frequency of periodic log reviews for all other system components is defined in the entity’s targeted risk analysis

Entities can determine the optimum period to review these logs based on criteria such as the complexity of each entity’s environment, the number of types of systems that are required to be evaluated, and the functions of such systems.

10.4.3 Exceptions and anomalies identified during the review process are addressed

Entities should consider how to address the following when developing their processes for defining and managing exceptions and anomalies: • How log review activities are recorded, • How to rank and prioritize exceptions and anomalies, • What procedures should be in place to report and escalate exceptions and anomalies, and • Who is responsible for investigating and for any remediation tasks.

10.5 Audit Log History Is Retained And Available For Analysis

10.5.1 Retain audit log history for at least 12 months, with at least the most recent three months immediately available for analysis

Retaining historical audit logs for at least 12 months is necessary because compromises often go unnoticed for significant lengths of time. Having centrally stored log history allows investigators to better determine the length of time a potential breach was occurring, and the possible system(s) impacted. By having three months of logs immediately available, an entity can quickly identify and minimize impact of a data breach.

10.6 Time-Synchronization Mechanisms Support Consistent Time Settings Across All Systems

10.6.1 System clocks and time are synchronized using time-synchronization technology

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 events, which is crucial for forensic analysis following a breach.

For post-incident forensics teams, the accuracy and consistency of time across all systems and the time of each activity are critical in determining how the systems were compromised.

10.6.2 Systems are configured to the correct and consistent time as follows: • One or more designated time servers are in use • Only the designated central time server(s) receives time from external sources • Time received from external sources is based on International Atomic Time or Coordinated Universal Time (UTC) • The designated time server(s) accept time updates only from specific industry-accepted external sources • Where there is more than one designated time server, the time servers peer with one another to keep accurate time • Internal systems receive time information only from designated central time server(s)

Another option to prevent unauthorized use of internal time servers is to encrypt updates with a symmetric key and create access control lists that specify the IP addresses of client machines that will be provided with the time updates.

10.6.3 Time synchronization settings and data are protected as follows: • Access to time data is restricted to only personnel with a business need • Any changes to time settings on critical systems are logged, monitored, and reviewed

Attackers will try to change time configurations to hide their activity. Therefore, restricting the ability to change or modify time synchronization configurations or the system time to administrators will lessen the probability of an attacker successfully changing time configurations.

10.7 Failures Of Critical Security Control Systems Are Detected, Reported, And Responded To Promptly

10.7.1 Additional requirement for service providers only: Failures of critical security control systems are detected, alerted, and addressed promptly, including but not limited to failure of the following critical security control systems: • Network security controls • IDS/IPS • FIM • Anti-malware solutions • Physical access controls • Logical access controls • Audit logging mechanisms • Segmentation controls (if used)

The specific types of failures may vary, depending on the function of the device system component and technology in use. Typical failures include a system ceasing to perform its security function or not functioning in its intended manner, such as a firewall erasing all its rules or going offline.

10.7.2 Failures of critical security control systems are detected, alerted, and addressed promptly, including but not limited to failure of the following critical security control systems: • Network security controls • IDS/IPS • Change-detection mechanisms • Anti-malware solutions • Physical access controls • Logical access controls • Audit logging mechanisms • Segmentation controls (if used) • Audit log review mechanisms • Automated security testing tools (if used)

The specific types of failures may vary, depending on the function of the device system component and technology in use. However, typical failures include a system no longer performing its security function or not functioning in its intended manner for example, a firewall erasing its rules or going offline.

10.7.3 Failures of any critical security controls systems are responded to promptly, including but not limited to: • Restoring security functions • Identifying and documenting the duration (date and time from start to end) of the security failure • Identifying and documenting the cause(s) of failure and documenting required remediation • Identifying and addressing any security issues that arose during the failure • Determining whether further actions are required as a result of the security failure • Implementing controls to prevent the cause of failure from reoccurring • Resuming monitoring of security controls

Documented evidence (for example, records within a problem management system) should provide support that processes and procedures are in place to respond to security failures. In addition, personnel should be aware of their responsibilities in the event of a failure. Actions and responses to the failure should be captured in the documented evidence.

Let’s Understand With An Example

This image is borrowed from the Cybersecurity Labs. Assume it represents your work environment and cardholder data is sitting on the server dz-win10.

Requirement 10.1

It’s all about defining policies and procedures. Then, allocate the responsibilities.

Requirements 10.2, 10.3, 10.4 And 10.7

All the activities, including administrative activities should be logged for dz-win10. It’s better if we can extend it to dsin-dangerzone and network too. These logs need same level of protection as the cardholder data. These logs need to be reviewed at least once daily and identified issues need to addressed immediately. Also, any failure in logging and monitoring itself should be fixed at highest priority.

Requirement 10.5

Retain audit log history for at least 12 months, with at least the most recent three months immediately available for analysis. It’s a best practice to keep the logs on the other server than its source.

Requirement 10.6

It’s a technical requirement to keep system clocks and time are synchronized using time-synchronization technology. The malicious users try to cover their trails by changing the system time.