Whether you’re in the healthcare, retail, or hospitality industry, you’re going to need to protect your customer information if you collect payments. The Payment Card Industry Data Security Standard (PCI DSS) not only sets the standard for cardholder data (CD), but it also enforces the standard with penalties.

PCI DSS Logging and Log Monitoring Requirements

What is the Payment Card Industry Data Security Standard (PCI DSS)?

In the early 2000’s, the five major payment card companies, American Express, Discover Financial Services, JCB International, MasterCard, and Visa, Inc. banded together to create the Payment Card Industry Security Standards Council (PCI SSC). The organization wanted to create a series of information security standards processing payments that protected customers from identity theft and the card industry from paying for data breaches.

PCI SSC worked together to establish “best practices” for protecting information which became standardized as PCI DSS.

What Are The Penalties for Noncompliance?

While PCI DSS is considered a “standard” and not a regulation, many merchants incorrectly assume compliance is optional. Noncompliance leads to consequences that can cause business failure.

Card brands and acquiring banks can, at their discretion, fine noncompliant merchants anywhere from $5,000 to $100,000 per month for a violation. Depending on an organization’s size, these fines can be either crippling or devastating.

Who Needs to Be PCI DSS Compliant?

Regardless of your size or industry, any company accepting, transmitting, or storing cardholder data must maintain PCI DSS compliance.

What is PCI DSS Requirement 10?

PCI DSS Requirement 10 focuses on monitoring access to networks and data. In its most broad definition, Requirement 10 states:

Requirement 10: Track and monitor all access to network resources and cardholder data

Logging 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 in all environments allows thorough tracking, alerting, and analysis when something does go wrong. Determining the cause of a compromise is very difficult, if not impossible, without system activity logs.

Essentially, Requirement 10 requires you to continuously monitor the user access to your environment. Setting up user access controls is the first step to maintaining a secure cardholder data environment (CDE), but you also need to ensure that those controls work.

Embedded within Requirement 10, however, are 39 subparts. Since PCI DSS is a highly prescriptive standard, it sets out a clear list of the steps and documents needed to meet its requirements.

What records are necessary for Requirement 10 Compliance?

If you’re looking to be PCI DSS compliant, the standard not only lists the sections and subsections and parts of subsections, but it also incorporates Guidance to help understand effective control review. As such, the following steps can help you log data necessary to prove your compliance:

1. Create a system or process linking user access to the system components accessed and make sure you can trace suspicious user activity to a specific user.
2. Generate audit trails that prove the system administrator receives suspicious activity alerts and follows up on them.
3.  Record all individual accesses to the CDE to show that new or unauthorized user accounts have not accessed the systems and networks.
4. Ensure you collect records of activities performed by “administrator” or “root” accounts that show potential misuse of these accounts and can trace the issue to a specific action and individual
5. Maintain file integrity of audit logs by having a way to identify changes, additions, and deletions to them.
6. Record invalid login attempts to trace “brute force” attacks or password guesses.
7. Maintain records that allow you to trace activities indicating manipulation of authentication controls by attempting to bypass them or impersonating a valid account, including but not limited to records that verify mechanisms, elevation of privileges, and any changes/additions/deletions to root or administrative accounts.
8. Document any pauses or restarts to your audit logging processes.
9. Maintain records to show that system-level object, such as databases or stored procedures, have not been created or deleted by unauthorized accounts.
10. For all system components, maintain an event log that records user identification, event type, date/time stamp, success/failure indication, event origination, and affected data, system component or resource identity/name.
11. Synchronize clocks across systems to maintain exact sequences of events for forensics teams.
12. Use “principle of least privilege” for audit log access to maintain security and integrity of the information.
13. Backup logs to a centralized server or media that maintains data integrity.
14. Write logs directly, or offload or copy from external systems to a secure internal system or media.
15. Use file-integrity monitoring or change-detection systems to ensure notification of audit log changes that may indicate a compromise.
16. Engage in regular log reviews either manually or by using a log harvesting, parsing, and alerting tool.
17. Engage in daily review of security daily for notifications or alerts indicating suspicious activity and critical system component logs.
18. Schedule periodic reviews for all system components that indicate potential issues or attempt to gain access to sensitive systems by using less sensitive systems.
19. Document investigations of exceptions and anomalies.
20. Retain all records for at least a year.
21. Ensure employees are trained and aware of security policies and monitoring.

Service providers are subject to the following additional requirements:

1. Establish formal procedures to detect and alert critical security control failures, such as a firewall erasing rules or going offline.
2. Document evidence supporting the response to a security failure, including the processes and procedures as well as the actions and responses.