Capstone: A second risk, end to end¶
What you'll be able to do in this chapter
- Run a single risk through the workshops in one place, from risk origin to treatment.
- Develop two different scenarios for the same feared event, from two different sources.
- Recognise when a risk is best treated by the socle and when it needs scenario-driven controls.
Why run one risk all the way through¶
Each earlier chapter took one step of the method and applied it to the same risk, the halt of the French production line. That taught each step, but it never showed one risk travelling through the workshops in a single place. This chapter does that, on a risk you have seen named but not analysed: the disclosure of the customer's design data.
It is a different kind of risk from the line-halt. The line-halt is about availability, treated by segmentation and measured by RTO and RPO. Design-data disclosure is about confidentiality, which cannot be recovered once lost. It also has more than one plausible origin, so this chapter develops two scenarios for the same feared event: an accidental leak by an employee, and a deliberate theft by an external group. The same feared event can arrive by very different paths, and the treatment has to cover both.
The socle (Module 3) and the object of study (Chapter 4.2) are already defined, so this chapter runs Workshops 2 to 5.
Application: two scenarios for one feared event¶
On paper, take the risk of customer design-data disclosure and work it through the method with two scenarios. Produce, in order:
- Workshop 2. The feared event and its severity, then two risk sources with their objectives: a non-deliberate internal source, and a deliberate external one.
- Workshop 3. A short macro chain for each scenario, from the source to the feared event.
- Workshop 4. A short technical path for each scenario, with the supporting asset and the weakness at each step, and a likelihood.
- Evaluation. Place both scenarios on the matrix from Chapter 4.5.
- Workshop 5. A treatment that covers both paths: the measures, each linked to an applied control, the expected residual, and who accepts it. Note which measures are shared and which are specific to one scenario.
- Recovery. State the RTO and RPO, or explain why they do not apply.
Then write one sentence on how the two sources led to different controls. Draft your answer before opening the model.
Model answer (open after you've drafted yours)
Workshop 2. Feared event: the customer's design data is disclosed outside Scaldimet. Severity: Critical (loss of the contract, loss of the customer's trust, legal exposure). Two sources:
-
Source A (non-deliberate, internal): an employee under deadline pressure, whose objective is to finish the work at home over the weekend. There is no intent to harm Scaldimet.
-
Source B (deliberate, external): an organised cybercrime group, whose objective is financial gain by selling the data on a criminal market.
Workshop 3, macro chains.
-
Scenario A: the employee moves the design files out of Scaldimet's controlled systems onto a personal cloud account to work at home. The data now sits on an unmanaged service. When that account is later compromised, the data is disclosed. The path runs through the employee's personal service, not through an attacker who targeted Scaldimet.
-
Scenario B: the group reaches the design data directly through Scaldimet's own perimeter, takes a copy, and sells it. The path is a direct attack, with no third party involved.
Workshop 4, technical paths.
Scenario A (accidental leak through shadow IT):
-
The employee copies design files from the PLM to a personal laptop. Asset: the design files. Weakness: nothing prevents copying design data to personal devices.
-
The employee uploads the files to a personal cloud account (for example Dropbox) to work over the weekend. Asset: the files, now outside Scaldimet. Weakness: personal cloud services are not blocked, and there is no monitoring of design-data leaving the environment.
-
The personal account is compromised later (a reused password, or a breach of the personal service), and the files are exposed. Asset: the personal account. Weakness: the data's confidentiality now depends on a service Scaldimet does not control, and the files were not encrypted in a way that limits their use once copied.
Likelihood: Likely. The behaviour is common under deadline pressure, and no control currently stands in its way.
Scenario B (deliberate external theft):
-
The group exploits a vulnerability on an internet-facing server. Asset: the internet-facing server. Weakness: the server is not patched within a safe window.
-
From that foothold, the group moves across the internal network to the PLM and design file shares. Asset: the internal network and the PLM. Weakness: the network is not segmented, and access to design data is broad.
-
The group copies the design files out and sells them. Asset: the design data. Weakness: large or unusual data transfers are not monitored.
Likelihood: Likely. Internet-facing servers are scanned continuously, the data is valuable to a motivated group, and the internal path is open.
Evaluation. Both scenarios are severity Critical (4). On the 4 by 4 matrix from Chapter 4.5, both land in the intolerable band, at likelihood Likely (3). One feared event, two intolerable paths to it.
Workshop 5, treatment. Option: reduce for both. Measures, each linked to a Module 3 applied control:
-
Shared (treats both paths): restrict access to the PLM and design shares to the roles that need it (access-control applied control); encrypt the design data so a copied file is of limited use without the keys (data-encryption applied control); monitor and alert on large or unusual movements of design data (data-monitoring applied control). Owner: the Alpha IT manager, CISO consulted.
-
Specific to Scenario A: a clear data-handling rule that design data must not leave managed systems, enforced by blocking uploads to unmanaged personal cloud services, supported by staff awareness (data-handling policy from Module 2, and a shadow-IT control). Owner: the Alpha IT manager. Note that this is largely socle work: the baseline should have prevented the copy in the first place, and the scenario simply made the gap visible.
-
Specific to Scenario B: patch internet-facing servers within a safe window (the ID.AM-08.2 applied control from Lesson 3.5.A) and segment the internal network so a perimeter foothold does not reach the design data (the segmentation applied control, PR.IR-01). Expected residual: severity stays Critical, but likelihood drops from Likely to Possible once access is restricted, data movement is monitored, personal cloud upload is blocked, servers are patched and the network is segmented. That moves both scenarios out of the intolerable band. Acceptance: the risk owner, and given Critical severity, formally the management body (Lesson 6, NIS2 Article 20).
Recovery. This risk has no RTO or RPO. Confidentiality cannot be restored once the data is disclosed, so there is no system to recover to a point in time. Its response is incident handling, contractual and legal notification (the NIS2 clock of Lesson 3.4 and the customer notification the contract requires), and limiting the damage with the customer. Recovery objectives apply to availability, not to confidentiality (Chapter 4.9).
How the two sources led to different controls. The same feared event came from a non-deliberate internal source and a deliberate external one, and each needed its own controls: the accidental leak is closed mainly by socle measures (data-handling rules, blocking shadow IT, awareness), while the deliberate theft needs scenario-driven measures (patching the exposed server, segmenting the network). Some controls, access restriction, encryption and monitoring of the data itself, reduce both. Treating the feared event meant covering every credible path to it, not just one.
Key takeaway
A single feared event can arrive by very different paths. Run end to end, design-data disclosure produced the same artefacts as the line-halt (sources and feared event, scenarios, a matrix placement, a treatment with owners and residual, an acceptance), but from two sources: a non-deliberate insider using shadow IT, and a deliberate external attacker. The accidental path is mostly a socle failure (data-handling rules and shadow-IT controls the baseline should already enforce); the deliberate path needs scenario-driven controls (patching, segmentation). Controls on the data itself, access, encryption and monitoring, reduce both. And like any confidentiality risk, it has no RTO or RPO, because a disclosure cannot be undone. Treating a risk means covering every credible path to its feared event.