10 Immutable Laws of Security Administration

By Scott Culp

November 2000

We recently published the 10 Immutable Laws of Security, a listing of ten facts of life regarding computer security. We realized that administrators have their own set of immutable laws, one that's entirely separate from the list for users. So, we canvassed the network administrators, security gurus, and other folks here at Microsoft, and developed the list that follows, which encapsulates literally hundreds of years of hard-earned experience.

As in the case of the immutable laws for users, the laws on this list reflect the basic nature of security, rather than any product-specific issue. Don't look for a patch from a vendor, because these laws don't result from a technology flaw. Instead, use common sense and thorough planning to turn them to your advantage.

On This Page

Law #1: Nobody believes anything bad can happen to them, until it does
Law #2: Security only works if the secure way also happens to be the easy way
Law #3: If you don't keep up with security fixes, your network won't be yours for long
Law #4: It doesn't do much good to install security fixes on a computer that was never secured to begin with
Law #5: Eternal vigilance is the price of security
Law #6: There really is someone out there trying to guess your passwords
Law #7: The most secure network is a well-administered one
Law #8: The difficulty of defending a network is directly proportional to its complexity
Law #9: Security isn't about risk avoidance; it's about risk management
Law #10: Technology is not a panacea

Law #1: Nobody believes anything bad can happen to them, until it does

Many people are unwilling partners in computer security. This isn't because they're deliberately trying to endanger the network—they simply have a different agenda than you do. The reason your company has a network is because it lets your company conduct business, and your users are focused on your company's business rather than on the vagaries of computer security. Many users can't conceive why someone might ever go to the trouble of sending them a malicious email or trying to crack their password, but an attacker only needs to find one weak link in order to penetrate your network.

As a result, relying on voluntary measures to keep your network secure is likely to be a non-starter. You need the authority to mandate security on the network. Work with your company's management team to develop a security policy that spells out specifically what the value of the information on your network is, and what steps the company is willing to take to protect it. Then develop and implement security measures on the network that reflect this policy.

Law #2: Security only works if the secure way also happens to be the easy way

As we discussed in Law #1, you need the authority to mandate security on the network. However, the flip side is that if you turn the network into a police state, you're likely to face an uprising. If your security measures obstruct the business processes of your company, your users may flout them. Again, this isn't because they're malicious—it's because they have jobs to do. The result could be that the overall security of your network would actually be lower after you implemented more stringent policies.

There are three key things you can do to prevent your users from becoming hackers' unwitting accomplices.

• Make sure your company's security policy is reasonable, and strikes a balance between security and productivity. Security is important, but if your network is so secure that nobody can get any work done, you haven't really performed a service for your company.

• Look for ways to make your security processes have value to your users. For instance, if you have a security policy that calls for virus signatures to be updated once a week, don't expect your users to do the updates manually. Instead, consider using a "push" mechanism to do it automatically. Your users will like the idea of having up to date virus scanners, and the fact that they didn't have to do anything makes it doubly popular.

• In cases where you must impose a restrictive security measure, explain to your users why it's necessary. It's amazing what people will put up with when they know it's for a good cause.

Law #3: If you don't keep up with security fixes, your network won't be yours for long

It's a fact of life: software contains bugs. Some of these bugs involve security, and there's a huge number of disreputable people actively searching for them in the hope of using them against you. No matter how secure your network is today, it could all change overnight if a particularly serious vulnerability is discovered. It could even happen if a series of less-serious vulnerabilities are discovered that can be used in tandem, in an attack that's greater than the sum of its parts. It's vital that you stay on top of the tactical world of security, and plug the holes in your armor whenever you find one.

The good news is that there are a lot of tools to help you do this. Security mailing lists like NTBugTraq, BugTraq and Win2kSecAdvice are a great way to learn about the latest attacks. In addition, many software vendors (including Microsoft) have developed security response processes to investigate and fix vulnerabilities. Make sure you check for new bulletins frequently. (Microsoft provides a notification service that enables subscribers to receive all security bulletins via email within minutes of publication, and also has developed a tool that lets IIS 5.0 servers constantly verify that the latest patches are installed). And don't forget service packs—they're one of the best ways to ensure that you're as secure as possible.

Law #4: It doesn't do much good to install security fixes on a computer that was never secured to begin with

Imagine you're a Visigoth and you're reconnoitering a castle that you and the rest of the horde plan to sack and pillage. From your hideout in the woods, you see that there's a veritable army of serfs performing maintenance on the castle's defenses—they're patching chinks in the mortar, sharpening the points on the chevaux-de-frise, and refilling the vats of boiling oil. Now you sneak around to the back of the castle and discover—that there is no back of the castle! They never built it! How much good is all that maintenance on the front of the castle going to do when you and the horde attack from the rear?

Similarly, what good are security patches if you've got a weak administrator password on your domain controller? Or if you've shared out your web server's hard drive to the world? Or if you've enabled the Guest account on your company's payroll server? The time to lock down a machine is before it's ever connected to the network. If this sounds like too much work, consider that, if a bad guy compromises the machine, you're going to need to rebuild it anyway. Microsoft provides security checklists that make it easy to lock down your machines, as well as a security lockdown tool that you can use to automatically secure IIS 5.0 Web servers. It doesn't get much easier than that.

Law #5: Eternal vigilance is the price of security

OK, so you read Laws 3 and 4 and patted yourself on the back. You've done everything right—you secured your machines before putting them into production, you've got the latest service pack installed, and you've been diligently applying security patches. You must be secure, right? Well, maybe, but maybe not. Even under these conditions, a malicious user could attack your network. For instance, he could mount flooding attacks, and simply send huge numbers of legitimate requests to a server in order to use all of its resources. Or he could conduct brute-force password-guessing attacks. Neither security patches nor machine configurations can totally prevent attacks like these, because the bad guy's activities, although malicious, aren't invalid.

You do have a weapon, though—the event logs. They'll give you information about who's using system resources, what they're doing, and whether the operation succeeded or failed. Once you know who's doing what, you can take appropriate action. If someone is flooding your system, you can block requests from their IP addresses. If someone is trying to brute-force your accounts, you can disable ones that are at risk, set up "honey traps" to catch him, or increase the lockout interval on the accounts. In sum, the event log lets you gauge the health of your systems, and determine the right course of action to keep them safe.

Be careful when configuring the event logs—you can easily audit so many events that you'll exceed your ability to analyze the data. Carefully plan what events you need to log, and whether you need to audit only successes, failures or both. The security checklists include suggested settings in this regard. Finally, keep in mind that the data won't do any good unless you use it. Establish procedures for regularly checking the logs. If you've got too many machines to check them all yourself, consider buying a third-party data mining tool that will automatically parse the logs for known indicators that your system is under attack.

Law #6: There really is someone out there trying to guess your passwords

Passwords are a classic example of the truism that your system is only as secure as the weakest part of your defenses. One of the first things an attacker may test is the strength of your passwords, for two reasons:

• They're extraordinarily valuable. Regardless of the other security practices you follow, if a bad guy can learn just one user's password, he can gain access to your network. From there, he has a perfect position from which to mount additional attacks.

• Passwords are "low-hanging fruit". Most people pick lousy passwords. They'll pick an easily guessed word, and never change it. If forced to pick a more-difficult password, many users will write it down. (This is also known as the "yellow sticky pad" vulnerability). You don't have to be technical whiz to crack someone's account if you already know their password.

Unless you can enforce a strong password policy, you'll never secure your network. Establish minimum password length, password complexity, and password expiration policies on your network. (Windows 2000, for instance, will let you set these as part of Group Policy). Also, use account lockout, and make sure you audit for failed logon attempts. Finally, make sure that your users understand why it's a bad practice to write their passwords down. If you need a demonstration, get management approval to periodically walk through your users' offices, and check for the dreaded sticky note with a password written on it. Don't do an intrusive search, just check the top desk drawer, the underside of the keyboard, and the pull-out writing table that's found on many desks. If your company is like most, you'll be amazed how many you'll find.

In addition to strengthening the passwords on your system, you may also want to consider using a stronger form of authentication than passwords. For instance, smart cards can significantly improve the security of your network, because the person must have both a PIN and physical possession of the card in order to log on. Biometric authentication takes this security to an even higher level, because the item that's used to log on – your fingerprint, retina, voice, etc. – is part of you and can't ever be lost. Whatever you choose, make sure that your authentication process provides a level of security commensurate with the rest of your network's security measures.

Law #7: The most secure network is a well-administered one

Most successful attacks don't involve a flaw in the software. Instead, they exploit misconfigurations—for example, permissions that were lowered during troubleshooting but never reset, an account that was created for a temporary employee but never disabled when he left, a direct Internet connection that someone set up without approval, and so forth. If your procedures are sloppy, it can be difficult or impossible to keep track of these details, and the result will be more holes for a bad guy to slither through.

The most important tool here isn't a software tool—it's procedures. Having specific, documented procedures is an absolute necessity. As usual, it starts with the corporate security policy, which it should spell out, at a broad level, who's responsible for each part of the network, and the overall philosophy governing deployment, management and operation of the network. But don't stop with the high-level corporate policy. Each group should refine the policy and develop operating procedures for their area of responsibility. The more specific these procedures are, the better. And write them down! If your procedures exist only as oral tradition, they'll be lost as your IT personnel changes.

Next, consider setting up a "Red Team", whose only job is to scour the network for potential security problems. Red Teams can immediately improve security by bringing a fresh set of eyes to the problem. But there can be a secondary benefit as well. Network operators will be much more likely to think about security in the first place if there's a Red Team on the prowl—if only because nobody wants the Red Team showing up at their office to discuss the latest security problem they found.

Law #8: The difficulty of defending a network is directly proportional to its complexity

This law is related to Law #7—more complex networks are certainly more difficult to administer—but it goes beyond just administering it. The crucial point here is the architecture itself. Here are some questions to ask yourself:

• What do the trust relationships between the domains in your network look like? Are they straightforward and easily understood, or do they look like spaghetti? If it's the latter, there's a good chance that someone could abuse them to gain privileges you don't intend for them to have.

• Do you know all the points of access into your network? If one of the groups in your company has, for instance, set up a public FTP or web server, it might provide a back door onto your network.

• Do you have a partnership agreement with another company that allows their network users onto your network? If so, the security of your network is effectively the same as that of the partner network.

Adopt the phrase "few and well-controlled" as your mantra for network administration. Trust relationships? Few and well-controlled. Network access points? Few and well-controlled. Users? Few and well-controlled—just kidding! The point is that you can't defend a network you don't understand.

Law #9: Security isn't about risk avoidance; it's about risk management

One of the most often-cited truisms in computer security is that the only truly secure computer is one buried in concrete, with the power turned off and the network cable cut. It's true—anything less is a compromise. However, a computer like that, although secure, doesn't help your company do business. Inevitably, the security of any useful network will be less than perfect, and you have to factor that into your planning.

Your goal cannot be to avoid all risks to the network—that's simply unrealistic. Instead, accept and embrace these two undeniable truths:

• There will be times when business imperatives conflict with security. Security is a supporting activity to your business rather than an end unto itself. Take considered risks, and then mitigate them to the greatest extent possible.

• Your network security will be compromised. It may be a minor glitch or a bona fide disaster, it may be due to a human attacker or an act of God, but sooner or later your network will be compromised in some fashion. Make sure you have made contingency plans for detecting, investigating and recovering from the compromise.

The place to deal with both of these issues is in your security policy. Work with corporate management to set the overall guidelines regarding the risks you're willing to take and how you intend to manage them. Developing the policy will force you and your corporate management to consider scenarios that most people would rather not think about, but the benefit is that when one of these scenarios occurs, you'll already have an answer.

Law #10: Technology is not a panacea

If you've read The 10 Immutable Laws of Security, you'll recognize this law – it's the final law on that list as well. The reason it's on both lists is because it applies equally well to both network users and administrators, and it's equally important for both to keep in mind.

Technology by itself isn't enough to guarantee security. That is, there will never be a product that you can simply unpackage, install on your network, and instantly gain perfect security. Instead, security is a result of both technology and policy—that is, it's how the technology is used that ultimately determines whether your network is secure. Microsoft delivers the technology, but only you and your corporate management can determine the right policies for your company. Plan for security early. Understand what you want to protect and what you're willing to do to protect it. Finally, develop contingency plans for emergencies before they happen. Couple thorough planning with solid technology, and you'll have great security.

Scott Culp is a security program manager in the Microsoft Security Response Center.