Failing Securely

You may have noticed that most of the examples of security issues I provided in this chapter involved some devices or applications that failed in one way or another. Hackers commonly use exploits that cause services to fail due to unexpected events. Most exploits are simple scripts that cause services to crash and open security holes. The worst examples are services that run as administrator and, when successfully attacked , give up control and allow the attacker to become the administrator.

Many times, the failure of an application, networking service, or operating system can be performed gracefully. When dealing with critical DB servers, for example, failures usually trigger events that attempt to leave the data in a usable state. Similarly, a firewall that detects a failure will oftentimes shut down access services to avoid allowing unauthorized access from outside entities. This is what is called failing securely .

Everything is subject to failure no matter how robust or expensive it is. Such failures often lead to lost productivity and potential security issues. As such, potential failure scenarios should be considered before any new implementation. When programming an application, failures should be made to lock down security. When a network architecture is designed, failures should not result in bypassing security as is commonly done. If a power outage occurs, services, applications, and devices should apply security during the reboot process. Consider failures in all devices and services, walk through the contingency plan, and consider the security implications therein. This is especially essential for major failure plans like disaster recovery policies.

I have had many clients implement an expensive firewall and intrusion detection architecture to protect their Internet connections and remote vendors . Knowing that a router or firewall may fail, however, they implement an inexpensive ISDN or DSL connection to act as a backup. This backup hooks directly into the network, bypassing the firewall and security. Many attacks are designed to disable a firewall or network devices, wait for an unsecure failover to take place, and then take advantage of the unlimited access.

Chapter 6. Making Security Decisions

graphics/ch06.gif

Using the Rules to Make a Decision

So here we are! Thus far in this book, I have provided the essential components for contemplating security in just about any given situation. With this information coursing through our minds, we now possess the tools required for making a wide variety of strong and effective security decisions. By reflecting on the rules, virtues, and other concepts we have discussed, security issues and their solutions should start becoming easier to identify and resolve. At this point, it is useful to present a formulaic process through which we can use these tools. This section will be a quick guide in how to utilize the information given thus far for recognizing, understanding, and dealing with security issues.

Notes on Policy

One of the great functions of a security policy is to simplify the process of making everyday decisions. The following techniques will lead us through a logical path , starting from a clean slate, gathering and weighing the details, and making an informed security decision. Once such a decision has been made, the efforts to make this decision can be simplified for the future by writing the end results into a policy. After making a security decision, writing it down in a globally applicable format will ensure that we will not have to go through the entire decision process again in the near future. Written policies also have the advantage that they tend to put more weight behind a decision, making it easier to enforce and more readily accepted by others.