Risk management is something each of us do. Every waking minute, we evaluate risk and make decisions based on our assessment. The process is so automated, one has to really slow down to understand what’s happening.
For example, step through how you determine if it’s safe to cross the street.
Can’t eliminate risk
- Inherent Risk: The risk to your company in the absence of any actions you might take to alter either the likelihood or impact.
- Residual risk: The risk (also known as “vulnerability” or “exposure”) that remains after you have attempted to mitigate all inherent risks.
Residual risk is the one we need to worry about. We know to look both ways before crossing the street, but seldom look up — residual risk — missing the meteorite that’s headed straight for us.
Residual risk is the one that drives security experts and upper management nuts. Why that is may not be readily apparent. I initially thought — wrongly, of course — that it was based on trying to determine all possible risks. Nope, that’s not it.
We agree that risk cannot be eliminated; so, how hard does one try to reduce risk? When is the cost of reducing risk more than the cost of having the risk occur? That’s the tricky bit and what keeps risk assessors up at night.
Trying to understand, I waded through several papers posted on the website Risky Thinking. You know how that went. Then I found the paper, “Quantifying Risk and Cost of IT Security Compliance” by Ron Lepofsky, CISSP, CISM, and President of ERE Information Security and Compliance Auditors — an information security, audit, and compliance company.
IT risk management
I had my fingers crossed; Ron’s article appeared to focus on IT security. And that’s important. I’ve lost track of all the readers who have commented on how upper management is clueless when it comes to IT security: “All they want to know is how much it costs.”
After my first read, I knew Ron’s article was the real deal. It explained what speaks to upper management and how IT personnel should present it. Trouble is, I don’t speak risk management. So, not wanting to mess up, I contacted Ron.
Ron got back to me, mentioning he was on vacation. I had a sinking feeling, and a deadline looming large. He thankfully added, “If Internet access was available, I’d be glad to answer your questions.” Yes.
Kassner: Most IT managers are familiar with the concept of risk management, but that’s it. What are your suggestions?
Lepofsky: Managers should factor into their decision process what is deemed acceptable by upper management. I would consider the following as potential residual risks:
- Loss of revenue or production due to unavailability of production resource
- Time and effort to recover from a security related loss of production
- Damage to brand
- Regulatory compliance violations
- Privacy compliance violations
- Damage to client relationships
- Loss of intellectual, competitive, or proprietary information
- Uncaptured profits resulting from inability to demonstrate to clients a strong security process
Kassner: In the article, you mention the need to speak the language of upper management - ROI, essentially. Is it possible to assign a monetary value to a risk?
Lepofsky: Cost is the resulting impact on the business should a risk become a reality. To help determine potential costs, I’d suggest the following:
- Soliciting advice from financial management, lawyers, and risk management consultants
- Conducting a straw poll of stakeholders, each estimating the downside cost of an event
- Participating in fact-gathering surveys of similar businesses, each providing a cost analysis of a security event
- Purchasing statistical information from industry experts or industry associations
Kassner: After you get a handle on potential risks, you claim it’s important to determine the likelihood of an event happening using Annualized Loss Expectancy (ALE); could you explain how it works?
Lepofsky: ALE is the monetary loss resulting from an asset being compromised over an entire year and is calculated by multiplying SLE by ARO. Where:
- Single Loss Expectancy (SLE) is the expected monetary loss resulting from one instance from an asset being compromised
- Annual Rate of Occurrence (ARO) is the expected number of occurrences per year
Kassner: We now understand how to assign a monetary value to individual risks. The next order of business would be to figure out what it costs to prevent each risk. You mention:
“Security professionals are well acquainted with determining the costs of mitigation. Senior executives sometimes think they too are familiar with these costs, based upon ads they read about anti-virus and firewall technology.
The danger here is that it is too easy for all concerned to focus on technology as the primary mitigation for security and compliance.”
You then advise responsible parties to consider the following mitigation steps:
- Re-engineering processes, both technological and people processes
- Policy — people and technology
- Technical security
- Physical security
- People processes
- Training and awareness
- Third party auditing to verify effectiveness
You are right, nothing new there. But, your next comment was an “oh-duh” moment for me, and honestly, the reason I wrote this article:
“IT-security types are good at protecting, but not so good at convincing the powers-that-be why it’s necessary.”
The following graph seems like something management would appreciate. Would you explain what we are looking at?
Lepofsky: The graph above shows the relationship between two factors:
- Potential loss versus risk (percent chance of an event occurring)
- Mitigation cost versus risk (percent chance of an event occurring)
The optimal cost for spending on security is the amount determined by the intersection of the two lines. And the green curve above that is the total cost of risk where:
Total cost = cost incurred by losses + cost of mitigation
In planning a security budget, the goal is to minimize expenditures, so a corporation would ideally not spend more on mitigation than the expected potential losses. As a sanity check, the total costs associated with risk should definitely be greater than the mitigation costs, or something is terribly wrong with the financial planning of risk mitigation.
Kassner: I see one small problem — well, maybe not so small. I’m thinking of the small-shop, harried IT person. What advice can you offer them?
Lepofsky: This is a huge problem. It is unlikely that IT-security techs will have the time or resources to perform risk analysis when creating a budget.
First step is to determine if management has any documentation assigning risk priorities to company assets. If not, then I’d suggest making upper management aware of the benefits of risk analysis. At least then they can make an informed decision about security budgets. Whatever the decision, I would recommend the IT department ask for management’s resolution in writing.
Speaking the language of risk management and optimal cost points should make convincing upper management a lot easier. I’m anxious to try it; I’ll let you know how it goes.
I’d like to thank Ron for shedding light on a very complex subject and helping us IT types better understand upper-management speak.