Threat Scenario Modeling
Purpose
This page explains how threat scenarios are constructed and used within Scheol Security Lab.
Threat scenarios are used to translate asset exposure, trust relationships and security-relevant weaknesses into structured and reviewable risk situations.
Their purpose is not to predict every possible incident, but to document plausible and security-relevant paths of compromise, misuse, disruption or control failure.
Why Scenario-Based Reasoning
In Scheol, risks are not documented as abstract concerns alone.
They are approached through concrete and contextualized scenarios, because this makes it easier to understand:
- what could realistically happen
- what asset or function would be affected
- how a threat could materialize
- what the likely consequences would be
- and what kind of controls or safeguards should exist in response
This approach is inspired by scenario-driven risk analysis practices such as EBIOS RM while remaining intentionally simplified for the scale and purpose of the lab, and is already applied to scenarios involving exposed VPS, administrative access paths and internal service dependencies within the lab.
Scenario Construction Logic
Threat scenarios are generally constructed by combining the following elements:
- a target asset or capability
- a threat source
- a plausible attack or failure path
- an exposure condition or weakness
- a set of potential impacts
- an initial view of existing or missing safeguards
The objective is to document scenarios that are:
- realistic
- security-relevant
- specific enough to be actionable
- broad enough to support governance and control reasoning
Scenarios should not be written as vague generic statements such as “the system could be hacked”, but as structured situations that can later support risk evaluation and control decisions.
Scenario Structure
Each documented threat scenario should progressively include the following elements:
| Field | Description |
|---|---|
| Scenario ID | Unique identifier for traceability |
| Target Asset / Capability | The asset, system, function or information area concerned |
| Threat Source | External attacker, internal misuse, operational failure, environmental event, etc. |
| Scenario Description | Concise narrative describing what could happen |
| Attack / Failure Path | Plausible path through which the scenario could materialize |
| Exposure Conditions | Relevant weaknesses, dependencies or enabling conditions |
| Potential Impacts | Expected consequences from a confidentiality, integrity, availability or governance perspective |
| Existing Safeguards | Controls or design elements already reducing the scenario |
| Residual Concerns | Remaining weaknesses, gaps or uncertainty areas |
| Related Risk Entry | Link to the associated risk evaluation when applicable |
| Owner / Review Role | Role responsible for follow-up or documentation review |
This structure is intended to support both clarity and later traceability.
Example Scenario (Simplified)
Scenario ID: S-001
Target Asset: Gitea (VPS-01)
Threat Source: External attacker
Scenario Description: An attacker exploits a vulnerability or misconfiguration in a public-facing service to gain access to the host and pivot toward sensitive services.
Attack Path:
- Scan exposed services on VPS-01
- Identify vulnerable web component
- Exploit vulnerability to gain initial access
- Attempt lateral movement toward Gitea data or system-level access
Exposure Conditions:
- Co-location of public web services and Gitea on the same host
- Limited isolation between services
Potential Impacts:
- Unauthorized access to repositories
- Credential exposure
- Integrity compromise of deployed services
Existing Safeguards:
- Restricted SSH access
- Reverse proxy isolation (partial)
Residual Concerns:
- Insufficient service isolation
- Lack of centralized monitoring at current stage
How Scenarios Are Used
Threat scenarios are used as an intermediate layer between asset identification and risk evaluation.
In practice, they help support:
- qualitative risk scoring
- treatment and prioritization decisions
- control selection and traceability
- validation planning
- architectural security reasoning
- later evidence or review logic where relevant
This makes them one of the most important connective elements in the overall documentation model of Scheol. In this lab, scenarios are already used to identify risks related to exposed services, administrative access and service co-location.
For formal scoring logic, see Risk Modeling Methodology.
Current Maturity
A first set of concrete scenarios has already been defined and linked to the risk register, forming the initial basis for risk-driven decision making. At the current stage, threat-scenario documentation is considered partially established and still expanding.
Established
- overall scenario-based reasoning model
- baseline structure for documenting threat scenarios
- initial linkage with assets and risk evaluation logic
In Progress
- scenario quality and consistency across documented components
- coverage depth for exposed, internal and administrative paths
- better visibility of enabling conditions and residual concerns
- stronger linkage between scenarios, controls and validation activities
Planned / Next Phase
- broader scenario coverage across future infrastructure areas
- improved prioritization and review cadence
- more explicit support for evidence and audit-oriented traceability
This section is therefore expected to evolve as the lab becomes more complete and more interconnected.