Domain 6 - Security Assessment and Testing

About this note

This is the expanded reference version of my original CISSP exam notes. The bullet-point original is preserved in Domain 6 - Security Assessment and Testing (Original-Stichpunkte) for comparison. Written for readers with several years of hands-on security and networking experience.

Security Assessment

A security assessment is the full-picture approach to answering one question: are our controls actually effective? Not “do we have a firewall” but “does the sum of everything we’ve built withstand what it’s supposed to withstand.” Because that question has technical, organizational, and human dimensions, an assessment deliberately opens multiple areas at once:

• politics — the organizational realities that shape (and distort) security decisions,
• real-world assessment — how things actually operate versus how the documentation claims,
• change management — whether changes flow through a controlled process or around it,
• architectural reviews — is the design sound, independent of implementation quality,
• penetration testing and vulnerability assessments — the technical probes, and
• security audits — the formal verification against a defined standard.

The assessment mindset connects back to Domain 1: assessments are how governance verifies rather than assumes. Each instrument below answers a different question, and the classic mistake is treating them as interchangeable — a clean vulnerability scan says nothing about whether your change management leaks, and a passed audit says nothing about whether an attacker gets in.

Security Audits

An audit verifies controls against a defined standard — its output is assurance for a specific audience, which is why the audit types differ mainly by who needs to trust the result. For assessing the security controls themselves, NIST SP 800-53Ar4 provides the assessment-procedures companion to the 800-53 control catalog from Domain 1 — for every control, the corresponding test.

SOC 2

SOC 2 reports (from the AICPA framework) attest a service organization’s controls against the Trust Services Criteria (security, availability, processing integrity, confidentiality, privacy). The two flavors:

• Type 1 — reports on the suitability of control design at a point in time: are the right controls in place, on paper and in configuration, today?
• Type 2 — reports on suitability and operating effectiveness over a period (typically 6–12 months): did the controls actually operate, continuously, as designed?

(The original note’s “rentability” was a typo for reliability/operating effectiveness — worth flagging because the distinction is exactly what makes Type 2 the meaningful one.) A Type 1 is a snapshot; a Type 2 is a film. When a vendor proudly presents a Type 1, the correct follow-up is asking when the Type 2 arrives — designing a control for audit day is easy, operating it for a year is the actual test. For your own vendor assessments: read the auditor’s exceptions and the scope statement before the executive summary; the interesting information is in what was excluded.

Internal and Third-Party Audits

• Structured audits are conducted by third parties — external, formal, against a defined framework, producing attestation someone outside the organization can rely on (customers, regulators).
• Unstructured audits are internal — self-assessments, typically run before the external audit to find and fix the findings while they’re still cheap. The internal audit is the dress rehearsal; treating it as adversarial preparation rather than paperwork is what separates organizations that pass external audits calmly from those that scramble.

Security Audit Logs

Log review is a detective control — it doesn’t stop anything, it makes things visible, and only if someone actually reviews. NIST SP 800-92, the log-management reference, names the primary log sources: network security software and hardware (firewalls, IDS/IPS, VPN concentrators, proxies) and operating systems (authentication events, privilege use, system events).

Centralized logging is the architectural prerequisite for all of it: logs shipped off their source systems to a central platform. Three reasons, each sufficient alone: correlation (attacks cross systems; investigations must too), integrity (an attacker who owns a box edits its local logs first — remote copies survive), and retention (central platforms enforce the retention policies Domain 2 requires). This is also where the accountability chain from Domain 5 becomes real: without intact, centralized, time-synchronized logs, “who did what” is unanswerable.

Vulnerability Scanners

Software armed with a catalog of known vulnerabilities, tested against your systems — the automated breadth instrument. What a scan delivers: known issues, misconfigurations, missing patches, at scale and repeatably. What it structurally cannot deliver: whether a finding is exploitable in your context, chained attack paths, logic flaws, or anything not in the catalog. Scan output is a to-do list sorted by CVSS, not a risk statement — turning one into the other requires the asset values and context from Domain 1’s risk assessment. That gap is precisely what the next instrument exists for.

Penetration Testing

A pen test is an authorized simulated attack answering the question the scanner can’t: are the vulnerabilities actually exploitable — individually or chained? NIST SP 800-115 — the Technical Guide to Information Security Testing and Assessment — is the reference methodology for this whole section. The two governance anchors from the original notes deserve their emphasis:

• Clear rules of engagement — scope, targets, excluded systems, permitted techniques, time windows, emergency contacts, and abort criteria, in writing, signed. The RoE document is what separates a pen test from a crime; it protects the testers legally and the business operationally.
• Senior management sets the goals — consistent with everything in Domain 1: the risk owner decides what gets tested and accepts the residual risk of testing itself (tests can break things).

The standard phases: Planning → Information Gathering and Discovery → Vulnerability Scanning → Exploitation → Reporting. The often-underrated phase is the last one: the report is the deliverable, and its value is determined by whether findings are reproducible, risk-rated in business terms, and paired with remediation guidance — a shell obtained but poorly documented helps nobody.

Knowledge models:

• Black box — testers know nothing beyond the target’s name: simulates the external attacker, spends much of the budget on discovery.
• White box — full knowledge: architecture, source, credentials. Maximum depth per testing hour; simulates the insider or the patient attacker who’s already done the recon.
• Gray box — partial knowledge; the pragmatic middle that most real engagements use.

Technique inventory (as listed in the original, with context):

• War dialing — sweeping phone ranges for answering modems; a museum piece with a live descendant: sweeping for forgotten remote access (exposed RDP/VNC, ISP-managed modems, out-of-band management).
• War driving — mapping wireless networks (Domain 4’s recon phase, from the attacker’s seat).
• Wireless testing — evaluating the risk of unauthorized access to your WLAN: crackable PSKs, evil-twin susceptibility, client certificate validation gaps.
• Client-side network attacks — targeting the users’ software (browsers, mail clients, document readers), typically delivered via phishing.
• Server-side network attacks — the classic direct route against exposed services.

Social Engineering

The attack that routes around the entire technical stack by targeting the human, and a standard component of full-scope engagements because it combines with nearly every other attack — the client-side attack above needs a click, and social engineering supplies it.

The six persuasion levers (Cialdini’s principles, weaponized):

• Authority — people comply with apparent power: the “CEO” email, the fake IT department call.
• Intimidation — compliance through threat: “your account will be terminated unless…”
• Consensus (social proof) — “everyone in your department has already confirmed…”
• Scarcity — perceived limited availability short-circuits deliberation.
• Urgency — time pressure, the universal solvent of skepticism; almost every phishing mail contains a deadline.
• Familiarity (liking) — people comply with those they know or like: rapport built over weeks, or a spoofed colleague.

The defensive reading: awareness training (Domain 1) works when it teaches people to recognize the levers, not memorize yesterday’s phishing template. “This message is pushing urgency and authority simultaneously” is a durable detection skill; “check for spelling errors” is not.

Software Testing

Code Reviews

The formal (Fagan-style) inspection process — six phases:

1. Planning — select the work product, assemble the reviewers, schedule.
2. Overview — the author walks the group through context and intent.
3. Preparation — reviewers examine the code individually, beforehand. The phase that determines the quality of everything after; unprepared reviewers produce theater.
4. Inspection — the structured meeting: defects are logged, not fixed and not debated.
5. Rework — the author addresses the findings.
6. Follow-up — verification that the rework actually resolved the defects, closing the loop.

Modern practice compresses this into asynchronous PR review — same phases, thinner ceremony. The security payoff either way: reviews catch logic and design flaws that no scanner recognizes, and they spread system knowledge as a side effect.

Static Testing

Analysis without executing the code — passive: walkthroughs, syntax checking, code reviews, and in tooling terms SAST scanners analyzing source or binaries. Strengths: complete coverage of what exists on disk, findable early (cheap to fix), no test environment needed. Weakness: no runtime context — configuration, data flow through live systems, and environment-dependent behavior are invisible, and false-positive rates reflect that.

Dynamic Testing

Testing the running system — active execution: DAST scanners, fuzzing, and pen testing itself is dynamic testing at engagement scale. It sees what static analysis can’t (runtime behavior, actual configuration, real authentication flows) and misses what it can’t reach (code paths never triggered during the test). The white box / black box distinction applies here exactly as in pen testing — with source knowledge or without. Static and dynamic are complements, not competitors; mature pipelines run both.

Requirements Traceability Matrix (RTM)

A table mapping customer requirements to the testing plan — each requirement traced to the test cases that verify it. Its two services: proving current project requirements are being met (no requirement ships unverified) and exposing orphans in both directions — requirements without tests (coverage gap) and tests without requirements (scope creep). For security work specifically: security requirements have a habit of being declared and never verified; an RTM makes that gap a visible empty cell instead of a post-incident discovery.

Software Testing Levels

Ascending scope — each level catches what the previous one structurally cannot:

• Unit testing — the functionality of a specific section of code, in OO environments typically at class level. Fast, isolated, the foundation of the pyramid.
• Integration testing — verifies the interfaces between components: units that pass individually and still disagree about data formats, ordering, or error semantics. Most real-world bugs live at these seams.
• Component interface testing — the focused variant: explicitly testing the data passed between units — boundary values, malformed input, unexpected types crossing the interface. (The original’s “test a complete system” note points ahead to system testing — full end-to-end verification of the assembled whole.)
• Operational acceptance testing — left empty in the original; it’s the operations-side gate: can this system be run? Backups restore, monitoring alerts fire, failover works, runbooks are followable — verified before production, not during the first incident.
• Installation testing — assures the software installs correctly in the target environment: fresh installs, upgrades, dependencies. The mundane level whose absence explains many “works in staging” incidents.
• Regression testing — re-running existing tests after major code changes to find what broke: the defect that was fixed and quietly returns, or the feature a refactoring silently damaged. Automated regression suites are what make continuous change safe — and are themselves a control worth auditing.

Software Testing Types

The technique catalog, orthogonal to the levels above:

• Fuzzing — throwing malformed, unexpected, or random input at software and watching for crashes and misbehavior. Cheap to run, brutally effective at finding memory-safety and parsing bugs — a large share of real CVEs in parsers and protocol handlers fall to fuzzers, which is why attackers run them too. Modern coverage-guided fuzzing (AFL/libFuzzer lineage) turned this from random noise into systematic exploration.
• All-pairs testing (pairwise) — the combinatorial compromise: instead of testing all possible combinations of input parameters (exponential, infeasible), use carefully chosen test vectors covering every pair of parameter values. The empirical justification: most defects are triggered by the interaction of at most two parameters, so pairwise coverage finds a large majority of combination bugs at a tiny fraction of the cost.
• Interface testing — systematically exercising each interface class: APIs (the contract machines rely on — and the attack surface scanners increasingly target), GUIs (what humans use), and physical interfaces (where hardware meets the world).
• Misuse case testing — the inversion of use cases: acting like an attacker, designing tests around what the software must not allow. Use cases verify the happy path; misuse cases verify the unhappy ones are actually closed. This is where threat modeling (Domain 3’s STRIDE) feeds directly into the test plan — each identified threat becomes a misuse case.
• Test coverage analysis — the meta-metric: how much of the code did we actually test? Measured as line, branch, or path coverage. The honest interpretation: low coverage proves testing is insufficient; high coverage does not prove it’s good — 100% line coverage with weak assertions verifies nothing. Coverage locates the untested dark corners; it doesn’t certify the lit ones.

---

Erstellt: 2026-07-08 — ausformulierte Fassung der Original-Stichpunkte, siehe Domain 6 - Security Assessment and Testing (Original-Stichpunkte)