Incident Response & Defence

Everything so far taught you how attacks work. This final module flips to the defender's chair (the “blue team”): how professionals detect an attack in progress, stop it, clean up, and make sure it never happens again. This is where most security careers actually live.

Red team vs. blue team

Analogy — Football practice The red team (attackers) is the opposing side that probes for gaps. The blue team (defenders) is your side that guards the goal, spots the play developing, and adjusts. The best players understand both roles — which is exactly why we learned attacks first.

The incident response lifecycle

When something goes wrong, professionals follow a calm, repeatable process. A common model (SANS) has six phases — remember P I C E R L:

Phase	What you do	Everyday version
1. Preparation	Tools, logging, plans, and training in place beforehand	Smoke alarms & a fire drill
2. Identification	Detect and confirm something is actually wrong	The alarm goes off — is there real smoke?
3. Containment	Stop it spreading (isolate the machine)	Close the door to the burning room
4. Eradication	Remove the cause (malware, bad account)	Put the fire out
5. Recovery	Restore clean systems and monitor	Repair the room, watch for flare-ups
6. Lessons Learned	Write it up; fix the root cause	Why did it start? Prevent a repeat

The golden rule of a live incident Stay calm and contain before you clean. Panicking and wiping a machine too early destroys the evidence you need to understand what happened. Isolate first, investigate, then eradicate.

Logs — the defender's eyes

You can't respond to what you can't see. Logs are the records systems keep of what happened. On Linux they live in /var/log (recall Module 2). Your grep and tail skills shine here.

$ sudo tail -f /var/log/auth.log # watch login attempts live $ grep "Failed password" /var/log/auth.log # find failed logins (possible brute force) $ grep "Failed password" /var/log/auth.log | wc -l # count them $ last # who logged in recently, and from where

SIEM — one screen for all the logs

A big organisation has thousands of machines. A SIEM (Security Information and Event Management) system — like Splunk, the ELK Stack, or Wazuh — collects every log into one place, correlates them, and raises alerts. A SOC (Security Operations Centre) analyst watches that screen.

Analogy — A building's security desk Individual logs are like separate CCTV cameras. A SIEM is the security desk with every camera feed on one wall, plus a system that flashes red when it spots someone trying the same locked door 500 times. That flashing red is the “Identification” phase in action.

Hardening & defence-in-depth

Hardening means shrinking a system's attack surface before anything happens. Defence-in-depth means using many layers so that if one fails, others still hold.

Layer	Example control
People	Security awareness & phishing training
Access	Strong passwords + multi-factor authentication (MFA)
Network	Firewalls, segmentation, closing unused ports (from your Nmap audits)
System	Patching, least-privilege permissions, disabling unused services
Data	Encryption at rest & in transit, backups you have tested
Detection	Logging + SIEM + alerts

$ sudo ufw enable # turn on a simple host firewall $ sudo ufw allow 22/tcp # allow only the ports you actually need $ sudo apt update && sudo apt upgrade # patching — closes known CVEs

Try It Yourself (practice terminal)

Investigate like an analyst. Try: grep "Failed password" /var/log/auth.log, last, or ufw status.

kali@lab: ~ (SOC analyst)

Defence practice shell. Investigate the logs below.

kali@lab:~$

Practical Exercise 12.1 — Detect and respond to a brute-force attempt

Do this in your lab. It ties the whole course together: attacker and defender in one exercise.

Prepare: on your Kali machine, make sure SSH is running and watch its log: sudo tail -f /var/log/auth.log.
Simulate the attack from your lab target by making several wrong SSH logins to your Kali box (this generates “Failed password” lines — your own machines only).
Identify: in another terminal, grep "Failed password" /var/log/auth.log | wc -l to count the attempts, and find the source IP.
Contain: block that IP with the firewall (sudo ufw deny from 192.168.56.50) and confirm the failures stop.
Lessons learned: write 3 preventive controls (MFA, fail2ban, key-only SSH).
Result: you've run a complete mini incident — detect, contain, prevent. That's the core loop of a SOC analyst's day.

Quick check: You discover a machine is actively compromised. What should you do first?

Immediately wipe and reinstall it

Contain it — isolate the machine to stop the spread, then investigate

Turn off all logging

Post about it online

Contain first. Wiping too early destroys the evidence you need. Isolate, investigate, then eradicate and recover.

Why does this matter for your career? Defence is where the majority of security jobs are: SOC analyst, incident responder, security engineer. The IR lifecycle, logging, SIEM, and hardening are core CompTIA Security+, CySA+, and blue-team material. Employers value people who can not only find problems but calmly fix them under pressure.

Key takeaways

Defenders follow the IR lifecycle: Prepare, Identify, Contain, Eradicate, Recover, Lessons Learned.
Contain before you clean — preserve evidence.
Logs + a SIEM are how you detect attacks; your grep/tail skills apply directly.
Hardening and defence-in-depth stop incidents before they start.

🎉 You've completed the CyberSchool core course

You started not knowing what a network was. You can now read a network, operate Kali, scan with Nmap, analyse packets, assess vulnerabilities, understand penetration testing and web/wireless attacks, use cryptography, and respond to incidents — the foundational knowledge behind CompTIA Security+, Network+, Cisco CCNA, and CEH.

Where to go next: pick a certification and practise relentlessly on legal platforms like TryHackMe, Hack The Box, and your own lab. Depth comes from doing. Keep everything ethical, keep building, and welcome to the field.