Legacy Haven University

Category: Uncategorized

  • Threat Modeling with MITRE ATT&CK, STRIDE, and the Diamond Model: A CAS-005 Study Guide

    Threat Modeling with MITRE ATT&CK, STRIDE, and the Diamond Model: A CAS-005 Study Guide

    Threat Modeling with MITRE ATT&CK, STRIDE, and the Diamond Model: A CAS-005 Study Guide

    Threat modeling is a core skill for senior security architects and analysts, and it appears across multiple CompTIA CASP+ CAS-005 domains, including Enterprise Security Architecture, Enterprise Security Operations, and Governance, Risk, and Compliance (GRC).[1][2] For CAS-005, you’re expected to reason about attacker behavior, system design, and compensating controls in complex, hybrid environments—not just memorize definitions.[2]

    This guide shows how to combine MITRE ATT&CK, STRIDE, and the Diamond Model of Intrusion Analysis into a practical, exam-ready threat modeling workflow you can reuse for PBQs and real-world design reviews.[3][4][5]

    TL;DR

    Use MITRE ATT&CK to understand how adversaries operate, STRIDE to systematically enumerate what can go wrong in your design, and the Diamond Model to analyze who, why, and how incidents unfold over time.[3][4][5] For CAS-005, you’ll see these ideas in architecture PBQs, incident response scenarios, and risk-based control selection questions.[2]

    1. Where Threat Modeling Fits in CAS-005

    CompTIA CASP+ (CAS-005) emphasizes risk-driven security architecture and operations across on-premises, cloud, and hybrid environments.[1][2] The official objectives reference threat modeling, adversary tactics, kill chains, and security architecture decisions that balance business and technical constraints.[1][2]

    Threat modeling in the CAS-005 context usually appears as:

    • Design PBQs where you must choose or justify controls for a given architecture.
    • Incident response or threat hunting scenarios that reference attacker behavior patterns.
    • Risk management questions that ask you to prioritize mitigations based on impact and likelihood.[1][2]

    Frameworks like MITRE ATT&CK, STRIDE, and the Diamond Model give you structured ways to think through these problems and defend your answers.[3][4][5]

    2. Quick Overview of the Three Frameworks

    Before we build a combined workflow, you need a crisp mental model of each framework.

    2.1 MITRE ATT&CK: Encyclopedia of Adversary Behavior

    MITRE ATT&CK is a globally accessible knowledge base of adversary tactics, techniques, and procedures (TTPs) based on real-world observations.[3] It organizes behavior into matrices (Enterprise, Mobile, ICS) with columns representing tactics (goals, like Initial Access, Privilege Escalation) and rows representing techniques (how attackers achieve those goals).[3]

    • Tactics = high-level objectives (e.g., Initial Access, Execution, Exfiltration).
    • Techniques/Sub-techniques = concrete methods (e.g., Phishing, Command and Scripting Interpreter, Ingress Tool Transfer).[3]
    • Each technique has example procedures, detection ideas, and mitigations.[3]

    For CAS-005, ATT&CK helps you:

    • Map attacker behavior to specific controls (e.g., EDR, application control, segmentation).[2][3]
    • Support incident response playbooks and threat hunting hypotheses.[3]
    • Explain “why this control here” in architecture and PBQ scenarios.[2][3]
    MITRE ATT&CK matrix used for threat modeling MITRE ATT&CK STRIDE Diamond Model
    ATT&CK matrix snippet annotated with a few techniques and controls.

    2.2 STRIDE: Systematic Design-Time Threat Enumeration

    STRIDE is a Microsoft-developed mnemonic for classifying application and system threats into six categories:[4]

    • Spoofing identity
    • Tampering with data
    • Repudiation (denying actions)
    • Information disclosure
    • Denial of service
    • Elevation of privilege[4]

    STRIDE is usually applied to data flow diagrams (DFDs) or architecture diagrams: for each element (process, data store, external entity, data flow), you ask, “What STRIDE threats apply here?”[4]

    For CAS-005, STRIDE is useful when you’re asked to:

    • Review a proposed architecture and identify the most likely threat type.
    • Choose mitigations for specific STRIDE categories (e.g., authentication for spoofing, integrity checks for tampering).[2][4]
    • Explain how logging, non-repudiation, and access control reduce risk.[1][2][4]

    2.3 Diamond Model: Analyzing Intrusions as Connected Events

    The Diamond Model of Intrusion Analysis describes each intrusion event as a relationship between four core features:[5]

    • Adversary – the threat actor (individual, group, organization).
    • Infrastructure – the systems and services used to deliver, control, or execute the attack (C2 servers, domains, cloud resources).
    • Capability – tools, malware, exploits, and techniques the adversary uses.
    • Victim – the target organization, system, or user.[5]

    The model also includes meta-features such as timestamp, phase, result, and methodology, and defines axioms about how intrusions evolve over time.[5]

    For CAS-005, the Diamond Model helps you:

    • Think like a threat intelligence analyst when correlating events across logs and tools.[5]
    • Identify opportunities to disrupt the adversary at different points (infrastructure takedown, tool detection, user training).[5]
    • Explain kill chains and campaign analysis in incident response scenarios.[1][2][5]
    Diamond Model of Intrusion Analysis diagram for threat modeling MITRE ATT&CK STRIDE Diamond Model
    Diamond Model of Intrusion Analysis diagram for threat modeling MITRE ATT&CK STRIDE Diamond Model

    3. When to Use Which Framework

    In practice—and on CAS-005—you rarely use just one framework. Each shines at a different point in the lifecycle.

    • STRIDE – best at design time for systematically thinking through what can go wrong in your architecture.[4]
    • MITRE ATT&CK – best for operational and detection-focused modeling, mapping attacker behavior to controls and telemetry.[3]
    • Diamond Model – best for incident and campaign analysis, tying together multiple events and understanding the adversary.[5]

    For the exam, you should be able to:

    • Identify which framework is most appropriate for a given scenario.
    • Explain how you would combine them into a repeatable threat modeling workflow.[1][2]

    4. Step-by-Step Threat Modeling Workflow (Combining All Three)

    This section gives you a practical, repeatable workflow that aligns well with CAS-005 architecture and operations objectives.[1][2] You can adapt it to PBQs, tabletop exercises, or real system designs.

    Step 1: Define the Scope, Assets, and Business Goals

    Start with the basics: what system or workflow are you modeling, and why does it matter? CAS-005 expects you to tie security decisions to business objectives and risk appetite.[1][2]

    • Identify critical assets (data, services, identities).
    • Clarify business processes (e.g., customer portal login, payment processing).
    • Note constraints (compliance, uptime SLAs, budget, legacy systems).[1][2]

    On the exam, this often shows up as a paragraph of business context before the technical question. Don’t skip it—your threat model should reflect what the organization actually cares about.[1][2]

    Step 2: Draw a Simple Data Flow / Architecture Diagram

    You don’t need an art degree. CAS-005 cares that you understand trust boundaries, data flows, and dependencies, not that your diagram is pretty.[2]

    • Identify external entities (users, third parties).
    • Mark processes (web app, API gateway, auth service).
    • Show data stores (databases, queues, object storage).
    • Draw data flows and trust boundaries (internal vs external networks, cloud vs on-prem).[4]

    This diagram becomes the substrate for STRIDE.

    Step 3: Apply STRIDE to Each Element

    Now walk each element and ask how the STRIDE categories apply.[4]

    • Spoofing: Can an attacker pretend to be a user, service, or component? (Think: weak auth, missing mutual TLS.)
    • Tampering: Can they alter data in transit or at rest? (Think: lack of integrity checks, insecure deserialization.)
    • Repudiation: Could they deny actions due to missing logs or signatures?
    • Information disclosure: Where might sensitive data leak?
    • Denial of service: What could attackers flood, exhaust, or lock?
    • Elevation of privilege: Are there paths to gain more access than intended?[4]

    Capture threats in a simple table, for example:

    Web app process – STRIDE example:

    • Spoofing: Credential stuffing against login endpoint.
    • Tampering: Manipulating JWT tokens if not signed/validated properly.
    • Repudiation: Lack of audit logs for admin actions.
    • Information disclosure: Verbose error messages exposing stack traces.
    • Denial of service: Application-level DoS via expensive search queries.
    • Elevation of privilege: Insecure direct object references (IDOR) in admin APIs.[4]

    For CAS-005, you don’t have to label everything formally as STRIDE on the exam, but this mental checklist helps you avoid missing obvious issues.

    Step 4: Layer in MITRE ATT&CK to Ground Threats in Real TTPs

    Once you have a list of potential threats, use MITRE ATT&CK to make them concrete and map them to detection and mitigation options.[3]

    • Identify relevant tactics (e.g., Initial Access, Persistence, Lateral Movement).[3]
    • Pick representative techniques that match your STRIDE threats (e.g., phishing for spoofing, credential dumping for elevation of privilege).[3]
    • Note ATT&CK’s suggested mitigations and detections for those techniques.[3]

    Example mapping:

    • Spoofing via credential stuffing → ATT&CK Credential Access tactics and techniques such as Brute Force and Valid Accounts → mitigations: MFA, strong password policies, anomaly detection.[3]
    • Information disclosure via misconfigured S3 bucket → ATT&CK Exfiltration and Initial Access techniques → mitigations: least privilege IAM, configuration scanning, data classification.[3]

    On CAS-005, using ATT&CK thinking helps you justify why a particular control or log source is the best answer among plausible options.[2][3]

    Step 5: Use the Diamond Model to Think in Campaigns, Not Single Events

    Now zoom out. The Diamond Model encourages you to see each event as part of a larger intrusion campaign with multiple linked diamonds over time.[5]

    • Who is the adversary (or type of adversary)? What are their likely objectives?
    • What infrastructure do they use (cloud accounts, domains, VPNs, residential proxies)?
    • What capabilities (malware, tools, ATT&CK techniques) are in play?
    • Who/what is the victim and what is the business impact?[5]

    This perspective is especially useful for CAS-005 questions around:

    • Threat intelligence program design.
    • Incident response playbook development.
    • Prioritizing mitigations that disrupt the adversary with minimal business impact.[1][2][5]

    For example, if you know a particular threat group repeatedly reuses the same cloud provider and domain registration patterns, you can design controls and monitoring focused on that infrastructure—an insight that flows directly from the Diamond Model.[5]

    Step 6: Prioritize and Select Controls

    Finally, choose mitigations that balance risk reduction, cost, and usability—a core CAS-005 skill.[1][2]

    • Use STRIDE to ensure you have coverage for all threat categories at critical components.
    • Use ATT&CK to ensure controls map to real attacker techniques and can be monitored.[3]
    • Use the Diamond Model to focus on controls that disrupt the adversary’s preferred infrastructure and capabilities.[5]

    This is where exam questions often ask, “Which control provides the most effective mitigation for the described threat?” The best answer usually aligns with the dominant ATT&CK techniques and the business context described.[2][3]

    5. Worked Example: CAS-005-Style Scenario

    Let’s walk through a simplified scenario that mirrors CAS-005 exam style.

    Scenario: You’re designing security for a customer-facing SaaS portal hosted in a public cloud. Users authenticate via SSO (OIDC), the app talks to microservices over an internal API gateway, and data is stored in a managed database and object storage. The organization has suffered credential stuffing attacks and a previous data exposure from a misconfigured storage bucket.[1][2]

    Step A: STRIDE on Key Components

    Consider three focal points: login endpoint, API gateway, and object storage.

    • Login endpoint:
      • Spoofing – credential stuffing, phishing against SSO.
      • Repudiation – weak logging around login attempts.
      • DoS – automated login attempts causing resource exhaustion.[4]
    • API gateway:
      • Tampering – manipulating JWTs or headers if not validated.
      • Information disclosure – verbose error messages, weak access control on internal APIs.[4]
    • Object storage:
      • Information disclosure – public buckets, overly permissive IAM policies.
      • Tampering – unauthorized modification of stored objects.[4]

    Step B: Map to MITRE ATT&CK Techniques

    Next, map these to representative ATT&CK techniques:[3]

    • Credential stuffing → Brute Force and Valid Accounts under Credential Access.[3]
    • Misconfigured object storage → Exfiltration via cloud storage under Exfiltration and Initial Access.[3]
    • Manipulated tokens → Abuse of authentication tokens and web session hijacking techniques (Execution/Credential Access).[3]

    From ATT&CK’s mitigations, you’d highlight:

    • MFA and risk-based authentication for login.
    • Rate limiting and anomaly detection on login endpoints.
    • Least privilege IAM and configuration scanning for storage.
    • Strong token signing, validation, and rotation for API security.[3]

    Step C: Use the Diamond Model to Think Like an Adversary

    Now frame the attack using the Diamond Model:[5]

    • Adversary: financially motivated group targeting SaaS logins and data exfiltration.
    • Infrastructure: botnets, credential stuffing tools, cloud-based proxies, throwaway email accounts.
    • Capability: large credential dumps, automation frameworks, scripts targeting known SaaS APIs.
    • Victim: your SaaS platform, specifically login and storage systems containing customer data.[5]

    This lens suggests additional controls:

    • Blocking or challenging traffic from known bad IP ranges or ASNs.
    • Monitoring for unusual login patterns (geolocation, device fingerprinting).
    • Threat intelligence feeds to detect reused infrastructure across campaigns.[5]

    Step D: Prioritize Controls – Exam-Style Reasoning

    In a CAS-005 question, you might be asked: “Which control most effectively reduces the risk of the described attacks while minimizing user friction?”

    Given your threat model, the strongest primary answer is usually:

    • Enforce adaptive MFA and implement credential stuffing protections at the identity provider and WAF/API gateway (mitigates spoofing and ATT&CK brute-force techniques).[2][3][4]

    Secondary but still important answers might add:

    • Automated configuration scanning and least-privilege IAM for storage.
    • Centralized logging and analytics mapped to ATT&CK tactics.[1][3]

    On the exam, think: “Which option best addresses the current stage of the attack, given the described techniques and business constraints?”

    6. How CAS-005 Tests Threat Modeling Skills

    CompTIA’s CAS-005 objectives include performance-based items and scenario-driven questions that require you to apply threat modeling concepts in context.[1][2] You won’t see “draw a STRIDE table” directly, but you will see its spirit.

    6.1 Common Question Patterns

    • Architecture review: Given a diagram and requirements, identify the most likely threat or the best control to add.
    • Incident reconstruction: Given log snippets and indicators, sequence events and identify what the attacker is trying to do next (Diamond Model + ATT&CK).[1][3][5]
    • Control justification: Choose between multiple controls and justify which better mitigates specific TTPs or STRIDE threats.[2][3][4]

    6.2 What You Should Be Able to Do

    • Explain, in plain language, when to use ATT&CK vs STRIDE vs the Diamond Model.
    • Map a described attack to a sequence of ATT&CK tactics and techniques and propose detections.[3]
    • Run a quick, mental STRIDE pass over a small architecture and identify missing controls.[4]
    • Describe how threat intelligence and campaign analysis (Diamond Model) inform architecture and operations decisions.[1][2][5]

    7. Practical Study Plan: Building Threat Modeling Muscle for CAS-005

    To make this stick, you need practice—not just reading. Here’s a focused plan.

    7.1 Week 1–2: Fundamentals and Vocabulary

    • Read MITRE’s “Getting Started with ATT&CK” and browse the Enterprise matrix.[3]
    • Review Microsoft’s STRIDE documentation and example threat models.[4]
    • Skim the original Diamond Model paper’s introduction and core concepts.[5]
    • Cross-reference CAS-005 objectives that mention threat modeling, adversary tactics, and incident analysis.[1][2]

    7.2 Week 3–4: Apply to Two Real Systems

    • Pick two systems you know well (e.g., VPN access, an internal web app, or an API).
    • Draw a simple DFD and run a STRIDE pass for each.[4]
    • Identify 5–10 relevant ATT&CK techniques and explicit mitigations.[3]
    • Write a short Diamond Model-style intrusion story for each system (who, what, how, why, and impact).[5]

    7.3 Week 5+: Practice Exam-Style Reasoning

    • Take CAS-005 practice questions and rewrite the scenario as a mini threat model.
    • For each wrong answer, ask, “Which STRIDE threat or ATT&CK technique did I overlook?”
    • For IR scenarios, sketch a quick Diamond Model to see what you missed.[1][2][3][5]

    Integrate this with broader CAS-005 prep around zero trust, cloud security, and incident response.[1][2][3] For example, when you study zero trust, explicitly map controls to ATT&CK techniques and STRIDE threats on your high-value assets.

    8. Key Takeaways for the CAS-005 Exam and Your Day Job

    Threat modeling with MITRE ATT&CK, STRIDE, and the Diamond Model is not academic theory—it’s how senior practitioners and exam writers structure their thinking.[1][2][3][4][5]

    • Use STRIDE to systematically find design flaws and missing controls in architectures.[4]
    • Use MITRE ATT&CK to ground threats in real TTPs and choose effective detections and mitigations.[3]
    • Use the Diamond Model to understand intrusions over time and design defenses that disrupt entire campaigns.[5]
    • For CAS-005, practice applying all three in time-limited, scenario-driven questions.[1][2]

    If you can explain your architecture and incident response decisions using these frameworks, you’ll be in a strong position both for the CAS-005 exam and for leading threat modeling sessions in your organization.[1][2][3][4][5]

    Bibliography

    1. CompTIA. (2023). CompTIA CASP+ (CAS-005) certification exam objectives [Certification exam objectives]. CompTIA. https://www.comptia.org/certifications/casp
    2. CompTIA. (n.d.). CompTIA CASP+ certification. CompTIA. https://www.comptia.org/certifications/casp
    3. MITRE Corporation. (2019). Getting started with ATT&CK (Rev. 1.0) [White paper]. MITRE. https://attack.mitre.org/resources/
    4. Microsoft. (n.d.). Microsoft threat modeling tool and STRIDE model [Documentation]. Microsoft Learn. https://learn.microsoft.com/en-us/azure/security/develop/threat-modeling-tool-threats
    5. Caltagirone, S., Pendergast, A., & Betz, C. (2013). The Diamond Model of Intrusion Analysis [Technical report]. Center for Cyber Intelligence Analysis and Threat Research. https://apps.dtic.mil/sti/citations/ADA586960
  • Cloud Security for SecurityX: CASB, Shadow IT, Shared Responsibility, and Container Orchestration

    Cloud Security for SecurityX: CASB, Shadow IT, Shared Responsibility, and Container Orchestration



    Cloud Security for SecurityX: CASB, Shadow IT, Shared Responsibility, and Container Orchestration

    Cloud security SecurityX is more than memorizing SaaS acronyms. For the CAS-005 exam, you’re expected to design and justify cloud architectures that use CASB, control shadow IT, respect shared responsibility, and secure container orchestration platforms like Kubernetes across multi-cloud and hybrid environments.[1][2]

    This tutorial ties those threads together so you can reason through performance-based questions (PBQs) and real-world designs, not just recall definitions.

    TL;DR

    CAS-005 expects you to secure cloud workloads end-to-end: SaaS usage via CASB, unsanctioned apps as shadow IT, shared responsibility splits with providers, and containerized workloads orchestrated at scale.[1][2] You’ll see this as architecture trade-offs: where to put controls, which tool to choose, and how to enforce policy without killing agility.

    1. How Cloud Security Shows Up on SecurityX (CAS-005)

    CompTIA’s CAS-005 objectives emphasize advanced security architecture, cloud capabilities, and operations across on-prem, public cloud, and hybrid environments.[2] Cloud topics are spread across domains such as:

    • Security architecture and engineering for cloud and hybrid designs
    • Governance, risk, and compliance (including third-party and cloud provider risk)
    • Security operations and incident response in cloud-native environments

    Within that, four recurring themes form a “cloud security SecurityX” cluster that exam writers love to mix into scenarios:[1][2]

    • CASB (Cloud Access Security Broker) for SaaS and cloud visibility
    • Shadow IT as the driver for risk and control gaps
    • Shared responsibility as the basis for “who owns what” in cloud security
    • Container orchestration (e.g., Kubernetes) as the modern way to run workloads

    Understanding how these pieces interact is more exam-relevant than treating them as isolated buzzwords.

    2. CASB: Your Control Point for SaaS and Cloud Access

    A Cloud Access Security Broker (CASB) sits between your users and cloud services to enforce security policies such as access control, data protection, and threat detection.[4] Think of it as an application-aware proxy that understands modern SaaS APIs, not just IPs and ports.

    2.1 Core CASB capabilities you must know for SecurityX

    Across vendor definitions, CASBs typically provide:[4]

    • Discovery – Identifying all cloud apps in use via logs (e.g., proxy, firewall) or endpoint agents to surface shadow IT.
    • Access control – Enforcing policies by user, group, device posture, location, and risk level (inline or via API).[4]
    • Data protection – Integrating DLP to detect and block sensitive data uploads, sharing, or downloads.
    • Threat protection – Detecting anomalous behavior, compromised accounts, and malware in cloud storage.[4]
    • Compliance reporting – Mapping usage and controls to frameworks like NIST CSF and ISO/IEC 27001.[3]

    On CAS-005, CASB often appears in options alongside secure web gateway (SWG), VPN, ZTNA, and SASE. Your job is to recognize when CASB is the right answer because you need app-level visibility and control over SaaS, rather than just network tunnel protection.[1][2]

    2.2 CASB deployment patterns

    Common deployment modes:[4]

    • Proxy (forward/reverse) – Routes traffic through CASB to inspect and enforce policy in real time.
    • API-based – Connects directly to SaaS APIs (e.g., Microsoft 365, Salesforce) to inspect data at rest and user activity.
    • Log-based – Analyzes firewall/proxy logs to discover cloud app usage and risk.

    For exam scenarios:

    • Choose API-based CASB when you need to scan historical data in SaaS (e.g., find sensitive files already shared externally).
    • Choose proxy CASB when you need inline control (e.g., block uploads of PCI data to unsanctioned storage).
    • Choose log-based discovery when the organization is just starting to tackle shadow IT across multiple regions.

    This aligns with NIST CSF’s focus on identifying assets and data flows before you protect them.[3]

    cloud security SecurityX CASB architecture diagram
    Diagram of CASB sitting between users and multiple SaaS apps, showing discovery, DLP, and access control flows.

    3. Shadow IT: Why CASB Matters

    Shadow IT is the use of hardware, software, or services without formal IT approval. In the cloud era, this is dominated by unsanctioned SaaS and cloud services adopted by business teams for convenience.[5][6]

    Studies consistently show that IT departments remain unaware of a significant portion of SaaS applications in use—roughly one-third in some surveys—and that more than 40% of employees acquire or build tools outside IT’s visibility.[5] Other industry reports estimate that a large majority of employees use at least some shadow IT.[6]

    3.1 Shadow IT risks you should call out in answers

    • Data leakage – Sensitive data lands in personal accounts or low-assurance SaaS providers without DLP or legal review.[5][6]
    • Compliance violations – Tools may not meet regulatory requirements (e.g., data residency, logging, encryption).
    • Identity and access gaps – No SSO or MFA; access persists after employees leave.
    • Incident response blind spots – Logs and telemetry from unsanctioned tools are missing from SIEM and IR playbooks.

    On CAS-005, a classic scenario is: “Users are adopting unsanctioned SaaS. Which control best addresses this with minimal friction?” The best answer usually combines:

    • Cloud app discovery via CASB or firewall logs
    • Risk classification of apps
    • Policy: block high-risk apps, coach users to approved alternatives, and integrate with SSO

    3.2 Using CASB to tame shadow IT

    CASB and shadow IT mitigation flow together:[4][5]

    • Feed firewall/proxy logs into CASB for discovery.
    • Rate each app by risk: certifications, encryption, location, admin controls.
    • Define sanctioned, tolerated, and blocked app categories.
    • Apply inline controls (block, coach, read-only) based on categories.
    • Integrate with SSO/MFA and endpoint posture checks.

    When pairing this with shared responsibility, note that even if a SaaS provider secures their infrastructure, you’re still responsible for approving the service, configuring it securely, and governing data placed in it.[7]

    4. Shared Responsibility: Who Owns What in Cloud Security?

    The shared responsibility model formalizes how security duties are split between cloud providers and customers. Major cloud providers all publish versions of this model; in broad terms:[7]

    • The provider secures the underlying infrastructure (physical data centers, hardware, hypervisors, core services).
    • The customer secures data, identities, configurations, and (for IaaS/PaaS) the workloads they deploy.[7]

    The U.S. Department of Defense and other agencies also stress that effective cloud security depends on understanding and honoring these boundaries.[7]

    4.1 Shared responsibility by service model

    • IaaS: You manage OS hardening, patching, network security controls, and application security. Provider manages physical, host, and core network infrastructure.[7]
    • PaaS: Provider manages more of the stack (OS, runtime); you manage application code, data, and identity.
    • SaaS: Provider manages the full application; you manage data classification, user access, and configuration (e.g., sharing settings, retention, MFA).[7]

    On the exam, shared responsibility questions often hide inside incident or misconfiguration scenarios:

    • Data breach due to misconfigured storage bucket => customer misconfiguration, not provider infrastructure failure.
    • Outage of a cloud region => provider issue; customer must design for resilience (multi-region, backups).
    • Exposed admin interface on a VM => customer’s job to harden OS and network security groups.

    4.2 Mapping CASB and shadow IT into shared responsibility

    CASB and shadow IT controls live squarely on the customer’s side of the model:[4][5][7]

    • Choosing which SaaS apps meet your compliance and security requirements.
    • Enforcing access control, DLP, and logging via CASB and IdP.
    • Monitoring usage and revoking access when people leave.

    For SecurityX answers, emphasize that cloud providers can’t protect you from apps you haven’t even inventoried, nor from poor configuration choices inside your tenant.[2][3][7]

    5. Container Orchestration Security: From NIST SP 800-190 to NSA/CISA Kubernetes Guidance

    Modern cloud workloads often run in containers orchestrated by platforms like Kubernetes. NIST SP 800-190, the Application Container Security Guide, outlines risks and mitigations across container images, registries, orchestration platforms, and the underlying host infrastructure.[1]

    NSA and CISA’s Kubernetes Hardening Guide further details best practices for securing clusters, including role-based access control, network policies, and hardening the control plane and worker nodes.[8]

    5.1 Threats and attack surface in containerized environments

    NIST SP 800-190 describes container risk areas such as:[1]

    • Image vulnerabilities – Outdated or unpatched software in container images, especially base images pulled from public registries.[1]
    • Registry compromise – Malicious or tampered images hosted in registries.[1]
    • Runtime escape and lateral movement – Exploits that break out of a container to the host, then move across the cluster.[1]
    • Orchestrator misconfiguration – Over-privileged service accounts, unauthenticated dashboards, or exposed APIs.[1][8]
    • Network exposure – Overly permissive network policies allowing unrestricted pod-to-pod communication.[8]

    NSA/CISA warn that misconfigured Kubernetes clusters are attractive targets and provide detailed hardening recommendations, such as disabling anonymous access to the API server and enforcing RBAC.[8]

    5.2 Core container orchestration security controls

    • Secure base images and registries – Use trusted base images, scan them for vulnerabilities in CI/CD, and restrict pulls to approved registries.[1]
    • Least privilege and isolation – Use namespaces, RBAC, and Pod Security/Pod Security Admission controls to limit capabilities.[1][8]
    • Network segmentation – Apply Kubernetes NetworkPolicies to restrict traffic between pods and namespaces.[8]
    • Secrets management – Store secrets securely (e.g., KMS-backed secrets) instead of environment variables or images.[1][8]
    • Logging and monitoring – Centralize logs from containers, nodes, and the control plane into a SIEM for detection.[1][8]

    These map well to NIST CSF functions: Identify images and components, Protect via hardening, Detect anomalies, Respond to incidents, and Recover via redeployment from known-good images.[3]

    cloud security SecurityX container orchestration Kubernetes hardening
    Diagram of a Kubernetes cluster showing nodes, pods, network policies, and a CI/CD pipeline doing image scanning.

    6. Connecting CASB, Shadow IT, Shared Responsibility, and Containers in One Design

    SecurityX PBQs often require you to design or improve an architecture that spans SaaS, IaaS/PaaS, and containerized workloads. Here is a pattern you can reuse in your reasoning.

    6.1 Scenario: Hybrid enterprise with SaaS and Kubernetes

    Assume the following environment:

    • Employees use sanctioned SaaS (Microsoft 365, Salesforce) and unsanctioned tools.
    • Core line-of-business services run in containers on a managed Kubernetes service in a public cloud.
    • Developers sometimes bypass IT to use new SaaS CI/CD tools (shadow IT).
    • The organization is subject to regulatory requirements and follows NIST CSF.

    6.2 Target architecture decisions

    • CASB for SaaS: Deploy CASB with log-based discovery first, then move to inline and API-based controls for high-risk or high-value SaaS.[4][5]
    • Shadow IT policy: Use CASB reports to classify apps; update acceptable use and cloud procurement policies to require security review.
    • Shared responsibility mapping: Document responsibilities per service type (IaaS, PaaS, SaaS) so teams know who owns patching, IAM, logging, and backup.[7]
    • Kubernetes hardening: Follow NIST SP 800-190 and NSA/CISA guidance—harden nodes, restrict cluster admin, enforce RBAC and network policies, and scan images in CI/CD.[1][8]
    • Central monitoring: Ingest CASB logs, cloud-native logs, and Kubernetes audit logs into a SIEM to support detection and incident response.[1][3][8]

    When you see an exam item mixing these elements, the “best” answer usually:

    • Uses CASB for SaaS visibility and control instead of trying to bolt on traditional firewalls alone.
    • Explicitly references shared responsibility to assign patching and configuration ownership correctly.[7]
    • Applies container and orchestrator hardening guidance from NIST SP 800-190 and NSA/CISA rather than treating containers like VMs.[1][8]
    • Aligns with NIST CSF by showing you’ve thought about the full lifecycle, not just a point control.[3]

    7. Exam-Style Design and PBQ Tips for Cloud Security SecurityX

    Use these patterns when approaching SecurityX exam questions about cloud security.[2][3]

    7.1 When the question is about SaaS data leakage

    • Think CASB + DLP + SSO/MFA.
    • Leverage API-based CASB to remediate data already stored in SaaS.
    • Apply shared responsibility: you own user access, sharing policies, and data classification.[7]

    7.2 When the question is about shadow IT visibility

    • Start with discovery (CASB log analysis or network logs).
    • Classify apps, then implement coaching or blocking policies.
    • Update governance (policies, procurement processes) to reduce future shadow IT.[3][5]

    7.3 When the question is about container security

    • Cite NIST SP 800-190 for container security practices.[1]
    • Cite NSA/CISA Kubernetes Hardening Guide for cluster and network hardening.[8]
    • Emphasize CI/CD scanning, least privilege, network policies, and secure registries.[1][8]

    7.4 When the question is about “who is responsible?”

    • Map the scenario to IaaS/PaaS/SaaS.
    • Apply the shared responsibility model plus internal governance: cloud provider vs. customer vs. business owner.[7][3]
    • Connect back to CAS-005’s emphasis on governance, roles, and accountability.[2][3]

    8. Cloud Security SecurityX Study Plan: How to Practice These Skills

    To translate this into exam and job performance, build a focused mini-lab and study routine.

    8.1 Hands-on practice ideas

    • Set up a free-tier SaaS tenant and experiment with CASB discovery and policies (even screenshots or vendor labs help).
    • List all SaaS apps used in your current team; categorize them as sanctioned/unsanctioned and assess risk.
    • Deploy a test managed Kubernetes cluster; practice applying basic RBAC, NetworkPolicies, and image scanning with open-source tools.[1][8]
    • Create a one-page shared responsibility matrix for a real application stack you work with.

    8.2 Mapping to SecurityX/CAS-005 objectives

    As you practice, link everything back to CAS-005 domains so you’re not just tinkering:[2][3]

    • Governance, risk, and compliance: Shared responsibility, shadow IT policies, third-party risk.[2][3][7]
    • Security architecture: CASB placement, cloud network segmentation, container orchestration design.[1][2][8]
    • Security engineering and operations: CI/CD pipeline security, logging, monitoring, and incident response in cloud-native stacks.[1][2][3][8]

    9. Key Takeaways and How to Use Them on the Exam

    Cloud security SecurityX is about integrated design, not isolated controls:

    • Use CASB to discover and control SaaS, especially when shadow IT is present.[4][5]
    • Treat shadow IT as a governance and risk problem; discovery, classification, and policy are your primary tools.[5][6]
    • Always reason from the shared responsibility model to assign accountability correctly across cloud provider, security team, and business owners.[7][3]
    • Secure container orchestration with guidance from NIST SP 800-190 and NSA/CISA Kubernetes Hardening, focusing on images, orchestration, and runtime.[1][8]
    • Frame answers in terms of NIST CSF functions and CAS-005 domains to show complete lifecycle thinking.[2][3]

    If you can consistently connect CASB, shadow IT, shared responsibility, and container orchestration in your mental model, you’ll be better prepared for CAS-005 PBQs and for securing real-world cloud environments.

    Bibliography

    1. National Institute of Standards and Technology. (2017). *NIST Special Publication 800-190: Application container security guide*. U.S. Department of Commerce. https://doi.org/10.6028/NIST.SP.800-190
    2. CompTIA. (2023). *CompTIA CASP+ (CAS-005) certification exam objectives* [Certification exam objectives]. CompTIA. https://www.comptia.org/certifications/casp
    3. National Institute of Standards and Technology. (2018). *Framework for improving critical infrastructure cybersecurity* (Version 1.1) [NIST Cybersecurity Framework]. U.S. Department of Commerce. https://doi.org/10.6028/NIST.CSWP.04162018
    4. Microsoft. (n.d.). *What is a cloud access security broker (CASB)?* Microsoft Learn. Retrieved April 27, 2026, from https://www.microsoft.com/en-us/security/business/security-101/what-is-a-cloud-access-security-broker-casb
    5. SecPod. (2023, March 28). *Shadow IT in the cloud: Risks and mitigation strategies*. SecPod Blog. https://www.secpod.com/blog/shadow-it-cloud-risks-mitigation-guide/
    6. IBM. (n.d.). *What is shadow IT?* IBM Think. Retrieved April 27, 2026, from https://www.ibm.com/think/topics/shadow-it
    7. U.S. Department of Defense. (2024). *Uphold the cloud shared responsibility model* (Cybersecurity Information Sheet). https://media.defense.gov/2024/Mar/07/2003407863/-1/-1/0/CSI-CLOUDTOP10-SHARED-RESPONSIBILITY-MODEL.PDF
    8. National Security Agency, & Cybersecurity and Infrastructure Security Agency. (2022). *Kubernetes hardening guide* (CTR-Kubernetes Hardening Guidance 1.2). https://media.defense.gov/2022/Aug/29/2003066362/-1/-1/0/CTR_KUBERNETES_HARDENING_GUIDANCE_1.2_20220829.PDF