Attack Mitigation

Every attack in Section III has a defence. This lesson maps the techniques from the last fifteen lessons to the specific controls that stop or detect each one — and explains how defenders build programmes that reduce real-world attack surface rather than just accumulating tools.

From finding to fixing — the pen tester's role in mitigation

A pen test report that lists vulnerabilities without actionable remediation is an incomplete deliverable. The findings section tells the client what is broken. The remediation section tells them how to fix it. The quality of a pen test report is often measured not by the number of findings but by the specificity and practicality of the remediation guidance — because that is what determines whether the client actually fixes the issues or lets them sit on a backlog indefinitely.

Understanding mitigation also makes the pen tester better at finding vulnerabilities. Knowing exactly what configuration change stops a technique tells you what misconfiguration to look for. Knowing that SYN cookies defeat SYN floods means you check whether they are enabled. Knowing that HSTS defeats SSL stripping means you test whether it is deployed. The offensive and defensive knowledge are the same knowledge, viewed from opposite directions.

Section III attack-to-defence map

The table below maps every major attack category from Lessons 21 through 34 to the primary controls that stop or significantly limit it. This is the reference that turns a set of findings into a structured remediation conversation with a client.

Hardening frameworks — how organisations structure defence

Individual controls address individual vulnerabilities. A hardening framework provides the structure for building a comprehensive, prioritised defence programme — ensuring controls are applied consistently across every system rather than ad hoc on whichever systems someone happened to configure carefully.

Three frameworks appear most consistently in enterprise security programmes. Each has a different purpose and a different level of prescriptiveness.

The defence-in-depth model

No single control stops all attacks. The principle of defence-in-depth acknowledges this and structures controls so that an attacker who bypasses one layer encounters another. The model is sometimes described as a castle — moat, walls, gates, guards, inner keep — each layer providing a barrier that must be overcome independently.

In a corporate network, defence-in-depth looks like this: perimeter firewall blocks most inbound attacks. Email filtering stops most phishing. Endpoint antivirus catches most commodity malware. EDR catches behavioural anomalies. Network segmentation limits lateral movement. Privileged access controls limit escalation. SIEM correlation detects multi-stage attacks. Incident response capability limits dwell time when detection occurs. Backup and recovery capability limits ransomware impact.

The important observation in this model is that no layer has a "Does not stop" caveat that is empty. Every layer fails against something. Defence-in-depth works not because any layer is perfect but because the combination of layers forces an attacker to bypass each one sequentially — and each bypass attempt creates detection opportunities. A sophisticated attacker may pass the perimeter. They may evade EDR. But their lateral movement generates network logs. Their privilege escalation generates Event ID 4672. Their persistence generates new autorun entries. At some point, one of the layers catches them — if the detection layer is actually monitoring for what each layer misses.

Translating pen test findings into a remediation roadmap

A pen test delivers findings at a point in time. The client needs to turn those findings into a programme of work — prioritised, resourced, and scheduled. The pen tester's job does not end at findings delivery. The most valuable engagement deliverables include a clear remediation roadmap that tells the client what to fix first, what to fix second, and what they can accept as residual risk.

Remediation priority is typically driven by three factors: severity (how bad is the worst-case impact), exploitability (how easy is it for an attacker to reach and use this finding), and exposure (is this internet-facing or only reachable from inside). A critical finding on an internet-facing service gets fixed immediately. A critical finding reachable only from a highly restricted internal network segment can be scheduled for the next maintenance cycle.

The re-test — confirming remediation worked

Most engagements include a re-test component — a follow-up assessment after the client has had time to remediate, confirming that the fixes actually work. Re-tests are not just good business practice. They are genuinely valuable: organisations frequently apply incomplete fixes, fix the symptom rather than the cause, or remediate in one environment while leaving the same issue in another.

A finding marked as "remediated" in a re-test carries real weight — it tells the client their fix was independently verified rather than self-assessed. A finding that recurs in a re-test or appears in a slightly different form suggests the root cause was not addressed. The re-test finding is often more useful to the client than the original finding because it reveals something about the organisation's remediation process that the initial report could not.

Quiz