Quantum Security

The May 2008 issue of TechNet Magazine is out. It has an article in it that I have been wanting to write for a long time, called Quantum Security. In it I posit the argument that there are some fundamental laws of security, similar to the laws of physics, which we must not ignore in our risk management practices. I also got to include a revised version of the age-old Annualized Loss Expectancy (ALE) equation. Anyone who has taken the CISSP exam should be familiar with ALE. I believe the equation in common use is outdated and fails to account for the modifications we make to systems when we apply security to them. To properly address risk we need an updated version of the ALE. The article includes the rationale.

 The article is available online, but I think the print version looks a lot nicer. Let me know what you think about it.

How to remove the security warning, or should you?

This morning there was an interesting question in the Windows Vista Security Newsgroup. The poster had written an application that users were downloading. However, when they ran the application they received a warning dialog, like this one:

The poster wanted to remove this warning dialog to avoid confusing users.

This dialog is created because Internet Explorer, and some other applications, add a bit to the file to mark it as being downloaded from the Internet. It serves as a warning that this may be untrusted content. If the file is digitally signed, the warning does not have the red shield, and the publisher is listed in the dialog, but otherwise it stays the same. The poster asked if getting a digital certificate and signing the executable would get rid of the warning. It will not. This warning is there to warn the user. I think it is an important safety mechanism, and that, rather than trying to remove the warning, which is possible, we should help the user understand it. Therefore, here is my response:

You should definitely digitally sign the application no matter what. However, that will not remove the warning. It just will have your (or your company's) name in the dialog and won't say "Unknown Publisher."

Technically, there is a way to get rid of this warning, but it is there as a warning to end users. If you remove it here, you would also remove it for all other executables. That would put your users at significant risk. If you programmatically remove that warning, you would be responsible for putting them at significant risk; a responsibility that I am pretty sure you do not want to accept.

Rather, I would suggest that you take the opportunity to educate your users. Teach them that the warning is there so that they can assess whether they want to accept the risk involved in opening applications off the Internet. In this case, you have digitally signed the application so they can trace it to you and have assurance that they are, in fact, opening a trusted application. Anytime they get a dialog like this they should evaluate it and see if they really want to accept that risk or not. If the publisher is unknown, they have no way to tell who wrote the application, and should consider it a higher risk.

Today’s forecast for O’Hare: Lots of Vulnerable Computers

Olliver Sommer, a German Small Business Server MVP, flew home from the Microsoft MVP Summit via O'Hare Airport in Chicago. While there, he spotted this wonderful piece of advice for how to configure your computer to use the airport wireless network.

The document is meant well, but lacks a bit in the execution. It recommends that you disable exceptions in Windows Firewall because doing so stops attacks through Windows Messenger while on the wireless network. Of course, you would only get attacked through Messenger if you actually accept unsolicited requests from people.

The document then goes on to show how to disable the exceptions. It even has a screenshot; which would work far better if the screenshot showed the exceptions disabled. Instead, the screenshot shows the firewall turned off entirely. One has to wonder how many people followed the advice in the picture as opposed to the text.

Then comes the piece de resistance. The document recommends you disable Simple File Sharing. Not only does this presume that you are using Windows XP Pro, as Windows XP Home does not permit you to turn off Simple File Sharing. Simple File Sharing, as it turns out, is partially a user interface feature that governs which sharing user interface you see. However, there is an internal feature as well. in fact, Simple File Sharing is essentially the Force Guest feature. If Force Guest is turned on all users connecting from the network connect as Guest. In other words, by disabling Force Guest, you would enable remote users to connect using as an authenticated user, potentially even an administrator. Force Guest ensures that the only thing a remote user can do is read, and write if you have permitted that, the files you have made available to network users. Turn off Force Guest and a user that guesses the password of your administrative account can take over your computer.

In other words, the guidance that O'Hare Airport is publishing has you disable the firewall and enable traditional file sharing so anyone can start guessing passwords against your computer. One wonders if this is perchance some new Transportation Security Administration (TSA) inspection scheme to investigate what is on your laptop?

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:

  1. 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.
  2. 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.
  3. Explaining to people that you are a security "expert" apparently does not stop them from asking you questions about SharePoint.
  4. 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)
  5. 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.
  6. 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.