The Sys-Security Group

During the weekend I have read several articles that I had interest in from a number of security magazines / online publications.

What I have found is that most of the reporters that wrote these articles simply do not have the experience to know when they are being fed with FUD.
There is a big difference between on paper to the real world of deployment in the field. Some technologies which look great simply cannot scale or do not work as expected in the real world.

The problem is with the experience of the reporter that writes about the technology. The experience is not always there (there are exceptions of course) and therefore the FUD is spade.

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.

So it seems Apple will be releasing a new version of its iPhone now with a 3G capability sometime next year.

The information was confirmed (leaked?) by no other then AT&T’s CEO Randall Stephenson.

One of the interesting things to watch will be the battery lifetime when the iPhone will have 3G capabilities.

From my own experience I can tell that when you use WiFi the battery drains fast (ok not fast as with playing Video).