CISSP
Domain 6 · 12%
Security Assessment and Testing
How you find out the controls from the other seven domains actually work — and prove it to an auditor. The exam distinguishes assessment types carefully; knowing which one answers which question is most of this domain.
Assessment types
- Vulnerability assessment/scanning — automated, broad, identifies known weaknesses (missing patches, misconfigurations). Cheap, frequent, doesn't prove exploitability.
- Penetration testing — authorized, goal-directed attempt to exploit weaknesses, proves real-world impact. Needs a signed rules of engagement document (scope, timing, authorized techniques, emergency contacts) before anything starts.
- Red team / blue team / purple team — red attacks, blue defends and detects, purple is the deliberate collaboration between them to close the loop (attack technique → detection gap → fix).
- Security audit — formal, evidence-based verification against a standard (internal or third-party/external, e.g. for SOC 2 or PCI DSS attestation).
Test knowledge strategies
- Black box — no internal knowledge, simulates an external attacker.
- White box (crystal box) — full knowledge (source code, architecture diagrams) — most thorough, fastest to find deep issues.
- Gray box — partial knowledge (e.g. a standard user account) — simulates an insider or a post-phishing attacker; the most common real-world engagement type.
Software and code assessment
- SAST (Static Application Security Testing) — analyzes source code without executing it; catches issues early, generates false positives, can't find runtime-only issues.
- DAST (Dynamic Application Security Testing) — tests a running application from the outside, like an attacker would; finds real runtime issues, no source access needed, later in the cycle and slower.
- IAST — instruments the running app to combine visibility from both; SCA (Software Composition Analysis) — specifically targets known-vulnerable third-party/open-source dependencies.
- Fuzzing — feeds malformed/random input to find crashes and unexpected behavior, especially effective for memory-safety bugs.
Operational assessment
Log review (manual or automated correlation of system/security logs), synthetic transactions (scripted, known-good actions run continuously to verify a system behaves correctly — also doubles as uptime monitoring), misuse case testing (deliberately test how the system responds to abuse, not just intended use), and interface testing (APIs, UI, physical interfaces — each is a separate attack surface to verify).
Metrics and reporting
A security program needs to show trend, not just point-in-time state: KPIs (e.g. mean time to detect/respond, patch compliance %, phishing click rate) tracked over time, rolled up for different audiences — technical detail for the security team, risk-framed summary for the board. Test/audit results should always produce a documented, prioritized remediation plan with owners and dates, not just a findings list.