PCI Requirement 10 Archives

Root or Administrative Privileges

Accounts that have root or administrative privileges have a greater chance of impacting the security and functionality of a system. This is why PCI Requirement 10.2.2 requires that organizations implement automated audit trails to reconstruct all actions taken by an individual with root or administrative privileges. Without logging mechanisms enabled, how could you trace issues resulting from misuse or root or administrative privileges?

To verify compliance with PCI Requirement 10.2.2, an assessor will observe audit logs and interview the responsible personnel to ensure that all actions taken by an individual with root or administrative privileges are being logged.

[av_toggle_container initial=’1′ mode=’accordion’ sort=” custom_class=”]
[av_toggle title=’Video Transcript’ tags=”]

Anytime anybody with administrative access or privileged access performs an action, those things need to be logged – whatever they’ve done needs to be logged. If there’s one reason why an individual should not be running around checking their email with administrative privileges, this might be it. From an administrative and logging perspective, what we recommend is that they might have two accounts. One for their normal administrative actions and then another account set aside for their normal online activities such as surfing the Internet or checking their email. But effectively, all actions taken by anybody with root or administrative privileges needs to be logged. Where we often find problems with PCI Requirement 10.2.2 is the logging of your changes or logging of your network. For example, if you log into a firewall or router, those are administrative actions that need to be logged. The assessor is going to be make sure that logging is enabled; they’re going to be looking for evidence that any time somebody does anything from an administrative perspective, those actions get logged.

[/av_toggle]

[/av_toggle_container]

Identifying Which Accounts Have Been Compromised

PCI Requirement 10.2.1 requires that audit trails reconstruct all individual user accesses to cardholder data. What is the purpose of PCI Requirement 10.2.1? The PCI DSS guidance explains, “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.”

Anytime someone accesses cardholder data, a log should be generated. An assessor will work with your database and network administrators to verify that all individual accesses to cardholder data is logged.

Anytime anybody accesses cardholder data, a log should be generated. The assessor is going to have worked with your database administrators and your network administrators, and in having them queried, the data that you might have on site. As part of this, the assessor is likely to remember those times, dates, and individuals that perform those actions. They might also ask you to recall those logs to demonstrate that your applications are logging or your servers are logging the appropriate necessary information to meet PCI Requirement 10.2.1.

What Do I Log?

Because PCI Requirement 10 requires that logging mechanisms be enabled, we often hear clients ask, “What do I log?” The PCI DSS gives us specific insight into which events need to be logged so that audit trails can provide a history to help identify and trace malicious activities. PCI Requirement 10.2 requires that organizations implement automated audit trails for all system components to reconstruct the following events:

All individual user accesses to cardholder data
All actions taken by any individual with root or administrative privileges.
Access to all audit trails.
Invalid logical access attempts.
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.
Initialization, stopping, or pausing of the audit logs.
Creation and deletion of system-level objects.

[av_toggle_container initial=’1′ mode=’accordion’ sort=” custom_class=”]
[av_toggle title=’Video Transcription’ tags=”]

From an organizational perspective, you’re required to have logging enabled. We often hear the question, “Well, what do I log?” The PCI DSS is very specific in terms of the events that occur that need to be logged, and you can find those specific requirements in PCI Requirement 10.2. The following topics are those items that need to be logged.

[/av_toggle]

[/av_toggle_container]

Audit Trails

PCI Requirement 10.1 is a pretty straightforward requirement. It states, “Implement audit trails to link all access to system components to each individual user.” This means that everything in scope should have logging enabled to allow organizations to track suspicious activity back to a specific user. To verify compliance with PCI Requirement 10.1, an auditor will observe and interview a system administrator to see that audit trails are enabled and active for system components and access to system components is linked to individual users.

[av_toggle_container initial=’1′ mode=’accordion’ sort=” custom_class=”]
[av_toggle title=’Video Transcript’ tags=”]

PCI Requirement 10.1 is pretty plain and simple. It says that everything that’s in scope should have logging enabled, and that’s kind of the end of the conversation there. From an assessment perspective, we’re going to be looking at your applications; we’re going to be looking at your routers, your firewalls. We’re going to be looking at everything within your environment to make sure that logging is actually enabled.

[/av_toggle]

[/av_toggle_container]

Importance of Logging and Tracking

If data was compromised at your organization, how would you determine the cause? PCI Requirement 10 focuses on a critical aspect of data protection: logging and tracking. Implementing logging mechanisms at your organization gives you the ability to track user activities, which is crucial in preventing, detecting, and minimizing the consequences of a data breach. Without logging and tracking, it’s even more difficult to find the source of the data breach. This is why PCI Requirement 10 requires, ““Track and monitor all access to network resources and cardholder data.”

How to Track and Monitor All Access to Network Resources and Cardholder Data

To ensure that organizations implement logging and tracking mechanisms and track and monitor all access to network resources and cardholder data, PCI Requirement 10 details the following sub-requirements:

10.1 – Implement audit trails to link all access to system components to each individual user.
10.2-10.2.7 – Implement automated audit trails for all system components to reconstruct the following events: all individual user accesses to cardholder data, all actions taken by any individual with root or administrative privileges, access to all audit trails, invalid logical access attempts, use of and changes to identification and authentication mechanisms and all changes, additions, or deletions to accounts with root or administrative privileges, initialization, stopping, or pausing of the audit logs, and the creation and deletion of system-level objects.
10.3-10.3.6 – Record at least the following audit trail entries for all system components for each event: user identification, type of event, date and time, success or failure indication, origination of event, and identity or name of affected data, system component, or resource.
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.
10.4.1 – Critical systems have the correct and consistent time.
10.4.2 – Time data is protected.
10.4.3 – Time settings are received from industry-accepted time sources.
10.5 – Secure audit trails so they cannot be altered.
10.5.1 – Limit viewing of audit trails to those with a job-related need.
10.5.2 – Protect audit trail files from unauthorized modifications.
10.5.3 – Promptly back up audit trail files to a centralized log server or media that is difficult to alter.
10.5.4 – Write logs for external-facing technologies onto a secure, centralized, internal log server or media device.
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.
10.6 – Review logs and security events for all system components to identify anomalies or suspicious activity.
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, and logs of all servers and system components that perform security functions.
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.
10.6.3 – Follow up exceptions and anomalies identified during the review process.
10.7 – Retain audit trail history for at least one year, with a minimum of three months immediately available for analysis.
10.8 – Additional requirement for service providers only: Implement a process for the timely detection and reporting of failures of critical security control systems, including but not limited to failure of: firewalls, IDS/IPS, FIM, anti-virus, physical access controls, logical access controls, audit logging mechanisms, and segmentation controls.
10.8.1 – Additional requirement for service providers only: Respond to failures of any critical security controls in a timely manner. Processes for responding to failures in security controls must include: restoring security functions, identifying and documenting the duration of the security failure, identifying and documenting cause(s) of failure, including root cause, and documenting remediation required to address root cause, identifying and addressing any security issues that arose during the failure, performing a risk assessment to determine whether further actions are required as a result of the security failure, implementing controls to prevent cause of failure from reoccurring, and resuming.
10.9 – 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.

PCI Requirement 10 is specifically focused on the log generation and being able to attribute actions back to an individual account; not necessarily back to an individual person, but back to an individual account. This would encompass making sure that logging and tracking is enabled. It defines the requirements around when an event happens, what gets logged, and your time management when reviewing these logs. Have a look at the rest of these videos and PCI Requirement 10 for the specific information around logging and tracking.