This sums-up my notes on the EBIOS Risk Manager methodology. I host both the original version and the official english version here :
EBIOS : Expression des besoins et identification des objectifs de sécurité (english : Expression of Needs and Identification of Security Objectives)
Big picture
5 main steps (workshops) :
Recapitulative table for each Workshop and use case :
Identifying cycles
Two main cycles can be distinguished during the whole assessment.
-
Strategic Cycle Approach the environment as a whole entity and ecosystem. It will be closely linked to Governance and aimed at defining a security posture. The audience target is mainly Management, non technical business owners, CISO.
-
Operational Cycle Zooming on the defined scope. We’re talking about implementation and concrete security measures once the risks have been identified. This targets Security Engineers, project managers and architecture IT people.
The idea is to use the strategic cycle with the Workshop 1 and 2 to prepare the operational cycle. By assessing the context in its entirety and pinpointing the Risks, you can then focus down on the different narrower scopes and elaborate the operational cycle.
Scope and Security Baseline
Main Objectives
This is structured in the following points :
Pretty much everyone is involved since it is the first defining step for the methodology. Both Business and Technical members are needed. Mandatory check is to state the need that reunites everyone for a meeting. Once that’s defined, the goal is to identify each people function and responsibility until the end of the study. To do so, creating an responsibility assignment matrix is recommended. At this step, it is essential to identify who is the person accountable for accepting the residual risks at the end of the study.
Residual risks acknowledgment
At the end of the study’s assessment and application, all risks can’t factually be eliminated. Residual risks can’t be the results of external scope impacts as they wouldn’t get considered in the study. A residual risk can be :
- Accepted : The risk is considered improbable or low enough to be kept as is. This choice can be made (not exhaustive):
- if the financial costs for the fix is substantially higher than the eventual loss.
- if you have no range of control on the matter (eg. company partners who refuses to act).
- Refused : The risk is too probable and impactful to be accepted. No sufficient measure can be leveraged to reduce the risk in the context, be it due to financial, technical, structural or organisational constraints. In this case, the goal of the study can’t be met.
Note that since the methodology works in cycle, identified refused risks will result in going back to the appropriate workshop.
Business assets
Since this is the first workshop, we must look for the customer’s contextual need regarding security after identifying the business assets. This term is particularly broad and is separated into Mission, Business process and Information. Some given example illustrate well the idea :
| Category | Business asset | Need for security |
|---|---|---|
| Mission | Global Transport Service Continuity | Availability : The core purpose of the organization must be maintained. |
| Business Process | On-line reservation cancelling service | Availability / Integrity : The function works and processes correct data. |
| Business Process | Deployment phase of a project | Integrity : Ensure transition to production is not compromised. |
| Information | Customer Information ; results of R&D work | Confidentiality : Preventing unauthorized access to sensitive data. |
| Information | Know-how in designing aeronautical parts | Confidentiality : Protecting the intellectual property advantage. |
These assets are defined to establish a clear direction for everyone, be it technical or business population. A proper first definition is key to express supporting assets later on.
Group information ; Rank according to security needs
The goal remains to identify the major business assets considered essentials and sensitive. If some assets are not considered essentials and retained, they should be grouped. Otherwise, inherit the measures that will be proposed later.
Timeframe
Pinpoint the expected duration for the study with workshop-level granularity. It is particularly important to take standards and regulatory frameworks into consideration.
Supporting Assets
Objective and needs have been discussed previously. Now we’re looking into the scope purposes, processes, and supporting assets. These are the technical resources that leviate your defined business assets. For each of the aforementioned, multiple supporting assets can be identified.
For example :
- Customer Information is stored in databases, in servers, managed by database administrators.
- Deployment phase of a project is tied to the development CI/CD pipeline and IT infrastructure (grouped for Prod servers) and managed by DevOps and Developers.
From now on, you can’t have a proper global view of the whole business context since you didn’t look for the operational scenarios. Business assets and associated supporting assets can be supplemented later on as you explore the scope in depth.
A clear definition of the first workshop can be created and visualised using the following format :
Feared Events
Here comes a very important part of the work we’re doing. Feared events are tied to Business assets in our work methodology, and aim at pinpointing harm the organisation might suffer. For it to be the most explicit possible, you want to leverage the usual CIA triad and more :
- Confidentiality
- Integrity
- Availability
- Proof / Traceability
- global impact on the business asset
A feared event’s severity depends on the business asset combined with existing regulations and potential impact. For example, GDPR compliance obligations tend to escalate the impact level of feared events involving personal data. Every time you assess a feared event’s severity, it should be tied to tangible consequences to facilitate the understanding of the potential harm.
Much like assessing a CVSS score for a vulnerability during a pentest, a structured approach is applied to feared event, evaluating specific criteria for each aforementioned type of impact.
Here are the two tables examples provided in E-BIOS RM documentation :
Security Baseline
Regarding compliance, the study must align with security references standards. The security measures tied to these standards must be systematically applied throughout the scope and methodology. This means ensuring that Regulatory and Legal Requirements are met as well as Sector-specific standards (eg. PCI-DSS).
If the scope needs to be ISO 27001 compliant for example, you will need to consider it throughout the study.
End goal of an audit / implementation
While standards and regulations can be a requirement tied to the client’s context, they are also often the primary objective to reach .
Already existing product
If the goal of the study is to create or define a product / solution, we’re effectively mapping needs. Otherwise, we’ll look into the implementation status for every standards and constraints, and point out existing gaps. The methodology provides a simple table to illustrate the concept :
We're not doing risk analysis yet
For now, the goal is to define the project scope, needs, assets and security standards.
While it is tempting for technical profiles to immediately link a supporting asset or a gap to a potential risk. We can start to process that as a background process but it is not yet relevant to the current workshop.
Risk Origins
This workshop is shorter than the others. We established the business assets and missions along with feared events. Now we want to evaluate the risks origins that could alter and impact the assets and their associated objectives.
These are called Risk Origins / Target Objectives : RO/TO.
Note
A single Risk Origin can have multiple Target Objectives. The scope and complexity of the study will define how many RO/TO you will work with.
The key question driving this workshop : who or what can infringe upon the missions and business assets identified in workshop 1, and for what purposes ?
To answer it, review the categories of risk origins and for each one, determine the attacker’s profile and what types of objectives they are after. Risk origins are typically characterized by three criteria :
- Motivation : what drives them toward this specific target ?
- Resources : financial means, technical skills, attack infrastructure available
- Activity : are they currently active in the perimeter, the sector, or a similar industry ?
These criteria allow you to assess the pertinence of each RO/TO pair. The goal isn’t to be exhaustive, it’s to identify the most relevant ones. 3 to 6 RO/TO pairs are generally sufficient to develop strategic scenarios without drowning in combinations.
Cover your business assets
One of the keys to success is searching varied categories of RO/TO pairs to have a differentiated panel of attacker profiles. Make sure you don’t leave any blind spots : the risk origins selected should collectively cover the organisation’s business assets as widely as possible.
The output of this workshop is a mapping of risk origins, along with a prioritized list of RO/TO pairs carried forward into Workshop 3, and a secondary list for surveillance. EBIOS provides us with an example :
Strategic Scenarios
Workshop 3 shifts the perspective from what could happen to how an attacker would actually get there. The ecosystem is the central concept here.
People involved in this workshop are :
- Business teams
- Functional architects
- CISO
The ecosystem includes all stakeholders that orbit the studied object and participate in carrying out its missions : partners, subcontractors, subsidiaries, cloud providers, etc. Modern attack paths increasingly leverage the most vulnerable links in this ecosystem rather than attacking the target directly. A well-informed risk origin will follow a logic of least effort and go for the weakest link.
The workshop has three steps :
Ecosystem digital threat mapping
For each stakeholder in the ecosystem, assess their threat level with regards to the studied object based on two axes :
- Exposure : dependency (how much does the studied object rely on this stakeholder ?) and penetration (how deep is the stakeholder’s access into the system ?)
- Cyber reliability : maturity (what is the stakeholder’s security level ?) and trust (what contractual and audit mechanisms are in place ?)
The combination of these scores produces a digital threat mapping that visually positions each stakeholder in one of three zones : watch, control, or danger. From this, you select the critical stakeholders : those likely to serve as relevant attack vectors due to
- privileged access
- vulnerability
- exposure.
Example of digital mapping, following the existing example we’ve been through :
Selection is a governance decision
The mapping and scoring provide decision support, but the final selection reverts to project governance. A stakeholder in the control zone may be set aside if the context and the nature of the risk origins make it irrelevant. That decision needs to be documented and justified.
Developing strategic scenarios
Using the RO/TO pairs from Workshop 2 as a starting point, construct high-level attack paths called strategic scenarios. The approach is deductive ; from the attacker’s standpoint, ask :
- Which business asset(s) do I need to target to reach my objective ?
- Which critical stakeholders in the ecosystem have privileged access to those assets and could serve as an entry point or relay ?
A strategic scenario describes the sequencing of events a risk origin would generate to reach its target. Events can be intermediate (affecting the ecosystem) or final (feared events for the studied object). Each strategic scenario is assessed in terms of severity, which corresponds to the severity of the feared event(s) it produces.
Keep it high level
Strategic scenarios should not be excessively detailed. The goal is to identify the most relevant entry points, dissemination relays and attack vectors, not to describe the technical implementation. That comes in Workshop 4. In general, 1 to 3 attack paths per RO/TO pair are enough.
The provided example is quite self sufficient and explanatory, there’s no point in detailing it here, you can read it in the provided resources. Here the expected outcome for a strategic scenario :
Security measures on the ecosystem
The work done in this step often exposes structural vulnerabilities in the ecosystem. Before moving on, translate the most critical ones into security measures aimed at reducing the intrinsic threat level of critical stakeholders. These measures often have governance implications, involving contracts, audits, or dependency reduction.
The example given uses the identified resources used in the strategic attack path and map them out along the appropriate security measures :
And as a consequence, the previously shown visual can be updated after security measures have been enforced :
The ecosystem security measures defined here, combined with the technical measures from incoming Workshop 4, feed directly into the Security Continuous Improvement Plan (SCIP) in Workshop 5.
Operational Scenarios
Workshop 4 zooms in from the ecosystem level to the supporting assets. Where Workshop 3 described what path an attacker would take, Workshop 4 describes how they would execute it technically. For this workshop, CISO and technical team are recommended to participate, especially a cyber security expert if possible.
Each strategic attack path selected in Workshop 3 maps to one operational scenario in Workshop 4. The operational scenario diagrams the methods of attack the risk origin could use to carry out the strategic scenario, structured as an attack graph or kill-chain-style sequence. Graphs are particularly useful for such workshops, since it allows anyone to pinpoint any misunderstood concept, part of the chain etc…
The provided example is a waterhole attack and the graph seems relevant in my opinion :
Several attack sequencing models can be used as a framework. Lockheed Martin’s Cyber Kill Chain being the most widely referenced. The approach should identify the critical supporting assets that serve as entry vectors, exploitation targets, or propagation relays.
Adjust granularity to your context
The level of detail of operational scenarios should match the maturity of the organisation and the depth of analysis required. A macroscopic approach (e.g. “WannaCry-type attack”) can be appropriate for some scopes ; a more refined sequence is necessary for sensitive or certified systems.
Building the scenarios
Construct each operational scenario from the corresponding strategic attack path, using the IT system mapping (application and logical infrastructure views). For each scenario, identify :
- The methods of entry (phishing, exploitation of pre-existing access, supply chain compromise, insider…)
- The lateral movement and propagation techniques
- The final action reaching the target (data exfiltration, production disruption, labelling alteration…)
Prioritize methods of least effort for the risk origin. Avoid generating an excessive number of attack combinations. A representative panel of supporting assets is more useful than exhaustiveness. A resulting attack graph can look like this :
The MITRE framework can be a great resource if you wish reproduce a step by step attack scenario with a more technical perspective. It also is pretty useful to map out each phase and thus identifying elementary scenarios.
After defining relevant attack scenarios, we look to assess which ones are the most likely to be exploited, using the RO profile from Workshop 2 and the security baseline from Workshop 3. A talk with the technical team can be (though not mandatory) relevant to assess the feasibility and probability from each exploitation step in an attack scenario, as well as the exposed vulnerable scope mentioned.
Evaluating likelihood
For each operational scenario, assess its overall likelihood, which reflects its probability of success given the risk origin’s resources and motivation on one side, and the organisation’s security baseline and ecosystem vulnerability on the other. This can be done through the sum of “elementary likelihood” by evaluating each step probability in an operational scenario. By doing so, you might dig into technical evaluation and precise contextual checking. Once each step is done, taking a step back on the scope will reveal the overall likelihood.
The likelihood scale used in the methodology :
| Level | Label | Description |
|---|---|---|
| V4 | Nearly certain | The risk origin will certainly reach its target. Likelihood is very high. |
| V3 | Very likely | The risk origin will probably reach its target. Likelihood is high. |
| V2 | Likely | The risk origin could reach its target. Likelihood is significant. |
| V1 | Rather unlikely | The risk origin has little chance of reaching its target. Likelihood is low. |
| The provided example states the likelihood given for each attack path kept, having considered the current state of the company security posture : |
Severity stays from Workshop 3
Note that the severity of an operational scenario corresponds to the severity of its associated strategic scenario, assessed during Workshop 3. Likelihood is the only new dimension assessed here.
At the end of Workshop 4, each risk scenario has a severity (from Workshop 3) and a likelihood (from Workshop 4). This is the input to Workshop 5.
Workshops 3 and 4 are iterative
During Workshop 4, you may identify vulnerabilities or attack paths that weren’t visible at the strategic level. This can lead to updating or supplementing strategic scenarios from Workshop 3. Allow for up to two iterations between workshops 3 and 4, but avoid overcomplicating the analysis.
Risk Treatment
Workshop 5 brings the whole study together. Where the previous workshops were about understanding and assessing risks, this one is about deciding what to do with them. As we’ve seen it in the beginning of this note, the workshop is cyclic. If our workshop 5 conclusion is deemed insufficient (be it related to risk definition, severity assessment, scope considerations), we can start again on the appropriate workshop to refine our work.
Participants are the same as Workshop 1 : top management, business teams, CISO, IT department. The risk treatment decisions carry organisational and sometimes financial weight. Management buy-in is not optional here.
Summary of risk scenarios
Start by positioning all risk scenarios on a risk mapping using severity (y-axis) and likelihood (x-axis). This initial mapping (before any treatment) gives a clear visual of where the organisation stands and makes it easier to prioritize. This is a common methodology for every risk analysis, which is often presented as follow :
Review coverage of the feared events from Workshop 1. If some feared events of significant severity were not addressed in any risk scenario, there may be a blind spot. A coverage matrix between feared events and risk scenarios helps identify these gaps and decide whether an iteration of workshops 2, 3 and 4 is warranted (as explained in the first paragraph).
Risk treatment strategy
For each risk scenario, agree on a treatment decision based on its risk level :
| Risk level | Acceptability | Decision |
|---|---|---|
| Low | Acceptable as is | No action required |
| Moderate | Tolerable under control | Follow-up in continuous improvement, actions over medium and long term |
| High | Unacceptable | Risk reduction measures must be taken in the short term. Otherwise, all or part of the activity is refused. |
Then define the security measures corresponding to each treatment decision. Each scenario must raise the question : which elementary phases of the attack chain would be most useful to disrupt ? Prioritize securing the elementary actions with the highest likelihood and the critical supporting assets that appear most frequently across scenarios.
Security Continuous Improvement Plan (SCIP)
Document all treatment measures in a Security Continuous Improvement Plan (SCIP), structured over time. The SCIP favors a progressive elevation of the organisation’s security maturity. It’s a living document, not a one-shot deliverable.
This is probably the most important part of the work so far, and the one which will be most likely to trigger a cycle on previous workshops since it is close to a restitution with every actions to be taken. The provided example is as follow :
Opinion
As you can see, we find the security measures we defined in Strategic Scenarios. The risks have been made explicit through their respective operational scenarios. We get back to a RAM Matrix by assigning responsibilities to each Security measure. This is a sensitive part of the work since you have to identify (or ensure the people involved in the actual work do it) who’s in charge of the right task.
NOTE that none of these above states the exact technical remediation to apply. Although anticipating difficulties in the matter is mentioned, this is where a technical skill can make a great difference in the capability to provide accurate and fine grained insight on constraints and direction for these security measures. Understanding the technical aspect will also be an advantage to assess the cost/complexity and expected duration, as you would when providing a pentest report with remediation propositions.
Residual risks
After applying the treatment measures, assess and document the residual risks. For each :
- Describe the residual risk including remaining vulnerabilities and aggravating factors
- Map it to the feared events from Workshop 1
- List existing and additional treatment measures
- Record initial and residual severity, likelihood, and risk level
- Note any particular monitoring measures
Represent residual risks on the same grid as the initial mapping to make the evolution visible. This residual risk mapping becomes the reference document for accreditation commissions and management reviews.
It is important to consider you don’t “delete” a risk but only reduce its severity and likelihood through remediation.
A vulnerability can be patched, but its associated risk doesn’t disappear. Imo, that thinking process is mandatory to a proper evaluation of any system, as any stake implies risk(s) by definition. Without going into the philosophical topic, having that distinction in mind (between deletion and mitigation) is fundamental to risk assessment and conformity in general.
Residual risks can be accepted
Not every residual risk will be brought down to an acceptable level. Management may decide to maintain a high residual risk when treatment cost exceeds benefit or when no viable measure exists in the current context. This decision must be documented and owned by whoever is accountable for accepting residual risks identified back in Workshop 1.
Framework for monitoring risks
The last step is setting up the governance structure for ongoing risk monitoring. Define steering indicators that make it possible to verify the effectiveness of the measures taken and their suitability relative to the threat landscape. Quantitative and qualitative data (relevant ones) are part of the system dynamic incoming topic tied to GRC, as well as how to exploit it in governance.
Practically :
- Form a steering committee meeting every 6 months during ramp-up, every 12 months at cruising speed
- Track SCIP progress and indicator evolution
- Update the risk study according to the strategic and operational cycle durations defined in Workshop 1
- Trigger out-of-cycle updates in case of major events : new threat emergence, significant change in ecosystem or in the studied object
The combination of the SCIP, the residual risk mapping and the monitoring framework is what transforms EBIOS RM from a one-time study into a genuine continuous risk management process.