Audit & Evidence – Methodology
Purpose
This section defines how security activities in the Scheol Security Lab are:
- documented through evidence
- verified through audit-oriented logic
- made traceable across risks, controls and validation
The objective is to ensure that security is not only implemented and tested, but also:
- provable
- reviewable
- consistent over time
Core Principle
If a control cannot be demonstrated, it cannot be trusted.
Evidence Philosophy
Evidence represents observable proof that a control:
- exists
- is active
- behaves as expected
Evidence must be:
- linked → to controls (C-XXX) and risks (R-XXX)
- contextualized → what was tested, when, and why
- verifiable → understandable by a third party
This is not about producing large amounts of data, but producing meaningful proof.
Types of Evidence
Evidence in Scheol is intentionally simple and pragmatic.
1. Configuration Evidence
Proof that a control is correctly configured.
Examples:
- SSH configuration showing root login disabled
- firewall ruleset
- reverse proxy configuration
2. Operational Evidence
Proof that a control is active during normal operation.
Examples:
- system logs
- access logs
- service status outputs
3. Validation Evidence
Proof generated through verification scenarios.
Examples:
- failed login attempts recorded in logs
- IP ban triggered by CrowdSec
- detection event during simulated attack
4. Recovery Evidence
Proof that resilience mechanisms work.
Examples:
- backup restoration output
- recovery test logs
- service restart validation
Evidence Structure
Each piece of evidence should be documented using a lightweight structure.
| Field | Description |
|---|---|
| Evidence ID | Unique identifier (E-XXX) |
| Related Control(s) | Linked control IDs (C-XXX) |
| Related Risk(s) | Linked risk IDs (R-XXX) |
| Source | System or tool generating the evidence |
| Description | What the evidence demonstrates |
| Collection Method | How it was obtained |
| Date | When it was collected |
| Result | Expected / Observed outcome |
| Storage Location | Where the evidence is stored |
Evidence Collection Approach
At the current stage:
- evidence collection is manual
- evidence is collected during validation activities
- storage is not yet centralized
This is intentional to keep the system:
- lightweight
- aligned with lab maturity
- easy to maintain
Traceability Model
Evidence is part of a structured chain:
Risk → Control → Validation → Evidence
This ensures:
- each control can be justified
- each validation can be proven
- each risk can be assessed based on real data
Audit Perspective
The lab does not aim for formal certification, but follows an audit-oriented mindset.
This means:
- decisions are documented
- controls are traceable
- validation is repeatable
- evidence is accessible
An external reviewer should be able to understand:
- what was secured
- how it was secured
- how it was verified
At the current stage, the Scheol Security Lab does not perform formal audit activities.
This section is designed to support audit readiness, by ensuring that controls, validation activities and evidence are structured in a way that could be independently reviewed in the future.
Known Limitations
At the current stage:
- evidence collection is not systematic
- storage is not centralized
- traceability is partial
- no formal audit process is defined
These limitations are expected in an evolving lab.
Evolution
The evidence model will evolve toward:
- structured evidence repository
- standardized evidence collection per control
- stronger linkage with validation scenarios
- partial automation of evidence generation
Current Maturity
Audit and evidence practices are considered early but intentional.
Established
- clear definition of evidence purpose
- linkage between validation and proof
- initial traceability model (Risk → Control → Evidence)
In Progress
- collection of evidence during validation scenarios
- improvement of documentation consistency
- better linkage between controls and observable proof
Planned / Next Phase
- centralized evidence storage
- standardized evidence per control
- improved traceability across all sections
- support for audit-style review
This section is expected to evolve alongside validation and monitoring capabilities.