Skip to main content

Security Design Decisions

Purpose​

This page documents key architectural and security decisions made within the Scheol Security Lab.

The objective is not to describe the infrastructure itself, but to explain:

  • why specific design choices were made
  • which risks they address
  • which trade-offs were accepted
  • how they are expected to evolve

Each decision reflects a balance between security, complexity, and practical constraints in a learning environment.

Decision Model​

Each decision is documented using the following structure:

  • Context - situation or constraint
  • Decision - chosen approach
  • Rationale - why this choice was made
  • Linked Risk - associated risk from the Risk Register (R-XXX)
  • Related Assets - impacted or concerned assets (A-XXX)
  • Risk Considerations - risks reduced and risks introduced
  • Status - Temporary / Transitional / Target
  • Next Steps - planned improvements

Key Decisions​

1. Mixed Exposure on a Single Public VPS​

Context Public-facing services (documentation, repositories) are currently hosted on the same exposed instance.

Decision Use a single VPS to host both static sites and development-related services.

Rationale

  • Simplifies deployment and management
  • Reduces cost and operational overhead
  • Enables rapid iteration during early lab stages

Linked Risk

Related Assets

Risk Considerations

  • Increased attack surface due to service co-location
  • Potential impact amplification in case of compromise
  • Dependence on service isolation and reverse proxy configuration

Status Transitional

Next Steps

  • Separate services across multiple instances
  • Strengthen isolation between exposed components
  • Reduce trust between co-hosted services

2. Progressive Trust Boundary Implementation​

Context The target architecture includes multiple trust zones, but not all are fully implemented yet.

Decision Adopt a staged approach to segmentation rather than enforcing full isolation from the beginning.

Rationale

  • Allows incremental deployment and validation
  • Keeps the environment manageable during early phases
  • Aligns with iterative, risk-driven design

Linked Risk

Related Assets

Risk Considerations

  • Temporary over-permissive communication paths
  • Increased exposure risk due to incomplete segmentation
  • Potential unintended access to internal services

Status In Progress

Next Steps

  • Enforce stricter inter-zone filtering
  • Review and harden reverse proxy routing rules
  • Align segmentation with critical assets and flows

3. Administrative Access Model (Transitional State)​

Context Administrative access is currently performed from a personal workstation.

Decision Allow direct administrative access during early stages.

Rationale

  • Practical constraint (no dedicated admin workstation yet)
  • Enables faster setup and iteration

Linked Risk

Related Assets

Risk Considerations

  • Weak separation between personal and administrative environments
  • Increased exposure of administrative credentials
  • Lack of centralized access control and auditability

Status Transitional (High Risk Accepted)

Next Steps

  • Introduce dedicated admin workstation
  • Deploy bastion host
  • Restrict direct administrative access paths

4. Local Logging with Planned Centralization​

Context Centralized logging infrastructure is not yet deployed.

Decision Maintain logs locally on systems with future centralization planned.

Rationale

  • Avoids blocking deployment on missing components
  • Keeps systems operational and simple at current stage

Linked Risk

Related Assets

Risk Considerations

  • Limited visibility on suspicious activities
  • Reduced detection capability
  • Risk of log loss or tampering on compromised systems

Status In Progress

Next Step

  • Deploy centralized logging solution
  • Implement log forwarding
  • Improve monitoring and alerting coverage

5. Absence of Reliable Backup Strategy​

Context No reliable backup mechanism is currently in place following the loss of provider snapshots.

Decision Operate temporarily without a complete backup solution while preparing a proper implementation.

Rationale

  • Infrastructure still being structured
  • Backup solution not yet deployed

Linked Risk

Related Assets

Risk Considerations

  • High risk of data loss
  • No recovery capability in case of compromise or failure
  • Critical resilience gap

Status Temporary (Critical Risk Accepted)

Next Steps

  • Implement external backup solution
  • Ensure backup isolation from production
  • Test restoration procedures

Decision Traceability​

Each decision is linked to:

  • one identified risk (Risk Register)
  • specific assets (Assets Inventory)
  • planned improvements

This ensures alignment between architecture, risk management and governance.

Evolution​

Security design decisions will evolve as:

  • new risks are identified
  • infrastructure matures
  • controls are implemented and validated

This page reflects the current architectural reasoning and will be updated as the lab progresses.