In part 2 we discussed the criticality of a risk assessment and started on implementing the framework with fixing monitoring and alerting so that we can properly manage the risk we will be accepting. In this part I will deal with Category 2 and 3 systems and how to manage their risk.
One of the big problems I have with the security purists is with their arguments over Category 3 systems. Do not get me wrong, I understand their reasons for their statements. However to me, their arguments seem to imply that Category 3 systems are somehow not secure or not as secure as other systems and therefore cannot be trusted. This further implies that organizations are implementing some sort of multi-tier security structure which should not be the case. Taking such an approach would create an operational and support nightmare, let alone increase the risk of compromise.
In today’s world, all devices need to have a certain basic level of security comprised of, at a minimum, hardened OS, minimized ports and services, access control, anti-virus and anti-malware (as appropriate and necessary), personal firewall (if mobile), logging and other similar security measures as necessary. All of this is something I like to refer to as “Security 101”. If you are not doing Security 101 across the board, then you likely have bigger issues than just PCI compliance. But if you are following a Security 101 approach, then all of your devices under your direct control should have a solid, basic level of security and should be able to be trusted when on your network. As a result, with the proper logical access controls in place, you should be able to trust Category 3 systems coexisting with certain Category 2 systems.
Notice I said “certain Category 2 systems” not “all” Category 2 systems.
Category 2b systems that have inbound connectivity to the CDE are the most risky because of that direct inbound connectivity. As such, should any Category 2b system become compromised, the CDE is also compromised by default. Most Category 2b systems are gateways to the CDE such as with out-of-band management systems or “jump boxes” for network and system administration and Citrix or other virtual desktop technologies that you can use to grant business user access to CDE applications.
These gateways need to be configured such that if they become compromised they are immediately taken out of service until they can be rebuilt and/or reconfigured as secure. This is typically accomplished not just with anti-virus, but also through file integrity monitoring, application whitelisting and other similar measures. But this needs to be monitored at the virtual desktop infrastructure level (aka, Citrix, VMware, Terminal Services, etc. servers), as well as the virtual desktop image level. If a file changes in the virtual environment or virtual desktop image that should not have changed, access to the virtual desktop environment is suspended until the infrastructure or image can be recertified as secure. But that means very tight monitoring on the critical files, however this should be relatively easy to do as long as the virtual desktop image is restricted to only a single cardholder data (CHD) application.
The other thing that needs to happen with virtual desktop is that organizations must be extremely diligent about who has access to the virtual desktop. This means very timely user management, something a lot of organizations are very lax about. The PCI DSS states in requirement 8.1.4 that organizations must “Remove/disable inactive user accounts at least every 90 days.” 90 days is a very long time when you look at what attackers are able to do in such a timeframe. As a result, organizations need to step up their game in this regard and when someone’s job function changes, that needs to have a help desk ticket generated for changing that person’s access. A 90 day review process is fine, but if you are relying on that sort of thing as a control, you are not being diligent enough in managing your users.
But what about Category 2a systems you might ask? Category 2a systems are directory servers, authentication servers, DNS and DHCP servers, anti-virus master servers, system update servers and other network and system management/monitoring support systems. These systems are those that only system or network administrators should ever have direct access. These systems should be configured as “bastion” servers, security hardened so that they are not easily compromised by vulnerabilities. Most vendors of these systems understand this and have set up their installation routines accordingly – restricting services, allowing only necessary applications, etc. The bottom line with Category 2a systems is that, if any of them become compromised, it is game over because the attacker has the privileges of an administrator.
I am not a fan of separate directory systems. These systems double as the access control management system and the more complicated access control becomes, the more likely that access control becomes less reliable and secure. As such, I prefer a common access control system managed through an integrated directory system such as Microsoft’s Active Directory (AD). Over the years, the amount of ports required to make AD work between domain controllers have gotten much better and easier to implement. Plus there is an ability starting with Windows Server 2008 to even limit and control the dynamic ports used. As such, I recommend using a common domain approach rather than separate domains with trust relationships as it just makes management so much easier and more reliable. Whether or not you choose to put domain controllers inside your CDE is up to you to decide.
However, there is a larger consideration here that needs to be put on the table. Think about what the security purists are saying with their statements about Category 3 systems. If an attacker can jump from a Category 3 system to owning a Category 2a system such as a directory server, DNS server, DHCP server, etc. what does that say about an organization’s security posture to begin with? If an attacker gains control of a system/network administrator’s credentials, it is game over. That is not a device failure issue, that is a social engineering failure. As a result, you can have whatever controls of separation all you want, but in the end if an administrator gets owed, what did all of that separation do for you? Nothing. The best we can do is to manage and mitigate the risks and monitor for any attempts to leverage those risks and deal with any attacks as quickly as possible.
At the end of the day, organizations need to assess the risk that their Category 2 systems provide to the CDE. If it is higher than desired, those systems need to be put into the CDE. Others can share networks with other Category 2 and 3 systems if necessary.
There are obviously enhancements that you can make to further improve on this strategy. But this is just what I would consider the minimum to get by which seems to be what a lot of you desire.
PCI Guru 
Just to be clear about one thing in Cat 2…..whereas everything on the same “subnet/segment” as a CDE system is part of the CDE, everything on the same subnet/segment as a Cat 2 system is NOT necessarily also Cat 2, correct? So far the few entities I have looked at have just lumped all systems on the same subnet as another Cat 2 system, as all Cat 2. This has made for some simplified pictures and has not caused difficulty, so far. But I guess it could cause extra work in some cases and the entity should be aware that there may be an opportunity to consider some of these systems as Cat 3. True?
I get what you are saying, but if a system resides in a Category 2 subnet it should be treated as Category 2 regardless. If an organization desires the system to be out of scope then it should be in a Category 3 subnet.