Skip to main content

Architecture Principles

Purpose​

This page defines the core security principles used to guide architectural decisions within the Scheol Security Lab.

These principles are not abstract guidelines. They are used to:

  • support risk-informed design decisions
  • ensure architectural consistency over time
  • provide a reference for reviewing and evolving the environment

They must be understood in relation to:

  • identified risks
  • operational constraints
  • the current maturity level of the lab

Core Principles​

1. Risk-Driven Architecture​

Architectural decisions are driven by identified risks, not only by technical preferences.

Exposure, segmentation, access control and monitoring are shaped by:

  • threat scenarios
  • asset criticality
  • potential impact

This ensures that security efforts are prioritised where they matter most.

2. Security by Design​

Security is considered during system design, not added after deployment.

Key aspects such as:

  • exposure level
  • trust boundaries
  • access paths
  • recovery capabilities

are evaluated early in the design process.

3. Segmentation over Implicit Trust​

The architecture avoids flat networks and implicit trust relationships.

Systems are separated based on:

  • exposure (public vs internal)
  • sensitivity (critical vs non-critical)
  • function (administration, services, monitoring)

This limits lateral movement and reduces the impact of compromise.

4. Least Exposure​

Only necessary services and interfaces should be exposed.

This applies to:

  • public-facing services
  • internal service communication
  • administrative access paths

Reducing exposure directly reduces the attack surface.

5. Controlled and Auditable Administrative Access​

Administrative access is treated as a high-risk activity.

It must be:

  • centralized
  • restricted
  • auditable

The objective is to prevent uncontrolled privileged access and ensure traceability of sensitive actions.

6. Defense in Depth​

Security does not rely on a single control layer.

Multiple layers of controls are expected:

  • network filtering
  • access control
  • system hardening
  • monitoring and detection

This ensures that a single failure does not lead to full compromise.

7. Traceable and Justified Decisions​

Security-relevant architectural decisions must be explainable.

Each significant choice (exposure, placement, access model) should be:

  • linked to a risk or constraint
  • documented
  • reviewable over time

This supports auditability and continuous improvement.

8. Progressive Maturity​

The architecture is intentionally evolving.

Temporary or suboptimal decisions may exist due to:

  • resource constraints
  • implementation sequencing
  • learning objectives

These decisions are:

  • documented
  • acknowledged as transitional
  • planned for improvement

This principle ensures alignment between documentation and reality.

How These Principles Are Applied​

These principles influence decisions such as:

  • definition of trust zones and segmentation strategy
  • exposure of services in public environments
  • design of administrative access paths
  • placement of monitoring and logging capabilities
  • prioritisation of security controls

They are used as a reference during:

  • architectural design
  • risk analysis
  • security decision-making
  • documentation reviews

Current Maturity​

At the current stage, architectural principles are considered partially established.

Established​

  • clear risk-aware architectural intent
  • initial application of segmentation and exposure reduction
  • recognition of administrative access as a critical control point
  • documentation of core design principles

In Progress​

  • stronger alignment between principles and actual implementation
  • improved consistency across all infrastructure components
  • clearer linkage between principles, risks, and design decisions
  • increased use of principles in decision documentation

Planned / Next Phase​

  • systematic use of principles in all architecture evolutions
  • stronger support for audit and traceability
  • tighter integration with control framework and validation activities
  • continuous refinement based on observed risks and incidents

This page is intended to remain stable while guiding the evolution of the architecture.