Domain 3 accounts for 13 percent of the current CISSP exam outline. It asks how trustworthy systems are designed, built, operated, and retired. The domain ranges from abstract security models to cryptography, cloud and industrial architectures, physical facilities, environmental protections, and the information-system lifecycle.
The breadth can make Domain 3 feel like a collection of unrelated facts. A better approach is to follow one question through every topic: what requirement must the design satisfy, which assumptions does the solution make, and what happens when a component, person, supplier, or control fails?
Architecture is not a diagram created after products are chosen. It is the set of structures, interfaces, trust boundaries, responsibilities, constraints, and design decisions that allow a system to meet business and security requirements over time.
1. Domain 3 map
The official outline divides Security Architecture and Engineering into ten objectives:
| Objective | Main focus | Questions to ask |
|---|---|---|
| 3.1 | Secure engineering principles | Which design principles reduce exposure, limit trust, protect privacy, and keep failures controlled? |
| 3.2 | Security models | Which property does the model protect, what information flow does it permit, and what assumptions does it make? |
| 3.3 | Control selection | Which controls satisfy the stated system requirements, risk decisions, and assurance needs? |
| 3.4 | System security capabilities | Which hardware, firmware, operating-system, and cryptographic features create or strengthen trust? |
| 3.5 | Architecture vulnerabilities | Where can each architecture fail, and which mitigations fit its design, operating environment, and dependencies? |
| 3.6 | Cryptographic solutions | Which method, algorithm, key process, and trust model provide the required protection? |
| 3.7 | Cryptanalytic attacks | Is the weakness in the mathematics, protocol, implementation, key handling, endpoint, or surrounding process? |
| 3.8 | Facility design principles | How should location, layout, access, visibility, utilities, safety, and resilience shape the site? |
| 3.9 | Facility controls | Which layered physical and environmental controls protect people, equipment, media, evidence, and operations? |
| 3.10 | Information-system lifecycle | How are security requirements traced from stakeholder need through design, verification, operation, and retirement? |
These objectives reinforce one another. Security models describe desired properties. Requirements translate business and risk decisions into outcomes the system must achieve. Architecture allocates those outcomes to people, processes, hardware, software, facilities, and suppliers. Engineering verifies that the implemented system still satisfies them.
2. Use the right decision order
CISSP questions often name a technology before the scenario has established what the system must protect. A Trusted Platform Module, Hardware Security Module, firewall, encryption algorithm, or biometric reader can be useful, but none is automatically the right starting point.
A practical architecture sequence is:
- Identify stakeholders, mission, assets, and obligations. Determine who depends on the system, what outcomes matter, and which legal, regulatory, contractual, safety, privacy, and business requirements apply.
- Define security objectives and unacceptable outcomes. State the required confidentiality, integrity, availability, authenticity, accountability, privacy, resilience, and safety properties.
- Understand threats and operating assumptions. Identify trust boundaries, likely adversaries, environmental conditions, supplier dependencies, failure modes, and limits on staffing, time, cost, and performance.
- Express measurable system requirements. Requirements should describe what the system must accomplish without prematurely locking the organization into one product.
- Choose architecture and design principles. Reduce attack surface, isolate functions, limit privileges, control information flows, and plan for failure and recovery.
- Select controls and allocate responsibilities. Assign requirements to technical, physical, administrative, and supplier controls. Make shared responsibilities explicit.
- Implement with trustworthy components and processes. Protect development, integration, configuration, secrets, dependencies, and deployment paths.
- Verify and validate. Verify that the implementation matches specifications. Validate that the resulting system satisfies stakeholder needs in the real environment.
- Monitor, maintain, and reassess. Architecture must adapt to new threats, requirements, uses, dependencies, vulnerabilities, and business priorities.
- Retire securely. Preserve required records, transfer or destroy data, revoke trust, remove access, sanitize assets, and update inventories and dependencies.
A question asking for the best architecture usually requires a requirement and risk analysis before product selection. A question asking for the next action depends on what the scenario has already completed.
3. Apply secure design principles
Secure design principles reduce the number of ways a system can fail and limit the damage when failure occurs. They should influence architecture before implementation, then remain visible in code, configuration, operations, monitoring, and retirement.
Threat modeling
Threat modeling identifies what must be protected, how the system is structured, where trust changes, what can go wrong, and which mitigations are appropriate. It is most valuable when started early and revisited as the design changes.
A useful threat model includes:
- Assets, business processes, and security objectives
- Data flows, entry points, identities, interfaces, and trust boundaries
- External services, suppliers, libraries, platforms, and administrative paths
- Threat actors, capabilities, motivations, and likely misuse cases
- Failure conditions, abuse paths, privacy harms, and safety consequences
- Existing and proposed controls, residual risks, and accountable owners
The output should inform requirements and design decisions. A diagram with no decisions, owners, or follow-up is not a completed threat model.
Least privilege and segregation of duties
Least privilege gives a person, service, device, or process only the permissions needed for its approved task, for only as long as needed. It limits accidental damage, misuse, and the reach of a compromised identity.
Segregation of Duties (SoD) divides a sensitive process so one person or role cannot complete an incompatible set of actions alone. It reduces fraud, error, concealment, and unilateral misuse.
Least privilege narrows authority. Segregation of duties separates authority. A payment administrator may have only the permissions needed to enter a transaction, while a different role must approve it.
Defense in depth
Defense in depth uses independent or complementary safeguards so the failure of one does not immediately expose the asset. Layers may include identity controls, segmentation, endpoint protections, application checks, encryption, monitoring, physical restrictions, backup, and recovery.
More layers do not automatically create better security. Controls that share the same dependency, administrator, identity provider, configuration error, or failure mode may fail together. Architecture should seek diversity where it meaningfully reduces correlated failure.
Secure defaults and fail securely
A secure default begins in the safer state until an authorized decision enables additional access or functionality. Examples include disabled services, denied access, private storage, strong authentication, and minimum permissions.
To fail securely, a system should preserve required protection when an error, outage, timeout, crash, or dependency failure occurs. The safe response depends on the mission. A failed access-control check may deny access, while a life-safety door may need a carefully designed emergency release. The requirement must balance security, safety, and availability rather than applying “fail closed” mechanically.
Keep it simple and small
Complexity creates more code, configuration, interfaces, dependencies, states, and assumptions to understand and defend. A smaller trusted computing base is easier to review, test, patch, and monitor.
Simplicity does not mean ignoring difficult requirements. It means avoiding unnecessary mechanisms and making the important ones understandable. A clever design that only one person can operate safely creates operational and succession risk.
Zero trust and trust but verify
Zero trust removes implicit trust based solely on network location, device ownership, or prior access. Access decisions consider identity, device, resource, context, policy, and current risk, then enforce least privilege and continuous evaluation where practical.
“Trust but verify” permits an initial trust relationship but checks whether the subject continues to satisfy expectations. Zero trust begins with no implicit trust and requires explicit authorization. Both depend on evidence, but the starting assumption differs.
Zero trust is an architecture and operating model, not one product. It requires accurate identity, asset, policy, telemetry, and enforcement information.
Privacy by design
Privacy by design incorporates privacy requirements into the system from the beginning. It asks whether data should be collected at all, how much is necessary, who may use it, how long it remains, how choices and rights are supported, and how unintended inference or secondary use is limited.
Encryption can protect data from unauthorized disclosure, but it does not make unnecessary collection, excessive retention, or inappropriate use acceptable.
Shared responsibility
A shared-responsibility model divides security duties among an organization, service provider, customer, supplier, and sometimes additional parties. The division changes by service and deployment model.
The organization should document who configures identities, protects data, patches components, monitors activity, responds to incidents, maintains evidence, manages keys, and proves compliance. A control with no clearly assigned owner is likely to be missed or duplicated.
Secure Access Service Edge
Secure Access Service Edge (SASE) delivers networking and security controls through cloud services so users and branch locations can receive consistent protection wherever they connect. Common elements can include software-defined wide-area networking, secure web gateway, cloud access security broker, firewall capabilities, and zero-trust network access.
The architectural question is not whether every named component is present. It is whether identity, traffic, policy, enforcement, availability, logging, privacy, and provider dependencies are addressed consistently.
4. Understand security models
Security models provide a formal or conceptual way to describe allowable states and information flows. They help architects reason about policy, but a model protects only the property it was designed to address.
| Model | Primary concern | Key idea |
|---|---|---|
| Bell-LaPadula | Confidentiality | Prevents information from flowing from a higher confidentiality level to an unauthorized lower level. |
| Biba | Integrity | Prevents lower-integrity information from contaminating higher-integrity subjects or objects. |
| Clark-Wilson | Commercial integrity | Uses well-formed transactions, authorized transformation procedures, separation of duties, and auditing. |
| Brewer-Nash | Conflict of interest | Changes access according to prior activity so one party cannot improperly use competing clients' confidential information. |
| State machine | Valid system states | Requires the system to begin securely and permit only transitions that preserve the security policy. |
| Information-flow model | Permitted movement | Examines how information may move between subjects, objects, levels, domains, or compartments. |
| Noninterference | Separation | Actions in one security domain should not reveal or influence protected information in another domain. |
| Lattice-based model | Ordered labels | Uses security labels and dominance relationships to determine permitted information flows. |
Bell-LaPadula and the star property
Bell-LaPadula focuses on confidentiality. Its simple security property is commonly summarized as no read up: a subject should not read information above its authorization. Its star property is commonly summarized as no write down: a subject should not move higher-level information into a lower-level object.
The model does not by itself solve integrity, availability, covert channels, poor classification, or trusted-user misuse. It assumes the labels and policy are correct.
Biba reverses the direction for integrity
Biba focuses on integrity. Its common summaries are no read down and no write up. A high-integrity subject should not rely on lower-integrity information, and a lower-integrity subject should not modify a higher-integrity object.
The direction can be confusing because confidentiality and integrity protect different properties. Ask whether the scenario is preventing secret information from leaking or preventing untrusted information from contaminating trusted information.
Clark-Wilson protects business transactions
Clark-Wilson uses constrained data items, transformation procedures, integrity verification, separation of duties, and audit records. A user does not directly modify protected data. The user invokes an authorized procedure that performs a valid transformation.
This approach fits commercial systems where the organization cares about authorized, complete, consistent, and auditable transactions.
Brewer-Nash changes access after a conflict appears
The Brewer-Nash model, also called the Chinese Wall model, addresses conflicts of interest. Access may be allowed initially, then restricted after a user accesses confidential information belonging to one organization in a conflict class.
The model is dynamic because prior access influences future permissions.
5. Select controls from system requirements
Controls should trace to requirements, threats, risks, obligations, and architecture decisions. Selecting a familiar control first and inventing a requirement later reverses the process.
Functional requirements and assurance requirements
A functional requirement states what the system or control must do, such as enforce multifactor authentication, encrypt stored records, prevent unapproved code execution, or retain audit events for a defined period.
An assurance requirement says how much evidence is needed before the organization can trust that a control was built correctly and still works. That evidence may come from testing, code review, formal analysis, certification, supplier records, monitoring, or repeated assessments.
A feature can exist with weak assurance. An encryption option that is disabled, incorrectly configured, poorly implemented, or dependent on exposed keys does not provide the intended protection.
Allocate controls across the system
A requirement may be satisfied by several coordinated controls:
- Technical controls in hardware, firmware, operating systems, applications, networks, and cloud platforms
- Physical controls in facilities, equipment locations, media storage, utilities, and environmental systems
- Administrative controls in policy, roles, contracts, training, review, and change management
- Supplier controls in agreements, service design, attestations, incident coordination, and exit planning
Architecture should identify dependencies and common failure modes. Two controls that depend on the same identity provider or management plane may not provide true independence.
Prefer requirements that can be tested
“Use strong security” cannot be verified. A useful requirement states the protected asset, required outcome, applicable conditions, responsible component, and evidence of success.
For example, instead of “encrypt sensitive data,” define which classifications require encryption, where the data exists, which interfaces and backups are included, who controls keys, what algorithms and modes are approved, how rotation and recovery work, and how compliance is verified.
6. Understand system security capabilities
Security capabilities create boundaries, protect secrets, establish platform integrity, and provide evidence. They must be enabled, configured, maintained, and integrated into the architecture.
Memory and process protection
Memory protection prevents one process from improperly reading or modifying another process or the operating system. Mechanisms include address-space isolation, privilege levels, execution protections, randomization, and controlled transitions between user and kernel functions.
These mechanisms reduce risk but do not make vulnerable software safe. A privileged process, kernel flaw, exposed secret, unsafe driver, or misconfiguration can still bypass the intended boundary.
Trusted Platform Module and measured boot
A Trusted Platform Module (TPM) is a protected hardware or firmware component that stores cryptographic keys and records information about how a device started. It can help prove the device's identity, protect disk-encryption keys, and support secure boot.
Attestation is evidence another system can check to determine whether the device is in an approved state.
Secure boot checks whether boot components are signed by an approved authority before execution. Measured boot records measurements so another party can evaluate what started. One blocks unapproved components; the other creates evidence about the boot path.
Hardware Security Modules and secure enclaves
A Hardware Security Module (HSM) protects cryptographic keys and performs sensitive operations within a controlled boundary. It is often used for certificate authorities, payment systems, code signing, database encryption, and high-value enterprise keys.
A Trusted Execution Environment (TEE) or secure enclave isolates code and data from other software on the same platform. It can reduce exposure during processing, but its security depends on processor design, implementation, attestation, update processes, side-channel resistance, and correct application use.
Virtualization and isolation
Hypervisors, containers, namespaces, access controls, and virtual networks create logical boundaries. Isolation is strongest when the architecture minimizes shared privileged components, protects management interfaces, separates tenants and workloads, and monitors movement across boundaries.
A snapshot, template, management plane, image registry, or orchestration account can affect many workloads at once. Centralized control improves consistency but increases the impact of administrative compromise.
Encryption and decryption capabilities
Encryption capabilities may exist in processors, storage devices, operating systems, databases, applications, network protocols, cloud services, and dedicated cryptographic modules. The architecture must decide where encryption begins and ends.
Data can be decrypted at an endpoint, application, proxy, gateway, database, or service provider. The location determines which components can see plaintext and which logs, caches, backups, or administrative tools may create additional copies.
7. Assess architecture vulnerabilities
Different architectures expose different trust boundaries, dependencies, update paths, failure modes, and concentrations of privilege. The same control does not fit every system.
| Architecture | Common concerns | Architecture responses |
|---|---|---|
| Client systems | Untrusted users, local secrets, phishing, malware, theft, unsafe networks, and inconsistent patching | Hardened builds, least privilege, endpoint protection, encryption, device health, application control, remote management, and rapid revocation |
| Server systems | Exposed services, privileged accounts, vulnerable dependencies, configuration drift, and high-value data | Service minimization, segmentation, hardened administration, patching, monitoring, redundancy, backups, and tested recovery |
| Database systems | Injection, excessive privileges, aggregation, inference, exposed backups, and weak administrative separation | Parameterized access, role separation, encryption, masking, activity monitoring, integrity constraints, controlled exports, and backup protection |
| Cryptographic systems | Weak algorithms, exposed keys, poor randomness, protocol errors, side channels, and failed rotation or recovery | Approved algorithms, protected key lifecycle, validated modules, protocol review, entropy assurance, monitoring, and migration planning |
| Industrial Control Systems | Safety impact, legacy protocols, long lifecycles, fragile availability, vendor dependence, and limited patch windows | Safety-aware risk analysis, segmentation, allowlisting, monitored remote access, passive discovery, compensating controls, tested change, and manual fallback |
| Cloud systems | Misconfiguration, exposed identities, public storage, provider dependencies, multitenancy, and unclear responsibility | Documented shared responsibility, strong identity, policy automation, encryption, logging, region and exit planning, resilient design, and configuration review |
| Distributed systems | Partial failure, inconsistent state, clock and ordering issues, network partitions, and complex trust between nodes | Defined consistency needs, authenticated communication, fault tolerance, idempotent operations, reconciliation, observability, and safe recovery |
| Internet of Things (IoT) | Weak credentials, limited updates, physical exposure, insecure protocols, data collection, and long unattended use | Unique identity, secure onboarding, signed updates, network isolation, data minimization, lifecycle support, and physical tamper considerations |
| Microservices and Application Programming Interfaces (APIs) | Service sprawl, authorization gaps, exposed interfaces, dependency chains, secrets, and inconsistent policy | Strong service identity, schema and input validation, least privilege, gateways where useful, rate limits, tracing, secret management, and dependency controls |
| Containers | Unsafe images, excessive privileges, shared kernels, exposed orchestration, secret leakage, and rapid configuration drift | Minimal signed images, scanning, runtime restrictions, namespace isolation, protected registries, secret management, policy enforcement, and orchestration hardening |
| Serverless | Event injection, excessive function permissions, dependency risk, short-lived visibility, and provider lock-in | Narrow roles, event validation, dependency review, protected secrets, centralized logs, concurrency controls, and tested failure handling |
| Embedded systems | Limited memory, hard-coded secrets, physical access, proprietary firmware, long lifecycles, and difficult updates | Secure boot, signed firmware, protected debug interfaces, unique keys, update planning, tamper resistance, and support commitments |
| High-Performance Computing | Large datasets, specialized networks, shared schedulers, powerful nodes, research openness, and performance pressure | Workload isolation, strong scheduler controls, protected management planes, data segmentation, secure high-speed transfer, and risk-based monitoring |
| Edge computing | Remote placement, intermittent connectivity, physical exposure, local data processing, and fleet-management complexity | Device identity, secure updates, local policy, encryption, remote attestation, resilient offline behavior, and centralized inventory and monitoring |
| Virtualized systems | Hypervisor compromise, virtual machine (VM) escape, management-plane concentration, snapshot exposure, and resource contention | Hypervisor hardening, administrative separation, secure templates, protected snapshots, network isolation, monitoring, patching, and capacity controls |
Industrial systems require safety-aware decisions
An Industrial Control System (ICS) can control physical processes. A change that improves confidentiality but interrupts production, disables a safety function, or causes unstable behavior may create greater harm than the original cyber risk.
Use consequence-based analysis. Coordinate with engineering and safety teams, test changes in representative environments, protect remote access, and preserve safe manual or degraded modes where required.
Cloud service models change responsibility
Infrastructure as a Service, Platform as a Service, and Software as a Service shift different responsibilities to the provider, but the customer remains accountable for understanding the division. Identity, data, configuration, workload, logging, encryption, incident response, and compliance duties vary by service.
Provider-managed does not mean risk-free. The organization still evaluates service design, evidence, concentration, jurisdiction, availability, portability, and exit requirements.
Management planes deserve stronger protection
Cloud consoles, hypervisor managers, container orchestrators, image registries, automation pipelines, remote-management platforms, and certificate authorities can change many systems at once. Protect them with dedicated administration, strong authentication, least privilege, network restrictions, monitoring, recovery plans, and independent evidence.
8. Select cryptographic solutions
Cryptography can protect confidentiality, integrity, authenticity, and nonrepudiation, but only when the complete system handles algorithms, protocols, keys, identities, endpoints, and lifecycle decisions correctly.
Choose the method for the required outcome
| Method | Primary use | Important limitation |
|---|---|---|
| Symmetric encryption | Efficient confidentiality for data and communications using a shared secret key | Secure key distribution and separation become difficult as participants and uses increase |
| Asymmetric encryption or key establishment | Protecting or establishing secrets without a pre-shared symmetric key | Slower operations, certificate or trust requirements, and algorithm-transition concerns |
| Cryptographic hash | Creating a fixed-length digest used for integrity checks and other constructions | A hash alone does not prove who created the data and does not hide the original data |
| Message Authentication Code | Integrity and source authentication among parties that share a secret | Any holder of the shared key may be able to create a valid code |
| Digital signature | Integrity, origin authentication, and support for nonrepudiation using a private signing key | Trust depends on key control, identity binding, validation, timestamps, and surrounding process |
| Authenticated encryption | Confidentiality and integrity in one coordinated construction | Nonce, mode, key, and implementation errors can still defeat protection |
Manage the complete key lifecycle
A cryptographic key lifecycle includes:
- Generation with approved algorithms and sufficient entropy
- Registration, ownership, and association with an identity or purpose
- Distribution or establishment through an authenticated process
- Storage and use within an appropriate protected boundary
- Rotation, renewal, and version management
- Backup, escrow, or recovery when the business requirement justifies it
- Revocation or suspension after compromise, role change, expiration, or policy violation
- Archival when old keys are needed to verify signatures or decrypt retained data
- Secure destruction when no legitimate need remains
Key recovery and key escrow can support availability, but they add sensitive copies and trusted roles. Signing keys may require different recovery rules from encryption keys because another party's ability to reproduce a signature can undermine accountability.
Public Key Infrastructure
A Public Key Infrastructure (PKI) manages digital certificates and the trust relationships that bind public keys to identities, systems, services, or roles. Components can include certificate authorities, registration authorities, repositories, validation services, policies, hardware security modules, and operational procedures.
Certificate validation should consider the trust chain, intended use, identity, validity period, revocation information, algorithm, key size, hostname or subject, and policy requirements. A valid signature does not prove that the certificate was issued to the intended party or used for the intended purpose.
Algorithm selection and cryptographic agility
Algorithm selection considers protection goal, data lifetime, performance, platform support, interoperability, regulatory requirements, implementation maturity, key size, mode of operation, and known weaknesses.
Cryptographic agility means being able to find and replace outdated encryption, signing methods, certificates, protocols, and keys without rebuilding the entire system. This requires an accurate inventory and a migration plan because encrypted data and digital signatures may remain in use for many years.
Quantum considerations
Quantum computing creates different concerns for symmetric and public-key systems. Organizations should identify long-lived sensitive data, public-key dependencies, embedded or difficult-to-update systems, and external interoperability requirements, then plan a controlled migration.
NIST has standardized post-quantum mechanisms for key establishment and digital signatures. Adoption still requires implementation review, interoperability testing, key and certificate lifecycle changes, performance analysis, and cryptographic agility. Quantum Key Distribution (QKD) is a specialized method for establishing keys over supported physical channels. It does not replace authentication, endpoint security, access control, or ordinary key governance.
9. Understand cryptanalytic attacks
A cryptographic failure may come from the algorithm, protocol, implementation, key process, endpoint, or surrounding identity system. Attack names are less useful than identifying which layer is being exploited.
| Attack | Attacker capability | Main concern |
|---|---|---|
| Brute force | Tries many possible keys, passwords, or values | Key space, password strength, rate limits, work factors, hardware, and time |
| Ciphertext-only | Observes encrypted data | Weak algorithms, patterns, repeated values, metadata, or implementation leakage |
| Known-plaintext | Knows some plaintext and its matching ciphertext | Whether the relationship reveals keys or other protected content |
| Chosen-plaintext | Can request encryption of selected plaintext | How the system responds to controlled input and whether patterns reveal information |
| Chosen-ciphertext | Can submit selected ciphertext for processing or decryption behavior | Error messages, padding behavior, timing, and protocol-oracle weaknesses |
| Frequency analysis | Studies symbol or pattern frequency | Especially relevant to simple substitution or deterministic patterns |
| Side-channel | Observes physical or operational effects | Timing, power, electromagnetic emissions, sound, cache behavior, or other leakage |
| Fault injection | Induces errors through voltage, clock, heat, radiation, or malformed input | Whether faulty results reveal secrets or bypass checks |
| Man-in-the-Middle | Intercepts and may alter communication | Weak endpoint authentication, certificate validation, key exchange, or channel binding |
| Pass the hash | Uses a captured password hash as an authentication credential | Credential reuse, protocol design, endpoint compromise, and administrative privilege |
| Kerberos exploitation | Targets tickets, service accounts, keys, delegation, or time and trust configuration | Identity-system design and key hygiene rather than breaking strong cryptography directly |
| Ransomware | Uses encryption or disruption against the victim | Endpoint compromise, privilege, lateral movement, backup protection, recovery, and extortion |
Implementation attacks bypass the mathematics
A strong algorithm can fail through predictable randomness, reused nonces, exposed keys, unsafe modes, missing authentication, detailed error messages, insecure libraries, poor certificate validation, or side-channel leakage.
When a scenario presents a cryptographic weakness, ask whether changing the algorithm alone addresses the cause. If the problem is key storage, endpoint compromise, or protocol validation, a newer cipher may leave the weakness intact.
Ransomware is not cryptanalysis
Ransomware often uses legitimate encryption against the victim's data. The defense is not “use stronger encryption.” It includes identity protection, segmentation, endpoint controls, monitoring, protected backups, restoration testing, incident response, and business resilience.
10. Apply security principles to facility design
Facility security begins before selecting locks, cameras, or guards. Location and layout decisions can either reduce exposure or make every later control more difficult.
Start with site selection and risk
Consider:
- Natural hazards such as flood, wildfire, earthquake, storm, extreme heat, and water scarcity
- Human-made hazards such as crime, civil unrest, industrial accidents, hazardous neighbors, transportation routes, and political instability
- Availability of power, water, telecommunications, emergency services, transportation, and skilled staff
- Legal jurisdiction, privacy obligations, data-location requirements, and government access risk
- Visibility, signage, adjacency, public access, and distance from high-profile targets
- Supplier concentration and whether supposedly redundant utilities share the same upstream path
A low-cost site can create long-term risk if it depends on one power feed, one carrier route, one access road, or one regional hazard zone.
Use layered zones
Physical design should create progressively stronger zones from public areas to controlled offices, restricted work areas, server rooms, evidence storage, and critical infrastructure. Each transition should have an approved purpose, access rule, monitoring method, and emergency procedure.
Avoid placing highly sensitive spaces against public walls, accessible roofs, shared utility areas, loading docks, or uncontrolled ceilings and floors when the risk warrants stronger separation.
Support safety and emergency response
Security controls must allow safe evacuation, emergency access, fire response, and life-safety operation. Doors, turnstiles, mantraps, alarms, and power-loss behavior require coordination with building codes and emergency plans.
A physical control that traps occupants or blocks responders is not an acceptable security improvement.
11. Design site and facility controls
Physical and environmental controls protect people first, then equipment, information, evidence, and operations. The correct design depends on threats, mission, occupancy, location, safety requirements, and recovery objectives.
Wiring closets and distribution facilities
Wiring closets and intermediate distribution facilities contain network and communications equipment that can provide broad access if compromised. Protect them with controlled access, inventory, locked racks where appropriate, environmental monitoring, fire detection, cable management, and separation from public or shared utility spaces.
Do not treat cabling as harmless infrastructure. Unprotected patch panels, fiber, copper, and management ports can permit interception, disruption, or unauthorized network access.
Server rooms and data centers
Server rooms and data centers may require:
- Layered access with identity, authorization, logging, and periodic review
- Visitor approval, escort, time limits, and badge control
- Cameras positioned for accountability without exposing sensitive screens or credentials
- Locked racks, protected consoles, and secure media handling
- Redundant power, network paths, cooling, and environmental monitoring
- Fire detection and suppression appropriate to occupants, equipment, and local requirements
- Water detection, drainage planning, and protection from overhead plumbing
- Inventory, maintenance control, and documented emergency shutdown procedures
Redundancy should avoid common failure. Two power supplies connected to the same upstream circuit do not provide meaningful resilience.
Media and evidence storage
Media storage should reflect classification, retention, environmental sensitivity, access, inventory, and recovery needs. Offsite copies should be far enough away to avoid the same regional event while remaining accessible within recovery requirements.
Evidence storage requires controlled custody, tamper indication, documentation, access logs, preservation conditions, and clear transfer procedures. The purpose is not merely to keep an item locked away, but to support integrity and admissibility.
Restricted and work areas
Restricted areas may use badges, biometrics, guards, locks, alarms, cameras, mantraps, visitor controls, and anti-tailgating measures. Work areas may also require clean-desk practices, privacy screens, secure printing, acoustic protection, locked storage, and controlled photography or portable devices.
Tailgating occurs when an unauthorized person follows an authorized person through an access point without proper verification. Awareness, access design, guards, and social norms all influence the risk.
Utilities and HVAC
Heating, Ventilation, and Air Conditioning (HVAC) maintains safe temperature, humidity, airflow, and equipment operation. Systems may require redundancy, monitoring, maintenance access control, spare capacity, and separation from ordinary building controls.
Utility spaces can create physical paths into restricted areas. Ducts, raised floors, suspended ceilings, drains, pipes, and maintenance corridors should be considered in the security boundary.
Fire protection
Fire protection combines prevention, detection, notification, suppression, compartmentation, evacuation, and recovery. Controls should match the hazard, occupancy, equipment, local code, and environmental considerations.
Common detector types respond to heat, smoke, flame, or combinations of signals. Suppression may use water, pre-action systems, clean agents, or other methods appropriate to the environment. Life safety takes priority over equipment preservation.
Power protection
Power design can include surge protection, grounding, Uninterruptible Power Supplies (UPS), generators, redundant feeds, fuel arrangements, load testing, maintenance, and orderly shutdown.
A UPS provides short-term power and power conditioning. A generator supports longer outages but takes time to start and depends on fuel, maintenance, ventilation, transfer equipment, and load capacity. Test the complete chain rather than assuming each component works because it exists.
12. Manage the information-system lifecycle
Security engineering continues from initial stakeholder need through retirement. Decisions made early often determine whether later controls are practical, affordable, and effective.
| Lifecycle stage | Security focus |
|---|---|
| Stakeholder needs and requirements | Identify mission, users, assets, obligations, risk tolerance, operating environment, safety, privacy, and acceptable outcomes. |
| Requirements analysis | Resolve conflicts, define measurable security requirements, identify assumptions, and establish traceability and acceptance criteria. |
| Architectural design | Define trust boundaries, interfaces, components, data flows, control allocation, resilience, dependencies, and shared responsibilities. |
| Development and implementation | Use trustworthy tools, secure coding and configuration, protected secrets, controlled dependencies, reviews, and reproducible builds. |
| Integration | Verify interfaces, inherited controls, identity and trust relationships, error handling, logging, and behavior across components. |
| Verification and validation | Verify that implementation matches specifications and validate that the complete system satisfies stakeholder needs in its intended environment. |
| Transition and deployment | Approve readiness, migrate data, establish monitoring, train operators, protect rollback paths, and confirm support and incident procedures. |
| Operations and maintenance | Monitor, patch, assess, manage configuration and change, review risk, respond to incidents, test recovery, and track component support. |
| Retirement and disposal | Transfer or destroy data, revoke credentials and certificates, terminate services, sanitize assets, preserve records, and update inventories and dependencies. |
Verification and validation answer different questions
Verification asks whether the system was built according to specifications and design. Validation asks whether the resulting system satisfies stakeholder needs and works acceptably in the intended environment.
A component can pass its specification and still fail the mission because the requirement was incomplete, the environment changed, the integration is unsafe, or users cannot operate it correctly.
Maintain requirements traceability
Traceability connects stakeholder needs to system requirements, architecture decisions, controls, implementation evidence, tests, risks, and operational monitoring. It helps the organization understand why a control exists and what must be reconsidered when the system changes.
Without traceability, teams may remove a control as “unused,” keep an obsolete control that no longer addresses the risk, or fail to test a requirement after a redesign.
Retirement is an engineering stage
Retirement includes more than shutting down a server. Identify data, backups, logs, certificates, domain names, accounts, integrations, supplier contracts, licenses, monitoring rules, dependencies, and physical assets. Transfer what must remain, destroy what no longer should, and verify that trust paths and access have been removed.
A forgotten Application Programming Interface (API) key, certificate, cloud snapshot, Domain Name System (DNS) record, or support account can leave a retired system connected to the organization.
13. Apply architecture principles to AI systems
AI systems add high-value models, large datasets, specialized compute, complex supply chains, probabilistic behavior, and new input and output risks. They still require ordinary security engineering fundamentals.
Protect the complete AI system
The architecture may include training data, preprocessing, model code, weights, embeddings, vector databases, prompts, retrieval sources, plugins, APIs, orchestration, compute clusters, endpoints, logs, evaluation data, and human review.
Protecting only the model file leaves many paths for data poisoning, unauthorized extraction, prompt injection, unsafe tool use, privacy leakage, output manipulation, and supply-chain compromise.
Separate control and data paths
Treat instructions, user content, retrieved content, tool output, and administrative policy as different trust levels. Validate inputs and outputs, constrain tool permissions, isolate sensitive workloads, protect model and prompt changes, and log consequential actions.
A model should not receive broad database, cloud, email, or code-execution permissions merely because a user may request a task. Apply least privilege and explicit authorization to the tools around the model.
Use shared responsibility explicitly
Cloud AI services divide responsibility across model provider, platform provider, application developer, data owner, customer administrator, and end user. Document who controls training use, retention, regions, access, model updates, safety settings, logging, incident response, deletion, and evidence.
Secure enclaves and confidential-computing features may reduce exposure during processing, but they do not correct unnecessary data collection, weak authorization, unsafe outputs, or vulnerable application logic.
14. Avoid common Domain 3 exam traps
Choosing a product before requirements
If the scenario has not defined the asset, requirement, threat, owner, or risk, gathering and analyzing those needs usually comes before buying a technology.
Confusing confidentiality and integrity models
Bell-LaPadula protects confidentiality. Biba protects integrity. Clark-Wilson protects commercial integrity through authorized transactions and separation of duties. Start with the property the scenario must preserve.
Treating encryption as complete protection
Encryption does not replace identity, authorization, key protection, integrity, availability, secure endpoints, retention, monitoring, or recovery. Determine where plaintext exists and who controls the keys.
Assuming more layers always mean better defense
Layers that share the same identity provider, management plane, privileged account, configuration, supplier, or physical location may fail together. Look for independence and common-mode failure.
Ignoring safety and availability in physical or industrial systems
A control that protects data but creates unsafe operation, blocks evacuation, or causes unacceptable downtime may be wrong. Balance security with life safety and mission requirements.
Confusing verification with validation
Verification checks conformance to specification. Validation checks suitability for stakeholder needs and the intended environment.
Blaming the algorithm for an implementation failure
A side channel, exposed key, reused nonce, certificate error, weak random number generator, compromised endpoint, or poor protocol may defeat strong cryptography. Fix the actual layer at fault.
Assuming provider-managed means customer-complete
Cloud and managed services shift responsibilities. They do not eliminate the customer's duties for data, identity, configuration, access, integration, monitoring, and risk acceptance.
15. Domain 3 review checklist
Before moving on, make sure you can:
- Apply threat modeling, least privilege, defense in depth, secure defaults, secure failure, segregation of duties, simplicity, zero trust, privacy by design, shared responsibility, and SASE.
- Explain the property protected by Bell-LaPadula, Biba, Clark-Wilson, Brewer-Nash, state-machine, information-flow, noninterference, and lattice models.
- Separate functional security requirements from assurance requirements.
- Select and allocate controls based on stakeholder needs, risk, obligations, architecture, and evidence.
- Compare secure boot, measured boot, TPM, HSM, Trusted Execution Environment, memory protection, and virtualization isolation.
- Assess the characteristic weaknesses of client, server, database, cryptographic, industrial, cloud, distributed, IoT, microservice, container, serverless, embedded, high-performance, edge, and virtualized systems.
- Explain symmetric encryption, asymmetric mechanisms, hashing, Message Authentication Codes, digital signatures, authenticated encryption, and PKI at a decision level.
- Follow keys through generation, distribution, storage, use, rotation, recovery, revocation, archival, and destruction.
- Explain cryptographic agility and the purpose of post-quantum migration planning.
- Identify whether a cryptographic attack targets mathematics, protocol, implementation, key handling, endpoint, or identity infrastructure.
- Apply layered facility design to site selection, zones, utilities, HVAC, fire, power, wiring, server rooms, media, evidence, and work areas.
- Distinguish UPS from generator support and recognize common upstream dependencies.
- Trace security from stakeholder needs through requirements, architecture, implementation, integration, verification, validation, deployment, operation, and retirement.
- Distinguish verification from validation.
- Apply ordinary secure design, least privilege, isolation, input validation, shared responsibility, and lifecycle controls to AI systems.
- Choose the correct next action based on what the scenario has already completed.
16. Official references
Use these primary sources to confirm scope and study the underlying practices:
- ISC2 CISSP Certification Exam Outline
- NIST SP 800-160 Volume 1: Engineering Trustworthy Secure Systems
- NIST SP 800-160 Volume 2 Revision 1: Developing Cyber-Resilient Systems
- NIST SP 800-207: Zero Trust Architecture
- NIST SP 800-53 Revision 5: Security and Privacy Controls for Information Systems and Organizations
- NIST SP 800-57 Part 1 Revision 5: Recommendation for Key Management
- NIST FIPS 140-3: Security Requirements for Cryptographic Modules
- NIST FIPS 203: Module-Lattice-Based Key-Encapsulation Mechanism Standard
- NIST FIPS 204: Module-Lattice-Based Digital Signature Standard
- NIST FIPS 205: Stateless Hash-Based Digital Signature Standard
- NIST SP 800-82 Revision 3: Guide to Operational Technology Security
- NIST SP 800-190: Application Container Security Guide
- NIST SP 800-204A: Building Secure Microservices-Based Applications Using Service-Mesh Architecture
- NIST SP 800-125A Revision 1: Security Recommendations for Server-based Hypervisor Platforms
- NIST AI Risk Management Framework