May 18, 2022
To start off this series on Security with Intent, I considered multiple different entry points before settling into tackling risk management as the intro. I certainly intend on broaching topics such as Security Technology, Compliance, Scope Creep, Governance, Metrics, Staffing…I have a number of topics and the list seems to grow the more thought I put toward the concept. However, at heart I am a self-declared risk management nerd so why not start with the area that I feel can be the most challenging for many organizations when it comes to understanding and applying intent.
Before we get too far it’s important to be clear with nomenclature. There are way too many people who either forget or just don’t know the difference between a risk, a threat and a vulnerability. Whatever the reason, some even use these terms interchangeably when discussing topics related to risk management. However, it is critical to level set on meaning of these terms in order to have a fruitful discussion about risk management. For the sake of simplicity, we’ll use the following definitions for each:
Threat: A circumstance or event that can cause harm or adverse impact.
Vulnerability: A flaw or weakness that can be exploited to allow harm or adverse impact to occur.
Risk: A measurement of impact from and likelihood of a threat event occurring.
Now that we’ve established base definitions for these terms we can start to explore a bit more on why intent is not aligning for some when it comes to performing risk management.
Assessing Risk
This area of risk management is usually the entry point for a lot of organizations but also where there can be a lot of confusion and misguidance. Services firms label their simple gap assessments as risk assessments, technology platforms claim risk awareness and lending to the assessment of risk, managed services firms claim a role in evaluating risk – none of which usually incorporate any aspect of the criteria laid out in the definitions above. It is no wonder people and organizations are confused with all of the highly creative marketing efforts that lack substance and reality.
Confusion aside, one of the first considerations in assessing risk that one needs to determine is scope or scale of what you are going to assess. From a simplistic view, the more assets and threat event types that are included in a true assessment of risk, the more complicated and costly it is likely to be. I would dare say impractical the larger the scope and scale in most situations. Here, one should lean on the intent for the risk assessment to really dial in the scope.
For example, if you’re looking to conduct a risk assessment to meet a regulatory requirement, you need to be asking what data is the regulation concerned about (if it’s not explicitly stated but usually is) and does it state specific threat events that need to be evaluated? In most cases you don’t need to focus on data or systems that fall outside of that regulation’s focus so obviously taking data/systems out of the equation where you can is the prudent thing to do to limit complexity. While most regulations and/or standards don’t tend to get too explicit with specific threat event types that should be included with a risk assessment, one can apply additional levels of intent to a periodic assessment to derive specific threat event types that make sense based on the current threat environment. I would recommend typically to limit to no more than three separate threat event types if possible for a single compliance driven risk assessment else costs can become significant and impractical due to the number of controls that will need to be evaluated against each event type.
In addition to scope and scale, another consideration that often comes into play is whether you need qualitative or quantitative results for your risk measurements. Going back to the regulatory requirement example, most do not require quantitative measurement so unless there is another requirement driving the need for quantitative results, the least complex approach would be to use qualitative risk ratings. I’m not a lawyer but I would hazard a guess that your General Counsel will likely prefer that you don’t provide quantitative results for this purpose as well.
However, if the requirement for a risk assessment is for internal consumption and you are questioning which method makes more sense, digging deeper into intent can help guide you in the right direction. While producing quantitative risk measurements come with quite a few benefits, it can also be a bit more complex and constrained process. While this may beg for an entirely separate dialogue and much more length to explain, for now know that choosing the quantitative path should not be taken lightly nor should the benefits of using quantitative measurements be undervalued despite the added complexity that can come with it.
In digging into intent on this topic it may be helpful to ask the following questions:
Who is my primary audience that will consume the assessment information?
Do they have a prescribed approach they are used to or asking for?
If not being driven by someone else, is qualitative risk data enough to satisfy the “why”?
Will the results be used to ask for [more] budget?
What level of quality can you produce with your qualitative data (e.g. are you considering specific threat events and some level of impact and likelihood even if not quantitative)?
As with most areas across security and risk management, I subscribe to the KISS principle when and where possible; performing risk assessments is no different. If you can meet your intent and take an easier path to meet it, it seems like that would make sense. But I’ve seen people who choose to take the hard path for whatever reason (ego, hubris, drama) and sometimes it’s because they simply don’t take the time to ensure they have a solid grasp on intent and let shiny objects take them down that hard road. Qualitative risk assessments in particular can be extremely valuable in a lot of situations, especially when they include elements as described earlier.
In coming segments I intend on covering “Building a Risk Management Program” and “Understanding Risk Response” as part of this Security with Intent – Risk Management series. I hope that what I’m sharing is helpful to some although I suspect for some of you this may be basic table stakes information.
Comments