Assets, business values and supporting assets¶
What you'll be able to do in this chapter
- Distinguish business values from the supporting assets that carry them.
- Model both at a granularity that is useful for risk, neither too coarse nor too fine.
- Map supporting assets to business values, and to the controls that protect them.
You cannot assess risk to things you have not named¶
Every scenario in this Module is an attack on something. If you have not first said clearly what that something is, and why it matters, the analysis loses its business context. So the method starts where EBIOS RM's first workshop starts: by modelling what the organisation must protect. It draws a distinction that may seem theoretical at first, but is important throughout the Module: business values versus supporting assets.
Business values versus supporting assets¶
A business value is something the organisation needs in order to accomplish its mission: a key process, or a body of information, expressed in business terms. It is what a competent attacker would want to harm in order to hurt you, and what the organisation needs to achieve its objectives. It is not a server or an application. For Scaldimet, the business values include the continuity of the production line, the confidentiality of the OEM's design data, and the integrity of the manufacturing instructions that tell the machines what to make.
A supporting asset is the concrete element of the information system on which a business value rests: the servers, applications, networks, people and premises that carry it. The Beta SCADA system is a supporting asset; so is the ERP database, the site network, and the maintenance contractor's access path. Supporting assets matter precisely because they support business values, and an attacker reaches a business value through its supporting assets.
The distinction matters because it keeps the analysis connected to the business in both directions. Start from business values and you never lose sight of why a control exists (you protect the SCADA because the line's continuity depends on it, not because a checklist named SCADA). Map down to supporting assets and you know exactly where an attacker would actually strike. Confusing the two is how organisations end up protecting servers nobody needs while a critical process sits exposed.
| Business value (what matters) | Depends on these supporting assets (where attacks land) |
|---|---|
| Continuity of the Beta production line | SCADA, PLCs, the OT network, the maintenance contractor's access, mains power |
| Confidentiality of OEM design data | ERP and file stores, engineering workstations, backups, identity system |
| Integrity of manufacturing instructions | MES, the IT/OT interface, the staff who configure jobs |
The right granularity¶
The hardest practical skill here is granularity: how finely to model. Too coarse ("all IT") and the analysis says nothing useful. Too fine (every individual device and cable) can make the analysis unnecessarily complex and difficult to maintain. EBIOS RM is explicit that the aim in this step is not exhaustiveness but to retain only what is essential, so the study stays agile.
The rule of thumb that works: model supporting assets at the level at which a control could be applied and a scenario could land. "The Beta OT network" is a useful granularity, because you can segment it (a control) and an attacker can traverse it (a scenario). "Ethernet cable number 47" is not. This is also the granularity that lets you later connect each asset to the applied controls from Module 3, which is the whole point of the linkage this course is building.
Application: model Scaldimet's apex¶
On paper, write Scaldimet's three or four most important business values in business terms (not as systems), then for each list the supporting assets it depends on, at a granularity where a control could attach and a scenario could land. Check each item against the granularity rule (too coarse to attack, or too fine to protect?) and adjust. Draft your map before opening the model
Model answer (open after you've drafted yours)
Business values (business terms): continuity of production (the lines keep running and shipping); confidentiality of customer design data; ability to demonstrate compliance (the certificate that keeps the contract).
Supporting assets, per value:
-
Continuity → Beta's OT network and SCADA/PLCs; the MES; the site interconnection; the contractor's access path.
-
Design-data confidentiality → the ERP/PLM database; the drawing file shares; engineer workstations; email.
-
Demonstrable compliance → the evidence store, the applied-controls records, the SoA.
Granularity check: "the Beta OT network" is right (you can segment it, an attacker can traverse it); "all IT" is too coarse (nothing attaches to it); "PLC firmware v2.3 on line 4" is too fine (it buries the study). The result is a small, essential map. This provides the basis for the scenario analysis that follows.
Key takeaway
Scenario risk is always risk to something, so the method begins by modelling it. A business value is a mission-critical process or body of information expressed in business terms (the line's continuity, the design data's confidentiality); a supporting asset is the concrete system, network, person or place that carries it, and the place an attacker actually strikes. Starting from business values keeps controls tied to why they exist; mapping to supporting assets shows where attacks land. Model at the granularity where a control could attach and a scenario could land, kept essential rather than exhaustive, which is also the granularity that links each asset to the Module 3 applied controls.