Google

The Ten Immutable Laws of Security Administration

The Ten Immutable Laws of Security Administration

Contact:[email protected]

By Scott Culp

November 2000

We recently published the Ten 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.

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 Ten 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.


Back to the Index