Domain 6 · Objective reference 6.2 · Chapter 39 of 62
Choose and execute security-control tests
About 5 minutes · Current ISC2 outline effective 15 April 2024; the announced 15 April 2027 replacement requires separate mapping
Session only. Enable saving or download a backup from this course’s hub.
Completion is self-reported and does not certify understanding.
See it · Try it · Recall it
Picture the topic
Remember this: Different tests observe different failure modes.
Explore the anchors
Examine code or configuration without execution.
Concept matching activity
Match this task or description to its concept:
Observe running behavior under selected inputs.
Choose a concept before checking the explanation.
A quick way to study this topic
- Hide the explanation and redraw these three anchors from memory.
- Explain the difference between the anchors in your own words.
- Apply the distinction to the worked example below. Check the full lesson for assumptions and exceptions.
- Recall it again tomorrow, then after a few days. A memory hint is a retrieval cue, not a replacement for understanding.
Original academy illustrations and fictional exercises. These are learning simulations, not a real virtual machine, network assessment or measure of job readiness. Activities reset when you leave or reload; they do not change quiz scores.
What this chapter explains
- Concepts and mechanisms
- Design, evidence and tradeoffs
- Choose a test for the assurance question
Concepts and mechanisms
Control testing can use configuration review, log review, synthetic transactions, code review, static and dynamic application methods, vulnerability assessment, penetration testing or approved simulations. A test should specify expected and rejected behavior. Misuse cases explore how a legitimate function can violate a business rule. Interface testing includes APIs and network paths, not only the visible user interface.
Design, evidence and tradeoffs
Validate automated findings and their deployment context. Coverage analysis identifies which requirements, populations and paths were exercised and which remain untested. Red, blue and purple exercises have different collaboration and evaluation purposes. Use controlled accounts and data, minimum-impact validation and explicit stop conditions. After remediation, retest the original condition and relevant alternate paths, not only the patch ticket.
Choose a test for the assurance question
Synthetic transactions test defined service paths; benchmarks measure performance under stated conditions. Misuse cases examine inappropriate behavior, interface tests exercise boundaries, and coverage analysis asks what was actually exercised. SAST inspects code or related artifacts without executing the application, DAST probes a running application and IAST combines runtime context with instrumentation. Software composition analysis examines dependencies and their known issues. Breach-and-attack simulation and red/blue/purple exercises have different objectives and constraints. Authorization, safety limits, realistic assumptions and follow-up verification remain necessary regardless of tool branding.
Worked example
Two synthetic tenants test that each can read its own invoice and is denied the other tenant’s invoice through both browser and export APIs.
Check your understanding
Why does passing a happy-path test not establish authorization correctness?
Show explanation
It shows a permitted action works but does not establish that forbidden actions and alternate paths are denied.
Source and study boundary
Official syllabus source. The reference identifies the topic being taught. Explanations and examples are original academy material; a topic link does not establish independent approval or sufficient exam mastery.