Risk Modeling Methodology
Objective
Provide a structured, repeatable approach to identify, analyse, and prioritise risks within the Scheol Lab environment. The primary output is a maintained Risk Register that feeds downstream compliance activities (GDPR DPIA, ISO 27001 internal audit, NIST CSF reporting).
Scope
Risk modeling applies to all assets documented in the Scheol Lab asset model, including:
- Infrastructure assets (virtualization hosts, network appliances, external hosting infrastructure).
- Platform assets (identity management, monitoring platforms, automation tools, documentation systems).
- Information assets (configuration data, credentials, backups, logs, and personal data).
- Business capabilities supported by the infrastructure (remote access, monitoring, automation, documentation governance).
Risk Scenario Construction
Risk scenarios are derived from the interaction between three elements:
- Asset - the system, platform, or data potentially affected.
- Threat event - the action that could exploit a vulnerability.
- Threat source - the actor or origin of the threat.
Example structure:
Threat source → Threat event → Affected asset → Impact
Example:
External attacker → Exploitation of exposed service → Public VPS → Loss of service availability
Impact Assessment Model (EBIOS RM inspired)
The impact of a scenario is evaluated against five EBIOS RM criteria (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 data (public info) | Leakage of personal data with limited scope | Disclosure of sensitive PII (health, finance) | Mass breach of highly‑sensitive data (credentials, trade secrets) |
| Integrity | Minor data‑corruption easily fixed | Alteration of non‑critical configs | Tampering with security‑critical configs (firewall, LDAP schema) | Manipulation of core system binaries or cryptographic keys |
| Availability | Brief hiccup (less than 5 min) - no business impact | Outage (less than 1 h) affecting a single service | Outage (1‑4 h) impacting multiple critical services | Complete loss of service (more than 4 h) or permanent data loss |
| Reputation | No noticeable effect on stakeholders | Limited negative press or internal complaints | Significant media coverage, loss of customer trust | Catastrophic brand damage, regulatory sanctions, market‑share loss |
| Compliance | Minor internal‑policy deviation (no regulator) | Breach of a non‑mandatory control, minor audit finding | Violation of a statutory requirement (e.g., GDPR Art. 5) with possible fine | Serious non‑compliance → heavy penalties, enforcement actions, loss of certification |
Likelihood Scale (Qualitative)
| Level | Description |
|---|---|
| 🟦 Rare | Event is highly unlikely ; may never occur. |
| 🟪 Unlikely | Could happen, but probability is low. |
| 🟧 Possible | Reasonably expected to occur at least once. |
| 🟥 Likely | Expected to occur frequently. |
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 |
Risk Treatment Decision Flow
- Is the risk rating ≤ Low? → Accept (document justification).
- Is the risk rating = Medium? → Mitigate if the cost‑benefit analysis shows a favourable ROI, otherwise Accept with monitoring.
- Is the risk rating ≥ High? → Mitigate (implement controls) or Transfer (insurance, outsourcing) if mitigation is impractical.
- Is the risk source avoidable? → Avoid (remove the vulnerable service or asset).
Risk Appetite Statement: Low risks may be accepted with minimal monitoring. Medium and higher risks require mitigation, transfer, or formal acceptance by the risk owner.
Governance & Ownership
- Risk Owner - Security Role (Sec).
- Subject‑matter experts - Operations (Ops) for infrastructure controls, Development (Dev) for application‑level safeguards.
- Approval - Risk register approval is performed by the Security Role acting as the CISO function. When personal data is involved, the Security Role acts as the Data Protection Officer function.
Review Cycle
Risk analysis is updated when:
- New infrastructure components are added.
- New services are exposed.
- Significant configuration changes occur.
- Periodic risk-assessment reviews.
Methodological References:
- ISO 27001 - Risk management and asset governance.
- NIST CSF - Asset management and monitoring.
- ISO 31000:2018 - Risk management principles.
- GDPR - Personal data protection obligations.
- EBIOS RM - Risk analysis methodology.