The Sys-Security Group

Tim Green is at it again targeting NAC and virtualization. I believe that he could have written about some more issues with NAC and virtualization that most NAC vendors are suffering from.

Specifically, what happens when you have a virtualized environment on a Server that might host multiple guest operating systems?

What is wrong with this scenario? Let’s take those NAC vendors that use the underlying switch infrastructure to place an element into quarantine VLAN until it’s posture is validated. Quarantine VLAN is a per port per device ‘technology’ meaning that is cannot be used for virtualization since it re-assigns the switch port’s VLAN ID to that of the quarantine VLAN. By doing this all the elements (virtual elements) using that switch port for their connectivity will also be assigned to that VLAN (meaning no communications for all).

Others may claim that the internal communications between the hosts is the problem. I disagree. I think that if the virtualization server’s administrator is installing another guest machine she is not doing that to break into the organization. It may be an unauthorized install, but not for malicious intents. The guest machine must be disallowed network access so communication with other systems on the network would not be possible (until either the guest machine is authorized and/or its posture is validated).

This brings me back mentioning that NAC solutions must first take care of rogue devices and network access (S-E-C-U-R-I-T-Y) and only then with compliance.

I have been speaking about this for some time now - a NAC solution that relies on agents is a solution, which would be bound to fail in deployment. The problem is more emphasized on large-scale deployments.

I can count several reasons like the problem of identifying all the elements that the agent needs to be installed on (organizations do not know what they have on the network as is. …And most of the NAC vendors do not know that to…), the NAC agent is one among many other agents that may already be installed on the element, a performance impact that may result from the agent, management overhead, and the fact that the agent is a target for a security breach.

Seems like I am not alone talking against the NAC agent approach. Tim Green of Network World published in his newsletter an article about issues with NAC agents.

NAC must scale. The deployment must include all sites, and not just a certain portion of the environment. If dependent on an appliance and/or on the switching fabric, it is bound to fail (time-to-value, effort and money).

Any NAC deployment must cover the entire environment, so other venues accessing the network would not be possible.

One good example is with guest access. Enforcing guest access on specific locations, such as meeting rooms, etc. would fail once the guest will connect to those unprotected locations.

As one that had worked for and consulted to a few large financial institutions I was surprised to learn that many people do not know what are the challenges that NAC solutions face at financial institutions.

Financial institutions are notoriously known for the strict roles they impose over changes to their infrastructure (external and internal). Usually, when a change is needed, a series of signatures are required to authorize the change, which could only be performed in a designated window of time (usually once a week on Sunday). If the change cannot be performed, or caused another problem, a role-back is performed, and the change is pushed back to the next week (if at all).

During some periods of time in the year a change freeze is in effect. No changes to the infrastructure are allowed. This is usually done between November – January, which represents the high season for shopping, etc.

So what are the barriers for NAC vendors? Just think about NAC solutions that use the Quarantine VLAN method to isolate devices, dynamically assigning VLAN IDs to switch ports, etc. As one can understand, a definitely no-no in a controlled environment.

Actually, any read-write access, which is required to the infrastructure switches would not be allowed.

Another interesting affect is the use of software-based agents, where most of the financial institutions would not be that happy to install (along a long list of other client-based software that they may already have on the desktop).

Recently we read about some NAC product comparisons performed by various magazines. The one thing that I find the most interesting is the test criteria and the parameters, which are being used in order to perform the comparisons and tests.

For example, one magazine just checked that NAC solutions can perform user authentication against Microsoft Active Directory, and Radius servers, and that they are able to provide with host-based checks and remediation.

What was the testing environment? One new Cisco switch capable of doing 802.1x, 2x VLANs were defined, about five managed Windows XP SP2 machines were used and a patch management server.

What is wrong with this picture? Well, first of all this cannot mimic a true network setup. And in a true network setup there are a lot of parameters you must include in the equation when you enroll a NAC solution. The second issue I find is even more problematic. The parameters, which were used to test the NAC solution, are simply, in my mind, the wrong parameters to check for.

I have written about this in the past when I have discussed parameters to add to a NAC RFI/RFP. Where is the check for proper element detection? Where are the questions in regards to how Quarantine is being done? Or how enforcement is performed? Three simple questions that opens a Pandora box.

If I were you, I would do my home work and verify that a comparison NAC test I read about was done in an appropriate manner, and that the parameters and tests it went through makes sense for NAC…