Review Posted Plus NAC
July's been a great month for controversy on this blog, so I thought I would continue that them by posting word of my Amazon.com review of Endpoint Security. Yes, I've been reading a lot, and it's been keeping me up past midnight for a few weeks. I've been intensely interested in these recent books, so staying up late has been worthwhile.Unfortunately, as you'll read in my three star review, you can skip Endpoint Security:
I really looked forward to reading Endpoint Security. I am involved in a NAC deployment, and I hoped this book could help. While the text does contain several statements that make sense (despite being blunt and confrontational), the underlying premise will not work. Furthermore, simply identifying and understanding the book's central argument is an exercise in frustration. Although Endpoint Security tends not to suffer any technical flaws, from conceptual and implementation points of view this book is disappointing.
I just finished this review, and it took a long time to write. Please read the review before commenting. I would like to mention one element of my review here, which contains a quote from Microsoft's article Planning for Network Access Quarantine Control:
On p 172 Microsoft says "Network Access Quarantine Control is not a security solution. It is designed to help prevent computers with unsafe configurations from connecting to a private network, not to protect a private network form malicious users who have obtained a valid set of credentials."
I've written about NAC several times for this blog, such as NAC Is Fighting the Last War. However, I find this Microsoft comment to be fairly realistic. Prior to that statement, quoted in Endpoint Security, Microsoft says this:
Because typical remote access connections only validate the credentials of a remote access user, a remote access client that connects to a private network can access network resources even if the configuration of the remote access client does not comply with corporate network policies. You can implement Network Access Quarantine Control to delay normal remote access to a private network until the configuration of the remote access client has been examined and validated by a client-side script.
The emphasis here is on configuration, i.e., compliance with policy, and not integrity of the endpoint. Compliance with policy != integrity or security (i.e., the state of not being compromised). NAC is incapable of validating the integrity of an endpoint. (There's the controversy for this post. Cue responses from NAC vendors.)
My point is that's ok, as long as your expectations are aligned with Microsoft's description of their capabilities. Now, it is possible for a compromised system to report that its configuration meets corporate policies while being under the control of a Romanian. I don't see the logic in trusting the endpoint to report its health, especially via a "client-side script." However, if your primary reason for deploying NAC is to get a better grip on configuration enforcement for endpoints, I think it has some merit -- it depends on the cost of the implementation and your goals for the process.
By the way, Wikipedia's entries for PID controller will help make sense of Endpoint Security's discussion of CLCP.
Comments
Imagine if your ISP refused to let your IIS server receive packets until it had asserted that it was secure against Code Red.
If it doesn't do that, it's probably vulnerable, and the patching process can commence.
If it is already compromised, well, it doesn't matter.
So the point of NAC isn't to (directly) protect other assets -- it's to protect the asset connecting with NAC.
I know biology metaphors are overused, but a school requiring polio vaccinations isn't just keeping out polio (although that's definitely a benefit) -- it's also making sure that any breakout doesn't hit everybody.
I'm still scared of how NAC will deal with Unix-like laptops, though.
NAC is a cool thing, but for every success story there are probably 10 other failures and backed-out stories.
NAC is to compliance/configuration control as IPS is to IDS. It's not for everyone. I think a lot of NAC purveyors are really looking for security and the ability to shunt rogue devices off into never-never-land or out of the trusted network. That's solving a small problem with a very complex solution, in my mind.
Kinda makes you wonder why it is called NAC/P (Network Access Control/Protection) when that's only a fallable side effect of the real activity...
However, considering the current threat landscape is typically generic infected machines with spray and pray worm infection vectors, how can you believe that a correctly implemented client based NAC solution does not significantly raise the bar for malware?
W32.Imautorun is a worm that copies itself to all drives and downloads potentially malicious files on to the compromised computer.
W32.Bratsters is a worm that copies itself to all drives and downloads potentially malicious files on to the compromised computer.
W32.Phoney.A is a worm that spreads through mapped drives. It also lowers security settings on the compromised computer.
W32.Himu.A@mm is a mass-mailing worm that also spreads through network drives and shared folders. The worm also attempts to disable security related applications and block access to certain Web sites.
[for the sake of argument I've taken out 2 trojans from this top 5 list - also McAfee shows a similar list to this]
So, you've correctly implemented a client based NAC solution. None of these have NAC evading capabilities. You have successfully prevented a machine without current AV defs (and installed AV software) from connecting to your network. Thus, you have prevented a machine infected by any one of these from spraying itself all over your fileservers.
Of course it is an arms race. Of course this depends on other security layers, like AV. However saying NAC is pointless because there is a possibility of workaround is the same as saying wall safes are useless because some thieves can break into them.
Now if you want to argue NAC cost analysis and the reality of deploying full blown NAC solutions to a non greenfields corporate environment you might have more success. Arguing technically just shows a lack of understanding of the problem NAC solutions are trying to solve.
Before I address your point, why don't you name yourself and the NAC vendor who employs you?