Speaker 1: Welcome back to the deep dive. Today. We are immersing
Speaker 1: ourselves in a topic that's well, highly specialized, but absolutely
Speaker 1: foundational for digital trust, cloud governance, compliance and auditing.
Speaker 2: It really is. It's dense critical stuff. For this deep dive,
Speaker 2: we're aiming to cut straight to the core, you know,
Speaker 2: extracting the essential frameworks and the specialized risks outlined and
Speaker 2: sources like thek the Certificate of Cloud Auditing Knowledge Study material.
Speaker 1: Yeah, our goal is really to give you a shortcut here.
Speaker 1: We want to synthesize exactly how major organizations manage security,
Speaker 1: meet those regulator demands, and maybe most importantly, established trust
Speaker 1: in these third party environments they don't physically control. And
Speaker 1: the starting line for all of this it has to
Speaker 1: be governance itself, right, that's right.
Speaker 2: I mean when you look at the definition of governance
Speaker 2: ISSAD talks about ensuring stakeholder needs are met through evaluated
Speaker 2: options based on policies, procedures, controls, all promoting transparency and accountability.
Speaker 2: You realize how complex that already is. And let's a
Speaker 2: traditional it. But in the cloud, where you introduce dynamic
Speaker 2: external actors, shared resources, that complexity just well, it explodes.
Speaker 1: Okay, let's unpack that explosion, that exponential growth. Why do
Speaker 1: those traditional IT governance models, you know, the ones we
Speaker 1: spend decades building for our own server rooms, why do
Speaker 1: they fundamentally break down when we shift to iss pace
Speaker 1: or sauce.
Speaker 2: The single biggest reason. It's the shared responsibility model. See
Speaker 2: traditional models assume you have full control over.
Speaker 1: The asset everything, your server, your network, your app exactly.
Speaker 2: But the cloud demands the specific, really granular mapping of controls.
Speaker 2: Who's responsible for the OS patching, who handles data encryption
Speaker 2: at rest? But here's the critical distinction, the thing you
Speaker 2: absolutely must always remember. While the responsibility for executing certain
Speaker 2: controls might transfer to the cloud service provider, the CSP
Speaker 2: accountability that always remains with the customer always.
Speaker 1: Okay, so on we get this straight. I'm a customer
Speaker 1: using maybe a Sauce application. Yeah, and that Sauce app
Speaker 1: runs on some is provider's infrastructure, which maybe uses a
Speaker 1: network subcontractor so there could be like four layers in.
Speaker 2: This change easily could be more.
Speaker 1: And even with all those providers handling operations down the stack,
Speaker 1: I am still the one ultimately held accountable if customer
Speaker 1: data gets lost or leaked exactly.
Speaker 2: That's the crux of it. And compounding that challenge, it's
Speaker 2: the sheer pace of change. Cloud platforms evolve constantly. Features
Speaker 2: get updated, they get retired, modified, sometimes, you know, multiple
Speaker 2: times in a single day. So this incredible rate of
Speaker 2: change means that any complex long term policy or governance
Speaker 2: framework you painstakingly built maybe six months ago, it's constantly
Speaker 2: at risk of becoming irrelevant, just poof outdated because the
Speaker 2: platform changed underneath you.
Speaker 1: Okay, so it makes existing governance harder. But let's turn
Speaker 1: the corner now and look at the risks that well,
Speaker 1: they only really exist because of the cloud model itself.
Speaker 1: It's not just making old risks harder, it's actually in
Speaker 1: nearing brand new ones. What are some of those unique
Speaker 1: inherent cloud risk factors that compliance teams are wrestling with now?
Speaker 2: Well, the first one, and it's tied right to the
Speaker 2: core architecture, is isolation failure. Okay, because the cloud is
Speaker 2: built on shared tenancy, right, multi tenancy. You've got multiple
Speaker 2: customers sharing the same underlying hardware, separated by these virtualization
Speaker 2: layers hypervisors. If that hypervisor or those isolation mechanisms fail
Speaker 2: even slightly, well, one customer's environment could potentially bleed into
Speaker 2: another's that could lead to unintended access. That specific risk,
Speaker 2: it just doesn't exist when you own all your own
Speaker 2: hardware in your own building, and.
Speaker 1: I imagine data deletion changes completely too. In our own
Speaker 1: data centers, we can take a drive out, shred it,
Speaker 1: wipe it physically. But in the cloud, where we're abstracted
Speaker 1: from the hardware, how can we really be sure that
Speaker 1: data is gone.
Speaker 2: That's the risk of incomplete data deletion. It's a big one.
Speaker 2: When you, as a cloud customer, request deletion, the CSP
Speaker 2: well often for its own upper rational reasons like ensuring reliability, availability,
Speaker 2: or maybe maintaining a fast rollback capability. They might maintain
Speaker 2: extra copies of that data in various storage layers, snapshots,
Speaker 2: backups you don't even know about. So you have limited visibility,
Speaker 2: very limited, meaning your deletion command might be technically fulfilled,
Speaker 2: but it might not result in a true complete wipe.
Speaker 2: That creates this potential long term compliance exposure, especially if
Speaker 2: that data legally must be purged, and.
Speaker 1: The very way you manage your cloud environment, the management
Speaker 1: interface that becomes a new attack surface, doesn't it.
Speaker 2: That's interface compromise precisely those management interfaces, the APIs, the
Speaker 2: web consoles, the dashboards. They're often exposed over the public
Speaker 2: Internet for convenience, but they control everything your networking, your storage,
Speaker 2: your compute instances, everything. So if a militia's actor compromises
Speaker 2: those interfaces, maybe they steal weak API keys or find
Speaker 2: hard coded credentials someone stupidly left encode. They essentially get
Speaker 2: the keys to your kin to make can compromise your
Speaker 2: entire computing environment, your data stores. Game over.
Speaker 1: And then there's the perennial challenge. It transcends all technologies really,
Speaker 1: but it just gets amplified like crazy by how easy
Speaker 1: it is to consume cloud services. Shadow I t.
Speaker 2: H shadow it T Yes, that's a really good question,
Speaker 2: and it gets to the core tension. The CCM, the
Speaker 2: cloud controls matrix. It isn't really trying to start over
Speaker 2: from scratch. It's often called a meta.
Speaker 1: Framework, a metaframework rap.
Speaker 2: Yeah. Its whole purpose is twofold. First to guide the
Speaker 2: CSPs themselves and implementing security correctly for the cloud context,
Speaker 2: and second to help prospective customers like you assess a
Speaker 2: provider's risk exposure. Specifically, related to those unique cloud native
Speaker 2: risks we just talked about.
Speaker 1: So it's kind of like a translation tool showing how
Speaker 1: existing compliance standards map onto the cloud reality exactly.
Speaker 2: That's a great way to put it. The CCM maps
Speaker 2: its specific cloud controls back to I think it's around
Speaker 2: forty existing industry accepted security standards, regulations and control frameworks NIST, ISO, COVID, PCIDSS,
Speaker 2: you name it.
Speaker 1: Oh, okay.
Speaker 2: So this means if a provider says they're compliant with,
Speaker 2: say a specific NIST eight hundred and fifty three control,
Speaker 2: the CCM helps show exactly where that overlaps with cloud needs,
Speaker 2: and crucially, it also highlights the specific governance gaps that
Speaker 2: still need cloud native controls.
Speaker 1: On top of that, that makes sense, and the structure
Speaker 1: itself sounds incredibly granular, which I guess is vital for auditors.
Speaker 1: It defines sixteen domains, right, things like application and interface
Speaker 1: security or governance and risk management.
Speaker 2: Yes, sixteen high level domains, but then it slices the
Speaker 2: controls within those domains by applicability, which is key.
Speaker 1: Oh so well.
Speaker 2: The CCM uses these specialized columns to make sure the
Speaker 2: controls are relevant to the specific situation. There are architectural
Speaker 2: relevance columns that denote applicability across the different cloud layers.
Speaker 2: Is this control about physical security, network, compute, storage, application data?
Speaker 1: Got it?
Speaker 2: And maybe most importantly, especially when you're procuring services it
Speaker 2: uses this is cloud service delivery model applicability columns. These
Speaker 2: clearly show which controls are relevant to IA versus POSS
Speaker 2: versus SAUS models, because you need very different assurances depending
Speaker 2: on which model you're consuming.
Speaker 1: Absolutely, so, how does a customer actually use this framework
Speaker 1: in practice? I mean other than just reading through a
Speaker 1: potentially massive spreadsheet.
Speaker 2: Right, you need something practical. That's where the Consensus Assessments
Speaker 2: Initiative Questionnaire or CAIQ comes in.
Speaker 1: It's CAIQ, okay.
Speaker 2: This is the practical industry accepted way for documenting which
Speaker 2: security controls actually exist in a providers specific IAS, PIASS
Speaker 2: or SAUCE offerings. It's essentially a standardized list of I
Speaker 2: think it's around three hundred and ten targeted questions derived
Speaker 2: directly from the CCM controls. A customer or an auditor
Speaker 2: can give this questionnaire to a CSP and the provider's
Speaker 2: answers demonstrate the presence and hopefully the operational status of
Speaker 2: those controls.
Speaker 1: So it's the practical interface to the CCM's theory.
Speaker 2: Precisely. Now here's a really important practical reality check. The
Speaker 2: CSPs they are almost never going to allow you, the customer,
Speaker 2: to perform your own hands on audits of their physical infrastructure.
Speaker 1: Right for security, multi tenancy reasons exactly.
Speaker 2: So this means cloud customers have to rely almost entirely
Speaker 2: on audited, documented, third party assurance. You can't kick the
Speaker 2: tires yourself.
Speaker 1: Okay, So we need some kind of robust, ideally public
Speaker 1: mechanism to establish that trust and transparency even though we
Speaker 1: can't physically step inside their data center.
Speaker 2: And that mechanism the industry standard is the CSA STAR program.
Speaker 2: STAR stands for Security, Trust, Assurance and Risk. Okay. It's
Speaker 2: the industry's framework that's really dedicated to rigorous auditing and
Speaker 2: trying to harmonize all these different cloud assurance standards, and
Speaker 2: it offers different tiered levels of assurance.
Speaker 1: Let's talk about those levels. Level one sounds like maybe
Speaker 1: the most basic self reporting.
Speaker 2: It is. Level one is the self assessment. It's the
Speaker 2: starting point. It offers pretty good transparency because the provider
Speaker 2: actually completes and publishes their answers to the CAIQ. Okay,
Speaker 2: so that gives you, let's say, good to moderate assurance.
Speaker 2: You see their claims, but they haven't necessarily been independently
Speaker 2: verified at this level.
Speaker 1: Right, So when a company wants real high assurance, they
Speaker 1: need to move up to the level two.
Speaker 2: Exactly. Level two is where you get third party certification
Speaker 2: or attestation. This is where the assurance level jumps significantly.
Speaker 2: And the really key element here, the one most mature
Speaker 2: organizations look for, is the Star attestation Star attestation.
Speaker 1: Now you mentioned it's built on SC two type two
Speaker 1: for listeners who might be less familiar with audit standards.
Speaker 1: What exactly does an SOOC two type two attestation verify?
Speaker 2: Sure? So a standard SoC two report. That's Service Organization
Speaker 2: control report. It's an independent audit that verifies that a
Speaker 2: service provider's internal controls are designed and operating effectively to
Speaker 2: meet the AICPA's trust services criteria over a specified period
Speaker 2: of time, usually six to twelve months for a type two.
Speaker 1: Those criteria are.
Speaker 2: Security, availability, processing, integrity, confidentiality, and privacy. The provider chooses
Speaker 2: which ones are relevant to their service.
Speaker 1: Okay, So if a CSP gets a STAR attestation. How
Speaker 1: does that differ from just getting a standard SEC two report?
Speaker 1: What's the added value?
Speaker 2: Great question. The Star attestation is fundamentally at SEC two
Speaker 2: type two report, but it's specifically augmented by adding the
Speaker 2: cloud specific controls detailed in the ccmh Okay.
Speaker 1: It layers on the cloud specifics precisely.
Speaker 2: It provides the independent auditor the CPA firm doing the
Speaker 2: audit with explicit guidelines for conducting cloud specific engagements. They're
Speaker 2: not just trying to shoehorn cloud security requirements into a
Speaker 2: generic IT audit template. It ensures those trust services criteria
Speaker 2: are tested against the real complexities of ias, plause or
Speaker 2: sauce environments.
Speaker 1: That makes perfect sense. It bridges the gap and theoretically
Speaker 1: the top tier level three that moves towards continuous auditing
Speaker 1: offering the absolute highest assurance through ongoing near real time assessment.
Speaker 2: That's the goal, yes, very high assurance and transparency. And
Speaker 2: this idea of continuous assessment moves us directly into the
Speaker 2: whole domain of auditing in the cloud. The complexity, especially
Speaker 2: with that shared responsibility model. It requires auditors to adopt
Speaker 2: what some of our sources call two dimensional thinking.
Speaker 1: Two dimensional thinking. Okay, what does that mean? In practice?
Speaker 2: The traditional audit, you have to evaluate every control through
Speaker 2: the lens of that shared responsibility model. You need to
Speaker 2: determine is this control mirrored or is it layered?
Speaker 1: Okay, mirrored versus layered. Let's break that down. Layered sounds
Speaker 1: like building blocks.
Speaker 2: Let's use an analogy, maybe renting an apartment, because layered
Speaker 2: controls are probably the most common source of confusion and
Speaker 2: frankly failure. Think of it like this. The landlord, who
Speaker 2: is like the CSP, is responsible for the building's foundation,
Speaker 2: the structural integrity, and maybe ensuring the locks on the
Speaker 2: main entrance store are functional. Those are the underling platform
Speaker 2: controls right the base, You, the tenant, the customer. You
Speaker 2: are responsible for deciding who you give keys to for
Speaker 2: your specific apartment, how you secure your valuables inside, maybe
Speaker 2: the multi factor authentication on your specific application log in.
Speaker 2: Those are the user controls built on top.
Speaker 1: Got it? So, layered controls mean the overall security depends
Speaker 1: on my controls operating effectively on top of the CSP's
Speaker 1: foundational controls exactly.
Speaker 2: Failure in either layer can cause a breach. Maybe the
Speaker 2: landlord leaves the front door unlocked CST failure, or maybe
Speaker 2: you leave your apartment window open customer failure. The operational
Speaker 2: responsibility is divided, but the outcome depends on both.
Speaker 1: Okay, that clarifies layered. What about mirrored?
Speaker 2: Then mirrored is simpler conceptually, think of something like secure
Speaker 2: awareness training. In that case, the CSP needs to train
Speaker 2: its staff effectively to defend against social engineering attacks directed
Speaker 2: at them and their infrastructure, and the customer needs to
Speaker 2: train its staff effectively to recognize phishing scams directed at
Speaker 2: their application users or their accounts.
Speaker 1: So both organizations have to operate the same type of
Speaker 1: control independently but effectively to protect the whole system.
Speaker 2: Precisely, both marrors need to be intact.
Speaker 1: Now we've established that cloud services change incredibly fast, sometimes
Speaker 1: multiple times a day. If our compliance program relies on
Speaker 1: a traditional audit basically a snapshot taken once a year,
Speaker 1: that assurance feels instantly obsolete the day after the auditor leaves,
Speaker 1: Which is why I assume we have to move toward
Speaker 1: this idea of continuous assurance.
Speaker 2: Absolutely, traditional point in time compliance is just fundamentally insufficient
Speaker 2: for the dynamic nature of the cloud environment. It requires
Speaker 2: a major shift from that snapshot perspective to a continuous process.
Speaker 2: But it's really important to clarify the terminology here because
Speaker 2: people often mix them up. There's continuous monitoring, which is
Speaker 2: typically the automated continuous feedback loop provided to management. It
Speaker 2: tells them about vulner our abilities, active threats, control failures
Speaker 2: in your real time. It's primarily a management tool for
Speaker 2: operational awareness.
Speaker 1: Right versus continuous auditing.
Speaker 2: Yes, continuous auditing is different. That's the ongoing assessment process
Speaker 2: conducted by auditors internal or external to determine the actual
Speaker 2: fulfillment of service level objectives, service qualitative objectives, control effectiveness,
Speaker 2: so provides assurance. It's the mechanism that provides ongoing assurance
Speaker 2: that controls are always operating effectively, not just on the
Speaker 2: specific day the auditor happens to show up and test them.
Speaker 1: And this whole need for speed for continuous validation, it
Speaker 1: inevitably pushes security earlier in the process. Doesn't it into
Speaker 1: the development cycle itself. We hear terms like DevSecOps and
Speaker 1: shifting security.
Speaker 2: Less absolutely unavoidable. Modern software development relies heavily on automated
Speaker 2: practices like continuous integration, continuous delivery and continuous deployment the
Speaker 2: CICD pipeline.
Speaker 1: Right, pushing code changes frequently.
Speaker 2: You simply it can't wait until the application is deployed
Speaker 2: to production to find critical security flaws. It's too late,
Speaker 2: too expensive, too risky. Security must be embedded earlier, shifted left,
Speaker 2: as they say, right into the software development life cycle itself.
Speaker 2: Automated security testing, code scanning, dependency checks all part of
Speaker 2: the build process.
Speaker 1: So this fundamentally changes the auditor's job too, right, They
Speaker 1: aren't just auditing the final production system anymore if they're
Speaker 1: actually auditing the automation pipelines themselves. The CICD tools and processes.
Speaker 2: Correct the focus shifts. The auditor now needs to verify
Speaker 2: that effective security gates are consistently built into that automated pipeline.
Speaker 2: They need assurance that the automation processes themselves are reliably
Speaker 2: producing code that has built in auditability and meets compliance
Speaker 2: checks before it ever gets deployed.
Speaker 1: So you audit the factory, not just the car coming
Speaker 1: off a line.
Speaker 2: That's a perfect analogy. You verify that the automated process
Speaker 2: guarantees security before deployment, rather than just checking the security
Speaker 2: status after deployment.
Speaker 1: Okay, so let's write this up. What does this all
Speaker 1: mean for you, the organization consuming these cloud services? I
Speaker 1: mean the very existence of these specialized frameworks like the CCM,
Speaker 1: the transparency hopefully offered by the CIIQ, and this rigorous
Speaker 1: multi level star program. It shows just how much effort
Speaker 1: the industry has poured into ensuring that trust can actually
Speaker 1: exist in environments you don't physically control.
Speaker 2: It really does. But we started by discussing accountability versus responsibility,
Speaker 2: and honestly, that is the most critical takeaway here. Even
Speaker 2: with all these sophisticated layers of third party controls, the
Speaker 2: specialized governance frameworks, the risk management efforts, the ultimate accountability
Speaker 2: lies squarely with you, the cloud customer. You must execute
Speaker 2: that continuous due diligence. You have to ensure that shared
Speaker 2: responsibility model is mapped out, clearly, understood and audited correctly
Speaker 2: for your specific use case.
Speaker 1: Understanding that distinction is absolutely paramount, because while you can
Speaker 1: and often must outsource the execution of a control to
Speaker 1: your SAE, you can never ever outsource the ultimate accountability
Speaker 1: for protecting your data and meeting your obligations.
Speaker 2: That's the fundamental truth and you know. Just to hammer
Speaker 2: this point home, here is a really stark figure from
Speaker 2: one of our sources that underscores exactly why understanding this
Speaker 2: two dimensional governance model is so critical for any organization
Speaker 2: using the cloud. A report from Gartner suggests that over
Speaker 2: the next five years at least get this, ninety nine
Speaker 2: percent of cloud security failures will actually be the customer's fault.
Speaker 1: Ninety nine percent.
Speaker 2: Ninety nine percent, that massive, almost overwhelming number. It just
Speaker 2: reinforces the reality the technical security operations might be largely outsourced,
Speaker 2: but the ownership of governance, the compliance posture, the risk
Speaker 2: management decisions that must remain firmly rooted within your organization,
Speaker 2: the consuming organization. It's non negotiable.