10
Immutable Laws of Security Administration
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.
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:
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:
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:
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.