Memory hook: Test the requirement; report the business consequence.
Must remember
Define scope, criteria, independence, authorization, frequency and reporting before an assessment. Internal reviews provide organizational context; external independent reviews provide another assurance perspective. Sampling reduces effort but limits what conclusions can be drawn.
Testing methods answer different questions. Code review and SAST inspect implementation; DAST exercises a running system; IAST combines runtime observation with instrumentation; composition analysis examines dependencies. Fuzzing explores unexpected inputs. Synthetic transactions test a known business path; misuse cases test forbidden behavior. Coverage metrics reveal what was exercised, not proof that untested behavior is safe.
A red team pursues objectives within authorization; a blue team defends; purple-team collaboration improves detection and response from shared learning. Penetration tests are scoped snapshots and can miss vulnerabilities. Breach simulations validate selected paths without representing every possible adversary.
Gather technical and administrative evidence: access reviews, change approvals, backups/restores, detection performance, training outcomes and continuity exercises. A control can be well designed yet poorly operated; test both. Distinguish key performance indicators (how a process performs) from key risk indicators (signals of increasing exposure).
Findings should state condition, criteria, cause, impact, evidence and recommended treatment. Confirm false positives, prioritize by risk, assign owners and due dates, then retest. Track accepted exceptions and their expiry. Ethical disclosure follows legal authorization and coordinated reporting, not public release of exploitable details without considering affected parties.
Audit reports differ in intended audience, scope and time period. Read exclusions and customer responsibilities before relying on a supplier report. A polished report is only as useful as its criteria, evidence and follow-through.
Choose under exam pressure
| Requirement | Choice and reason |
|---|---|
| Prove a control operated over time | Review time-bound evidence and representative samples. |
| Find risky dependency versions | Software composition analysis and provenance review. |
| Improve detection after an exercise | Translate observed gaps into owned changes and retest. |
Traps
- High code coverage does not prove secure behavior.
- An external audit is not a guarantee that every system is secure.
Active recall
1. Design effectiveness versus operating effectiveness?
A control may be suitable in design but fail to run reliably in practice.
2. What does SCA inspect?
Software components/dependencies, including version and known-risk information.
3. What should a finding connect to?
Evidence, applicable criteria and business/security impact.
4. Why retest a closed finding?
To verify that the intended risk was actually reduced.
5. What is a key limitation of penetration testing?
Its scope, timing and techniques limit the conclusions; it cannot prove absence of all flaws.