AWS Lambda Logging & Monitoring Tutorial
Going serverless relieves you of setting up servers, updating operating systems, or maintaining physical infrastructure. But what happens when a function doesn’t work and things go…
Our next-gen architecture is built to help you make sense of your ever-growing data Watch a 4-min demo video!
Formats: PNG, PDF, and SVG
Files size: 2.8 MB
For brand guidelines, please click here
For an organization to be compliant with PCI logging requirements, it must follow PCI Requirement 10 of the Payment Card Industry Data Security Standards (PCI DSS). Below, we’ve listed the highlights of this section and the important details that you need to know.
For PCI logging compliance, a critical aspect of data protection is logging and tracking. Implementing logging mechanisms at a company provides the ability to track user activities, which is crucial in preventing, detecting, and minimizing the consequences of a data breach.
To comply with this requirement, organizations need to keep track of user access to all system components. Every user, particularly the administrators, should be monitored over the network and their activities should be checked. This allows organizations to track suspicious activity back to a specific user or administrator.
It isn’t easy to keep track of all systems component access. Requirement 10.2 recommends organizations implement automated audit trails for system components for the following events:
This requirement states that audit trails log all individual user accesses to cardholder data – pretty straightforward, right? PCI DSS guidance explains that malicious individuals could obtain knowledge of a user account with access to systems in the Cardholder Data Environment, or they could create a new, unauthorized account to access cardholder data.
A record of all individual accesses to cardholder data can identify which accounts may have been compromised or misused. Whenever someone accesses cardholder data, a log should be generated.
Accounts that have root or administrative privileges have a greater chance of impacting the security and functionality of a system, as these accounts have full control over a network and they can easily access all sensitive information related to cardholder data.
Requirement 10.2.2 mandates organizations to implement automated audit trails, to log all actions taken by an individual with root or administrative privileges. Logging should record the administrator user name, the areas accessed, the changes made and the time spent.
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 actions made by unauthorized users.
Invalid logical access attempts are often an indication of a malicious user attempting to gain unauthorized access. This PCI logging requirement requires that organizations implement automated audit trails to log invalid logical access attempts. You should log all of these events:
Similarly to 10.2.2., organizations should implement automated audit trails to log the use of, and changes to, identification and authentication mechanisms, such as the creation of new accounts and elevation of privileges and all changes, additions, or deletions to accounts with root or administrative privileges.
You need to know who logged on and when. When there is a breach, visibility of the active accounts gives you a place to begin investigating.
Stopping or pausing audit logs before performing malicious activities is common practice for users hoping to avoid detection. The initialization of audit logs or clearing of log data could indicate that the log function was disabled by a user. To comply with this requirement, audit trails should log the initialization, stopping, or pausing of audit logs.
Requirement 10.2.7 requires audit trails to log the creation and deletion of system-level objects.
The PCI DSS defines a system-level object as anything on a system component that is required for its operation, including but not limited to database tables, stored procedures, application executables and configuration files, system configuration files, static and shared libraries and DLLs, system executables, device drivers and device configuration files, and third-party components. Malware often creates or replaces system-level objects on the target system to control a specific function. The purpose of this requirement is to make it easier to determine whether those modifications have been made to any system-level objects.
Requirement 10.3 states organizations should record the following audit trail entries for all system components for each event:
These components will help quickly identify and provide details related to who, what, when, where, and how compromises occurred.
Time-synchronization technology helps to synchronize clocks on multiple critical systems. If you do not synchronize these clocks correctly, comparing different log files in different systems to build a proper sequence of events and activity timings becomes very difficult.
Using Time-synchronization technology, such as Network Time Protocol (NTP) is recommended.
Audit trails contain all the correct information about events and incidents, so malicious individuals will often seek to alter log files to hide their actions.
To comply with 10.5., organizations must limit access to audit trails to personnel with business-related needs. They must also protect audit trails from unauthorized modifications, back up audit trail files on a centralized server, and write logs for external-facing technologies onto a centralized, internal log server.
Audit trails contain sensitive information that only some members of an organization should have access to. If a user does not have a business need to view log files, then don’t grant them access.
Audit trails contain all the correct information about events and incidents in critical systems, so malicious individuals will often seek to modify log files to hide their actions. If an approved individual in an organization finds unencrypted cardholder data or sensitive data in a log, they may want to modify the log file to encrypt this data.
The purpose of this requirement is to prevent unauthorized modifications to audit trail files. Promptly backing up log files to a centralized log server or media that is difficult to alter keeps the logs protected even if the system generating log files becomes compromised.
Organizations should write logs from external-facing technologies such as wireless, firewalls, DNS, and mail servers onto a secure device. This minimizes the risk of those log files being lost or compromised as they are more secure within the internal network.
Organizations should use file-integrity monitoring or change-detection software on log files to ensure that existing log data cannot be changed without generating alerts (new data being added should not trigger an alert). Check for changes to critical files and provide notification when such changes are noted.
Many security breaches occur over a period of time before being detected. How can anomalies or suspicious activity be identified if the logs are not reviewed?
Organizations could meet this requirement through manual reviews by training employees to review log data and identify suspicious activity. Other options are automated methods such as log harvesting, parsing, and alerting tools.
Organizations should review the following logs at least daily:
Based on the organization’s annual policies and risk management strategy, you should determine which system components should or should not be prioritized for log review.
Simply put, logs not covered in Requirement 10.6.1. should be reviewed periodically.
Following a log review, an organization must follow up on any and all exceptions and anomalies identified. You must take appropriate actions to any incidents that might be impacting the cardholder data environment.
This PCI logging requirement expects organizations to retain audit trail history for at least one year, with a minimum of three months immediately available for analysis. The reasoning behind the recommended length of time is because it may take months to notice a security compromise. However, 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.
This is an additional requirement for service providers only.
Without formal processes in place to monitor when critical security controls have failed, failures could go undetected for long periods. This provides malicious individuals with opportunities to compromise your systems and obtain sensitive cardholder data.
Service providers must implement a process for the timely detection and reporting of failures of critical security control systems. This could be the failure of things like firewalls, anti-virus, physical access controls, logical access controls, or audit logging mechanisms.
This is an additional requirement for service providers only.
Service providers should respond to any failures of any critical security controls promptly.
The organization’s policies and procedures should outline the expected response to failures, which includes how to:
To comply with this final PCI logging requirement, organizations should ensure that all security policies and operational procedures, monitoring all access to the network resources and cardholder data, are documented, in use, and known by all affected parties.
Requirement 10 of the PCI Data Security Standard is directly concerned with network access and security, making it one of the most important requirements in the PCI DSS guidance.
Therefore, in order for an organization to comply, all the PCI logging policies, procedures, and standards described above must be implemented.