The most important function IT security managers perform is the selection of IT security measures.
Without effective security in place, rational day-to-day security management is impossible. Since security resources are always limited, even for Uncle Sam, it is essential to make optimum use of them. This means avoiding the bad reasons and focusing on the good reasons for selecting measures.
Let's begin by identifying the bad reasons for putting security mechanisms in place.
Best practices. These can't be 'best' in every situation, and, in fact, may not be best. Before you seize a list of best practices, notice that such lists never tell you how to prioritize implementation. (Later, I'll tell you how to make best use of best practices.)
Impact analyses. These are interesting, but they don't tell you how likely you are to suffer a worst-case loss.
Vulnerability analyses. These are also interesting, but, by often taking the checklist approach, they don't tell you if an identified vulnerability is significant. Vulnerability is only one part of the risk equation. We also need to look at the threats. Furthermore, if we prioritize our actions, we need to look at all the threats at the same time.
The threat-of-the-month. For example, 9/11 terrorism always gets lots of attention, but may actually be unimportant. Did you know that the threat of al-Qaeda attacks has a historic occurrence rate of once a year, and there are hundreds of thousands of potential targets? The White House, the Capitol and CIA Headquarters are probably at the top of the list, but where do you think your IT facility is on the list?
Perfect security. Now this just sounds great, but is infinitely expensive. Don't fall into the trap of promising that some loss will 'never' happen. Never is a long time.
Further reflection suggests that there are four basic reasons for selecting a security measure, none of which motivate ad-hoc approaches to implementing security measures.
Required by law. Legislators pass laws requiring security actions. For example, 'exit' signs in places of public assembly. We hope that such laws and regulations are well founded, but Risk and Reason by Cass Sunstein suggests this may not always be the case. Nonetheless, it should be our policy to obey the law. And there are plenty of regulatory mandates, such as HIPAA, GLB in the U.S. and the Data Protection Act in the U.K. Another in the U.S. is the Foreign Corrupt Practices Act, passed around 1978. It requires the preservation of records, which triggered various IT security requirements.
Trivial cost but material benefit. If you discover a security exposure that can be plugged at nominal cost, it makes sense to implement the measure. Best practice lists may help you to identify these opportunities.
The next two reasons are grounded in the product of a carefully conducted quantitative risk analysis. You may want to rely on some kind of qualitative analysis, but qualitative just doesn't cut the mustard. Do you really want to say to your chief finance officer, "I have identified a big risk exposure so I need a big resource allocation"? A quantitative risk analysis will produce estimates of the single occurrence loss (SOL) and annualized loss expectancy (ALE) for each of the threats to your IT facility. Here is how you use these results to support two more good selection methods.
Potentially fatal threats. There is some SOL level that is intolerably high for your organization. It is up the CEO and the CFO to make this judgment, and also to identify the threat occurrence rate threshold. They may decide to ignore extremely rare threats, for example, less frequent than once in 10,000 years. If you identify a threat with an intolerable SOL and an occurrence rate above the threshold, you should look for a way to either reduce the SOL, for example with an insurance policy, or push the occurrence rate below the threshold with mitigation. Put the action on your list of proposed security actions, and leave it to the CEO and CFO to make the decision.
Cost-beneficial actions. Finally, you examine the remaining threats to see if you can identify security actions with a strongly positive return on investment. Your quantitative risk analysis will make it possible to evaluate the cost of implementation against the reduction in ALE that a proposed action is expected to yield so you can estimate the ROI. Similarly, you can use the analysis to identify the optimum values for recovery time objective and recovery point object.
With a businesslike approach like this, you won't have to 'sell' to the chief information officer. The CFO will do the 'selling' for you.
Robert V. Jacobson is president and founder of International Security Technology, Inc., a New York City-based risk management consulting firm (www.ist-usa.com).
