Measuring the Risk of Not Managing Risk

Question

I've seen scenarios in which organizations don't invest enough in cybersecurity, are short-handed, and thus have a difficult time meeting the policy requirements defined within their Security Programs. I would assume that many companies don't properly invest in cybersecurity and that this scenario is fairly common.

My question is related to measuring risk of not meeting policy requirements. Measuring risk by performing a standard risk assessment is well defined: identify threats/vulnerabilities and assess the impact and likelihood of exploitation. But what about the situation where you don't know the likelihood/impact of vulnerabilities because you literally just don't have the manpower to perform a risk assessment across all of your systems?

In basic terms: how can you assess and properly communicate the risk associated with not following policy? For example, the risk associated with not performing risk assessments across each of your systems?

Any ideas? I find that communicating risk up the chain of command is the best way to get resources to tackle problems. Am I framing this incorrectly by thinking about it in terms of risk?

Answer 1

You are not using a useful risk assessment process, which is why you are having trouble coming up with a measure.

Importance of Inherent Risk

You are combining likelihood and impact with the mitigations (people, controls, policies, etc.). A risk assessment first assesses the risk without mitigations. This gives you your inherent risk. Sometimes you can assume some mitigations in inherent or a constant, so you can use that knowledge in your assessing of inherent risk. But, as you say, you can't assume that you have everything you need to mitigate.

Residual Risk

Your mitigations (people, controls, policies, etc.) reduce that risk level to a new level (hopefully a lower one), called residual risk.

Your assessment process needs to consider the impact of the mitigations carefully so as not to assume that those mitigations are always there.

Policies as Risk Mitigation

Policies are one of those mitigations. You should carefully consider the impact a policy has, or else you have a useless policy (or you copy/pasted it from some source online or an external expert who had ideas one day). So, you should already know the impact of not following a policy.

Risk Communication

You are correct that having the right information is the best thing you can do to improve your security posture and communicating to decision-makers. You need to communicate the gap between:

• inherent risk
• your current residual risk
• your target level of residual risk (a step most people forget about, because, no, you can't and shouldn't get all risks to "green" on a heatmap)

Specific Example

If you do not perform risk assessments on systems, then you have no means of effectively controlling the potential impacts on those systems (the risk assessment is a form of mitigation from the org perspective). So, then, you potentially have no controls against impacts, which means your inherent risks are considered to be your actual risks. Risk assessments on the systems help define how to lower your risks (impacts/likelihoods).

Answer 2

Although a little late to the party, here are my 2 cents (para-phrasing some parts of @schroeder's answer / comments above, with some secret sauce of my own.

1. Not following policy is NOT a risk. The risk is the reason why policy exists.

Taking your example of missing patches, you seem to be on the right path. Some additional things to do to qualify the risks:-

a - are those missing patches map to any CVE? If yes, are those CVE's exploitable? If yes, what is the impact (Remote code execution, server compromise, potential data leakage, etc.)? What are the pre-requisites for the exploit (pre-auth, post-auth, privilege escalation, etc.);

Your run-of-the-mill VA tool (e.g., nessus, nexpose, etc.) should give you data points on this.

b - how critical is the data (on the server with the missing patches)? if the server and data on it are not critical, are they connected to any machine which is (critical)?

c - What does your internal risk assessment methodology say about qualifying / quantifying the risk?

After you qualify / quantify the risk (it is always a scenario that is risky, never the vulnerability / threat / data), you can then state the absence of an existing control (policy) which is not followed (in this case), resulting in the risk scenario to be plausible.

Risk communication fails because the scenarios are not aligned with business, nor do they provide a context to it. e.g., unless a risk results in potential loss, business won't care.

And they would be right in doing so.