SOC Incident Workflow

Turn Wazuh alerts into a structured SOC workflow with triage, scope, evidence, containment, remediation, and lessons learned.

Kubernetes SOC Field Lab · Practical Security Operations

Domain alignment

What this lesson covers

• Turning an alert into an incident workflow
• Writing scope, evidence, impact, containment, and remediation notes
• Deciding when an alert is not an incident
• Using Kubernetes and Windows evidence together

Step 1: Start with the triage decision

Triage decision:
- Expected lab activity
- Benign but useful signal
- Needs more investigation
- Suspicious
- Confirmed incident

Step 2: Define scope

Scope:
Affected endpoint(s):
Affected user(s):
Affected namespace/pod if Kubernetes:
Affected file/path/process if Windows:
Start time:
End time:
Related events:
Data involved:
Business impact:

Step 3: Capture evidence

Evidence:
Wazuh alert URL or screenshot:
Rule ID:
Full log:
Endpoint inventory:
Kubernetes command output:
Windows command output:
Timeline notes:
Analyst observations:

Step 4: Decide response actions

Containment:
- None needed
- Isolate endpoint
- Stop workload
- Restrict namespace
- Disable account
- Block network path

Remediation:
- Remove unwanted file/process
- Patch system
- Correct configuration
- Rotate secret
- Update deployment
- Improve monitoring

Step 5: Write the incident note

Incident note:
Summary:
Status:
Severity:
Detection source:
Timeline:
Scope:
Evidence:
Impact:
Containment:
Remediation:
Lessons learned:
Follow-up actions:

Step 6: Close or escalate

Most lab events should close as expected activity. The purpose is to practice the workflow, not invent drama. Escalate only when evidence supports it.

Check your understanding

1. Why is triage not the same as incident confirmation?
2. Why does scope matter?
3. Why should containment be proportional?
4. What makes an incident note useful?