Skip to main content

Validation & Monitoring

Purpose​

This section defines how security controls in Scheol Security Lab are:

  • observed (monitoring)
  • tested (validation)
  • evaluated over time

The objective is to ensure that controls are:

  • not only implemented
  • but actually effective and observable

Core Principle​

A control that cannot be observed or tested cannot be trusted.

Monitoring vs Validation​

Monitoring​

Continuous observation of system behavior.

Answers:

  • Is the control active?
  • Is it producing signals?

Validation​

Intentional verification of a control.

Answers:

  • Does the control actually work?
  • Would it resist misuse or attack?

Control-Centric Approach​

Validation and monitoring are control-driven, not generic.

Each control must have:

  • at least one observable signal
  • at least one validation method

Current Monitoring Coverage​

C-001 – Reverse Proxy Exposure Control​

Signals

  • Nginx access logs
  • HTTP error codes
  • unusual request patterns

Current State

  • logs available locally
  • no centralized analysis

C-003 – Web Application Hardening​

Signals

  • application logs (Dolibarr)
  • authentication failures
  • error logs

Current State

  • partial visibility
  • no structured monitoring

C-005 – Administrative Access Hardening​

Signals

  • SSH login attempts
  • failed authentication logs
  • CrowdSec alerts

Current State

  • CrowdSec active
  • logs not centralized

C-006 – Credential & Secrets Management​

Signals

  • manual verification of vault usage
  • absence of credential reuse

Current State

  • no automated monitoring

C-002 / C-004 / C-007​

Status

  • not monitorable yet (controls not implemented)

Detection Capability​

Current State​

  • detection is limited and local
  • some blocking (CrowdSec) exists
  • no correlation between systems

Key Limitation​

Most events are visible, but not actively detected.

Validation Strategy​

Validation is performed through simple, targeted tests.

1. Access Control Validation​

Examples

  • multiple failed SSH logins
  • verify:
    • logs are generated
    • CrowdSec reacts

2. Exposure Validation​

Examples

  • HTTP probing on exposed services
  • verify:
    • access logs
    • no unintended exposure

3. Application Behavior Validation​

Examples

  • failed login on Dolibarr
  • invalid requests

4. Recovery Validation (Planned)​

Examples

  • backup restore test

Validation Frequency​

  • manual
  • event-driven (after changes)
  • focused on critical controls

Evidence Model​

Validation activities should produce:

  • logs
  • screenshots
  • command outputs

These can be linked to:

  • Control (C-XXX)
  • Risk (R-XXX)

Known Limitations​

  • no centralized logging
  • no SIEM
  • limited detection rules
  • validation mostly manual
  • incomplete coverage

Current Maturity​

Validation & Monitoring is early and limited.

Strengths​

  • clear methodology
  • initial signals identified
  • basic validation possible

Weaknesses​

  • weak detection capability
  • no central visibility
  • incomplete control coverage

Evolution Priorities​

  1. Centralize logs (Wazuh)
  2. Improve detection capability
  3. Link each control to validation scenarios
  4. Increase validation frequency and consistency

This section will evolve toward a more observable, testable and measurable security posture.