Appendix C

Appendix C

The Ten Immutable Laws of Security Administration

After Microsoft released the Ten Immutable Laws of Security, described in Appendix B, we realized that administrators have their own list of immutable laws, one that s entirely different 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, one that 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.

The Ten Immutable Laws of Security Administration are as follows:

  1. Nobody believes anything bad can happen to them until it does.

  2. Security works only if the secure way also happens to be the easy way.

  3. If you don t keep up with security fixes, your network won t be yours for long.

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

  5. Eternal vigilance is the price of security.

  6. There really is someone out there trying to guess your passwords.

  7. The most secure network is a well-administered one.

  8. The difficulty of defending a network is directly proportional to its complexity.

  9. Security isn t about risk avoidance; it s about risk management.

  10. Technology is not a panacea.

Let s look at each law in detail.

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 focus on your company s business rather than on the vagaries of computer security. Many users can t conceive why someone might go to the trouble of sending them a malicious e-mail or trying to crack their password, but an attacker needs to find only one weak link to penetrate your network.

As a result, relying on voluntary measures to keep your network secure is likely to be a nonstarter. 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 the value of the information on your network 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 works only if the secure way also happens to be the easy way.

As 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 might 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 be lesser after you implemented more stringent policies.

You can take three key steps 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 sure your security processes have value to your users. For example, 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 will make it doubly popular.

  • In cases in which you must impose a restrictive security measure, tell 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 a huge number of disreputable people are actively searching for them to use 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 number 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 a lot of tools are available to help you do this. Security mailing lists such as NTBugTraq (www.ntbugtraq.com), BugTraq (www.securityfocus.com), and Win2kSecAdvice (listserv.ntsecurity.net/archives/win2ksecadvice.html) 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 at www.microsoft.com/technet/security/notify.asp that enables subscribers to receive all security bulletins via e-mail within minutes of publication. And don t forget service packs (details at www.microsoft.com/technet/security); 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 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 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 connected to the network. If this sounds like too much work, consider that you re going to need to rebuild it anyway if a bad guy compromises the machine. Microsoft provides security checklists at www.microsoft.com/technet/security/tools.asp that make it easy to lock down your machines, as well as a security lockdown tool that you can use to automatically secure Internet Information Server 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, maybe not. Even under these conditions, a malicious user could attack your network. For instance, she could mount flooding attacks and simply send huge numbers of legitimate requests to a server to use all its resources. Or she could conduct brute-force password-guessing attacks. Neither security patches nor machine configurations can totally prevent attacks like these, because the attacker 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 honeypots 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, only 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 tasks an attacker usually performs is testing 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 to many attackers. Most people pick lousy passwords they ll pick an easily guessed word and never change it. If forced to pick a more difficult-to-guess password, many users will write it down. (This is also known as the yellow sticky pad vulnerability.) You don t have to be a 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 down their passwords. 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 pullout writing table that s found on many desks. If your company is like most, you ll be amazed how many you find.

In addition to strengthening the passwords on your system, you should consider using a stronger form of authentication than passwords. For instance, smart cards can significantly improve the security of your network, because a person must have both a personal identification number (PIN) and physical possession of the smart card to log on. Biometric authentication takes such security to an even higher level, because the item that s used to log on your fingerprint, retina, voice, and so on is part of you and can t be duplicated. 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 involve the exploitation of 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 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 that network. But don t stop with the high-level corporate policy. Each group should refine the policy and develop operating procedures for its 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 or Tiger 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 to discuss the latest security problem the team 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 administration. 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 someone could abuse them to gain privileges you don t intend 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 into 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 oft-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 might be a minor glitch or a bona fide disaster, it might be because of a human attacker or an act of God, but sooner or later your network will be compromised in some fashion. Make sure you have contingency plans in place 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 policy will force you and your corporate management to consider scenarios that most people would rather not think about, but when one of these scenarios occurs, you ll already have an answer.

Law #10: Technology is not a panacea.

You ll recognize this law from the previous appendix it s the final law on that list as well. It s on both lists 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 and install on your network to 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.



Writing Secure Code
Writing Secure Code, Second Edition
ISBN: 0735617228
EAN: 2147483647
Year: 2005
Pages: 153

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net