Microsoft has come a long way in improving the security of their products. Platforms like Windows XP with Service Pack 2 and Windows Server 2003 with Service Pack 1 are now “secure by default” when you perform a clean install of these operating systems (upgrades are generally only as secure as the security level of the pre-upgrade operating system). In Windows Server 2003, for example, IIS is not installed by default, Remote Desktop is disabled by default, and so on.
Trouble is, it’s not enough for the technology to be secured-those who use and administer these technologies must be secured also. Consider the role of the administrator of your network for example. The administrator’s account is all-powerful, so an administrator can pretty much do anything he wants on your network. That can lead to total disaster in several situations:
- If someone steals the password for an administrator account, your system is toast (if the account is a local one) or your domain is fried (if the account is a domain admin one).
- If someone penetrates your network and exploits an unpatched vulnerability to elevate their account to administrator level, you’re information assets are toast (or fried toast) once again.
- If you hire someone to be your administrator and you don’t properly screen their background, you may be putting your entire business in the hands of a criminal.
- If a formerly happy-go-lucky administrator for your company becomes disgruntled because he didn’t receive a raise, and he decides to get even, he may plant malicious software that runs under administrator credentials at a future time, quit and go on a long vacation far away, and then when the malware triggers your entire customer database gets wiped.
- If you hire someone to be an administrator and they don’t have proper technical qualifications and training, he might do something dumb while logged on with his administrator account-real dumb, like delete all the digital certificates used to identify employees in your company, or reformat C: drive on your domain controller, or browse a black hat website using an administrator account and thus download a worm that takes out your whole business for a day.
Toast (bad) or fried toast (really bad), either way you don’t want to find your business in this kind of situation. So you spend the bucks to get the latest and most secure-by-default versions of Microsoft Windows for both your desktop and server machines. Now your machines are secure, but how do you secure the administrators who operate them and who have the power of life (four nines reliability) and death (blue screen) over them? Two recently released security planning guides can be of help here, namely the Administrator Accounts Security Planning Guide and the Secure Access Using Smart Cards Planning Guide. Let’s look at some of their recommendations now.
The Administrator Accounts Security Planning Guide
This guide focuses on the importance of securing administrative-level accounts and how best to do this. Like all security guides it tends to annoy me a bit by being (a) too long and (b) too wordy (marketing people probably got their hands on it during the revision process) and (c) frequently state the obvious (like “Use a strong password” sheesh!) and (d) give a whole bunch of recommendations without really indicating which are critical always and which are necessary only in certain situations. On the other hand, this particular guide is only about 30 pages long so you can read it through in an hour and pick up a few good tips on how to keep your administrative accounts secure. But as I often mention in my blog ITreader.net, let me do the reading for you, so here’s my quick take on useful recommendations from this document.
First, the guide reminds us that the computers that administrators use must be kept secure. That means both the desktop machines in his office and also any laptop, tablet PC, PDA, or other mobile device she uses to manage machines on her network. Don’t forget those mobile devices-especially if they’re wireless! And secure doesn’t just mean locked down using Group Policy, it also means physically secure and completely trustworthy. You must be sure that the computer you are using for administering your network does not have a keystroke logger plugged into the back of it or screen scraping software installed on it or has been compromised in any other way, physically or otherwise.
Naturally, the guide also tells us that administrators should each have two accounts: a privileged (domain admin) one for administrative tasks, and a non-privileged (domain users) one for ordinary work (web browsing, email, writing reports, and so on). On any machine except a server, admins should only use their non-priv accounts for interactive logons and then use Runas to perform administrative tasks using admin creds. Well, I’d go even a step further and say that admins should never log on interactively to a desktop or mobile machine that they use for anything else than administrative tasks. Why? Security dependencies-the security of your network is like a chain where no computer is more secure than the least secure computer on your network. And each time you log on to another computer using a domain admin account, you weaken that that chain. Why? Because it increases the chances that you’ve logged on to a system that’s already been compromised, and if you log onto a compromised machine using an admin level account, you may as well clean out your desk because you’re network has been 0wn3d by the bad guys. Security dependencies is a complex subject and the best explanation I’ve seen to date is chapter 8 of Protect Your Windows Network by Steve Riley and Jesper Johannson, two security program managers at Microsoft. If you’re an enterprise administrator who works with Microsoft Windows platforms, I strongly suggest you buy a copy of this book and read it-especially chapter 8.
Next, the guide suggests that we rename or disable the built-in Administrator account for each domain/system. Which should we do? Rename or disable it? Like all good guides, it leaves it up to us to decide-thanks a lot. But it does warn us that if we plan on disabling the built-in Admin account you should first create at least one new admin level account so you’ll have a door to get back into your network or system! Plus it reminds us that the built-in Admin account is also the default Data Recovery Agent (DRA) for EFS and before you disable it you need to create a new DRA otherwise your encrypted data could one day become unrecoverable. Steve and Jesper also have some useful things to say about disabling the built-in Admin account in their book.
Finally, the guide suggests we separate the functions of enterprise (forest-wide) administrators and domain administrators. That’s a good idea, and another good reason for not using the built-in Admin account in the forest root domain since by default it belongs to both the Domain Admins and Enterprise Admins groups.
The guide also says some interesting things about using passprop (a Windows 2000 Server Resource Kit tool) for enabling account lockout for remote logons of administrator accounts; using MBSA to scan for weak passwords; and a few other topics. One suggestion I like is that in high-security environments you split the Enterprise Admin password into two halves and share it between two different people. This reduces the risk of a rogue admin damaging your network, though I suppose if one guy was bad he might offer enough money to the other guy to work as a team. If you’re using smart cards you can do the same thing by giving the smart card to one person and the PIN for that card to another person. This is probably done on nuclear submarines and such, but mom and pop’s e-flowers ordering shop probably don’t want to go quite that far.
The Secure Access Using Smart Cards Planning Guide
This guide intrigued me a bit more than the other one as it gives step-by-step (sort of) advice for implementing a secure smart card solution for securing two key aspects of enterprise network access: admin level accounts and remote VPN users. After a quick intro to the how and why of smart cards, the guide details the components you need to deploy and use to implement a smart card solution on a Windows Server-based network. These include a PKI (roll your own using Microsoft Certificate Services or outsource to a third-party CA), certificate templates, Group Policy, Internet and Authentication Service (IAS) for RADIUS authentication of remote VPN users, CMAK for deploying connections to mobile computers, smart cards and smart card readers, and so on. One useful suggestion is the creation of a number of new security groups for managing different aspects of the smart card lifecycle. These include groups for enrollment agents, staging, smart card users, temporary exceptions and permanent exceptions. And of course it’s good to remember to tell users not to use their PIN or car license numbers as the PIN for their card!
The guide then illustrates the process for implementing a smart card solution by working through a fictional scenario involving Woodgrove National Bank. I like the scenario-based approach but only if it complements a step-by-step tutorial, and unfortunately that’s missing here-no screenshots of how to configure a user account to use a smart card or where smart card Group Policy settings are found, only text descriptions to go by. I learn better with a few pictures I can latch onto.
On one point I wholly agree with the guide, and that’s the following: “The implementation of smart cards is not a one-time action, because the security certificates embedded on the cards require management and you must cope with situations in which administrators forget their smart cards, lose them, or have them stolen.” That’s true of any aspect of information security of course-the price of security is constant vigilance. But because smart card technology-especially for VPN users in a changing company environment-can be complex and challenging to manage, administrators need to really familiarize themselves fully with every aspect of smart card technologies and the Windows Server services that support them before they go ahead and roll them out across their enterprise.
And Microsoft has done just that-deployed smart cards for all domain admins in their company and for all users who need remote access to the corporate network (which is probably everybody in the company). And they use Microsoft Consulting Services and Premier Support to promote such solutions to partner companies and customers also, with good reason. You just can’t ignore the threats any more and expect to survive as a business. You need to make sure those admins who log on are really your admins, and those remote users who tunnel into your corporate network are really legitimate employees.
Still, I’d like to see Microsoft provide a much more detailed, step-by-step, configure-this-configure-that example of deploying a smart card solution than the one presented here, especially for VPN access.
