Incident response, in six steps

When something looks wrong, a calm order of steps beats a rush. This set covers the six phases of incident response applied to a small incident on your own device, and why the last phase, the one most people skip, is the one that makes the next incident easier.

4 questions 1 task Read the lesson

Questions

Each one is marked as you go, and the explanation arrives straight after, which is the part worth reading.

4 questions, marked as you go.

1 What is the purpose of the preparation phase?
2 Why take a snapshot before changing anything?
3 How does containment differ from eradication?
4 Why is lessons learned the phase most people skip, and why does it matter?

Tasks

These need your own device. Run the command in Termux, then paste what it printed. The marking looks at what the output means, so spacing, version numbers and ordering do not matter. If you have not installed anything yet, the lesson covers the setup.

Take an incident snapshot

This makes an evidence file, locks its permissions down, and writes a dated snapshot of the device state: the time, the listening ports, the file permissions and the file hash. Read it as the record you would keep at the start of an incident.

Run this in Termux On your own device. Nothing on this page executes it. The command runs in your terminal, and this box only reads what you paste back.

cd ~; mkdir -p ir; printf 'report\n' > ir/evidence.txt; chmod 600 ir/evidence.txt; { echo "== when =="; date -u +%Y-%m-%dT%H:%M:%SZ; echo "== listeners =="; ( ss -tuln 2>/dev/null || netstat -tuln 2>/dev/null || echo none ) | head -n 5; echo "== file =="; ls -l ir/evidence.txt; sha256sum ir/evidence.txt; } > ir/incident.txt; cat ir/incident.txt
Marking your own work Both halves of this are checked in your browser, with no server involved, so nothing stops you from pasting output you did not run. The tasks are written so that the easiest way to pass one is to actually do it and read the result, which is the whole intention.

All sets Read the lesson