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.

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]

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]

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