Security testing and assessment methodology
Security testing and assessment methodology
This domain tests whether you can plan and govern an assessment rather than just run tools: how you agree scope, select a methodology, justify coverage, and keep the work lawful, reproducible and defensible if it is later challenged in a report or a courtroom.
Core rules and concepts
- Authorisation precedes everything. Written permission, signed rules of engagement (RoE) and a named emergency contact are prerequisites, not paperwork. Understand the Computer Misuse Act 1990 position for every host you touch, including cloud instances and systems hosted by a third party on the client's behalf.
- A methodology is a framework, not a script. PTES gives phase structure, OSSTMM gives measurable coverage, the OWASP Web Security Testing Guide covers web, and MITRE ATT&CK maps adversary behaviour. Name the one you used and state why.
- Standard phases: scoping, reconnaissance, threat modelling, discovery and enumeration, exploitation, post-exploitation, analysis, reporting, retest.
- Coverage versus depth is a commercial trade-off. With finite days you cannot exhaustively test everything. Define sampling logic and exit criteria up front so that "we tested the external estate" is a statement you can defend.
- Reproducibility: log commands, timestamps, source IPs and tool versions as you work. Evidence assembled after the engagement is weaker and harder to verify.
Worked example
A client asks for "a full black-box penetration test of our external estate, 200 IPs, three days." Reasoning: three tester-days cannot cover 200 hosts to any credible depth. Rather than accept the scope and silently under-deliver, propose a risk-based alternative: grey-box access for the five internet-facing applications handling personal data, full port scanning and service identification across all 200 addresses, targeted manual testing on the remainder, and an explicit statement of residual risk in the report. That converts an impossible promise into a defensible assessment with documented limitations.
Traps that cost marks
- Accepting scope without confirming which hosts are third-party hosted or out of bounds.
- Scope creep: testing a related domain "because it was reachable".
- Claiming exhaustive coverage when sampling was used.
- No documented exit criteria, so testing drifts and the report overstates assurance.
- Failing to record a change to scope mid-engagement in writing.