CISSP Secure Design Principles: Security Models, TPM, and HSM

Introduction

Secure design principles turn CISSP security requirements into access rules, trustworthy architectures, and platform controls. This lesson opens Domain 3, Security Architecture and Engineering (13% of the exam, ISC2 exam outline effective 15 April 2024). It covers the first tasks of the domain: researching, implementing, and managing engineering processes using secure design principles (3.1), understanding the fundamental concepts of security models (3.2), selecting controls based on system security requirements (3.3), and understanding the security capabilities of information systems (3.4).

Think of this domain as the "why behind the controls." Earlier lessons showed you how to manage risk; here you learn the design rules that stop risks from being built into systems in the first place. The exam asks you to recognize a principle in a scenario ("which principle is violated?"), name the model that explains a rule ("which model prevents reading up?"), and choose a control that matches a requirement ("which hardware feature protects keys?"). Memorizing definitions is not enough; you need to apply them.

Learning objectives

After this lesson you can:

1. Apply secure design principles: threat modeling, least privilege, defense in depth, secure defaults, fail securely, separation of duties, keep it simple, zero trust, privacy by design, trust but verify, and shared responsibility.
2. Explain secure access service edge (SASE) and where it fits.
3. Describe and distinguish the Bell-LaPadula, Biba, Clark-Wilson, Brewer-Nash, Take-Grant, and Graham-Denning models plus state machine and noninterference concepts.
4. Select controls from system requirements, using common evaluation ideas such as assurance and certification versus accreditation.
5. Explain trusted platform modules (TPM), hardware security modules (HSM), memory protection, secure boot, and encryption capabilities.
6. Decide when to use secure defaults, fail-secure versus fail-safe behavior, and simple designs.
7. Explain how shared responsibility affects design in cloud and outsourced systems.

1. Secure design principles

A principle is a rule of thumb that guides many specific decisions. Know each one well enough to spot when a scenario violates it.

1.1 Threat modeling

Design should start by asking "what can go wrong?" Use threat modeling with STRIDE and PASTA to identify problems before deployment, when changes can be easier to incorporate. Output: a list of threats, trust boundaries, and required mitigations that feed the requirements.

1.2 Least privilege

Every subject (user, process, service) receives only the access needed for its task, for the shortest time needed. Related ideas: need to know (information access), just-in-time privileges, and separation of administrative from daily accounts.

1.3 Defense in depth (layering)

Use multiple, independent, different controls so that a single failure does not cause a breach. Layers should cover people, process, and technology and span physical, network, host, application, and data levels. Two firewalls of the same brand with the same misconfiguration are not independent.

1.4 Secure defaults (secure by default)

The system ships in its most secure reasonable configuration: unnecessary services off, default passwords forced to change, encryption on, deny by default. A user must make a deliberate choice to reduce security.

1.5 Fail securely

When a component fails, it should not expose assets. Two related ideas:

Human safety takes priority. For doors, assess ingress and egress separately: free emergency exit can coexist with a locked entrance. For industrial systems, opening a valve is not automatically safe. Choose the failure state from safety requirements and the scenario, rather than equating fail-safe with fail-open everywhere.

1.6 Separation of duties and dual control

No single person can complete a critical process alone (for example, one person requests a payment and another approves it). Dual control (two people act together) and split knowledge (each holds part of a secret) are close relatives. Separation of duties reduces fraud and error, and works with job rotation and mandatory vacations (Domain 7).

1.7 Keep it simple (economy of mechanism)

Complex systems hide bugs. Prefer small, understandable components, minimal code, and few special cases. Reduce the attack surface by removing what is not needed.

1.8 Zero trust

"Never trust, always verify." No implicit trust based on network location. Access decisions authenticate and authorize the subject and device using identity, device health, and context, and access is limited to the resource, not the network. Core components include a policy decision point that evaluates requests and a policy enforcement point that applies the decision (see Domain 5). Zero trust assumes breach, so it favors micro-segmentation, strong identity, ongoing policy evaluation, and logging. This does not require an interactive login on every operation: sessions and cached decisions must have appropriate validity, revocation, and reevaluation controls.

1.9 Privacy by design

Build privacy into systems from the start: data minimization, purpose limitation, default privacy settings, pseudonymization, user transparency and control, and retention limits. It is proactive (not remedial) and privacy is the default.

1.10 Trust but verify

Even trusted components, vendors, and administrators are monitored and audited: logs, reviews, independent testing, and assurance evidence. Zero trust takes this further by removing implicit trust.

1.11 Shared responsibility

In cloud and outsourced services, security duties are divided between provider and customer. The split changes with the model:

Under every model the customer remains accountable for its data and for identity and access. An open storage bucket or overprivileged role illustrates a customer configuration duty; confirm the actual service and contract rather than assuming every service fits one table row.

1.12 Other well-known principles

• Open design: the security of a system should not depend on keeping the design secret (Kerckhoffs's principle for cryptography: security depends on key secrecy rather than algorithm secrecy). Design secrecy alone is insufficient assurance; protecting keys and other operational secrets still matters.
• Complete mediation: access must pass the applicable policy checks. A cache must preserve policy validity and revocation requirements rather than bypass enforcement.
• Least common mechanism: limit shared mechanisms between users to reduce unintended channels.
• Psychological acceptability: controls must be usable, or people work around them.
• Resilience and recoverability: design for failure, with redundancy and tested recovery.

1.13 SASE

Secure Access Service Edge (SASE) converges network and security services delivered from the cloud close to users: software-defined WAN (SD-WAN), secure web gateway, CASB, zero trust network access (ZTNA), and firewall-as-a-service. It fits distributed workforces and cloud-first companies, where traffic should not be hairpinned through a central data center. Identity and context drive policy at the "edge" instead of a fixed perimeter. SASE is an architectural pattern; its name does not guarantee a complete or correctly configured security implementation.

Worked example 1: naming the violated principle.

Scenario. A payroll application lets the same clerk create a new employee, set the pay rate, and approve the first payment. Auditors also find that, when the authorization service times out, the application skips the check and proceeds "so payroll is not delayed."

Reasoning.

1. One person controls the whole transaction: separation of duties is violated.
2. Skipping the check on failure: the application fails open, violating fail-secure and complete mediation.
3. The design should require a second approver, deny when authorization cannot be confirmed, and log the event.

Solution. Separation of duties and fail-secure design are violated; fix with split roles and a deny-on-error policy.

Why other labels are weaker. Least privilege is also implicated (the clerk has too much), but the question's central issue is the combination of one person doing incompatible steps; "defense in depth" does not describe a missing check. Watch for the most specific principle.

2. Security models

A security model is a formal or semi-formal description of rules that enforce a security goal. The exam asks which model enforces which property, and which "direction" it blocks.

2.1 Confidentiality models

State machine model. If the initial state satisfies the policy and every permitted transition preserves it, the modeled system remains secure. This is a conditional assurance argument, not a guarantee about every implementation. Many models build on this idea.

Bell-LaPadula (BLP). Focus: confidentiality in classified environments.

• Simple Security Property: no read up. A subject cannot read objects at a higher level.
• *-Property (star): no write down. A subject cannot write to a lower level (prevents leaking secrets downward).
• Strict star variant (terminology varies): restricts writes to the subject's current level rather than allowing write-up; always read the variant specified in the question.
• Discretionary security property: an access matrix supports need to know within levels.

Memory aid: "no read up, no write down." Compare the subject's current operating label, not just maximum clearance; compartments and discretionary permissions can further restrict access.

Brewer-Nash (Chinese Wall). Prevents conflicts of interest. Access depends on what the subject has already accessed: once a consultant has seen Company A's confidential data, access to a competing company in the same conflict-of-interest class is restricted. Public or properly sanitized information is treated separately. Dynamic and based on history.

2.2 Integrity models

Biba (strict integrity policy). Uses integrity ratings to prevent contamination; these are separate from confidentiality classifications:

• Simple integrity axiom: no read down (do not consume lower-integrity data).
• *-integrity axiom: no write up (low-integrity subjects cannot corrupt high-integrity objects).

Memory aid: "no read down, no write up."

Clark-Wilson. Focus on integrity in commercial systems. It enforces well-formed transactions through a controlled interface: users cannot modify protected data (constrained data items, CDIs) directly; they use transformation procedures (TPs) that keep it consistent, and integrity verification procedures (IVPs) check it. It enforces separation of duties and the access triple (subject, program, object). It is the model most associated with applications such as banking.

2.3 Other models

2.4 Comparing the big three

Worked example 2: apply the model.

Scenario. A defense system labels documents Unclassified (U), Secret (S), and Top Secret (TS). Assume a subject currently operating at Secret, the simple hierarchy U < S < TS, no compartments, and otherwise permitted discretionary access. It tries to (a) read a TS document, (b) write a note into a U document, (c) read a U document, (d) write into a TS document.

Reasoning with Bell-LaPadula.

1. (a) reading up is denied (simple security property).
2. (b) writing down to U is denied (star property): it could leak Secret information into a less protected container.
3. (c) reading down is allowed.
4. (d) writing up is allowed by basic BLP (though the subject cannot read the result), and the strict star variant described above would restrict writing to the same level only.

Solution. Denied: (a) and (b); allowed: (c) and (d).

Now use separate integrity labels. In a strict Biba example with Low < Medium < High integrity, a Medium-integrity process cannot read Low-integrity input or write High-integrity records. Do not substitute national-security classification labels for integrity ratings. A system can enforce both confidentiality and integrity policies, although the combined permitted flows may be restrictive.

Exam tip: read the question for the goal. "Prevent leakage of classified information" is Bell-LaPadula. "Prevent unauthorized modification" is Biba or Clark-Wilson. "Prevent consultants from serving competitors" is Brewer-Nash.

3. Selecting controls from system requirements

Controls should come from requirements, which come from risk assessment, classification, and legal obligations. A usual path:

1. Define requirements (confidentiality, integrity, availability, privacy, compliance, performance).
2. Categorize the system by the impact of loss (for example low, moderate, high per FIPS 199).
3. Select a baseline of controls (NIST SP 800-53, ISO/IEC 27002, CIS Controls).
4. Tailor the baseline, including scoping, as explained in data lifecycle controls and baseline tailoring.
5. Implement, then assess that controls work and are operating as intended.
6. Authorize operation by an accountable official based on residual risk, and monitor continuously.

Control types by function: preventive, detective, corrective, deterrent, recovery, compensating, and directive. By implementation: administrative, technical (logical), physical.

3.1 Assurance, evaluation, and accreditation

• Assurance is confidence that controls work as intended. Higher-risk systems need more rigorous evidence.
• Common Criteria (ISO/IEC 15408) is an international evaluation standard. Evaluation covers the identified target of evaluation and its security target, with applicable protection profile conformance claims. An EAL1 to EAL7 is one kind of assurance package; not every certification uses an EAL. Compare evaluated requirements, scope, configuration, and assurance evidence, rather than treating an EAL as a general security ranking.
• In historical system certification-and-accreditation terminology, certification is technical evaluation and accreditation is management risk acceptance. Current NIST RMF uses assessment and authorization; other certification schemes use their own meanings.
• FIPS 140-3 provides security requirements for cryptographic modules (levels 1 to 4). A CMVP validation applies to the specified module, version, environment, and approved operation, not automatically the whole application.

Worked example 3: derive the control from the requirement.

Scenario. A clinic plans an online portal where patients view lab results. Requirements: only the patient and explicitly authorized clinical staff can see the patient's results (confidentiality), results cannot be altered without detection (integrity), the portal must work during business hours with 99.5% availability, and the clinic must prove who viewed what (accountability).

Reasoning.

1. Confidentiality: strong patient authentication plus record-level authorization, TLS in transit, encryption at rest, and least-privilege roles for staff. MFA alone does not enforce who owns a result.
2. Integrity: digital signatures or MACs with protected keys on result records, change logging, write access restricted to the lab system (Clark-Wilson style well-formed transactions).
3. Availability: redundant servers, tested backups, DDoS protection, monitored capacity.
4. Accountability: unique IDs, tamper-resistant audit logs with time synchronization, log review.
5. Select a baseline for health information systems, tailor it, test it, and obtain authorization from the business owner.

Solution. A layered set of preventive, detective, and recovery controls traced to each requirement, not a generic list.

Why not simply "buy a firewall"? A single control addresses one requirement at one layer, violating defense in depth and leaving integrity and accountability uncovered.

4. Security capabilities of information systems

Hardware and operating system features give software a trustworthy foundation.

4.1 Memory protection

Operating systems isolate processes so one cannot read or overwrite another's memory.

• Process isolation and virtual memory with separate address spaces.
• Hardware segmentation and protection rings (kernel in the innermost, most privileged ring; applications outside).
• ASLR (address space layout randomization) makes memory addresses unpredictable.
• DEP / NX (data execution prevention) marks selected pages non-executable, reducing code-injection opportunities; it does not stop every exploit.
• Stack protections such as canaries; memory-safe languages reduce memory-error classes, while unsafe code, foreign-function interfaces, and logic flaws still need review.

4.2 Trusted Platform Module (TPM)

A TPM is a tamper-resistant chip (or firmware equivalent) on a device that provides:

• Protected generation and use of keys, including non-exportable private keys; key attributes and policies determine permitted duplication or migration. Sealed data can be released for host use.
• Measured boot / remote attestation: measurements extend cumulative digests in platform configuration registers (PCRs), accompanied by an event log. A verifier evaluates attested evidence against its policy; this does not prove the device is free of malware.
• Sealing: protected material can be unsealed when its authorization policy is satisfied, potentially including approved PCR values. Plan legitimate update and recovery workflows rather than assuming every changed measurement is an attack.

A TPM typically anchors trust for a device. An HSM is commonly selected for dedicated cryptographic services; exact capabilities depend on the implementation.

4.3 Hardware security module (HSM)

An HSM is a dedicated, tamper-resistant appliance or cloud service that generates, stores, and uses keys and performs cryptographic operations at high speed for many applications. Typical uses: certificate authorities' private keys, payment processing, code signing, database key management. Often validated to FIPS 140.

4.4 Secure boot and trusted execution

• Secure boot (UEFI) checks signatures and trust/revocation policy for boot components; operating-system mechanisms can extend the chain. It reduces boot-level malware risk rather than guaranteeing protection from every rootkit.
• Trusted execution environments / secure enclaves can isolate selected code and data from a more privileged host, protecting data in use within the implementation's threat model. Side channels, I/O, and application vulnerabilities still need evaluation.
• Hypervisor-based isolation separates workloads and can protect the kernel.

4.5 Encryption capabilities

• Full-disk and file-level encryption (data at rest).
• Self-encrypting drives (hardware encryption with an authentication key).
• Transport encryption (TLS, IPsec) and application-layer encryption.
• Key management: generation, distribution, rotation, storage, escrow, revocation, destruction.

Encryption provides confidentiality but does not provide integrity or authenticity by itself without an appropriate MAC, digital signature, or authenticated encryption mode. A plain hash stored beside attacker-modifiable data does not authenticate it.

4.6 Other capabilities

• Reference monitor and security kernel: the reference monitor concept mediates all access; the security kernel is the implementation. The ideal is tamper resistance, complete mediation, and verifiability; actual implementations require assurance evidence.
• Trusted computing base (TCB): all hardware, firmware, and software that enforce security policy. A smaller TCB is easier to verify.
• Virtualization and containers for isolation; sandboxing for untrusted code.
• Fault tolerance and redundancy (RAID, clustering) for availability.
• Logging and time synchronization for accountability.

5. Putting the principles to work: a design review

When reviewing a design, ask in order:

1. What are we protecting, and what is its classification? (Lessons 5 and 6)
2. What are the threats and trust boundaries? (Threat model)
3. Which principles are met or violated? Least privilege, defense in depth, secure defaults, fail secure, separation of duties, simplicity, zero trust, privacy.
4. Which model explains the access rules (confidentiality, integrity, or conflict of interest)?
5. Do the chosen controls trace to requirements, with assurance proportional to risk?
6. Who is responsible under the shared responsibility model, and is that documented in the contract?

6. Mini case study

Situation. Northwind Bank is building a mobile loan application. Requirements gathered by the architect: loan officers must not approve loans they originated; credit scores come from an external vendor; customers' identity documents are stored in a cloud object store; the app runs on containers in a managed cloud platform; staff reach internal tools through a flat VPN that gives full network access once connected. A developer proposes disabling certificate validation on the vendor integration "temporarily" because test certificates keep expiring. Another suggests using a team-wide admin account for the deployment pipeline.

Questions.

1. Which design principles are violated?
2. Which security model best expresses the loan approval rule, and why?
3. What should the bank change about the VPN and the storage?

Commented solution.

1. Disabling certificate validation breaks complete mediation, secure defaults, and defense in depth (it removes authentication of the vendor and exposes data to man-in-the-middle attacks); a shared admin account breaks least privilege and accountability; the flat VPN violates zero trust and least privilege (network access equals trust). Cloud storage of identity documents requires customer-side configuration under the shared responsibility model.
2. Clark-Wilson, because it models commercial integrity via well-formed transactions and separation of duties: the originator creates the loan through a controlled procedure, and a different person approves it. Bell-LaPadula concerns confidentiality levels, not business process integrity.
3. Replace the flat VPN with zero trust network access: per-application access based on identity and device posture, MFA, and micro-segmentation. Encrypt the object store using a key-management design matched to requirements; use customer-managed or HSM-backed keys where the risk and control needs justify them. Also block public access, enforce least-privilege roles, log access, and apply retention. Fix the test certificate problem with an internal test CA rather than disabling validation.

7. Common pitfalls and exam tips

• Exam tip: BLP = confidentiality (no read up, no write down). Biba = integrity (no read down, no write up). Clark-Wilson = commercial integrity with well-formed transactions and separation of duties. Brewer-Nash = conflicts of interest.
• Exam tip: preserve safe egress, even if ingress stays locked; choose fail-safe behavior from the hazard analysis and fail-secure behavior from asset protection requirements.
• Pitfall: treating security by obscurity as a control. Open design says the system must stay secure even if the design is known.
• Pitfall: believing the cloud provider is responsible for everything. Data, identity, and configuration remain the customer's responsibility.
• Exam tip: TPM is per device (keys, attestation, sealing); HSM is a shared, high-performance key service.
• Pitfall: confusing a higher Common Criteria EAL with "more features." It signals more rigorous assurance.
• Exam tip: certification is technical evaluation; accreditation is management's risk acceptance.
• Pitfall: using the same type of control in every layer. Layers should be diverse and independent.
• Exam tip: choose the most specific principle that matches the scenario; zero trust, for example, applies when access depends on network location.
• Pitfall: assuming encryption alone provides integrity.

Key terms

• Least privilege / need to know: minimum access for the task / minimum information for the duty.
• Defense in depth: multiple, independent, diverse layers of control.
• Secure by default: most secure reasonable configuration out of the box.
• Fail-secure / fail-safe: protect assets on failure / reach the hazard-appropriate safe state.
• Separation of duties / dual control / split knowledge: no single person completes a critical process.
• Zero trust: no implicit trust; continuous verification.
• Privacy by design: privacy built in, proactive and default.
• SASE: cloud-delivered convergence of networking and security services.
• Bell-LaPadula / Biba / Clark-Wilson / Brewer-Nash: confidentiality / integrity / commercial integrity / conflict-of-interest models.
• TPM / HSM: per-device key chip with attestation / shared tamper-resistant cryptographic service.
• Reference monitor / TCB: mediator of all access / set of components enforcing policy.
• Common Criteria / EAL: evaluation against specified security claims / one family of assurance packages, levels 1 to 7.

Summary checklist

• I can name and apply the main secure design principles to a scenario.
• I can explain fail-secure versus fail-safe and when each applies.
• I can state the rules of Bell-LaPadula, Biba, Clark-Wilson, and Brewer-Nash.
• I can derive controls from system requirements and explain assurance, certification, and accreditation.
• I can distinguish TPM and HSM and describe secure boot, ASLR, DEP, and enclaves.
• I can describe the shared responsibility split in IaaS, PaaS, and SaaS.
• I can explain zero trust, privacy by design, and SASE.

Classification supplies the labels these models enforce; review asset classification and handling requirements when deriving access rules.

Official sources

• ISC2 CISSP exam outline: https://www.isc2.org/certifications/cissp/cissp-certification-exam-outline (opens in a new tab)

• NIST SP 800-160 Vol. 1 Rev. 1, Engineering Trustworthy Secure Systems: https://csrc.nist.gov/pubs/sp/800/160/v1/r1/final (opens in a new tab)

• NIST SP 800-207, Zero Trust Architecture: https://csrc.nist.gov/pubs/sp/800/207/final (opens in a new tab)

• NIST FIPS 199 and SP 800-53 Rev. 5: https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final (opens in a new tab)

• Common Criteria portal: https://www.commoncriteriaportal.org/ (opens in a new tab)

• Trusted Computing Group TPM resources: https://trustedcomputinggroup.org/resource/trusted-platform-module-tpm-summary/ (opens in a new tab)

• NISTIR 7316, Assessment of Access Control Systems: https://csrc.nist.gov/pubs/ir/7316/final (opens in a new tab)

• OSHA, Exit-route requirements (US example): https://www.osha.gov/laws-regs/regulations/standardnumber/1910/1910.36 (opens in a new tab)

• Common Criteria 2022 Part 5, Assurance packages: https://www.commoncriteriaportal.org/files/ccfiles/CC2022PART5R1.pdf (opens in a new tab)

• Microsoft, TPM fundamentals: https://learn.microsoft.com/en-us/windows/security/hardware-security/tpm/tpm-fundamentals (opens in a new tab)

• Microsoft, PCR banks: https://learn.microsoft.com/en-us/windows/security/hardware-security/tpm/switch-pcr-banks-on-tpm-2-0-devices (opens in a new tab)

• Microsoft, Secure boot process: https://learn.microsoft.com/en-us/windows/security/operating-system-security/system-security/secure-the-windows-10-boot-process (opens in a new tab)

• NIST, CMVP scope and validation: https://csrc.nist.gov/projects/cryptographic-module-validation-program/faqs (opens in a new tab)