Security Architecture & Engineering

Security Architecture & Engineering is the practice of making trustworthiness a built-in quality of a system rather than a patch applied after a breach, and NIST SP 800-160 Vol. 1 calls this disciplined view systems security engineering. The ten subtopics are the stages of that discipline: durable design principles and formal models state WHAT secure behavior is; control/assurance selection and system capabilities decide and enforce it; architecture vulnerabilities, the cryptographic pair, and the physical-site pair apply it to specific exposures; and the system lifecycle is the schedule that carries all of it from first requirement to disposal. At 13% of the exam this domain ties Communication & Network Security, Identity & Access Management, and Security Operations and sits behind only the 16% Security & Risk Management domain. Its recurring 'what should you do FIRST / what is the BEST design' questions almost always reward the principle or earliest-stage action over a specific product.

Secure Design Principles supply the vendor-neutral rules an engineer applies before any product is named: least privilege, need-to-know, defense in depth, secure defaults, fail-securely, and zero trust (NIST SP 800-207), which removes implicit trust based on network location. Security Models then formalize one such goal into rules a machine can enforce and prove for every reachable state: Bell-LaPadula protects confidentiality (no read up, no write down), Biba mirrors it for integrity (no read down, no write up), and Clark-Wilson and Brewer-Nash handle transaction integrity and conflict-of-interest that the level-based models cannot. Both subtopics assume a reference monitor (the always-invoked, tamperproof, verifiable mediator) as the enforcement core, which is why the model layer hands directly to the capability layer that implements it.

Controls Selection is requirements-driven, not a checklist: you start from an impact-based baseline (NIST SP 800-53B low/moderate/high, picked from the FIPS 199 high-water mark) and tailor it to the system, then an independent assessment confirms the controls work and an authorizing official accepts the residual risk under Assessment and Authorization (the modern name for Certification and Accreditation). Running parallel to that is product assurance: the Common Criteria (ISO/IEC 15408) evaluates how rigorously a Target of Evaluation was examined and expresses it as an Evaluation Assurance Level from EAL1 to EAL7. The single most-tested distinction in this domain is that a higher EAL means more rigor of evaluation, NOT more security features, and an EAL holds only within the exact configuration and assumptions of the product's Security Target.

System Security Capabilities are the concrete hardware and OS mechanisms that make a design enforceable (memory protection (process isolation, protection rings, DEP, ASLR), the reference monitor's implementation as a security kernel, a TPM (platform-bound trust and measured boot) versus an HSM (scalable, FIPS 140-3-validated key operations), a hardware root of trust extending a chain of trust, and a trusted execution environment), and the smaller this Trusted Computing Base, the easier it is to assure. Architecture Vulnerabilities is the inverse view: every architecture concentrates a signature weakness (a database invites inference and aggregation, virtualization invites VM escape, ICS cannot tolerate active scanning), and a shared component is a shared blast radius. The skill the exam rewards is recognizing the architecture from the scenario and matching the mitigation to its root cause rather than reciting a generic control list.

Cryptographic Solutions teaches selection: match the algorithm class to the property (symmetric for bulk confidentiality, asymmetric to solve key distribution, hashes for integrity, digital signatures for integrity plus origin authenticity plus non-repudiation), recognize that real systems are hybrid, and govern the key lifecycle because most cryptographic failures are key-management failures, not broken algorithms. Cryptanalytic Attacks is the adversary's mirror: classify the attack by the access the attacker has (ciphertext-only up to chosen-ciphertext), treat brute force as the floor and the cheapest analytic shortcut as the real strength, and recognize that side-channel, fault, protocol, and credential attacks bypass sound math entirely by attacking the implementation or stealing the result. Read the two together: a control chosen in Solutions is only as strong as the attack class it survives in Attacks.

The physical pair runs from outside in. Site & Facility Design owns the outer rings (choosing the site before you harden it (hazards, surroundings, visibility), applying Crime Prevention Through Environmental Design (CPTED) so layout itself discourages crime, and arranging concentric zones of decreasing public access), and these siting trade-offs cannot be fully undone later by adding controls. Facility Security Controls owns everything inside the protected envelope, where the dominant goal flips to availability: keep equipment cool, dry, powered, and fed via HVAC (hot-aisle/cold-aisle, 40–60% relative humidity), class-matched fire suppression (clean agent over water for live electronics, pre-action as the data-center default), and layered power (conditioning, UPS as bridge power, generator for sustained outages), with the precise power-anomaly vocabulary that maps each symptom to its fix.

System Lifecycle ties the domain together by treating protection as a quality engineered in stage by stage (NIST SP 800-160 Vol. 1, ISO/IEC/IEEE 15288): each stage produces security artifacts the next consumes, from stakeholder needs through requirements, design, build, verification and validation, operation, and finally disposal. Security requirements are fixed before design because a defect costs sharply more the later it is found, so the exam reward is to choose 'define security requirements' over 'add a control later' whenever the question lets you act early. Verification ('did we build the system right?') and validation ('did we build the right system?') are distinct and both mandatory, and retirement/disposal is a real security stage: sanitize media (NIST SP 800-88), revoke identities, and update inventory, or you leave orphaned credentials and recoverable data.