Identifying control strategies that have the effect of ignoring threats

[scp93ch]

In the risk report, as being generated in the risk reporting tool, we need to be able to provide a list of abbreviated attack paths (root cause, intermediate cause), the uncontrolled consequence, the control strategy applied and the impact level and before and after likelihood, and risk levels.

Some of our control strategies are e.g. "ignore physical threats from world" and if such a strategy is used in a model then it may appear in the risk report the same as any other "proper" control strategy. We need to treat them differently in the risk report, either by putting them in a separate part of the report (e.g. "things we've ignored") or removing them altogether.

If there is no explicit way of identifying these "ignore something" control strategies, can we add one?

[scp93ch]

It occurred to me that the control strategies of this "ignore something" type are in a sense part of the ISO 27005 "Context Establishment" step, as illustrated in the overview paper:

In the way we implement the process, the scope of the analysis is reflected primarily in the assets and relations, but then (after validation) in these particular control strategies. The scoping aspect of the initial "Context Establishment" step in the ISO process can be understood as deciding the scope, which is then reflected in these different aspects.

[scp93ch]

An example of a risk report (CSV) is attached. The model is the following (also attached):

small-2-secure-router-2.6.csv

small-2-secure-router-2FW.nq.gz

So in this simple case, most of the lines are saying problems have been resolved by ignoring threats from the world. In the current output format (which is not finalised at all) I have just been using the control strategy label (in contrast to what I said earlier).

[mike1813]

If there is no explicit way of identifying these "ignore something" control strategies, can we add one?

The short answer is 'no', at least not within the current core model. These 'signalling' control strategies and controls work the same way as any other control strategies and controls. Indeed, some CSGs can be viewed as a signal or a real control. The 'uses no email' control strategy is a signal to ignore a modelling error threat reminding the user to insert an email client, whose omission will mean phishing attacks (and threat paths stemming from those attacks) will be ignored. However, it can also represent a policy that users do not have access to email when operating in specific roles (i.e., user accounts with the necessary privileges have no email address).

The longer answer is 'yes in principle' if the entity doing the identification is a human. We could mention in the description of either the control or control strategy that this is not a real security measure but an instruction to ignore this threat. This is already done for many control strategies, but each control strategy description refers to assets involved in threats it addresses, and is worded to make sense when viewed in conjunction with a threat (i.e., in Threat Explorer).

Some work would be needed to rephrase those CSG descriptions so they convey their more general significance, e.g., 'this means we're ignoring physical threats to hosts unless their location is specified explicitly'.

In your example, I see that you do use the description of each root cause or intermediate cause threat, but not that of each control strategy. Some work would also be needed to make use of the descriptions in the risk report.

[scp93ch]

@dgc this is the issue I mentioned 😄

[scp93ch]

I wasn't asking for rephrasing of CSG descriptions. What I thought would be useful was a new predicate on the CSG which says it is a "scope" CSG. The key example being "ignore physical threats from [wherever]". You would then, in your generated report want to list the scope CSGs at the top and exclude them from the risk report table.

For the "uses no email" CSG, as you say it could be a scope CSG or a policy CSG. Perhaps we'd solve that by having two CSGs which do the same thing and the user chooses to either apply "uses no email policy" or "Ignore threats from email" scope CSG?

Anyway, over to you and @dgc ....