16
Nov
18

Shared Services (aka Category 2 In Scope)

All of us on the PCI Dream Team get the following question a lot as we consult with organizations on PCI scoping and network segmentation.

“With the guidance from the SSC at the Community Meeting regarding network isolation (they provided a slide that highlighted key concepts) we are expecting QSAs to dig deep into category 2 systems.  PCI controls are not applied to servers that support infrastructure outside of the CDE on these category 2 systems.  Is the council really suggesting we setup completely dedicated category 2 infrastructure for the CDE?”

For those readers that have forgotten what the PCI scoping categories are here is a quick refresher.

Category 1 systems are those that either: (a) directly process, store or transmit sensitive authentication data (SAD) or cardholder data (CHD), or (b) are on a network segment the same as or directly assessible to those systems that directly process, store or transmit SAD/CHD.  Category 1 systems are those that exist in or create the cardholder data environment (CDE) and are always in scope for PCI compliance.

Category 2 systems are those 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, etc. and are segmented from and have controlled access from/to those Category 1 systems through a firewall and/or jump box.  Category 2 is typically referred to as “Shared Services”, that is, services that are shared between Category 1, Category2 and Category 3 systems.

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

The bottom line though is that Category 2 systems are always in scope for PCI compliance because they can affect the security and controls of the CDE.

Category 3 systems are those that do not and never can access Category 1 systems in any way including via a jump box.  Only Category 3 systems are out of scope for PCI compliance. .  That said, Category 3 systems can be provided services by Category 2 systems and still be considered out of scope for PCI compliance.

The first part of the question I would like to address is:

“PCI controls are not applied to servers that support infrastructure outside of the CDE on these category 2 systems.”

Category 1 and Category 2 systems are deemed in scope for PCI compliance, so ALL relevant PCI controls are required to be applied to those devices.  With Category 2 systems, there may be a very, very few controls that do not apply, but they will be very, very few if there are any at all.  So, if you are not applying all PCI controls to Category 2 systems you are likely not in PCI compliance.

The next part of the question I would like to address is:

“… we are expecting QSAs to dig deep into category 2 systems.”

QSAs better be assessing Category 2 systems just as rigorously as Category 1 because they are, by definition, in scope for PCI compliance and no different from Category 1 systems.

Finally, there is this question.

“Is the council really suggesting we setup completely dedicated category 2 infrastructure for the CDE?”

If that is how you wish to approach the problem, that is your prerogative.

However, the QSAs I know would tell you to avoid that approach.  That approach only adds complexity, introduces even more chances for human error and usually creates ever more bizarre controls and nonsense that does nothing to improve security.

That is not to say that I have not encountered instances where directory services, DNS, DHCP and other services servers are located inside an organization’s CDE.  But they are connected to other services servers within the organization in Shared Services no different than any others to simplify management of those services.  They are only inside the CDE because of performance or availability issues, not for security reasons.

This is the whole point of Category 2 is to provide an area where such services can be located to serve all categories of systems.  Hence the name “Shared Services” because the services are shared between all of the categories.

That said, it is not unusual to have multiple shared services areas.  I have clients that isolate their directory, DNS and DHCP servers in their own shared services environment.  The SIEM is also isolated in its own area.  The reason is to allow for further granularity of monitoring and control as well as limiting the number of administrative personnel that have access.  They also have shared service areas for internal FTP and mainframe LPARs.  How many shared services network segments your organization will need is all up to your organization and what makes sense.  The bottom line though is to make sure you can monitor and control the shared devices and ensure that you are not putting CDE systems at risk.


2 Responses to “Shared Services (aka Category 2 In Scope)”


  1. 1 Wayne Murphy
    November 16, 2018 at 3:49 AM

    One of my frustrations with the PCI SSC released Scoping and Network Segmentation guidance is the reference to ‘directory services’ in Cat 2. Yes, the likes of LDAP, TACACS and Radius type directory services are ok, however when we are talking about Microsoft Active Directory as a shared service the network segmentation breaks as the risk associated with compromising an Active Directory domain joined machine in CAT 3 is huge since this will most definitely result in a compromise of the entire Active Directory infrastructure and thus the CDE. I think this should have been made clearer within the document.

    • November 16, 2018 at 6:57 AM

      I would agree with you if we were talking versions of Active Directory (AD) prior to Windows Server 2008 R2, but domain controllers from then on are hardened and have only gotten more secure with each new release. The problem with AD comes from their implementations. In order to support some “antique” solution, they are required to support authentication protocols that put that very well hardened domain at risk. This is where the other controls in the PCI DSS come into play by monitoring the domain controllers as well as setting them away from all other systems so that they can be more closely monitored and controlled. Is that a perfect solution? No. But in our Microsoft-centric world, it is the best that you can do other than go against the tide and implement a different directory solution.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s


Announcements

If you are posting a comment, be patient, as the comments will not be published until they are approved.

If your organization has a PCI opportunity, is in need of assistance with a PCI issue or if you would like the PCI Guru to speak at your meeting, you can contact the PCI Guru at pciguru AT gmail DOT com.

I do allow vendors to post potential solutions in response to issues that I bring up in posts. However, the PCI Guru does not endorse any specific products, so "Caveat Emptor" - let the buyer beware. Also, if I feel that the response is too "sales-ee", I reserve the right to edit or not even authorize the response.

Calendar

November 2018
M T W T F S S
 1234
567891011
12131415161718
19202122232425
2627282930  

Enter your email address to subscribe to the PCI Guru blog and receive notifications of new posts by email.

Join 2,303 other followers


%d bloggers like this: