Domain 6 of 8 · Chapter 2 of 5

Security Control Testing

The model: identify, then validate, then judge

Every control-testing technique sits somewhere on one spectrum, from examining a control to exploiting a weakness in it, and where a technique falls decides what evidence it produces. A vulnerability scan reports that a flaw may exist; a penetration test confirms it by actually exploiting it. Pick the technique by the depth of evidence the question demands, and you answer what a control (a safeguard that reduces risk, see Controls Selection) is really doing instead of what it claims to do.

One spectrum, three depths

Every control-testing technique sits somewhere on a spectrum from examining a control to exploiting a weakness. NIST SP 800-115[1], the Technical Guide to Information Security Testing and Assessment, organizes the techniques into three categories that map onto that spectrum (the figure groups the techniques in each, left to right from examine to exploit):

  • Review techniques: examination, generally manual and passive: documentation review, log review, ruleset review, system-configuration review, network sniffing, and file-integrity checking. They evaluate a control without touching its attack surface.
  • Target identification and analysis techniques: mostly automated discovery: network discovery, port and service identification, vulnerability scanning, and wireless scanning. They find and enumerate what is present and what might be weak.
  • Target vulnerability validation techniques: active confirmation: penetration testing, password cracking, social engineering, and application security testing. They prove a weakness is real by exercising it.

The categories are cumulative, not competing. NIST is explicit that no single technique gives a complete picture, so a real assessment combines them: review to understand the control, scanning to find candidate weaknesses, and validation to confirm the ones that matter.

The three assessment methods

Underneath the techniques are three assessment methods, also from SP 800-115, and exam stems use these exact words:

  • Testing exercises one or more objects under specified conditions to compare actual versus expected behavior (a synthetic transaction, a fuzzing run).
  • Examination checks, inspects, reviews, observes, or analyzes objects to obtain evidence (log review, code review, compliance checks).
  • Interviewing holds discussions with people to clarify or locate evidence.

The practical takeaway is that much of control testing is non-destructive examination, not exploitation, and choosing examination when it answers the question avoids the cost and risk of an active test.

The distinction the exam turns on

The one comparison CISSP returns to repeatedly is vulnerability assessment versus penetration test, and the difference is the identify-vs-exploit line NIST draws (the scanner reports a possible flaw; the penetration test's attack phase exploits it to confirm[1]). What that buys you differs sharply: a vulnerability assessment answers "what weaknesses might exist?" with broad, repeatable, low-risk coverage but false positives to triage, while a penetration test answers "can this actually be breached, and how far?" with narrower but validated, low-false-positive evidence, at the cost of labor and the real possibility of disrupting the target. So the choice is not which is better but which question you are funding.

Review techniquesdocumentation review, log review, ruleset review,system-configuration review, network sniffing, file-integrity checkingTarget identification and analysis techniquesnetwork discovery, port and service identification,vulnerability scanning, wireless scanningTarget vulnerability validation techniquespenetration testing, password cracking,social engineering, application security testingexamineexploit
Techniques sort into three categories on an examine-to-exploit spectrum (NIST SP 800-115).

How each technique works

A stem rarely names a technique; it describes an activity, and the right answer turns on matching that activity to the correct named method. Building on the identify-then-validate model above, here are the mechanics of each major technique.

Vulnerability assessment

A vulnerability assessment runs automated scanners that compare a host's services, applications, and operating systems against vulnerability databases (such as the National Vulnerability Database[2]) and reports ranked potential weaknesses. Credentialed (authenticated) scanning logs into the target and sees installed patch levels and configuration, giving far fewer false positives than an unauthenticated scan that only probes from the network. Because scanners flag possible flaws, their output always needs human triage to separate true findings from false positives before remediation.

Penetration testing and its four phases

A penetration test mimics a real attacker to confirm exploitability. NIST SP 800-115[1] divides it into four phases (see the figure): Planning sets the rules of engagement, scope, and written management authorization and does no testing; Discovery gathers information and scans to identify targets and analyze candidate weaknesses; Attack attempts to exploit them, and on success loops back to Discovery as a new foothold reveals more targets (privilege escalation, pivoting); Reporting runs concurrently and ends in a report of findings, risk ratings, and mitigations. Knowledge of the target also defines the test: black-box (zero prior knowledge, simulating an outsider), white-box (full knowledge: architecture, source, credentials), and gray-box (partial knowledge, e.g. a standard user account).

Red, blue, and purple teams

A red team[3] is authorized to emulate an adversary's attack capabilities against the organization's security posture; the blue team is the defenders who monitor, detect, and respond. A purple team is a collaboration mode, not a separate group: red and blue work together so each attack technique is immediately translated into a detection or response improvement. The defining property of a red-team engagement is that, unlike a scheduled scan, it also measures whether the blue team can detect and respond.

Breach and attack simulation

Breach-and-attack simulation (BAS) tools continuously and automatically replay known adversary techniques against live defenses to verify, on an ongoing basis, that controls actually detect and block them, closing the gap between point-in-time penetration tests, which capture only a single moment.

Code review and testing

Custom software is tested by analyzing the code and the running application:

Technique Runs the code? Sees source? Strength Limit
SAST (static) No Yes Early, points to the exact line Misses runtime/config flaws; false positives
DAST (dynamic) Yes No Finds runtime and deployment flaws Cannot pinpoint the offending code
IAST (interactive) Yes Yes (instrumented) Combines both views Needs instrumentation in the running app
Manual code review No Yes Catches logic/design flaws tools miss Slow, expertise-dependent

Fuzzing (fuzz testing[4]) submits malformed or unexpected input to a running target to reveal how it responds, exposing input-handling defects like buffer overflows. Misuse-case testing inverts the use case: instead of verifying intended behavior, it tests how the system behaves under deliberate abuse, modeling what an attacker would do.

Examination and monitoring techniques

  • Log review determines whether controls are logging the proper information and the organization adheres to its logging policy. For example, confirming all authentication attempts to critical servers are recorded at the required detail. It is examination, not a test, and can surface misconfigurations and intrusion attempts after the fact.
  • Synthetic transactions run scripted, pre-defined interactions (a login, a checkout) against a live system on a schedule to confirm it responds correctly; real user monitoring (RUM) instead captures actual user interactions passively.
  • Interface testing exercises the connection points between components (APIs, web service endpoints, and inter-system boundaries) to confirm they behave and fail securely.
  • Test coverage analysis measures how much of a target the tests actually exercised (e.g. statement, branch, or condition coverage for code; requirements coverage for controls) so gaps in what was not tested are visible.
  • Compliance checks verify configurations against a required baseline or benchmark, confirming the implemented state matches the mandated one.
PlanningDiscoveryAttackadditional discovery (loop)Reporting (concurrent, all phases)
The four penetration-testing phases run in order, Attack loops back to Discovery, and Reporting runs concurrently (NIST SP 800-115).

Exam-pattern recognition

CISSP dresses the techniques above up in stems where the right answer hides among plausible distractors, and each recurring pattern has a tell that singles out the correct method and explains why the distractors fail.

Pattern 1: vulnerability assessment vs penetration test

When a stem says the goal is to confirm a weakness can actually be exploited, or to measure how far an attacker could reach, the answer is penetration testing, not a vulnerability scan. The scan reports only that a flaw may exist. The mirror trap is choosing a penetration test when the goal is broad, low-risk, repeatable enumeration across many hosts: that is a vulnerability assessment. Match the verb in the stem: identify/enumerate points to assessment, exploit/confirm/breach points to a pen test.

Pattern 2: what to do FIRST in a penetration test

When a stem asks what must happen before a penetration test begins, the answer is obtaining written management authorization / rules of engagement (the Planning phase), never "start scanning" or "begin the attack." Testing a system without documented authorization is the trap, and in CISSP framing it is indistinguishable from an actual attack. Scope, timing, and a point of contact are all fixed in Planning before any tool runs.

Pattern 3: who and what a red team really tests

When a stem emphasizes measuring detection and response (can the SOC see the attack and react?) the answer involves a red team (often unannounced), not a vulnerability scan, because a scheduled, visible scan never exercises the defenders. If the stem describes red and blue working together to improve detection in real time, that is a purple team, a collaboration mode, not a separate group. The trap is calling any penetration test a "red team"; the red-team distinction is the adversary-emulation-plus-detection-test focus.

Pattern 4: SAST vs DAST vs the rest

When a stem describes analyzing source code without running it and finding the exact vulnerable line early in development, the answer is SAST (static). When it describes testing the running application from the outside with no source, it is DAST (dynamic). When it describes feeding malformed/random input to crash a program and expose input-handling defects, it is fuzzing. The trap is picking SAST for a runtime/configuration flaw it structurally cannot see, or DAST when the stem wants the offending line of code DAST cannot pinpoint.

Pattern 5: examination methods masquerading as tests

When a stem asks whether a control is recording the right events or adhering to logging policy, the answer is log review (examination), not active testing. When it describes scripted, pre-defined transactions run on a schedule to confirm a live system responds correctly, that is synthetic transactions; passively capturing real user activity is real user monitoring. When it asks how much of the target the tests actually exercised, that is test coverage analysis, and the trap is treating high coverage as proof of security rather than proof of what was examined.

Vulnerability assessment vs penetration testing

DimensionVulnerability assessmentPenetration test
Core questionWhat weaknesses might exist?Can a weakness actually be exploited, and how far?
DepthIdentifies and ranks potential flaws (no exploitation)Exploits flaws to confirm them and chain access
Coverage vs precisionBroad coverage, may include false positivesNarrower, validated, low false positives
Effort / risk to systemsLargely automated, low risk, repeatableLabor-intensive, can disrupt or damage systems
Tests detection/response?No, scan is scheduled and visibleYes, especially an unannounced red-team engagement
Typical outputRanked list of weaknesses to remediateProven attack paths with risk ratings and mitigations

Decision tree

Testing custom-builtcode?YesNoSAST / DAST / fuzzingSAST for the line; DAST on therunning app; fuzzing for input flawsConfirm a weakness isactually exploitable?NoYesVerify a control logs /behaves correctly?YesNoLog review /synthetic transactionsexamination, non-destructiveVulnerability assessmentenumerate and rank weaknesses;no exploitationAlso test detectionand response?NoYesPenetrationtestRed team(often un-announced)Always: written authorization (rules of engagement) before any active test
Cheat sheet

Sharp facts the exam loves — give these one last read before exam day.

Cheat sheet

Sharp facts the exam loves — scan these before test day.

A vulnerability assessment identifies weaknesses; a penetration test exploits them

A vulnerability assessment enumerates and ranks weaknesses but stops at reporting that a flaw may exist; a penetration test goes further and exploits the flaw to confirm it is real and show how far an attacker reaches. NIST puts it directly: a vulnerability scanner checks only for the possible existence of a vulnerability, while the attack phase of a pen test exploits it to confirm its existence. Pick the assessment by the question asked: "what is exposed?" wants an assessment, "can it be breached?" wants a pen test.

Trap Choosing a penetration test for broad, repeatable enumeration across many hosts: that low-risk coverage is a vulnerability assessment, not an exploit-and-confirm pen test.

6 questions test this
A penetration test runs four phases: Planning, Discovery, Attack, Reporting

NIST SP 800-115 divides a pen test into Planning (set rules of engagement, scope, written authorization, no testing happens here), Discovery (information gathering and scanning to find targets), Attack (exploit the weaknesses), and Reporting (deliver findings and risk ratings). Reporting runs concurrently with the other phases rather than only at the end, and Attack loops back to Discovery whenever a new foothold reveals more targets.

Trap Assuming Reporting happens only at the very end after Attack finishes, when NIST has reporting run concurrently throughout the engagement.

Get written authorization before any penetration test begins

The first action in a penetration test is the Planning phase: obtain documented management authorization and rules of engagement defining scope, timing, and a point of contact before any tool runs. Without that written authorization the same activity is indistinguishable from a real attack and is potentially illegal. No actual testing occurs during Planning.

Trap Starting scanning or exploitation before authorization is signed: in CISSP framing an unauthorized test is an attack, regardless of intent.

4 questions test this
The attack phase loops back to discovery as new footholds appear

When an exploit succeeds, the tester often gains a foothold that exposes new internal targets, so the Attack phase feeds back into Discovery: escalating privileges, pivoting to other systems, and re-scanning from the new vantage point. This loopback is why a pen test measures how far an attacker could chain access, not just whether one isolated flaw is exploitable.

2 questions test this
Black-, white-, and gray-box define how much the tester knows up front

Black-box testing gives the tester zero prior knowledge, simulating an external attacker; white-box gives full knowledge such as architecture, source code, and credentials, for the most thorough coverage; gray-box gives partial knowledge, like a standard user account. More knowledge trades realism of an outsider's view for depth and efficiency of coverage.

Trap Confusing the knowledge levels by picking white-box to simulate an outside attacker, when zero-knowledge black-box is the one that models an external threat.

A red team emulates the adversary; the blue team defends; purple is collaboration

A red team is authorized to emulate a real adversary's attack capabilities against the organization's defenses, while the blue team is the defenders who monitor, detect, and respond. A purple team is not a separate group but a mode where red and blue work together so each attack technique immediately drives a detection or response improvement. The defining feature of a red-team engagement is that, unlike a scheduled scan, it also tests whether defenders can detect and respond.

Trap Calling every penetration test a "red team": the red-team label specifically means adversary emulation that also exercises the blue team's detection and response.

7 questions test this
SAST analyzes code without running it; DAST tests the running app from outside

Static application security testing (SAST) examines source, bytecode, or binaries without executing them, so it runs early and points to the exact vulnerable line, but it misses runtime and configuration flaws and produces false positives. Dynamic application security testing (DAST) tests the running application from the outside with no source access, so it catches runtime and deployment issues but cannot pinpoint the offending code. Interactive testing (IAST) instruments the running app to combine both views.

Trap Picking SAST to catch a runtime or misconfiguration flaw it structurally cannot see, or DAST when the stem wants the exact offending line that only source analysis reveals.

4 questions test this
Fuzzing feeds malformed input to a running target to expose input-handling defects

Fuzz testing submits invalid, unexpected, or random input to a running program to reveal how it responds, surfacing input-handling defects such as buffer overflows and crashes. It is a dynamic technique run by tools called fuzzers, and it is most valuable for code paths that parse external input where validation may be incomplete.

Trap Classifying fuzzing as a static, source-analysis technique, when it is a dynamic technique that requires actually executing the target against malformed input.

Misuse-case testing verifies behavior under abuse, not just intended use

Where a use case describes how a system should behave for a legitimate user, a misuse case models what an attacker would deliberately do to abuse it, and misuse-case testing verifies the system resists that abuse. It complements normal functional testing by asking how the system fails under hostile input rather than only confirming it works under expected input.

Trap Confusing a misuse case with a use case, treating it as just another positive functional scenario instead of the adversary's deliberate abuse of the system.

4 questions test this
Synthetic transactions script known interactions; RUM captures real user activity

Synthetic transactions run scripted, pre-defined interactions (a login, a search, a checkout) against a live system on a schedule to confirm it responds correctly and on time, independent of real traffic. Real user monitoring (RUM) instead passively captures actual user interactions as they happen. Use synthetic transactions to proactively verify availability and behavior even when no real users are active.

Trap Reaching for real user monitoring to proactively verify availability when no real users are active, a job only scheduled synthetic transactions can do.

Interface testing exercises the connection points between components

Interface testing targets the boundaries where components connect (APIs, web service endpoints, and inter-system handoffs) to confirm they accept, reject, and fail securely. These integration points are a common source of defects because each side may assume the other validated the data, so testing them directly catches gaps neither component's internal tests would find.

Trap Reading interface testing as exercising the graphical user interface, when it targets the API and inter-system connection points between components.

2 questions test this
Test coverage analysis measures how much of the target the tests exercised

Test coverage analysis quantifies how much of a target the tests actually exercised (statement, branch, or condition coverage for code, or requirements coverage for controls) so the gaps in what was not tested become visible. It answers "what did we miss?" rather than "did the tested parts pass?"

Trap Treating high test coverage as proof the system is secure: coverage measures only what was examined, not that the exercised code is free of flaws.

Breach-and-attack simulation continuously replays adversary techniques against live defenses

Breach-and-attack simulation (BAS) tools automatically and continuously replay known adversary techniques against production defenses to verify on an ongoing basis that controls detect and block them. BAS closes the gap left by point-in-time penetration tests, which capture only a single moment, by turning detection-and-response validation into a continuous, repeatable check.

Trap Equating breach-and-attack simulation with a point-in-time penetration test, when its defining value is continuous, repeatable validation rather than a single snapshot.

2 questions test this
Log review verifies controls record the right events, not that they block attacks

Log review is an examination technique that determines whether security controls are logging the proper information and whether the organization adheres to its logging policy, for example, confirming that all authentication attempts to critical servers are recorded at the required detail. It can also surface misconfigurations, unauthorized access, and intrusion attempts after the fact, but it evaluates evidence rather than actively exploiting a weakness.

Trap Classifying log review as a testing technique that actively exploits or blocks attacks, when it is an examination method that evaluates recorded evidence after the fact.

3 questions test this
Compliance checks verify the implemented state matches a required baseline

A compliance check compares a system's actual configuration against a mandated baseline or benchmark and reports where they diverge, confirming the implemented state matches the required one. It is a verification of conformance to a defined standard, distinct from a vulnerability assessment that hunts for unknown weaknesses regardless of any baseline.

Trap Treating a compliance check as a vulnerability assessment, when it measures conformance to a defined baseline rather than hunting for unknown weaknesses.

2 questions test this
Testing, examination, and interviewing are the three assessment methods

NIST SP 800-115 defines three assessment methods: testing exercises an object under specified conditions to compare actual against expected behavior; examination checks, inspects, reviews, or analyzes objects to obtain evidence; interviewing holds discussions with people to clarify or locate evidence. Because no single technique gives a complete picture, a sound assessment deliberately combines methods rather than relying on one.

Trap Confusing examination with testing, when only testing actively exercises an object under specified conditions while examination merely inspects and reviews it for evidence.

Credentialed scanning sees patch and configuration state; unauthenticated scanning only probes

A credentialed (authenticated) vulnerability scan logs into the target and reads installed patch levels and configuration, yielding far fewer false positives than an unauthenticated scan that only probes from the network. Either way scanner output flags possible flaws and always needs human triage to separate true findings from false positives before remediation.

Trap Assuming an unauthenticated network scan is more accurate than a credentialed one, when reading patch and configuration state from inside the host is what cuts false positives.

8 questions test this
Combine techniques because no single one gives a complete security picture

NIST is explicit that no individual testing technique provides a comprehensive view of a system's security, so assessments should layer them: review to understand a control, scanning to find candidate weaknesses, and validation to confirm the ones that matter. Relying on a single method (only a scan, or only a pen test) leaves predictable blind spots.

Trap Assuming a single thorough method such as a penetration test gives a comprehensive security picture, when NIST says no individual technique covers all blind spots.

SCAP standardizes machine-readable config and vulnerability checking

The Security Content Automation Protocol (SCAP) is a NIST suite of interoperable specifications that lets tools from different vendors express and check security configuration and vulnerability data in machine-readable form. XCCDF describes the checklist and benchmark of requirements, while OVAL defines the low-level technical checks that determine whether a system meets them.

Trap XCCDF is the human-level checklist language; OVAL is the low-level check logic the scanner executes.

8 questions test this
CIS Benchmark Level 1 is a usable baseline; Level 2 is defense-in-depth

CIS Benchmarks ship two profiles. Level 1 is the base recommendation that lowers attack surface with minimal performance or usability impact, suitable for general systems. Level 2 is intended for environments where security is paramount, adding more stringent settings that may require application changes and can affect functionality.

Trap Level 2 is not 'better and always preferred'; its stricter settings can break functionality, so general workstations use Level 1.

4 questions test this
SIEM correlation requires normalizing logs to a common schema first

Different log sources name and format the same data differently (for example a user as 'jsmith' versus 'john.smith@company.com', or varying timestamp and IP field names). A SIEM must normalize these into a standardized schema or common information model so events can be compared and correlated across sources; without normalization, cross-source correlation rules fail.

Trap Normalization fixes inconsistent field names/formats; out-of-order or skewed timestamps are a separate problem solved by time synchronization (NTP).

6 questions test this
SIEM event correlation turns isolated events into a single incident

Event correlation links related events from multiple sources by common attributes (user, host, IP, time window) so that activity that looks benign in isolation becomes a recognizable incident when combined. It is what enables detection of multi-stage attacks and timeline reconstruction across diverse logs.

Trap An alert that looks weak alone is not necessarily a false positive; the cure is correlation for context, not suppression.

7 questions test this
Tune correlation rules and add exceptions to cut SIEM false positives

When a rule floods analysts with alerts that investigation confirms are benign (for example a service account doing legitimate automated work), the right fix is to tune the rule and add a scoped exception or allow-list for the validated source, adjusting thresholds to the organization's use cases. This preserves detection while reducing alert fatigue.

Trap Tune or scope an exception for the validated source; do not disable the whole rule, which would blind the control.

3 questions test this
Pivoting routes through a compromised host to reach internal segments

After gaining a foothold, a tester uses pivoting to route traffic through the compromised system and reach internal networks that are not directly accessible from the attack platform (for example via a Meterpreter session). In PTES this enumeration of additional subnets and onward access happens in the post-exploitation phase.

Trap Pivoting reaches otherwise unreachable internal segments; it is a post-exploitation activity, not the initial exploitation step.

5 questions test this
Scope defines WHAT is tested; rules of engagement define HOW

In pre-engagement, two distinct documents govern a penetration test. The scope document explicitly identifies which systems, networks, and IP ranges are authorized targets, while the rules of engagement (RoE) set the constraints on how testing is conducted, including the degree of exploitation permitted and procedures after a system is compromised. NIST treats the RoE as the authority that lets the team act without seeking further permission mid-test.

Trap Scope = what; rules of engagement = how. The degree of exploitation allowed belongs in the RoE, not the scope.

7 questions test this
An out-of-scope discovery means stop, document, and notify, not exploit

If a tester encounters a system or vulnerability outside the authorized scope (for example a third-party-owned host), professional standards require ceasing activity against it, documenting only what was already observed without further probing, and notifying the engagement authority so additional authorization or a new statement of work can be obtained before any further testing.

Trap Exploiting an out-of-scope finding to prove impact; testing outside the agreed scope creates legal exposure regardless of intent.

4 questions test this

Also tested in

References

  1. NIST SP 800-115, Technical Guide to Information Security Testing and Assessment Whitepaper
  2. NIST National Vulnerability Database (NVD) Whitepaper
  3. NIST Computer Security Resource Center, Glossary: Red Team (CNSSI 4009-2015) Whitepaper
  4. NIST Computer Security Resource Center, Glossary: Fuzz Testing (SP 800-95) Whitepaper