In a recent post, we discussed some scenarios involving Service Providers and their integration into Payment Card Industry Data Security Standard (PCI DSS) compliance. Click here for more of our recent series of blog posts on PCI DSS-related topics for more information.
Defining the cardholder data environment (CDE) is a key step toward PCI DSS compliance and has become somewhat of a pain point when determining scope since the introduction of PCI DSS version 3.0. PCI DSS version 3.2 introduced additional complexity by adding a new control requiring multi-factor authentication for any non-console administrative into CDE systems, including systems like web applications. For insight into how WMP approached this control for a client, see our blog post “Managing Administrative Access To an Azure-Based PCI Environment.” There are several approaches to minimizing scope depending on the technologies used and business processes involved. This post will focus on some approaches to limit scope increase when allowing access to additional resources and areas to consider where scope can be maintained or reduced.
One of the clearest ways to reduce scope is through allowing a smaller number of devices to access the CDE. In general, the greater the number of devices that can access the CDE, the larger the administrative burden. However, reducing the number of devices with access is not always possible due to designated resources who need access to the CDE to perform their daily duties.
Devices that are connected to CDE systems or that can impact the security of those systems are considered in scope from a PCI DSS perspective. The best way to reduce PCI DSS scope, and prevent increase of scope, is to physically and/or logically separate those devices from the rest of the systems in the environment. The benefit here is twofold:
- Provides a clear delineation between in scope and out of scope systems
- Identifies areas where controls need to be implemented to restrict access to the environment
Once network isolation is achieved, the use of a solution such as a can allow access to the CDE without further increase of PCI scope, as connecting to the jump host cannot directly impact the security of the environment without proper authorization.
An additional solution to minimize the scope of compliance is to utilize dedicated devices on isolated network segments that are only used to process cardholder payments or perform administrative functions within the isolated environment. These devices are typically found in the form of point of sale terminals in retail locations or call center workstations in the case of phone-based retail processes. These dedicated devices will interact with systems within the boundaries of the CDE and have no access to systems outside of the isolated CDE. The downside to this approach is the introduction of additional devices to maintain, potentially duplicating functionality between two environments, (e.g., two anti-virus servers, two centralized logging servers, etc.). Depending on the payment processes and application workflows, this solution may be easier to achieve in some cases.
For more administrative-level tasks within the CDE, utilizing multi-factor authentication (MFA) as a means of accessing the CDE has been a recommended standard since version 3.0 of the PCI DSS. This may involve utilizing MFA on a remote desktop session (aka a “jump host”), from which an administrator can gain system level access or console access to any systems in the CDE. With some of the recent changes introduced by PCI DSS version 3.2, multi-factor authentication is now required when performing non-console administrative access as well. This non-console access may include web based administrative interfaces that control systems within the CDE.
As an example, assume there is a web application that allows both end users and administrators the ability to log into their accounts through the same URL / interface, with the key difference being the features presented to the user post authentication. With the recent MFA changes, any access to an account that allows the modification of other accounts, or administrative level tasks, would need utilize MFA prior to gaining access. This requirement is new for web applications or other systems that may have some form of non-console-based administrative access that’s exposed outside of the CDE. When considering the example of a web application, approaches to meet compliance might include:
In many scenarios, a system may need to know that a legitimate card number has been provided, but may not need to see or interact with the full 16 digits of the primary account number (PAN). In these scenarios, the PAN may be “tokenized” with little or no impact to the process or system that uses the token. Tokenization is a process whereby a card number is replaced with a different string of characters, which may or may not use the same 15 or 16 digit format of the PAN, and all subsequent operations utilize the replacement characters rather than the original number. The benefit of this tokenization is that only the systems that originally receive the PAN itself, the tokenization system, and any intermediate systems, are required to be in scope for compliance. Any other system that only stores or interacts with the token can be considered out of scope for compliance, if they are appropriately isolated from other card-processing systems. It is important to note that without proper segmentation and isolation, the token-handling systems may still be considered in scope, removing the main benefit of tokenization.
Point to Point Encryption
Lastly, point to point encryption (P2PE) may be used to drastically reduce PCI DSS scope within the environment. Typically found in point of interaction (POI) devices, this technique will encrypt cardholder data directly at the terminal, and that data won’t be decrypted until it reaches the payment processor. The owner of the POI device doesn’t have access to the encryption keys, and therefore, you can consider the environment that encrypted data flows through to be removed from scope. While this can help reduce the scope of your compliance efforts, all other credit card handling processes still need to be considered when defining the full CDE. For instance, if there’s a business process to write down cardholder information and then process that information later or take telephone payments, your scope must include those processes and any associated systems.
Through the use of network isolation, dedicated devices, MFA, tokenization, P2PE or a combination, merchants can effectively reduce the scope of their CDE while still providing essential business functions. Each of these approaches should be considered when evaluating the total cost of PCI DSS compliance.