CASES.LU

In depth articles

Why pool risk analysis?

Risk analysis consists of identifying the attack scenarios which would cause the most serious impacts, and putting forward a treatment to reduce their consequences.

The problem with this exercise lies in the need to be as exhaustive and precise as possible. If there are any oversights in terms of assets or any incorrect estimates of the probability of a given threat, any errors in assessing the ease of exploitation of vulnerabilities or even of the impacts caused, this will lead to incorrect conclusions…and to inappropriate security measures.

If this were to occur, the best thing that could happen would be to end up with excessively severe measures, while the worst case scenario would be to end up with measures that are poorly targeted and therefore ineffective. To be effective in carrying out a risk analysis, it is necessary to have a good view of the primary assets of the organisation – to fully understand the business processes, the information and their values.

Performing a risk analysis is unfortunately a very difficult task for small businesses, which are generally not capable of doing this with the resources available to them. Risk analysis is discriminatory through both its complexity and its cost.

However, an analysis of small organisations such as SMEs, town councils or even small-scale administrative bodies shows that business processes, the information processes and the support assets used are all fairly similar. This observation leads us to a pragmatic, simple solution. Within the same business sector, it is possible to pool risk analysis initiatives in order to make them accessible to even the smallest organisations, while maintaining the quality of the results generated.

For example, by analysing the business processes for town councils, we find that all town councils basically deal with the same forty-six processes and the same types of data. Examining things a little more closely, we see that they all use more or less the same secondary assets (with the same vulnerabilities) and are exposed to the same threats. Even the potential impacts are similar, especially legal impacts and the impact on reputation.

This has led to the idea of building contextual models describing:

  • business processes,
  • information,
  • potential impacts, and
  • typical attack scenarios existing within this context.

The people in charge of the various structures have no need to each repeat this exercise – they can gain access to a model specific to their own context. The only thing they still have to do themselves is to identify their own specific characteristics and enter them into the model.

The probability of threats, outside the scope of organisations, is estimated by context. In most cases, this estimate arises from the experience of CERT – Luxembourg experts working in threat monitoring. Organisations only have to input the probability of specific threats, such as targeted attacks for various reasons, such as revenge, for example.

The estimated ease of exploitation of vulnerabilities specific to support assets can usually be pooled. The experts in these metrics are generally suppliers. They regularly publish alerts regarding vulnerabilities in their products. To enable Luxembourg CERTs to monitor these vulnerabilities as well, they may make different contexts available at actual scale. Certain vulnerabilities will naturally be specific to certain structures and these will need to be entered by the organisations themselves, alongside experts assisting them in the process (e.g. disrepair of buildings).

The impacts are also often specific to different contexts. These can even be defined by a central body (a regulator). So the legal impact on town council A is the same as for town council B in the case of confidentiality breaches in citizen files. So even different impacts can be managed in a pooled way.

The pooling of this strategy not only makes risk analyses more objective and accurate, but also accessible to non-experts. Pooling also has the knock-on effect of substantially reducing costs, as it enables the implementation of effective and efficient security measures, thereby minimising the budget invested in security while simultaneously ensuring an acceptable level of security.

Pooling also lowers the legal risk (see legal aspects) for different organisations, as this strategy proves that the organisation manages security with due diligence, using state-of-the-art methods and tools as required by the Law of 2 August 2002 on data privacy.

This risk analysis strategy has to be more than a “one shot” measure. To be effective, the development of threats, vulnerabilities and impacts have to be taken into consideration. The risk analysis has to be repeated if any of these parameters change.

The Law of 2 August 2002 on data privacy is a good example of a change of impacts. The law introduced many new requirements in respect of private data processing security. Many companies have yet to incorporate this law into their procedures and are even unaware of its impacts. The new draft European regulation will go even further with these requirements and increase the potential legal impacts.

update above for GDPR