Layer by Layer
Confidence by Practice
Preparing your CISSP domains…
Read knowledge points freely. Practice, saved topics, progress and personal records require sign-in.
547 knowledge points
Use verifiable secure-design principles throughout the architecture and engineering lifecycle so security is an intrinsic system property rather than a feature added after deployment.
Common traps: Secure design is not equivalent to buying more security products.
Define security objectives, threats, trust boundaries, and controls beginning in requirements and architecture rather than waiting until the system is built to remediate weaknesses.
Common traps: Penetration testing is not a substitute for security by design.
Identify assets, attack surface, trust boundaries, potential attack paths, and mitigations during design and update the threat model as architecture changes.
Common traps: Threat modeling should not be performed only once after deployment.
Locations where trust level, identity domain, management domain, or security control changes are important attack surfaces and should have explicit validation, isolation, and data-flow controls.
Common traps: A trust boundary is not limited to a firewall location.
Reduce attack surface by disabling unnecessary services, interfaces, privileges, and functions while preserving required business capability.
Common traps: Reducing attack surface does not mean disabling every external connection.
Grant subjects only the minimum privilege, scope, and duration required for authorized tasks to reduce the impact of mistakes and abuse.
Common traps: Administrative convenience does not justify permanent maximum privilege.
Enable only business-required services, ports, components, and functions. Least functionality complements least privilege but focuses on exposed functionality rather than permission assignment.
Common traps: Least functionality and least privilege are related but not identical.
Distinctions: least functionality vs least privilege
Even when a subject has a particular privilege level, provide only the information needed for the task and design architecture for fine-grained segmentation and access paths.
Use multiple complementary layers of control so another mechanism can still constrain attack paths and impact when one control fails.
Common traps: Stacking multiple similar products does not automatically create effective defense in depth.
Distinctions: defense in depth vs redundancy
Diverse control mechanisms and failure modes can reduce common-mode failure, although diversity also increases complexity, operational burden, and integration risk.
Redundant capability can improve availability, but identical designs may share the same vulnerability. Redundancy should not be confused with control diversity.
Distinctions: redundancy vs diversity
Secure defaults should restrict access and functionality until explicitly authorized rather than depending on users to harden permissive defaults.
Common traps: Permissive defaults that users must harden are not secure defaults.
Default deny rejects access or communication unless it is explicitly allowed and applies to access control, network rules, and policy engines without preventing authorized services.
Common traps: Default deny still permits explicitly authorized services.
On failure or abnormal conditions, a component should enter a state that protects critical security properties rather than automatically relaxing controls for availability.
Common traps: Fail securely is not always identical to fail closed.
Fail closed blocks access or operations on failure and often protects confidentiality or integrity but can reduce availability. Whether it is appropriate depends on business and security objectives.
Common traps: Not every security-system failure should fail closed regardless of availability and safety needs.
Distinctions: fail closed vs fail open
Fail open allows traffic or operations to continue on failure and can be appropriate for life-safety or critical-availability needs when chosen deliberately through risk analysis rather than convenience.
Common traps: Fail open is not automatically an insecure design when life safety or mission availability requires it.
Distinctions: fail open vs fail closed
Segregation of Duties separates authorization, execution, review, or custody roles in high-risk processes so one person cannot independently complete fraud or another high-impact action.
Common traps: Splitting a process into several steps controlled by the same person does not create separation of duties.
Dual control requires two or more authorized people to participate in a high-risk operation and is a specific implementation of separation of duties.
Distinctions: dual control vs split knowledge
Split knowledge divides a complete secret so no single participant can independently possess the whole secret and is commonly used for high-value key management.
Common traps: Split knowledge is not simply two people pressing one button.
Distinctions: split knowledge vs dual control
Keep designs simple and small by reducing unnecessary complexity, code, dependencies, and state to lower error, attack surface, and verification cost. Complex security mechanisms can themselves create risk.
Common traps: More complexity does not automatically mean stronger security.
Economy of mechanism means security mechanisms should be as simple, understandable, and verifiable as practical and aligns with keep-it-simple-and-small design.
Complete mediation requires every access to a protected object to be authorized rather than validating only the first access and trusting indefinitely afterward.
Common traps: One successful authentication does not permit authorization checks to be skipped indefinitely.
Open design means security should not depend on keeping the algorithm or system design secret. Secrets should be concentrated in manageable elements such as keys while the design can withstand public scrutiny.
Common traps: Hiding system-design details should not be the primary security mechanism.
Distinctions: open design vs security through obscurity
Obscuring implementation details can increase attacker effort but cannot replace validated authentication, authorization, encryption, isolation, and other substantive controls.
Zero Trust provides no implicit trust based on network location or asset ownership and continuously uses identity, device, context, and resource policy for explicit verification and least access.
Common traps: Zero Trust does not mean permanently refusing access to every user.
Being on an enterprise LAN, VPN, or internal cloud does not prove trustworthiness. Resource access still requires identity, device, and policy validation.
Common traps: Internal-network origin does not remove the need for authentication.
Trust but verify permits established trust assumptions while continuing to validate behavior through monitoring and evidence. Unlike Zero Trust, it begins with some preexisting trust relationship.
Distinctions: trust but verify vs zero trust
Zero-trust architectures commonly separate policy decision and policy enforcement functions. Domain 3 focuses on the architecture principle, while detailed identity and network implementation extends to Domains 5 and 4.
Fine-grained microsegmentation among workloads and services can limit lateral movement, but it is only one supporting Zero Trust mechanism and is not the complete Zero Trust architecture.
Common traps: Microsegmentation alone does not complete a Zero Trust program.
Privacy by design integrates data minimization, purpose limitation, access, lifecycle, and demonstrable privacy controls into requirements, architecture, and defaults rather than adding them afterward.
Common traps: Encryption alone is not privacy by design.
Privacy by default configures systems to collect and expose only data needed for the business purpose unless a user deliberately chooses otherwise.
Reduce collection, copying, caching, and display of unnecessary data to reduce both attack surface and privacy risk.
In cloud, managed-service, and supply-chain environments, provider and customer responsibilities differ. Define boundaries explicitly based on service model, contract, and actual control capability.
Common traps: Using SaaS does not remove all customer security responsibility.
In IaaS, the provider usually manages physical infrastructure and lower platform layers while the customer assumes more responsibility for operating systems, applications, identity, data, and configuration. Exact boundaries follow the provider model.
Common traps: IaaS customers commonly retain operating-system security responsibility.
In PaaS, the provider manages more runtime and middleware capability, while the customer still normally owns application, identity, data, and service configuration responsibilities.
In SaaS, the provider manages most application and infrastructure layers, while the customer still commonly owns accounts, authorization, data classification, lawful use, and critical tenant configuration.
Common traps: SaaS security responsibility does not belong entirely to the provider.
Secure Access Service Edge combines wide-area networking with cloud-delivered security services so distributed users and resources receive consistent access and policy enforcement.
Common traps: SASE is broader than a new VPN product.
SASE implementations commonly combine capabilities such as SD-WAN, secure web gateway, CASB, ZTNA, and FWaaS, but CISSP does not require one immutable product-component list.
Common traps: Not every SASE product must contain an identical fixed component set.
Explicitly document trust assumptions involving identity, platforms, suppliers, networks, time, keys, and other dependencies and evaluate the impact if those assumptions fail.
Individually secure components can create new vulnerabilities when combined through interfaces, configuration, inherited permissions, and trust relationships, so evaluate the composed architecture as a whole.
Common traps: Individually certified components do not prove that the combined system is secure.
Separate security domains of different trust levels or sensitivity through process, virtualization, network, account, or physical boundaries to limit propagation of failures and attacks.
Secure interfaces define identity, authorization, input constraints, error handling, logging, and protocol-security requirements at system and component boundaries, which are often easier to attack than internal implementation.
Resilience is an architectural property that allows critical capability to continue or degrade controllably during faults, attacks, or resource stress and supports recovery rather than focusing only on prevention.
Graceful degradation preserves the most critical business capabilities while limiting noncritical functionality when resources are constrained or components fail.
High-performance AI computing can use hardware-protected isolated execution environments to reduce access to sensitive models and data by hosts, administrators, or neighboring workloads, while still requiring validation of threat model and root of trust.
Common traps: A secure enclave does not eliminate every host and side-channel risk.
AI applications should treat external prompts, retrieved content, tool calls, and model outputs as potentially untrusted inputs and validate, constrain, and authorize them at trust boundaries.
Common traps: Natural-language input to an LLM is still system input that may require validation.
Architectures should separate model instructions, external content, and privileged tools and restrict model output from directly triggering sensitive actions. Prompt injection cannot be solved only by writing stronger prompt text.
Common traps: Keeping the system prompt secret does not prevent prompt injection.
For cloud-hosted AI, explicitly define responsibilities among model provider, cloud platform, and customer for data, model, identity, logs, configuration, content filtering, and infrastructure.
Common traps: A provider-hosted AI API does not remove customer responsibility for input data and authorization.
A security model translates high-level security policy into analyzable and implementable rules that describe subjects, objects, state transitions, and permitted information flows.
A subject is an active entity that requests or performs access, such as a user, process, or service.
Distinctions: subject vs object
An object is a passive resource being accessed, such as a file, database record, memory object, or device.
Distinctions: object vs subject
A security state represents the current access relationships, labels, and control conditions. A secure system should remain secure after every permitted state transition.
A state machine model represents a system as states and state transitions. If the initial state is secure and every allowed transition preserves security, the system remains secure.
An information flow model constrains how information may move among subjects, objects, and security levels, preventing flows that violate policy.
A noninterference model aims to ensure that high-level activities do not have observable effects on lower-level subjects, reducing unauthorized information leakage.
A lattice-based access model uses partially ordered security levels and dominance relationships to constrain access and information flow. It provides a theoretical basis for models such as Bell-LaPadula and Biba.
Mandatory Access Control uses labels and system-enforced policy; ordinary users cannot change the core access rules. It is commonly associated with multilevel security.
Discretionary Access Control allows an owner or other authorized subject to grant access within policy constraints, unlike MAC where central policy and labels dominate authorization.
The Bell-LaPadula model protects confidentiality by preventing information from flowing from higher-sensitivity levels to lower-sensitivity levels.
Common traps: Do not treat Bell-LaPadula as an integrity model.
Distinctions: Bell-LaPadula = confidentiality Biba = integrity
Bell-LaPadula's simple security property is “no read up”: a subject cannot read an object at a higher confidentiality level.
Common traps: Do not confuse Bell-LaPadula's “no read up” rule with Biba's integrity direction.
Distinctions: BLP simple = no read up
Bell-LaPadula's *-property is “no write down”: a subject cannot write information to a lower confidentiality level.
Common traps: The Bell-LaPadula *-property is “no write down,” not “no write up.”
Distinctions: BLP star = no write down
Bell-LaPadula's strong *-property permits read and write operations only at the same security level, making it stricter than the standard simple-security and *-property combination.
Bell-LaPadula also includes a discretionary security property based on an access matrix or need-to-know restrictions; holding an adequate clearance does not automatically authorize access to every object at that level.
Bell-LaPadula primarily addresses confidentiality, not integrity or availability, and it does not by itself eliminate every covert channel or implementation flaw.
The Biba model protects integrity by preventing lower-integrity information from contaminating higher-integrity subjects or objects. Its information-flow direction is the inverse of Bell-LaPadula's confidentiality rules.
Common traps: Do not treat Biba as a confidentiality model.
Distinctions: Biba = integrity Bell-LaPadula = confidentiality
Biba's simple integrity property is “no read down”: a subject should not read data at a lower integrity level.
Common traps: Do not misremember Biba's simple integrity property as “no read up.”
Distinctions: Biba simple = no read down
Biba's *-integrity property is “no write up”: a subject should not write data to a higher integrity level.
Common traps: Do not misremember Biba's *-integrity property as “no write down.”
Distinctions: Biba star = no write up
Biba's invocation property prevents a lower-integrity subject from invoking a higher-integrity subject.
Biba primarily addresses integrity, not confidentiality or availability, and it does not capture every form of business-process integrity.
The CISSP outline names the “Star Model.” For exam purposes, understand the *-property write rules in Bell-LaPadula and Biba and their opposite directions rather than inventing a separate undefined model.
Common traps: Do not invent a completely separate set of rules for the outline's “Star Model” apart from the Bell-LaPadula/Biba *-property context.
Distinctions: BLP star = no write down Biba star = no write up
Bell-LaPadula protects confidentiality with “no read up, no write down”; Biba protects integrity with “no read down, no write up.”
Common traps: Do not memorize only the up/down directions and forget each model's security objective.
Clark-Wilson is a commercial integrity model based on well-formed transactions, separation of duties, constrained data items, and certification of transformation procedures.
Common traps: Do not equate Clark-Wilson with Biba's multilevel-label integrity rules.
A Constrained Data Item is protected data whose integrity must be preserved and that may be modified only through authorized transformation procedures.
An Unconstrained Data Item is input not yet subject to Clark-Wilson integrity constraints; it can become controlled data after appropriate validation and transformation.
A Transformation Procedure is an authorized operation that changes a CDI while preserving defined integrity constraints.
An Integrity Verification Procedure checks that CDIs satisfy required integrity constraints.
Clark-Wilson enforces separation of duties by separating authorization, execution, and certification responsibilities across users and transformation procedures.
The Brewer-Nash, or Chinese Wall, model dynamically restricts access based on a subject's prior access to competing organizations' data; access history changes future authorization decisions.
Common traps: Do not treat the Chinese Wall model as a fixed static security-level model.
Distinctions: dynamic conflict-of-interest model
A conflict-of-interest class groups competing organizations or datasets. After a subject accesses one member's sensitive data, access to competing members is restricted to prevent conflicts of interest.
The Graham-Denning model formally describes creation and deletion of subjects and objects and the granting, transfer, and deletion of access rights.
The Harrison-Ruzzo-Ullman model analyzes access-matrix permission propagation, including whether rights can leak to subjects that should not obtain them.
The Take-Grant model represents authorization as a graph and analyzes how rights can propagate through take and grant operations and whether a subject can eventually reach a target right.
An access matrix represents subjects as rows, objects as columns, and permissions as cells. ACLs and capabilities are common implementation views of this concept.
An Access Control List is object-centered: it answers which subjects have which permissions to a particular object.
Distinctions: ACL vs capability
A capability is subject-centered: a subject holds an unforgeable authorization token or permission set describing what objects and operations it may access.
Distinctions: capability vs ACL
The Trusted Computing Base is the collection of hardware, software, and firmware trusted to enforce the security policy. A larger TCB is generally harder to verify and protect.
The security perimeter is the logical or physical boundary that separates the TCB from untrusted components and exposes only controlled interfaces across that boundary.
A reference monitor is the abstract policy-enforcement mechanism that mediates every subject-to-object access. It should be tamper-resistant, non-bypassable, and small enough to analyze or verify.
Common traps: Do not equate the abstract reference monitor with a specific firewall or other single security product.
The security kernel is the core implementation of the reference monitor and normally executes within the TCB at high privilege.
A trusted path is a protected communication path between a user and the TCB or a security function, allowing the user to know that security-sensitive interaction is occurring with the trusted component.
Protection rings are hardware and OS privilege levels that restrict lower-privilege code from directly performing higher-privilege operations. Ring 0 commonly denotes the most privileged level.
Kernel mode or Ring 0 has broad hardware and system access, while user-mode applications run at lower privilege. Unauthorized escalation from user mode to kernel privilege is a major security breach.
Common Criteria, ISO/IEC 15408, is a product-security evaluation framework built around Protection Profiles, Security Targets, and Evaluation Assurance Levels.
Common traps: A higher EAL does not mean a product is universally more secure or more appropriate for every use case.
A Protection Profile defines implementation-independent security requirements for a product category or security problem rather than for one specific product.
A Security Target describes the security functions, operating environment, and assurance requirements claimed for the specific Target of Evaluation.
An Evaluation Assurance Level reflects the rigor and depth of an evaluation. A higher EAL means more rigorous assurance activities, not more security features or better business suitability.
The Target of Evaluation is the product, system, component, or defined boundary that is being evaluated under Common Criteria.
TCSEC, commonly called the Orange Book, is a historical U.S. trusted-computing evaluation standard focused heavily on confidentiality and tiered assurance; Common Criteria is its modern successor context.
A security model defines rules and desired properties; an operating system, database, IAM system, or application implements those rules. A sound model does not prove that the real implementation is free of defects.
Translate business, risk, legal, asset, and threat needs into verifiable confidentiality, integrity, availability, identity, audit, privacy, and resilience requirements.
Define security requirements and risk first, then select controls. Do not buy technology first and search for a problem afterward.
Common traps: Do not choose the strongest product first and define the requirement afterward.
Functional security requirements describe the security functions the system must perform, such as authentication, access restriction, encryption, logging, isolation, and failure protection.
Assurance requirements describe how confidence will be obtained that security functions are correctly designed, implemented, and operated, such as through testing, independent assessment, formal verification, and supply-chain assurance.
Distinctions: security function vs assurance
A security control objective states the risk to be reduced or security outcome to be achieved. Different technical or administrative controls can satisfy the same objective.
Control strength should match asset value, threats, vulnerabilities, impact, business tolerance, and compliance obligations rather than simply pursuing the highest possible security level.
A control baseline provides a starting set of controls for a class of systems and is then scoped and tailored to actual risk, environment, and requirements.
Tailor architectural controls to system boundaries, business needs, and technical constraints without undermining security objectives or mandatory requirements, and document the rationale and compensating measures.
When the preferred control cannot be implemented, choose a compensating control that achieves a comparable risk-reduction objective and verify its coverage and residual risk.
Common traps: An alternative measure is not automatically equivalent to the preferred control; its risk reduction and residual risk must be evaluated.
Preventive architectural controls stop an attack or error before it occurs or reduce its likelihood, such as strong authentication, isolation, input validation, and hardening.
Detective architectural controls identify abnormal activity and control failures, such as integrity monitoring, logging, sensors, and intrusion detection. Detection does not replace necessary prevention.
Corrective and recovery controls restore a secure state, service, or data after an event, such as reconfiguration, image restoration, failover, and key revocation.
Domain 3 emphasizes architectural and engineering controls, but system requirements may also depend on policy, people, and process. A complete design cannot rely only on technical mechanisms.
In the 3.3 control-selection context, each architectural control should trace to a business, risk, regulatory, or system-security requirement so the organization can explain why it is needed and what objective it covers.
Distinctions: 3.3 control-selection traceability vs 3.10 lifecycle traceability
Map attack paths from threat models to preventive, detective, and recovery controls to identify uncovered threats and single points of failure.
Apply stronger controls and verification to exposed interfaces, privileged boundaries, complex parsers, and high-value data paths based on their attack surface.
Controls may depend on identity, time, logging, keys, networks, or platform trust. Architecture must identify how failure of these dependencies affects overall security.
Apparently independent controls can fail together when they share the same identity source, cloud platform, certificate, or software component, creating a common-mode failure.
Place controls where they can best observe or influence the risk, such as at data entry points, trust boundaries, management planes, or near critical assets. Poor placement reduces effectiveness.
Centralized controls simplify consistent policy and auditing, while distributed controls can reduce latency and single points of failure. Architecture should balance availability, trust, and management complexity.
A system may inherit controls from a platform, cloud, or shared service, but the scope of inheritance must be evidenced; upper-layer controls do not automatically cover every application risk.
When a security requirement cannot be met, document the risk, compensating controls, accountable owner, and expiration, and obtain governance approval rather than allowing an engineering team to grant a permanent exception.
In ICS, medical, or other life-safety systems, fail-safe behavior, availability, and human safety may take precedence over traditional fail-closed behavior. The decision should follow business and life-safety risk.
Encryption, inspection, isolation, and logging can add latency and resource cost. Design should meet security objectives while validating capacity and performance rather than simply disabling controls.
Excessively burdensome security can encourage bypasses and shadow practices. Design should reduce unnecessary user friction without sacrificing core security objectives.
When selecting a control, also define how its function, failure modes, and coverage will be tested so that the original requirement can ultimately be verified.
Evaluate the isolation, trusted-boot, memory-protection, encryption, hardware-root-of-trust, and audit capabilities provided by the platform itself, and understand the limits of each capability.
Operating systems and CPUs use address-space isolation, permission bits, execution controls, and related mechanisms to prevent one process from reading or modifying another process's or the kernel's memory without authorization.
Common traps: An application process cannot inherently read all memory on the same host.
Separate processes normally have distinct virtual address spaces and permission boundaries, reducing the ability of one failed or compromised application to directly affect another process.
Virtual memory maps process virtual addresses to physical memory through page tables, supporting isolation, paging, and permissions; incorrect mappings or kernel flaws can break that isolation.
Sensitive data can be written from RAM to swap or page files, so at-rest protection and sensitive-memory handling must account for these secondary copies.
DEP/NX marks data pages non-executable, reducing the ability of traditional code-injection attacks to execute instructions from data regions; it does not stop every memory-exploitation technique.
ASLR randomizes the locations of code, libraries, stacks, and other memory regions, making reliable address prediction harder; information disclosure can weaken its protection.
Stack canaries place a detection value near critical stack data and verify it before return to detect some stack overwrites. They are a mitigation, not a cure for all memory-safety bugs.
Languages with bounds checking, automatic memory management, or ownership mechanisms can reduce classes of memory-corruption vulnerabilities, but they do not eliminate logic, authorization, or design flaws.
Processor privilege rings separate code into privilege levels. Kernels typically run at higher privilege while user applications run at lower privilege, providing hardware-supported isolation.
Supervisor or kernel mode can execute privileged instructions and access core resources; user mode is restricted. Gaining kernel-mode execution from user mode is privilege escalation.
A Trusted Platform Module is a hardware or firmware trust component that provides protected key operations, platform measurements, and device-identity capabilities, supporting disk encryption, attestation, and trusted boot.
Common traps: A TPM is not a general-purpose HSM suitable for every high-throughput enterprise key-management workload.
Distinctions: TPM vs HSM
A TPM can generate or protect keys that are difficult to export and can bind key use to platform state or authorization policy.
TPM Platform Configuration Registers store measurement digests of boot and platform components for later attestation; they hold measurement values, not the complete software contents.
Measured boot measures components in the boot chain and records results in a trusted mechanism so a verifier can later determine what actually booted. It differs from Secure Boot, which blocks untrusted boot code.
Distinctions: measured boot vs secure boot
Secure Boot verifies signatures or a trust chain for firmware, bootloaders, and other boot components and permits only trusted code to progress through the boot process.
Distinctions: secure boot vs measured boot
Remote attestation lets a device provide platform-measurement evidence protected by a root of trust so a remote verifier can assess whether the device is in an expected state.
A Hardware Security Module is a protected device dedicated to high-value key generation, storage, and cryptographic operations, commonly used for enterprise PKI, payments, and code signing.
Common traps: An HSM and a TPM do not serve exactly the same purpose.
Distinctions: HSM vs TPM
A TPM is typically bound to one platform and supports platform trust and local key protection; an HSM usually provides centralized, high-assurance, higher-throughput enterprise key services.
A Trusted Execution Environment creates a hardware-isolated execution area that gives code and data additional protection even from a highly privileged host, while still being subject to side channels and implementation flaws.
A secure enclave is a TEE implementation concept for isolating sensitive computation and keys; it is not absolute protection against the host, supply-chain compromise, or side channels.
A hardware root of trust is the lowest-level, difficult-to-tamper-with trust anchor used for trusted boot, device identity, and integrity evidence, such as ROM keys, a TPM, or a secure element.
A secure element is a dedicated tamper-resistant chip for protected operations such as key storage, payment functions, or device identity, isolated from the general-purpose CPU environment.
A system may provide hardware- or software-based encryption for data at rest, in transit, or in selected use cases. Security depends on algorithms, modes, key management, and implementation, not merely on enabling encryption.
Authorized use normally requires decryption, which exposes plaintext in memory, CPU, or application boundaries. At-rest encryption does not automatically protect data while it is in use.
Full-disk encryption protects data at rest when a device is powered off or media is stolen, but provides limited protection against a logged-in user, malicious administrator, or unauthorized access through the application.
File- and database-level encryption can provide finer-grained protection than full-disk encryption, but introduces issues such as application transparency, key access, query capability, and backup handling.
Self-encrypting drives perform encryption within the storage device and can reduce host CPU overhead, but authentication, key management, firmware, and sanitization capabilities must be managed correctly.
CPU virtualization extensions provide hardware-assisted separation between guests and the hypervisor, improving performance and strengthening boundaries, but hypervisor vulnerabilities can still break isolation.
An IOMMU restricts the memory ranges that peripherals can access through DMA, reducing the risk that a malicious or compromised device can read or modify arbitrary memory.
Platform firmware provides boot, device-configuration, and root-of-trust functions. It should support signed updates, rollback protection, and trusted boot because compromised firmware can bypass higher-layer controls.
Anti-rollback protection prevents an attacker from downgrading firmware or security components to older versions with known vulnerabilities, using trusted version counters or signature policy.
Firmware updates should authenticate the source and integrity, restrict authorization, and support safe failure and recovery so the update mechanism does not become a persistence path.
Hardware-protected device keys and certificates can establish a device identity that is difficult to clone, supporting zero trust, attestation, and supply-chain validation.
GPUs and AI accelerators create additional isolation boundaries through shared memory, DMA, and multi-tenant execution. Appropriate IOMMU controls, memory clearing, tenant isolation, and trusted execution help reduce data-remanence and cross-tenant risk.
Confidential-computing technologies such as TEEs or secure enclaves can add protection for sensitive training or inference data and models while in use; attestation, side-channel exposure, and supply-chain risk still require validation.
Common traps: Confidential computing does not mean the cloud provider can have no effect on the workload.
Assess architectural risk through trust boundaries, exposed interfaces, dependencies, privileges, data flows, single points of failure, and lifecycle concerns rather than relying only on vulnerability scans.
Common traps: A vulnerability-scan result is not a complete architectural risk assessment.
The attack surface includes every interface, protocol, management plane, component, and data entry point that an external or lower-trust subject can interact with; architecture should continuously reduce and monitor it.
Complex platforms are often exposed by open defaults, excessive permissions, incorrect network rules, uncontrolled interfaces, or inconsistent configurations; automated configuration must also be validated.
When many services share an identity source, DNS, key management, cloud region, image, or software library, one dependency failure can cause a broad common failure.
Any component, dependency, person, or service with no alternate path whose failure interrupts a critical function is a single point of failure; redundancy must avoid sharing the same failure domain.
Redundant components that depend on the same software version, power source, region, or supplier can fail together in one event; numerical redundancy alone is not enough.
Establish repeatable minimum-secure configurations for each platform type by disabling unnecessary functions, restricting management planes, enabling logging, and protecting default settings.
Availability, compatibility, certification, or physical-access constraints can delay patching; architecture should use segmentation, redundancy, and compensating controls to reduce risk during the exposure window.
Client endpoints are close to users and often process sensitive data, credentials, and untrusted content, making them susceptible to malware, phishing, loss, and local privilege abuse.
Caches, downloads, browser data, and offline files can copy centrally managed data to endpoints; minimize caching and apply encryption and lifecycle controls.
Restrict local administrators, disable unnecessary services, enable patching, application control, and secure boot to reduce the impact of endpoint compromise.
User interaction, browsers, documents, and peripherals make clients common initial attack vectors, requiring layered detection, least privilege, and content isolation.
Endpoint memory, browsers, tokens, and cached credentials can be stolen; reduce long-lived secrets and use hardware protection and strong identity mechanisms.
Mobile endpoints outside controlled facilities face increased physical risk; use disk encryption, remote management, device identity, and rapid lost-device response.
Servers concentrate high-value data and services and remain online for long periods, making privileged management planes, patching, service exposure, and availability primary risks.
Run only necessary services and listening ports to reduce attack surface and dependencies; new services should undergo change and security review.
Separate administrative interfaces from ordinary business traffic and protect them with strong authentication, least privilege, controlled jump hosts, and auditing.
Long-running servers can drift from baselines through temporary changes and inconsistent updates; continuously detect drift and correct it through configuration management.
Use clustering, load balancing, redundancy, health checks, and failover to reduce single points of failure, while ensuring shared storage, identity, or networks do not become hidden single points.
Management interfaces and out-of-band controls are highly privileged; restrict their sources, use separate identities, encrypt and monitor them, and separate them from the data plane when appropriate.
Databases concentrate structured high-value data; risks include excessive privilege, injection, weak separation, exposed backups, inference, and aggregation.
Applications and users should receive only the required schema, table, row, column, and operation privileges; avoid shared highly privileged database accounts.
Even without direct access to sensitive fields, users may infer sensitive facts from statistical queries, differential results, or correlated data.
Aggregating many individually low-sensitivity records can create a highly sensitive profile or business intelligence; access and export controls should account for volume and combination effects.
Views or APIs can expose only the rows and fields needed for a business function, reducing direct table access, but the view itself still requires correct authorization and inference controls.
TDE and file encryption mainly protect storage media at rest; they do not automatically prevent misuse by authorized database processes, administrators, or SQL-level access.
Logging high-risk queries, permission changes, bulk exports, and administrative actions supports anomaly detection, but log access and integrity must also be protected.
Architecture should limit injection impact through parameterized interfaces, input boundaries, and least-privilege database access; detailed secure coding and testing belong to Domain 8.
Cryptographic-system risk comes from algorithm selection, key lifecycle, randomness, modes, protocol composition, and implementation—not only from theoretical algorithm strength.
In the 3.5 vulnerability-assessment context, cryptographic agility is the ability to migrate safely when algorithms, key lengths, certificates, or standards weaken or retire; lacking this capability is itself a long-term architectural weakness.
Distinctions: 3.5 vulnerability/architecture-debt perspective vs 3.6 cryptographic-solution design principle cryptographic agility vs algorithm strength
Even a sound algorithm can be defeated by weak randomness, nonce reuse, side channels, incorrect certificate validation, or leaked keys.
Mapping applications, protocols, certificates, hardware, and data to the algorithms and keys they depend on is foundational for crypto-agility and post-quantum migration.
HSMs, TPMs, and secure elements can improve key isolation and assurance for high-value operations, but device supply chain, access, backup, and lifecycle still require governance.
Industrial Control Systems directly affect physical processes, so security design must also address human safety, process reliability, real-time behavior, and availability rather than copying ordinary IT priorities.
In life-safety or process-stability situations, immediately blocking activity may be more dangerous than continuing in a constrained mode; controls must align with process-safety requirements.
Many industrial protocols were designed for trusted networks and may lack strong authentication, encryption, or integrity; compensate with segmentation, gateways, and monitoring.
Segment enterprise IT, industrial control zones, safety systems, and remote-maintenance paths to restrict lateral movement and unintended traffic.
Production downtime, vendor certification, and real-time requirements can delay ICS patches; use tested maintenance windows, isolation, application allowlisting, and monitoring to reduce risk.
Control systems depend on predictable latency and stable behavior; deep inspection or resource-intensive security tools can disrupt the process and therefore require engineering validation.
An independent Safety Instrumented System should avoid excessive shared dependencies with the normal control network so that one cyber incident cannot also defeat safety protection.
Vendor maintenance and remote operations are high-risk ICS paths; use strong authentication, jump hosts, time-limited access, monitoring, and revocable authorization.
Accurate inventories of controllers, HMIs, engineering workstations, firmware, and dependencies are essential; unvalidated configuration changes can have physical consequences.
On failure or attack, the physical process should move to a pre-analyzed safe state; the safe state is not necessarily “turn everything off.”
Cloud architecture relies on virtualization, APIs, automation, and shared infrastructure; major risks include misconfiguration, identity abuse, multi-tenancy, control planes, and responsibility boundaries.
Customer and provider responsibilities differ across IaaS, PaaS, and SaaS; the organization must explicitly identify the identity, data, application, and configuration controls it still owns.
Cloud management APIs and consoles can create, modify, or delete large numbers of resources, making the control plane a high-value attack surface that requires strong identity, least privilege, and auditing.
The data plane carries business traffic and data operations; the control plane manages resources and policy. Their identity, network, and monitoring requirements differ.
Public storage, overly broad IAM, default networks, and incorrect key configurations are common cloud risks; Infrastructure as Code can rapidly amplify a configuration error.
Multiple tenants share physical or logical cloud infrastructure and depend on hypervisor, network, storage, and service isolation; customers should understand provider isolation assurances and their own configuration responsibilities.
Tenant isolation uses identity, network, compute, storage, and key boundaries to prevent one tenant from accessing another; isolation failure can produce high-impact cross-tenant disclosure.
Cloud automation depends heavily on APIs, so weak tokens, excessive permissions, missing validation, or inadequate logging can greatly increase the attack surface.
Choose deliberately among provider-managed, customer-managed, or external keys based on the trust and responsibility model. Customer-managed keys increase control but also availability and lifecycle responsibility.
Deploying across failure domains can improve resilience, but cross-region replication may affect latency, cost, and data-residency requirements.
Heavy dependence on one cloud platform, identity provider, or region creates enterprise concentration risk even when individual workloads have local redundancy.
Cloud observability should cover control-plane, identity, network, and data-service logs, with independent protection and retention; application logs alone miss platform events.
Architecture should plan data export, keys, formats, dependencies, and replacement services to reduce vendor lock-in and abrupt-termination risk.
Distributed systems coordinate across nodes and networks and must handle partial failure, clocks, identity, state consistency, and potentially untrusted nodes.
Some nodes or links can fail while other parts continue running; design timeouts, retries, quorum behavior, and idempotence for these partial failures.
A network partition can make multiple nodes believe they are primary, causing conflicts or data corruption; quorum, fencing, and similar consistency mechanisms mitigate split brain.
Services must authenticate and authorize each other and protect message integrity; internal cluster location is not sufficient reason for automatic trust.
Under partitions and latency, distributed designs trade among consistency, availability, and latency; security controls should reflect business tolerance for those tradeoffs.
Retries and asynchronous queues can cause duplicate execution; use idempotent design, nonces, sequence numbers, or transaction controls to prevent repeated high-risk actions.
IoT devices are often resource-constrained, long-lived, physically exposed, and dependent on cloud or mobile management; security must cover device identity, firmware, communications, and lifecycle.
Shared or unchangeable default passwords can enable mass compromise; use per-device identity, strong authentication, and secure initial provisioning.
IoT firmware should support signed updates, secure boot, version control, and rollback protection; devices without long-term update capability can accumulate permanent vulnerabilities.
IoT devices are often deployed in unattended locations where attackers can access debug ports, storage, and buses; use tamper resistance, disable debug interfaces, and establish a hardware root of trust.
CPU, battery, and storage constraints can limit encryption, logging, and update designs; choose controls appropriate to the device rather than copying a server security design.
Sensors may continuously collect location, audio/video, and behavioral data; apply data minimization, classification, protected transmission, and retention limits.
An IoT gateway aggregates many devices and connects trust domains, making it both a high-value control point and potential single point of failure; harden identity, protocol translation, segmentation, and updates.
IoT devices may operate for years after a supplier ends support. Procurement should evaluate update support, key rotation, and secure retirement capabilities.
Microservices use many small independently deployable services communicating through APIs and messages. This increases delivery flexibility but also identity, interface, dependency, logging, and policy complexity.
Every service call should authenticate and authorize the caller rather than trusting network location; short-lived workload identities are generally preferable to shared long-lived secrets.
An API gateway can centralize authentication, rate limiting, routing, and logging, but it must not become the only security layer; east-west calls still require security controls.
Services should enforce least-privilege authorization at data and operation boundaries so compromise of one service does not grant broad lateral access across the system.
Dynamic services should not hard-code API keys, passwords, or certificates in images or configuration repositories; use controlled secret delivery and rotation.
Microservice architectures generate extensive east-west traffic across trust boundaries; encryption, identity, policy, and observability are needed in addition to north-south perimeter protection.
A service mesh can provide common mTLS, identity, and policy enforcement, but its control plane, certificates, sidecars, or proxies become high-value dependencies.
Failure of a shared library, authentication service, configuration system, or message bus can affect many microservices at once; identify dependencies and failure domains.
Containers share the host kernel and isolate workloads through namespaces, cgroups, and related mechanisms. They are lightweight, but their isolation boundary differs from a full virtual machine.
Containers usually share the host kernel, while VMs provide a more complete guest-OS boundary. A container should not automatically be treated as equivalent to an independently isolated VM.
Common traps: Containers do not have independent kernels; their isolation should not automatically be considered stronger than a VM boundary.
Distinctions: containers vs VMs
Use trusted registries, signatures, SBOMs, and vulnerability scanning to validate container-image provenance and dependencies and avoid malicious or obsolete base images.
Kernel, runtime, or configuration flaws can allow a process to escape a container and access the host or other containers; use least privilege, patched runtimes, and restricted capabilities.
Privileged mode or excessive Linux capabilities significantly weaken container isolation and should be used only when necessary and tightly controlled.
Secrets should not be embedded in image layers, logged environment variables, or public configuration. Deliver and rotate them dynamically through a dedicated secret mechanism.
A container orchestrator can create workloads, access secrets, and change network policy, making its control plane highly privileged; protect it with strong identity, RBAC, auditing, and isolation.
Short-lived containers can lose local logs and forensic evidence quickly; collect events, images, and runtime metadata centrally.
Serverless computing transfers more infrastructure management to the cloud provider, but the customer still owns function code, identity, event inputs, data, dependencies, and configuration.
Each serverless function should use the minimum execution role and resource permissions needed so compromise of one function does not expose the entire cloud account.
Functions may be triggered by messages, HTTP, storage, or scheduled events; validate untrusted event payloads and constrain invocation chains.
Function packages, layers, runtimes, and third-party libraries still require supply-chain and vulnerability management; “serverless” does not remove software-dependency risk.
Short lifetimes and provider abstraction limit traditional host monitoring; rely on cloud audit logs, function logs, traces, and event correlation for observability.
The provider manages the underlying serverless runtime, but the customer remains responsible for function logic, IAM, data, triggers, and security configuration.
Embedded systems are often fixed-function, resource-constrained, long-lived, and physically exposed; security must address firmware, debug interfaces, boot, and updates.
The boot and update chain should verify firmware signatures so malicious firmware cannot gain persistent control.
Production devices that leave JTAG, UART, or similar debug interfaces enabled may let attackers bypass software controls to read memory or alter firmware.
Embedded Secure Boot begins with an immutable trust anchor and verifies subsequent firmware and code, preventing unauthorized components from executing during startup.
Over-the-air updates should verify signatures, version, and authorization and support rollback protection and failure recovery; update signing keys are critical assets.
Select tamper-evident, tamper-resistant, or tamper-responsive designs based on the threat to protect keys and critical components.
Embedded-system design must account for years of key rotation, vulnerability remediation, certificate expiration, and secure retirement or the deployed device may become impossible to fix.
HPC environments combine large numbers of compute nodes, high-speed interconnects, shared storage, and schedulers; security must balance throughput, shared resources, research data, and privileged jobs.
The job scheduler determines who can use compute resources and data, making it a privileged control point that requires strong identity, quotas, isolation, and auditing.
Parallel shared file systems aggregate sensitive data and privileged access; isolate projects, restrict permissions, and protect management interfaces.
Low-latency HPC interconnects may bypass traditional network devices and monitoring paths, requiring specialized segmentation, protocol security, and node trust controls.
When organizations or research workloads share compute nodes, GPUs, and storage, prevent cross-workload access to memory, files, and devices.
Large or malicious jobs can exhaust compute, storage, or interconnect capacity; use quotas, scheduling, and monitoring to preserve availability for critical work.
Edge computing places processing near users or data sources to reduce latency but increases physical exposure, distributed management, and intermittent-connectivity risk.
Edge nodes often operate in remote or uncontrolled locations; use device encryption, Secure Boot, tamper protection, and remote attestation.
Edge nodes must operate securely while disconnected and cache data safely; on reconnection, synchronize state, patches, and logs securely.
Local processing can reduce raw-data transmission but creates more distributed data copies that require classification, retention, and disposal controls.
A centralized edge-management platform can control many nodes at once and is therefore a high-value attack surface requiring strong identity, signed updates, and tiered authorization.
Before trusting data from an edge node or allowing it to join the system, hardware identity and attestation can be used to verify device state.
A hypervisor isolates multiple VMs on shared hardware, providing abstraction and flexibility while making the hypervisor and management plane high-value trust anchors.
A Type 1 hypervisor runs directly on hardware; a Type 2 hypervisor runs on a host operating system. Their trust and attack surfaces differ, but type alone does not prove security.
Common traps: A Type 1 hypervisor is not immune to attack.
Hypervisor vulnerabilities, management interfaces, and device-emulation flaws can affect many VMs, making the hypervisor one of the most critical privileged components in a virtualized architecture.
VM escape occurs when an attacker breaks guest isolation to access the host or other VMs, representing a high-impact failure of the virtualization boundary.
Rapid VM creation can produce unknown, unpatched, or ownerless assets; control sprawl through inventory, templates, and lifecycle management.
Snapshots can contain sensitive memory, disk contents, and old credentials. Restoring an old snapshot can also roll back patches or security state, so snapshots must be protected as sensitive assets.
Traffic between VMs on the same host may never traverse physical network controls; enforce policy and visibility through virtual switches, distributed firewalls, or other virtual layers.
Live migration transfers VM memory and state, so protect the transfer, authorize the destination host, and secure management interfaces to prevent interception or migration to an untrusted host.
Competing guests can exhaust shared CPU, memory, storage, or network resources, creating noisy-neighbor or DoS conditions; use quotas, reservations, and monitoring.
A virtual TPM can provide TPM-like functions to a VM, but its trust depends on the hypervisor, key protection, and migration design, so its boundary differs from that of a physical TPM.
Treat retrieved content, user input, and tool output as untrusted data, separate system instructions from privileged actions, and enforce authorization and validation outside the model to mitigate prompt injection.
Common traps: Do not treat prompt injection only as a model-training-quality problem.
For deliberately adversarial inputs, constrain accepted input domains, detect anomalies, protect model interfaces, and independently validate high-impact outputs rather than relying only on the model's own judgment.
Isolate model-serving components from sensitive tools, keys, training environments, and management planes, using least-privilege identities and explicit API boundaries to limit blast radius.
Large AI training and inference workloads consume substantial GPU, storage, and network capacity; architecture should address resource exhaustion, failure domains, queues, and graceful degradation.
Shared GPUs and AI accelerators can create memory-remanence, side-channel, and resource-contention risks; evaluate provider isolation, memory clearing, allocation policy, and trusted-execution capabilities.
Select cryptographic solutions based on security objectives, data lifecycle, performance, interoperability, regulatory requirements, and threats rather than comparing algorithm bit lengths alone.
Encryption provides confidentiality by making plaintext difficult to recover without the correct key; effectiveness depends on the algorithm, mode, key management, and implementation.
Use MACs, digital signatures, or cryptographically protected checks to detect unauthorized modification. Encryption alone does not necessarily provide integrity.
Shared secrets, certificates, MACs, and digital signatures can help authenticate entities or message origin, but the authentication meaning depends on the protocol and how keys are bound to identities.
Reliable digital signatures, strong identity binding, private-key control, and sound evidence processes can support nonrepudiation; a shared-secret MAC normally cannot prove a unique signer to a third party.
Manage algorithms, protocols, and keys from selection and deployment through use, rotation, and retirement so systems can respond to weak algorithms, key compromise, and changing standards.
In the 3.6 solution-selection context, crypto-agility is the design ability to replace algorithms, key lengths, certificates, or protocols in a controlled manner without major redesign, supporting algorithm retirement, standards changes, and PQC migration.
Distinctions: 3.6 solution-selection/design principle vs 3.5 vulnerability/architecture-debt perspective crypto-agility vs cryptographic strength
Choose publicly analyzed, standardized algorithms that meet current security-strength and business requirements; avoid proprietary homegrown cryptography and deprecated algorithms.
Common traps: A proprietary algorithm is not inherently more secure because its design is secret.
When an algorithm, key length, or mode no longer meets security requirements, stop using it for new purposes, plan migration, and address historical data and dependencies.
Keys must be controlled throughout generation, distribution, storage, use, rotation, backup, recovery, revocation, archival, and destruction.
Generate keys using sufficient entropy and validated random-number mechanisms; weak randomness directly undermines otherwise strong algorithms.
Keys, nonces, and IVs require unpredictable or protocol-appropriate random or pseudorandom values; ordinary application random functions may not be suitable for cryptographic use.
Cryptographic randomness depends on high-quality unpredictable inputs. Early boot, embedded devices, and cloned VMs can suffer from insufficient entropy.
Key distribution must protect confidentiality, integrity, and recipient identity. Secure distribution is one of the major management challenges for symmetric keys.
Separate keys from ordinary data and code, use protected keystores, TPMs, HSMs, or dedicated secret-management systems according to key value, and restrict export.
Periodic or event-driven key rotation limits the exposure window of one key, but rotation must account for re-encryption, service continuity, and access to data protected by old keys.
When keys are compromised, identities change, or authorization ends, stop trusting the affected key or certificate and ensure relying parties learn the revocation status promptly.
Destroy keys reliably when no longer needed, especially keys on which cryptographic erase depends, accounting for backups, HSM replicas, and escrow copies.
Encryption keys needed for data recovery may require backup, but backups expand the exposure surface and should use strong protection, separation of duties, and audited recovery.
Key escrow places decryption keys or recovery material with a trusted party for recovery, legal, or business needs; it also creates a high-value concentration of sensitive material.
Key recovery restores required decryption capability through controlled backup, escrow, or recovery procedures and should use dual control, auditing, and strong authorization.
Split knowledge divides critical secret material among multiple authorized people so that no one person independently possesses the complete high-value key.
Dual control requires at least two authorized people to participate in a sensitive key operation. It can be combined with split knowledge but is a distinct concept.
Symmetric cryptography uses the same or equivalent shared secret for encryption and decryption. It is usually fast and suitable for bulk data, but key distribution and scalability are major challenges.
Distinctions: symmetric vs asymmetric
Asymmetric cryptography uses mathematically related public and private key pairs and supports key establishment, digital signatures, and identity binding, but is generally more computationally expensive than symmetric cryptography.
Distinctions: asymmetric vs symmetric
Hybrid cryptography commonly uses an asymmetric mechanism to establish or protect a session key and an efficient symmetric algorithm for bulk encryption, combining the strengths of both approaches.
AES is a widely used modern symmetric block cipher with standard key sizes of 128, 192, and 256 bits; actual security also depends on mode, key management, and implementation.
DES has an effective 56-bit key and is no longer adequate against modern brute-force attacks; treat it as legacy exam knowledge, not a new-system choice.
3DES strengthens DES through repeated operations but is limited by performance and security constraints and is no longer a preferred choice for new designs; modern systems should migrate to stronger standards.
A block cipher transforms fixed-size blocks of data; practical security depends on the mode of operation, IV or nonce handling, and authentication mechanism, not only the underlying cipher.
A stream cipher generates a keystream that is combined with data and is useful for streaming communications; reusing the same key or nonce combination can catastrophically reveal information.
ECB produces identical ciphertext blocks for identical plaintext blocks, revealing patterns, so it is unsuitable for most structured data requiring confidentiality.
Common traps: ECB is not the most secure mode merely because it is simple to implement.
CBC chains each block to the previous ciphertext block and requires an unpredictable IV. CBC alone does not provide authentication, and faulty implementations can enable attacks such as padding oracles.
CTR turns a block cipher into a stream-like mode and supports parallel processing; a counter or nonce must never be reused with the same key.
GCM provides confidentiality plus integrity and authentication with high performance, but nonce reuse can severely compromise security.
AEAD protects ciphertext confidentiality and integrity while also authenticating associated metadata that need not be encrypted, making it a preferred construction in many modern protocols.
Many modes use an Initialization Vector to provide randomness or uniqueness. Whether an IV must be secret depends on the mode, but it must meet that mode's unpredictability or uniqueness requirements.
A nonce is a value intended for one-time use to prevent replay or ensure unique cryptographic inputs; nonce reuse in modes such as GCM or CTR can be catastrophic.
RSA is a public-key algorithm based on the difficulty of integer factorization and can support signatures and certain key-establishment or encryption uses; security requires correct padding, adequate key sizes, and sound implementation.
Elliptic Curve Cryptography is based on the elliptic-curve discrete-logarithm problem and can provide security comparable to traditional public-key systems with smaller keys, commonly for signatures and key exchange.
Diffie-Hellman allows parties to establish a shared secret over an untrusted channel, but basic DH does not authenticate the parties and must be combined with certificates, signatures, or another authentication mechanism to prevent MITM attacks.
ECDH provides ECC-based key agreement and efficient shared-secret establishment with smaller parameters; it still requires identity authentication to prevent MITM attacks.
Perfect Forward Secrecy uses ephemeral session keys so later compromise of a long-term private key should not decrypt completed past sessions; it is commonly achieved with ephemeral DH or ECDH.
A hash function maps arbitrary-length input to a fixed-length digest. Desired properties include one-way behavior and resistance to preimage, second-preimage, and collision attacks; hashing is not encryption.
SHA-2 is a widely used modern hash family including SHA-256, SHA-384, and SHA-512; select a member according to the application and current standards.
SHA-3 is a standardized hash family based on Keccak and has a different internal structure from SHA-2, providing algorithmic diversity.
MD5 has practical collision attacks and is unsuitable for secure digital signatures or integrity assurance; retain it only as legacy-recognition knowledge.
SHA-1 no longer provides adequate collision resistance and should not be used as the basis for new digital-signature or secure-integrity designs.
A Message Authentication Code uses a shared secret to provide message integrity and source authentication; because both parties share the secret, it normally cannot provide third-party nonrepudiation.
HMAC combines a cryptographic hash with a shared secret to generate a MAC that verifies message integrity and origin from a holder of the shared key.
A digital signature is generated with the signer's private key over a message digest or protocol data and verified with the public key; it can support integrity, origin authentication, and evidence for nonrepudiation.
The primary purpose of a digital signature is integrity and origin authentication, not confidentiality. Confidentiality is normally provided using the recipient's public key or a symmetric session key.
Common traps: “Encrypting with a private key” is not a complete or generally correct definition of every digital-signature operation.
Distinctions: signature vs encryption
A digital certificate binds a subject's identity or attributes to a public key through the digital signature of a trusted issuer.
Public Key Infrastructure manages public-key identity binding, certificate issuance, validation, revocation, trust chains, and related policy; it is more than a CA server.
A Certificate Authority issues and signs digital certificates and maintains trust and revocation processes. A root CA private key is an extremely high-value asset.
A Registration Authority verifies certificate applicants' identities and forwards validated requests to the CA; it normally does not perform root-trust signing.
A Root CA is the self-signed or pre-trusted anchor at the top of a PKI trust chain; its private key should be highly protected and kept offline as much as practical.
An Intermediate CA is issued by a root or superior CA and performs routine certificate issuance, isolating the root key and supporting hierarchical trust.
Certificate-chain validation checks signatures, validity periods, names or usages, trust anchors, and revocation status; merely having a certificate file is not sufficient.
A Certificate Revocation List is a periodically published list of revoked certificates. Clients must obtain and check a sufficiently fresh list, which creates size and update-latency concerns.
OCSP lets a client query the current status of a specific certificate, providing fresher status than a full CRL but adding availability, privacy, and responder-trust considerations.
OCSP stapling lets a server provide a recent OCSP-responder-signed status response, reducing direct client queries to the CA and improving performance and privacy.
Expiration is the planned end of a certificate's validity period; revocation terminates trust early because of compromise, identity change, or another event. They are not the same.
Certificate pinning restricts which certificates or public keys an application will accept and can reduce some CA-related risks, but adds complexity to rotation, recovery, and availability.
Sufficiently capable quantum computers pose a long-term threat to public-key algorithms based on integer factorization and discrete logarithms, so organizations should plan post-quantum migration in advance.
“Harvest now, decrypt later” means attackers may steal long-lived sensitive ciphertext today and wait for future quantum capability to decrypt it; data requiring long-term confidentiality should consider PQC early.
Post-Quantum Cryptography uses algorithms that run on conventional computers but are designed to resist quantum attacks, especially to replace vulnerable key-establishment and digital-signature mechanisms.
Distinctions: PQC vs QKD
NIST FIPS 203 standardizes ML-KEM for post-quantum key encapsulation and shared-secret establishment; it is not a digital-signature algorithm.
Common traps: Do not treat ML-KEM as a digital-signature algorithm.
Distinctions: ML-KEM = KEM
NIST FIPS 204 standardizes ML-DSA for post-quantum digital signatures; it is not a general symmetric-encryption algorithm or a KEM.
Common traps: Do not treat ML-DSA as a key-encapsulation mechanism.
Distinctions: ML-DSA = signature
NIST FIPS 205 standardizes the hash-based SLH-DSA digital-signature scheme, providing a post-quantum signature option based on a different mathematical foundation.
Common traps: Do not treat SLH-DSA as a data-encryption algorithm.
Distinctions: SLH-DSA = signature
PQC migration should begin by inventorying algorithm and certificate dependencies, building crypto-agility, prioritizing by data lifetime and risk, and validating performance, interoperability, and supply-chain support.
During transition, combining classical and PQC mechanisms can reduce dependence on one new algorithm, but combinations should follow standardized protocol designs rather than ad hoc constructions.
Quantum Key Distribution uses quantum-physical properties to help parties establish keys and detect eavesdropping on the distribution link; it requires specialized infrastructure and an authenticated classical channel.
Common traps: QKD and PQC are different technologies.
Distinctions: QKD vs PQC
The ISC2 outline mentions QKD in a PKI example, but QKD itself is a physical key-distribution mechanism and does not automatically provide digital certificates, identity governance, or a complete PKI.
Common traps: Deploying QKD does not eliminate the need for CAs, certificates, and identity governance in a PKI.
High-assurance environments may require cryptographic modules validated to applicable standards. “Using a standardized algorithm” is different from having the complete cryptographic module validated.
The FIPS 140 family defines cryptographic-module security requirements and a validation framework for relevant government or contractual contexts; a FIPS label is not a universal legal requirement for all products.
If a key is suspected of compromise, revoke or rotate it, assess affected data and signatures, update dependencies, investigate the cause, and determine the exposure of historical sessions.
Cryptographic erase is valid only when the data has always been protected by strong encryption and every relevant copy of the encryption key is reliably destroyed.
Maintain an inventory of critical certificates, algorithms, expiration dates, owners, key locations, and dependencies to avoid expired certificates or weak algorithms becoming hidden single points of failure.
Model weights, training data, and AI-service communications can be encrypted according to sensitivity, but encryption does not solve prompt injection, model abuse, or plaintext exposure during authorized inference.
Cryptanalysis studies cryptographic systems, protocols, or implementations to recover plaintext or keys or otherwise break security properties. Attacks may target mathematics, implementation, key management, or protocol composition.
A brute-force attack systematically tries candidate keys or passwords until a valid one is found; a sufficiently large, high-entropy key space is the basic defense against exhaustive search.
The theoretical key space grows exponentially with effective key length, but weak generation, predictable keys, or implementation restrictions can greatly reduce the practical search space.
In a ciphertext-only attack the attacker has only ciphertext and tries to infer plaintext or the key; modern cryptography should remain secure under this strong attacker assumption.
In a known-plaintext attack, the attacker knows some plaintext and corresponding ciphertext pairs and uses them to analyze the key or weaknesses in the algorithm.
In a chosen-plaintext attack, the attacker can choose plaintexts and obtain corresponding ciphertexts, enabling more active analysis; modern schemes are commonly designed with this capability in mind.
In a chosen-ciphertext attack, the attacker submits selected ciphertexts and observes decryption results or errors, potentially creating a decryption oracle; secure schemes should resist adaptive queries.
Frequency analysis uses statistical patterns in natural language to break classical ciphers such as simple substitution; it is not directly effective against modern strong cryptography.
Differential cryptanalysis studies how differences in inputs influence differences in outputs to analyze block-cipher structure; modern standardized ciphers are designed with such attacks in mind.
Linear cryptanalysis uses statistical linear approximations among plaintext, ciphertext, and key bits to analyze block ciphers and generally requires many samples and exploitable structural bias.
A birthday attack exploits the birthday paradox to find hash collisions. For an ideal n-bit hash, generic collision work is about 2^(n/2), so collision strength is lower than preimage strength.
A collision attack finds two different inputs with the same hash and primarily threatens uses of weak hashes in digital signatures and integrity protection.
A preimage attack starts from a hash and seeks any input that produces it. It differs from a collision attack; an ideal n-bit hash requires roughly 2^n generic work.
Rainbow tables use precomputation to accelerate cracking of unsalted or low-cost password hashes; a unique random salt makes precomputed tables difficult to reuse across users.
Implementation attacks do not defeat the underlying mathematics directly; they exploit randomness, memory, error handling, APIs, padding, certificate validation, or coding flaws.
A side-channel attack derives secrets from timing, power, electromagnetic, cache, or other physical or microarchitectural leakage rather than directly breaking the cryptographic algorithm.
A timing attack infers keys, passwords, or comparison results from execution-time differences correlated with secret values; constant-time implementations are a common mitigation.
Power analysis measures power-consumption variations during cryptographic operations to infer keys and is especially relevant to smart cards and embedded hardware.
Electromagnetic side-channel analysis observes EM emissions from device computation to infer internal activity or secrets, generally requiring physical proximity or specialized equipment.
Cache side-channel attacks infer another process's or tenant's secrets from shared CPU-cache access timing and patterns, an important risk in multi-tenant shared hardware.
Fault injection induces computation errors through voltage, clock, laser, temperature, software, or other faults and uses erroneous behavior to bypass controls or recover secrets.
A padding-oracle attack exploits observable differences between valid and invalid padding responses to progressively recover plaintext, showing how error handling and protocol composition can undermine a sound cipher.
Reusing a key or nonce combination in modes such as CTR or GCM can reveal plaintext relationships and even break authentication; uniqueness requirements must be enforced strictly.
An IV that fails the mode's randomness or uniqueness requirement can reveal patterns or weaken confidentiality; IV handling is security-critical metadata, not an irrelevant detail.
Predictable random-number generation can expose keys, session tokens, nonces, and signature parameters even when the underlying cryptographic algorithm is mathematically strong.
A Man-in-the-Middle attacker intercepts and may alter traffic between communicating parties; unauthenticated key agreement is particularly vulnerable to MITM.
A downgrade attack induces parties to negotiate a weaker algorithm, protocol version, or security option; disable weak choices and protect negotiation to mitigate it.
A replay attack resends a previously valid authentication or signed message; use nonces, timestamps, sequence numbers, or challenges to provide freshness.
Pass-the-hash uses a stolen password hash or equivalent credential material directly for authentication without recovering the plaintext password. Although listed under 3.7, it is primarily credential reuse rather than mathematical hash cracking.
Common traps: Pass-the-hash does not require first brute-forcing the plaintext password.
Kerberos can be abused through tickets, service accounts, key material, and configuration weaknesses. Although the outline lists it in 3.7, most technical details concern IAM and operational trust rather than cryptanalysis of the underlying cipher.
Kerberoasting obtains service tickets and performs offline guessing against service-account password-derived keys; risk increases with weak service-account passwords and weaker encryption types.
A Golden Ticket attack uses compromised Kerberos domain key material to forge highly privileged TGTs. It represents severe identity-infrastructure compromise rather than ordinary password cracking.
Ransomware uses cryptography maliciously to deny an organization access to its own data; its core is malicious use of encryption rather than traditional cryptanalysis. Recovery emphasizes prevention, isolation, backups, and incident response.
Common traps: Ransomware's main objective is not to break the enterprise's encryption algorithm.
Cryptojacking abuses computing resources for cryptocurrency mining, while ransomware usually encrypts or blocks data to demand payment; their objectives and impacts differ.
Disable weak algorithms and protocols, reduce key exposure, use secure implementations, control error information, and rotate keys promptly to reduce both mathematical and implementation attack surfaces.
Constant-time implementations try to keep execution paths for sensitive operations independent of secret values, reducing some timing and cache side-channel leakage.
Side-channel mitigation can combine constant-time code, masking, isolation, noise, tamper-resistant hardware, and reduced sharing; no single technique covers every side channel.
AI accelerators and multi-tenant compute still rely on ordinary keys, TLS, and platform isolation; evaluate cryptographic side-channel risk using the shared-hardware threat model rather than assuming AI workloads are fundamentally different.
Design layered physical and environmental protection from the outset based on site location, threats, people flow, asset value, critical dependencies, and life safety rather than adding devices after construction.
Assess natural disasters, crime, civil disturbance, transportation, neighboring facilities, critical infrastructure, and human threats to determine site suitability and control strength.
Before selecting a site, consider flood, earthquake, wildfire, storm, crime, transportation, political risk, neighboring hazards, and utility reliability; avoiding a bad location is often more effective than retrofitting controls.
Flood zones, seismic areas, storms, fire, and extreme temperatures can affect buildings, power, communications, and personnel access and should be incorporated into facility design and BC or DR planning.
Industrial accidents, explosions, pollution, protests, terrorism, transportation accidents, and nearby hazardous facilities can affect site availability and personnel safety.
Nearby airports, railways, chemical plants, government targets, rivers, dams, or high-crime areas can increase accident, attack, or evacuation risk.
External dependencies such as electricity, water, fuel, communications, sewage, and cooling should be assessed for reliability, alternative paths, and recovery time.
Fire, medical, and law-enforcement response times affect life safety and recovery; site design should allow emergency personnel and vehicles rapid access.
Use progressively stronger physical-security zones from public and reception areas through work areas to high-security areas so sensitive assets are not directly exposed to outer zones.
Use multiple concentric layers such as the property boundary, building shell, internal zones, computer rooms, and cabinets to increase barriers and opportunities for detection.
Effective physical security combines deterrence, timely detection, delay, and response so responders can act before an attacker fully succeeds; it is not only about building an impenetrable barrier.
Crime Prevention Through Environmental Design uses natural surveillance, access control, territorial reinforcement, and maintenance so the physical layout itself reduces opportunities for crime.
Natural surveillance uses lighting, sight lines, windows, and spatial design to make activity visible and reduce concealed approaches and tailgating opportunities.
Natural access control uses roads, landscaping, entrance placement, and movement patterns to guide people through controlled entry points rather than relying solely on electronic access control.
Territorial reinforcement uses boundaries, signs, and spatial design to make public and controlled areas clear so abnormal entry is easier to recognize.
Facility security controls must not obstruct emergency evacuation, firefighting, or rescue. High-security access controls must be coordinated with life-safety codes and emergency mechanisms.
Common traps: Preventing unauthorized entry does not justify permanently blocking an emergency exit.
Concentrating normal entrances simplifies control, but safe and lawful emergency exits must remain available; ingress and egress present different risks.
Design reception, meeting, and delivery areas so visitors do not need to pass through highly sensitive workspaces, reducing escort and tailgating exposure.
Loading docks connect the external supply chain to the facility and should be separated from high-security areas while controlling vehicles, goods, people, and temporary storage.
Vehicles can support surveillance, concealment, or explosive threats; depending on risk, use distance, lighting, patrols, bollards, and visitor-vehicle controls.
Critical computer rooms should avoid locations exposed to flooding, exterior-wall impact, roof leaks, public corridors, or other hazards and should account for structural load and cooling.
Wiring closets and intermediate distribution facilities should be in controlled areas, restrict physical access, and avoid co-location with water pipes or public-space hazards.
Backup and sensitive-media storage should match classification, temperature or humidity, fire, water, and access requirements and should not share the same disaster domain as primary production.
Evidence storage should support restricted access, tamper protection, environmental controls, and auditable custody; investigation procedures and chain of custody primarily belong to Domain 7.
In the 3.8 facility-design context, highly sensitive work areas should limit sight lines, photography, removable media, visitors, and unauthorized devices through spatial zoning and controlled personnel flow.
Distinctions: 3.8 facility-design principle vs 3.9 operational/physical control implementation
Facilities should allow critical functions to continue or degrade in an orderly way through localized equipment, power, cooling, or access failures and should provide viable recovery paths.
Use boundaries, access controls, locks, personnel, surveillance, environmental controls, and power protections to safeguard people, facilities, equipment, and media as part of an integrated emergency-response system.
Fences mark boundaries, deter, and delay intruders. Height, construction, lighting, and monitoring should match the threat; a fence alone does not provide complete detection and response.
Limit vehicle and pedestrian entrances, verify authorization, and monitor them. Automated gates must address tailgating, forced entry, and emergency release.
Bollards use standoff distance and impact-resistant barriers to reduce vehicle-ramming risk to buildings, entrances, and critical equipment.
Appropriate lighting improves human and camera visibility and deters intrusion, while excessive brightness, glare, and shadows can reduce visibility.
CCTV primarily supports detection, investigation, and deterrence. It requires suitable viewpoints, lighting, retention, time synchronization, and access protection and does not replace physical barriers.
Security guards can judge abnormal situations, respond to incidents, and adapt to complexity, but introduce training, cost, fatigue, and social-engineering risks.
Automated controls are consistent and scalable, while people provide judgment and adaptability. High-risk environments usually benefit from complementary use rather than replacing one with the other.
Mechanical, electronic, combination, and smart locks provide different manageability and resistance to attack; consider duplication, auditability, power failure, and emergency egress.
Electronic access control can use badges, smart cards, biometrics, and related mechanisms to verify entry rights and centrally revoke or log access; identity lifecycle management primarily belongs to Domain 5.
A mantrap or access vestibule uses interlocked doors to limit the number of people entering at once and reduce tailgating, while still meeting fire, accessibility, and life-safety requirements.
Tailgating occurs when an unauthorized person follows an authorized person into a controlled area; training, vestibules, guards, and anti-tailgating sensors can reduce the risk.
Some texts use piggybacking when an authorized person knowingly helps another person enter and tailgating when the authorized person is unaware. Usage varies; the exam focus is unauthorized co-entry.
Visitor management verifies identity and purpose, issues time-limited credentials, provides escorts when needed, and recovers badges so visitor activity stays within approved scope.
Visible badges help personnel recognize authorized users and visitors, but badges can be borrowed or forged and should be combined with identity verification and security culture.
Physical access logs for critical areas support investigation and anomaly detection and should be time-synchronized, integrity-protected, and retained according to policy.
Wiring closets contain network aggregation and patching points; restrict access, lock them, protect the environment, and maintain inventory to prevent unauthorized connections, interception, or outages.
Intermediate Distribution Facilities and similar network distribution points should be protected as critical network infrastructure, including power, cooling, fire, and unauthorized-connectivity risks.
Server rooms require strong physical access control, environmental monitoring, redundant power and cooling, fire protection, and visitor controls and should be separated from ordinary office areas.
Large data centers protect compute and storage assets with multiple physical zones, strict change control, redundant infrastructure, monitoring, and personnel procedures.
Highly sensitive equipment can use locked racks, asset labels, and port controls as an inner physical layer, while still allowing proper cooling, emergency response, and maintenance.
Sensitive media should be stored in restricted, fire- and water-protected, environmentally suitable areas with records for checkout, transport, return, and destruction.
Offsite backup storage reduces correlation with a primary-site disaster but must be sufficiently separated, reachable within recovery objectives, and compliant with classification and transport security.
Evidence storage should restrict access, prevent tampering, record custody, and maintain suitable environmental conditions; unauthorized contact can undermine evidentiary reliability.
In the 3.9 facility-control context, restricted work areas implement the 3.8 design objective through access control, visitor restrictions, device limitations, monitoring, and handling rules.
Distinctions: 3.9 operational/physical control implementation vs 3.8 facility-design principle
Sensitive paper, media, and devices should be put away or locked when unattended to reduce casual observation, theft, and improper disposal.
Temperature, humidity, airflow, and cooling capacity directly affect equipment availability; critical facilities should monitor these conditions and provide redundancy and failover.
Overheating shortens equipment life and can cause outages, while low temperature or rapid changes can create condensation and other problems; monitoring targets should follow equipment specifications.
Low humidity increases static-electricity risk and high humidity increases condensation and corrosion; use equipment or facility standards rather than memorizing one universal percentage.
Electrostatic discharge can damage electronics; grounding, antistatic materials, humidity management, and maintenance procedures reduce the risk.
Computer rooms should account for water threats from roofs, plumbing, cooling, and fire systems and use sensors, drainage, and equipment placement to reduce damage.
Unnecessary water pipes above or near critical computing equipment increase leak risk; when unavoidable, use detection, isolation, and drainage measures.
Continuously monitor temperature, humidity, smoke, water, airflow, power, and door status with defined alert and response thresholds.
Reduce combustible material, maintain electrical systems, separate fire zones, and control heat sources to reduce fire likelihood; prevention is preferable to relying only on suppression.
Smoke, heat, and flame detectors have different detection speeds and false-alarm characteristics and should be combined according to space, equipment, and personnel risk.
Smoke detectors often detect combustion particles before major heat rise and support early warning, although dust, airflow, and environmental conditions can affect false alarms.
Heat detectors respond to a fixed temperature or rate of rise and are generally slower than smoke detectors but can be preferable in environments where smoke or steam is common.
Flame detectors use optical characteristics such as UV or IR to detect flames quickly but require line of sight and an appropriate environment.
Choose fire-suppression methods based on fire type, equipment damage, personnel safety, and reignition risk rather than protecting hardware at the expense of life safety.
Fire-class naming varies by jurisdiction. Common North American CISSP context uses Class A ordinary combustibles, B flammable liquids, C energized electrical equipment, D combustible metals, and K cooking oils or fats.
Common traps: Do not assume one jurisdiction's fire-class labels are globally identical legal classifications.
Water-based suppression is effective and economical for many ordinary combustibles. Data-center design must consider energized equipment, water damage, and sprinkler type; after de-energizing, water may still be an effective medium.
Wet-pipe sprinklers keep pipes filled with water and discharge immediately when a heat-activated head opens. They are simple and reliable but have a higher accidental-water-release exposure.
Dry-pipe systems keep pressurized air or gas in the pipes until a sprinkler opens, after which pressure drops and water enters; they suit freeze-prone areas but respond somewhat more slowly.
Preaction systems generally require detection to admit water to the piping and then heat activation of a sprinkler head to discharge, reducing accidental-release risk in high-value equipment environments.
Deluge systems use open nozzles and release water across a broad area when activated, making them suitable for rapidly spreading high-hazard fires rather than typical high-value electronics rooms.
Clean-agent systems use nonconductive, low-residue gases or chemicals suitable for electronic equipment, while still requiring attention to human exposure, enclosure integrity, and environmental rules.
CO2 can suppress fire effectively but displaces oxygen and poses serious life-safety risk, requiring strict interlocks, alarms, and evacuation controls.
Portable extinguishers must match the fire class and be used by trained people; an incorrect extinguishing medium can worsen hazards or damage equipment.
Emergency Power Off allows rapid shutdown during fire, electrical, or life-safety events, but accidental activation can cause major availability impact and therefore requires protection and clear identification.
Critical equipment needs not only continuous power but also protection against abnormal voltage, frequency, surges, noise, and transient conditions.
A blackout is a complete loss of utility power, requiring UPS power for short-term bridging and generators or another source for longer outages.
A brownout is an extended period of below-normal voltage that can destabilize or damage equipment; it is similar to a voltage sag but generally lasts longer.
A voltage sag is a short-duration voltage drop that can cause reboots or errors; UPS systems, voltage regulation, and power design mitigate it.
A power surge is a comparatively sustained rise in voltage that can damage equipment and requires surge protection and power conditioning.
A power spike is a very short high-voltage transient, often caused by lightning or switching events, that can damage electronics.
Electrical noise or electromagnetic interference can disrupt sensitive equipment and communications; grounding, filtering, shielding, and power conditioning reduce it.
A UPS immediately provides short-term power during utility failure and can improve some power-quality problems; it commonly bridges the load to a generator or controlled shutdown.
Common traps: A UPS is designed for short-term bridging and power conditioning, not indefinite power supply.
Distinctions: UPS vs generator
An online UPS continuously powers the load through an inverter while utility power feeds the battery or DC system, providing strong conditioning at greater cost and efficiency tradeoffs.
A standby UPS normally powers the load directly from utility power and switches to battery or inverter during failure, costing less but introducing transfer time and less continuous conditioning.
Generators provide longer-duration backup power but require fuel, maintenance, startup time, ventilation, and periodic load testing; they normally do not replace the instantaneous bridging function of a UPS.
An Automatic Transfer Switch moves loads from a failed primary power source to backup power and is a critical component of generator and redundant-power architectures.
Power feeds from independent distribution paths or supply sources reduce single-path failure, but verify true physical independence so a shared transformer or upstream circuit does not remain a hidden single point.
Rack PDUs distribute power and may provide monitoring and redundant inputs; misconfiguration or overload can create a local single point of failure.
Proper grounding reduces electric shock, static, and electrical-noise risk and is fundamental to equipment and personnel safety.
Electromagnetic shielding uses conductive materials, grounding, and spatial design to reduce electromagnetic leakage or external interference in high-sensitivity or high-interference environments.
A Faraday cage is a conductive enclosure that attenuates electromagnetic fields to reduce signal leakage or interference; openings, seams, and grounding affect performance.
TEMPEST is a high-assurance concept related to unintended electromagnetic emanations from electronic equipment and their control, primarily relevant to highly sensitive government contexts rather than a universal enterprise requirement.
Critical computer-room cooling and environmental systems require redundancy, adequate capacity, and maintenance bypasses so one HVAC failure does not defeat otherwise redundant IT.
Identify and protect the entrances, controls, redundancy, and maintenance paths for power, water, fuel, communications, cooling, and other facility utilities so one utility failure cannot defeat IT redundancy.
Facility controls should use monitoring, isolation, redundancy, response, and recovery measures for natural and human-made environmental threats while incorporating life safety and business continuity.
Security architecture and engineering requirements must be managed continuously from requirements, design, implementation, integration, verification, and deployment through operations and retirement rather than as a one-time activity.
Each lifecycle phase should have clear responsibilities, entry and exit criteria, risk decisions, and evidence so security issues can be resolved and tracked at the most appropriate stage.
Collect business, user, operations, security, privacy, compliance, and maintenance needs and understand the mission and constraints before defining the system solution.
Security architecture must support the business mission. If a control undermines a critical mission, redesign the solution rather than assuming security objectives always override every business need.
Identify business owners, users, operations, security, privacy, legal, suppliers, auditors, and other stakeholders so important requirements do not appear only late in design.
Translate stakeholder needs into clear, verifiable, prioritized, non-conflicting system and security requirements and identify dependencies and assumptions.
Define the business and security functions the system must provide, such as identity, isolation, logging, encryption, and recovery.
Define quality attributes such as performance, availability, resilience, privacy, auditability, maintainability, and security assurance; these often shape the architecture rather than a single feature.
In the 3.10 lifecycle context, trace each security requirement from its source through architecture, implementation, integration, verification, deployment, and operational evidence so change impact and final acceptance can be systematically verified.
Distinctions: 3.10 end-to-end lifecycle traceability vs 3.3 control-selection traceability
When cost, performance, schedule, life safety, and security conflict, appropriate business and risk owners should decide based on mission priorities.
Map requirements to system boundaries, components, data flows, trust domains, interfaces, controls, and failure strategies and document key architectural decisions.
Architecture Decision Records capture important design choices, alternatives, assumptions, and risks so future changes, audits, and failure analysis can understand design intent.
Before implementation, review threat models, trust boundaries, dependencies, privileges, data flows, and failure modes to find systemic issues at lower cost.
Update threat models as architecture, data flows, suppliers, identities, and threats change so the model remains a living engineering artifact rather than a project-start document.
Implement the system according to approved architecture and security requirements using secure configuration, controlled code and components, and repeatable builds; detailed software development belongs primarily to Domain 8.
Retain build, configuration, signature, component-version, and change evidence so the final system can demonstrate alignment with approved design and requirements.
Establish baselines, versioning, and change control for architecture, code, infrastructure, firmware, and security settings across the lifecycle to prevent unauthorized drift.
When integrating components, reassess interfaces, identities, privileges, protocols, data formats, and failure propagation because individually secure components can create new risks when combined.
Integration security testing validates component interactions, error handling, trust boundaries, and end-to-end security requirements, focusing on interface problems that unit tests cannot expose.
Third-party hardware, software, cloud services, and libraries introduce new trust and lifecycle dependencies at integration; verify provenance, support, and security requirements.
Verification confirms whether a system or component was built correctly according to specified requirements and design—“build the product right.”
Common traps: Verification and validation are not synonyms.
Distinctions: verification vs validation
Validation confirms whether the final system actually meets user, mission, and business needs—“build the right product.”
Common traps: Passing specification tests alone does not prove the system meets real business and mission needs.
Distinctions: validation vs verification
Verification focuses on conformance to specification and design; validation focuses on whether the system meets its intended use. Both are necessary and neither substitutes for the other.
Domain 3 defines when lifecycle verification and validation are needed; detailed vulnerability assessment, penetration testing, control testing, and audit methods primarily belong to Domain 6.
Before deployment, define required security requirements, residual-risk conditions, exceptions, and test evidence so release decisions follow acceptance criteria rather than project pressure.
When moving a validated system into its target environment, protect configuration, data, identities, keys, and the change process and prepare rollback and support.
Production deployment should remove development and debug functions, default accounts, test data, and temporary privileges and confirm the production security baseline.
During migration, protect source, temporary, and target environments, verify integrity, and remove obsolete copies and access after completion.
Major deployments should have a tested rollback path, but old versions may contain security flaws, so rollback itself must be controlled by risk and version management.
During operations and sustainment, continue patching, configuration management, monitoring, capacity management, key and certificate management, and support and reassess system changes.
Feed incidents, metrics, vulnerabilities, and performance data back into risk and architecture decisions and adjust controls or design when needed rather than treating them only as operational alerts.
Patches and upgrades change code, dependencies, and risk and therefore require testing, change control, deployment, and verification rather than being treated as purely operational actions.
Business growth, data volume, and threats change capacity and failure assumptions; continuously validate redundancy, performance, and recovery capability.
Temporary workarounds, legacy dependencies, and delayed fixes create technical and security debt. Record, quantify, and plan their removal rather than allowing them to become permanent implicit architecture.
Major changes to architecture, suppliers, data, identities, or functionality should trigger impact analysis of threat models, controls, and compliance scope.
At end of life, stop services, revoke identities and keys, migrate or retain required data, update inventory, and securely dispose of assets.
Formal decommissioning includes dependency confirmation, access revocation, data disposition, certificate and key revocation, network cleanup, record updates, and final verification—not merely powering off a system.
During retirement, use retention, legal-hold, and classification requirements to decide whether data is migrated, archived, or destroyed; media-sanitization methods primarily belong to Domain 2.
Revoke service accounts, API tokens, certificates, and keys that are no longer needed so identities associated with retired systems do not remain valid.
Update CMDB or inventory and ownership records and confirm that physical, cloud, and SaaS resources are actually removed or transferred to avoid orphaned assets.
Retain necessary configuration, logs, contracts, and disposal evidence according to legal, audit, and operational needs rather than deleting all historical evidence when a system is retired.
Feed incidents, architectural defects, supplier issues, and retirement lessons into requirements, standards, and reference architectures for future systems.
The Domain 3 system lifecycle covers hardware, cloud, integration, operations, and retirement; Domain 8 focuses more specifically on software-development ecosystems, code, and SDLC security. They overlap but are not equivalent.
Changing a foundation model, supplier, tool permissions, retrieval sources, or inference architecture can alter trust boundaries and attack surface and should trigger renewed threat modeling and security validation.
Before deploying an AI service, verify data boundaries, model or provider responsibilities, input and output controls, authorization for privileged tools, logging, and degradation strategies—not just model accuracy.
When retiring GPUs, accelerators, and model-serving infrastructure, address device memory and local caches, keys, model artifacts, firmware, and inventory to prevent residual data or orphaned resources.