In-Depth

Risky Business

The work of risk analysis—evaluating security threats, alerts and all-out panic attacks—is vital to keeping your network safe and sound and you sane.


Some days I just want to put my head down on my desk and give up. I'm talking about those days—just as I'm starting to feel proud to be evangelizing the many built-in security features of Windows 2000—when a really dumbfounding security alert from Microsoft arrives in my inbox and shatters my beliefs. On those days, becoming a Wal-Mart greeter sounds appealing.

Oh, I know that every operating system has flaws (See "Severity Metrics"), and I'm glad that Microsoft is telling me about its latest. But, sometimes, the cumulative effect of what I'm hearing just bruises my soul. Nevertheless, those days are few and far between, and I've yet to lose my faith. In fact, I've often been asked how I can respond so calmly to the screaming meemees out there who are constantly raising some alert about this or that. Why haven't I joined them in parading around on the virtual street corner with placard raised proclaiming the end of the world? How do I provide a calm, measured response that dispels fears and prevents panic among the masses?

It's not that I don't feel the need to consider their messages. It's just that I don't believe they're all of equal value and, thus, don't require an equal response. You see, I've got a secret approach to these doomsdayers: Most of the time they're not telling all of the truth! And, when they are, it may not apply to you or may not apply if you've taken serious charge of your systems and use sound security practices. A greater risk may be that of a hurricane or power outage or from a disgruntled employee.

You already knew that, right? OK. Then all you have to do is figure out which security alerts you should be paying attention to and calmly go about making sure your systems are protected. How do you do this? Simple. Learn to apply the principles of risk analysis to all of the potential threats to your systems and promise Sister Roberta that you'll stop jerking your knee up into your chin every time you see the words "Microsoft" and "security bug" in the same sentence.

While keeping that second promise is something you'll have to do, I can help you understand the basic principles of risk analysis and how to apply them. Once you've started down this path by identifying the more mundane threats to your network, you'll be better able to evaluate Chicken Little's frantic cries.

The Basics of Risk Analysis
While esoteric definitions of risk analysis exist ("Risk analysis is the science of putting the future at the service of the present," from the Journal of Risk Analysis), a more straightforward approach can be found in Will Ozier's article, "Risk Analysis and Assessment," from Auerbach Press' Handbook of Information Security Management. His article defines risk as, "…the potential for harm or loss," and risk analysis as, "…the process of analyzing a target environment and the relationships of its risk-related attributes."

The target environment, in our case, is our information systems. The risk-related attributes are numerous, but certainly include exposure to hostile networks such as the Internet, employee misuse, acts of nature, bugs in software and human stupidity. Risk analysis, when understood and practiced properly, provides a way to organize your understanding of the what-if and put it into perspective by judging the financial consequences vs. how often it might happen and how likely it may happen at all. Thus, you can look at all of the possibilities and weigh them on a scale that allows you to put your efforts and anxiety where they'll do the most good.

Severity Metrics

Ever wonder which products pose more of a threat to your network? Take a look at the Computer Emergency Response Team's list of vulnerabilities by severity. A large number of known vulnerabilities to information systems (OSes, applications, routers, modems and so on) is ordered and listed at www.kb.cert.org/vuls/bymetric. It makes for really interesting reading. In the top 10, only three Microsoft-related vulnerabilities are ranked; there are more Unix-related issues detailed.

So what's the top vulnerability? With a metric of 108.16 is a flaw in BIND T_NXT record processing, which may cause a buffer overflow (repaired in version 8.2.2.) that has the potential to give an attacker control over the name server, potentially at the root (administrator) level. IIS' superfluous file name decoding flaw comes in fourth at 79.31. This vulnerability might allow an attacker to gain access to the IIS server with the privileges of IUSR_computername. This account is limited by the privileges and file access assigned to it. A patch exists to correct this issue.

The point here isn't to pit the relative security of one thing against another—it's merely to give you some perspective (and, possibly, ammunition). The metrics, by the way, are calculated in a relative manner (using 0 as the lowest and 180 as the highest) and consider factors such as how widely the vulnerability is known, whether there's knowledge of the vulnerability being exploited, whether Internet infrastructure (think globally, act locally) is at risk, how many systems are at risk, the impact and ease of exploitation, and any preconditions that must exist before the vulnerability can be exploited.

The results may assist you in identifying very serious vulnerabilities. CERT advises that any vulnerability with a rating above 40 is generally severe enough to be considered serious. As a note, CERT cautions that ratings aren't linear. The Microsoft IIS vulnerability above with its rating close to 80 isn't twice as bad as the "Compaq Web-enabled management software buffer overflow in user authentication name" vulnerability with a metric of almost 40.

—Roberta Bragg

Properly done, risk analysis allows you to ignore threats that can't affect you ("I don't use that product so I don't need to be concerned," or "I'm not connected to the Internet so the worm can't get me"); spend less time on that which carries little chance of happening ("Someone's going to capture my SSL-encrypted, changed-frequently password, decrypt it and use it to obtain access to my network resources"); and devote your time to those things that stand a definite chance of affecting you (hostile code in e-mail attachments, weak protection of sensitive files and folders, and penetration through paths, such as modems, that go around your firewall).

While no numeric system, gut feeling or even statistical analysis can be a hundred percent correct, we can come up with a methodology that allows you to compare calculated threats. One such process is the Annualized Loss Expectancy (ALE) calculation. This is derived by multiplying the Single Loss Expectancy (SLE)—the expected monetary loss for a single occurrence of some event—times the Annualized Rate of Occurrence (ARO)—how many times the event might occur in a single year.

For example, to determine the merits of properly monitoring your network's Internet traffic and how much money you can expend on that process, you might have to calculate the price tag should each threat occur. How much would it cost if the next Internet worm or macro virus or other hostile attachment breeched your defenses and was able to attack your network? Don't forget the cost of lost productivity and the time it takes to repair systems, clean e-mail servers and restore data. How many times per year might this happen? Once you have these two answers, simply multiply them to arrive at the ALE.

Would purchasing a new virus-checking product that works on your entry points, frequent updating of desktop virus patterns, or training of administrators and users reduce the number of effective attacks and/or reduce the amount of loss? How much would it cost to put these solutions into place? How does this threat rank as opposed to others? Once you know the answers to these questions, not only can you determine the threats that could harm your company the most, but you can identify which ones would be best alleviated by your efforts.

The benefit of risk analysis isn't in exposing the enormous costs that may result if some threat becomes reality. It's that you can put all risk in proper perspective and find those you can effectively reduce by applying your resources. This process is called risk assessment: risk management is the process of doing something about it.

To use the results of your analysis, the cost of solutions must also be calculated. By identifying the problem, what it may cost should it occur, and calculating the cost of a solution that will reduce the risk (and, thus, the cost), you can compare the cost of the solution in relative terms. Does it take more to protect the systems than it would if the risk became reality? Can some intermediate solution obtain most of the benefits at a reduced cost? This is the kind of analysis that'll result in the effective use of your current resources. It can also help you obtain the budget to put solutions into production.

Study Threats to Your Network
Does all this non-technical mumbo-jumbo sound like a lot of work? Where will you get the statistics? How can you calculate the numbers? Does anybody really know the probability or frequency that some risk will occur?

Risk analysis, like any other business activity, has many approaches. The first thing to determine is which type of assessment (assignment of value to assets, threat frequency, consequence and so on) you wish to do. There are two major divisions: quantitative and qualitative. Quantitative assessment is exhaustive and applies hard-dollar values to every aspect (how much will the lack of a firewall cost?). Qualitative assessment uses non-numeric results (you don't have a firewall, therefore you're at risk). Most risk analysis sits somewhere between these extremes. We could even argue, as Ozier does, that a purely quantitative risk assessment is impossible, as we're attempting to apply that to qualitative properties (how much will loss of esteem cost?). Or you could insist, as many practical managers do, that using the quantitative approach is a bunch of hooey. They argue that it costs a ton to get those figures and complete the analysis; when you're done, a qualitative analysis would give you the same ordering of threats and identify the same practices that can provide the most benefit. In other words, here's one place where gut feeling can outrank pure science.

If you'd like to investigate the quantitative approach further, you should realize that most companies that use such techniques have long since abandoned paper and pencil and either have automated their calculations or purchased a risk-analysis package such as C&A Systems COBRA (www.pcorp.u-net.com), Crystal Ball (www.decisioneering.com/index.html) or Pertmaster (www.pertmaster.com). These programs still require extensive work, but remove the tedium of calculations. They outline the steps and allow you to focus on the technical and business issues particular to your systems. Remember that even a sophisticated, vetted program won't produce good results unless you realize the impact of GIGO (garbage in, garbage out). To get accurate results, you may need to enlist the support and assistance of business entities beyond IT.

Any good risk analysis considers more than the impact of threats to information systems. To do this right, you'll want to enlist the aid of non-IT departments. As a techie, however, you can gain a lot of the benefit of risk analysis by taking the first look at IT issues.

The approach I usually recommend uses primarily a qualitative approach. There are three parts to this process.

Know Your Enemy, Your Strengths and Your Weaknesses
Instead of spending countless hours attempting to apply a dollar amount to every risk, use your experience and the knowledge of your peers to catalog and then apply a weighted factor to each threat. You'll still have to estimate relative cost, chance and frequency, as well as mitigating factors. I use a scale of 1 to 10, with 10 being highest. Compiling and ordering these results will tell you where to spend your energy and money.

The process starts simply. List the threats and determine the information you want to accumulate about each. You may want to prepare a chart, Excel spreadsheet or Word table, like Table 1. Along the left side of the table is a partial list of threats to a typical small business network with Internet connectivity. (For this to work, you must list all of the potential threats to your systems.) Across the top of the table, in columns, are designations for information necessary to start the process. These represent assets, frequency, certainty, mitigating factors and space for an overall rating. Table 2 details a partial list of the process. Remember these are representative ratings for a fictitious company. Only you know your systems and can compile an appropriate list of threats and their ratings.

Threat Asset/
Process		 Value of Loss Frequency (Number of times annually) Weight Certainty Mitigating Factor Rating
Hostile code in e-mail attachment x x x x x x x
Hostile code from Web site x x x x x x x
Port scan x x x x x x x
DDOS attack x x x x x x x
Power spike/
brown out		 x x x x x x x
Malicious employee x x x x x x x
Mistake (data entry in product pricing table) x x x x x x x
Misuse of system x x x x x x x
Data theft (stolen customer credit card numbers from Web site) x x x x x x x
Table 1. Stage one of risk analysis is to develop a table to weigh the risks to your network in specific areas and give each aspect of the risk a weighting.
Sample Risks/Solutions table
Table 2. Once you've determined the most serious risks, the next step is to identify solutions or poducts and practices that can reduce the threat and, thus, the cost. (Click image to view larger version.)

Assets represent the computer systems, data, public confidence, productivity and so on that may be affected by such a threat. In some cases you might not see the loss in replacement systems, but in the labor required to fix the problem. Record this as well. Provide a value column, but don't record an exact value—rather rate each asset in importance. For example, it's obviously more serious if you lose the financial database server than a desktop system. You might, using my scale or one you develop, rate the loss of desktops as a three, while loss of the database server might represent a 10. When you're done, you can very easily see the threats that represent catastrophic scenarios.

But you're not finished. The next step is to determine the frequency of each potential threat. You want to know how many times a year this might occur. (For instance, you might like to know how often a new e-mail attachment containing hostile code is released on the Internet.) A good source for some of these statistics is the CERT site. CERT is the Computer Emergency Response Team at Carnegie Mellon University. You can find quarterly reports at www.cert.org/summaries/. In addition to releasing security alerts, CERT keeps statistics on the nature of information system threats. Practical notes might also be obtained from the Honeynet Project at http://project.honeynet.org/. These folks leave a test network open on the Internet and record the techniques used to attack their systems. You won't find quantified statistics, but you will find—in numerous "Know Your Enemy" white papers—various factoids, such as the 524 TCP port 139 (NetBIOS Session Service) scans in one month.

Brothers and Sisters, It's Time

It's time to stand up and be counted. It's time to look in the mirror and say, "I'm mad as hell and I'm not going to take it anymore." It's time to leave your office cubicle and repeat the refrain.

I say this not because the Code Red Worm infected thousands of unpatched IIS servers and denied service to other systems and networks in July. While this evil piece of code spread havoc like some Old Testament devil, it's only a symptom of our disinterest, a symptom of our ability to hide behind fences and run our networks as if they were appendages of our self-centered selves. Like some frontier explorers, at the first sign of attack, we circle the wagons and make it about them and us.

But it's not time to point the finger. Yeah, Microsoft should have written the product better in the first place. OK, the installer should have followed good security practices and removed the mappings. Sure, the admin should be keeping the system patched. But is management providing the resources to do this? Or do they only listen to the security mantra when big bucks have already been lost because their unpatched and unhardened systems have gone down? More than "non-patchers" are at fault here.

All righty, then. What can we do? How can we protect our network from untrained admins, unsophisticated users, stingy managers and well-meaning executives who don't have a clue? Patch your servers. Participate in user and home user education. Focus on keeping the rest of cyber-connected space safe as well. Your properly patched servers won't participate in DDOS attacks; but what about the ones your neighbors have?

Doing your part is good, but that's only the first step. What we also need, brothers and sisters, is activity that preserves the entire Internet and associated computing environments. That means we have an enormous educational, emotional and technical job on our hands. We need security awareness training for all levels of computer users: managers, executives. IT, end users and home users. We need procedures focused on setting up secure systems and evaluating risks and responding to security alerts, and then follow them. We need to get enough people to do the job that needs to be done and enough money to do it with. We need to join with others for the good of all. Educate them, honor them and provoke them into doing what's right.

As it went in the '60s, "You're either part of the solution or part of the problem." Which one are you?

—Roberta Bragg

While neither of these can tell you exactly how many times the threat will occur for your network, they can give you an idea. They help validate gut feelings like "there will be a larger number of new hostile code type attacks spread via e-mail or via connection with questionable Internet sites than all-out attacks directed at your specific network" (unless, of course, you have a very public presence or there's some clear benefit to attacking you that's well known).

By now, you should realize that even the frequency of the threat couldn't be generalized or probably even calculated very accurately. The number of attacks present each year must be filtered by knowledge of your company and its systems.

Nevertheless, public figures can give you averages as a starting point and help you begin to determine if a particular event will happen. You'll want to try to find out if a particular threat will become reality or is certain to happen this year. Once again, this is a relative rating. While no one can predict natural disasters, your data center is more likely to be flattened by a tornado in the Midwest, a hurricane in Florida, a tsunami in Japan or an earthquake along the West Coast. Thus, depending on your geographic location, the certainty of one of these events varies. However, if you allow file sharing on systems directly connected to the Internet, the certainty of your system being compromised is very high.

If you're really interested in how this process can be quantified, you might take a look at actuarial science. This is the process of determining—through statistical analysis using large amounts of data—the relative certainty that a particular event will occur to a particular class of individuals or companies. It's the science behind the variance in insurance rates, say, between teenage male drivers and 30-something female drivers. While I haven't seen many publications on work done on the types of threats we face in cyberspace, there are many statistics on how likely it is that a storm will threaten e-commerce site warehouses or how likely it is that an earthquake will shut down the power to server farms in California. Start your studies by checking out www.actuary.com or turn to risk-analysis sites such as www.sra.com and www.risk-analysis-center.com, which quantify the risk to public health from chemical spills and biological hazards as well as natural disasters.

Finally, you need to list mitigating factors. These are systems or practices already in place that can reduce the loss presented by the threat. They can also be specific information about your business, which naturally limits its loss. Properly configured and maintained firewalls, for example, can reduce the risk of being connected to untrusted networks.

Pick the 10 Percent
It's often said that 10 percent of the threats cause 90 percent of the damage. Your job is to identify that 10 percent and reduce the risk. Simply take each threat and add up the weighted responses to each category. Those threats with the largest results represent your worst nightmares. Next, take a quantitative approach to determine what to do about them. At this time you must attempt to apply a real-world dollar figure to the loss and to the products and processes that can reduce that cost. This will help you identify the processes that will be of the greatest benefit. You might find, for example, that it would cost an enormous sum to reduce the risk only a tiny amount. On the other hand, you might find that funds spent on a security-awareness program or providing security training for network and systems administrators would reduce risk substantially. You might be surprised by how much good, well-known security practices can mitigate risk. Choose projects that will realize large benefits with little effort. Presenting this information to management will often obtain the support and financial backing needed to put your solutions in place.

In Table 2, you can see that, comparatively speaking, the risk at our hypothetical company is higher from hostile code in e-mail systems than anything else. The next step would be to identify solutions or products and practices that can reduce the risk and, thus, the cost should the risk become reality. By now you're thinking this company needs to scan attachments for known hostile code, and there are products that can do this. While this won't eliminate all risks, it'll counter many of them, especially if the code signature database is frequently updated. Justification for its purchase may seem evident. But wait! You must first attempt to determine a real-dollar loss for this company and compare it to the cost of purchasing, installing and maintaining the filtering product. If I told you that this company comprises 10 users, I think you'd agree that most products that do this at the network entry point would cost more than the potential loss. (That would depend, of course on the value of the data, existence of backups and so on. That's why we attempt to assign a dollar value at this point.) Alternatively, the cost of providing some protection—in the form of a desktop security application and training users in its proper use—can be justified.

Filtering Alerts Through Wise Eyes
Finally, use this knowledge each time a new threat is identified. You'll find that—because you've done your homework—you can calmly approach and even dismiss many of those alerts that previously precipitated panic attacks. (As an example, consider those systems administrators who applied patches to IIS systems when Microsoft provided them who weren't bothered by several highly successful attacks that have been crippling some sites this year.) Like MASH's Hawkeye, when the wounded are brought in, you'll dismiss the minor, place aside that which can wait, and concentrate on life-threatening emergencies. You'll also sleep a lot better at night.

Keep the faith, baby.

Featured

Most   Popular