Security Testing Planning
Security Testing Planning
Planning is where the exam expects you to show that security testing is risk-driven and traceable, not a generic scan bolted onto the end of a project. The plan must state what will be tested, against which threats, with which techniques, and when testing is complete.
Core rules
- Prioritise by risk: business value of the asset × threat likelihood × impact. A plan that tests everything equally has no priorities.
- Derive security requirements from three sources: legal and regulatory (GDPR, PCI DSS), standards and contracts (ISO/IEC 27001, OWASP ASVS), and threat modelling of the specific system (for example STRIDE). Requirements must be testable - "accounts lock after five failed logins", not "the system shall be secure".
- A security test plan adds to a normal test plan: attack-surface inventory, threat-model reference, test types (SAST, DAST, penetration test, social-engineering simulation), rules of engagement, environment and data constraints, tooling, reporting and disclosure route, entry and exit criteria, and acceptable residual risk.
- Shift left: threat modelling at design, SAST in the build pipeline, DAST in system test, independent penetration testing before release, and periodic production checks.
- ISO/IEC 29119 supplies the documentation skeleton; the security-specific content is layered onto it.
Worked example
An online bank plans testing for its transfer function. Threat modelling identifies credential stuffing, session hijacking and parameter tampering. The plan assigns SAST to the authentication module, DAST to the transfer endpoint, a grey-box manual penetration test to session management and object-level authorization, and a rate-limiting test to the login service. Phishing simulation is declared out of scope. Exit criterion: no open critical or high finding; mediums accepted only with a named compensating control. The reasoning is traceability - every significant threat maps to at least one technique, and every technique has a completion criterion.
Traps
Writing "test the OWASP Top 10" without mapping items to this system; equating security testing with a single pre-release penetration test; confusing a security requirement with a control; forgetting that security tests can affect availability and performance.