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 low-level implementation details.

Trust Model Overview​

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

These zones represent both:

  • the current state of the lab
  • the target architecture

Gaps between the two are explicitly acknowledged and tracked.

Trust Zones​

1. Public Exposure Zone (Heaven)​

This zone includes all components directly exposed to the Internet.

Examples:

  • VPS-01 (Documentation site, Reverse Proxy, Gitea - co-located)
  • VPS-02 (Dolibarr application stack)

Characteristics:

  • Direct Internet exposure
  • Primary attack surface
  • Minimal trust granted

Current limitation: Co-location of multiple services (Gitea + web content) increases lateral movement risk.

2. Application & Data Zone (Heaven - Transitional)​

This zone represents services processing business or sensitive data.

Examples:

  • Dolibarr application
  • MariaDB database

Characteristics:

  • Handles sensitive and business-critical data
  • Should be isolated from exposure layer
  • Currently not properly segmented

Known gap: Application and exposure layers are partially merged on VPS infrastructure.

3. Internal Core Infrastructure (Hell)​

This zone contains foundational infrastructure components.

Examples:

  • Hypervisor
  • Firewall / IDS
  • Internal network segmentation
  • NAS / storage systems

Characteristics:

  • No direct Internet exposure
  • High trust level
  • Critical dependency layer

This zone is high-value and must be strongly protected against lateral movement.

4. Administrative Zone (Hell - In Progress)​

This zone is dedicated to privileged access.

Target components:

  • Bastion (planned)
  • Admin workstation (planned)
  • SSH access paths

Characteristics:

  • Controls access to all critical systems
  • Requires strong authentication and traceability

Current state:

  • No fully enforced bastion model
  • Administrative access is still partially decentralized

This is one of the highest priority security gaps

5. Security Monitoring & Detection Zone (Hell - Planned)​

This zone centralises visibility and detection capabilities.

Examples:

  • Wazuh (SIEM)
  • Monitoring stack (Prometheus / Grafana)
  • Velociraptor (DFIR)

Characteristics:

  • Receives telemetry from multiple zones
  • Supports detection and investigation
  • Should limit outbound trust

Current limitation:

  • Logs are mostly local
  • No centralized correlation yet

6. Support & Control Services Zone (Hell - Planned)​

This zone includes operational support systems.

Examples:

  • Backup systems
  • Ansible control node
  • Internal CI/CD components (Gitea, Runner)

Characteristics:

  • Broad access across environment
  • Handles sensitive data and credentials

This zone is high-risk due to its operational reach

Segmentation Logic​

Segmentation in Scheol follows these principles:

  • separation of exposed vs internal systems
  • restriction of administrative paths
  • minimisation of inter-zone trust
  • use of controlled entry points (reverse proxy, bastion)
  • preference for unidirectional flows (logs, backups)

Current State​

Segmentation is:

  • Partially implemented
  • Clearly defined at design level
  • Incomplete in enforcement

Critical Security Flows​

1. Public Access Flow​

Internet → Reverse Proxy → Applications

  • Entry point is controlled
  • Backend isolation is not yet sufficient

2. Administrative Access Flow​

Admin → Infrastructure (SSH)

  • Intended: via bastion
  • Current: partially direct access

High-risk flow (linked to admin compromise scenarios)

3. Log Forwarding Flow (Planned)​

Heaven → Hell

  • Goal: centralised detection
  • Current: mostly local logs

4. Backup Flow (Planned)​

Systems → Backup Storage

  • Currently weak / incomplete
  • High priority for resilience

5. Deployment Flow​

CI/CD → Systems

  • Planned automation (Gitea / Ansible)
  • Not yet fully controlled or isolated

Known Limitations​

Current architectural gaps include:

  • co-location of services in exposed VPS environments
  • lack of enforced administrative isolation (no bastion yet)
  • absence of centralized logging and detection
  • incomplete backup strategy (no immutable/external backups)
  • limited enforcement of inter-zone restrictions

These limitations are:

  • intentional (learning + phased build)
  • documented
  • tracked as risks

Current Maturity​

Established​

  • clear trust zone model
  • identification of critical flows
  • separation between exposed and internal environments (logical)

In Progress​

  • administrative access model (bastion)
  • centralised monitoring and logging
  • improved segmentation enforcement

Planned​

  • full separation of exposure vs application layers
  • hardened inter-zone communication controls
  • integration with detection and response capabilities
  • alignment with risk scenarios and control framework

This page reflects both the current operational reality and the target security architecture, and will evolve as the lab matures.