Incident Response and Troubleshooting

Why it matters: The first 15 minutes of an incident decide whether it's a small cleanup or a large loss. A simple, practiced routine beats improvising under stress.

By the end you can:

• Recognize and report an incident signal
• Triage severity and scope using evidence
• Contain through an authorized process while preserving evidence
• Recover, document, and improve

Learn (15 min)

1. Prepare before it happens (5 min)

Define who can declare an incident, who coordinates, how to reach them, where evidence lives, and how communication works. Keep inventories, access procedures, backups, logs, and runbooks current. Current NIST guidance (SP 800-61 Rev. 3) integrates incident response with the Cybersecurity Framework 2.0 and treats it as an ongoing capability, not a one-time checklist.

2. Triage with evidence (5 min)

Record what, when, where, who noticed. Establish scope (identities, data, services, users), impact, and unknowns. Preserve logs and timestamps before routine retention or cleanup removes them. Separate facts from hypotheses. Escalate to the designated incident lead and follow your legal, privacy, and communication processes.

3. Contain, recover, learn (5 min)

Choose proportionate containment with the system owner: revoke exposed credentials, disable a compromised account, isolate a host, restrict a service. Preserve evidence; don't wipe systems reflexively. Remove the cause, restore from trusted backups or images, validate function and access, and monitor for recurrence. Close with a timeline, impact, decisions, causes, and owned improvements. Recovery isn't done until owners confirm it's safe and usable.

Apply (15 min)

Worked example (3 min). First-15-minutes note (no secret values included):

Time noticed: 10:42 ET   Reported by: Ops
Observed: Automation "lead-followup" sent ~200 unexpected emails since 10:15.
          Its API key string appears in a workflow log.
Affected: lead-followup workflow; email sending account; recipients unknown.
Unknowns: Was the key used outside our systems? Which recipients?
Actions taken: Paused the workflow (10:50). Notified incident lead (10:52).
Next: Incident lead approves key revocation/rotation; preserve logs; check sending history.
Next update: 11:15

Lab (7 min): Write your own.

1. Use this scenario: a staff member's password was reused on a breached site, and unusual mailbox rules appeared.
2. Write the first-15-minutes note (observed facts, affected assets, unknowns, containment candidates, evidence to preserve, next update).
3. List who must approve each containment step.
4. Draft three bullets for the post-incident review.

Deliverable: An incident note and review bullets. You're done when: Facts and hypotheses are clearly separated and no secret appears in the note.

Check yourself (5 min)

1. What belongs in an initial incident note?
2. Why preserve logs before cleanup?
3. What should happen when an API key is exposed?
4. Scenario: Someone proposes wiping the affected server immediately "to be safe." What's the concern?
5. Containment vs. recovery?

Reference

Common mistakes

Cheat sheet: Prepare → detect/report → triage and scope → contain → eradicate → recover and validate → review and track improvements.

Key terms: incident, triage, containment, eradication, recovery, evidence preservation.

Interview prompts: What do you do in the first 15 minutes of a suspected credential leak?

Go deeper: NIST SP 800-61 Rev. 3 · NIST CSF 2.0

Next: Revisit Lesson 20 to connect monitoring with incident response, and build your own runbook set.

---

Course wrap-up: your next steps

1. Pick one track and complete every lab, because the deliverables are your portfolio.
2. Build a personal runbook set from Lessons 20, 47, and 50.
3. Re-test your prompts, automations, and tracking quarterly. Tools change.
4. Teach one lesson to a colleague; it's the fastest way to find what you don't yet know.

End of course.