The Red vs. Blue Split

The lab is structured around a deliberate attacker-defender separation. Kali Linux sits on an isolated VLAN and operates as the attacker machine. The same tools that would be used against a real target — Hydra for credential attacks, Metasploit for exploitation and post-exploitation, nmap for reconnaissance — are used against the lab’s victim VMs. The point is that the attack traffic is realistic, not synthetic. Wazuh and Suricata are the defenders: collecting logs, generating alerts, and providing the visibility surface that a real SOC would work from.

Running the same attack patterns in the lab that show up in real environments means the detections being built and tuned have actual signal value. A rule that catches Hydra SSH brute force in the lab will recognize that pattern anywhere it appears.

Detection Engineering: Writing and Tuning Rules

Rules are written and tuned against real alert data from simulated attacks, not against hypothetical traffic. The workflow is:

1. Run an attack from Kali — for example, an nmap SYN scan followed by a Hydra credential spray against SSH.
2. Observe what Wazuh fires, what Suricata catches, and what produces no alert at all.
3. For alerts that fired correctly: verify the rule logic, check the alert metadata, confirm the rule is identifying the right event type and not overfitting to incidental fields.
4. For things that did not fire: trace back through the log source — is the event being ingested? Is it reaching the rule? Is the rule condition wrong? Fix the gap.
5. For rules generating false positives: adjust thresholds, add exclusion conditions, or tighten the match criteria against known-good baselines.

Detection engineering in the lab is iterative. What fired on the first scan pass may not fire after the rule is adjusted, or a new attack variant may slip through a rule written against the previous pattern. The goal is coverage that holds under variation, not just under the exact attack that produced the original alert.

EDR Context from MSTS

At MSTS, endpoint detection runs on CrowdStrike Falcon and Symantec in a federal environment. Working with those tools professionally informs how the lab is structured and what is worth simulating. CrowdStrike’s detection model is built heavily on behavioral indicators — process lineage, memory injections, unusual parent-child relationships — rather than pure signature matching. That means the attack simulations in the lab include behaviors that would trigger behavioral detection logic, not just known-bad hashes or static signatures.

The home lab cannot replicate a federal EDR deployment directly. What it can do is develop the analyst instinct: understanding what process behavior looks suspicious, what parent-child relationships are anomalous, what network connection patterns warrant investigation. Working with real EDR telemetry at MSTS and working with Wazuh alert data in the lab are complementary — the professional context makes the lab work more purposeful, and the lab work builds pattern recognition that transfers to professional tool environments.

Incident Response Workflow

Alert triage follows a structured workflow even in the lab, because the purpose is to build the habit, not just demonstrate that alerts fire. When Wazuh surfaces an alert:

1. Detection — identify the alert, review the raw log, confirm the event is what the rule claims it is.
2. Analysis — look at surrounding context: what happened before and after the flagged event? Are there correlated alerts across other rule categories? What system is affected?
3. Containment — in the lab, this is simulated: isolate the affected VM from the internal switch, disable the affected account if credential compromise is simulated.
4. Eradication and Recovery — document what was found, restore the VM to a clean snapshot, verify the detection rule that caught it is still intact.
5. Post-incident review — did the detection work as expected? Was the triage fast or did something slow it down? What would have been missed?

This maps directly to NIST 800-61’s incident response phases: Preparation, Detection and Analysis, Containment/Eradication/Recovery, and Post-Incident Activity. Applying the framework in the lab means it is not abstract process documentation when it shows up in a professional context.

The Goal

Professional security monitoring experience — working with enterprise EDR, operating in a federal compliance environment, handling real alerts on real infrastructure — and hands-on detection and response practice are not separate tracks. The lab exists to close the gap between the two: to take what is observed in production and build the technical depth to understand it from the inside. Writing a Wazuh rule from scratch, watching it fire on a real simulated attack, and tuning it against false positives builds a different kind of understanding than reading documentation about how detection rules work. That is what the lab is for.