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 is 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 provide 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
Risk Origins (RO) Target Objectives (TO)