Security Architecture Modeling

Two documents can describe the same system: one lists every safeguard the organization owns, the other shows the security domains (zones the design draws, not the exam's four subject areas), what sits inside them, how they interconnect, the trust each connection carries, and therefore how policy is enforced inside a domain and across the boundary to the next one. Only the second is a security architecture, and the gap between them is what this 22% of the exam tests. Everything in this exam domain is one of two moves: Choose settles the structure and the method the design argument will use, and Prove produces the evidence that the resulting design meets its requirements and fits its intended use. The trap that costs marks is letting an artifact stand in for the argument, because a control catalog, a connectivity diagram, a framework name, or conformance to a reference architecture says nothing on its own about where policy is enforced or what shows that it holds.

Read the two pages in that order. Select a security architecture approach is the Choose move, and it settles five things: the scope the architecture covers, the type of structure it describes (network, service-oriented architecture (SOA), zero trust, among others), the framework that produces it (most often TOGAF, The Open Group Architecture Framework, or SABSA, Sherwood Applied Business Security Architecture), the reference content (reference architectures and blueprints) it reuses, and the threat-modeling framework that says what can go wrong, where STRIDE's six categories (spoofing, tampering, repudiation, information disclosure, denial of service, elevation of privilege), the Common Vulnerability Scoring System (CVSS), and MITRE ATT&CK, a catalog of adversary behavior that has actually been observed, each answer a different question. Verify and validate the security design is the Prove move, which asks both whether the design was built to its specification (verification) and whether that specification was the right one for the intended use (validation), and runs from threat-model-driven test selection and gap analysis against a target, through mitigations, compensating controls, and review by others, to the code-analysis methods and the residual risk this move records, while GRC owns accepting it. The mechanisms, the method-by-method detail, and the traps live on those two pages; this one only says which move a question is asking about.

The instinct this domain rewards is that a label is not evidence. A framework name, an external assessor, a passing test, a reference architecture, and a control family that matches the affected asset each describe something that exists; none of them shows that a business requirement reached a design decision, or that a design decision produced a result somebody checked. The exam-correct answer is usually the one that keeps that line unbroken: requirements that stay traceable as the architecture decomposes, a method tailored to this enterprise rather than adopted whole, a mitigation that changes the modeled scenario rather than one merely filed against the same asset, and the residual risk recorded for the person authorized to accept it. When a distractor offers a stronger-sounding artifact with nothing traced to it, that is usually the distractor.