Security Assessment and Testing
Security Assessment and Testing asks you to choose the right assessment for a question, design coverage that actually exercises controls, and interpret results without over-trusting a number. Items frequently contrast two similar activities or ask what evidence a given report provides.
Name the activity correctly
- Vulnerability assessment is breadth-first: enumerate known weaknesses, no exploitation.
- Penetration test is goal-oriented exploitation under written rules of engagement and scope, protected by a get-out-of-jail letter.
- Audit evaluates evidence against defined criteria and requires independence.
- Control testing distinguishes design effectiveness (is the control capable?) from operating effectiveness (did it run over the period?).
Reports and evidence
SOC 1 covers controls relevant to financial reporting; SOC 2 covers trust services criteria; SOC 3 is a public summary without detailed test results. Type I reports design suitability at a point in time; Type II reports operating effectiveness over a period. Sampling supports conclusions about populations, so coverage and sample rationale must be documented.
Techniques
SAST reads source and finds data-flow flaws early but cannot see runtime configuration. DAST attacks a running application and finds configuration and authentication issues but cannot see the code. IAST instruments runtime, SCA inspects dependencies, fuzzing feeds malformed input, and code review catches logic flaws scanners miss.
Worked example
Two findings land the same day: CVSS 9.8 in an internal developer-only service, and CVSS 7.2 in the internet-facing payment API reachable before authentication. Ranking purely by base score puts the internal issue first. Context changes it: the payment API is externally reachable, pre-auth, and touches cardholder data, while the internal service sits behind network controls with no sensitive data. Remediate the payment API first. The reasoning: CVSS is base severity, not organisational risk, and prioritisation uses exposure, exploitability, data sensitivity, and compensating controls.
Traps that cost marks
- Calling a penetration test an audit, or vice versa.
- Mixing up Type I (point in time, design) and Type II (period, operating effectiveness).
- Reading a clean scanner report as proof that no vulnerabilities exist.
- Testing production without written authorisation and scope.
- Closing findings without retesting the fix.