Why a canonical event model keeps the telemetry believable
A single SecurityEvent object feeds the different emitters, so the same event keeps the same core identity even when it appears as Windows Security Events, Sysmon, Zeek JSON, Snort alerts, Linux syslog, bash history, firewall, web server, proxy, or EDR/XDR telemetry. That matters because detection engineering depends on cross-source correlation, not isolated strings that happen to look like logs.
Shared context objects carry the pieces that usually break consistency: PID, parent PID, image, command line, username, LogonID, logon type, source and destination addresses, ports, and Zeek UID. Reusing those values across sources keeps process trees, authentication trails, and network traces aligned. Without that, a process can appear to exist in one stream and vanish in the next, which is bad training data and worse alert validation.
Shared context objects stop the same host looking different in every stream
ProcessContext, NetworkContext, AuthContext, DnsContext, and HttpContext let a single action fan out into several logs without losing state. A DNS lookup can stay tied to the same host and time window as the process that triggered it. A logon can keep its LogonID when it later shows up in process or network activity. That is the difference between believable security telemetry and a pile of disconnected samples.
Prerequisite events need to land before the interesting one
Causal ordering matters more than volume. If a rule says a network logon happened, the supporting protocol and authentication events need to appear first. A composable rule engine that inserts prerequisite events automatically is doing the boring part that analysts notice when it is missing. It keeps the attack path readable in SIEM training datasets and prevents impossible sequences that break trust in the data.
YAML scenarios, background noise, and the files analysts actually use
Scenarios live in YAML, which keeps the host list, user accounts, topology, and optional attack storyline in one place. That makes the output easier to reason about during blue team exercises, because the shape of the environment is visible before any log file is opened. Windows and Linux hosts can emit different telemetry sets, and selected sources can be disabled when a scenario needs that kind of constraint.
The background noise matters too. Real log streams are full of ordinary activity, not just neat attack chains. Synthetic data that skips that detail becomes too clean, then detection rules get trained on a world that does not exist.
Hosts, users, and topology belong in the same scenario file
A scenario file that keeps hosts, users, and network layout together gives the generator enough context to place events in the right place. That is what lets a Windows host emit the right mix of Security Events and Sysmon records while a Linux host produces syslog and bash history. It also gives the engine a sensible basis for cross-source timing and routing, which is where a lot of synthetic data falls apart.
ENVIRONMENT.md and GROUND_TRUTH.md carry the useful reference data
The companion documents matter because analysts need a fast way to check what the environment looked like and what the intended sequence was. ENVIRONMENT.md holds the useful reference data about the scenario. GROUND_TRUTH.md records what actually happened in the storyline. For alert validation, that is more useful than another pile of raw output with no frame of reference.
Keeping SIEM training data and alert validation honest
Cross-source consistency matters more than sheer volume. A large dataset full of mismatched state teaches detectors to tolerate nonsense. A smaller dataset with consistent timing, shared context, and realistic background noise teaches far better patterns for correlation and triage.
The coverage is broad enough to support more than one log source. EvidenceForge emits over 20 Windows, Linux, and network monitoring formats, including Windows Security Events with 30 event IDs, Sysmon with 10 event IDs, Zeek logs in JSON, Snort IDS alerts, and OS-aware Linux telemetry. That spread helps, but only if the same scenario state survives across all of it.
Cross-source consistency matters more than sheer volume
Heavily anonymised public datasets can stop resembling the original sources. Public material can also be stale, narrow, and over-recycled. Synthetic data avoids those problems, but only if the event relationships stay coherent. A log set that is big and incoherent still makes poor training material.
Test the dump path, not just the rule wording
A rule can look fine in isolation and still fail when the logs land in the SIEM. The dump path needs checking because parsing, field mapping, and source alignment can break the picture before detection logic sees it. Synthetic logs are useful here because alert validation can be run against known ground truth without needing live infrastructure for every test run.
No purely synthetic dataset will fool a seasoned analyst in every case. The useful test is narrower: whether the telemetry is consistent enough to train detection models, exercise rules, and show where the pipeline breaks when the logs finally arrive.
