Nac Talk

Cisco has recently announced availability of dissolving Network Access Control agents as part of their NAC appliance using ActiveX and Java. At first blush, this sounds great for IT and security teams looking to provide an effective agent for guest devices, or other systems where a persistent agent isn’t desirable.

It meets the objective of enabling IT to deploy an agent on devices without requiring a full-blown install, and with the capacity to remove the agent at the end of the NAC connection cycle. So what’s the problem?

It’s a serious headache to deploy this way both for users and IT.
ActiveX obviously requires Internet Explorer to be running, and it ActiveX must be enabled. Now, the obvious issue is that if you have users who want to use Firefox, Opera, or other browsers, this is a user annoyance. Plus, some users and enterprises disable ActiveX. Instant support hassle for a measurable subset of users who now have to enable it (possibly in violation of a policy at their company network).

Then there’s Java. Good solution for Mac OS X users, not so hot for Windows, since Microsoft doesn’t bundle it. Windows users now have to install it to then be able to run the agent, making the “simple” install for Windows impractical.

Now IT has to choose; ActiveX for Windows AND/OR Java? If one is deployed, some group of users will face complex installation and a high level of inconvenience. If both are deployed, IT must now support multiple use case, and users may have to decode which agent is right for them.

How to get around this? Lockdown created a self-dissolving executable. It’s no bigger to download than an ActiveX or Java agent, requires only one click to install and removes itself at the end of the NAC session.

Chris Hoff writes in his article How The Hypervisor is Death by a Thousand Cuts to the IPS/NAC Community that virtualization in the data center is a severe problem for network access control. While it is correct that an IPS-based NAC product might not be able to detect traffic between the VMs, this whole issue seems off base. It doesn’t impact Lockdown directly in that we aren’t IPS based, but still, as a NAC vendor, it seems worth addressing the fact that this article seems to miss the mark.

Why? For the simple reason that if you are worried about the compliance of your servers, and you should be, you probably have a well defined process for maintaining them. Automated approaches like NAC may not make a lot of sense in the data center; would you seriously use NAC to determine if your server is running antivirus software with current signatures? Of all the devices on a network that should be carefully maintained and managed by IT, it’s the servers.

The second issue is that since end-users aren’t able to install software, launch malware infected websites or open emails on with viral payloads on enterprise servers, they aren’t really the target for technology like NAC.

The bottom line is that the right way to use NAC is to focus on endpoints around the network, managed and unmanaged, to ensure compliance and automate identity-based access. So while it’s an interesting theoretical discussion about IPS and virtualization, the premise that NAC is even involved in this particular discussion seems confusing to me…

Victor Garza and Matt Hines wrote an article today discussing that Vernier Networks, now Autonomic Networks, is dropping out of Network Access Control market to focus on role based access (sounds like I&AM to me).   Aside from the obvious bet that IBM will have something to say about their new name, what does this imply for the NAC market?  Matt and Victor claim consolidation.  

I say it’s about time.  Let’s face it; since NAC  was announced, it’s become a very noisy market.  When Lockdown announced our NAC product in early 2005, there were only a couple of vendors in the space.  By late 2006, I counted SIXTY companies claiming to offer NAC.  Offerings claiming to be NAC are based on a wide array of products including VA (which was our origin), I&AM offerings, infrastructure services, IDS and IPS, wireless security, etc.  

A few were full featured NAC, but the vast majority of these took an existing product and added one or two minor features to allow them to say they had “access control.”  The new feature tended to be something to knock a user or device into quarantine without addressing remediation or communication to the user, enforcing policy with extremely minimal security, very limited policy capabilities, etc. 

There’s certainly no definitive definition of NAC in the market, but abstracting the concept to be independent of product, the hallmark of a NAC solution that is a product not a feature is that it a) has extensive capabilities to discover environmental information about users, devices, and malware and b) it has a rich policy environment that can enable IT to take relevant and appropriate actions based on the environmental data, and c) that it facilitates or automates device remediation. 

If you really look at the products on the market claiming to be NAC, I would bet that fewer than ten really meet these criteria.  The rest simply make it harder for users to sort out the solutions which map best to their objectives and criteria.  Bolting on an agent that just checks for OS updates, AV and a few other things on top of a product that was designed to do something else is not enough to make a product NAC.  

So I hope Matt and Victor are right, and that the products (and maybe companies) where NAC is a feature, not a solution, move on to other pastures. 

Tim Green’s recent network access control article about OpenSEA and 802.1x supplicants makes a good argument for the value of having a broader selection of supplicants available to support the NAC process.  One aspect of deployment that he doesn’t discuss, though, is that there are many use-cases where a supplicant can’t be installed on a device.  When would that be an issue?   

At Lockdown Networks, we’ve seen many use-cases where a large number of systems that won’t, or can’t, run systems still must participate in a network.  Many unmanaged devices, like lab equipment, printers, embedded systems, have a problem with supplicants.  Or guest devices owned by parent companies that may not allow installation of  agents or other software, or for which the user doesn’t have credentials.   

So while it’s important to consider the role of 802.1x authentication in NAC, it’s also important to remember that there are many cases where the capacity to support some form of fallback to an alternate authentication method may be essential.  It wouldn’t be a very productive NAC deployment if all these devices without supplicants can’t particpate either in the NAC process, or are kept off the network. Lockdown chose to handle this by allowing fallback to a guest login page, and this has been a useful feature. It’s probably a good “check-list” item to ask vendors how they deal with missing suplicants.

’nuff said.   

It’s certainly been a challenging week in San Diego. The fires here have been unreal. The air is still smokey, even though the fires have moved about 40 miles to the East. Tonight the sunset is a dark, dull umber.

By now, you’ve undoubtedly seen the coverage. My family was nearly touched by this catastrophe; the fire stopped across the street from my daughter’s mom’s house. They are still missing their cat. But my daughter approached the uncertainty, as do all the people I’ve met this week, with a brave face and a hopeful heart.

One friend had horses that panicked and wouldn’t get in the trailer. He had to abandon them. The fire swept past their house, but stayed on the opposite side of the road, and the horses are OK.

The beauty of trying times, though, is watching the community come together. One of the more touching stories I came across was reading blog entries about the destruction of the San Pasqual Academy, a foster home and school for teens. Half their facilities were destroyed. The sense of family the children showed online really broke my heart. I plan to donate to help them recover.

http://www.sanpasqualacademy.org/

On the technology side, the reverse 911 system seemed to do a lot to make the evacuations which we and over half a million of our best friends went through smooth and easy. Minor traffic, no panic, time to get out of the way. Amazingly, the advanced reverse 911 system was just activiated last month.

The only glitch, if you use VOIP or a mobile phone and have no land line (like me), you have to register. Registration requires IE7. No Firefox, Opera, Safari, etc. Well, it’s early days I guess, but how hard can it be to create a form with 10 fields that’s cross-browser compatible.

There were other problems freeing up military aircraft for air support, etc, but frankly, on Sunday and Monday, it probably would have made very little difference.

We are all proud of the fantastic and heroic job the San Diego fire, police, and National Guard teams pulled off. Thanks, from our hearts!

Tim Green’s blog “It takes more than NAC to block malware” raises a few interesting issues. The first is whether or not the data is valid, which based on the methodology and sample size, is probably “no.” Dana Hendrickson in his NAC Survey Shocks the Industry does a nice job digging into the stats.
But there is a bigger question behind this, IMHO, than just the validity of vendor-sponsored surveys at events with self-selecting audiences.
It’s this: who actually believes NAC is the cure to all malware ills on the network? I don’t. And anyone who says it is the “solution” to network security is either on marketing steroids, or just self-delusional.
Why would I, as a NAC vendor, say this? Simple. I believe NAC is part of a mutli-tier security infrastructure, and that first and foremost, NAC is about automation of policy enforcement. This means that a) NAC must be extremely flexible in how it collects data used to make decisions, and b) that it must be able to take a broad array of actions in response to policy requirements.
The real issue is simple, there are too many types of data about the status and health of devices (and traffic) on the network (endpoint scanning, packet scanning, behavior analysis, etc) for anyone one device to fully support all this collection of data.
Some NAC products are better at detecting malware, but usually weaker at solving other problems on the network. Other products are better at protecting endpoints from attack by assessing their compliance. Either way, a customer should understand how these systems complement other systems on their network to provide a comprehensive multi-tier solution of which NAC delivers enforcement.
From the customer perspective, the real question ought not to be “will NAC get rid of all malware (or unauthorized users, or rogue devices, or whatever other worry is driving interest in NAC). Instead, the question should be “how will NAC complement and/or strengthen the infrastructure and security systems I already have in place.”

Mike Rothman makes an interesting observation in http://securityincite.com/TDI-2007-09-12#TSN3 where he questions why mid-size security companies spend the same per-employee as large companies. Mike thinks this could be a driving factor behind why midsize companies are behind the security curve, as big companies have a smaller “attack surface”.

It’s an interesting question, but I think it gets even more interesting, because when a big company spends the same as a small company on security, they’re actually probably putting a lot more firepower behind each $ per user due to purchasing scale. So $100/user in a small company maybe buys AV, a better VPN, and some NAC, while the same amount per user in a big company could throw in IPS and/or IDS, I&AM, and a few other goodies.

The conclusion one would draw is that midsize companies probably don’t just need to spend more, they need to spend a lot more.

The question is how big does that variance per user need to be?

Small and midsize companies also have some factors that may reduce their need for certain security programs. For example:

They may be subject to less regulatory baggage, like SOX, so when they deliver a program, it’s really focused on their objectives. This can have a big impact on how much fluff gets built into programs.
The smaller the company, the less likely it is to have highly distributed operations, or locations where hundreds of guests, vendors or contractors are on and off the network
They may not *need* some more advanced functions like I&AM

So while I agree that many midsize companies are not as mature or robust in their security implementations, maybe budget isn’t the first order issue. Perhaps is that they don’t feel the sense of urgency.

But then again, people seldom do, until they’ve been burned.

Ok, as goofy as things sometimes get in the highly competitive world of network security, and especially NAC, weíre wannabes in comparison to the consumer electronics market. Just look at the scenario created by Toshiba and Sony as they duke it out between Blue Ray and HD DVD. While they’ve saddled the market with two incompatible but mostly functionally equivalent formats, at least they both seemed on board with a great new HDMI spec, v. 1.3.

HDMI 1.3 sounds great! After all, it promises the ability to transmit deep color video, which will move the color-space bar from 16M colors to billions, covering over 160% of NTSC color spec. And, it allows uncompressed True HD and DTS-HD to be transmitted between the player and the surround processor.

So what could be bad?

Well, for starters, deep color may have value someday, but right now, DVD, Blu-ray and HD-DVD use 24-bit RGB in the mastering process, so the extra color data simply doesn’t exist. Perhaps some video codecs will someday add color interpolation, and maybe, just maybe, this would reduce the already minor banding artifacts we can see. Or perhaps a new consumer video product, like a camcorder, will support the deep color color space. But for now, there’s nada.

Well, at least there’s True HD and DTS-HD on discs, so that feature is usable, right? Nope. HD-DVD has two modes, Advanced and Basic. Basic allows the codec audio stream to go out over HDMI 1.3, but, and it’s a BIG BUT, nobody uses it. Everyone uses Advanced audio to allow on the fly audio mixing and other capabilities enabled by the HD DVD format. And guess what? Advanced mode audio doesn’t go out over HDMI, only the final PCM 24/96 audio stream.

Blu-Ray works with HDMI audio today, but only because they are behind on delivery of their equivalent of advanced mode audio. When they do deliver, itís dollars to donuts everyone will switch to the advanced mode.

The net is that this is a hugely hyped “feature” by receiver, TV and high-def DVD player makers, but it has no value except to promote upgrade sales.

Now you add this to Blu-ray vs. HD DVD format wars, or the notion of having to do bi-monthly firmware updates to your HD DVD player, and you get the following scenario playing out.

“Hey mom, heard you bought a high-def player?”

“Sure did, son. I decided to go with HD DVD because they bribed a couple of studios to do exclusive content, and because I really loved the idea of being able to update the firmware on the players as they play catch-up to deliver the features the promised but didn’t initially deliver. But that list of undelivered features was shorter than Blu-rays, and because I can update the firmware, I won’t have to replace my early-adopter hardware to get a production unit that actually delivers the spec. I think. And wow! The new player I got has HDMI 1.3, which I thought could drive the audio codec in my high-end receiver, but I guess I got that part wrong. Anyhow, since my house has no wired network, I decided to do a wireless network using a WDS topology, and setting up the remote transmitter as the relay, with bridging enabled to allow my player to pull updates wirelessly, so I donít have to burn my own ISO image to do the player firmware updates.”

Sure. My mom’ll have no problem with this.

And I thought NAC was confusing.