Apply secure design, models, system controls, platform capabilities, vulnerability analysis, cryptography, physical security, and lifecycle engineering.
Research, implement, and manage least privilege, defense in depth, fail secure, separation, simplicity, trust-boundary, and resilience principles.
Understand formal confidentiality, integrity, information-flow, access, and trusted-computing models and their practical limits.
Select controls based on system requirements, threat, risk, assurance, lifecycle, environment, and business constraints.
Understand memory protection, hardware roots of trust, virtualization, isolation, encryption, and platform-security capabilities.
Assess client, server, database, cryptographic, ICS, cloud, distributed, IoT, embedded, mobile, and container design weaknesses.
Select algorithms, protocols, key management, certificates, PKI, cryptographic lifecycle, integrity, confidentiality, and nonrepudiation mechanisms.
Recognize implementation, key, protocol, side-channel, downgrade, collision, brute-force, and misuse attacks against cryptographic systems.
Apply secure facility location, construction, shared-fate, environmental, utility, surveillance, and layered-perimeter principles.
Design and assess deterrent, preventive, detective, corrective, recovery, safety, visitor, access, and environmental controls.
Integrate security requirements, architecture, acquisition, development, operation, maintenance, change, and disposal across the lifecycle.
Architecture converts security requirements into boundaries, components, interfaces, controls, assumptions, and evidence. Begin with assets, actors, trust boundaries, threats, failure modes, and lifecycle. Choose a principle or model because it constrains a real risk, not because its name appears in a glossary.
Prefer simple, layered designs that fail securely, minimize privilege, separate duties, reduce attack surface, isolate faults, and remain supportable. Security added after architecture usually becomes a compensating control around an unsafe boundary.
| Objectives | Decision focus |
|---|---|
| 3.1–3.3 Design principles, models, control selection | Apply least privilege, defense in depth, secure defaults, separation, formal models, threat, risk, assurance, and lifecycle constraints |
| 3.4–3.5 Platform capabilities and vulnerabilities | Evaluate hardware trust, memory, virtualization, isolation, cloud, distributed, ICS, IoT, mobile, container, client, server, and database risks |
| 3.6–3.7 Cryptography and attacks | Select mechanisms and key lifecycle for required properties; recognize implementation, protocol, key, side-channel, downgrade, and misuse failures |
| 3.8–3.9 Site and physical security | Layer location, perimeter, access, surveillance, utilities, environment, fire, safety, and recovery controls |
| 3.10 System lifecycle | Integrate requirements, acquisition, design, build, operation, change, maintenance, and disposal |
Least privilege grants only the access needed for an approved task and duration. Separation of duties divides incompatible authority. Defense in depth uses controls with independent failure modes. Complete mediation checks every access rather than trusting a stale decision. Fail secure moves to a protected state on failure. Economy of mechanism favors simpler designs that can be reviewed. Open design does not rely on secret architecture. Least common mechanism reduces shared components and unintended channels. Psychological acceptability makes secure behavior usable.
Apply zero trust as an architecture approach that removes implicit trust based solely on location and continually evaluates subjects, devices, resources, context, and policy. It does not mean one product or constant reauthentication. Resilience assumes components fail and designs containment, recovery, and adaptation.
Security models provide reasoning tools. Bell-LaPadula emphasizes confidentiality through information-flow rules. Biba emphasizes integrity. Clark-Wilson uses well-formed transactions, constrained data, and separation for commercial integrity. Brewer-Nash addresses conflicts of interest based on prior access. Lattice and mandatory models use labels and clearances; discretionary models leave control to owners; role, rule, attribute, and risk-based models express other authorization logic. Know the property and limitation, not only the slogan.
Select controls from requirement, threat, exposure, assurance, operational context, user impact, cost, and lifecycle. Preventive controls reduce occurrence; detective controls identify events; corrective and recovery controls restore; deterrent controls influence behavior; compensating controls provide alternative risk reduction when a primary control is infeasible. A control can have several classifications depending on purpose.
Assurance asks why the control or component should be trusted. Consider independent evaluation, development process, formal methods where justified, testing, provenance, secure configuration, maintenance, evidence, and known limitations. Certification of a component does not certify the whole system or its deployment.
Hardware roots of trust, secure boot, trusted execution, memory protection, virtualization, and isolation can strengthen boundaries when configured and verified. Firmware, management interfaces, shared hardware, side channels, speculative behavior, supply chain, and privileged hypervisors remain risks. Containers commonly share a kernel and should not be treated as equivalent to a separate physical host for every threat model.
Cloud shifts responsibility but retains customer decisions about identity, data, configuration, workload code, and many network controls. Distributed systems add partial failure, consistency, time, coordination, retry, and dependency risk. ICS and safety systems prioritize availability and human safety and may have long lifecycles and constrained patching. IoT and embedded systems often combine physical exposure, limited update, default credentials, and supply-chain risk. Mobile systems add device loss, hostile networks, app ecosystems, and privacy concerns.
Use threat modeling and abuse cases across clients, APIs, services, databases, queues, caches, administrative planes, CI/CD, and suppliers. Validate isolation and recovery, not only steady-state functionality.
Choose the property first. Symmetric encryption provides efficient confidentiality with shared-secret key distribution. Asymmetric cryptography supports key establishment, encryption in suitable designs, and digital signatures at greater computational cost. Hash functions support integrity constructions and identifiers but do not encrypt. Message authentication codes provide integrity and authenticity to parties sharing a secret; they do not provide public nonrepudiation. Digital signatures depend on private-key control, certificate or public-key trust, algorithm, validation, and process.
Use established algorithms and protocols. Do not design custom cryptography. Govern generation, entropy, distribution, storage, use, rotation, backup, recovery, revocation, destruction, and compromise. Public key infrastructure includes certificate authorities, registration, policies, validation, revocation information, roots, and private-key protection. Encrypting data without recoverable keys can destroy availability.
Attacks target more than algorithms: brute force, collisions, downgrade, padding oracles, protocol confusion, weak randomness, nonce reuse, key exposure, side channels, fault injection, implementation bugs, certificate validation failures, and operational misuse. Patch, configure, test, and monitor the complete cryptosystem.
Select site location with natural, political, utility, transport, supplier, crime, and shared-fate risks. Layer deterrent, preventive, detective, corrective, and recovery controls across perimeter, building, secure areas, equipment, media, and environmental systems. Consider power, cooling, water, fire detection and suppression, electromagnetic issues where relevant, visitor control, surveillance, alarms, guards, locks, and emergency access. Life safety comes before asset protection.
Integrate security through concept, requirements, architecture, acquisition, development, test, deployment, operation, maintenance, change, and disposal. Define acceptance criteria and residual risk before production. Track end-of-support components and secure data and key disposal.
A healthcare organization is designing a connected medical-device platform with hospital gateways, cloud services, mobile apps, and supplier firmware.
