Risk analysis is not the favorite activity of most IT security pros, and it's certainly not mine. Aside from being a rather dry subject, it carries an air of artificiality far removed from buffer overflows, open ports, and unpatched systems.
So-called experts on information security risk analysis have put forth several quantitative methodologies for identifying assets that need protection, evaluating threats to those assets, and estimating losses that might result from those threats. However, it's not uncommon to be off by an order of magnitude high or low when estimating the cost of losses associated with an incident, making all those formulas and methods impractical for in-the-trenches IT security pros. But what should we be doing instead?
Making Choices
Despite the inaccuracies of painstakingly developed methods of evaluating risk, fundamental, commonsense principles of risk analysis have value for everyone working in information security, particularly when it comes to making decisions about what you spend time and money on. The first thing to recognize is that resources have limits. It's an illusion to think that you can prevent every possible risk. Trying to do so would be a disservice to you and your organization.
The hitch is that although resources are limited, risks aren't. Consequently, a large part of risk analysis involves choosing which risks to address and how much of the resource pie to direct to each risk.
Wise choices don't result from letting yourself be blown about by the latest bluster in the media or the risk your boss is fixated on this week after having read about it in The Wall Street Journal. But following a few commonsense principles will lead you to good decisions that will save you time and money.
Know Your Assets
First, know which assets you need to protect. The definition of an asset varies depending on the focus of your responsibilities and how technical your role is. Ask different people in the same IT department to identify assets that need protection, and you'll get answers ranging from specific servers or pieces of equipment to databases, business processes, and even abstract concepts such as goodwill. All are correct depending on the level at which you work.
Map Back to High-Level Assets
When identifying a technical component or process of your IT infrastructure that needs protection, make sure you map that low-level asset back to the appropriate high-level asset. For example, backups of customer data are a low-level technical asset that map to several valuable high-level business assets, including your core-revenue-generating order fulfillment process, goodwill from customers who trust you with confidential information, and compliance with regulations. Looked at in this light, the choice to expend resources on backing up customer data is a wise one.
But is it as smart to do the same for your data warehouse? Probably not. Unlike a customer database, your data warehouse lacks personally identifiable information, doesn't affect order fulfillment, and represents a small percentage of profit through supply-chain optimization.
Map Back to High-Level Risks
A similar principle calls for mapping technical risks to high-level business risks before implementing countermeasures. This step helps you avoid using security settings and technologies just because they exist rather than because implementing them is worthwhile.
For example, you can encrypt backup sets, but doing so usually requires extra effort—and possibly new hardware, if you need to stage the data on disk before encrypting it and sending it to tape. Encrypting customer data backups alleviates the very real risk of disclosure of highly confidential information. This measure can even be fairly affordable because the database might be small enough to be encrypted on disk and sent to tape without requiring you to have a SAN for staging purposes.
But encrypting your data warehouse might be a waste of resources. In the worst-case scenario, deciding against encryption might mean that some business intelligence reaches competitors. If your data warehouse is so large that you'd need to buy additional storage for staging purposes, it's even clearer that implementing a safeguard just because you can isn't sufficient justification.
Choose Your Battles
Password cracking is a perfect example of how some of my colleagues often waste resources. You can choose to spend time figuring out what combination of characters and password length will defeat or at least delay the latest password cracking tools. And you can fret about how rainbow tables let attackers crack passwords in a fraction of the time that used to be required. My advice, however, is to think before you spend a lot of time or money and be sure that the enemy you're fighting is the real threat.
To crack a password, an attacker must obtain a copy of the password hash, which usually requires the attacker to have administrator authority or physical access to the target system. By the immutable laws of computer security, someone who has administrative authority or access to a system has carte blanche—and you've already lost the war. Trying to prevent a rogue administrator or someone who has physical access from cracking passwords is akin to severing a single-snake from Medusa's head: You might solve one problem, but there are many more.
Instead of devoting resources to making passwords difficult to crack, you might do better to safeguard your administrator accounts and physical access to systems. Then you can turn your attention to identifying other scenarios that might lead to theft of password data susceptible to cracking. For example, given the right circumstances, attackers can capture packets of authentication traffic. If your organization considers authentication sniffing to be a significant exposure, you might be able to mitigate the risk by implementing stronger authentication protocols on your network, adding physical security-over network drops, and decreasing your networks' susceptibility to Address Resolution Protocol (ARP) redirects.
Keep Things in Perspective
Effective risk analysis comes down to one important precept: When protecting assets, don't spend more than the asset is worth. Walking that line is precarious, of course, because quantifying the variables is more black art than science. But understanding the connection between low-level and high-level assets and risks, weighing your options, and fighting only the battles that will return more than you invest will help you make the most effective use of your limited resources.
