Skip to main content

Control Framework

Purpose​

This section describes how security controls are defined, structured, and managed within the Scheol Security Lab.

The objective is to:

  • translate identified risks into concrete control measures
  • ensure traceability between risks, controls, and implementation
  • support validation and progressive improvement

Controls are treated as practical and risk-driven mechanisms, directly derived from the current exposure of the lab.

What is a Control in Scheol​

A control is any measure that reduces the likelihood or impact of a risk.

Controls may be:

  • Technical - configurations, system hardening, access restrictions
  • Operational - procedures, workflows, administrative practices
  • Organizational - governance rules, ownership, documentation

Each control is expected to be:

  • clearly defined
  • linked to one or more risks
  • implemented or realistically planned
  • verifiable at a basic level

Control Approach​

At the current stage, the control framework follows a risk-first approach:

  • controls are defined only when a risk is identified
  • priority is given to real exposure, not theoretical coverage
  • implementation is incremental and aligned with lab maturity

This avoids over-engineering and ensures that controls remain relevant and actionable.

Simplified Control Lifecycle​

Controls follow a lightweight lifecycle:

  1. Identification Derived from a specific risk

  2. Definition Description of the control objective

  3. Implementation Applied to the system or process

  4. Basic Validation Verification that the control is present and functional

  5. Improvement (when needed) Adjusted based on observed gaps or evolving risks

This lifecycle is intentionally simplified and will evolve as the lab matures.

Risk-to-Control Traceability​

Traceability is a core principle.

Each control should be:

  • linked to at least one risk entry
  • associated with specific assets or components
  • supported by minimal documentation or configuration reference

This allows:

  • understanding why a control exists
  • ensuring consistency with the risk model
  • identifying missing or weak protections

Control Scope (Current State)​

At the current stage, controls focus primarily on:

  • administrative access protection
  • exposure reduction (network / reverse proxy)
  • application-level security (basic hardening)
  • initial logging and visibility

Other domains (backup, SIEM, CI/CD security, etc.) are recognized but not yet fully implemented.

Relationship with Architecture​

Controls are directly influenced by the architecture:

  • exposed services require stronger access and filtering controls
  • lack of segmentation increases the need for hardening
  • absence of bastion increases administrative risk

Controls are therefore defined as compensating or reinforcing mechanisms based on current architectural gaps.

Framework Alignment​

The control framework is informed by common standards such as:

  • ISO/IEC 27001
  • NIST Cybersecurity Framework

However:

  • no formal compliance is claimed
  • no exhaustive control coverage is expected at this stage

These references are used only as guidance, not as strict requirements.

Evolution​

The control framework is expected to evolve progressively:

Current Focus​

  • defining controls for identified risks
  • ensuring minimal traceability
  • implementing practical safeguards

Next Steps​

  • expanding control coverage as new risks are introduced
  • improving validation mechanisms
  • strengthening linkage with monitoring and detection

Current Maturity​

At the current stage, the control framework is considered early but structured.

Established​

  • risk-driven control definition
  • initial linkage between risks and controls
  • practical implementation mindset
  • basic traceability

In Progress​

  • consistency of control definition
  • alignment across assets and scenarios
  • initial validation practices

Planned / Next Phase​

  • broader control coverage
  • stronger validation and monitoring integration
  • improved traceability (risk → control → evidence)

This section is designed to grow alongside the lab while remaining aligned with its actual maturity.