What Are the Effects of Using Active Directory as a Shared Service on PCI Compliance?

It is undeniable that it is highly dangerous to use Microsoft Active Directory as a “Shared Service” and takes a lot of technical configuration and discipline to protect the environment with best practices. Breaking just one of these technical controls, or disciplining applied best practices, could compromise the secure environment and breach cardholder data.

From a PCI DSS perspective, Microsoft Active Directory can be treated as a “Shared Service” because the same Microsoft Active Directory can be used to service the in-scope Cardholder Data Environment (CDE) and out-of-scope environments.

See Also: Scoping and Segmentation for PCI DSS

It is recommended that a separate Microsoft AD environment be designed to support CDE and non-CDE environment, as sharing the Microsoft AD environment will create unnecessary risks to CDE and processed cardholder data (CHD).

Incorrect configurations to a shared Microsoft AD over time will only increase the likelihood of a breach. Therefore, a shared Microsoft AD is an important risk that must be well managed to keep the environment safe.

The PCI SSC Scoping Guide discusses the concept of network segment by dividing it into 3 categories within different security boundaries. The three network segment system categories specified by the PCI SSC manual are as follows:

• Category 1 – CDE Systems,
• Category 2 – Connected or Security-impacting Systems (Shared Services),
• Category 3 – Out of Scope Systems.

We can explain a little more below what the PCI scope categories are:

Category 1 systems directly process, store, or transmit sensitive authentication data (SAD) or cardholder data (CHD) or are located in a network segment and can be directly evaluated or the same as those systems. Category 1 systems are systems that process, store or transmit SAD / CHD. Category 1 systems are systems that reside in or form the cardholder data environment (CDE) and are always under PCI compliance.

Category 2 systems are systems that do not directly process, store or transmit SAD / CHD but provide services to Category 1 systems such as directory services, DNS, DHCP, SIEM, NTP are segmented and have controlled access from there. Category 1 systems are segmented through a firewall or jumper box. Category 2 is typically referred to as “Shared Services,” i.e., services shared between Category 1, Category 2, and Category 3 systems.

Category 2 systems include system administrator workstations that access Category 1 systems via a jump box. Another example of Category 2 systems is workstations that work with Category 1 systems over virtual desktop (VDI) technology. VDI is a Category 1 system because workstations using VDI are Category 2.

As a result, Category 2 systems are always PCI compliant because they can affect the security and controls of the CDE.

Category 3 systems cannot access Category 1 systems in any way, including the jumper. Category 3 systems only are excluded from PCI compliance. However, Category 3 systems may be provided services by Category 2 systems and still be considered out of scope for PCI compliance.

Category 1 and Category 2 systems are considered PCI compliance, so the relevant PCI controls must be applied to these devices. It would be best to evaluate Category 2 systems as rigorously as Category 1 because they are PCI compliance by definition and are no different from Category 1 systems.

Directory services, DNS, DHCP, and other services can also be found on an organization’s CDE. They connect to other service providers within the organization in Shared Services to simplify the management of services. Often they are only inside the CDE for performance or usability issues, not security reasons.

The overall purpose of Category 2 is to provide a space where such services can be positioned to serve all system categories. Since the services are shared between all categories, the name “Shared Services” comes from here.

See Also: How is the PCI Network Segmentation Affecting the PCI Scope

The basic concept here is that CDE systems and out-of-scope system segments should never have direct connectivity. “Shared Services” can operate in connected or environments that affect CDE security, which can serve both CDE and out-of-scope segments.

PCI DSS assessment activities cover CDE systems and Connected or Security Affecting Systems (Shared Services). At the same time, typically, the out-of-scope segment is excluded for PCI DSS assessment activities.

The PCI SSC guidance document also includes Microsoft Active Directory as a “Shared Service” that can serve both CDE systems and out-of-scope segments.

Administrator access can access the threat actor through Firewalls / Access Control Lists (ACLs) and provides segmentation across various network segment security boundaries. Therefore, the purpose of PCI MS Active Directory segmentation is to specify an Active Directory configuration for connected or Security Affecting Systems (Shared Services) and CDE systems that protect the Active Directory infrastructure from a domain-level attack and only limits exposure to out-of-scope devices.

In the PCI SSC Scoping Guide, it is stated that the purpose of segmentation is to prevent out-of-scope systems from communicating with systems in the CDE or from affecting the security of the CDE.

Segmentation is typically accomplished through technologies and process controls that allow differentiation between CDE and out-of-scope systems. A compartmentalized (out of scope) system component does not affect the security of the CDE when correctly implemented, even if an intruder gains administrative access to the out-of-scope system.

Domain Controllers can be placed in different locations, such as CDE systems, Connected or Security-impacting Systems (Shared Services), and out-of-scope systems. Regardless of their deployment, if Microsoft Active Directory Sites and Services are configured correctly, you can still restrict which DCs to use with authentication to limit extensive access through firewalls from many Domain Joined hosts.

Multiple services running within a Windows infrastructure have varying port requirements for Microsoft Windows and Microsoft AD to work properly. The table below lists the various port requirements that allow connection between Windows workstations and DCs and intra-DC communications.

These ports are used to support but are not limited to the services listed below. For a breakdown of ports and services, you can refer to the following Microsoft article; “Service Overview and Network Port Requirements for Windows.”

Therefore, the firewall ports mentioned above will be included between PCI out of scope systems and PCI Connected or Security-impacting Systems in the above diagram, and between CDE systems and Connected or Security-impacting Systems. Also, these ports will probably need to be in both directions.

See Also: How Micro Segmentation Can Help You in the PCI Compliance Process?

As you can see from the table, Microsoft Active Directory port requirements will bring many additional security concerns to the environment. Since Microsoft Active Directory services are often the target of threat actors who want to find 0-day vulnerabilities, they can reveal user credentials or vulnerabilities.

What are the Domain Controller PCI DSS Requirements?

Once the Domain Controller is placed in the out-of-scope system zone, it will continue to be in scope for all applicable requirements. The environment setup is effective on which PCI DSS Version 3.2.1 requirements apply to the Domain Controller, and the requirements may be at QSA’s discretion.

The specified requirements cover the Domain Controller scenario in the out-of-scope system’s zone and do not include organizations’ general PCI DSS requirements.

Concerning PCI DSS requirement 1, WFAS applies as DCs must be configured to reduce the attack surface. Other “in scope” devices are; For example, a Jump Box / PAWS resides at remote sites where RODCs are located, a hardware firewall can be used to protect the components in scope.

This will depend heavily on the environment, as WFAS can simplify firewall configuration as Windows can pre-configure it based on installed roles/components.

The following requirements have been determined not to be potentially applicable;

• PCI DSS Requirement 1.1.4 – DMZ will not apply to Domain Controller.
• PCI DSS Requirement 1.2.2 – Router does not apply to Domain Controller.
• PCI DSS Requirement 1.3 – Public access to Domain Controller will not be applicable.
• PCI DSS Requirement 1.4 – Portable computing devices do not apply to the Domain Controller.

Per PCI DSS requirement 2, the hardening of DCs will be in scope to ensure they are not compromised. It has only been determined that the following requirements are potentially not applicable;

• PCI DSS Requirement 2.1.1 – Wireless will not apply to Domain Controller.
• PCI DSS Requirement 2.6 – Shared Hosting should not apply to Domain Controller.

Per PCI DSS requirement 2.2, the configuration standards must be in place for all system components, including the Domain Controller. Industry-accepted system strengthening standards exist and should be used to help meet this requirement.

PCI DSS requirement 3 will not apply, as Domain Controllers on out-of-scope systems will not store CHD.

PCI DSS requirement 4 will not apply, as the CHD’s transmission will not touch the Domain Controller.

Because the Domain Controller is considered to be widely affected by malware and therefore the anti-virus will need to be installed, the only requirement that cannot be implemented in PCI DSS requirement 5 would be 5.1.2.

Under PCI DSS Requirement 6, only PCI DSS requirements 6.1, 6.2, and 6.4 will likely apply for in-scope Domain Controllers.

All PCI DSS requirement 7 items are likely in scope for out-of-scope Domain Controllers.

All PCI DSS requirement 8 clauses are likely to be in scope for out-of-scope Domain Controllers. Most of the requirements will be covered by settings configured within the Active Directory domain to be copied to Domain Controllers. Therefore, it is already covered by the entire PCI DSS program.

Only requirements from PCI DSS requirement 9.1 through PCI DSS requirement 9.4 (inclusive) will be included in the scope of PCI DSS assessment activities. PCI DSS requirements 9.1 through 9.4 covers the physical location of the Domain Controllers physically located.

All PCI DSS requirement 10 clauses are likely to be in scope for out-of-scope Domain Controllers.

The only exception to all covered PCI DSS requirement 11 is PCI DSS requirement 11.2.2 for External ASV scanning.

PCI DSS requirement 11.1 will apply to out-of-scope Domain Controllers and their locations.

All of PCI DSS requirements 12 are expected to be in the scope of PCI DSS. PCI DSS requirement 12.3 should include some privileged accounts’ acceptable use and limit their use on certain devices.

While the above techniques can help organizations securely configure Microsoft Active Directory to support its use within a PCI DSS Cardholder Data Environment (CDE), organizations still need to be wary of shifting coverage to the out-of-scope environment.

The premise of determining whether a system component is covered depends on the risk the system has to the environment if it is compromised.

A QSA should review your specific environment to determine what coverage is, and only a PCI QSA can certify your coverage. Although the client is responsible for determining the environment’s scope, QSA will verify this during the assessment. This is a requirement in the Compliance Report (ROC) front section, so a QSA still needs to approve the scope.

The scenarios mentioned above are only one type of Microsoft Active Directory design and do not include multiple domains or multiple interconnected forests in a domain forest. Certain attacks against domain trusts should also be considered when using a Microsoft Active Directory forest with multiple Active Directory domains.

See Also: How to Reduce the PCI Scope for Easier Compliance

If the assessed organization is deploying a shared Active Directory, the specific concepts of hardening and secure design being followed must be adequately documented so that QSA can verify the secure design and review specific configuration settings before approving them as adequately segmented and secure.

I want to mention a particular point about segmentation testing and penetration testing. If a shared Active Directory is deployed, the scope of internal penetration testing and partitioning testing should include thorough testing of all out-of-scope system environments, including system components within.

The scope of segmentation and penetration testing should include domain-joined hosts, even if they are not determined as part of the PCI DSS Assessment. The purpose of penetration or segmentation tests is to see if PCI can take advantage of the host to compromise in-scope systems or connected system environments. Also, the organization must be fully documented in penetration testing methodology, which is a requirement under PCI DSS Requirement 11.3.