Security Onion Hands-on Labs

Choose the route that fits your available time and computing resources. Use the Interactive Lab for a short guided investigation, or the Full Lab to build and operate a complete Security Onion workflow in a virtual machine.

Hands-on proof of concept

Build it. Correlate it. Explain it.

Start with one Security Onion Standalone VM, load the built-in test data, trace a Suricata alert into related Zeek evidence, and preserve a defensible finding in a case. Add live endpoints and network sources only after the core route works.

⏱ 5–8 hours core ◆ Guided beginner ✓ Evidence required

Start building

Self-hosted · Several hours

Security Onion Full Lab

Installation required

How this differs from the guided journeys

This is not a screenshot-by-screenshot transcript. It gives you outcomes, checkpoints, and evidence requirements while leaving room to investigate. Your version, alert names, field names, timestamps, and results may differ from the original proof of concept.

Use an isolated, authorised environment

Import only test data you are authorised to handle. Treat packet captures as untrusted evidence: do not extract or execute payloads. Take a snapshot before adding live endpoints, rules, accounts, or network sources.

Before you begin

You need: an x86-64 computer with virtualisation enabled, administrator access, enough capacity to allocate at least 24 GB RAM and 200 GB disk to the Security Onion VM, and temporary internet access for authorised downloads.

How to use this lab

Complete one session at a time. Stop when a checkpoint fails; fix that boundary before importing more data or adding an endpoint, sniffing interface, or rule.

Recommended

Beginner Core Lab

Use one Security Onion Standalone VM and the built-in test-data workflow. Complete all three activities before adding a live source.

Expected time: 5–8 hours across three sessions.

Optional extension

Complete PoC

After the core checkpoints pass, add Windows and Elastic Agent, Sysmon, a monitored network, a firewall VM, or custom detection content.

Expected time: one or more additional sessions.

1. Session 1Build and snapshot3–4 hours
2. Session 2Load and correlate1–2 hours
3. Session 3Investigate and preserve1–2 hours

Objective

You are a junior SOC analyst validating a small Security Onion deployment. Build the platform, load a controlled dataset, identify a network alert, connect it to related evidence, and create a case that another analyst can reproduce.

The Beginner Core Lab consists of:

• one Security Onion Standalone deployment;
• built-in Security Onion test data or an authorised PCAP imported through Grid;
• one Suricata alert with a shared flow identifier; and
• related Zeek evidence preserved with the analyst conclusion in a case.

Use the Complete PoC only after this single-VM workflow works reliably.

01

Activity 1: Build the environment

Download checklist

Record the filename, version, architecture, checksum, licence condition, and download date for every item.

Required for the Beginner Core Lab

Item	Purpose	Authoritative source
VMware Workstation Pro, demonstrated	Hypervisor used for the screenshots; another x86-64 hypervisor is suitable if it supports isolated networking and snapshots	Broadcom installation and download guidance
Security Onion ISO	Standalone manager and sensor platform	Security Onion download and verification instructions

Verify the Security Onion ISO

Compare the downloaded ISO against its published checksum before attaching it to the VM. Do not continue when verification fails.

Create the virtual machine and network

VM	Suggested lab allocation	Interface	Demonstrated address
so-standalone	4+ vCPU, 24 GB minimum RAM, 200 GB local disk	Isolated management network	10.0.0.100

1. Enable hardware virtualisation and install VMware Workstation or an equivalent x86-64 hypervisor with isolated networking and snapshot support.
2. Create an isolated management network. Provide NAT only while the VM needs authorised installation, update, or download access.
3. Create the Standalone VM, allocate the required resources, attach the verified Security Onion ISO, and install the operating system.
4. Configure the hostname, address, DNS, and time synchronisation. Adapt the address plan consistently if required.
5. Confirm the analyst workstation can reach only the required management and update services.
6. Take a clean base-os snapshot before platform configuration.

Milestone 1Standalone VM readyThe VM has a recorded address, synchronised clock, isolated management path, verified installation media, and a clean snapshot.

Optional Complete PoC machines and downloads

Add these only after the Beginner Core Lab works:

Optional item	Purpose
Windows Server evaluation ISO	Disposable endpoint for Elastic Agent
Sysmon	Additional Windows process telemetry
FortiGate or pfSense	Authorised firewall and monitored-network traffic
Separate endpoint or traffic source	Live data for the sniffing interface

A live monitored network requires a separate, addressless sniffing interface and traffic-delivery method supported by the hypervisor. Keep management and monitored traffic separate.

Expected result The Standalone VM starts with a recorded address, synchronised clock, isolated management connectivity, and a recoverable base-os snapshot.

02

Activity 2: Load and correlate

Follow the checkpoints in order. Keep this page open and return after each linked journey.

1. SOC is availableInstall Security Onion, sign in to SOC, and record the platform version.
2. Grid is healthyOpen Grid and confirm the node and required services are healthy; compare the result with so-status.
3. The baseline is recoverableTake a working-securityonion-core snapshot before importing test data.
4. Controlled data is loadedUse the Grid test-data workflow or upload an authorised PCAP, then record the import time and source.
5. A suitable alert is foundSelect one Suricata alert that includes a Community ID or equivalent shared flow identifier.

Open Grid, select the Standalone node, and use the test data control described in Analyst Tools. Confirm the import and allow several minutes for processing. Record:

• the time you started the import;
• whether you used built-in test data or an authorised PCAP;
• the node that processed it; and
• any warnings or differences from the guide.

Open Alerts, use a narrow time range around the import, and begin with alerts generated by suricata. Select one medium- or high-severity network alert that exposes network.community_id or another correlation value. Record the actual alert name rather than trying to match a screenshot.

Expand the event and capture these fields where available:

• timestamp and rule name;
• severity and event module;
• source and destination IP addresses and ports;
• observer or sensor name; and
• Community ID or equivalent flow identifier.

Milestone 2Evidence correlatedYou selected one real alert from the controlled dataset and used its shared flow identifier to locate related Security Onion evidence.

Extend the working core with a live source

Choose only one extension at a time:

• enrol a disposable Windows endpoint using Endpoint agents;
• add Sysmon after the basic endpoint events are searchable;
• connect an addressless sniffing interface to an authorised monitored segment;
• add a FortiGate or pfSense VM as a controlled network source; or
• import a separately authorised PCAP through the Grid upload control.

Repeat the source → sensor or agent → dataset → Alerts or Hunt checkpoint before adding another integration.

Expected result SOC and Grid are healthy, a recoverable core snapshot exists, controlled test data is searchable, and one Suricata alert has the fields required for correlation.

03

Activity 3: Investigate and preserve

Confirm SOC opens, Grid remains healthy, and the selected alert is still searchable. Continue only when the known event can be reopened.

Investigation scenario

You are the junior analyst reviewing suspicious outbound network activity from a controlled dataset. Determine what the network evidence supports, what it does not prove, and what the next analyst should verify.

1. Open the alert selected in Activity 2 and confirm the raw fields.
2. Select its Community ID or equivalent value and choose Correlate.
3. In Hunt, identify at least one related Zeek connection, DNS, HTTP, SSL/TLS, or file record from the same flow or time window.
4. Open PCAP only when it is available and relevant; do not extract or execute transferred content.
5. Record any field-name substitutions or missing evidence.

Answer these questions:

• What happened, and when did it happen?
• Which source and destination were involved?
• Which Suricata fields support the alert?
• Which Zeek or PCAP evidence adds context?
• Does the evidence show network communication, endpoint execution, or both?
• What remains unknown about the process, user, intent, or wider scope?
• Is the activity malicious, suspicious, or benign in this controlled context?

Record the reasoning before deciding:

Hypothesis	Supporting evidence	What remains unknown	Disposition
The selected host made suspicious outbound network contact	Add the alert, flow, DNS, connection, and PCAP fields you observed	Note missing endpoint, process, user, payload-execution, or wider-scope evidence	Record the classification supported by the available evidence

Preserve the finding

Create or update a Security Onion case. Include:

• a concise title naming the affected source and activity;
• the alert and correlated records;
• source, destination, domain, hash, or other relevant observables;
• the Hunt query or correlation value;
• the evidence-based disposition and confidence;
• important limitations and unknowns; and
• one practical next action for the receiving analyst.

Ask another learner, or review the case as if you were the next analyst. Confirm that the saved query or correlation value reopens the same evidence without depending on your memory or the original screenshots.

Improve and validate a detection

After the core case workflow works, choose one optional improvement:

• create a narrowly scoped Sigma, Suricata, or YARA rule;
• tune a rule or suppress a demonstrated false positive;
• improve a Hunt query or dashboard that makes the pattern easier to recognise;
• add case guidance that makes the alert more actionable; or
• add a detection mapping or description supported by the observed evidence.

Record the owner, rationale, expected data source, syntax validation, and rollback. Repeat a controlled positive test and a comparable benign test. Document both results, telemetry gaps, false-positive assumptions, and any performance impact. Disable the object afterward or retain it with an owner and review date.

Write the analyst handoff

Keep the note short enough to scan. Include:

• Who and where: source, destination, sensor, and account if known;
• What happened: the alert and connected network activity;
• Evidence: Suricata, Zeek, PCAP, timestamps, and saved query;
• Decision: disposition, confidence, and why it fits the evidence;
• Unknowns: endpoint execution, user intent, payload, or wider scope; and
• Next action: the most useful collection or verification step.

Milestone 3Case handed offAnother analyst can open the case, reproduce the evidence chain, understand the disposition and limitations, and continue the investigation.

Expected result You can connect a Suricata alert to related evidence, avoid claiming more than the records prove, and preserve a reproducible analyst finding in a case.

Full Lab evidence checklist

This checklist applies to the self-hosted Full Lab. If you completed the Interactive Lab, retain its downloaded evidence summary instead.

Do not aim to match every screenshot or complete every optional integration. Collect evidence that proves your selected route works:

• Verified ISO, Standalone VM resources, network, address, time synchronisation, and snapshots.
• SOC availability, platform version, Grid health, and core-service status.
• Controlled data source and selected Suricata alert with timestamp, rule, severity, endpoints, and flow identifier.
• Correlated Zeek or PCAP evidence and the Hunt query or Community ID used to find it.
• Evidence-based disposition, confidence, and important unknowns.
• A reproducible Security Onion case with observables, reasoning, and next action.
• Cleanup or snapshot restoration, healthy ingestion, selected route, and differences from the original PoC.

0 of 7 recorded Mark each item when you have saved the evidence. Reset

Clean up

Stop test activity and remove temporary live sources, accounts, firewall rules, or custom detections. If you used only imported test data, restore the working-securityonion-core snapshot when you want a clean platform state. Confirm SOC opens, Grid is healthy, and normal ingestion matches the recorded baseline. Retain only sanitised queries, screenshots, case notes, and conclusions.

PreviousEngineer a detectionNextReturn to Security Onion overview