Introduction to the Defense-in-Depth Model

Introduction to the Defense- in-Depth Model

One of the fundamental guiding principles for network protection is defense in depth. As a general rule, it is always a good idea to have multiple prevention mechanisms, at multiple levels, to guard your network and the resources on it. Defense in depth, however, must be done to some threat model. Far too often, we deal with people who want to put some "security" measure in place but do not know what potential problems it mitigates or blocks. In that case, they usually call it a defense-in-depth measure. Unfortunately, one of the results that we need to consider from the fundamental tradeoff above is that any security measure impacts on usability or usefulness or both. At best, this impact is obvious. At worst, it is undefined. Defense in depth is a good thing, but instituting security measures to guard against a nonexistent threat at best has no effect and at worst makes the network less secure or stable and causes grief to users.

Figure 1-4 shows the defense-in-depth model we follow. This model is based loosely on the seven-layer Open Systems Interconnect (OSI) model. The OSI model is old by now, and some people scoff at us when we bring it up. However, the OSI model is still an incredibly useful abstraction for how networking works. It is still one of the most concise and tractable ways to demonstrate functionality in a network, notwithstanding the fact that efforts to build a network that directly implements the abstraction usually fail spectacularly.

Figure 1-4. Defense-in-depth model.

NOTE: Many people actually argue that there is an eighth layer on the OSI model: the political layer. (Yes, that is a joke, and we have heard it called other things! Other potential layers include the financial and religious layers .) This is actually accounted for in this defense-in-depth model. It is in the people, policies, and process layer.

Defense in depth starts with proper policies, procedures, and, perhaps most importantly, the right people and awareness among the general user population. Without a policy to guide you, you have no hope of developing procedures to implement the policy. Without a policy to guide your users, they will never be able to do the right thing. Users actually want to do the right thing . We know this statement comes as a shock to many system administrators, but it really is true. Users are actually interested in being good citizens and do not want to cause undue grief for their colleagues. Ok, there are some exceptions, but if you tell users how to do the right thing, as long as it makes sense to them, they will usually give it a sporting chance. As for the exceptions, well, if you have a policy, you can always turn them into ex- employees in accordance with the rules for breaking the policy! Part 2 of the book deals with policies, procedures, and how to educate users.

After you have established the policy, you must establish physical security. A network that is not physically secure will never be secure, period. (See Appendix E, "10 Immutable Laws of Security," for more information.) There are things that you can do at a logical level to make up for poor physical security, but in the end, if a bad guy can get to your systems, and he does not care whether you find out that he was there, it is not your system any longer. Chapter 6, "If You Do Not Have Physical Security, You Do Not Have Security," goes into more depth on physical security.

Going beyond physical security, we get into the actual technology that makes up our network. The first step is to ensure that we have a secure perimeter. The perimeter is the interface between your network and the rest of the world. It is where you meet your customers, and your attackers . If we had a dime for every time we had heard someone say "we have a firewall, so perimeter security is taken care of" well, let's just say we would not have to write this book if that were true. In Chapter 7, "Protecting Your Perimeter," we will explain more about why a firewall does not a perimeter make.

Within the perimeter, there is the network. This is all the gear, wires, and systems that make your organization tick. It is the place where all the attackers want to be. Why? Because most networks are built on the eggshell principle. They have a hard crunchy outside and a soft chewy inside. In Chapters 8 through 10 ("Security Dependencies," "Network Threat Modeling," and "Preventing Rogue Access Inside the Network," respectively), we will look into how to make your network less soft and chewy.

Of course, no network is a network without hosts (the computers that are used on the network). The hosts are the actual systems that store and process information on a network. Hosts are running some form of operating system. In this book, we are primarily concerned with Windows operating systems, by which we mean modern Windows NT-based operating systems (i.e., Windows 2000, Windows XP, and Windows Server 2003 being the current versions). That is not because those are less or more secure than any other operating system. Windows is not any less secure, or securable, than other operating systems. In the hands of the right people, any platform can be adequately protected, and in the wrong hands, any platform can be successfully compromised. The only differentiators are (a) how much money and effort went into protecting it, and (b) how much functionality you gave up in the process. The reason we discuss primarily Windows is actually much more pragmatic than that. We know our way around Windows. It is what we deal with every day. It is what we have spent a significant part of the past 10 years both securing and hacking. Although most of the principles in the book apply to a network on any platform, some of it is specific; and Chapter 12, "Server and Client Hardening," deals specifically with hardening Windows.

A host without applications is not particularly useful. Applications are what make a system valuable to us. We can have the coolest computer in the world, but without applications, it is only interesting to someone who is willing to write the applications. Unfortunately, at least with common off-the-shelf systems, the more applications you install on a computer, the less secure that computer usually becomes, and by extension, the less secure the network that computer is a part of becomes. Therefore, application hardening is critical. In Part 6 we look at hardening several different kinds of applications, all running on Windows. We also look at how to evaluate the security of additional applications you are using, or considering using, in Chapter 16, "Evaluating Application Security."

Finally, we have the most important part of it all, the raison-d' tre of your network: data. Without data, you would not need a network to transmit it. What should you to do protect your data? Turn to Part 7 to find out.