WEBVTT

1
00:00:00.080 --> 00:00:04.080
<v Speaker 1>Welcome back to the deep dive. Today. We are immersing

2
00:00:04.080 --> 00:00:08.480
<v Speaker 1>ourselves in a topic that's well, highly specialized, but absolutely

3
00:00:08.480 --> 00:00:12.679
<v Speaker 1>foundational for digital trust, cloud governance, compliance and auditing.

4
00:00:13.119 --> 00:00:17.039
<v Speaker 2>It really is. It's dense critical stuff. For this deep dive,

5
00:00:17.079 --> 00:00:19.160
<v Speaker 2>we're aiming to cut straight to the core, you know,

6
00:00:19.320 --> 00:00:24.079
<v Speaker 2>extracting the essential frameworks and the specialized risks outlined and

7
00:00:24.120 --> 00:00:28.760
<v Speaker 2>sources like thek the Certificate of Cloud Auditing Knowledge Study material.

8
00:00:29.000 --> 00:00:31.000
<v Speaker 1>Yeah, our goal is really to give you a shortcut here.

9
00:00:31.039 --> 00:00:34.920
<v Speaker 1>We want to synthesize exactly how major organizations manage security,

10
00:00:35.320 --> 00:00:39.920
<v Speaker 1>meet those regulator demands, and maybe most importantly, established trust

11
00:00:40.039 --> 00:00:43.039
<v Speaker 1>in these third party environments they don't physically control. And

12
00:00:43.079 --> 00:00:45.399
<v Speaker 1>the starting line for all of this it has to

13
00:00:45.399 --> 00:00:46.960
<v Speaker 1>be governance itself, right, that's right.

14
00:00:47.000 --> 00:00:48.679
<v Speaker 2>I mean when you look at the definition of governance

15
00:00:48.719 --> 00:00:52.119
<v Speaker 2>ISSAD talks about ensuring stakeholder needs are met through evaluated

16
00:00:52.159 --> 00:00:57.320
<v Speaker 2>options based on policies, procedures, controls, all promoting transparency and accountability.

17
00:00:57.600 --> 00:01:00.200
<v Speaker 2>You realize how complex that already is. And let's a

18
00:01:00.439 --> 00:01:05.640
<v Speaker 2>traditional it. But in the cloud, where you introduce dynamic

19
00:01:05.840 --> 00:01:11.159
<v Speaker 2>external actors, shared resources, that complexity just well, it explodes.

20
00:01:10.640 --> 00:01:15.000
<v Speaker 1>Okay, let's unpack that explosion, that exponential growth. Why do

21
00:01:15.159 --> 00:01:18.519
<v Speaker 1>those traditional IT governance models, you know, the ones we

22
00:01:18.560 --> 00:01:21.480
<v Speaker 1>spend decades building for our own server rooms, why do

23
00:01:21.560 --> 00:01:25.359
<v Speaker 1>they fundamentally break down when we shift to iss pace

24
00:01:25.799 --> 00:01:26.280
<v Speaker 1>or sauce.

25
00:01:27.000 --> 00:01:30.319
<v Speaker 2>The single biggest reason. It's the shared responsibility model. See

26
00:01:30.319 --> 00:01:32.599
<v Speaker 2>traditional models assume you have full control over.

27
00:01:32.480 --> 00:01:35.079
<v Speaker 1>The asset everything, your server, your network, your app exactly.

28
00:01:35.159 --> 00:01:40.280
<v Speaker 2>But the cloud demands the specific, really granular mapping of controls.

29
00:01:40.519 --> 00:01:43.840
<v Speaker 2>Who's responsible for the OS patching, who handles data encryption

30
00:01:43.959 --> 00:01:46.680
<v Speaker 2>at rest? But here's the critical distinction, the thing you

31
00:01:46.719 --> 00:01:50.640
<v Speaker 2>absolutely must always remember. While the responsibility for executing certain

32
00:01:50.680 --> 00:01:54.000
<v Speaker 2>controls might transfer to the cloud service provider, the CSP

33
00:01:54.079 --> 00:01:57.480
<v Speaker 2>accountability that always remains with the customer always.

34
00:01:57.560 --> 00:01:59.719
<v Speaker 1>Okay, so on we get this straight. I'm a customer

35
00:02:00.120 --> 00:02:03.040
<v Speaker 1>using maybe a Sauce application. Yeah, and that Sauce app

36
00:02:03.159 --> 00:02:06.760
<v Speaker 1>runs on some is provider's infrastructure, which maybe uses a

37
00:02:06.760 --> 00:02:10.159
<v Speaker 1>network subcontractor so there could be like four layers in.

38
00:02:10.159 --> 00:02:12.080
<v Speaker 2>This change easily could be more.

39
00:02:11.919 --> 00:02:14.919
<v Speaker 1>And even with all those providers handling operations down the stack,

40
00:02:15.400 --> 00:02:17.919
<v Speaker 1>I am still the one ultimately held accountable if customer

41
00:02:18.000 --> 00:02:19.759
<v Speaker 1>data gets lost or leaked exactly.

42
00:02:19.919 --> 00:02:23.400
<v Speaker 2>That's the crux of it. And compounding that challenge, it's

43
00:02:23.400 --> 00:02:27.879
<v Speaker 2>the sheer pace of change. Cloud platforms evolve constantly. Features

44
00:02:27.879 --> 00:02:31.800
<v Speaker 2>get updated, they get retired, modified, sometimes, you know, multiple

45
00:02:31.840 --> 00:02:34.520
<v Speaker 2>times in a single day. So this incredible rate of

46
00:02:34.599 --> 00:02:38.960
<v Speaker 2>change means that any complex long term policy or governance

47
00:02:39.039 --> 00:02:43.719
<v Speaker 2>framework you painstakingly built maybe six months ago, it's constantly

48
00:02:43.759 --> 00:02:47.400
<v Speaker 2>at risk of becoming irrelevant, just poof outdated because the

49
00:02:47.400 --> 00:02:48.840
<v Speaker 2>platform changed underneath you.

50
00:02:48.960 --> 00:02:52.039
<v Speaker 1>Okay, so it makes existing governance harder. But let's turn

51
00:02:52.080 --> 00:02:54.319
<v Speaker 1>the corner now and look at the risks that well,

52
00:02:54.360 --> 00:02:56.800
<v Speaker 1>they only really exist because of the cloud model itself.

53
00:02:57.240 --> 00:02:59.800
<v Speaker 1>It's not just making old risks harder, it's actually in

54
00:03:00.080 --> 00:03:02.759
<v Speaker 1>nearing brand new ones. What are some of those unique

55
00:03:02.879 --> 00:03:06.639
<v Speaker 1>inherent cloud risk factors that compliance teams are wrestling with now?

56
00:03:06.879 --> 00:03:08.719
<v Speaker 2>Well, the first one, and it's tied right to the

57
00:03:08.719 --> 00:03:12.919
<v Speaker 2>core architecture, is isolation failure. Okay, because the cloud is

58
00:03:12.919 --> 00:03:16.439
<v Speaker 2>built on shared tenancy, right, multi tenancy. You've got multiple

59
00:03:16.439 --> 00:03:20.879
<v Speaker 2>customers sharing the same underlying hardware, separated by these virtualization

60
00:03:20.960 --> 00:03:25.840
<v Speaker 2>layers hypervisors. If that hypervisor or those isolation mechanisms fail

61
00:03:26.159 --> 00:03:31.240
<v Speaker 2>even slightly, well, one customer's environment could potentially bleed into

62
00:03:31.280 --> 00:03:35.520
<v Speaker 2>another's that could lead to unintended access. That specific risk,

63
00:03:35.639 --> 00:03:37.919
<v Speaker 2>it just doesn't exist when you own all your own

64
00:03:37.960 --> 00:03:39.759
<v Speaker 2>hardware in your own building, and.

65
00:03:39.719 --> 00:03:42.840
<v Speaker 1>I imagine data deletion changes completely too. In our own

66
00:03:42.919 --> 00:03:45.879
<v Speaker 1>data centers, we can take a drive out, shred it,

67
00:03:46.080 --> 00:03:49.479
<v Speaker 1>wipe it physically. But in the cloud, where we're abstracted

68
00:03:49.520 --> 00:03:51.680
<v Speaker 1>from the hardware, how can we really be sure that

69
00:03:51.800 --> 00:03:52.599
<v Speaker 1>data is gone.

70
00:03:53.000 --> 00:03:55.639
<v Speaker 2>That's the risk of incomplete data deletion. It's a big one.

71
00:03:55.680 --> 00:03:58.560
<v Speaker 2>When you, as a cloud customer, request deletion, the CSP

72
00:03:58.639 --> 00:04:03.120
<v Speaker 2>well often for its own upper rational reasons like ensuring reliability, availability,

73
00:04:03.199 --> 00:04:06.400
<v Speaker 2>or maybe maintaining a fast rollback capability. They might maintain

74
00:04:06.479 --> 00:04:09.879
<v Speaker 2>extra copies of that data in various storage layers, snapshots,

75
00:04:09.879 --> 00:04:12.599
<v Speaker 2>backups you don't even know about. So you have limited visibility,

76
00:04:12.759 --> 00:04:16.439
<v Speaker 2>very limited, meaning your deletion command might be technically fulfilled,

77
00:04:16.519 --> 00:04:20.519
<v Speaker 2>but it might not result in a true complete wipe.

78
00:04:20.959 --> 00:04:25.360
<v Speaker 2>That creates this potential long term compliance exposure, especially if

79
00:04:25.360 --> 00:04:28.160
<v Speaker 2>that data legally must be purged, and.

80
00:04:28.519 --> 00:04:31.480
<v Speaker 1>The very way you manage your cloud environment, the management

81
00:04:31.560 --> 00:04:34.120
<v Speaker 1>interface that becomes a new attack surface, doesn't it.

82
00:04:34.199 --> 00:04:38.439
<v Speaker 2>That's interface compromise precisely those management interfaces, the APIs, the

83
00:04:38.480 --> 00:04:41.759
<v Speaker 2>web consoles, the dashboards. They're often exposed over the public

84
00:04:41.839 --> 00:04:47.079
<v Speaker 2>Internet for convenience, but they control everything your networking, your storage,

85
00:04:47.120 --> 00:04:51.439
<v Speaker 2>your compute instances, everything. So if a militia's actor compromises

86
00:04:51.480 --> 00:04:55.240
<v Speaker 2>those interfaces, maybe they steal weak API keys or find

87
00:04:55.240 --> 00:04:59.319
<v Speaker 2>hard coded credentials someone stupidly left encode. They essentially get

88
00:04:59.319 --> 00:05:00.959
<v Speaker 2>the keys to your kin to make can compromise your

89
00:05:01.079 --> 00:05:03.759
<v Speaker 2>entire computing environment, your data stores. Game over.

90
00:05:04.079 --> 00:05:08.199
<v Speaker 1>And then there's the perennial challenge. It transcends all technologies really,

91
00:05:08.199 --> 00:05:11.160
<v Speaker 1>but it just gets amplified like crazy by how easy

92
00:05:11.160 --> 00:05:13.839
<v Speaker 1>it is to consume cloud services. Shadow I t.

93
00:05:14.439 --> 00:05:17.519
<v Speaker 2>H shadow it T Yes, that's a really good question,

94
00:05:17.639 --> 00:05:20.439
<v Speaker 2>and it gets to the core tension. The CCM, the

95
00:05:20.480 --> 00:05:23.879
<v Speaker 2>cloud controls matrix. It isn't really trying to start over

96
00:05:23.920 --> 00:05:26.040
<v Speaker 2>from scratch. It's often called a meta.

97
00:05:25.839 --> 00:05:27.240
<v Speaker 1>Framework, a metaframework rap.

98
00:05:27.360 --> 00:05:30.600
<v Speaker 2>Yeah. Its whole purpose is twofold. First to guide the

99
00:05:30.639 --> 00:05:34.439
<v Speaker 2>CSPs themselves and implementing security correctly for the cloud context,

100
00:05:35.000 --> 00:05:39.000
<v Speaker 2>and second to help prospective customers like you assess a

101
00:05:39.040 --> 00:05:43.399
<v Speaker 2>provider's risk exposure. Specifically, related to those unique cloud native

102
00:05:43.480 --> 00:05:44.759
<v Speaker 2>risks we just talked about.

103
00:05:44.839 --> 00:05:47.279
<v Speaker 1>So it's kind of like a translation tool showing how

104
00:05:47.279 --> 00:05:50.839
<v Speaker 1>existing compliance standards map onto the cloud reality exactly.

105
00:05:50.839 --> 00:05:53.240
<v Speaker 2>That's a great way to put it. The CCM maps

106
00:05:53.279 --> 00:05:55.879
<v Speaker 2>its specific cloud controls back to I think it's around

107
00:05:55.959 --> 00:06:04.240
<v Speaker 2>forty existing industry accepted security standards, regulations and control frameworks NIST, ISO, COVID, PCIDSS,

108
00:06:04.279 --> 00:06:04.720
<v Speaker 2>you name it.

109
00:06:04.879 --> 00:06:05.560
<v Speaker 1>Oh, okay.

110
00:06:05.600 --> 00:06:07.639
<v Speaker 2>So this means if a provider says they're compliant with,

111
00:06:07.759 --> 00:06:10.839
<v Speaker 2>say a specific NIST eight hundred and fifty three control,

112
00:06:11.040 --> 00:06:14.399
<v Speaker 2>the CCM helps show exactly where that overlaps with cloud needs,

113
00:06:14.800 --> 00:06:18.040
<v Speaker 2>and crucially, it also highlights the specific governance gaps that

114
00:06:18.120 --> 00:06:19.480
<v Speaker 2>still need cloud native controls.

115
00:06:19.519 --> 00:06:21.560
<v Speaker 1>On top of that, that makes sense, and the structure

116
00:06:21.600 --> 00:06:24.800
<v Speaker 1>itself sounds incredibly granular, which I guess is vital for auditors.

117
00:06:25.120 --> 00:06:29.120
<v Speaker 1>It defines sixteen domains, right, things like application and interface

118
00:06:29.199 --> 00:06:31.360
<v Speaker 1>security or governance and risk management.

119
00:06:31.720 --> 00:06:35.399
<v Speaker 2>Yes, sixteen high level domains, but then it slices the

120
00:06:35.399 --> 00:06:38.639
<v Speaker 2>controls within those domains by applicability, which is key.

121
00:06:38.800 --> 00:06:39.920
<v Speaker 1>Oh so well.

122
00:06:39.959 --> 00:06:42.439
<v Speaker 2>The CCM uses these specialized columns to make sure the

123
00:06:42.439 --> 00:06:46.279
<v Speaker 2>controls are relevant to the specific situation. There are architectural

124
00:06:46.319 --> 00:06:49.759
<v Speaker 2>relevance columns that denote applicability across the different cloud layers.

125
00:06:49.920 --> 00:06:55.519
<v Speaker 2>Is this control about physical security, network, compute, storage, application data?

126
00:06:55.600 --> 00:06:55.920
<v Speaker 1>Got it?

127
00:06:56.360 --> 00:06:59.720
<v Speaker 2>And maybe most importantly, especially when you're procuring services it

128
00:06:59.800 --> 00:07:03.480
<v Speaker 2>uses this is cloud service delivery model applicability columns. These

129
00:07:03.519 --> 00:07:07.720
<v Speaker 2>clearly show which controls are relevant to IA versus POSS

130
00:07:08.040 --> 00:07:11.560
<v Speaker 2>versus SAUS models, because you need very different assurances depending

131
00:07:11.600 --> 00:07:12.759
<v Speaker 2>on which model you're consuming.

132
00:07:12.920 --> 00:07:16.600
<v Speaker 1>Absolutely, so, how does a customer actually use this framework

133
00:07:16.639 --> 00:07:18.879
<v Speaker 1>in practice? I mean other than just reading through a

134
00:07:19.000 --> 00:07:21.079
<v Speaker 1>potentially massive spreadsheet.

135
00:07:20.759 --> 00:07:24.279
<v Speaker 2>Right, you need something practical. That's where the Consensus Assessments

136
00:07:24.319 --> 00:07:26.839
<v Speaker 2>Initiative Questionnaire or CAIQ comes in.

137
00:07:26.879 --> 00:07:28.079
<v Speaker 1>It's CAIQ, okay.

138
00:07:28.120 --> 00:07:31.639
<v Speaker 2>This is the practical industry accepted way for documenting which

139
00:07:31.680 --> 00:07:36.519
<v Speaker 2>security controls actually exist in a providers specific IAS, PIASS

140
00:07:36.600 --> 00:07:40.360
<v Speaker 2>or SAUCE offerings. It's essentially a standardized list of I

141
00:07:40.360 --> 00:07:44.199
<v Speaker 2>think it's around three hundred and ten targeted questions derived

142
00:07:44.240 --> 00:07:47.639
<v Speaker 2>directly from the CCM controls. A customer or an auditor

143
00:07:47.680 --> 00:07:51.000
<v Speaker 2>can give this questionnaire to a CSP and the provider's

144
00:07:51.040 --> 00:07:54.879
<v Speaker 2>answers demonstrate the presence and hopefully the operational status of

145
00:07:54.959 --> 00:07:55.800
<v Speaker 2>those controls.

146
00:07:55.920 --> 00:07:58.439
<v Speaker 1>So it's the practical interface to the CCM's theory.

147
00:07:58.480 --> 00:08:02.199
<v Speaker 2>Precisely. Now here's a really important practical reality check. The

148
00:08:02.240 --> 00:08:06.240
<v Speaker 2>CSPs they are almost never going to allow you, the customer,

149
00:08:06.279 --> 00:08:10.360
<v Speaker 2>to perform your own hands on audits of their physical infrastructure.

150
00:08:09.720 --> 00:08:12.399
<v Speaker 1>Right for security, multi tenancy reasons exactly.

151
00:08:12.439 --> 00:08:15.240
<v Speaker 2>So this means cloud customers have to rely almost entirely

152
00:08:15.319 --> 00:08:19.000
<v Speaker 2>on audited, documented, third party assurance. You can't kick the

153
00:08:19.000 --> 00:08:20.079
<v Speaker 2>tires yourself.

154
00:08:19.800 --> 00:08:22.920
<v Speaker 1>Okay, So we need some kind of robust, ideally public

155
00:08:23.000 --> 00:08:26.959
<v Speaker 1>mechanism to establish that trust and transparency even though we

156
00:08:27.000 --> 00:08:29.079
<v Speaker 1>can't physically step inside their data center.

157
00:08:29.399 --> 00:08:33.679
<v Speaker 2>And that mechanism the industry standard is the CSA STAR program.

158
00:08:34.120 --> 00:08:39.000
<v Speaker 2>STAR stands for Security, Trust, Assurance and Risk. Okay. It's

159
00:08:39.039 --> 00:08:43.159
<v Speaker 2>the industry's framework that's really dedicated to rigorous auditing and

160
00:08:43.200 --> 00:08:47.000
<v Speaker 2>trying to harmonize all these different cloud assurance standards, and

161
00:08:47.080 --> 00:08:50.679
<v Speaker 2>it offers different tiered levels of assurance.

162
00:08:50.840 --> 00:08:53.159
<v Speaker 1>Let's talk about those levels. Level one sounds like maybe

163
00:08:53.200 --> 00:08:55.360
<v Speaker 1>the most basic self reporting.

164
00:08:55.799 --> 00:08:58.799
<v Speaker 2>It is. Level one is the self assessment. It's the

165
00:08:58.840 --> 00:09:02.639
<v Speaker 2>starting point. It offers pretty good transparency because the provider

166
00:09:02.759 --> 00:09:07.039
<v Speaker 2>actually completes and publishes their answers to the CAIQ. Okay,

167
00:09:07.120 --> 00:09:09.480
<v Speaker 2>so that gives you, let's say, good to moderate assurance.

168
00:09:09.559 --> 00:09:12.480
<v Speaker 2>You see their claims, but they haven't necessarily been independently

169
00:09:12.600 --> 00:09:13.960
<v Speaker 2>verified at this level.

170
00:09:13.720 --> 00:09:16.399
<v Speaker 1>Right, So when a company wants real high assurance, they

171
00:09:16.440 --> 00:09:18.279
<v Speaker 1>need to move up to the level two.

172
00:09:18.480 --> 00:09:20.960
<v Speaker 2>Exactly. Level two is where you get third party certification

173
00:09:21.080 --> 00:09:24.240
<v Speaker 2>or attestation. This is where the assurance level jumps significantly.

174
00:09:24.559 --> 00:09:27.279
<v Speaker 2>And the really key element here, the one most mature

175
00:09:27.399 --> 00:09:31.279
<v Speaker 2>organizations look for, is the Star attestation Star attestation.

176
00:09:31.759 --> 00:09:34.360
<v Speaker 1>Now you mentioned it's built on SC two type two

177
00:09:34.840 --> 00:09:37.159
<v Speaker 1>for listeners who might be less familiar with audit standards.

178
00:09:37.159 --> 00:09:40.639
<v Speaker 1>What exactly does an SOOC two type two attestation verify?

179
00:09:40.840 --> 00:09:44.320
<v Speaker 2>Sure? So a standard SoC two report. That's Service Organization

180
00:09:44.399 --> 00:09:47.320
<v Speaker 2>control report. It's an independent audit that verifies that a

181
00:09:47.360 --> 00:09:51.559
<v Speaker 2>service provider's internal controls are designed and operating effectively to

182
00:09:51.679 --> 00:09:56.120
<v Speaker 2>meet the AICPA's trust services criteria over a specified period

183
00:09:56.159 --> 00:09:58.440
<v Speaker 2>of time, usually six to twelve months for a type two.

184
00:09:58.879 --> 00:09:59.919
<v Speaker 1>Those criteria are.

185
00:10:00.039 --> 00:10:05.759
<v Speaker 2>Security, availability, processing, integrity, confidentiality, and privacy. The provider chooses

186
00:10:05.799 --> 00:10:07.320
<v Speaker 2>which ones are relevant to their service.

187
00:10:07.399 --> 00:10:12.159
<v Speaker 1>Okay, So if a CSP gets a STAR attestation. How

188
00:10:12.200 --> 00:10:15.039
<v Speaker 1>does that differ from just getting a standard SEC two report?

189
00:10:15.080 --> 00:10:16.080
<v Speaker 1>What's the added value?

190
00:10:16.200 --> 00:10:19.279
<v Speaker 2>Great question. The Star attestation is fundamentally at SEC two

191
00:10:19.399 --> 00:10:22.399
<v Speaker 2>type two report, but it's specifically augmented by adding the

192
00:10:22.399 --> 00:10:25.679
<v Speaker 2>cloud specific controls detailed in the ccmh Okay.

193
00:10:25.720 --> 00:10:28.039
<v Speaker 1>It layers on the cloud specifics precisely.

194
00:10:28.399 --> 00:10:31.519
<v Speaker 2>It provides the independent auditor the CPA firm doing the

195
00:10:31.559 --> 00:10:37.480
<v Speaker 2>audit with explicit guidelines for conducting cloud specific engagements. They're

196
00:10:37.519 --> 00:10:40.799
<v Speaker 2>not just trying to shoehorn cloud security requirements into a

197
00:10:40.879 --> 00:10:45.720
<v Speaker 2>generic IT audit template. It ensures those trust services criteria

198
00:10:45.759 --> 00:10:49.679
<v Speaker 2>are tested against the real complexities of ias, plause or

199
00:10:49.759 --> 00:10:50.799
<v Speaker 2>sauce environments.

200
00:10:51.120 --> 00:10:54.519
<v Speaker 1>That makes perfect sense. It bridges the gap and theoretically

201
00:10:54.960 --> 00:10:59.039
<v Speaker 1>the top tier level three that moves towards continuous auditing

202
00:10:59.399 --> 00:11:04.480
<v Speaker 1>offering the absolute highest assurance through ongoing near real time assessment.

203
00:11:04.639 --> 00:11:07.919
<v Speaker 2>That's the goal, yes, very high assurance and transparency. And

204
00:11:07.960 --> 00:11:10.799
<v Speaker 2>this idea of continuous assessment moves us directly into the

205
00:11:10.799 --> 00:11:14.120
<v Speaker 2>whole domain of auditing in the cloud. The complexity, especially

206
00:11:14.120 --> 00:11:17.679
<v Speaker 2>with that shared responsibility model. It requires auditors to adopt

207
00:11:17.759 --> 00:11:20.639
<v Speaker 2>what some of our sources call two dimensional thinking.

208
00:11:20.320 --> 00:11:24.000
<v Speaker 1>Two dimensional thinking. Okay, what does that mean? In practice?

209
00:11:26.360 --> 00:11:29.120
<v Speaker 2>The traditional audit, you have to evaluate every control through

210
00:11:29.120 --> 00:11:31.600
<v Speaker 2>the lens of that shared responsibility model. You need to

211
00:11:31.639 --> 00:11:35.279
<v Speaker 2>determine is this control mirrored or is it layered?

212
00:11:35.559 --> 00:11:39.200
<v Speaker 1>Okay, mirrored versus layered. Let's break that down. Layered sounds

213
00:11:39.240 --> 00:11:40.159
<v Speaker 1>like building blocks.

214
00:11:40.519 --> 00:11:43.639
<v Speaker 2>Let's use an analogy, maybe renting an apartment, because layered

215
00:11:43.639 --> 00:11:46.399
<v Speaker 2>controls are probably the most common source of confusion and

216
00:11:46.679 --> 00:11:51.639
<v Speaker 2>frankly failure. Think of it like this. The landlord, who

217
00:11:51.720 --> 00:11:54.600
<v Speaker 2>is like the CSP, is responsible for the building's foundation,

218
00:11:54.759 --> 00:11:57.360
<v Speaker 2>the structural integrity, and maybe ensuring the locks on the

219
00:11:57.360 --> 00:12:00.759
<v Speaker 2>main entrance store are functional. Those are the underling platform

220
00:12:00.799 --> 00:12:04.759
<v Speaker 2>controls right the base, You, the tenant, the customer. You

221
00:12:04.799 --> 00:12:07.600
<v Speaker 2>are responsible for deciding who you give keys to for

222
00:12:07.720 --> 00:12:11.919
<v Speaker 2>your specific apartment, how you secure your valuables inside, maybe

223
00:12:11.960 --> 00:12:15.720
<v Speaker 2>the multi factor authentication on your specific application log in.

224
00:12:16.200 --> 00:12:18.159
<v Speaker 2>Those are the user controls built on top.

225
00:12:18.559 --> 00:12:21.919
<v Speaker 1>Got it? So, layered controls mean the overall security depends

226
00:12:21.919 --> 00:12:24.799
<v Speaker 1>on my controls operating effectively on top of the CSP's

227
00:12:24.799 --> 00:12:26.360
<v Speaker 1>foundational controls exactly.

228
00:12:26.559 --> 00:12:29.320
<v Speaker 2>Failure in either layer can cause a breach. Maybe the

229
00:12:29.399 --> 00:12:32.960
<v Speaker 2>landlord leaves the front door unlocked CST failure, or maybe

230
00:12:33.000 --> 00:12:36.879
<v Speaker 2>you leave your apartment window open customer failure. The operational

231
00:12:36.919 --> 00:12:39.960
<v Speaker 2>responsibility is divided, but the outcome depends on both.

232
00:12:40.240 --> 00:12:43.039
<v Speaker 1>Okay, that clarifies layered. What about mirrored?

233
00:12:43.080 --> 00:12:47.440
<v Speaker 2>Then mirrored is simpler conceptually, think of something like secure

234
00:12:47.519 --> 00:12:51.879
<v Speaker 2>awareness training. In that case, the CSP needs to train

235
00:12:51.960 --> 00:12:56.000
<v Speaker 2>its staff effectively to defend against social engineering attacks directed

236
00:12:56.039 --> 00:12:59.519
<v Speaker 2>at them and their infrastructure, and the customer needs to

237
00:12:59.519 --> 00:13:03.759
<v Speaker 2>train its staff effectively to recognize phishing scams directed at

238
00:13:03.759 --> 00:13:05.919
<v Speaker 2>their application users or their accounts.

239
00:13:06.000 --> 00:13:08.399
<v Speaker 1>So both organizations have to operate the same type of

240
00:13:08.399 --> 00:13:12.120
<v Speaker 1>control independently but effectively to protect the whole system.

241
00:13:12.159 --> 00:13:14.360
<v Speaker 2>Precisely, both marrors need to be intact.

242
00:13:14.480 --> 00:13:19.360
<v Speaker 1>Now we've established that cloud services change incredibly fast, sometimes

243
00:13:19.440 --> 00:13:22.559
<v Speaker 1>multiple times a day. If our compliance program relies on

244
00:13:22.600 --> 00:13:25.759
<v Speaker 1>a traditional audit basically a snapshot taken once a year,

245
00:13:26.240 --> 00:13:29.720
<v Speaker 1>that assurance feels instantly obsolete the day after the auditor leaves,

246
00:13:30.200 --> 00:13:32.919
<v Speaker 1>Which is why I assume we have to move toward

247
00:13:32.960 --> 00:13:34.759
<v Speaker 1>this idea of continuous assurance.

248
00:13:35.000 --> 00:13:39.039
<v Speaker 2>Absolutely, traditional point in time compliance is just fundamentally insufficient

249
00:13:39.080 --> 00:13:42.399
<v Speaker 2>for the dynamic nature of the cloud environment. It requires

250
00:13:42.440 --> 00:13:47.000
<v Speaker 2>a major shift from that snapshot perspective to a continuous process.

251
00:13:47.480 --> 00:13:50.279
<v Speaker 2>But it's really important to clarify the terminology here because

252
00:13:50.279 --> 00:13:54.159
<v Speaker 2>people often mix them up. There's continuous monitoring, which is

253
00:13:54.360 --> 00:13:59.039
<v Speaker 2>typically the automated continuous feedback loop provided to management. It

254
00:13:59.080 --> 00:14:02.559
<v Speaker 2>tells them about vulner our abilities, active threats, control failures

255
00:14:02.600 --> 00:14:05.639
<v Speaker 2>in your real time. It's primarily a management tool for

256
00:14:05.679 --> 00:14:07.320
<v Speaker 2>operational awareness.

257
00:14:06.879 --> 00:14:08.480
<v Speaker 1>Right versus continuous auditing.

258
00:14:08.600 --> 00:14:12.399
<v Speaker 2>Yes, continuous auditing is different. That's the ongoing assessment process

259
00:14:12.480 --> 00:14:16.919
<v Speaker 2>conducted by auditors internal or external to determine the actual

260
00:14:16.960 --> 00:14:23.080
<v Speaker 2>fulfillment of service level objectives, service qualitative objectives, control effectiveness,

261
00:14:23.480 --> 00:14:26.919
<v Speaker 2>so provides assurance. It's the mechanism that provides ongoing assurance

262
00:14:26.960 --> 00:14:30.360
<v Speaker 2>that controls are always operating effectively, not just on the

263
00:14:30.399 --> 00:14:33.080
<v Speaker 2>specific day the auditor happens to show up and test them.

264
00:14:33.399 --> 00:14:38.720
<v Speaker 1>And this whole need for speed for continuous validation, it

265
00:14:38.799 --> 00:14:42.679
<v Speaker 1>inevitably pushes security earlier in the process. Doesn't it into

266
00:14:42.679 --> 00:14:46.200
<v Speaker 1>the development cycle itself. We hear terms like DevSecOps and

267
00:14:46.240 --> 00:14:47.519
<v Speaker 1>shifting security.

268
00:14:47.159 --> 00:14:51.759
<v Speaker 2>Less absolutely unavoidable. Modern software development relies heavily on automated

269
00:14:51.799 --> 00:14:56.559
<v Speaker 2>practices like continuous integration, continuous delivery and continuous deployment the

270
00:14:56.600 --> 00:14:58.279
<v Speaker 2>CICD pipeline.

271
00:14:57.840 --> 00:14:59.559
<v Speaker 1>Right, pushing code changes frequently.

272
00:14:59.639 --> 00:15:02.039
<v Speaker 2>You simply it can't wait until the application is deployed

273
00:15:02.039 --> 00:15:05.240
<v Speaker 2>to production to find critical security flaws. It's too late,

274
00:15:05.440 --> 00:15:10.360
<v Speaker 2>too expensive, too risky. Security must be embedded earlier, shifted left,

275
00:15:10.399 --> 00:15:13.320
<v Speaker 2>as they say, right into the software development life cycle itself.

276
00:15:13.720 --> 00:15:17.679
<v Speaker 2>Automated security testing, code scanning, dependency checks all part of

277
00:15:17.720 --> 00:15:18.480
<v Speaker 2>the build process.

278
00:15:18.519 --> 00:15:21.279
<v Speaker 1>So this fundamentally changes the auditor's job too, right, They

279
00:15:21.279 --> 00:15:23.960
<v Speaker 1>aren't just auditing the final production system anymore if they're

280
00:15:23.960 --> 00:15:29.240
<v Speaker 1>actually auditing the automation pipelines themselves. The CICD tools and processes.

281
00:15:28.799 --> 00:15:32.639
<v Speaker 2>Correct the focus shifts. The auditor now needs to verify

282
00:15:32.799 --> 00:15:37.200
<v Speaker 2>that effective security gates are consistently built into that automated pipeline.

283
00:15:37.519 --> 00:15:41.279
<v Speaker 2>They need assurance that the automation processes themselves are reliably

284
00:15:41.279 --> 00:15:44.639
<v Speaker 2>producing code that has built in auditability and meets compliance

285
00:15:44.720 --> 00:15:46.360
<v Speaker 2>checks before it ever gets deployed.

286
00:15:46.679 --> 00:15:49.279
<v Speaker 1>So you audit the factory, not just the car coming

287
00:15:49.360 --> 00:15:49.879
<v Speaker 1>off a line.

288
00:15:49.919 --> 00:15:52.919
<v Speaker 2>That's a perfect analogy. You verify that the automated process

289
00:15:52.960 --> 00:15:56.759
<v Speaker 2>guarantees security before deployment, rather than just checking the security

290
00:15:56.759 --> 00:15:58.039
<v Speaker 2>status after deployment.

291
00:15:58.159 --> 00:16:00.639
<v Speaker 1>Okay, so let's write this up. What does this all

292
00:16:00.679 --> 00:16:04.720
<v Speaker 1>mean for you, the organization consuming these cloud services? I

293
00:16:04.759 --> 00:16:08.559
<v Speaker 1>mean the very existence of these specialized frameworks like the CCM,

294
00:16:08.879 --> 00:16:12.960
<v Speaker 1>the transparency hopefully offered by the CIIQ, and this rigorous

295
00:16:13.120 --> 00:16:16.480
<v Speaker 1>multi level star program. It shows just how much effort

296
00:16:16.519 --> 00:16:18.879
<v Speaker 1>the industry has poured into ensuring that trust can actually

297
00:16:18.960 --> 00:16:21.120
<v Speaker 1>exist in environments you don't physically control.

298
00:16:21.399 --> 00:16:26.120
<v Speaker 2>It really does. But we started by discussing accountability versus responsibility,

299
00:16:26.159 --> 00:16:29.639
<v Speaker 2>and honestly, that is the most critical takeaway here. Even

300
00:16:29.679 --> 00:16:33.320
<v Speaker 2>with all these sophisticated layers of third party controls, the

301
00:16:33.399 --> 00:16:38.679
<v Speaker 2>specialized governance frameworks, the risk management efforts, the ultimate accountability

302
00:16:38.759 --> 00:16:42.799
<v Speaker 2>lies squarely with you, the cloud customer. You must execute

303
00:16:42.799 --> 00:16:45.840
<v Speaker 2>that continuous due diligence. You have to ensure that shared

304
00:16:45.879 --> 00:16:50.360
<v Speaker 2>responsibility model is mapped out, clearly, understood and audited correctly

305
00:16:50.720 --> 00:16:52.360
<v Speaker 2>for your specific use case.

306
00:16:52.600 --> 00:16:56.480
<v Speaker 1>Understanding that distinction is absolutely paramount, because while you can

307
00:16:56.840 --> 00:16:59.720
<v Speaker 1>and often must outsource the execution of a control to

308
00:16:59.759 --> 00:17:04.359
<v Speaker 1>your SAE, you can never ever outsource the ultimate accountability

309
00:17:04.440 --> 00:17:07.079
<v Speaker 1>for protecting your data and meeting your obligations.

310
00:17:07.160 --> 00:17:09.440
<v Speaker 2>That's the fundamental truth and you know. Just to hammer

311
00:17:09.480 --> 00:17:12.319
<v Speaker 2>this point home, here is a really stark figure from

312
00:17:12.359 --> 00:17:15.200
<v Speaker 2>one of our sources that underscores exactly why understanding this

313
00:17:15.279 --> 00:17:18.440
<v Speaker 2>two dimensional governance model is so critical for any organization

314
00:17:18.599 --> 00:17:21.279
<v Speaker 2>using the cloud. A report from Gartner suggests that over

315
00:17:21.319 --> 00:17:25.720
<v Speaker 2>the next five years at least get this, ninety nine

316
00:17:25.799 --> 00:17:28.960
<v Speaker 2>percent of cloud security failures will actually be the customer's fault.

317
00:17:29.039 --> 00:17:30.119
<v Speaker 1>Ninety nine percent.

318
00:17:30.279 --> 00:17:34.599
<v Speaker 2>Ninety nine percent, that massive, almost overwhelming number. It just

319
00:17:34.680 --> 00:17:38.799
<v Speaker 2>reinforces the reality the technical security operations might be largely outsourced,

320
00:17:38.920 --> 00:17:42.400
<v Speaker 2>but the ownership of governance, the compliance posture, the risk

321
00:17:42.480 --> 00:17:46.240
<v Speaker 2>management decisions that must remain firmly rooted within your organization,

322
00:17:46.319 --> 00:17:49.079
<v Speaker 2>the consuming organization. It's non negotiable.