Security Logging and Monitoring (PCI DSS Requirement 10): Why all the Fuss?

Understanding PCI DSS Requirements

‍

Merchants who are just learning about the Payment Card Industry Data Security Standard (PCI DSS) can become quickly overwhelmed by its lengthy list of requirements, especially when there is no IT or security expert on staff to break it down into bite-sized chunks. In addition, many merchants may find themselves wondering whether certain requirements are even applicable to their business.

‍

Each of the 12 PCI DSS requirements do, in fact, serve a common purpose to ensure that all companies processing, storing or transmitting credit card information maintain a secure environment.

‍

While each requirement is necessary even for the smallest merchant, some can be more difficult to comply with than others.

‍

This article is dedicated specifically to PCI DSS Requirement 10, because for some it is one of the most frustrating and misunderstood obstacles to compliance:

‍

Regularly Monitor and Test Networks

‍

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 and 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.

‍

(Source: PCI DSS Requirements and Security Assessment Procedures, Version 2.0.)

‍

Prior to the PCI DSS, “logging” (i.e., maintaining a historical account of the people and activity associated with an information network) was not something most organizations regarded as necessary, because they did not consider it to be integral to the protection of cardholder data. As a result, many organizations have implemented technology platforms and information systems without an understanding of the need for logging and monitoring.

‍

Why Requirement 10 Exists

‍

When dealing with Requirement 10—and indeed any requirement set forth by the DSS—it’s important to understand the basic intent behind the requirement’s creation. Requirement 10.1 states this goal fairly succinctly:

‍

“Establish a process for linking all access to system components (especially access done with administrative privileges such as root) to each individual user.”

‍

The intent of PCI DSS Requirement 10, then, is to determine the “who, what, where and when” of users accessing your data processing resources:

‍

• In this instance, “system components” refers to the parts of the system (read: application or computer) that store, process or transmit cardholder data.
• “To each individual user” refers to any employee who uses the system. This is comparable to a retail situation in which employees are required to sign into cash registers; if a till comes up short during the nightly count, it’s important to know who worked that particular register.
• The reference to “access done with administrative privileges” is highlighted, because administrative users have primary control and power over the system.

‍

Knowing who accessed the system and what they did there is critical in the event that an asset (in this case, cardholder data) goes missing, or even if there is a suspicion of foul play. Failure to properly factor all internal and external users into your logging mechanism can leave you unable to substantiate a breach timeline or pinpoint responsibility.

‍

While the cash register analogy serves as a basic example, most organizations accept payments through numerous means, including by telephone, mail and through the Internet. Therefore, all internal resources—including employees and their methods of collecting and processing cardholder information—should be considered. In addition, if you contract with an outside company that provides technical support or troubleshooting, they may also have access to the data you are storing or processing.

‍

“Administrative users” must also be uniquely tracked. Often, when outside organizations assist companies in troubleshooting their IT systems, they may need the same level of administrative access as employees of the organization. In order to minimize the risk of outside users compromising the company’s sensitive information, it’s imperative to understand and track what actions have been performed on the system during that process. The same is true of organizations where there may be administrative users writing custom code, accessing sensitive data or logging into systems—even if the administrators work for the organization.

‍

What Requirement 10 Means to You

‍

So what does all of this mean for you—the owner or administrator—who must comply with all of the requirements set forth by the PCI DSS? In a nutshell, it means that you must be able to identify who was logged into or using a system at any given time, what they did on the system and whether they accessed the system in person or over an electronic connection.

‍

The DSS sets forth the requirements contained in Section 10 because they are the most reliable method of identifying users accessing data on electronic systems. With enough of these elements successfully and functionally implemented, they will provide a state of non-repudiation, which means that a user cannot challenge or deny that they performed the action in question. In fact, without non-repudiation there is almost no chance that you can successfully prosecute someone for theft or criminal actions conducted online.

‍

The DSS is explicit about the requirements for auditing and logging. Here are a few of the requirements and why they’re important:

‍

• Assigning users unique usernames using a documented process.

‍

This practice ensures that you will be able to reliably identify the user or access code that performed the action in question. For example, if I am logged into the system as the user ‘jdoe,’ the system should always track the actions performed by my username and tie me to each of them. If Sally and Bob share the same user account, and it later turns out that the account was shown to have deleted an important piece of data, it will be much more difficult (if not impossible) to prove which person actually carried out the action.

‍

• Logging access to the very logs and audit trails generated by the application or system.

‍

If someone can log in and delete the logs, that user will have essentially prevented you from proving that they carried out the action in question—such as moving money from one account to the other, or accessing data of a sensitive nature. Administrators should be the only system users with access to view, modify or delete the logs, and even then you should be able to uniquely identify which administrator did so by ensuring that a shared administrator account is not used by multiple users.

‍

• Ensuring that systems and applications have the correct time set.

‍

Timestamps (i.e., a piece of data associated with each action, showing the time the action occurred) are important because they create a window during which malicious or inappropriate actions have occurred. When investigators attempt to reconstruct the event, they need to know who was logged into the system during that time and what other actions occurred during that window.

‍

• Examining the logs on a regular basis.

‍

Regular monitoring helps you identify malicious or inappropriate actions sooner than later. This can involve an actual person looking at logs line by line; however, most organizations today utilize automated applications that read the logs and extract interesting or unusual events based on predetermined parameters and notify administrators by email.

‍

Log Monitoring and PCI DSS Compliance

‍

Moving forward, it should be easy to comply with this rule, as most software packages and applications come equipped with the ability to perform the level of logging required for compliance; however, this capability may not always be enabled out of the box. When selecting software vendors and applications for use within the PCI environment, ensure they provide all of the requirements described in PCI DSS Requirement 10. All modern operating systems, including Windows, Linux and Mac OS X, also provide these functions out of the box, but they require additional work to turn them on and tune them to the required settings.

‍

At the end of the day, remember that the PCI DSS is all about intent, and the intent here is reconstructing an electronic theft or data breach to determine when it occurred, how it occurred and who carried it out. Organizations that can demonstrate this ability will not only comply with the intent and rigor of the DSS, but will also ensure that data compromises—when they happen—can be detected quickly and investigated thoroughly.

‍

Read more about how to ensure PCI DSS compliance or contact the VikingCloud team for more information.

‍