dotfiles-Defense

Role Stable

The blue mirror of Kali — the defensive role. Detection engineering & investigation: hunt/triage tooling, version-controlled detection content (Sigma, Sysmon, Zeek/Suricata, SIEM), and a Dockerized detection lab. Distro-agnostic.

Highlights

  • Sigma / Sysmon / Zeek
  • mkcase hunt workflow
  • Dockerized detection lab
  • distro-agnostic + Core

How it fits

The Role layer — Operator role — offensive or defensive — stacked on top of an OS layer. It builds on Core, which is vendored into its core/ directory. See the three-layer model for how the layers compose.

Getting started

git clone https://github.com/dotgibson/dotfiles-Defense ~/dotfiles-Defense
cd ~/dotfiles-Defense
./bootstrap.sh                 # symlinks Core + defense; checks docker
exec zsh

Distro-agnostic: host tools come from your OS-native layer; the heavy detection stack comes up in containers via docker/ (siemup / siemdown).

What actually bites

  • A defense stage on the loader — Adds one stage just before local overrides (… os defense local). defense/defense.zsh holds workflow helpers only (mkcase, gocase, note, siemup/siemdown), all HAVE_*-guarded.
  • Case data never lives in the repo — Investigation data lives under ~/cases (outside the repo), exactly like Kali keeps engagements in ~/engagements. mkcase scaffolds a case outside the repo by design; the .gitignore is a backstop.
  • No blue-team distro required — The blue stack is overwhelmingly containers, so this repo assumes no specific OS — you do not need Security Onion or a dedicated distro. Version-controlled detection content (Sigma/Sysmon/network/SIEM) lives under detections/.
  • Red vs blue is a split, not a merge — Attacker-authored detections stay in Kali's PURPLE-TEAM.md; defender-authored capability lives here. The two cross-link rather than copy.

Read next

View dotfiles-Defense on GitHub ↗