Lesson Eight

Security Architecture Foundations and Protection Mechanisms

SierraTec Secure CISSP Certification Preparation Course

Lesson Overview

Security architecture determines how security is built into systems.

A security program may contain strong governance, careful risk management, accurate asset classification, and effective policies. However, if systems themselves are poorly designed, security becomes dependent on compensating controls, manual processes, and constant operational intervention.

Security architecture attempts to answer questions such as:

• Where should trust exist?

• Where should trust end?

• How should subjects interact with objects?

• How should privileged code be separated from ordinary applications?

• How should processes be isolated?

• How should memory be protected?

• How can a system verify that its boot environment has not been improperly modified?

• How should sensitive information be hidden from components that do not require it?

• What should happen when a system fails?

• Which functionality should be enabled by default?

• How many security layers should exist?

• Where should policy be enforced?

• Which hardware features can strengthen trust?

This lesson begins CISSP Domain 3 — Security Architecture and Engineering.

The current CISSP examination outline assigns 13% of the examination to this domain. Objective 3.1 includes secure-design principles such as threat modeling, least privilege, defense in depth, secure defaults, fail securely, segregation of duties, simplicity, Zero Trust, privacy by design, shared responsibility, and Secure Access Service Edge. Objective 3.3 requires candidates to select controls based on system-security requirements, while Objective 3.4 specifically identifies system-security capabilities such as memory protection, Trusted Platform Module, and encryption/decryption.

This lesson develops those objectives using the architectural concepts that make them understandable:

• abstraction;

• data hiding;

• encapsulation;

• isolation;

• security domains;

• security boundaries;

• reference monitors;

• security kernels;

• Trusted Computing Base;

• protection rings;

• memory protection;

• hardware roots of trust;

• TPM;

• secure boot;

• layered security.

The central Lesson Eight question is:

How should a system be designed so security is enforced by architecture rather than depending only on users, administrators, or individual security products?

CISSP Exam Objective Alignment

Learning Objectives

After completing this lesson, you should be able to:

1. Define security architecture.

2. Explain why security should be designed rather than added after deployment.

3. Distinguish architecture from implementation.

4. Explain protection mechanisms.

5. Define abstraction.

6. Explain how abstraction can reduce security complexity.

7. Define data hiding.

8. Distinguish data hiding from encryption.

9. Define encapsulation.

10. Explain how encapsulation supports controlled interaction.

11. Define isolation.

12. Explain process, memory, workload, and network isolation.

13. Define a security domain.

14. Define a security boundary.

15. Distinguish a security boundary from a network perimeter.

16. Explain a trust boundary.

17. Define the Trusted Computing Base.

18. Explain the reference-monitor concept.

19. Explain security-kernel concepts.

20. Explain protection rings.

21. Describe memory protection.

22. Explain user mode versus privileged mode conceptually.

23. Explain address-space separation.

24. Explain privilege separation.

25. Explain hardware roots of trust.

26. Explain Trusted Platform Module capabilities at a CISSP level.

27. Explain secure boot and measured boot conceptually.

28. Explain secure defaults.

29. Explain fail-secure behavior.

30. Explain simplicity as a secure-design principle.

31. Explain least privilege architecturally.

32. Explain segregation of duties architecturally.

33. Explain defense in depth as an architectural principle.

34. Explain Zero Trust as an architectural approach.

35. Explain privacy by design.

36. Explain shared responsibility.

37. Explain Secure Access Service Edge at a high level.

38. Select controls based on system-security requirements.

39. Analyze architectural trust relationships.

40. Apply protection mechanisms to CISSP-style scenarios.

Part I — Understanding Security Architecture

1. What Is Security Architecture?

Security architecture is the structured design of security principles, components, trust relationships, boundaries, controls, and mechanisms within an information system or enterprise environment.

Security architecture asks:

How should the system be structured so security objectives are consistently enforced?

It considers relationships among:

• hardware;

• firmware;

• operating systems;

• applications;

• networks;

• identities;

• data;

• security controls.

2. Architecture Versus Technology Product

A firewall is a technology.

A security architecture determines:

• where the firewall belongs;

• which traffic should cross it;

• which trust boundary it protects;

• how it interacts with identity;

• how failures are monitored;

• what other controls support it.

Likewise:

An encryption product is a control.

Architecture determines:

• which information needs encryption;

• where encryption occurs;

• who manages keys;

• where decryption is permitted.

3. Architecture Versus Implementation

Architecture

Defines:

• structure;

• trust;

• relationships;

• principles;

• boundaries.

Implementation

Builds or configures those architectural decisions.

Example:

Architectural Decision

Administrative workloads must be isolated from ordinary user workloads.

Implementation

Use:

• separate privileged workstations;

• network segmentation;

• dedicated administrative identities.

4. Security Architecture Flow

BUSINESS REQUIREMENTS

        │

        ▼

SECURITY REQUIREMENTS

        │

        ▼

SECURE DESIGN PRINCIPLES

        │

        ▼

SECURITY ARCHITECTURE

        │

        ▼

PROTECTION MECHANISMS

        │

        ▼

IMPLEMENTATION

        │

        ▼

TESTING & ASSURANCE

        │

        ▼

OPERATIONS

5. Why Architecture Matters

Poor architecture can produce:

• unnecessary trust;

• excessive privilege;

• flat networks;

• unrestricted data access;

• weak isolation;

• insecure defaults;

• single points of failure.

Strong architecture attempts to prevent these problems before they become operational vulnerabilities.

Part II — Protection Mechanisms

6. What Is a Protection Mechanism?

A protection mechanism is a technical or architectural method used to enforce security.

Examples include:

• access controls;

• isolation;

• memory protection;

• encryption;

• hardware roots of trust;

• process separation;

• security boundaries.

A protection mechanism answers:

How is the security requirement actually enforced?

7. Protection Mechanism Model

SECURITY REQUIREMENT

       │

       ▼

PROTECTION PRINCIPLE

       │

       ▼

PROTECTION MECHANISM

       │

       ▼

ENFORCEMENT

       │

       ▼

SECURITY OUTCOME

Example:

Requirement:

Prevent ordinary users from modifying the OS kernel



       ↓



Principle:

Least privilege / isolation



       ↓



Mechanism:

CPU privilege levels + memory protection

Part III — Abstraction

8. What Is Abstraction?

Abstraction hides unnecessary implementation complexity and presents a controlled interface to a resource.

Instead of allowing a subject to directly manipulate underlying components, the system provides an approved method of interaction.

9. Abstraction Example

A user does not directly manipulate:

• disk sectors;

• filesystem metadata;

• storage-controller instructions.

Instead, the operating system provides:

USER

  │

  ▼

APPLICATION

  │

  ▼

OPERATING SYSTEM API

  │

  ▼

FILESYSTEM

  │

  ▼

STORAGE DEVICE

Each layer abstracts the layer beneath it.

10. Security Benefit of Abstraction

Abstraction can:

• reduce direct access;

• simplify interfaces;

• centralize enforcement;

• limit unnecessary knowledge;

• reduce opportunities for misuse.

11. Database Abstraction Example

Poor design:

USER

  │

  ▼

DIRECT DATABASE ACCESS

Better architecture:

USER

  │

  ▼

APPLICATION

  │

  ▼

VALIDATED API

  │

  ▼

DATABASE

The user interacts with the abstraction rather than the underlying database directly.

12. CISSP Exam Focus

Abstraction does not automatically guarantee security.

It creates a layer through which security controls can be applied.

Part IV — Data Hiding

13. What Is Data Hiding?

Data hiding limits direct visibility or accessibility of internal data or implementation details.

The objective is:

Expose only what another component actually needs.

14. Data-Hiding Example

A software object may contain:

CustomerAccount



Internal:

- accountBalance

- fraudScore

- encryptionKeyReference



External Interface:

- getAvailableBalance()

- submitPayment()

External code does not need unrestricted access to internal fields.

15. Data Hiding Versus Encryption

These concepts are different.

16. CISSP Trap

Do not assume:

Data hiding = encryption.

Data may be hidden from an interface but remain stored in plaintext.

Part V — Encapsulation

17. What Is Encapsulation?

Encapsulation groups information and the operations permitted to manipulate it while restricting direct access to internal implementation.

Conceptually:

┌────────────────────────────┐

│       SECURITY OBJECT      │

│                            │

│   Private Data             │

│   Internal Logic           │

│                            │

│ ────────────────────────── │

│ Approved Interface         │

└─────────────┬──────────────┘

              │

              ▼

       EXTERNAL SUBJECT

18. Why Encapsulation Matters

Encapsulation can:

• reduce unauthorized manipulation;

• enforce approved interfaces;

• simplify security review;

• separate internal implementation from external behavior.

19. Abstraction, Data Hiding, and Encapsulation

They are related but not identical.

Part VI — Isolation

20. What Is Isolation?

Isolation separates components so compromise or failure of one component does not automatically affect another.

Isolation is fundamental to secure architecture.

21. Types of Isolation

Isolation may occur between:

• processes;

• users;

• virtual machines;

• containers;

• applications;

• networks;

• security domains;

• physical systems.

22. Process Isolation

Process isolation prevents one application process from freely reading or modifying another process's memory or resources.

PROCESS A

┌────────────┐

│ Memory A   │

└────────────┘



      ║



   ISOLATION



      ║



PROCESS B

┌────────────┐

│ Memory B   │

└────────────┘

23. Virtual Machine Isolation

┌────────────┐   ┌────────────┐

│    VM 1    │   │    VM 2    │

│ App + OS   │   │ App + OS   │

└─────┬──────┘   └─────┬──────┘

      │                │

      └───────┬────────┘

              ▼

          HYPERVISOR

              │

              ▼

           HARDWARE

The hypervisor helps isolate virtual machines.

If the isolation layer fails, multiple workloads may be affected.

24. Container Isolation

Containers typically share more of the underlying operating-system environment than separate virtual machines.

This can provide efficiency but means:

The isolation model is different from full VM separation.

Detailed container architecture will be covered later under Domain 3.5.

25. Network Isolation

Segmentation can isolate:

• departments;

• production;

• administration;

• sensitive workloads;

• guest devices.

Isolation can limit attack movement.

26. Security Benefit

Isolation limits:

• interference;

• unauthorized access;

• lateral movement;

• failure propagation.

Part VII — Security Domains

27. What Is a Security Domain?

A security domain is an environment containing resources governed by common:

• security policies;

• trust assumptions;

• control requirements;

• authorization rules.

Examples may include:

• classified environment;

• payment-card environment;

• privileged administration environment;

• production network.

28. Security Domain Model

┌──────────────────────────┐

│ SECURITY DOMAIN A        │

│                          │

│ Users                    │

│ Applications             │

│ Data                     │

│ Controls                 │

└────────────┬─────────────┘

             │

      CONTROLLED ACCESS

             │

             ▼

┌──────────────────────────┐

│ SECURITY DOMAIN B        │

│                          │

│ Different rules          │

│ Different trust          │

└──────────────────────────┘

Part VIII — Security Boundaries

29. What Is a Security Boundary?

A security boundary identifies where:

• security policy changes;

• trust assumptions change;

• authorization requirements change;

• protection requirements differ.

30. Security Boundary Diagram

        UNTRUSTED ENVIRONMENT

                 │

                 ▼

═════════════════════════════════

        SECURITY BOUNDARY

═════════════════════════════════

                 │

                 ▼

        CONTROLLED DOMAIN

                 │

                 ▼

═════════════════════════════════

      HIGH-TRUST BOUNDARY

═════════════════════════════════

                 │

                 ▼

        SENSITIVE RESOURCE

31. Boundary Controls

Crossing a security boundary may require:

• authentication;

• authorization;

• encryption;

• filtering;

• inspection;

• logging.

32. Security Boundary Is Not Always Physical

A boundary may exist:

• between processes;

• between applications;

• between cloud services;

• between privilege levels;

• inside one physical server.

33. Security Boundary Versus Network Perimeter

Modern architectures may contain many security boundaries inside the enterprise.

Part IX — Trust Boundaries

34. Trust Boundary

A trust boundary is a point where the degree or basis of trust changes.

Example:

INTERNET USER

     │

     ▼

══════════════════

 TRUST BOUNDARY

══════════════════

     │

     ▼

WEB APPLICATION

     │

     ▼

══════════════════

 TRUST BOUNDARY

══════════════════

     │

     ▼

PRIVILEGED DATABASE

Threat modeling pays particular attention to these transitions.

Part X — Trusted Computing Base

35. What Is the TCB?

The Trusted Computing Base, or TCB, is the collection of system components that must function correctly for the system's security policy to be enforced.

Conceptually, the TCB may include:

• hardware;

• firmware;

• operating-system security mechanisms;

• security-critical software.

36. TCB Concept

┌──────────────────────────────┐

│ APPLICATIONS                 │

│ Most are outside the TCB     │

└──────────────┬───────────────┘

               │

════════════ SECURITY ═══════════

               │

┌──────────────────────────────┐

│ TRUSTED COMPUTING BASE       │

│                              │

│ Security Kernel              │

│ Access-Control Mechanisms    │

│ Privileged OS Components     │

│ Trusted Hardware/Firmware    │

└──────────────────────────────┘

37. Why the TCB Matters

If a security-critical TCB component fails or becomes malicious, controls relying on it may become unreliable.

This creates an important architectural principle:

Keep security-critical trusted components as small and understandable as practical.

This aligns with the current CISSP secure-design principle keep it simple and small.

Part XI — Reference Monitor

38. Reference-Monitor Concept

A reference monitor is a conceptual mechanism that mediates access by subjects to objects.

Conceptually:

SUBJECT

(User / Process)

     │

     ▼

┌───────────────────────┐

│ REFERENCE MONITOR     │

│                       │

│ Evaluate Policy       │

│ Check Authorization   │

└───────────┬───────────┘

            │

       ┌────┴────┐

      ALLOW      DENY

        │

        ▼

      OBJECT

39. Reference Monitor Characteristics

Classic reference-monitor concepts emphasize that the mechanism should be:

• always invoked;

• tamper resistant;

• sufficiently small and simple to permit analysis.

These concepts support trusted-system design.

40. Complete Mediation

Every access request should be evaluated rather than relying indefinitely on a previous authorization decision when the design requires mediation.

This concept helps prevent unauthorized bypass.

Part XII — Security Kernel

41. What Is a Security Kernel?

The security kernel is the security-enforcing core that implements reference-monitor functionality within a system.

It is generally considered part of the TCB.

42. Relationship

REFERENCE MONITOR

   Conceptual Model

        │

        ▼

SECURITY KERNEL

Implementation Mechanism

        │

        ▼

TRUSTED COMPUTING BASE

Broader Trusted Components

This distinction is useful for CISSP terminology questions.

Part XIII — Protection Rings

43. What Are Protection Rings?

Protection rings divide computing execution into privilege levels.

The most privileged code operates closer to the center.

Less privileged code operates farther outward.

44. Ring Model

       ┌───────────────────────────┐

       │        RING 3             │

       │    User Applications      │

       │                           │

       │   ┌───────────────────┐   │

       │   │      RING 2       │   │

       │   │                   │   │

       │   │  ┌─────────────┐  │   │

       │   │  │   RING 1    │  │   │

       │   │  │             │  │   │

       │   │  │ ┌─────────┐ │  │   │

       │   │  │ │ RING 0  │ │  │   │

       │   │  │ │ KERNEL  │ │  │   │

       │   │  │ └─────────┘ │  │   │

       │   │  └─────────────┘  │   │

       │   └───────────────────┘   │

       └───────────────────────────┘

45. Ring 0

Ring 0 is typically associated with the highest privilege.

It may execute:

• kernel code;

• critical operating-system functions.

46. Outer Rings

Outer rings represent lower levels of privilege.

Typical modern systems may not use all theoretical ring levels equally.

The CISSP concept is:

More privileged code should be more tightly controlled.

47. Why Rings Matter

Protection rings help enforce:

• privilege separation;

• system integrity;

• memory isolation;

• controlled hardware access.

Part XIV — User Mode and Kernel Mode

48. User Mode

Ordinary applications generally operate with limited privilege.

They should not directly execute every privileged hardware instruction.

49. Kernel Mode

Kernel-mode code operates with significantly greater system privilege.

Because compromise here can affect the entire system:

Kernel components require strong protection.

50. Mode Transition

USER APPLICATION

       │

       ▼

SYSTEM CALL

       │

       ▼

SECURITY CHECK

       │

       ▼

KERNEL MODE

       │

       ▼

PRIVILEGED OPERATION

       │

       ▼

RETURN TO USER MODE

Part XV — Memory Protection

51. Memory Protection

Memory protection restricts one process or privilege level from improperly accessing another process's memory or protected system memory.

Memory protection is explicitly listed as an information-system security capability in the current CISSP examination outline.

52. Why Memory Protection Matters

Without effective memory protection:

• one application could read another application's secrets;

• malicious code could overwrite kernel memory;

• process failures could corrupt unrelated applications.

53. Address-Space Isolation

Conceptually:

PROCESS A

┌───────────────────┐

│ Address Space A   │

└───────────────────┘



PROCESS B

┌───────────────────┐

│ Address Space B   │

└───────────────────┘



KERNEL

┌───────────────────┐

│ Protected Memory  │

└───────────────────┘

The architecture prevents unrestricted cross-access.

54. Memory-Protection Mechanisms

At a high level, systems may use:

• CPU privilege levels;

• page permissions;

• virtual memory;

• access controls;

• execution protections.

The exact implementation depends on architecture.

55. Read, Write, Execute

Memory regions may have permissions controlling whether they may be:

• read;

• written;

• executed.

This supports the principle that code and data should not automatically receive every permission.

Part XVI — Hardware Roots of Trust

56. What Is a Root of Trust?

A root of trust is a component or function considered sufficiently trustworthy to establish or support security assurances for other system components.

Hardware-based roots of trust can provide a stronger foundation because they exist below ordinary application software.

NIST describes trusted platforms as depending on multiple technologies and identifies roots of trust as foundational components used to establish trustworthiness.

57. Trust Chain

HARDWARE ROOT OF TRUST

        │

        ▼

FIRMWARE VERIFIED

        │

        ▼

BOOT COMPONENT VERIFIED

        │

        ▼

OPERATING SYSTEM

        │

        ▼

APPLICATION ENVIRONMENT

Security in higher layers depends on trust established below them.

Part XVII — Trusted Platform Module

58. What Is a TPM?

A Trusted Platform Module is a hardware-based security component used to support trusted computing functions.

The current CISSP exam outline explicitly identifies Trusted Platform Module (TPM) as a system-security capability.

NIST's cryptographic-module records describe TPM implementations as hardware modules supporting cryptographic keys, certificates, and trusted-platform security functions.

59. TPM Capabilities

At CISSP level, associate TPMs with:

• secure key storage;

• platform measurements;

• attestation support;

• device identity;

• trusted boot functions;

• cryptographic operations.

60. TPM Concept

┌────────────────────────────┐

│        PLATFORM            │

│                            │

│  Operating System          │

│  Applications              │

│                            │

│  ┌──────────────────────┐  │

│  │        TPM           │  │

│  │                      │  │

│  │ Keys                 │  │

│  │ Measurements         │  │

│  │ Trust Functions      │  │

│  └──────────────────────┘  │

└────────────────────────────┘

61. TPM Is Not a General CPU

A TPM is not intended to replace the system processor.

It performs specialized trusted-security functions.

62. TPM Exam Trap

Do not assume:

TPM = full-disk encryption.

A TPM can protect keys used by disk-encryption systems, but the concepts are different.

Part XVIII — Secure Boot

63. Secure Boot

Secure boot attempts to ensure that authorized and trusted software components participate in the boot process.

Conceptually:

POWER ON

   │

   ▼

TRUSTED FIRMWARE

   │

   ▼

VERIFY NEXT COMPONENT

   │

   ▼

BOOTLOADER

   │

   ▼

VERIFY OS COMPONENT

   │

   ▼

OPERATING SYSTEM

64. Why Secure Boot Matters

If an attacker can modify firmware or boot components before ordinary security controls start, the attacker may establish highly privileged persistence.

NIST's platform-firmware resiliency guidance emphasizes protecting firmware against unauthorized changes, detecting changes, and securely recovering from attacks.

65. Measured Boot

Measured boot records measurements of boot components so platform state can later be evaluated or attested.

Simplified distinction:

66. Attestation

Attestation provides evidence about the state or identity of a platform.

A remote system may use attestation information when determining whether a device should be trusted for access.

Part XIX — Secure Defaults

67. Secure Defaults

Secure defaults means a system should start from a secure state rather than requiring users to discover and disable insecure functionality.

The current CISSP exam outline explicitly lists secure defaults under Objective 3.1.

68. Insecure Default Example

A new service ships with:

• administrator password = admin;

• remote administration enabled;

• anonymous access enabled.

This violates secure-default principles.

69. Better Default

NEW SYSTEM

   │

   ▼

MINIMUM SERVICES ENABLED

   │

   ▼

STRONG AUTHENTICATION REQUIRED

   │

   ▼

RESTRICTIVE ACCESS

   │

   ▼

ADMIN ENABLES ADDITIONAL

FUNCTIONALITY WHEN NEEDED

70. Fail-Safe Default Concept

Access should generally be denied unless explicitly permitted.

This concept complements secure defaults.

Part XX — Fail Securely

71. Fail Securely

When a system component fails, it should move toward a secure state rather than an insecure state.

The current CISSP outline explicitly includes fail securely as a design principle.

72. Fail-Open Versus Fail-Closed

Example:

An access-control mechanism loses communication with its policy server.

Possible behaviors:

Fail Open

Allow all traffic.

Fail Closed

Deny traffic.

73. Is Fail Closed Always Correct?

No.

Consider:

• emergency exits;

• life-safety systems;

• medical systems.

Architecture must consider:

• safety;

• mission;

• availability;

• security.

74. CISSP Principle

The correct failure state depends on the system's security and safety requirements.

Do not memorize:

Fail closed is always correct.

Part XXI — Keep It Simple and Small

75. Simplicity

The current CISSP outline specifically includes:

Keep it simple and small

as a secure-design principle.

Complex systems are harder to:

• understand;

• test;

• secure;

• verify.

76. Complexity Creates Attack Surface

MORE FEATURES

    │

    ▼

MORE CODE

    │

    ▼

MORE DEPENDENCIES

    │

    ▼

MORE INTERACTIONS

    │

    ▼

MORE POSSIBLE FAILURE MODES

This does not mean complex functionality is always unnecessary.

It means unnecessary complexity should be avoided.

Part XXII — Least Privilege in Architecture

77. Architectural Least Privilege

Least privilege applies not only to users.

It also applies to:

• services;

• applications;

• containers;

• APIs;

• devices;

• administrators.

78. Poor Architecture

WEB APPLICATION

      │

      ▼

DATABASE ACCOUNT

FULL ADMINISTRATOR

If the application is compromised, the attacker inherits excessive privilege.

79. Better Architecture

WEB APPLICATION

      │

      ▼

RESTRICTED SERVICE ACCOUNT

      │

      ├── READ required tables

      ├── WRITE required records

      └── NO administrative rights

Part XXIII — Separation of Duties

80. Architectural Separation of Duties

The current CISSP outline includes segregation of duties under secure-design principles.

Architecture can enforce separation through:

• roles;

• approval workflows;

• separate administrative accounts;

• separate environments.

81. Example

DEVELOPER

    │

 Creates Code

    │

    ▼

CODE REVIEWER

    │

 Approves

    │

    ▼

DEPLOYMENT SYSTEM

    │

 Deploys

    ▼

PRODUCTION

The developer cannot unilaterally create, approve, and deploy a sensitive change.

Part XXIV — Defense in Depth

82. Defense in Depth as Architecture

Defense in depth was introduced in Lesson Two.

Here we apply it architecturally.

                  INTERNET

                     │

                     ▼

              EDGE CONTROLS

                     │

                     ▼

             NETWORK CONTROLS

                     │

                     ▼

               SEGMENTATION

                     │

                     ▼

             IDENTITY CONTROL

                     │

                     ▼

             HOST PROTECTION

                     │

                     ▼

          APPLICATION SECURITY

                     │

                     ▼

               DATA CONTROL

                     │

                     ▼

          MONITORING & RESPONSE

                     │

                     ▼

            RECOVERY CONTROLS

Defense in depth is explicitly identified in Objective 3.1.

83. Layer Independence

Strong layers should not all depend on one vulnerable mechanism.

Example:

If:

• firewall;

• endpoint console;

• cloud admin;

• backups;

all depend on one unprotected administrator password, layered technology may still have a single trust weakness.

Part XXV — Zero Trust Architecture

84. Zero Trust

Zero Trust removes the assumption that an identity or device should be implicitly trusted simply because of:

• network location;

• organizational ownership;

• previous access.

NIST SP 800-207 describes Zero Trust as moving security away from static network perimeters toward protecting users, assets, and resources, with no implicit trust based solely on network location or asset ownership.

85. Traditional Perimeter Model

INTERNET

   │

   ▼

FIREWALL

   │

   ▼

INTERNAL NETWORK

  "TRUSTED"

86. Zero Trust Model

SUBJECT

User / Service / Device

        │

        ▼

VERIFY IDENTITY

        │

        ▼

ASSESS DEVICE / CONTEXT

        │

        ▼

POLICY DECISION

        │

     ┌──┴───┐

   ALLOW   DENY

     │

     ▼

MINIMUM AUTHORIZED

RESOURCE ACCESS

     │

     ▼

CONTINUOUS MONITORING

87. Resource-Centric Security

NIST emphasizes protecting resources rather than assuming a network segment is trustworthy.

This means the security question becomes:

Should this subject access this resource under these conditions?

rather than:

Is the subject inside the network?

88. Zero Trust Does Not Mean

Zero Trust does not mean:

• no one is ever trusted;

• deny everything permanently;

• eliminate networks;

• purchase one product.

It is an architectural approach.

Part XXVI — Policy Engine and Enforcement

89. Zero Trust Components

At a conceptual level, NIST's Zero Trust Architecture includes:

• Policy Engine;

• Policy Administrator;

• Policy Enforcement Point.

90. Architecture

SUBJECT

   │

   ▼

POLICY ENFORCEMENT POINT

   │

   ├─────────────► POLICY ENGINE

   │                  │

   │             Decision

   │                  │

   ◄──────────────────┘

   │

   ▼

RESOURCE

Detailed Zero Trust implementations may vary.

Part XXVII — Privacy by Design

91. Privacy by Design

Privacy by design means privacy considerations should be incorporated into architecture early rather than added only after deployment.

The current CISSP outline includes privacy by design as a secure-design principle.

92. Architecture Example

Instead of:

COLLECT EVERYTHING

      │

      ▼

STORE FOREVER

      │

      ▼

TRY TO PROTECT IT

Design:

DEFINE PURPOSE

     │

     ▼

COLLECT MINIMUM

     │

     ▼

RESTRICT ACCESS

     │

     ▼

LIMIT RETENTION

     │

     ▼

SECURELY DISPOSE

Part XXVIII — Shared Responsibility

93. Shared Responsibility

Shared responsibility recognizes that security responsibilities may be divided among multiple organizations or parties.

The concept is particularly important in:

• cloud computing;

• managed services;

• SaaS.

It is explicitly included in current CISSP secure-design principles.

94. Cloud Example

In a cloud service:

The provider may secure:

• physical infrastructure;

• portions of the virtualization environment.

The customer may remain responsible for:

• identities;

• data;

• configurations;

• application settings.

Exact responsibilities depend on the service model and contract.

95. Shared Does Not Mean Undefined

RESPONSIBILITY MATRIX



PROVIDER

   │

   ├── Physical infrastructure

   ├── Platform components

   │

CUSTOMER

   │

   ├── Identities

   ├── Data

   ├── Configuration

   │

SHARED

   │

   └── Defined responsibilities

The key principle is:

Responsibility must be explicit.

Part XXIX — Secure Access Service Edge

96. SASE

Secure Access Service Edge, or SASE, is explicitly identified in the current CISSP secure-design objective.

At a high level, SASE combines network-connectivity and security capabilities in a distributed, often cloud-delivered architecture.

97. SASE Concept

Traditional:

REMOTE USER

    │

    ▼

HQ DATA CENTER

    │

 Security Stack

    │

    ▼

CLOUD APPLICATION

SASE-oriented concept:

USER / BRANCH / DEVICE

        │

        ▼

DISTRIBUTED SECURITY

& ACCESS SERVICE

        │

        ├── Identity-aware access

        ├── Policy enforcement

        ├── Secure connectivity

        │

        ▼

APPLICATION / CLOUD / DATA

98. CISSP Perspective

For CISSP:

Associate SASE with:

• distributed users;

• cloud services;

• integrated networking and security;

• policy enforcement closer to users and resources.

Detailed networking implementation belongs in Domain 4.

Part XXX — Selecting Controls From Requirements

99. Requirements Before Controls

Domain 3.3 requires candidates to:

Select controls based upon systems security requirements.

Good architecture begins with requirements.

100. Control-Selection Flow

MISSION

  │

  ▼

ASSET

  │

  ▼

SECURITY REQUIREMENT

  │

  ▼

THREAT / RISK

  │

  ▼

ARCHITECTURAL PRINCIPLE

  │

  ▼

CONTROL SELECTION

  │

  ▼

IMPLEMENTATION

101. Example

Requirement:

Only authorized payment services may modify transaction data.

Possible controls:

• service authentication;

• authorization;

• integrity protection;

• least-privileged service accounts;

• logging.

Do not choose a firewall simply because it is a familiar control.

Choose controls that satisfy the actual requirement.

Part XXXI — Protection-Mechanism Comparison

102. Comparison Table

Part XXXII — Defense Architecture Example

103. Secure Enterprise Application

                   INTERNET

                      │

                      ▼

              ┌──────────────┐

              │ EDGE FILTER  │

              └──────┬───────┘

                     │

                     ▼

════════════════ TRUST BOUNDARY ════════════════

                     │

              ┌──────▼───────┐

              │ WEB SERVICE  │

              └──────┬───────┘

                     │

                     ▼

              ┌──────────────┐

              │ APP SERVICE  │

              │ Least Priv.  │

              └──────┬───────┘

                     │

                     ▼

════════════════ DATA BOUNDARY ═════════════════

                     │

              ┌──────▼───────┐

              │ DATABASE     │

              │ Encryption   │

              │ Access Ctrl  │

              └──────────────┘



Supporting controls:

• MFA

• Logging

• Monitoring

• Segmentation

• Backup

• Recovery

Part XXXIII — Architecture Failure Example

104. Flat Trust Architecture

INTERNET

   │

   ▼

VPN

   │

   ▼

INTERNAL NETWORK

   │

   ├── Workstations

   ├── Servers

   ├── Admin Systems

   ├── Databases

   └── Backups



One authenticated user

may reach almost everything.

Potential problems:

• excessive trust;

• weak segmentation;

• large attack surface;

• lateral movement;

• privilege escalation.

105. Improved Architecture

IDENTITY

   │

   ▼

CONTEXT / DEVICE CHECK

   │

   ▼

POLICY

   │

   ▼

SEGMENT / RESOURCE

   │

   ▼

LEAST-PRIVILEGED ACCESS

   │

   ▼

MONITORING

Part XXXIV — Hardware/Firmware Security

106. Why Firmware Matters

Firmware often executes before the operating system.

If compromised, it may undermine controls running above it.

NIST notes that platform-firmware compromise can cause severe system disruption and emphasizes mechanisms for protection, detection, and secure recovery.

107. Layered Boot Trust

HARDWARE

   │

   ▼

FIRMWARE

   │

   ▼

BOOTLOADER

   │

   ▼

OPERATING SYSTEM

   │

   ▼

SECURITY SOFTWARE

   │

   ▼

APPLICATION

Higher layers depend partly on lower layers.

108. Architectural Lesson

Security architecture should protect the entire stack.

A secure application cannot fully compensate for a maliciously compromised platform beneath it.

Part XXXV — Fail-Secure Scenarios

109. Scenario — Firewall Policy Server

A firewall loses connection with its central authorization service.

Security requirements prioritize preventing unauthorized external access.

Which behavior is MOST appropriate?

A. Allow all connections.

B. Continue only explicitly permitted local rules or deny new unauthorized traffic according to approved fail-secure design.

C. Disable all logging.

D. Convert all users to administrators.

Correct Answer

B

110. Scenario — Emergency Exit

An electronically controlled emergency exit loses power during a building fire.

What is the PRIMARY consideration?

A. Preventing unauthorized entry at all costs.

B. Human life safety.

C. Preserving logs.

D. Protecting the access-control server.

Correct Answer

B

Fail-secure design must consider safety requirements.

Part XXXVI — Architecture Scenarios

111. Scenario — Abstraction

Users directly connect to a sensitive database using privileged database accounts.

Which architectural improvement BEST reduces unnecessary direct access?

A. Introduce an application/API abstraction layer with appropriate authorization.

B. Give users database administrator rights.

C. Disable logging.

D. Move the database to a public network.

Correct Answer

A

112. Scenario — Data Hiding

A software component exposes its internal cryptographic keys through a public application interface.

Which design principle is MOST clearly violated?

A. Data hiding.

B. Availability.

C. Job rotation.

D. Recovery.

Correct Answer

A

113. Scenario — Isolation

A vulnerability in one customer workload allows access to another customer's workload on the same platform.

Which architectural control MOST clearly failed?

A. Isolation.

B. Retention.

C. Classification.

D. Copyright.

Correct Answer

A

114. Scenario — Memory

A normal user application overwrites operating-system kernel memory.

Which protection capability failed?

A. Memory protection.

B. Data retention.

C. DLP.

D. SLA.

Correct Answer

A

115. Scenario — TPM

An organization wants device-specific protected cryptographic key storage and platform measurements.

Which technology is MOST directly relevant?

A. TPM.

B. CASB.

C. DLP.

D. RAID.

Correct Answer

A

116. Scenario — Secure Defaults

A newly installed database permits remote administrator login using a default password.

Which principle has been MOST clearly violated?

A. Secure defaults.

B. Data minimization.

C. Job rotation.

D. Risk transfer.

Correct Answer

A

117. Scenario — Simplicity

A development team wants to add dozens of unused services and components “in case they are needed someday.”

What secure-design principle argues against this?

A. Keep it simple and small.

B. Risk transfer.

C. Mandatory vacation.

D. Data remanence.

Correct Answer

A

118. Scenario — Zero Trust

A company automatically trusts every device connected to its internal network.

Which architectural principle MOST directly challenges this assumption?

A. Zero Trust.

B. Copyright.

C. Retention.

D. Tokenization.

Correct Answer

A

Part XXXVII — Common CISSP Exam Traps

119. Trap — Architecture Means Product Selection

Architecture defines structure and trust relationships.

Technology implements architectural requirements.

120. Trap — Abstraction Equals Encryption

Abstraction hides complexity.

Encryption protects confidentiality through cryptographic transformation.

121. Trap — Data Hiding Equals Encryption

Data hiding restricts exposure.

It does not necessarily make information cryptographically unreadable.

122. Trap — Isolation Means Air Gap Only

Isolation can exist:

• logically;

• virtually;

• physically;

• at process level.

123. Trap — Security Boundary Equals Firewall

A firewall may enforce a boundary.

The boundary is the policy/trust transition itself.

124. Trap — TPM Encrypts Everything

TPMs provide specialized trust and cryptographic-support capabilities.

They are not a replacement for every cryptographic control.

125. Trap — Fail Closed Is Always Correct

Safety and mission requirements may demand different failure behavior.

126. Trap — Internal Network Equals Trusted

Zero Trust explicitly rejects implicit trust based solely on network location.

127. Trap — More Controls Always Means Better Architecture

Unnecessary controls may add:

• complexity;

• cost;

• misconfiguration.

Architecture should be proportionate and understandable.

128. Trap — Secure Boot Equals Measured Boot

Secure boot:

Enforces authorized boot components.

Measured boot:

Records boot measurements for evaluation/attestation.

129. Trap — Shared Responsibility Means Shared Confusion

Responsibilities should be explicitly defined.

Part XXXVIII — SierraTec Secure Architecture Method

130. ARCHITECT Model

Use the SierraTec Secure ARCHITECT model for architecture questions.

A — Assets

What requires protection?

R — Requirements

Which security properties are necessary?

C — Components

Which systems, services, and processes exist?

H — Hierarchy of Trust

Which components are more privileged or trusted?

I — Interfaces and Boundaries

Where does data or trust cross boundaries?

T — Threats

What can go wrong?

E — Enforcement

Which protection mechanisms enforce requirements?

C — Containment

How is compromise isolated?

T — Test and Trust

How is effectiveness verified and maintained?

131. ARCHITECT Diagram

A

ASSETS

   │

   ▼

R

REQUIREMENTS

   │

   ▼

C

COMPONENTS

   │

   ▼

H

HIERARCHY OF TRUST

   │

   ▼

I

INTERFACES / BOUNDARIES

   │

   ▼

T

THREATS

   │

   ▼

E

ENFORCEMENT

   │

   ▼

C

CONTAINMENT

   │

   ▼

T

TEST & TRUST

Part XXXIX — Knowledge Check

132. Knowledge Check

Question 1

What is the PRIMARY purpose of security architecture?

A. Purchase products.

B. Structure systems so security requirements are enforced by design.

C. Eliminate governance.

D. Replace risk management.

Correct Answer

B

Question 2

Which concept hides unnecessary implementation complexity?

A. Abstraction.

B. Encryption.

C. Retention.

D. Availability.

Correct Answer

A

Question 3

Which principle restricts direct visibility into internal information or implementation?

A. Data hiding.

B. Recovery.

C. Risk transfer.

D. Availability.

Correct Answer

A

Question 4

Which concept packages information and approved operations while restricting direct access?

A. Encapsulation.

B. Retention.

C. Authentication.

D. Disaster recovery.

Correct Answer

A

Question 5

Which principle prevents one process from freely accessing another process's memory?

A. Isolation.

B. Availability.

C. Privacy notice.

D. SLA.

Correct Answer

A

Question 6

What is a security boundary?

A. A point where security policy or trust requirements change.

B. A legal contract.

C. An asset inventory.

D. A retention schedule.

Correct Answer

A

Question 7

What does TCB stand for?

A. Trusted Computing Base.

B. Technical Control Boundary.

C. Trusted Cloud Backup.

D. Total Cybersecurity Baseline.

Correct Answer

A

Question 8

What is the conceptual purpose of a reference monitor?

A. Mediate subject access to objects according to policy.

B. Provide backup power.

C. Encrypt all files.

D. Create contracts.

Correct Answer

A

Question 9

Which component generally implements the core reference-monitor functionality?

A. Security kernel.

B. DLP.

C. CASB.

D. SLA.

Correct Answer

A

Question 10

Which ring is commonly associated with the highest system privilege?

A. Ring 0.

B. Ring 3.

C. Ring 8.

D. Ring 10.

Correct Answer

A

Question 11

Which capability prevents an ordinary process from improperly writing kernel memory?

A. Memory protection.

B. Retention.

C. DLP.

D. Data classification.

Correct Answer

A

Question 12

Which technology provides hardware-assisted trusted-platform functions?

A. TPM.

B. DLP.

C. CASB.

D. RAID.

Correct Answer

A

Question 13

Which principle says systems should begin in a restrictive secure state?

A. Secure defaults.

B. Risk transfer.

C. Data remanence.

D. Job rotation.

Correct Answer

A

Question 14

Which principle addresses secure behavior during system failure?

A. Fail securely.

B. Data minimization.

C. Copyright.

D. Risk acceptance.

Correct Answer

A

Question 15

Which principle seeks to reduce unnecessary system complexity?

A. Keep it simple and small.

B. Data replication.

C. Risk transfer.

D. SLA.

Correct Answer

A

Question 16

Which design approach uses several complementary security layers?

A. Defense in depth.

B. Tokenization.

C. Data retention.

D. Licensing.

Correct Answer

A

Question 17

Which architecture rejects automatic trust based solely on network location?

A. Zero Trust.

B. Perimeter-only trust.

C. DRM.

D. RAID.

Correct Answer

A

Question 18

Which principle integrates privacy requirements into system design?

A. Privacy by design.

B. Fail-open design.

C. Risk transfer.

D. Availability only.

Correct Answer

A

Question 19

Which concept is particularly important for defining security responsibilities between cloud customer and provider?

A. Shared responsibility.

B. Data remanence.

C. Copyright.

D. Job rotation.

Correct Answer

A

Question 20

What should primarily drive selection of security controls?

A. System-security requirements and risk.

B. Product popularity.

C. Vendor advertising.

D. Number of available features.

Correct Answer

A

Part XL — Original CISSP-Style Scenario Practice

133. Practice Question 1

A security architect wants to reduce the amount of trusted security-critical code in a new operating system.

Which principle BEST supports this objective?

A. Keep the trusted design simple and small.

B. Add unnecessary services.

C. Give every application kernel privileges.

D. Disable isolation.

Correct Answer

A

134. Practice Question 2

A user application directly accesses physical memory belonging to another application.

Which protection mechanism MOST clearly failed?

A. Memory isolation/protection.

B. Data retention.

C. Encryption at rest.

D. SLA monitoring.

Correct Answer

A

135. Practice Question 3

A cloud customer assumes the provider is responsible for configuring every customer identity and application permission.

Which principle should the architect review?

A. Shared responsibility.

B. Copyright.

C. Risk transfer only.

D. Data remanence.

Correct Answer

A

136. Practice Question 4

A new system enables every optional network service by default.

Which design principle is MOST clearly violated?

A. Secure defaults.

B. Availability.

C. Data minimization.

D. Separation of duties.

Correct Answer

A

137. Practice Question 5

An application processes highly sensitive data using one administrator account for every service.

Which principle is MOST clearly violated?

A. Least privilege.

B. Availability.

C. Retention.

D. Data sovereignty.

Correct Answer

A

138. Practice Question 6

A database server contains public, confidential, and highly restricted data but provides identical unrestricted access to all application components.

What architectural improvement is MOST appropriate?

A. Create security domains and enforce authorization boundaries according to requirements.

B. Increase storage capacity.

C. Remove logging.

D. Make every account administrator.

Correct Answer

A

139. Practice Question 7

A compromised workstation can directly communicate with backup infrastructure, domain administration systems, and production databases.

What architectural weakness is MOST apparent?

A. Insufficient isolation and segmentation.

B. Excessive data retention.

C. Poor copyright management.

D. Too many backups.

Correct Answer

A

140. Practice Question 8

A hardware security component protects device cryptographic keys and supports platform measurements.

Which capability is being described?

A. TPM.

B. DLP.

C. CASB.

D. DRM.

Correct Answer

A

141. Practice Question 9

A company wants only approved boot components to execute when a workstation starts.

Which mechanism MOST directly addresses this requirement?

A. Secure boot.

B. DLP.

C. Tokenization.

D. Job rotation.

Correct Answer

A

142. Practice Question 10

A user is authenticated to the corporate network. The organization automatically allows that user unrestricted access to every internal application.

Which modern architecture principle is MOST clearly missing?

A. Zero Trust / resource-specific authorization.

B. Data retention.

C. DRM.

D. Copyright.

Correct Answer

A

Part XLI — Key Terms

143. Key Terms

Security Architecture

Structured design of security relationships, boundaries, mechanisms, and controls.

Protection Mechanism

Technical or architectural mechanism enforcing a security requirement.

Abstraction

Hiding implementation complexity behind a controlled interface.

Data Hiding

Restricting direct visibility or access to internal information.

Encapsulation

Combining data and approved operations while restricting direct access.

Isolation

Separating components to prevent unauthorized interaction or failure propagation.

Security Domain

Environment governed by common security policies or trust assumptions.

Security Boundary

Point where security requirements, policies, or trust levels change.

Trust Boundary

Point at which trust assumptions change.

Trusted Computing Base

Collection of components relied upon to enforce a system's security policy.

Reference Monitor

Conceptual mechanism mediating access between subjects and objects.

Security Kernel

Core trusted implementation enforcing security-policy decisions.

Protection Ring

Privilege level separating more trusted execution from less privileged execution.

Kernel Mode

Highly privileged processor execution mode.

User Mode

Restricted execution mode used by ordinary applications.

Memory Protection

Mechanisms preventing improper access to protected memory.

Root of Trust

Trusted foundation used to establish security assurances for other components.

TPM

Trusted Platform Module; hardware security component supporting trusted computing and cryptographic functions.

Secure Boot

Mechanism intended to permit only authorized boot components to execute.

Measured Boot

Process recording measurements of boot components for evaluation or attestation.

Attestation

Evidence supporting claims about platform identity or state.

Secure Defaults

Principle that systems should begin in a restrictive, secure configuration.

Fail Securely

Principle that system failures should not unnecessarily create insecure conditions.

Defense in Depth

Use of multiple complementary security layers.

Zero Trust

Architecture that avoids implicit trust based solely on location or ownership.

Privacy by Design

Embedding privacy requirements into system architecture from the beginning.

Shared Responsibility

Division of security responsibilities between multiple parties.

SASE

Secure Access Service Edge; architecture combining distributed networking and security capabilities.

Part XLII — CISSP Exam Focus

144. Architecture Mindset

Remember:

REQUIREMENT

    ↓

TRUST MODEL

    ↓

BOUNDARIES

    ↓

PRIVILEGE

    ↓

ISOLATION

    ↓

PROTECTION MECHANISM

    ↓

MONITORING

    ↓

ASSURANCE

For CISSP questions:

• Architecture should begin with requirements.

• Security should be designed in, not added afterward.

• Abstraction hides unnecessary complexity.

• Data hiding reduces unnecessary visibility.

• Encapsulation enforces controlled interfaces.

• Isolation contains failure and compromise.

• Security boundaries represent changes in policy or trust.

• TCB components are relied upon for security enforcement.

• A reference monitor conceptually mediates access.

• A security kernel implements core security enforcement.

• Protection rings separate privilege levels.

• Memory protection prevents improper cross-process or kernel access.

• TPMs provide hardware-assisted trust capabilities.

• Secure boot supports trusted startup.

• Secure defaults reduce unnecessary exposure.

• Fail-secure behavior must consider security and safety.

• Simplicity reduces unnecessary attack surface.

• Least privilege applies to users, services, and applications.

• Separation of duties can be built into architecture.

• Defense in depth requires complementary layers.

• Zero Trust removes implicit trust based solely on location.

• Privacy should be incorporated into design.

• Shared responsibility should be explicit.

• SASE combines distributed networking and security concepts.

• Controls should be selected from defined security requirements—not vendor popularity.

145. Lesson Summary

Lesson Eight introduced the architectural foundation upon which secure systems are built.

The current CISSP examination explicitly requires candidates to understand secure-design principles including:

• threat modeling;

• least privilege;

• defense in depth;

• secure defaults;

• fail securely;

• separation of duties;

• simplicity;

• Zero Trust;

• privacy by design;

• shared responsibility;

• Secure Access Service Edge.

You learned that security architecture should translate:

BUSINESS REQUIREMENT

        ↓

SECURITY REQUIREMENT

        ↓

DESIGN PRINCIPLE

        ↓

ARCHITECTURE

        ↓

PROTECTION MECHANISM

        ↓

IMPLEMENTATION

You studied foundational protection concepts including:

• abstraction;

• data hiding;

• encapsulation;

• isolation;

• security domains;

• security boundaries;

• trust boundaries.

You also examined trusted-system concepts:

TRUSTED COMPUTING BASE

        │

        ├── Security Kernel

        │

        ├── Reference-Monitor Enforcement

        │

        ├── Trusted Hardware

        │

        └── Security-Critical OS Components

You learned how protection rings and memory protection help separate privileged system execution from ordinary applications.

The current CISSP outline specifically identifies memory protection, TPM, and encryption/decryption as system-security capabilities under Objective 3.4.

You also examined hardware-based trust.

NIST describes trusted platforms as systems that rely on multiple technologies to establish reliable security and privacy behavior, while its platform-firmware guidance emphasizes protection, detection, and recovery mechanisms for low-level firmware.

Finally, you studied Zero Trust. NIST SP 800-207 explains that Zero Trust removes implicit trust based solely on network location or device ownership and shifts focus toward protecting individual enterprise resources.

The central Lesson Eight principle is:

A secure system should not depend on everyone doing the right thing all the time. Its architecture should limit privilege, mediate access, isolate components, establish clear boundaries, protect trusted functions, and fail in predictable and appropriately secure ways.

Exam Readiness Check

Before continuing to Lesson Nine, make sure you can explain:

• What security architecture means.

• Why architecture differs from implementation.

• What a protection mechanism is.

• What abstraction means.

• Why abstraction can improve security.

• What data hiding means.

• Why data hiding differs from encryption.

• What encapsulation means.

• How encapsulation differs from abstraction.

• What isolation means.

• What process isolation does.

• How VM and container isolation differ conceptually.

• What a security domain is.

• What a security boundary is.

• What a trust boundary is.

• Why a security boundary is not necessarily a firewall.

• What the Trusted Computing Base is.

• Why TCB size matters.

• What a reference monitor does conceptually.

• What a security kernel does.

• How a security kernel relates to the TCB.

• What protection rings represent.

• Why Ring 0 is highly privileged.

• The difference between user mode and kernel mode.

• What memory protection accomplishes.

• Why address-space separation matters.

• What a root of trust is.

• What a TPM is.

• What TPMs can protect or measure.

• Why TPM does not equal disk encryption.

• What secure boot accomplishes.

• What measured boot accomplishes.

• How secure boot differs from measured boot.

• What attestation means.

• What secure defaults mean.

• What fail securely means.

• Why fail closed is not always appropriate.

• Why simplicity is a security principle.

• How least privilege applies to applications.

• How separation of duties can be architectural.

• Why defense-in-depth layers should be independent.

• What Zero Trust means.

• Why internal network location does not automatically imply trust.

• What privacy by design means.

• What shared responsibility means.

• What SASE means at a high level.

• Why security controls should be selected from security requirements.

Coming Next

Lesson Nine: Security Models, Trusted Systems, and Secure Design

Lesson Nine will build directly on the architecture foundation by examining formal and conceptual security models used to define and reason about information flow, confidentiality, integrity, and system trust.

It will include:

• security models;

• state-machine concepts;

• information-flow models;

• access-control models;

• confidentiality models;

• integrity models;

• Bell-LaPadula;

• Simple Security Property;

• Star Property;

• Strong Star Property;

• Biba;

• Simple Integrity Axiom;

• Star Integrity Axiom;

• Invocation Property;

• Clark-Wilson;

• well-formed transactions;

• separation of duties;

• Constrained Data Items;

• Unconstrained Data Items;

• Transformation Procedures;

• Integrity Verification Procedures;

• Brewer-Nash / Chinese Wall;

• conflict-of-interest controls;

• lattice-based security;

• multilevel security;

• trusted systems;

• system evaluation concepts;

• assurance;

• certification versus accreditation/authorization concepts;

• security-model comparison tables;

• original diagrams;

• scenario-based model selection;

• CISSP examination traps.

The central Lesson Nine question will be:

How can formal models define what information may flow, who may access it, and how confidentiality and integrity can be enforced consistently across trusted systems?

Publication and Independence Notice

This lesson is independently developed educational material for the SierraTec Secure CISSP Certification Preparation Course.

CISSP is administered by ISC2. SierraTec Secure's course is independent certification-preparation material and should not be represented as official ISC2 training unless separately authorized.

The principal examination alignment for Lesson Eight was checked against the current ISC2 CISSP Certification Exam Outline, effective April 15, 2024. Domain 3 currently assigns 13% of the examination to Security Architecture and Engineering. Objective 3.1 includes threat modeling, least privilege, defense in depth, secure defaults, fail securely, segregation of duties, simplicity, Zero Trust/trust but verify, privacy by design, shared responsibility, and SASE. Objective 3.3 covers control selection based on system-security requirements, while Objective 3.4 includes memory protection, TPM, and encryption/decryption.

Zero Trust concepts were checked against NIST SP 800-207. TPM and trusted-platform concepts were checked against current NIST trusted-platform and cryptographic-module material, and firmware-resiliency concepts against NIST SP 800-193.

The SierraTec Secure ARCHITECT model, diagrams, examples, comparisons, knowledge checks, and practice questions are original instructional content. They are not actual, recalled, leaked, or official CISSP examination questions.