Domain 3: security architecture and engineering

Domain 3, Security Architecture and Engineering, carries 13 % of the exam and is often described as the most technical domain. It covers how secure systems are designed and built: the principles that guide design, the formal models that describe security properties, the ways systems can be evaluated, the vulnerabilities of different kinds of systems, cryptography and public key infrastructure, and the physical security of sites and facilities. Candidates with a networking or operations background often find parts of it familiar, while the security models and cryptography can be new territory. This lesson gives a guided tour of the domain and shows how its ideas connect to the rest of the common body of knowledge.

What the domain covers

The 2024 outline lists topics such as researching, implementing and managing engineering processes using secure design principles; understanding the fundamental concepts of security models; selecting controls based on systems security requirements; understanding the security capabilities of information systems; assessing and mitigating the vulnerabilities of security architectures, designs and solution elements; selecting and determining cryptographic solutions; understanding methods of cryptanalytic attacks; applying security principles to site and facility design; and designing site and facility security controls. Like every domain in the 2024 outline, it also mentions the security implications of artificial intelligence and machine learning where relevant.

Secure design principles

Secure design principles are rules of thumb that, when applied consistently, produce systems that are harder to attack and fail more safely. The outline names several that you should be able to explain and apply.

• Threat modelling: systematically identifying what could go wrong in a design, using approaches such as STRIDE (spoofing, tampering, repudiation, information disclosure, denial of service and elevation of privilege).
• Least privilege: giving users and processes only the access they need, for only as long as they need it.
• Defence in depth: layering independent controls so that the failure of one does not expose the asset.
• Secure defaults: shipping and configuring systems in a secure state, so that insecurity requires a deliberate choice.
• Fail securely: ensuring that when a component fails, it fails into a state that protects the asset, for example denying access rather than allowing it.
• Separation of duties: dividing critical tasks so that no single person can complete them alone.
• Keep it simple and small: reducing complexity and attack surface, because complex systems hide flaws.
• Zero trust: never granting trust automatically based on network location; verifying every request explicitly, using least privilege and assuming breach.
• Privacy by design: building privacy protections into systems from the start rather than adding them later.
• Trust but verify, and shared responsibility: relying on others, such as cloud providers, only with appropriate checks, and understanding which security tasks belong to whom.

Security models

Security models are formal descriptions of how a system should enforce a security policy. The exam expects you to recognize the main models and the property each protects. The Bell-LaPadula model protects confidentiality in multilevel systems. Its simple security property says 'no read up': a subject may not read an object at a higher classification. Its star property says 'no write down': a subject may not write information to a lower classification, which prevents leaks. The Biba model protects integrity and reverses these rules: 'no read down' (do not rely on less trustworthy data) and 'no write up' (do not contaminate more trustworthy data).

The Clark-Wilson model protects integrity in commercial systems by requiring that users access data only through well-formed transactions (programs that are certified to preserve integrity) and by enforcing separation of duties. The Brewer-Nash model, sometimes called the Chinese Wall, prevents conflicts of interest by dynamically blocking access to data of competing clients once a user has accessed one of them, which suits consulting and financial firms. Other models, such as Graham-Denning and Harrison-Ruzzo-Ullman, describe how access rights are created, transferred and deleted.

Evaluating systems and choosing controls

How can a buyer trust that a product is secure? Formal evaluation schemes give some assurance. The Common Criteria for Information Technology Security Evaluation (ISO/IEC 15408) lets vendors have products evaluated against a protection profile by an accredited laboratory, with evaluation assurance levels (EAL1 to EAL7) indicating how rigorous the evaluation was. A higher EAL means more rigorous testing, not necessarily a more secure product. Both Canada and the United States run Common Criteria schemes.

Canadian government systems select and tailor controls using the Canadian Centre for Cyber Security's guidance, especially ITSG-33, IT Security Risk Management: A Lifecycle Approach, whose control catalogue is derived from NIST SP 800-53 and adapted to Canadian context. The Cyber Centre also publishes medium and high security control profiles for cloud services, and Protected B cloud services are assessed against these profiles. The Canadian Common Criteria Scheme is operated by the Cyber Centre.

Whatever framework applies, the principle is the same: identify the system's security requirements from its classification and risk assessment, select a baseline of controls, tailor the baseline to the system's circumstances and document the result so that it can be assessed and authorized.

Vulnerabilities in different kinds of systems

Domain 3 asks you to recognize the characteristic weaknesses of different architectures. Client-server and web systems suffer from injection, weak authentication and misconfiguration. Database systems face aggregation and inference problems, where combining harmless data reveals sensitive information. Industrial control systems and operational technology, which run power grids, water treatment and manufacturing, often use old protocols without authentication and cannot be patched easily. Internet of Things devices tend to have weak default credentials and limited update mechanisms. Virtualized systems introduce risks such as virtual machine escape and sprawl. Containers and microservices multiply the number of components that must be secured. Serverless and other cloud services shift responsibilities to the provider but raise new questions about configuration and visibility. Embedded systems and high-performance computing systems each have their own constraints.

Cloud computing receives particular attention. In infrastructure as a service (IaaS), the customer manages the operating system, applications and data; in platform as a service (PaaS), the provider manages more of the stack; in software as a service (SaaS), the customer manages mainly its data, users and configuration. Under every model, the customer remains accountable for its data and its users' access. Misunderstanding this shared responsibility is a leading cause of cloud breaches.

Cryptography

Cryptography is a large part of Domain 3. Symmetric encryption uses the same secret key to encrypt and decrypt; it is fast and suits bulk data. AES, with 128-, 192- or 256-bit keys, is the dominant symmetric algorithm. Asymmetric encryption uses a key pair: a public key that can be shared and a private key that must be kept secret. RSA and elliptic curve cryptography (ECC) are the common asymmetric families. Asymmetric cryptography solves the key distribution problem and enables digital signatures, but it is much slower, so real systems combine the two: an asymmetric exchange establishes a symmetric session key, as in TLS. Hash functions, such as SHA-256, produce a fixed-length digest of any input and are used to check integrity; a digital signature is created by encrypting a hash with the signer's private key.

A classic exam calculation shows why asymmetric cryptography matters for key management. With symmetric keys, every pair of users who want to communicate privately needs its own shared key. With asymmetric keys, each user needs only one key pair.

Public key infrastructure (PKI) binds public keys to identities using digital certificates issued by certificate authorities (CAs). Certificates follow the X.509 standard, and a chain of trust runs from a trusted root CA through intermediate CAs to the end-entity certificate. Certificates can be revoked through certificate revocation lists or the Online Certificate Status Protocol. Key management, covering generation, distribution, storage, rotation, escrow and destruction, is often where real-world cryptography fails.

The domain also covers cryptanalytic attacks: brute force, frequency analysis, known-plaintext and chosen-plaintext attacks, side-channel attacks that measure timing or power consumption, implementation attacks and attacks on poor key management. Quantum computing is a looming threat to today's asymmetric algorithms, and NIST published its first post-quantum cryptography standards in 2024 (FIPS 203, 204 and 205), which organizations are beginning to plan migrations toward.

Site and facility security

Finally, Domain 3 covers the physical environment. Secure site design starts with location: avoiding flood plains and other hazards, and considering crime rates and access to emergency services. Crime prevention through environmental design (CPTED) uses natural surveillance, natural access control and territorial reinforcement to discourage crime. Inside the facility, controls protect wiring closets, server rooms and data centres, media storage, evidence storage and work areas. Environmental controls manage power (uninterruptible power supplies and generators), heating, ventilation and air conditioning, humidity and fire. Fire detection and suppression must suit the space: water sprinklers, such as wet pipe, dry pipe and pre-action systems, and clean agent gas systems for equipment rooms. Pre-action systems are popular for data centres because they need two triggers before water is released.

Physical security also overlaps with Domain 7, which covers the day-to-day operation of physical controls such as guards, badges, visitor logs and monitoring. Domain 3 focuses on design decisions made before a facility is built or fitted out, when choices about layout, construction materials, power supply and fire suppression are cheapest to get right. A security professional involved early in a facility project can prevent costly retrofits later, which is another example of the principle that security designed in is better than security added on.

As with every domain, the questions in Domain 3 reward understanding of why a principle or mechanism exists rather than memorized lists.