How SentinelCore works

Cybersecurity is a discipline you cannot master by reading alone. Attackers, defenders, and the systems they use behave in ways that only reveal themselves under real conditions. SentinelCore exists to provide a safe, repeatable, and observable environment where learners and teams can practice the full workflow of modern cyber operations — provisioning vulnerable systems, detecting intrusions, collecting forensic evidence, and writing defensible reports — without any risk to production networks.

Traditional classroom training stops at theory. Public CTF platforms teach puzzle solving but not operational discipline. Enterprise incident-response drills are expensive and infrequent. SentinelCore closes that gap by giving instructors and operators a portal that:

• Spins up isolated virtual networks on demand, so exercises never touch real infrastructure.
• Enforces containment automatically — a compromised lab machine cannot escape its network segment.
• Records every action to an immutable audit trail, so students learn accountable behaviour from day one.
• Grades performance against measurable objectives instead of subjective impressions.

The platform is designed to serve four broad experience levels simultaneously:

SentinelCore enforces least privilege — every account is granted only the capabilities its role requires. Roles are stored server-side and validated by database row-level security; the browser cannot elevate itself.

The single most important architectural rule of SentinelCore is that the browser never talks directly to hypervisors, firewalls, or SIEM administrative APIs. Every privileged operation is routed through authenticated server functions and a central orchestration agent. This means:

• No credentials for Proxmox, pfSense, or Wazuh ever reach the client.
• Every action is scoped to an organization and a session before execution.
• Destructive actions require an explicit confirmation and are logged with the actor's identity.
• Session state is guarded by a database trigger — the state column cannot be modified directly, only through the state-machine RPC.

A lab template describes an exercise — its virtual machines, network topology, objectives, and scoring rubric. A lab session is a live instance of that template, assigned to specific participants and tracked through an eleven-state lifecycle:

1. 1scheduled
2. 2provisioning
3. 3ready
4. 4running
5. 5paused
6. 6containment_warning
7. 7containment_breach
8. 8stopping
9. 9completed
10. 10failed
11. 11archived

Transitions between states are validated server-side against an explicit finite state machine. Stuck transient states (e.g. provisioning that never completed) are swept automatically by a scheduled job so sessions cannot silently hang.

The catalog is the library of reusable lab templates. Templates move through a simple lifecycle:

• Draft — editable, invisible to students. Author the specification and iterate.
• Published — a specific version is marked as current and becomes available to instructors and students.
• Archived — retired from new use but preserved for auditability.

Every published version is immutable. If a scenario needs to change, a new version is drafted and republished — this guarantees that any student grade can be reproduced against the exact scenario they experienced.

The Infrastructure module lists the virtual machines managed by SentinelCore and their current power state, containment level, and owning session. Operators submit agent jobs — small, allow-listed instructions — to the orchestration agent, which is the only component permitted to talk to the hypervisor.

Allow-listed agent actions:

• Power on / off — start or hard-stop a VM.
• Reboot — orderly restart.
• Suspend / resume — freeze VM state to disk.
• Snapshot — capture a point-in-time image for later revert or forensics.
• Revert — restore a VM to a prior snapshot.
• Isolate — cut a VM off from all networks except a management interface. Used to contain suspected breaches.

Any action the agent does not recognise is rejected. Preconditions (for example, you cannot snapshot a powered-off VM) are checked in the database before the agent is invoked.

A SIEM (Security Information and Event Management) system aggregates logs and telemetry from every host, network device, and application in a monitored environment, then applies detection rules to surface events that may indicate malicious activity. SentinelCore uses Wazuh as its SIEM backend and exposes the resulting alerts in the Alerts module.

Each alert has a severity, a source rule, an affected host, and a status:

• New — freshly generated, not yet triaged.
• Investigating — an analyst has claimed it.
• Resolved — closed with a rationale. Requires explicit confirmation to prevent accidental dismissal.
• False positive — resolved with a note that the detection rule fired on benign activity.

Evidence is any artefact a participant collects during a session — a screenshot, a log excerpt, a memory dump, a network capture. When uploaded, every artefact is hashed with SHA-256 and its hash, uploader, timestamp, and originating session are recorded on an append-only timeline called the chain of custody.

Chain of custody is the same principle used in criminal forensics: any handling event — access, transfer, analysis — must be recorded, and the artefact's integrity must be verifiable at every step. If a hash later fails to match, the evidence has been tampered with and is no longer admissible.

Reports document what happened during a session — what was detected, how it was handled, and what conclusions were reached. Every report is versioned as an append-only sequence of revisions: once written, a revision cannot be edited or deleted. Publishing a report makes it visible to the students associated with the session; archiving retires it without destroying history.

The audit log is an immutable record of every security-relevant action taken in the portal — role changes, session transitions, agent jobs, evidence uploads, report publications. Administrators can search and export it but nobody, including administrators, can modify or delete entries.