The ISO 27005 risk management methodology standard has weaknesses when it comes to risk measurement. "Fuzzy math" theory can help fill the gaps.
ISO 27005, issued in 2005, filled a noticeable gap in the ISO 27000 series of standards. The standard is officially titled ISO/IEC 27005.2008, "Information technology -- Security techniques -- Information security risk management." It took the International Organization for Standardization three years to document the standards for the risk management methodology. Now, just as ISO 27005 is gaining traction, the same organization has issued a new standard, ISO 31000.2009, "Risk management -- Principles and guidelines." As a result, some bewilderment has been re-introduced to an already confusing topic.
There is a wide array of definitions of the word risk ISO 27001, despite calling for risk management, does not define the term at all. ISO 27001, containing the requirements for an information security management system, states clearly that an ISMS should "align with the organization's strategic risk management context," "establish criteria against which risk will be evaluated" and "identify a risk assessment methodology that is suited to the ISMS."
More on risk management
ISO 27005 defines risk as "potential that a given threat will exploit vulnerabilities of an asset or group of assets and thereby cause harm to the organization." ISO 31000 states that risk is the "effect of uncertainty on objectives." The definition I've previously used for risk, "the measurement of the uncertainty of harm to an asset or group of assets," falls between the two.
This disparity in the definitions of risk is explained to some extent by the fact that the goal of ISO 27005 is an ISMS, whereas ISO 31000 is a means to the end of enterprise risk management. This forces the issue as to whether information security risk is distinct from, a component of or subordinate to overall organizational risk. Clearly the risks to information are a subset of the risks to the enterprise, but the technical nature of both the threats and the vulnerabilities does distinguish them. Whether IT is different enough from rocket technology, brain surgery technology or nuclear power plant technology to justify its own standard is an excellent, but unanswered, question.
Thus, those attempting to build risk management into an information security program need to honor the standards set in ISO 27005, while simultaneously not contravening the requirements, or at least the intentions, of ISO 31000.
Managing and measuring risk with ISO 27005
The process of managing information security risk includes many overlapping and poorly differentiated steps (or clauses, to use ISO-speak):
- Context establishment
- Risk assessment
- Risk treatment
- Risk acceptance
- Risk communication
- Risk monitoring and review
What, for example, is the context of risk management if not the sum of all the other steps? Does not communication of risk include monitoring and reviewing? The most aggressively confusing section of ISO 27005 is the one on risk assessment, which includes risk analysis and risk evaluation. Risk analysis in turn is made up of risk identification and risk estimation. Some (but not all) of these terms are defined in the glossary, but in so arbitrary a manner that a perfectly valid alternative approach could use the same terms in a different way or use different terms altogether and still achieve the same objective: managing risk.
Missing from ISO 27005: Risk estimation
What does not appear in the standard is the measurement of risk. It is axiomatic that what cannot be measured cannot be managed. The omission of risk measurement from the standard is significant enough that, whether mentioned or not, it must be performed by anyone seriously attempting to manage risk. Measurement is addressed indirectly by risk estimation, in the same sense that all estimates are measurements of a sort, but not vice versa "About a foot" is not the same as "12 1/2 inches," as anyone who has ever had to cut window glass can testify.
The ISO 27005 standard recognizes the weakness of its estimation methodology:
An estimation methodology may be qualitative or quantitative, or a combination of these, depending on the circumstances. In practice, qualitative estimation is often used first to obtain a general indication of the level of risk and to reveal the major risks. Later it may be necessary to undertake more specific or quantitative analysis on the major risks because it is usually less complex and less expensive to perform qualitative than quantitative analysis.
All information security risks by definition are relatively rare and their effects are significant. If the risks were commonplace but insignificant, no standard would be needed to manage them. Thus, all qualitative estimates would show the magnitude of any information security risk to be "high" and the likelihood "low," to use the ISO 27005 standard's terms. But if all relevant risks are all estimated at the same level on the same scales, what value is there in the estimates?
The alternative is quantitative estimation. The ISO 27005 standard states this must be based on historical incident data, which, it says, has "the disadvantage [of] the lack of such data on new risks or information security weaknesses." In his influential book on risk, "The Black Swan," Nassim Nicholas Taleb wrote that "what you don't know is far more important than what you do know." Managing new risks and weaknesses is, or should be, the aim of risk management.
The difficulty of working with ISO 27005 is captured in its definition of risk estimation: "the process to assign values to the probability and consequences of a risk." Compliance with the standard means assigning values to the unknowable (likelihood) and the unknown (consequences). No wonder risk estimation is such a blunt tool for managing risk!
Fuzzy math and ISO 27005
The solution to applying ISO 27005 in a useful way lies in accepting that although measurement of risk cannot be precise, it can be accurate within defined boundaries. This is a form of estimation with rigor around the process. There is a methodology for systematically handling concepts that embody imprecision and vagueness: "fuzzy set theory."
This field of mathematics, devised by L. A. Zadeh in 1965, describes objects or processes that are not amenable to precise definition or precise measurement. It recognizes there are some aspects of human experience that cannot be expressed as absolute numerical quantities but rather as a range of possible values. Fuzzy set theory can be used as a technique to modify or amend the risk estimation methodology in ISO 27005.
In brief, the application of fuzzy math to risk management can be summarized this way:
- Ignore probability and replace it with the concept of credibility. If a risk is credible -- that is, it might realistically occur -- it must be managed.
- Find more reasonable qualitative terms than high, medium and low to measure consequences. These should communicate meaning without the need for precision. Fuzziness in thinking and reasoning processes is an asset because it makes it possible to convey a large amount of information with very few words. For example, the terms used to measure impact could range from total destruction, to loss of most of an asset, to loss of some of an asset, to loss of units of an asset, to inconsequential loss.
- Ensure definitions of qualitative terms are clearly stated and broadly accepted in general semantic terms, as well as within the confines of the risk measurement exercise.
- Use quantitative measures for confidence levels, not for dollar amounts or probabilities (number of events over time). In this case, confidence is an admittedly ambiguous term. Confidence is used in the mathematical sense of estimating a statistical parameter (as a mean or variance) that tends to include the true value of the parameter in a predetermined proportion of the time. In other words, the dominant value in a fuzzy set is used to establish the range of risk, minus absolute precision. It does not mean assuredness in the conversational sense. Theorist Taleb rails against assuming that the value with highest level of confidence will actually occur.
No doubt this is what the authors of ISO 27005 had in mind when they wrote the standard. A standard is not immutable, however, and its weaknesses must be addressed. Failing to do so will result in risk management practices that are based on biases and preconceived notions, not discernable evidence. The fact that the evidence is a little fuzzy around the edges, however, does not undercut the value of ISO 27005 for measuring risk.
Steven J. Ross, CISSP/MP, MBCP, CISA is a contributing writer based in New York City. Let us know what you think about the story; email firstname.lastname@example.org. Follow @ITCompliance for compliance news throughout the week.
This was first published in February 2010