As we move through the requirements for PCI DSS 4.0, we’re coming up to the double digits, which means some more advanced expectations. Namely, the tenth requirement focuses on system logging and monitoring for systems containing cardholder data. 

The maintenance of audit logs is about more than automatically recording data about system events. Your system must secure, protect, and ensure the integrity of that information to serve a role in incident prevention and investigation.

What Are System Logging and Monitoring in PCI DSS 4.0?

System logging and monitoring are critical parts of security, providing security experts and professionals with the necessary information to analyze and address security issues. Because system forensics is such an essential part of cybersecurity, there are subsequent rules and best practices for logging and monitoring.

Both monitoring and logging tend to come at the problem of forensics and information from two different directions. 

System Monitoring

System monitoring is generally preventative in that monitoring allows administrators to notice inconsistencies or anomalies in a system as or shortly after they occur. Automated tools and software can monitor active systems to determine anomalous activity. 

However, since these systems are composed of several different components, each with their operations, data flows, and interfaces, such monitoring solutions will typically focus on (or integrate with) specific types of system observation. 

These can include:

• Network: Network monitoring will often include tracing packet traffic across the network, noticing anomalies with packet structure or formation, unexpected or unauthorized access to the network, or issues arising from interactions with network devices.
• Application: App monitoring will typically look at user-facing applications, covering anomalous user activity, attempts to breach authentication systems or performance-related issues based on how users interact with the app interface. 
• API: APIs offer deep access to a system, including resources and the code that makes up the app. Thus, API security is crucial, and API monitoring tools can track API calls from third-party users to track the resources and code they access and what kind of requests they make. 
• User: Real user monitoring (RUM) can trace user interactions and behaviors to determine patterns and calling cards around the system that could point to potential vulnerabilities. 

System Logging

System logging, rather than actively scanning a system or noticing different behavior patterns, provides forensic information about those patterns, behaviors, or activities. Logs are records of system events that store critical data about that event that can be used to create a picture of the event’s context and its relationship with other events within the system.

Logs are a critical, necessary part of cybersecurity, and as such, they also include several requirements for how organizations manage and protect them. These can include:

• Storage: Logs must be stored in a central, predictable location so that auditors can readily access them individually or as a series for investigatory purposes.
• Security: Logs contain private data, including a user’s location or mission-critical information. As such, logs must be protected against unauthorized access. 
• Enrichment: While audit logs may gather core information from a system event or user activity (like the type of activity, the time, date, etc.), administrators can also configure logging solutions to add additional data (like user location, IP addresses, etc.) that can provide additional context for the event. 
• Integrity: Logs are essentially worthless if they cannot be trusted, and as such, the integrity of those logs is paramount. Some industries will dictate that integrity and security measures must be in place to ensure this integrity as part of compliance regulations.
• Analysis: Logs will often come in a format that isn’t human-readable or at least human-friendly. Auditing and analytics solutions can ingest logs and render them readable and useful for security administrators.

What Is the Tenth Requirement of PCI DSS 4.0?

The tenth requirement of PCI DSS 4.0 focuses on both logging and monitoring as information-gathering mechanisms for organizations handling cardholder data. These mechanisms must provide ways to support the tracking of security issues and user activity both externally and internally. Likewise, this requirement guides how these businesses can keep an entire audit trail to use as a forensic and legal tool to identify, trace, and remedy security issues.

10.1 – Process and Mechanisms for Logging and Monitoring 

• Documentation and Responsibilities: The first part of this requirement emphasizes the need for documented, up-to-date, and evolving policies and procedures around audit logs and monitoring. This includes defining and maintaining roles and responsibilities around managing, maintaining, and implementing such solutions.

10.2 – Audit Logs Are Implemented to Support the Detection of Anomalies

• The Function of Logs: Audit logs must be enabled for all components in a CDE and any system containing cardholder data. These logs must capture all individual user access to cardholder data, including administrative or application data. This includes both valid and invalid login attempts, changes to credentials and privileges, and any attempts to access audit logs themselves.
• Information Required for Logs: For any event captured, the audit log system must record, at least, user identification, the type of event, date and time of the event, success or failure, origination of the event, and the data or component affected. 

10.3 – Audit Logs Are Protected from Destruction and Unauthorized Modifications

• Log Access and Authorization: Access to read audit logs is based on a need-to-know basis. Furthermore, these logs must be protected against tampering or modification.
• Backups: Logs are promptly blacked up to secure archiving servers or other media where they can be protected. 
• Integrity: Logging solutions must have some sort of change-monitoring mechanism in place to ensure the integrity of a log.

10.4 – Audit Logs Are Reviewed to Identify Anomalies or Suspicious Activity

• Audit Log Reviews: There must be a daily, automated review of audit logs that cover all security events, logs of critical system components, and all components performing security functions. Furthermore, there must be a periodic review of other components not falling into these categories.
• Review Anomalies: Any anomaly found during a review must be addressed.

10.5 – Audit Log History Is Retained and Available for Analysis

• Retention: Organizations must retain audit log histories for at least 12 months, and the most recent three months of logs must be made readily available for analysis.

10.6 – Time-Synchronization Mechanisms Support Consistent Time Settings

• Synchronization: Special technology must be implemented to synchronize system clocks across logged systems to ensure that logs accurately reflect events over time.
• Time Server Configurations: To ensure correct and consistent clocks, logging systems must designate at least acceptable one time server that bases time measurements on International Atomic Time or Coordinated Universal Time (UTC). These time sources must be industry-accepted, and the organization may only have one server receiving time from this external source.
• Access Restriction: Access to time data is restricted to users with business or administration needs, and any change to time settings must be logged.

10.7 – Failures of Critical Security Control Systems are Detected, Reported, and Responded to Promptly

• Logging and Monitoring System Failures: System failures in an organization’s system, or the system of a vendor, are detected, alerted, and addressed quickly. These failures include those network security controls, change-detection mechanisms, anti-malware programs, physical and logical access controls, audit logging and review solutions, and automated security testing tools.
• Responses: Any failures are responded to promptly. Responses include restoring security functions, identifying compromised data and systems, implementing preventative measures, and resuming monitoring and logging capabilities.

Prepare for PCI DSS 4.0 with Lazarus Alliance

As we dig into the requirements of PCI DSS, you will see the increasing complexity and interoperability of the different technologies, policies, and practices you’ll need to deploy to receive PCI verification and maintain compliance. These practices aren’t just to complete a checklist. However–they are tried-and-true security practices that will help support your security efforts ten years from now. 

Are You Thinking Ahead for PCI DSS 4.0?

Call Lazarus Alliance at 1-888-896-7580 or fill in this form.