January 12

Security Friday Fast Fact: Risky Business (without Tom Cruise)

14  comments

By Ron Woerner

We experience risk simply by living.  It’s not about eliminating risks; it’s about knowing the risks you have and doing something smart about it. We need to take that approach both in our lives and in our business.

Risk Management is the essence of security.  The role Risk Management is to identify and assess the risks to business processes and work with the business owners or service providers to appropriately mitigate those risks.  We are all about identifying risks and finding appropriate strategies for managing the risk.

Here’s a simple equation:  RISK = IMPACT X PROBABILITY.

Once you see a potential risk, it is weighed against the burden or cost of reducing impact, probability or both.  Not every risk requires attention, but that doesn’t mean that risks can or should be ignored. Mitigation strategies include transferring the risk to another party, avoiding the risk, reducing the negative effect of the risk, and accepting some or all of the consequences of a particular risk. In ideal risk management, the risks with the greatest impact and the greatest probability of occurring are handled first, and risks with lower probability of occurrence or lower loss are handled later.

Risk management is about finding and solving problems. You can use the same risk equation and process for managing any risks or problem.  Ask yourself:
•    What am I trying to protect?  That is your asset.
•    What bad things can happen to it? This is the threats to the asset.
•    How much money could I lose should these bad things happen?
•    What are the weaknesses or vulnerabilities associated with the asset?
•    What am I already doing to reduce the risk?
The first three questions define the Impact and the last two define the probability.  Together they formulate the overall risk.

After you have asked and answered these questions, you can decide what you are going to do about it. This process allows you to prioritize and make knowledgeable decisions on risks, wherever you find them.
By working together, we all become stronger.


Tags


You may also like

Are you using frameworks properly?

Leadership and communication are actually layers, not levels

  1. Nice post Ron. Timely with Anton’s prediction about Risk Management this morning. A couple of things jumped out at me:

    “Here’s a simple equation: RISK = IMPACT X PROBABILITY.”

    A little too simple. Both the impact (loss) and probability of event are probability functions.

    “Once you see a potential risk…”

    To me, that’s kind of the crux of the matter, where you “see” risk. What you’re describing in the bullet list above isn’t really so much “Information Risk Management” as it is “Vulnerability Management” with likelihood and impact rating thrown in. Information Risk Management isn’t a Jaquith “Hamster Wheel of Pain.” In it’s most effective form, it is *learning to manage by risk* and not “best practices” or FUD (and I think you could make an argument that most best practices are FUD).

    So where do you “see potential risk”? Hint, it’s not in the asset. It is the entire business process, from beginning to end. Our networking background causes us think in such an asset centric approach, so we end up ignoring the big picture. This is why our OCTAVE and NIST “risk assessments” fail, they are asset centric, happen once every great while and their results sit on a shelf in a big binder gathering dust. OCTAVE and NIST simply deliver very little value other than a little help for prioritizing the results of a vulnerability assessment.

    Think of it this way, can you use the bullet lists above, or OCTAVE or FRAPP or NIST to evaluate the potential benefits of two different control strategies? Can you use them to assess the risk in S,C, & A processes or Policy Exception Handling? Not very well, no. The ingredients for use are there, no doubt. But they simply aren’t put together in a way that lends itself to completeness, consistency or effectiveness. IRM isn’t something you add to Vulnerability Management, it is something that should govern every action a security department makes.

  2. Nice post Ron. Timely with Anton’s prediction about Risk Management this morning. A couple of things jumped out at me:

    “Here’s a simple equation: RISK = IMPACT X PROBABILITY.”

    A little too simple. Both the impact (loss) and probability of event are probability functions.

    “Once you see a potential risk…”

    To me, that’s kind of the crux of the matter, where you “see” risk. What you’re describing in the bullet list above isn’t really so much “Information Risk Management” as it is “Vulnerability Management” with likelihood and impact rating thrown in. Information Risk Management isn’t a Jaquith “Hamster Wheel of Pain.” In it’s most effective form, it is *learning to manage by risk* and not “best practices” or FUD (and I think you could make an argument that most best practices are FUD).

    So where do you “see potential risk”? Hint, it’s not in the asset. It is the entire business process, from beginning to end. Our networking background causes us think in such an asset centric approach, so we end up ignoring the big picture. This is why our OCTAVE and NIST “risk assessments” fail, they are asset centric, happen once every great while and their results sit on a shelf in a big binder gathering dust. OCTAVE and NIST simply deliver very little value other than a little help for prioritizing the results of a vulnerability assessment.

    Think of it this way, can you use the bullet lists above, or OCTAVE or FRAPP or NIST to evaluate the potential benefits of two different control strategies? Can you use them to assess the risk in S,C, & A processes or Policy Exception Handling? Not very well, no. The ingredients for use are there, no doubt. But they simply aren’t put together in a way that lends itself to completeness, consistency or effectiveness. IRM isn’t something you add to Vulnerability Management, it is something that should govern every action a security department makes.

  3. Alex, Thanks for the comments. You make some great points.
    1. The risk equation I use is supposed to be simple, so it will be used. Have you ever seen a complex risk equation that was successfully used in an organization? This risk equation is also based on the “Hand” test from the Carroll Towing case of 1947 (see the Wikipedia entry: http://en.wikipedia.org/wiki/U.S._v._Carroll_Towing ).
    2. The bulleted list of questions is also known as “Potential Problem Analysis” and is not directly related to IT. (See Kent Blumberg’s post and template: http://kentblumberg.typepad.com/kent_blumberg/2006/09/potential_probl.html). That’s why I never used the term “Information Risk Management” in my post only Risk Management.
    3. The other risk methodologies fail because they are too complex and they’re IT-sentric. (Please include the Microsoft Security Risk Process in the list.) The idea of using the above methodology is to have the business identify the risk and determine it’s impact and probability. Then the cost of mitigation can be evaluated based on the cost of the risk. You can also chart the risks by putting Impact on the Y axis and Probability on the X axis. This allows you to prioritize risks by seeing the potential costs of each risk compared to each other.
    4. Vulnerability Management is a subset of Risk Management.

  4. Alex, Thanks for the comments. You make some great points.
    1. The risk equation I use is supposed to be simple, so it will be used. Have you ever seen a complex risk equation that was successfully used in an organization? This risk equation is also based on the “Hand” test from the Carroll Towing case of 1947 (see the Wikipedia entry: http://en.wikipedia.org/wiki/U.S._v._Carroll_Towing ).
    2. The bulleted list of questions is also known as “Potential Problem Analysis” and is not directly related to IT. (See Kent Blumberg’s post and template: http://kentblumberg.typepad.com/kent_blumberg/2006/09/potential_probl.html). That’s why I never used the term “Information Risk Management” in my post only Risk Management.
    3. The other risk methodologies fail because they are too complex and they’re IT-sentric. (Please include the Microsoft Security Risk Process in the list.) The idea of using the above methodology is to have the business identify the risk and determine it’s impact and probability. Then the cost of mitigation can be evaluated based on the cost of the risk. You can also chart the risks by putting Impact on the Y axis and Probability on the X axis. This allows you to prioritize risks by seeing the potential costs of each risk compared to each other.
    4. Vulnerability Management is a subset of Risk Management.

  5. “Have you ever seen a complex risk equation that was successfully used in an organization?”

    Depends on what you mean by “equation”. I think risk is best measured by a series of equations. If you want it to be done effectively, you’ll want to get deep into the workings of the Right Rev. Thomas Bayes and Monte Carlo. Not simple, but that’s what we have computers for.

    Kent’s stuff is nice, but it’s not “managing by risk”. In other words, if your CFO asks you “How much risk do we have?” Kent’s not going to get you very far except at a very, very high level of abstraction.

    On point 3, we’re very agreed. I’ve frankly ignored others (and some of them deserve no more than the cold shoulder).

    On point 4, I guess to some my thoughts is that yes, VM is a subset of IRM, but it’s only one over-represented subset. If you have something that’s really telling you “risk” it ought to be scalable enough to handle all your discreet issues as well as give you an idea of an aggregate picture.

  6. “Have you ever seen a complex risk equation that was successfully used in an organization?”

    Depends on what you mean by “equation”. I think risk is best measured by a series of equations. If you want it to be done effectively, you’ll want to get deep into the workings of the Right Rev. Thomas Bayes and Monte Carlo. Not simple, but that’s what we have computers for.

    Kent’s stuff is nice, but it’s not “managing by risk”. In other words, if your CFO asks you “How much risk do we have?” Kent’s not going to get you very far except at a very, very high level of abstraction.

    On point 3, we’re very agreed. I’ve frankly ignored others (and some of them deserve no more than the cold shoulder).

    On point 4, I guess to some my thoughts is that yes, VM is a subset of IRM, but it’s only one over-represented subset. If you have something that’s really telling you “risk” it ought to be scalable enough to handle all your discreet issues as well as give you an idea of an aggregate picture.

  7. The idea behind Risk Management is to think about the risks and make decisions based on those structured thoughts.
    “The greatest risk is when we stop thinking.”

  8. The idea behind Risk Management is to think about the risks and make decisions based on those structured thoughts.
    “The greatest risk is when we stop thinking.”

  9. As an executive general manager, I don’t care precisely how much risk we have. I just want to know that we have identified what could go wrong with our plans (or our systems), sorted out – roughly – which could have the biggest impact x probability, and taken action to mitigate those risks. I find that leadership groups, whether in IT or elsewhere, often develop stunning plans and then fail to ask what could go wrong. My approach, and the one outlined above by Ron, helps get folks past that and into action. And action is what turns big risks into smaller risks.

    Here’s the choice as I see it:

    1) Ignore risk entirely.
    2) Calculate risk to the tenth decimal point (which is not possibly anyway – that’s why they call it “risk” – it is uncertain) and never get around to taking any action.
    3) Get a rough estimate of risk and impact, then take action on the biggest issues to reduce overall risk.

    As a general manager, I’m going to push you to make choice #3.

    Ron hits it spot-on, in the last paragraph of his post: “After you have asked and answered these questions, you can decide what you are going to do about it.” The key is “do.”

  10. As an executive general manager, I don’t care precisely how much risk we have. I just want to know that we have identified what could go wrong with our plans (or our systems), sorted out – roughly – which could have the biggest impact x probability, and taken action to mitigate those risks. I find that leadership groups, whether in IT or elsewhere, often develop stunning plans and then fail to ask what could go wrong. My approach, and the one outlined above by Ron, helps get folks past that and into action. And action is what turns big risks into smaller risks.

    Here’s the choice as I see it:

    1) Ignore risk entirely.
    2) Calculate risk to the tenth decimal point (which is not possibly anyway – that’s why they call it “risk” – it is uncertain) and never get around to taking any action.
    3) Get a rough estimate of risk and impact, then take action on the biggest issues to reduce overall risk.

    As a general manager, I’m going to push you to make choice #3.

    Ron hits it spot-on, in the last paragraph of his post: “After you have asked and answered these questions, you can decide what you are going to do about it.” The key is “do.”

  11. Kent,

    First, I have an issue with your choice #3 above. As Ron says, impact is part of the risk equation. Second, I would argue that your approach is very nice, but again, unsophisticated for use by a CSO in executing IRM.

    For example if you’re CSO and called on to present your $12,000,000 security budget to the executive committee, and the CFO asks you “how much risk do we have” – you’ll be comfortable with answering her using the above? And what do you say when she asks, “If we give you $12mil, how much less risk do we have”?

    This level of unsophistication in your approach leads to several issues in applying it to IRM (as Ron is advocating).

    In IRM there are usually many separate “assets” that contribute to the overall business process. This process must be understood before you can truly identify applicable controls and their strength, vulnerability and various levels of impact for each attack scenario. Your outline advocates an asset centric approach. If you’re trying to determine risk in a discreet issue, like, oh, say, online banking, what is your asset? Is it the application? The database? The customer information? The money in the account? How about the user? Their workstation?… At some level, all these things are assets, with their own (and in the context of the process of online banking, aggregate) controls and weaknesses with many representing a point of attack for various threat communities. Now if you want to claim that the process *is* the asset, then fine. I can see working within that context (and would actually advocate it). Unfortunately, however, that definition flies in the face of commonly accepted risk assessment methodologies (OCTAVE, NIST) and definitions set out by the ISO.

    I also have a problem with the order in which you perform some of the tasks in your outline. In IRM, existing controls affect both probability and magnitude of loss. I don’t see how you can figure step 3 or 4 without considering 5 first. In terms of probability of loss, weaknesses must be taken within the context of your control framework or you have no idea if you’re even vulnerable to an actual threat event (moreover, as your outline has it, analysts would ignore concepts like defense in depth and asset/object inheritance). Existing controls also tend to have an impact on the factors that constitute IRM losses (response, replacement, productivity, fines/judgments, competitive advantage, reputation).

    Finally, there’s a disconnect in this entire article between “risk assessment” and “risk management”. Your nice 5 steps aren’t “risk management” at all – they are an assessment methodology. Risk management is just as much an understanding of how, where, and when to do risk assessment within the InfoSec process portfolio – and how to express that risk, as it is the simple development of mitigation strategies. In other words, true risk management consists of both analysis and synthesis functions.

  12. Kent,

    First, I have an issue with your choice #3 above. As Ron says, impact is part of the risk equation. Second, I would argue that your approach is very nice, but again, unsophisticated for use by a CSO in executing IRM.

    For example if you’re CSO and called on to present your $12,000,000 security budget to the executive committee, and the CFO asks you “how much risk do we have” – you’ll be comfortable with answering her using the above? And what do you say when she asks, “If we give you $12mil, how much less risk do we have”?

    This level of unsophistication in your approach leads to several issues in applying it to IRM (as Ron is advocating).

    In IRM there are usually many separate “assets” that contribute to the overall business process. This process must be understood before you can truly identify applicable controls and their strength, vulnerability and various levels of impact for each attack scenario. Your outline advocates an asset centric approach. If you’re trying to determine risk in a discreet issue, like, oh, say, online banking, what is your asset? Is it the application? The database? The customer information? The money in the account? How about the user? Their workstation?… At some level, all these things are assets, with their own (and in the context of the process of online banking, aggregate) controls and weaknesses with many representing a point of attack for various threat communities. Now if you want to claim that the process *is* the asset, then fine. I can see working within that context (and would actually advocate it). Unfortunately, however, that definition flies in the face of commonly accepted risk assessment methodologies (OCTAVE, NIST) and definitions set out by the ISO.

    I also have a problem with the order in which you perform some of the tasks in your outline. In IRM, existing controls affect both probability and magnitude of loss. I don’t see how you can figure step 3 or 4 without considering 5 first. In terms of probability of loss, weaknesses must be taken within the context of your control framework or you have no idea if you’re even vulnerable to an actual threat event (moreover, as your outline has it, analysts would ignore concepts like defense in depth and asset/object inheritance). Existing controls also tend to have an impact on the factors that constitute IRM losses (response, replacement, productivity, fines/judgments, competitive advantage, reputation).

    Finally, there’s a disconnect in this entire article between “risk assessment” and “risk management”. Your nice 5 steps aren’t “risk management” at all – they are an assessment methodology. Risk management is just as much an understanding of how, where, and when to do risk assessment within the InfoSec process portfolio – and how to express that risk, as it is the simple development of mitigation strategies. In other words, true risk management consists of both analysis and synthesis functions.

Comments are closed.
{"email":"Email address invalid","url":"Website address invalid","required":"Required field missing"}

Subscribe to our newsletter now!