CISSP Domain 3 Revision: Security Architecture and Engineering

Domain 3 is the one candidates tend to fear most, and not without reason. It covers cryptography, security models, physical facility design and system architecture in a single sweep, and the breadth can feel unmanageable next to a domain like Governance where the concepts at least share a family resemblance. The trick is to treat it as several smaller, connected domains rather than one enormous one. Secure design principles, formal security models, system-specific vulnerabilities, cryptography, physical security, and the system development lifecycle each have their own internal logic. Learn them separately and the whole becomes far less daunting.

Secure design principles

This objective lists the engineering philosophy that should sit behind every technical decision made later in the domain. None of these ideas are exotic. What the exam wants is recognition of the principle in a scenario, not the ability to recite a definition.

Threat modelling reappears from Domain 1, but here it's applied at the point of system design rather than as a governance exercise. Building it in early is cheaper than retrofitting it after deployment, which is the argument the exam expects you to make if asked to justify the practice.

Least privilege grants users and processes only the access required to perform their function, nothing more. It sounds obvious stated plainly, but most real-world breaches involve an account with more privilege than its role justified.

Defence in depth layers multiple controls so that the failure of one doesn't expose the whole system. A firewall alone is not defence in depth. A firewall, an intrusion detection system, endpoint protection and a hardened configuration together, arranged so an attacker has to defeat several independent barriers, is closer to the idea.

Secure defaults means a system should be secure the moment it's switched on, before anyone configures anything. Shipping a product with an open administrative port and a blank password, on the assumption the customer will lock it down later, is the failure mode this principle exists to prevent.

Fail securely is about what happens when something goes wrong. A system that fails open, granting access when it can't verify a request, is worse than one that fails closed and simply denies access until the fault is fixed.

Segregation of duties splits a sensitive process across multiple people so no single individual can complete it alone. A classic example is requiring one person to initiate a financial transaction and a different person to approve it.

Keep it simple and small favours minimal, auditable design over complexity for its own sake. Complex systems have more places for vulnerabilities to hide and are harder to review properly.

Zero trust, and its older cousin trust but verify, both reject the assumption that anything inside a network perimeter is automatically safe. Zero trust goes further: every request is authenticated and authorised regardless of where it originates, internal network included.

Privacy by design builds privacy protections into a system from the start rather than adding them once a regulator asks questions. This concept has legal teeth under GDPR specifically, so expect it to be tested alongside privacy law from Domain 1.

Shared responsibility matters most in cloud contexts. A cloud provider secures the infrastructure; the customer remains responsible for what they build and configure on top of it. Misunderstanding where that line sits is one of the most common causes of cloud misconfiguration breaches.

Secure Access Service Edge (SASE) is a newer addition, combining network security functions (like secure web gateways and zero trust network access) with wide area networking, delivered as a cloud service rather than through traditional on-premises hardware. It's worth knowing as the architectural response to a workforce that no longer sits behind a single corporate perimeter.

Security models

This is a small but exam-heavy section, and the three named models are worth learning as a set because they're easy to confuse under pressure.

Bell-LaPadula: confidentiality focused. "No read up, no write down." A subject cannot read data at a higher classification than their own clearance, and cannot write data down to a lower classification. Built for military and government contexts where preventing disclosure matters more than preventing corruption.
Biba: integrity focused, and effectively the mirror image of Bell-LaPadula. "No write up, no read down." A subject cannot write to data of higher integrity than their own level, and cannot read data of lower integrity, to avoid contaminating trusted data with less trustworthy input.
Star Model (often referring to Clark-Wilson or the Star property specifically): worth being precise about which model a question is actually invoking, since "star property" is also a specific rule within Bell-LaPadula (no write down) rather than always a separate named model. Clark-Wilson, frequently grouped in this conversation, focuses on integrity through well-formed transactions and separation of duties rather than simple read/write rules.

The exam's favourite technique here is presenting a rule ("subjects cannot read data below their clearance level") and asking which model it belongs to. Keep the mnemonic simple: Bell-LaPadula stops secrets leaking down, Biba stops rubbish leaking up.

Selecting controls based on system requirements

This objective is less about memorising a list and more about reasoning: given a stated security requirement, availability, confidentiality, regulatory compliance, choose the control that actually satisfies it rather than one that merely sounds relevant. Scenario questions here tend to bury the real requirement in a paragraph of context, so the exam skill is extracting what's actually being asked before reaching for an answer.

Security capabilities of information systems

Three concepts dominate this objective:

Memory protection: mechanisms like address space layout randomisation and data execution prevention that stop malicious code from executing in memory regions it shouldn't touch.
Trusted Platform Module (TPM): a dedicated hardware chip that generates and stores cryptographic keys, supports secure boot, and underpins full-disk encryption schemes like BitLocker. Know that it's hardware-based, which is what makes it more resistant to tampering than a software-only equivalent.
Encryption and decryption: covered in far more depth later in the domain, but here it's tested as a system capability, something the underlying hardware and OS need to support properly rather than something bolted on afterwards.

Vulnerabilities across architecture types

This is the longest list in the domain, and it rewards knowing the one or two vulnerabilities that are distinctive to each system type rather than trying to master every possible weakness across all of them.

Client-based systems: local malware, unpatched software, weak endpoint configuration.
Server-based systems: exposed services, privilege escalation, unpatched operating systems.
Database systems: SQL injection, weak access controls on underlying tables, aggregation and inference attacks where individually harmless data combines to reveal something sensitive.
Cryptographic systems: weak key management, outdated algorithms, poor random number generation.
Industrial Control Systems (ICS): legacy equipment never designed with network exposure in mind, long patch cycles, and safety systems where availability failures can cause physical harm rather than just data loss.
Cloud-based systems: misconfiguration is the dominant risk across SaaS, IaaS and PaaS, closely tied to the shared responsibility confusion mentioned earlier.
Distributed systems: consistency and synchronisation issues, plus a wider attack surface simply because there are more components talking to each other.
Internet of Things (IoT): weak default credentials, limited processing power for proper encryption, and infrequent or absent patching.
Microservices: API security becomes the central concern, since each service boundary is a potential point of unauthorised access if authentication isn't enforced consistently across all of them.
Containerisation: image vulnerabilities, container escape, and orchestration platform misconfiguration.
Serverless: function-level permissions that are broader than necessary, and reduced visibility into the underlying execution environment.
Embedded systems: firmware rarely updated after deployment, physical access risk.
High-Performance Computing: shared resource risk, since multiple workloads or tenants may run on the same infrastructure.
Edge computing: physical security is weaker at distributed edge locations compared with a centralised data centre.
Virtualised systems: hypervisor vulnerabilities and VM escape, where a compromise in one virtual machine reaches the underlying host or neighbouring VMs.

If a scenario asks which system type is at risk from a specific attack, look for the keyword that points to the category rather than trying to recall an exhaustive list. "Container escape" points to containerisation. "VM escape" points to virtualisation. "SQL injection" points to database systems.

Selecting and determining cryptographic solutions

Cryptography deserves its own dedicated study time rather than being absorbed in a single revision pass, but the structural points worth anchoring are these.

The cryptographic lifecycle covers key generation, distribution, storage, rotation, and eventual destruction, alongside algorithm selection appropriate to the sensitivity of the data and the expected lifespan of the protection needed.

Cryptographic methods split into three families worth being able to compare directly:

Symmetric: same key for encryption and decryption. Fast, efficient for bulk data, but key distribution is the weak point (AES is the standard reference algorithm here).
Asymmetric: separate public and private keys. Solves the key distribution problem but is computationally slower, so it's typically used to exchange a symmetric key rather than to encrypt bulk data directly (RSA is the classic example).
Elliptic curve cryptography: achieves equivalent security to RSA with much smaller key sizes, which matters for constrained environments like mobile devices and IoT.
Quantum: a growing exam presence, covering both the threat quantum computing poses to current asymmetric algorithms and the emergence of post-quantum cryptography designed to resist it.

Public Key Infrastructure (PKI) ties asymmetric cryptography to identity through certificates, certificate authorities, and a chain of trust. Quantum key distribution is worth knowing as a distinct concept from PKI itself: it uses the physical properties of quantum mechanics to detect eavesdropping on a key exchange, rather than relying on mathematical hardness assumptions the way traditional PKI does.

Cryptanalytic attacks

Worth learning by what the attacker actually has access to, since that's usually the detail a scenario question gives away:

Brute force: trying every possible key.
Ciphertext only: attacker has only encrypted data, no plaintext to compare against.
Known plaintext: attacker has matching plaintext and ciphertext pairs.
Frequency analysis: exploits the statistical frequency of letters or symbols, effective against classical ciphers rather than modern algorithms.
Chosen ciphertext: attacker can submit ciphertext and observe the resulting plaintext.
Implementation attacks: exploit weaknesses in how an algorithm is implemented rather than the algorithm's mathematics.
Side-channel: extracts information from physical characteristics of a system, power consumption or electromagnetic emissions, rather than from the cryptography itself.
Fault injection: deliberately induces errors in a system to reveal information through its faulty behaviour.
Timing: infers information from how long an operation takes to complete.
Man-in-the-Middle: intercepts communication between two parties, potentially altering it, while each party believes they're communicating directly with the other.
Pass the hash: reuses a captured password hash to authenticate without ever needing the plaintext password.
Kerberos exploitation: covers attacks like Golden Ticket and Kerberoasting, which target weaknesses in Kerberos ticket issuance and validation rather than the cryptography behind it directly.
Ransomware: technically a broader category of attack rather than a pure cryptanalytic technique, but included here because it weaponises encryption itself, against the victim, as the mechanism of extortion.

Site and facility security

Physical security tends to get short shrift in revision because it feels less technical, but it's tested with real specificity.

Applying security principles to site design means thinking in layers, much like defence in depth applied physically: perimeter, building, floor, room, and then the asset itself, each with its own barrier.

Design controls worth knowing individually:

Wiring closets and intermediate distribution facilities: need restricted access, since compromising network infrastructure here bypasses higher-layer controls entirely.
Server rooms and data centres: layered access control, environmental monitoring, and often positioned away from exterior walls and windows.
Media storage facilities: physical protection for backup tapes and drives, proportional to the classification of the data they hold.
Evidence storage: chain of custody requirements apply here as much as in the investigation objective from Domain 1.
Restricted and work area security: badge access, visitor escort policies, clean desk requirements.
Utilities and HVAC: temperature and humidity control protects hardware directly, and utility failure is itself a security event if it takes systems offline.
Environmental issues: both natural (flood, earthquake, fire) and man-made (arson, sabotage, nearby industrial hazard) need to factor into facility site selection, not just facility operation.
Fire prevention, detection and suppression: know that suppression systems in server rooms typically use gas-based agents rather than water, to avoid destroying the equipment they're meant to protect.
Power: redundant power feeds and backup generation (UPS for short-term bridging, generators for extended outage) protect availability directly.

Managing the information system lifecycle

The final objective in this domain traces a system from concept through to disposal, and it's a useful structure to hold in mind because it echoes the software development lifecycle covered elsewhere in the CBK, applied here at a broader systems engineering level.

Stakeholder needs and requirements: understanding what the system actually needs to achieve before any design work begins.
Requirements analysis: turning stated needs into specific, testable requirements.
Architectural design: defining the structure and components of the system.
Development and implementation: building the system according to the design.
Integration: connecting the system with existing infrastructure and other systems.
Verification and validation: confirming the system meets requirements (verification) and that it actually solves the intended problem (validation), a distinction the exam likes to draw out explicitly.
Transition and deployment: moving the system into live operation.
Operations and maintenance: ongoing running, patching and support.
Retirement and disposal: decommissioning the system securely, including the data destruction principles from Domain 2.

Security needs to be embedded at every stage of this lifecycle rather than inserted as a single review before deployment. A system that passes a security review at the design stage but receives no further scrutiny until it's already in production has, in practice, had no security lifecycle management at all.

Where AI now sits in Domain 3

Architecture and engineering is where hosting and running AI safely gets tested directly. Secure enclaves for high-performance AI compute extend the memory protection and TPM concepts covered earlier to workloads that are unusually compute-hungry and, in many deployments, unusually exposed. Input validation takes on a sharper edge too, since prompt injection and adversarial input are effectively a new attack class sitting alongside the cryptanalytic attacks covered earlier in this domain, exploiting the model's own interpretation of input rather than a flaw in an algorithm.

Shared responsibility, already a core design principle in this domain, applies with real force to cloud-hosted AI services: a provider secures the underlying infrastructure a model runs on, but the customer remains accountable for how that model is configured, what data feeds it, and what it's allowed to do. Explainable AI is worth knowing as a security requirement in its own right rather than just a nice-to-have for end users, since a security team auditing a model's behaviour needs some visibility into why it produced a given output, not just confirmation that it did.

Final thought for revision

Domain 3 punishes candidates who try to memorise it as a flat list of facts. It rewards those who build a mental map instead: design principles that guide every decision, formal models that govern how confidentiality and integrity rules are enforced, system-specific weaknesses tied to their architecture, cryptography understood by what problem each method solves, and physical controls layered the same way logical ones are. Once the map is in place, most exam questions become an exercise in locating where a scenario sits on it, rather than recalling an isolated fact under pressure.