Skip to main content

Control Definition

Purpose​

This page defines the set of security controls used within the Scheol Security Lab.

The objective is to:

  • translate risks into concrete and actionable controls
  • maintain traceability between risks, controls and implementation
  • support validation, monitoring and future audit activities

The catalog reflects controls that are actually implemented or realistically planned, not an abstract or exhaustive framework.

Control Philosophy​

Controls in Scheol are:

  • risk-driven → no control without a linked risk
  • pragmatic → adapted to the lab’s maturity and constraints
  • traceable → linked to risks, assets and validation methods

The goal is not completeness, but coherence and effectiveness.

Control Definition Model​

Each control is documented using a consistent and lightweight structure.

Required Attributes​

FieldDescription
Control IDUnique identifier (C-XXX)
NameShort descriptive name
ObjectiveWhat risk the control reduces
TypePreventive / Detective / Corrective
ScopeAssets, zones or flows concerned
ImplementationHigh-level description (no low-level config)
Related RisksLinked risk IDs
ValidationHow effectiveness is verified
StatusActive / In Progress / Planned
OwnerResponsible role (Sec / Ops / Dev)

Control Categories​

Controls are grouped by security function, aligned with both risks and architecture.

1. Identity & Access Control​

Controls related to:

  • authentication mechanisms
  • administrative access restriction
  • credential and secret management

2. Network & Exposure Control​

Controls related to:

  • service exposure
  • reverse proxy configuration
  • firewalling and segmentation

3. System & Application Hardening​

Controls related to:

  • system configuration baseline
  • service minimization
  • application-level protections

4. Monitoring & Detection​

Controls related to:

  • log collection
  • detection capabilities
  • alerting mechanisms

5. Backup & Recovery​

Controls related to:

  • data protection
  • backup integrity
  • restoration capability

6. Governance & Documentation​

Controls related to:

  • documentation quality
  • traceability
  • risk/control consistency

Control Granularity​

Controls must remain:

  • high-level enough to be readable and auditable
  • concrete enough to be actionable

What to avoid:

  • vague controls (“ensure security”)
  • overly technical controls (exact commands/configs)

Detailed implementation belongs to:

  • technical documentation
  • configuration management (Ansible, etc.)

Risk-to-Control Relationship​

Each control must be:

  • derived from a risk treatment decision
  • linked to at least one risk
  • scoped to specific assets or flows

This ensures a consistent chain:

Risk → Control → Implementation → Validation

Relationship with Architecture​

Controls are directly influenced by architectural decisions:

  • segmentation drives network controls
  • identity model drives access controls
  • exposure level drives hardening requirements

Controls must therefore remain aligned with the Applied Security Architecture section.

Practical Implementation Strategy​

At the current stage, the priority is to:

  • focus on controls addressing existing risks (R-001 to R-003)
  • avoid premature definition of controls for non-existent scenarios
  • progressively expand the catalog as new risks are introduced

This avoids:

  • unused controls
  • documentation drift
  • artificial complexity

Evolution​

The control catalog will evolve as:

  • new risks are identified
  • architecture becomes more structured
  • validation and monitoring capabilities improve

Future improvements include:

  • stronger validation methods per control
  • better linkage with monitoring signals
  • optional mapping to ISO 27001 / NIST CSF

Current Maturity​

The control catalog is considered early but controlled.

Established​

  • clear control definition model
  • alignment with current risks (R-001 to R-003)
  • initial categorization

In Progress​

  • definition of concrete controls for existing risks
  • linkage with assets and architecture
  • introduction of validation logic

Planned / Next Phase​

  • expansion with new risks and scenarios
  • improved validation and monitoring linkage
  • optional external framework mapping

The focus remains on coherence over completeness.