D6 — Security Assessment & Testing

If you coordinate audits or pentests, this domain is largely about giving precise names to distinctions you already make instinctively — which test type answers which question, and why "we ran a scan" and "we did an audit" are not interchangeable claims.

The knowledge spectrum: black-box, gray-box, white-box

Testing approaches differ by how much the tester knows going in:

• Black-box — zero prior knowledge, no credentials, no architecture diagrams. Models an external, uninformed attacker. Most realistic simulation of an outside threat, but slower and may miss internal-only issues.
• Gray-box — partial knowledge or limited credentials. A common practical middle ground: enough access to test meaningfully without the full internal picture.
• White-box — full knowledge: source code, architecture, credentials. Most efficient and thorough, but least representative of what an external attacker actually faces.

There's no universally "best" choice — it depends on what question the test is answering. A test meant to validate "could an anonymous internet attacker get in" needs black-box; a test meant to find every logic flaw in a specific application as fast as possible benefits from white-box.

Three different deliverables, often confused

• Vulnerability assessment — identifies and catalogs known vulnerabilities (via scanning tools, version checks, misconfiguration detection). Broad coverage, doesn't attempt exploitation, produces a prioritized list.
• Penetration test — actively attempts to exploit vulnerabilities to demonstrate real-world impact, often chaining multiple weaknesses together. Narrower scope than a vulnerability assessment, but proves exploitability rather than just flagging possibility.
• Security audit — verifies compliance against a defined standard, policy, or framework (which is exactly the discipline this platform's ISO 27001 Lead Auditor track covers in full depth) — a fundamentally different goal from either of the above: not "what's vulnerable" or "what's exploitable," but "does this conform to what we said we'd do."

A report that says "we ran a vulnerability scan" is not equivalent to "we conducted a penetration test," and neither is equivalent to "we passed an audit" — each answers a genuinely different question, and a scenario question testing whether you can tell them apart is testing exactly this distinction, not just vocabulary recall.

SAST vs DAST — complementary, not competing

• SAST (Static Application Security Testing) — analyzes source code or binaries without executing them. Catches issues early (before deployment), sees the full codebase including unreached code paths, but produces more false positives and can't catch runtime-only issues (e.g. misconfigurations that only manifest when the application is actually running).
• DAST (Dynamic Application Security Testing) — tests a running application from the outside, the way an actual attacker would interact with it. Catches runtime and configuration issues SAST can't see, but only tests code paths actually exercised during the scan, and happens later in the pipeline (the application has to be running).

Neither replaces the other — a mature secure-development pipeline runs both, because each catches a different class of issue the other structurally cannot.

The CISSP mindset: manager vs technician

Leadership asks whether the company's new customer portal is "secure enough to launch." The team runs an automated vulnerability scan, finds no critical findings, and reports the portal is ready.

The technician answer: the scan is clean, ship it — the tool did its job and found nothing severe.

The manager (CISSP) answer: ask what question "secure enough to launch" is actually asking, and whether a vulnerability scan answers it. A clean vulnerability scan means no known, scannable issues were detected — it says nothing about business-logic flaws, chained exploitation paths, or whether the application actually resists a motivated attacker, none of which automated scanning reliably catches. If the launch decision carries real stakes, the CISSP-correct answer is matching the assessment type to the actual question: a penetration test (to test exploitability) or an audit against a defined security standard (to test conformance), not treating a vulnerability scan's clean result as proof of something it was never designed to prove.