Bad things happen, even to good information systems. It makes no difference how well they are designed, how they are operated or controlled. Bad things just keep happening. In some cases, they result from accidents, either because of poor training and supervision or just because human beings are fallible. In other cases, Mother Nature intervenes and meteorological, seismic or other climatic events interrupt normal systems operations. Worst, there are some bad people in the world, from script kiddy hackers to dedicated terrorists, who intentionally try to degrade or destroy information and systems.
Hard experience has shown that enough bad things happen over a period of time that it is imprudent to simply shrug them off. At the individual level, it's commonplace to find firewalls and virus protection on home computer systems. Without these and other safeguards, people find their personal computers under attack from viruses, hacks and zombie bots. The threats to commercial information systems are more severe in scope and the impacts are immeasurably greater.
ISO 27005 threat categorization
Some threats must be taken more seriously than others. Moreover, it's important to categorize the broad range of threats to be certain that they are all being addressed. In turn, the controls necessary to combat them must be arrayed to provide the greatest level of protection consistent with both cost and risk. How does an information security professional determine the breadth and relative weight among the threats and corresponding controls?
The globally recognized guidance on the matter, the International Organization for Standardization, has issued ISO 27005:2008, "Information technology -- Security techniques -- Information security risk management." "The premise of ISO 27005 is that a risk assessment can be performed based as a process that determines the value of the information assets, identifies the applicable threats and vulnerabilities that exist (or could exist), identifies the existing controls and their effect on the risk identified, determines the potential consequences and finally prioritizes the derived risks and ranks them against the risk evaluation criteria set in the context establishment."
In other words, figure out what something is worth, what bad things can happen, and do something about those things in priority order.
Are all threats credible?
But not all threats are real in all circumstances. If one looks to ISO 27005 for guidance on the threats to consider (in Appendix C of that document), he will find that the list includes such matters as freezing, volcanic phenomena, electromagnetic pulses, remote spying, computer crime and terrorism. Some of these, to be sure, apply to some organizations, but there is very little exposure from volcanoes in Manhattan, freezing in Hawaii or terrorism in Sioux Falls, S.D. Threats may exist but not be credible, and therefore the controls applied to prevent, detect or recover from them are not credible either.
These stand out as examples of threats that can be disregarded. But what of threats that seem more credible, such as theft of media, tampering with software, software malfunction or abuse of rights? There is no purpose in differentiating them on the basis of likelihood; they are all quite rare.
Or perhaps they are only rare because of the controls in place. Would media be more likely to be stolen if tapes and other magnetic media were not kept in secure locations? Would software bugs be more likely to happen if there were no acceptance procedures? Of course they would. Those controls are put in place because it is understood that protection is needed to prevent bad things from happening; the controls are specific to the threats. Media libraries are not very effective in preventing programming problems, nor are acceptance procedures useful for stopping media theft. Threats drive controls, which must pass the test of credibility, not probability.
Threats and investment in controls
This is a fine academic distinction until real money has to be spent on real security, real recoverability, real controls. The priority of "derived risks" will depend on the cost of mitigating or eliminating them. Inasmuch as no single control (or combination for that matter) can eliminate all risk, decisions need to be made as to what budgetary priorities are, as well as risk.
In planning for and investing in its portfolio of protection, each organization must consider the reality of different threat types.
Returning to ISO 27005 and the list in Appendix C, there are high-level solutions to many of the high-level categories. For example, a single form of protection -- in this case an effective disaster recovery capability -- would be a credible control against four threat types listed in the standard: physical damage, natural events, loss of essential services or disturbance due to radiation. Credible, but not complete: the focus of all these threats is disruption of service, but service can be disrupted by unmentioned events such as distributed denial-of-service attacks (DDOS), for which a disaster recovery plan is of no use.
Should money be spent to deter all types of threats? Protection against disturbance due to radiation may (barely) pass the credibility test, but investment in preventing the effects of radiation might be better spent on encryption or identity management systems, which address more prevalent threats. Underinvestment in controls is an obvious problem, but overinvestment in preventing less credible threats is possibly worse: funds are diverted to adding unnecessary protection, leaving other threats insufficiently addressed.
Thus, the military is justified in using TEMPEST protection to prevent against the effects of an electromagnetic pulse produced by a nuclear explosion. For most commercial organizations, this threat is not credible while investments are necessary to manage other threats to operations, such as technical failures (equipment and software failure or malfunction, saturation of the information system, breach of information system maintainability).
In planning for and investing in its portfolio of protection, each organization must consider the reality of different threat types. Most would consider compromised information or functions and unauthorized actions to be credible threats. So are technical failure and physical damage, but some threats in each category (e.g., breach of information system maintainability, corrosion) can and usually are given less weight.
How to address threat credibility
None of the foregoing is meant to argue against risk or threat assessment. It is intended to make a case for an approach to threat assessment that:
- Eliminates wasteful spending on controls to prevent less-than-credible threats.
- Focuses attention on all credible threats, not just the most obvious ones.
- Balances investment in credible controls across a panoply of risks.
Risk managers and information security professionals should approach risk assessment as a means of directing investment towards controls that make the most sense in their environments. They should consider completeness in facing off against all credible threats, as well as protection in depth against those considered most consequential. Using guidance such as ISO 27005, they should ask themselves:
- Are all the threats to the organization's information systems identified? Those considered less than credible can be eliminated from consideration.
- Are there any threats that are not being addressed by the current set of controls? Failure to address a threat may be a reason to question its credibility.
- Which controls can be applied to the widest variety of threats? These, by and large, deserve the greatest funding.
- Which unaddressed threats would have the greatest consequences if not addressed? These deserve to be accepted by management (and perhaps be insured against) to generate additional investment in protection.
The baseball player Wee Willie Keeler advised that one should "hit 'em where they ain't." In terms of managing credible threats, it's better to hit them where they are.
Steven J. Ross, CISSP, CISA, MBCP, is founder and principal of Risk Masters Inc. Let us know what you think about the story: email firstname.lastname@example.org.
This was first published in October 2009