Problem

A common theme we encounter during the course of our engagements, is helping clients make the best possible decisions related to risk. Most of the time decisions are made with sub-optimal information or with significant gaps in knowledge.

Take for example the following:

• A firewall rule review, wherein decisions need to be made to keep, remove, or modify rules. In many cases there is insufficient information about the sources and destinations to determine what needs to be done with a rule.
• Deciding on risk mitigation actions requires a lot of knowledge about the assets under threat. In many cases, information is limited, making a disproportionate mitigation responses more likely.

 

Adding Context

The solution to these problems is to add context to decision making. Probably one of the areas where context is easily added is to the asset, as its largely under enterprise control. So, let’s consider assets here as systems that support a process (e.g., an OT system for manufacturing), or data (e.g., customer order data) collected during the course of operations.

Let’s break down a few sample problems.

The first one is a simple one. Say you have rule objects that are associated with two assets. In isolation, this offers no clue as to what to do with a rule.

 

 

Simply adding context about the status of an asset means you can make an easy decision to keep or eliminate a rule. Other cases could include attaching context on regulations (or internal standards) applying to assets and limiting communication between them to only allowed protocols.

A good example of this is PCI-DSS, which mandates that traffic into and out of the cardholder zone be limited to a known subset of secure protocols. See the illustration below:

 

 

Now, how about selecting a risk management response. What context is useful in guiding mitigation responses?

How about a few examples:

• The criticality of the asset to a business process. This will help in establishing the effective ‘budget’ for a response. The more critical process, the more money you can be expected to be allocated to secure it. This context is of course enhanced if it is quantitative, but that is a topic for another blog post.
• Vulnerabilities that the asset has. This is a fairly common one, and it does drive mitigation responses, usually the need to patch it. But consider the case of OT assets (the fact that it is OT is context), where vulnerabilities cannot be easily patched. The appropriate response in this case might be to deploy a compensating control instead of patching.
• Regulations that apply to the asset. This is especially important when it comes to data, as some types of data have stricter control requirements than others and thus constrain your possible choice of response.

Exercising your imagination, you could probably come up with a vast range of possibilities where context can help you make a more informed choice about a mitigation response.

 

Limiting Choices

What does it mean to make a ‘good’ choice? Consider that with unlimited choice options, there are likely going to be many more ‘bad’ choices than ‘good’ choices. So, consider a different point of view about what you are doing. What if every bit of context constrains your choices to some extent? Think about adding context as a means of prohibiting you from doing certain things.

Regulations are again a good illustration. Consider the firewall example from earlier, if you did not know that a particular rule was governed by PCI-DSS, you would happily accept it if it used prohibited protocols. However, knowing that it is, means you are prohibited from doing so.

Imagine, if you had full context about a particular risk, you would in effect have only one choice – the perfect choice. Obviously, this is not feasible, as the amount of context would probably be too large to manage. However, consider the degree to which you wish to include context about a risk to have a level of comfort that the decision you are making in relation to it is close enough to optimal to be effective.

 

 

Consider the series of diagrams above. Your aim is to set a direction from the red cross. Not to get to the green cross, but to just to set a direction to it. The vector from the green cross is the ‘optimal’ direction. Indicated by the black arrow.

1. With no additional context, you are free to choose any direction. There are many wrong choices.
2. Adding context will prohibit several directions, limiting your available choices.
3. Further context again limits your choices. Though not all the time, in some cases additional context might be irrelevant (i.e., if the second orange segment is entirely contained in the first orange segment, in which case it has added no value).

 

 

If you keep doing this, then eventually with enough context, you’ll pretty much have a segment that only contains the green cross. However, as explained earlier, this is probably infeasible, so ‘good enough’ will have to do.

As with most things in information technology, when adding context, scalability rears its ugly head. While many problems related to lack of context can be resolved at limited scale, anything beyond that becomes much harder.

Technology solutions to these problems do exist, and one that has impressed us greatly is the offering from Axonius. A platform purpose built for adding context.

 

However, there is still work to be done to understand how to maximise the value from context, and we would be more than happy to:

• Help you understand the types of problems your organisation has where additional context would enable you to make significantly better decisions.
• Help to determine what type of context would benefit your organisation the most.
• Help you determine where ‘good enough’ is good enough.
• Design and deploy solutions to add context at scale and at speed.

 

 

Comments are closed.