What I Learned from Attending the Windows Launch Event Today
Today I attended the Microsoft 2008 server wave launch event in Seattle. In the process I learned a number of things:
-
The launch event apparently does not need to coincide with actually launching anything. Server 2008 launched a couple of months ago. Visual Studio 2008 launched in November 2007, and SQL Server 2008, the third part of the tri-fecta that comprised the launch, will not actually launch until the third quarter this year.
-
The primary purpose of launch events is apparently to get free junk, and in some cases, other stuff, from a collection of vendors you have never heard of and don't care about. I hung out in the "Ask the Experts" booth for a while, with fellow MVP Alun Jones. I think we answered more questions about "so, what free stuff do you give away" or "would you like to scan my badge for your drawing" than we did on any other topic. We did not actually have any drawing, nor any free stuff to give away other than actual knowledge, or at least, opinions. We answered precious few security questions.
-
Explaining to people that you are a security "expert" apparently does not stop them from asking you questions about SharePoint.
-
What the one sausage said to the other sausage in the frying pan (yeah, it was bad, and it is not really worth the bits to relay it)
-
Windows Firewall with Advanced Security stops malware from spreading on your network. Yes, that's right. I went to the security presentation and, apparently, in conjunction with System Center, Windows Firewall will somehow cause malware to ask for permission before sending your credit card to Russia and your bank account to China. Had I not known already that no host-based firewall can stop malware running on a computer from sending anything to anyone I might actually have been convinced by this claim. As it were, I was just kind of appalled that Microsoft now officially makes the same ludicrous and impossible claims that the security vendors do.
-
Network Access Protection (NAP) provides "Secure Access Control" to your network. Apparently it does this by giving your computer a bogus IP address. This means that the domain admin that logs on to a workstation cannot disable the built-in firewall. Yes, that is correct, during the demo, the presenter actually logged on to a Vista client using a domain admin account (bad), and then claimed that NAP can stop the locally logged on user from doing whatever that user possibly pleases to do (untrue).
At that point, I decided I had had enough marketing shill for one day. The event was interesting, and I think most of the attendees got some value out of it in that they learned a little about some new features. however, the NAP issue deserves some additional commentary.
In case you did not know, NAP is a policy compliance feature in Windows Server 2008. It will ask well-meaning clients to provide their state of health before they get to communicate on the network. It can use three different "enforcement" mechanisms. One is DHCP based. The client simply does not get a proper lease. One is IPsec based - the client does not get the proper material to negotiate IPsec security associations. And the third is 802.1x-based - the switch won't open the port to the correct network until the client is considered good.
As you can probably tell, the DHCP based "enforcement" is extremely weak. The user on the client, or some piece of malware, can simply configure a valid IP address and go to town on the network. 802.1x can be easily defeated by installing a hub in front of the switch, letting a legitimate client open the switch port, and then stealing the port by setting your MAC address on a rogue host on the same hub to the same address as the legitimate client. The IPsec enforcement is considerably more difficult to circumvent, but you can still do it by making the NAP client lie.
The short story then, is that NAP still relies on the client to tell the Network Policy Server (NPS) what its state is. If the client lies, the NPS server has no way to know the difference, and will trust it. I actually helped design NAP, years ago, and this was a weakness we were very aware of then, but saw no way around. Yet, NAP is still valuable. It is a great technology to ensure that compliant clients stay compliant; that non-malilcious clients have all the necessary policies deployed, the right patches installed, the correct anti-malware software running and updated, and so on. Every network security administrator should definitely spend some time with NAP and consider whether it could provide another valuable tool in their arsenal.
However, NAP does NOT provide "Secure Access Control" to the network. It does not do so because it cannot provide true security. It cannot prevent malicious clients from getting on the network. Unless it is used with IPsec enforcement, in conjunction with Server and/or Domain Isolation, it also cannot prevent a malicious client from communicating with any other computer on the network. None of that makes it useless, nor does it mean that it is not a security technology. Policy enforcement, even when only on clients that choose to comply, is still a security concern, and a valid objective. Keeping managed clients managed is important. However, it is also really important that we understand the limitations of the technologies we are using, which is why I wrote this post.
