Windows Vulnerabilities - 92% mitigated by not being administrator

I'm going to step aside from my normal patching discussions and talk about what happens when you do get attacked with malware that exploits a vulnerability. When a nasty program exploits an unpatched vulnerability, there are always mitigating factors that can help limit the impact. One of the big ones is that the exploit usually runs in the security context of the account which it attacks/is run against. Security vendor BeyondTrust looked at the 154 Microsoft vulnerabilities published in 2008. They found that 92% of all vulnerabilities had their impact mitigated or were rendered completely harmless when the user was running with no elevated privilege (normal user rights). Obviously this is a report from a security vendor selling software that helps manage user rights... but the breakdown for 2008 is striking, indicating that running as non-administrator at least mitigates:

• 94% of Microsoft Office vulnerabilities reported in 2008
• 89% of Internet Explorer vulnerabilities reported in 2008
• 53% of Microsoft Windows vulnerabilities reported in 2008

That makes sense when you realize that the first two categories are just applications. They're very specialized, widespread and extensible applications, hence the risk. Ultimately, however, they're running at the user's privilege level. Even though the OS itself is somewhat less protected-- many of the juicier exploits will run at the System context or elevate privileges-- 53% mitigation is still pretty good.

Here's my beef with Microsoft in this regard. We all know that running in the least level of privilege is the safest and these numbers add good ammunition to that argument. While Microsoft has made great strides in allowing the user to elevate their privilege on some actions in the "XP era" and later, getting the ability to universally change security context on the fly eludes them. *nix with sudo and the standard GUI security elevation method of OS X both have serious problems, but they're a lot closer to right. Windows 7 will certainly continue the slow progress in this area, but at some point Microsoft ought to do better.

Security Basics: Authentication and Authorization

A key pair of linked concepts, Authentication and Authorization are so fundamentally important to networked computing, yet often ignored as "assumed knowledge." The fact is that most networked operating systems handle Authentication and Authorization pretty well if configured properly, but I want to cover the basics in case there are any problems. Pay attention, there will be a quiz later!

Authentication is a process by which you prove that you are who you say you are. The most common form of authentication is a user password. In this case, you provide some piece of information only you and the computer know. If you have that info, you are (as far as the computer is concerned) who you say you are.

You have probably also seen biometric authentication systems like fingerprint scanners, and some of you may have seen Handheld Authenticators like the RSA/SecurID system. In the first example of biometric data, something you know is replaced by something you have-- and in the case of your finger, something hopefully you and only you have.

Two-factor authentication builds on the previous two concepts. You need something you have plus something you know. You the basic form at an ATM machine. To make it give you money, you need your PIN code and your card. A thief would need both rather than an either-or to get access to your account. From an administrative standpoint, you may need to consider something like a SmartCard system or an RSA/SecurID system. For SecurID, you have a physical token/device (key fob usually) that generates one use-codes. You combine these one-use codes from the authentication device with a PIN number only you know. Instead of a password, you now have not only a two-factor password, but a one-time two-factor password!

The most common way for this to break down would be to share passwords or use shared accounts (accounts that aren't meant to be tied to a specific person and more than one person has the password.) For authentication to be reliable and secure, you must not have any situations where one person knows another person's password! If you just can't resolve this, realize that it's an insecure situation and work to mitigate the risk.

Authorization is the other half of this coin. Once a system can reliably tell that you are who you say that you are, now the system can give you permission to do what you should be able to do-- this is often revered to as user privilege or privs in admin-speak.

As an admin, you'll typically work within the specifics of your networked OS/system to grant and modify user privilege as required by your organization. Users should operate under the concept of least privilege. That is to say, that they should have the rights to do what they need to do, and not more than that. Granting them extra permissions is a risk that the users may engage in dangerous activities (installing spyware, snooping through HR payroll databases, etc.)

Your risk here is threefold:

• You need a strong authentication system to ensure that you know who is logging in to your systems.
• You need to be vigilant in that the IT group is setting up permissions properly, without any loopholes and obeying the principle of least privilege.
  
• You need to guard against outside threats which will use exploits in the system to elevate their privilege beyond what they should have.

As you can see, these two concepts are tightly linked and important building blocks for all security concepts.