Skip to main content

Environment Notes

Purpose​

This page captures operational context, constraints and practical decisions related to the Scheol Security Lab environment.

The objective is to:

  • document real-world constraints
  • provide context for architectural and security decisions
  • retain useful operational knowledge that does not belong in structured sections

This page is intentionally flexible, but must remain concise and relevant.

Scope​

This page includes:

  • infrastructure constraints
  • operational choices
  • technical limitations
  • environment-specific assumptions

It does not include:

  • formal architecture (Applied Security Architecture)
  • controls or security measures (Control Framework)
  • system or service descriptions (Inventory / Service Reference)

Core Principles​

1. Reality Over Perfection​

The lab reflects a realistic, constrained environment, not an ideal architecture.

Decisions are influenced by:

  • available hardware
  • cost constraints
  • time limitations
  • learning objectives

2. Transitional State​

Many components are:

  • partially implemented
  • temporarily simplified
  • planned but not yet deployed

This is intentional and documented.

3. Controlled Technical Debt​

Some design choices introduce known weaknesses, such as:

  • service co-location
  • lack of full segmentation
  • incomplete monitoring

These are:

  • acknowledged
  • tracked (Residual Gaps)
  • progressively addressed

Infrastructure Constraints​

Limited Hardware (Hell)​

  • single Proxmox host
  • no high availability
  • limited resource isolation

Impact:

  • constrained segmentation capabilities
  • shared risk across internal systems

Limited External Infrastructure (Heaven)​

  • small number of VPS
  • multiple services co-located

Impact:

  • increased attack surface concentration
  • dependency on configuration quality (reverse proxy, isolation)

No Dedicated Admin Workstation (Current)​

  • administrative access performed from personal machine

Impact:

  • weak separation between personal and administrative contexts
  • increased exposure risk (linked to R-003)

Operational Practices​

Documentation-Driven Approach​

  • all major components are documented
  • changes should be reflected in documentation

Limitation:

  • documentation may lag behind rapid changes

Manual Operations (Current State)​

  • deployments partially manual
  • validation mostly manual
  • monitoring partially manual

Impact:

  • reduced repeatability
  • increased risk of configuration drift

Progressive Automation​

  • automation planned via Ansible / CI/CD
  • not yet fully implemented

Security Posture Assumptions​

Exposure Awareness​

  • all public services are considered potentially exposed
  • misconfiguration is treated as a primary risk vector (R-001)

Trust Model​

  • internal environment is trusted but not secure by default
  • no implicit trust between zones should exist (target state)

Detection Limitations​

  • detection capabilities are limited and evolving
  • visibility is partial

Known Technical Limitations​

  • no centralized identity provider yet
  • no enforced bastion access
  • no centralized logging (planned)
  • backup strategy incomplete
  • segmentation partially enforced

These limitations are tracked in:

  • Residual Gaps
  • Control Status
  • Validation & Monitoring

Design Trade-offs​

Examples of accepted trade-offs:

  • simplicity vs isolation
  • speed of deployment vs security depth
  • cost vs redundancy

These trade-offs are:

  • documented in Security Design Decisions
  • linked to risk acceptance

Relationship with Other Sections​

This page supports:

  • Architecture → explains why things are the way they are
  • Risk Management → provides context for risk scenarios
  • Control Framework → explains constraints on control implementation
  • Validation & Monitoring → explains detection limitations

Governance Rule​

This page must remain concise and relevant.

Add a note only if:

  • it provides useful context
  • it cannot logically belong to another section
  • it helps explain a decision, limitation or risk

Avoid:

  • duplication
  • low-value notes
  • outdated information

Current Maturity​

At the current stage, environment documentation is considered useful but lightweight.

Established​

  • identification of key constraints
  • documentation of major limitations
  • alignment with real environment

In Progress​

  • refinement of operational practices
  • better linkage with risks and controls
  • improved consistency with architecture

Planned / Next Phase​

  • tighter integration with decision tracking
  • reduced gap between documentation and reality
  • improved operational discipline

This page provides practical context necessary to understand the lab beyond formal documentation.