Risk Modeling Methodology
Purpose
This page describes how documented threat scenarios are assessed and prioritised within Scheol Security Lab.
The objective of risk modeling is to transform documented exposure situations into structured risk entries that can support:
- prioritisation decisions
- control selection
- implementation planning
- validation logic
- auditability and documentation traceability
The primary output of this process is the Risk Register.
Scope
Risk modeling applies to all documented asset categories within Scheol Security Lab, including:
- business capabilities
- infrastructure assets
- platform assets
- information assets
This includes both currently implemented components and relevant planned components when their future exposure is already meaningful for architectural or governance reasoning.
Assessment Logic
Risk modeling in Scheol is performed after an asset and a threat scenario have already been documented.
Each risk entry is therefore derived from:
- a target asset or capability
- a documented threat scenario
- a set of potential impacts
- an estimation of likelihood
- an evaluation of the resulting risk level
- a documented treatment decision
This means that risks are not recorded as abstract concerns, but as evaluated consequences of plausible and documented situations.
Risk Evaluation Model
Each risk is assessed through two dimensions:
- Impact
- Likelihood
These two values are then combined to determine the resulting Risk Level.
Impact Assessment Model (EBIOS RM inspired)
The impact of a scenario is evaluated against five simplified criteria inspired by EBIOS RM:
- Confidentiality
- Integrity
- Availability
- Reputation
- Compliance
Each criterion receives a rating from Minor to Critical.
The highest rating among the five criteria becomes the overall Impact rating for the scenario.
| Impact Criteria | 🟩 Minor | 🟨 Moderate | 🟧 Major | 🟥 Critical |
|---|---|---|---|---|
| Confidentiality | Exposure of non-sensitive or public information | Limited leakage of low-sensitivity personal or internal data | Disclosure of sensitive internal or personal data | Large-scale exposure of highly sensitive data, credentials, or security-critical secrets |
| Integrity | Minor and reversible alteration of low-impact data | Alteration of non-critical configurations or operational data | Tampering with security-relevant configurations or trusted records | Compromise of core system integrity, trust anchors, or critical security configurations |
| Availability | Brief and low-impact service interruption | Outage affecting a single non-critical or limited-scope service | Service disruption affecting critical functions or multiple components | Major or prolonged outage, administrative lockout, or unrecoverable service disruption |
| Reputation | No visible external effect | Limited credibility or trust impact | Significant perceived reliability or professionalism impact | Major reputational damage affecting project credibility or stakeholder trust |
| Compliance | Minor internal documentation or control deviation | Weakness affecting expected governance or security posture | Clear gap against expected regulatory or control obligations | Serious governance or compliance failure with strong documentary or regulatory implications |
Likelihood Scale (Qualitative)
Likelihood reflects how plausible it is that a documented scenario could realistically occur in the context of the lab.
| Level | Description |
|---|---|
| 🟦 Rare | The scenario is theoretically possible but currently unlikely in realistic operating conditions. |
| 🟪 Unlikely | The scenario could occur, but would require specific conditions or failures to align. |
| 🟧 Possible | The scenario is plausible under current or reasonably expected conditions. |
| 🟥 Likely | The scenario is considered realistically expected if no additional controls are applied or if exposure remains unchanged. |
Likelihood is assessed qualitatively based on factors such as:
- exposure surface
- trust relationships
- administrative paths
- existing safeguards
- complexity of exploitation
- dependency weaknesses
Combined Likelihood × Impact → Risk Level
| Likelihood \ Impact | 🟩 Minor | 🟨 Moderate | 🟧 Major | 🟥 Critical |
|---|---|---|---|---|
| 🟦 Rare | 🟩 Low | 🟩 Low | 🟨 Medium | 🟧 High |
| 🟪 Unlikely | 🟩 Low | 🟨 Medium | 🟧 High | 🟧 High |
| 🟧 Possible | 🟨 Medium | 🟧 High | 🟧 High | 🟥 Critical |
| 🟥 Likely | 🟧 High | 🟧 High | 🟥 Critical | 🟥 Critical |
This matrix is used to produce a consistent and reviewable prioritisation model, not a mathematically precise prediction of real-world probability.
Its purpose is to support decision-making and documentation coherence.
Risk Treatment Logic
Once a risk level is assigned, a treatment decision is documented.
The four standard treatment options used in Scheol are:
- Accept – tolerate the risk with documented justification
- Mitigate – reduce the risk through safeguards or design changes
- Transfer – reduce direct ownership of the risk where relevant
- Avoid – remove the risky condition, dependency or exposure entirely
Treatment Decision Guidance
- Low → usually acceptable if documented and periodically reviewed
- Medium → requires contextual review and usually some mitigation or monitoring
- High → should normally trigger mitigation or structural reduction
- Critical → should not remain untreated without strong justification and explicit documentation
Risk Positioning in Scheol
Scheol does not aim to simulate a fully formal enterprise risk committee.
However, the documentation follows a deliberately structured posture:
- risks should be visible
- treatment decisions should be traceable
- significant exposure should not remain implicit
- architectural and governance decisions should remain defensible
The practical risk posture used in the lab can therefore be summarised as follows:
Low risks may be tolerated when documented.
Medium risks should be reviewed and justified.
High and Critical risks are expected to drive corrective action, redesign, or stronger control coverage.
Governance & Ownership
Risk modeling is maintained under the responsibility of the Security Role (Sec).
Supporting contributions may come from:
- Operations Role (Ops) for infrastructure and operational realities
- Development Role (Dev) for application, automation or implementation-related exposure
For documentation consistency, the Security Role is considered responsible for:
- maintaining the evaluation method
- reviewing risk entries
- documenting treatment rationale
- ensuring consistency between risks, controls and evidence logic
Review Cycle
Risk modeling should be reviewed when:
- a new infrastructure component is introduced
- a new service is exposed or reconfigured
- a trust boundary changes
- a significant administrative or identity path changes
- a control materially changes the exposure of an existing scenario
- a scheduled periodic review is due
Risk entries are therefore expected to evolve alongside both the infrastructure and the documentation model.
Current Maturity
At the current stage, risk modeling in Scheol Security Lab is considered partially established.
Established
- overall qualitative risk evaluation logic
- documented impact and likelihood model
- baseline risk matrix for prioritisation
- initial linkage between threat scenarios and risk evaluation
- treatment categories and review logic
In Progress
- broader coverage across implemented and planned components
- consistency of evaluation depth across all documented scenarios
- stronger traceability between risk entries, controls and validation activities
- more consistent use of treatment rationale and review cadence
Planned / Next Phase
- more complete population of the risk register
- stronger linkage between risk treatment and evidence collection
- improved support for validation-driven reassessment
- better integration with future audit and monitoring logic
This page is therefore intended to evolve as the lab becomes more complete, more interconnected and more formally documented.