How to Think About Risk Management

There are some core concepts that we should cover first. The first concept to consider is threats. A threat is defined as an attacker or any person, trusted or mistrusted, who wants to break into, steal, cause damage, manipulate, or deny access to your information assets. In Information Warfare parlance, there are three general classes of threats. They are unstructured, structured, and highly structured threats. Briefly, these are defined as

• Unstructured: A non-funded adversary with no specific organization or long term planning. Example: disgruntled employee or a lone "cracker."

• Structured: A funded attacker or group of attackers with some organization and funding with generally longer term planning. Examples: organized crime or well-funded "cracker" organizations.

• Highly Structured: A highly funded attacker or group of attackers, usually with national state assets. Examples: national intelligence agencies or terrorist organizations.

These are general classes of threats, and there are certainly overlaps between them, so don't think of them as hard and fast rules. These are generalizations of all the "bad guys" out there to help you think about who might want to cause harm to your assets, to "steal" them so they can use them for their own purposes or even just to deny you access to your assets. It's folly to try and divine the motivations of a threat. You'll never really know what your attacker is thinking, so don't get caught up in trying to convince yourself that some attacker won't be motivated to do something. People do things for all sorts of irrational reasons, and computer crackers are no exception.

The point here is that understanding the threat is only part of the process of managing risk. You should consider the threats against your assets, but you will also need to consider the second concept at the same time: value. It is not only important to define how valuable your assets are to you, but also to understand who might be willing to spend some of their own assets to steal or "borrow" yours and what those assets might be worth to them. The secretary's computer might seem unimportant in the grand scheme of things, but maybe your attacker just wants to use her drive space to store something on, or perhaps the attacker needs the secretary's computer to break into the network at large and then break into something far more important. Keep this in mind when analyzing threats and value in your organization.

In economic terms, it's also useful to remember that assets are not only monetary. An asset's value could simply be the time needed to break into your system, or perhaps something more abstract, the opportunity cost of breaking into your system versus some other organization's systems. The bottom line is that value goes beyond just putting a price on an asset; an attacker might not have money in mind at all when breaking into a network.

Consider this example: An unstructured threat, a bored student, decides to try and break into your network. The student might have no funding at all to attack your assets but is simply curious and motivated to see if he can break into a highly secure facility. Time, for that threat, might be also be a low value asset because the student is on summer break and has free time in extreme abundance. Not all threats are so pedestrian; there are also highly funded and highly motivated organizations that have all the resources necessary to penetrate even the most well guarded assets. The point here is not to underestimate the resources at the disposal of a particular class of threats you might be attempting to defend against. Even though you will never truly be able to read the mind of someone who wants to beak into your computers, it can help to try to think like your opponent. Try to imagine what your enemy might do and, if possible, attempt to break into your own networks from the perspective of those various threats you are attempting to defend against. Just try not to underestimate your threats. A lack of imagination has been the undoing of more than one organization.

With those two critical concepts out of the way, the next core concept to cover is protection or to simply answer the question: What is it exactly that you want to protect? And within that question lies another: What is it about that asset you want to protect? One useful way to answer that question is by considering the following acronym: CIA. It stands for confidentiality, integrity, and availability. This defines what it is about the asset that is important.

For instance, if the asset has to be kept secret, then confidentiality is the goal. Is it critical that the asset not be altered or tampered with? If so, then integrity is a protection goal. And finally, must the asset be available, to whom, and under what circumstances? None of these goals are mutually exclusive; they are simply another means of determining what is important in a security model. You can have an asset that needs all three of these protection goals accomplishedand another with only one.

It's critical that you consider what it is, out of the CIA acronym, that you want to protect within each asset. If your goal is to make sure your website stays up and all the information on your site is public, then IA is important for that system. For e-mail perhaps you are only concerned with confidentiality, or perhaps your company is a health care provider and has a legal requirement to maintain the confidentiality of its customers' information. For each asset, the goals are different, and the reasons for those goals are going to be different.

The next concept to consider is means. How will you accomplish your risk management goals? With any risk management problem, you have three options, which also have their own acronymAMR: avoid, mitigate, recover.

Specifically with avoidance you can try to prevent or avoid the worst case, with mitigation you attempt to mitigate or manage your risk, and with recovery, you simply plan how you will recover from that risk. As with CIA, none of these are inherently mutually exclusive. You must consider which of these options is acceptable to you before proceeding with your risk management plan.

Above all else, it's important to keep these elements in mind when designing a security model. One example of a "simple" attack on an electronic infrastructure would be to use explosives to destroy the systems. This concept, while far-fetched for our unstructured threat, is not outside the realm of possibility for the structured threat and is part and parcel for the highly structured threat. If you consider how inexpensive explosives are and that they could be placed inside a server, and then that server could be placed inside the co-location facility your systems are located in, the capacity for causing tremendous damage becomes shockingly clear. It's a far simpler solution than a complicated electronic attack when the goal is simply to cause destruction. That's why it's critical to really consider all of these elements when thinking about the risks your systems might face. Your system could simply be in the wrong place at the wrong time. It's a complicated world, and it takes some careful thought to put together a good plan.

Just remember, risk management is a process, not a silver bullet. You cannot "engineer" your way into being secure. Security can only be accomplished by practicing risk management, and that's what this material is all about. With all of this said, this book is not intended to be a comprehensive risk management tome, but merely a guide to the subject to help you think about how to build secure firewalls as part of the process of troubleshooting them. We recommend that if you find these risk management concepts to be new, you read up on risk management before embarking on a new or improved security plan.