🎯 Purpose of Domain 3

This domain focuses on the foundational principles and practices needed to design, build, and maintain secure IT systems. It emphasizes how to integrate security throughout the system development life cycle (SDLC), evaluate architectures, and apply technical controls across various environments — from traditional IT to cloud and emerging technologies.

Considering the domain depth, i have summarized the notes in to two parts and this is the Part I. Happy Learning 1

📚 What You’ll Learn in This Domain -Part I

1. Secure Design Principles
Understand how to embed security early in system and software architecture using concepts like least privilege, defense in depth, fail-safe defaults, and zero trust.


2. Security Models and Architectures
Study formal security models such as Bell-LaPadula, Biba, Clark-Wilson, and how they apply to confidentiality, integrity, and access control.


3. Systems Security Requirements
Learn how to identify and select security controls based on the needs of the business and risk assessments.


4. Security Capabilities of Information Systems
Explore how components like memory protection, encryption, TPMs, and secure boot contribute to a secure computing environment.


5. Vulnerabilities in Architectures and Systems
Analyze the unique risks of servers, cloud systems, IoT, microservices, containers, and ICS, and how to mitigate them effectively.

🔐 3.1 Secure Design Principles

🎯 Objective

To ensure systems and processes are secure by design. This involves embedding security principles into engineering and architectural decisions, from early planning to post-deployment.

🔍 Key Secure Design Principles — Deep Dive

1️⃣ Threat Modeling

Definition: A structured process used to identify and evaluate potential threats and vulnerabilities during the design and development stages of a system.

Common Methodologies:

• STRIDE – Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege.
• PASTA – Process for Attack Simulation and Threat Analysis.

Implementation:

• Conduct during architectural reviews or sprint planning.
• Involve development, security, and product teams.

Example:
A financial app applies STRIDE to its login service and identifies spoofing (fake credentials) and tampering (modification of tokens). As a result, they implement MFA and JWT signature validation.

2️⃣ Least Privilege

Definition: Users, processes, or systems should be granted only the minimum access necessary to perform their function.

Benefits:

• Reduces attack surface.
• Minimizes impact of insider threats or malware.

Examples:

• A web server account has read-only access to static content folders.
• A DevOps pipeline allows deploy scripts to access only staging, not production.

Real-World Scenario:
An attacker compromises a developer’s account. Since the account lacks admin rights and access to production secrets, damage is limited.

3️⃣ Defense in Depth

Definition: Employing multiple, layered security controls throughout a system to reduce risk if one control fails.

Layers of Defense:

• Network layer (firewalls, VPNs)
• Application layer (WAFs, input validation)
• Endpoint layer (antivirus, EDR)
• Data layer (encryption, access controls)
• Administrative layer (policies, training)

Example:
A healthcare system protects patient records using:

• MFA for users
• WAF for public APIs
• Encryption of data at rest
• Monitoring via SIEM tools

4️⃣ Secure Defaults

Definition: Systems should ship and deploy with security-focused default configurations.

Why Important:

• Most security breaches result from misconfigured defaults.
• Users may not know how to securely configure features.

Examples:

• Cloud storage (e.g., S3 buckets) are private by default.
• Unused services are disabled in operating systems.

Real-World Scenario:
A company left a cloud database open to the public. If the default had been secure (private), the exposure would have been avoided.

5️⃣ Fail Securely

Definition: When a system experiences an error or failure, it should default to a secure state, not leave resources exposed.

Examples:

• Login system locks account after 5 failed attempts instead of allowing unlimited tries.
• If a firewall malfunctions, it drops all traffic instead of allowing all.

Real-World Scenario:
A bank ATM fails and displays a message. A “fail open” approach would allow access to the system — a major security risk. Instead, it locks and powers down.

6️⃣ Segregation of Duties (SoD)

Definition: No one person should have enough access or privileges to abuse the system on their own.

Types of SoD:

• Development vs. Deployment roles
• Payment initiation vs. approval
• Backup creation vs. restoration

Example: In a finance system:

• One employee can create an invoice.
• A second employee must approve it.
• A third issues payment.

7️⃣ Keep it Simple and Small (Economy of Mechanism)

Definition: Simplify system design so it’s easier to understand, test, and secure.

Benefits:

• Fewer bugs and misconfigurations
• Better maintainability and auditability

Examples:

• Using standard APIs and frameworks.
• Keeping authentication flows minimal and well-documented.

Real-World Scenario:
A startup rewrites its complex auth code using OAuth2 libraries. This reduces attack vectors and improves compliance.

8️⃣ Zero Trust / Trust But Verify

Zero Trust Concept:

• No implicit trust for any user, device, or network — every request is verified.
• Enforce least privilege access continuously.

Core Elements:

• Identity verification (MFA, SSO)
• Device health (MDM, posture assessment)
• Microsegmentation (isolate network components)

Real-World Application:
Google’s BeyondCorp architecture enables employees to work securely from anywhere, by authenticating every session and verifying device status.

9️⃣ Privacy by Design

Definition: Embedding privacy and data protection principles into systems and processes from the start, not as an afterthought.

Core Privacy Practices:

• Data minimization
• Purpose limitation
• User control and consent
• Secure data storage and transfer

Example: A mobile health app collects only required medical information and encrypts all data both at rest and in transit. It also allows users to delete their data on demand.

Compliance Context:

• Required by GDPR, CCPA, and global privacy laws.

🔟 Shared Responsibility Model (Cloud Security)

Definition: In cloud environments, security responsibilities are divided between the cloud provider and the customer.

Real-World Example:
In AWS, they secure the data center. You must:

• Enable encryption for S3.
• Patch EC2 instances.
• Configure IAM properly.

Exam Insight: Know where responsibility lies in IaaS, PaaS, and SaaS models.

🔟Secure Access Service Edge (SASE)

Definition: A cloud-delivered architecture that converges networking and security functions into a single service.

Includes:

• SD-WAN (for connectivity)
• CASB (Cloud Access Security Broker)
• FWaaS (Firewall-as-a-Service)
• ZTNA (Zero Trust Network Access)
• SWG (Secure Web Gateway)

Use Case:

• Ideal for distributed workforces.
• Unifies access, data protection, and policy enforcement across users and devices.

Example: A global company uses SASE to give employees secure access to internal tools, regardless of location, while applying centralized policies (e.g., block Dropbox uploads).

✅ Summary

🏛️ 3.2 Understand the Fundamental Concepts of Security Models

🔍 What Are Security Models?

Security models are abstract frameworks that define how access control and information flow are handled within a computing system. They are critical in designing systems that enforce confidentiality, integrity, and availability (CIA) through forma2l policies and access restrictions.

They act as the blueprint for enforcing:

• Who can access what information
• Under what conditions
• With what level of privilege

These models help ensure secure system behavior and form the basis of many modern access control mechanisms (MAC, DAC, RBAC).

🔐 Security Models by Objective

📘 1. Bell-LaPadula Model (BLP) – Confidentiality First

🌟 Objective:

Prevent unauthorized disclosure of information.

🔑 Core Rules:

• Simple Security Property (“No Read Up”): A subject can’t read data at a higher classification level.
• *-Property (“No Write Down”): A subject can’t write information to a lower classification level.
• Discretionary Security Property: Allows using Access Control Lists (ACLs) for more flexible control.

🛡️ Real-World Example:

A government worker with “Secret” clearance cannot read “Top Secret” files (no read up) and cannot write sensitive data into “Confidential” reports (no write down).

📌 Summary:

• Enforces Mandatory Access Control (MAC)
• Prevents information leakage
• Used in military, intelligence, defense systems

📗 2. Biba Model – Integrity First

🌟 Objective:

Ensure data remains uncorrupted by untrusted sources.

🔑 Core Rules:

• Simple Integrity Property (“No Read Down”): Prevents a subject from reading lower-integrity data.
• *-Integrity Property (“No Write Up”): Prevents lower-integrity subjects from writing to higher-integrity objects.

🛡️ Real-World Example:

A junior employee cannot write data to the general ledger (no write up), and a senior accountant won’t read error-prone data from unverified sources (no read down).

📌 Summary:

• Prevents unauthorized modification
• Often used in financial or clinical systems
• Opposite of Bell-LaPadula in terms of flow control

📙 3. Clark-Wilson Model – Commercial Integrity & Transactions

🌟 Objective:

Ensure that data modifications are:

• Authorized
• Auditable
• Done via validated programs

🔑 Core Components:

• Well-formed Transactions: Only specific programs can manipulate critical data.
• Separation of Duties (SoD): No single user can execute all parts of a critical task.
• Enforced via:
  • CDIs – Constrained Data Items
  • TPs – Transformation Procedures
  • UDIs – Unconstrained Data Items

🛡️ Real-World Example:

In an enterprise resource system (ERP), a purchase order must be entered by one person, approved by another, and fulfilled by a third.

📌 Summary:

• Ensures data integrity and traceability
• Emphasizes auditing and accountability
• Applied in finance, ERP, audit-heavy systems

📕 4. Brewer-Nash Model – Dynamic Access Control / Conflict of Interest Model

🌟 Objective:

Prevent conflicts of interest by dynamically adjusting user access.

🔑 Concept:

• Access is granted based on a user’s previous actions.
• A user accessing one client’s data is barred from accessing a competitor’s data.

🛡️ Real-World Example:

A cybersecurity consultant analyzing data for Company A will be automatically blocked from viewing Company B’s data in the same industry.

📌 Summary:

• Implements context-aware, dynamic control
• Used in law firms, financial auditing, consulting
• Prevents information bleeding between clients

📓 5. Graham-Denning Model – Access Control Management

🌟 Objective:

Define secure rules for subject-object interactions (users, processes, and resources).

🔑 Features:

• 8 rules for actions like:
  • Creating/deleting subjects/objects
  • Granting or removing access rights
• Uses an access control matrix

🛡️ Real-World Example:

A user creates a file, sets read-only access for a colleague, and later revokes it using OS-level access controls.

📌 Summary:

• Foundation for access control mechanisms
• Used in operating systems, file systems
• Underpins Discretionary Access Control (DAC)

📔 6. Harrison-Ruzzo-Ullman (HRU) Model – Theoretical Access Verification

🌟 Objective:

Mathematically analyze if a system’s access control policy can maintain security over time.

🔑 Features:

• Extension of Graham-Denning
• Uses access control matrices
• Demonstrates if rights can leak via subject-object interactions

🛡️ Real-World Example:

Used in academia or research to prove whether a security policy can become insecure through a chain of user actions.

📌 Summary:

• Focused on state transitions
• More theoretical, less commonly implemented directly

📊 Summary

🛡️ 3.3: Select Controls Based Upon System Security Requirements

🎯 Objective:

Understand how to analyze security requirements for systems and apply appropriate security controls—technical, physical, and administrative—to mitigate risk, ensure compliance, and support CIA (Confidentiality, Integrity, Availability) goals.

🔍 What Are Security Controls?

Security controls are safeguards or countermeasures implemented to:

• Prevent, detect, or respond to threats
• Minimize risk to assets
• Enforce security policies and regulatory requirements

They are chosen based on system needs, risk profiles, data sensitivity, and business impact.

📂 Categories of Security Controls

🔁 Functional Types of Controls

🔄 Security Control Lifecycle

1️⃣ Identify Security Requirements

• Analyze CIA needs of the system
• Consider asset sensitivity, threat actors, operating environment
• Evaluate legal/compliance drivers (e.g., GDPR, HIPAA, PCI DSS)

📘 Example: A healthcare SaaS must meet HIPAA requirements for confidentiality and auditability.

2️⃣ Conduct Risk Assessment

• Identify assets, threats, vulnerabilities, and risks
• Calculate risk using qualitative or quantitative methods
• Prioritize risks by likelihood and impact

📘 Example: SCADA systems have high risk from cyber threats—availability becomes top priority.

3️⃣ Select Appropriate Controls

Match controls to:

• Mitigate specific threats
• Address risk levels
• Satisfy compliance or business continuity

Use control frameworks like:

• NIST SP 800-53 (for federal systems)
• ISO/IEC 27001 & 27002 (international standard)
• CIS Controls (practical implementation)
• COBIT (IT governance)
• PCI DSS (for payment card data)

📘 Example: Choose disk-level encryption to meet GDPR’s data protection mandate.

4️⃣ Implement Controls

Deploy controls based on roles, systems, and sensitivity

• Use secure configuration tools (e.g., Ansible, GPOs)
• Assign ownership for accountability

📘 Example: Enforcing RBAC in Azure AD for least privilege.

5️⃣ Monitor & Validate Effectiveness

• Test controls through vulnerability scanning, audits, and penetration testing
• Use KPIs, log analytics, and SIEM to monitor real-time performance
• Conduct periodic control reassessments during change management

🛠️ CIA Objective–Control Mapping

🛡️ 3.4: Understand Security Capabilities of Information Systems

🎯 Objective

To identify, analyze, and understand the built-in security features of modern information systems (IS) that ensure confidentiality, integrity, and availability (CIA) — by leveraging both hardware and software mechanisms such as memory protection, secure boot, TPM, encryption, and sandboxing.

🧠 Key Capabilities of Secure Information Systems

1️⃣ Memory Protection

✅ Purpose: Prevent one process from accessing or corrupting another process’s memory space.

🔧 Techniques:

• Virtual Memory: Each process gets isolated address space.
• Segmentation & Paging: Breaks memory into protected regions.
• DEP (Data Execution Prevention): Prevents code execution in memory marked as non-executable.
• ASLR (Address Space Layout Randomization): Randomizes memory addresses to thwart predictable exploits.

💡 Real-World Use: Operating systems like Windows and Linux apply DEP + ASLR to stop malware from exploiting buffer overflows.

2️⃣ Trusted Platform Module (TPM)

✅ Purpose: Hardware chip used to ensure platform integrity, secure key storage, and enable hardware-rooted trust.

🔐 Functions:

• Secure Boot & Measured Boot: Ensures only trusted firmware/OS loads.
• Cryptographic Key Generation & Sealing: Hardware-based key security.
• Platform Configuration Registers (PCRs): Store integrity measurements.

💡 Example: BitLocker leverages TPM to encrypt disk contents and verify system integrity during boot.

3️⃣ Encryption & Decryption

✅ Purpose: Ensure data confidentiality and integrity, in storage and transit.

🔒 Encryption Types:

• Symmetric (e.g., AES): One key used for encryption/decryption. Fast, efficient.
• Asymmetric (e.g., RSA): Public/private key pairs for secure exchange, authentication.
• Hybrid (e.g., TLS): Combines both for secure sessions.
• Hashing (e.g., SHA-2): Provides integrity, not confidentiality.

💡 Examples:

• HTTPS uses TLS (RSA + AES).
• Disk encryption uses AES-256.
• PGP/GPG protects sensitive emails.

4️⃣ Hardware Security Module (HSM)

✅ Purpose: Dedicated physical device for secure cryptographic key generation, protection, and processing.

🔐 Capabilities:

• Tamper-resistant key storage
• Secure certificate and digital signature processing
• Offloads crypto operations from hosts

💡 Example: Banks and payment processors use HSMs to protect keys used in card processing or SWIFT communications.

5️⃣ Secure Boot & Measured Boot

✅ Secure Boot: Ensures only signed and trusted firmware/OS components are loaded at startup.

✅ Measured Boot: Captures and records the hash of each component during boot for integrity validation via TPM.

💡 Example: On Windows, Secure Boot verifies UEFI and kernel drivers; Measured Boot ensures boot chain integrity.

6️⃣ Hardware Root of Trust

✅ Purpose: Establishes a trusted starting point at the hardware level, enabling verification of the bootloader and OS integrity.

💡 Examples:

• Intel Boot Guard
• AMD Platform Security Processor (PSP)

Used in environments requiring strong tamper protection and chain-of-trust validation.

7️⃣ Trusted Execution Environment (TEE)

✅ Purpose: A secure enclave within the CPU where code and data are isolated and protected during execution.

🔐 Features:

• Protected from OS and apps
• Used for biometrics, key storage, DRM, and mobile payments

💡 Examples:

• ARM TrustZone
• Intel SGX (Software Guard Extensions)

Used by smartphones and cloud providers for secure workloads.

8️⃣ Sandboxing

✅ Purpose: Run untrusted or semi-trusted code in restricted, isolated environments to prevent access to system resources.

💻 Applications:

• Web browsers (Chrome, Edge)
• Mobile OSs (Android, iOS)
• Application containers (Docker)

💡 Example: Each browser tab in Chrome runs in a sandbox to isolate crashes and limit exploit propagation.

9️⃣ Hypervisor Security (Virtualization Layer)

✅ Purpose: Enforces isolation between virtual machines (VMs) on the same hardware.

🔧 Types:

• Type 1 (bare-metal): Directly on hardware (e.g., VMware ESXi, Hyper-V)
• Type 2 (hosted): Runs on top of another OS (e.g., VirtualBox)

🔐 Security Features:

• Inter-VM isolation
• Encrypted VM snapshots
• Secure virtual networking

💡 Example: Cloud providers use hypervisors to isolate tenants in IaaS platforms.

🔟 Access Control Enforcement Mechanisms

✅ Purpose: Define and enforce who can access what resources, and how.

🔒 Models:

• Discretionary Access Control (DAC): File owners define access.
• Mandatory Access Control (MAC): Based on classification labels.
• Role-Based Access Control (RBAC): Permissions tied to job roles.
• Attribute-Based Access Control (ABAC): Uses policies and user attributes.

💡 Example: Linux systems use SELinux (MAC) to control daemon privileges beyond standard Unix permissions.

📊 Summary

3.5: Assess and Mitigate the Vulnerabilities of Security Architectures, Designs, and Solution Elements

🎯 Objective

To identify and mitigate vulnerabilities across a diverse set of system architectures and solution elements by applying secure design principles and security controls appropriate to each system type.

These systems include:

• Traditional IT (clients, servers, databases)
• Modern and emerging platforms (cloud, microservices, containers)
• Specialized systems (ICS, IoT, HPC, embedded)

🔍 Detailed Vulnerability Assessment & Mitigation by Architecture

1️⃣ Client-Based Systems

Common Risks:

• Local data leakage (unencrypted temp files)
• Keylogging and malware
• Insecure browser plugins
• Unpatched software vulnerabilities

Mitigation Strategies:

• Endpoint protection (EDR, anti-malware)
• Host-based firewalls and hardening
• Disk encryption (BitLocker, FileVault)
• Auto-update and patch management
• Least privilege with user separation (standard vs. admin accounts)

Real-World Example:
Corporate laptops configured with BitLocker, restricted USB access, and monitored using CrowdStrike Falcon.

2️⃣ Server-Based Systems

Common Risks:

• Misconfigured services and open ports
• OS-level vulnerabilities
• Weak admin authentication (e.g., exposed SSH)

Mitigation Strategies:

• Apply CIS hardening benchmarks
• Role separation and administrative boundaries
• Patch automation and configuration management (Ansible, Puppet)
• Multi-factor authentication (MFA) for remote access

Real-World Example:
Hardened Linux web servers configured with Fail2Ban, SELinux, and 2FA-enabled SSH.

3️⃣ Database Systems

Common Risks:

• SQL Injection
• Excessive privileges (over-permissioned accounts)
• Poor auditing/logging

Mitigation Strategies:

• Input validation and parameterized queries
• Database Activity Monitoring (DAM)
• RBAC/ABAC enforcement
• Encrypt data at rest and in transit

Real-World Example:
Secure PostgreSQL setup with pgAudit, TLS encryption, and access limited via roles.

4️⃣ Cryptographic Systems

Common Risks:

• Use of deprecated ciphers (MD5, RC4)
• Poor key lifecycle management
• Hardcoded keys or keys in plaintext

Mitigation Strategies:

• Use strong algorithms (AES-256, RSA 2048+, ECC)
• Employ HSMs or cloud KMS
• Rotate keys regularly; enforce expiration
• Implement certificate pinning and revocation checks

Real-World Example:
TLS 1.3 enforced on web servers with HSTS, AES-GCM encryption, and Let’s Encrypt automation.

5️⃣ Industrial Control Systems (ICS)

Common Risks:

• Legacy, unauthenticated protocols (Modbus, DNP3)
• No native encryption
• Flat networks (no segmentation)

Mitigation Strategies:

• Segment networks (zones and conduits)
• Use jump servers and unidirectional gateways
• Passive traffic monitoring
• Restrict USB and physical access

Real-World Example:
An energy utility segments its OT and IT networks and monitors ICS traffic using Nozomi Guardian.

6️⃣ Cloud-Based Systems (SaaS, IaaS, PaaS)

🟠 SaaS Risks:

• Shadow IT
• Inadequate data governance
• Multi-tenancy exposure

Mitigations:

• CASB for visibility
• SSO with MFA
• DLP & access control enforcement

🔵 IaaS Risks:

• Misconfigured buckets/firewalls
• VM snapshot exposure
• Weak IAM policies

Mitigations:

• Security groups and network ACLs
• IAM least privilege
• Cloud-native monitoring (AWS Config, Azure Defender)

🟣 PaaS Risks:

• Vulnerable libraries in code
• Misconfigured runtime environments

Mitigations:

• Secure coding & dependency scanning (e.g., Snyk)
• Isolated environments per tenant/app
• Runtime security controls

Real-World Example:
AWS Lambda with strict IAM, encrypted environment variables, and integrated GuardDuty alerting.

7️⃣ Distributed Systems

Common Risks:

• Insecure communication between nodes
• Lack of authentication or encryption
• Inconsistent configuration across nodes

Mitigation Strategies:

• Enforce mTLS for all services
• Apply zero trust principles
• Distributed logging and consistent state validation
• Consensus protocols (e.g., Raft) for integrity

Real-World Example:
A Kubernetes-based distributed app using SPIFFE identities and mTLS between pods.

8️⃣ Internet of Things (IoT)

Common Risks:

• Default/hardcoded passwords
• Lack of firmware updates
• No encryption or authentication

Mitigation Strategies:

• Require strong authentication
• Signed firmware and OTA updates
• Encrypted data transfer
• Network segmentation per device class

Real-World Example:
Smart home hubs using certificate-based authentication and encrypted MQTT communication.

9️⃣ Microservices / APIs

Common Risks:

• API abuse (excessive access, lack of auth)
• Insecure inter-service communications
• Lack of throttling or validation

Mitigation Strategies:

• Use OAuth 2.0 / JWT for access control
• API gateways with rate limiting and logging
• Enforce input/output validation (OpenAPI)

Real-World Example:
REST APIs behind AWS API Gateway, integrated with Cognito for auth and CloudWatch for logs.

🔟 Containerization

Common Risks:

• Container escape to host
• Over-permissioned containers (e.g., root)
• Insecure images

Mitigation Strategies:

• Use signed, scanned images
• Drop root privileges in Docker
• Enforce runtime controls (Seccomp, AppArmor)

Real-World Example:
Containers scanned with Trivy, run as non-root, and isolated using PodSecurityPolicies.

1️⃣1️⃣ Serverless

Common Risks:

• Over-scoped permissions
• Trigger abuse (e.g., S3 events)
• No input sanitation

Mitigation Strategies:

• IAM scoping per function
• Event source validation
• Logging, throttling, structured exception handling

Real-World Example:
GCP Cloud Functions limited by least privilege and validated by Cloud Endpoints.

1️⃣2️⃣ Embedded Systems

Common Risks:

• Static credentials
• Inability to patch/update
• Limited crypto or logging

Mitigation Strategies:

• Design for OTA updates and rollback
• Secure boot and signed firmware
• Simplified code base with memory safety

Real-World Example:
Medical device using ARM TrustZone and signed firmware for integrity.

1️⃣3️⃣ High-Performance Computing (HPC) Systems

Common Risks:

• Shared memory risks
• Weak tenant isolation
• Research or IP theft

Mitigation Strategies:

• Job-based RBAC
• Disk/network encryption
• Strong tenant segmentation

Real-World Example:
University HPC clusters using Slurm scheduler with user quotas and encryption of scratch space.

1️⃣4️⃣ Edge Computing Systems

Common Risks:

• Physical tampering
• Latency in policy enforcement
• Limited local logging/storage

Mitigation Strategies:

• Tamper-resistant hardware
• Remote attestation and device health checks
• Synchronize edge-to-core policies securely

Real-World Example:
Retail kiosks using Intel TPM, auto-patching, and encrypted disk for offline operation.

 1️⃣5️⃣ Virtualized Systems

Common Risks:

• VM escape
• Host compromise
• Unmonitored internal traffic

Mitigation Strategies:

• Hypervisor patching
• VM isolation (vSwitch, VLAN)
• Secure snapshots & disk encryption
• Monitor east-west traffic (virtual firewalls)

Real-World Example:
Enterprise uses VMware NSX to inspect VM traffic and isolate PCI-compliant systems.

📌 Summary

📘 Final CISSP Study Tips

3.1

• Design principles are scenario-based in the exam — know how to apply them.
• Understand trade-offs: security vs. usability, cost vs. protection.
• Expect questions about cloud models, identity verification, and access control.
• Pair this with threat modeling methods and architecture frameworks (TOGAF, SABSA) for complete preparation

3.2

• BLP = Confidentiality, Biba = Integrity. Easy to confuse—memorize by function.
• Know the difference between static models (BLP, Biba) and dynamic models (Brewer-Nash).
• Clark-Wilson focuses on business rules, not classifications.

3.3

• Understand how to choose controls based on the risk, asset type, and security objective
• Know the difference between preventive, detective, corrective, and compensating
• Expect scenario questions where you must select the most effective or feasible control
• Be familiar with control frameworks like NIST, ISO, and CIS

3.4

• Understand the difference between hardware and software controls (e.g., TPM vs. sandboxing)
• Match capabilities to goals (e.g., confidentiality → encryption, integrity → TPM)
• Know where and how controls like TPM, HSM, TEE fit into system architecture
• Expect scenario-based questions where you’re asked to secure boot processes or key storage

3.5

• Understand which threats map to which architecture
• Know specific mitigations for modern platforms (cloud, containers, APIs)
• Pay attention to legacy vs. modern attack surfaces
• Focus on real-world risks like misconfigurations, access control gaps, or lack of encryption