- The Methodical Approach and the Need for a Methodology
- Firewalls, Security, and Risk Management
- How to Think About Risk Management
- Computer Security Principles
- Firewall Recommendations and Definitions
- Why Do I Need a Firewall?
- Do I Need More Than a Firewall?
- What Kinds of Firewalls Are There?
- The Myth of "Trustworthy" or "Secure" Software
- Know Your Vulnerabilities
- Creating Security Policies
- Training
- Defense in Depth
- Summary
This chapter is from the book
This chapter is from the book
This chapter is from the book
Computer Security Principles
Computer security, a subset of risk management, is about facilitating activity while minimizing unnecessary exposures that activity creates—in a way that makes it possible for users to still get work done. The bad news is that it's a pretty darn subjective process, and what makes one person feel secure might make another cringe. You can't please everyone. But you can construct a very solid security model by sticking with this simple and powerful premise: Unless we allow the system or network to do something, we will always deny it. The default state of all systems is to deny. Again, the rule is: unless allowed, deny. This is the golden rule for all well-designed firewalls.
This runs counter to the way some people choose to go about creating computing systems and networks. They build a system to do something, and if security is a criteria, they come back to the system after it's built with a set of rules defining what they do not want someone to do. That is the wrong way to go about it, and it also can be a painfully tedious process, even if you do it before you start to build a system. If you want to build a truly secure system, do what you do best—design your system and define what you want your users to do. From there, you construct a security model that opens those capabilities in your firewall. What you don't want to do is add a bunch of rules to your firewall, defining (exclusively) behavior that your users cannot do. You're bound to miss something that the highly imaginative human mind will come up with. The only thing you want to concern yourself with is what the users need to be able to do. Because your firewall is configured by default to deny everything, you don't run the risk of missing something. You're only allowing things through your firewall that you know about.
Let's explore this further. Think of a firewall as a totally closed system, in essence a "cut" in the wire between two networks through which no traffic at all flows. There are no holes in real firewalls, that is, the physical kind that protect buildings, and we want to keep it that way unless we can prove that there is a need for a hole or service to be opened and that we know we can do it in a way that doesn't introduce fire into the rest of the building. There is a reason firewalls, the networking kind, got their name. A long time ago, that's how most of them were configured—with no holes at all. They were just application proxies that moved data from one domain to the next, and in classified environments there were even firewalls that could only move data one way through a firewall where literally no traffic could flow back in the opposite direction. The point is, firewalls need to be built in as paranoid a manner as you can because with today's demanding networks and customer needs, we have to open a lot of holes in firewalls, and this is where we need to be especially careful. A firewall is not a silver bullet. Allowing traffic through a firewall, sometimes referred to as opening a hole in the firewall, is the same as putting that system out on the Internet with no firewall in front of it!
Remember, the firewall isn't going to magically strip away all the attacks that someone might launch through your firewall. Use the firewall as one of many mechanisms to protect the system or systems behind it. You need to look at things like Intrusion Detection, Protocol analyzers, Intrusion Prevention Systems, classic system hardening, the venerable method of keeping your system patched, cryptography, authentication, software security, and above all else real risk management before you can even begin to say that your system is "secure." Firewalls are only one slice of the security spectrum. You need all the elements of the visible light spectrum to get white light, so it is with security; you need the whole spectrum of methods, procedures, technologies, and management practices to make something "secure."
With that said, here's the bad news...there is no such thing as a "secure" system, which is why we put this word in quotes. The term, secure, is subjective and means different things to different people at different times. For example, your system might be patched up today, so you tell yourself it's "secure," but when you head off for a much earned vacation this weekend, a new vulnerability is published, and you can't get to your system to patch it. And along comes an attacker that uses that vulnerability to break into your, now, insecure systems.
It's also important to keep in mind that with all these measures taken, it is still possible that your system might be broken into or that some other calamity might destroy or make the system unavailable. A flood for instance, an earthquake, or a just plain old hardware failure could be far more damaging than a hypothetical attack. That's why it's important to recognize that there is more to risk management than just securing a system from attacks.
That's the real business that every security professional is really in—managing risk. With risk, as we stated before, you can do three things to manage it: you can avoid it, mitigate it, or recover from it. Sometimes you can do several of theses things; other times you can do only one; and sometimes you can do none of the above. It's important to understand this. This point is critical, and it bears repeating. All security is really about is managing risk. Sometimes you can do something because the risk is acceptable, and sometimes you cannot. This point causes much grief for many security professionals, their customers, users, and bosses when security is confused with some mythical state of being absolutely secure. All you can ever do is manage your risk in a manner that meets your criteria for acceptable risk and loss. You're happy jumping out of the airplane with a parachute; your buddy is not.
Also, to review, threats are a critical competent of risk analysis. To determine if your efforts are necessary or if they are enough, you must consider what threats are going to try to compromise the system(s) you are protecting. For instance, if you are running a simple website with nothing of interest or value to terrorists or organized crime, you might not need to consider those threats. If you're the CIA, you need to consider those threats.
One other thing to keep in mind with threat analysis is that the system you are running might not be the attacker's real target. Your system might be broken into by a highly structured threat to attack the real target or perhaps another "zombie" along the way, which in turn might be used to break into the real target, or your system could just be broken into by a worm, virus, or bored cracker.
The bottom line is that there are some very odd people out there who want to break into systems for all sorts of reasons. It's critical to understand that there are many reasons your system might be broken into, some of which might never have dawned on you. Many a poor system owner has found their "unimportant" system broken into by persons that could care less about what that system had been used for. The attackers now "own it," and they're using it for their own ends. Sometimes, all an attacker really wants is the virtual real estate your systems occupy.