PCI DSS Requirement 10: Track and Monitor Network Access

Logging mechanisms and tracked user activities are critical to preventing, detecting, or minimizing the impact of a data compromise. Implementing logs on all system components and in the cardholder data environment (CDE) allows thorough tracking, alerting, and analysis should something go wrong. 

Without system activity logs, determining the root cause of a compromised system is difficult, and, in some cases, nearly impossible.

This requirement applies to all user activities by employees, contractors, consultants, and internal and external vendors, and other third parties.

PCI DSS requirement 10 outlines the processes and guidelines for monitoring and tracking network access to maintain compliance.

For additional details on all 12 of the Requirements, read our PCI DSS Requirements overview.

Requirement 10 Details and Sections

Requirement 10 contains seven sections that detail the means of securing account data by carefully assigning user permissions and access controls.

Detailed requirement sections include:

• Requirement 10.1: Processes and mechanisms for logging and monitoring all access to system components and cardholder data are defined and documented.
• Requirement 10.2: Audit logs are implemented to support the detection of anomalies and suspicious activity, and the forensic analysis of events.
• Requirement 10.3: Audit logs are protected from destruction and unauthorized modifications.
• Requirement 10.4: Audit logs are reviewed to identify anomalies or suspicious activity.
• Requirement 10.5: Audit log history is retained and available for analysis.
• Requirement 10.6: Time-synchronization mechanisms support consistent time settings across all systems.
• Requirement 10.7: Failures of critical security control systems are detected, reported, and responded to promptly.

Requirement 10.1: Processes and mechanisms for logging and monitoring all access to system components and cardholder data are defined and documented.

Like other requirements found in PCI DSS 4.0, the first section of the requirement - 10.1 - explains the importance of creating and maintaining policies for adherence. These processes must be consistently monitored and updated whenever required, and all involved personnel must understand their responsibilities.

Detailed requirement sections include:

• Requirement 10.1.1: All security policies and operational procedures that are identified in Requirement 10 are documented, up-to-date, in use, and known to all impacted parties.
• Requirement 10.1.2: Roles and responsibilities for performing activities in Requirement 10 are documented, assigned, and understood. 

Requirement 10.2: Audit logs are implemented to support the detection of anomalies and suspicious activity, and the forensic analysis of events.

Audit logs are required for all system components, and must send alerts to system admins, provide data to monitoring tools, and provide a history trail for any post-incident investigation.

This requirement details the means and methods of implementing audit logs on systems, compliantly and effectively.

Detailed requirement sections include:

• Requirement 10.2.1: Audit logs are active for all system components and cardholder data. 
  • Requirement 10.2.1.1: Audit logs capture all individual user access to cardholder data. 
  • Requirement 10.2.1.2: Audit logs capture all actions taken by any individual with administrative access.
  • Requirement 10.2.1.3: Audit logs capture all access to audit logs.
  • Requirement 10.2.1.4: Audit logs capture all invalid logical access attempts.
  • Requirement 10.2.1.5: Audit logs capture all changes to identification and authentication credentials including creation of new accounts, elevation of privileges, and all changes to accounts with administrative access.
  • Requirement 10.2.1.6: Audit logs capture all initialization of new audit logs and all starting, stopping, or pausing of the existing audit logs. 
  • Requirement 10.2.1.7: Audit logs capture all creation and deletion of system-level objects.
• Requirement 10.2.2: Audit logs record the following details for each auditable event:
  • User identification
  • Type, origination, and date and time of event
  • Success and failure indication
  • Identity of affected data, system component, resource, or service
    
    

Requirement 10.3: Audit logs are protected from destruction and unauthorized modifications.

It is common for individuals who have entered networks maliciously to edit audit logs to hide their activity. Adequate protection of audit logs can ensure their completeness, accuracy, and integrity and will be useful for post-incident review. 

Detailed requirement sections include:

• Requirement 10.3.1: Read access to audit logs files is limited to those with a job-related need.
• Requirement 10.3.2: Audit log files are protected to prevent modifications by individuals.
• Requirement 10.3.3: Audit log files, including any for external-facing technologies, are promptly backed up to a secure, central, internal log server or other media that is difficult to modify.
• Requirement 10.3.4: File integrity monitoring or change-detection mechanisms are used on audit logs to ensure that existing log data cannot be changed without generating alerts.

Requirement 10.4: Audit logs are reviewed to identify anomalies or suspicious activity.

Using log harvesting, parsing, and alerting tools, as well as event log analyzers and security information and event management (SIEM) solutions, can help identify events that need to be investigated. Exceptions and anomalies identified during log-review audits should always be investigated to help prevent malicious activity from taking over a network.

Detailed requirement sections include:

• Requirement 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
    • Requirement 10.4.1.1: Automated mechanisms perform audit log reviews.
• Requirement 10.4.2: Logs of all other system components are reviewed periodically.
  • Requirement 10.4.2.1: The frequency of periodic log reviews for all other system components is defined in the entity’s targeted risk analysis.
• Requirement 10.4.3: Exceptions and anomalies identified during the review process are addressed. 

Requirement 10.5: Audit log history is retained and available for analysis.

Historical records of audit logs should be retained for at least 12 months, with the most recent three months (at a minimum) available for analysis.

Requirement 10.6: Time-synchronization mechanisms support consistent time settings across all systems.

Technologies that synchronize clocks on multiple systems, called time synchronization technology, keep all system clocks in sync. This is vital when completing audits of log files to determine the correct sequence of events at the correct time to diagnose issues.

Detailed requirement sections include:

• Requirement 10.6.1: System clocks and time are synchronized using time-synchronization technology. 
• Requirement 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 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 for accuracy.
  • Internal systems receive time information only from the designated central time server. 
• Requirement 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.

Requirement 10.7: Failures of critical security control systems are detected, reported, and responded to promptly. 

All businesses should have a formal process in place to detect and alert when systems experience failures. To maintain compliance, admins should respond quickly to such alerts to reduce the amount of time malicious software and individuals have to attack a system.

Detailed requirement sections include:

• Requirement 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:
  • Network security controls
  • IDS/IPS
  • FIM
  • Anti-malware solutions
  • Physical access controls
  • Logical access controls
  • Audit logging mechanism
  • Segmentation controls (if used)
• Requirement 10.7.2: Failures of critical security control systems are detected, alerted, and addressed promptly, including but not limited to failure of:
  • 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)
• Requirement 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 of the security failure
  • Identifying and documenting the cause(s) of failure and 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
  • Resuming monitoring of security controls 

How Basis Theory can help you Satisfy PCI DSS Requirement 10

Securing cardholder data in a CDE satisfies many PCI DSS requirements and provides companies greater control and flexibility over their payment stack. However, building and maintaining the necessary infrastructure and programs can require hundreds of thousands of dollars and months to implement and assess. Basis Theory provides the platform, infrastructure, and tools to secure cardholder data in minutes and without these costs and distractions.

As a PCI Level 1 compliant service provider, Basis Theory extends an independently assessed and approved CDE to customers. Combined with a suite of configurable tools, services, and tokens, companies can collect, secure, and share credit cards without bringing their systems into scope. This approach allows companies to avoid the costs and distractions associated with 95% of the requirements in the Payment Card Industry Data Security Standard (PCI DSS) while retaining complete control over their cardholder data.

*PCI DSS Requirement information contained in this post is for educational purposes only and references material from the guide "Payment Card Industry Data Security Standard: Requirements and Testing Procedures, v4.0" published by the PCI SSC in March 2022. Please refer to the PCI Security Standards Council website for the complete, up-to-date, accurate requirements.