What is a risk analysis?

A risk analysis is an approach which, within a given scope, enables you to understand your risks, prioritise them and adopt the right treatment plan.

No, a vulnerability scan report is not a risk analysis. People sometimes make the serious mistake of thinking that by listing a whole series of vulnerabilities, the job is done. Such a list may feed into a risk analysis, but it is neither its core nor an essential component (when I carry out an analysis on a project in its scoping phase, there are not yet any vulnerabilities in production).

What is the difference between a vulnerability and a risk?

• A vulnerability is a technical bug or an organisational flaw that causes or allows an unauthorised action, not intended in the normal operation of a system.
• A risk is an event that undermines the achievement of a system's objectives, potentially by exploiting a vulnerability in that system.

A vulnerability exists in its own right, whereas a risk always depends on one or more objectives. It is therefore highly contextual.

A lack of validation rules on form inputs, a weak password or the absence of two-factor authentication are vulnerabilities. But they do not necessarily lead to risks. Not requiring two-factor authentication for a user to access a standard online newspaper is rarely a risk for the organisation. Nor is an SQL injection systematically a risk: in fact, many of those identified in penetration tests have absolutely no impact on the proper functioning of the application.

A risk, for example, is: “Inability to pay employees' salaries” or “Massive leak of the personal data in the charity's donor database”. The language is not technical: it is business-oriented and crystal clear to any member of the organisation, especially senior management.

If a vulnerability does not clearly enable, with reasonable probability, a scenario with a significant impact on the organisation, then it is not a risk, or at most a negligible risk that is not worth mentioning in a risk analysis. It makes little difference to us that a vulnerability allows data to be extracted from a database if that data is public anyway!

A compliance analysis is a binary exercise: you take a list of questions or checkpoints and ask whether the subject of the study is compliant or not. It is fairly simple and mechanical. The main difficulty is that it can be tedious, depending on the size and complexity of the scope and the amount of evidence to gather.

The risk-based approach, on the other hand, requires genuine reflection and a real grasp of the context. Just as a vulnerability does not necessarily represent a risk, non-compliance with a point in a standard or in any question grid may have no impact for one organisation but a severe impact for another. Compliance questionnaires are, moreover, often based on potential vulnerabilities.

The quality of a risk analysis depends heavily on:

• a clear definition of the scope;
• a very good understanding of the context, the objectives of the stakeholders and the processes within that scope.

This is what then guides the whole study: you are not searching blindly for vulnerabilities but rather for feared events that could prevent certain objectives from being achieved. It is these feared events that will then make it possible to prioritise the vulnerabilities to be addressed.

A risk analysis should produce, at the very least, the following:

• a list of feared events / risks (not vulnerabilities);
• ratings of these risks, making it possible to rank them against one another in terms of their importance to the organisation;
• a treatment plan for these risks, with genuine prioritisation based on the ratings established.

The list of any vulnerabilities that could allow the identified risks to materialise is relevant mainly for determining the right measures to put in place. But it will not necessarily interest the business decision-maker reviewing the results of the analysis.

Any approach or study that produces these elements constitutes a risk analysis. So you do not have to follow Ebios RM to the letter to carry out a risk analysis.

In fact, a simple brainstorming session can already constitute a risk analysis. What matters is asking these questions:

• What events do I fear for the achievement of the objectives of this system and/or my organisation, regardless of any technical consideration?
• What countermeasures should be put in place to reduce the likelihood and/or impact of these events? (which also means asking how the identified risks could actually materialise, and therefore which vulnerabilities could be exploited)
• By what criteria should they be prioritised?

Well-known methods are nothing more than attempts to establish a more or less precise approach that serves as a guide in answering these questions. They are certainly valuable for saving time and providing inspiration for the methodologies you will put in place in your organisation!

But from there, everyone should be free to adapt these methods, or even create their own method suited to their context! The key is not to lose sight of the objective:

• identifying major risks that make sense to the business, to make communication with it easier and ensure the value of my risk analysis;
• establishing a treatment plan consistent with the context (objectives, budget constraints, regulations, corporate culture, etc.).

So no: “Doing a risk analysis” is not necessarily synonymous with “Doing an Ebios”. The Ebios RM method will, for example, be entirely suitable for a security accreditation in a context subject to strong regulatory constraints. On the other hand, in an organisation where the risk management culture is still emerging and which wants to introduce a quick risk analysis methodology for projects, applying the Ebios RM method could discourage project teams from building security in. Adaptations of Ebios RM or the definition of an ad hoc method are then called for.