Skip to main content

Trust Boundaries & Segmentation

Purpose​

This page describes how the Scheol Security Lab environment is structured in terms of trust levels, exposure and segmentation.

Its objective is to explain how systems are separated to:

  • limit attack propagation
  • reduce implicit trust between components
  • control administrative access paths
  • support monitoring and incident response

This section focuses on logical security boundaries, not on low-level network configuration.

Trust Model Overview​

The environment is organised into several logical trust zones, reflecting different levels of exposure and sensitivity.

These zones are not always fully isolated yet, but they provide a target structure used to guide architectural decisions and future improvements.

Main Trust Zones​

1. Public Exposure Zone​

This zone includes all components directly exposed to the Internet.

Examples:

  • Public VPS hosting documentation platforms, reverse proxy and source code management
  • Public-facing application servers (e.g. ERP)

Characteristics:

  • Directly reachable from the Internet
  • Highest exposure to external threats
  • Minimal trust granted to incoming traffic

This zone is considered untrusted by default and is treated as the primary attack surface of the lab.

2. Public Application Zone​

This zone represents application logic and services handling business or sensitive data.

Examples:

  • ERP application (Dolibarr)
  • Source code management platform (Gitea)

Characteristics:

  • Processes sensitive or business-critical data
  • May be exposed indirectly through a reverse proxy
  • Should not be directly accessible beyond required entry points

At the current stage, this zone is partially merged with the Public Exposure Zone, which is identified as a known architectural limitation.

3. Internal Core Infrastructure​

This zone contains the foundational components of the environment.

Examples:

  • Hypervisor and virtualization layer
  • Firewall and network segmentation systems
  • Internal DNS and directory services
  • Storage systems (NAS, backups)

Characteristics:

  • High level of trust
  • Not exposed to the Internet
  • Critical for overall system integrity and availability

This zone is considered highly sensitive and must be strongly protected from both external and lateral movement.

4. Administrative / Privileged Zone​

This zone is dedicated to administrative access and privileged operations.

Target components:

  • Bastion host
  • Dedicated administrative workstation
  • Privileged access paths (SSH, management interfaces)

Characteristics:

  • Controls access to all critical systems
  • Requires strong authentication and access restrictions
  • Should be isolated from standard user environments

At the current stage, this zone is not fully established, as administrative access is still partially performed from non-dedicated environments.

This is identified as a major maturity gap.

5. Security Operations & Monitoring Zone​

This zone centralises detection, monitoring and incident response capabilities.

Examples:

  • SIEM and log management platform
  • Monitoring and alerting systems
  • Threat detection and forensic tools

Characteristics:

  • Receives telemetry from multiple zones
  • Should not initiate unnecessary connections to other systems
  • Supports detection and investigation activities

Data flows into this zone are primarily unidirectional, reducing the risk of lateral movement from monitoring systems.

6. Support & Control Services Zone​

This zone includes operational support systems required to maintain and evolve the environment.

Examples:

  • Backup systems
  • Automation tools (Ansible)
  • CI/CD platforms and runners
  • Internal development services

Characteristics:

  • Broad access to multiple systems
  • Often handles sensitive data or credentials
  • Requires controlled and auditable access

This zone is considered sensitive due to its operational reach.

Segmentation Logic​

Segmentation in Scheol is designed to reduce unnecessary trust and limit the impact of compromise.

The main principles applied are:

  • Separation of exposed and internal systems
  • Restriction of administrative access paths
  • Limitation of direct communication between zones
  • Preference for controlled entry points (reverse proxy, bastion)
  • Use of unidirectional flows where possible (logging, monitoring, backup)

At the current stage, segmentation is partially implemented, with a clear target model but incomplete isolation between some components.

Key Security Flows​

Several flows are considered critical from a security perspective:

  • Log forwarding (Heaven → Hell)
    Centralisation of logs from exposed systems to internal monitoring platforms.

  • Administrative access (Admin → Infrastructure)
    Intended to be restricted through a bastion and dedicated workstation.

  • Application exposure (Internet → Reverse Proxy → Backend services)
    Public access routed through controlled entry points.

  • Automation and deployment (CI/CD → Systems)
    Controlled interactions used for deployment and configuration management.

These flows are progressively being secured and documented to improve traceability and control.

Known Limitations​

At the current stage, several limitations affect the effectiveness of segmentation:

  • partial mixing of public and sensitive services in exposed environments
  • absence of a fully isolated administrative zone
  • incomplete centralisation of identity and access control
  • limited enforcement of strict inter-zone communication policies

These limitations are known and explicitly tracked as part of the lab’s evolution.

Current Maturity​

At the current stage, trust boundaries and segmentation in Scheol Security Lab are considered partially established.

Established​

  • high-level definition of trust zones
  • initial separation between exposed and internal components
  • early segmentation through firewalling and network design
  • identification of critical security flows

In Progress​

  • clearer enforcement of separation between application and exposure layers
  • implementation of a dedicated administrative access model
  • improved control over inter-zone communication
  • centralisation of logging and monitoring flows

Planned / Next Phase​

  • stronger isolation of public-facing services
  • full implementation of bastion-based administrative access
  • improved identity and access management integration
  • more granular segmentation aligned with risk scenarios and control requirements

This section is therefore expected to evolve as the architecture becomes more structured and mature.