Security Lab — operating workflow

How the lab should be used for VAPT, blue-team telemetry, and documentation.

Daily Workflow

Use the lab in short, documented loops:

Define a test objective and target scope.
Confirm the target is inside the lab.
Capture the baseline state before changes.
Run the scan, attack simulation, detection test, or configuration change.
Record findings, telemetry, and screenshots.
Update the private lab repo with infrastructure notes and ADRs.
Promote reusable learning notes into this docs section after removing secrets.

Background-First Rule

Long-running lab work should run in the background so disconnects do not lose state. The private lab repo now treats this as an accepted ADR:

Use sub agents for independent side work when the runtime supports safe parallel delegation.
Run long-running shell work in named tmux sessions.
Keep useful command output in logs/.
Keep task state in docs/task-log/.
Update docs/AGENT_MEMORY.md when infrastructure state changes.
Commit and push durable documentation after state-changing work.

Examples of long-running tasks include VM installs, image imports, package upgrades, scanner feed updates, Security Onion setup, Nexus Dashboard deployment, and large verification jobs.

The standard helper in the private lab repo is:

./scripts/start-background-task.sh <session-name> logs/<task>.log '<command>'

On resume, check Git, tmux, and the task notes before continuing:

git status --short --branch
tmux ls
find docs/task-log -maxdepth 1 -type f | sort

Tool Roles

Tool	Role
Kali Linux	Offensive validation, enumeration, exploit research, packet capture, and manual VAPT
Kali Purple	Blue-team and purple-team package set for detection engineering and defensive validation
EVE-NG	Router, switch, and appliance topology emulation
Security Onion	Network security monitoring, IDS, packet evidence, and alert triage
Wazuh	Endpoint monitoring, log collection, rule testing, and compliance-style visibility
Greenbone	Vulnerability scanning and remediation tracking
Linux target	Controlled host for hardening, scanning, and telemetry validation
Juice Shop	Controlled web application for OWASP-style testing

Documentation Rules

Keep these categories separate:

Publishable docs: architecture, learning notes, topology, safe commands, high-level procedures.
Private repo docs: host-specific runbooks, current VM details, ADRs, operational memory.
Secrets directory: credentials, generated passwords, API tokens, private keys.

Do not paste tokens, passwords, session cookies, private keys, or licensed software download URLs into docs.

Evidence Hygiene

When documenting security tests, include enough information to reproduce the lesson without leaking sensitive material:

Include target hostname/IP only when it is lab-local.
Include command intent and safe command examples.
Redact session cookies, bearer tokens, API keys, and appliance passwords.
Prefer summaries over raw scanner output when the output contains credentials, keys, or host-specific identifiers.