1
00:00:05,239 --> 00:00:07,259
[music]

2
00:00:09,825 --> 00:00:11,845
[music]

3
00:00:15,200 --> 00:00:19,039
Our next presenter is Shiaoan Lee. She

4
00:00:19,039 --> 00:00:21,039
will be presenting

5
00:00:21,039 --> 00:00:23,920
privacy data encryption and deletion

6
00:00:23,920 --> 00:00:27,039
while preserving analytical integrity.

7
00:00:27,039 --> 00:00:29,119
Please give a very warm welcome to Shiao

8
00:00:29,119 --> 00:00:32,150
Han. [applause]

9
00:00:34,000 --> 00:00:37,760
Thank you. Good afternoon everyone.

10
00:00:37,760 --> 00:00:40,239
Thank you all for being here. My name is

11
00:00:40,239 --> 00:00:43,520
Xiaoan. I work as an analytics engineer

12
00:00:43,520 --> 00:00:46,960
and consultant at Zia Data based in the

13
00:00:46,960 --> 00:00:50,879
Netherlands. I flew 27 hours to get here

14
00:00:50,879 --> 00:00:54,399
from the Netherlands. So, I am extremely

15
00:00:54,399 --> 00:00:57,520
jet-lacked and sleepd deprived. So, I

16
00:00:57,520 --> 00:01:00,480
hope I'm going to make sense today.

17
00:01:00,480 --> 00:01:03,199
And if I start yawning on stage, don't

18
00:01:03,199 --> 00:01:04,799
worry. It's not because I find you

19
00:01:04,799 --> 00:01:07,799
boring.

20
00:01:08,080 --> 00:01:10,880
I'm here to talk about data privacy and

21
00:01:10,880 --> 00:01:12,560
security.

22
00:01:12,560 --> 00:01:14,159
Have you ever checked whether your

23
00:01:14,159 --> 00:01:16,560
information is in one of those bridge

24
00:01:16,560 --> 00:01:19,119
databases?

25
00:01:19,119 --> 00:01:22,320
If you've been clients of Optus,

26
00:01:22,320 --> 00:01:24,000
Medbank,

27
00:01:24,000 --> 00:01:26,880
if you've flown with Quantis,

28
00:01:26,880 --> 00:01:28,720
your data is probably out there

29
00:01:28,720 --> 00:01:31,759
somewhere on the internet for everyone

30
00:01:31,759 --> 00:01:35,600
to download and forever.

31
00:01:35,600 --> 00:01:36,240
Now, [snorts]

32
00:01:36,240 --> 00:01:39,600
out of those bridge databases, a lot of

33
00:01:39,600 --> 00:01:42,000
those information are from former

34
00:01:42,000 --> 00:01:44,640
customers. But means even when you

35
00:01:44,640 --> 00:01:47,119
stopped using a service

36
00:01:47,119 --> 00:01:49,200
when an when the breach happens at your

37
00:01:49,200 --> 00:01:54,560
old supplier it will still affect you.

38
00:01:54,560 --> 00:01:58,799
Um there are laws around the globe that

39
00:01:58,799 --> 00:02:03,040
are that are starting to catch up

40
00:02:03,040 --> 00:02:07,240
to protect our data privacy.

41
00:02:10,800 --> 00:02:13,920
I live in the EU and we have adopted the

42
00:02:13,920 --> 00:02:16,920
GDPR.

43
00:02:17,440 --> 00:02:20,879
Um, the GDPR regulates how organizations

44
00:02:20,879 --> 00:02:23,760
are allowed to store personal

45
00:02:23,760 --> 00:02:26,720
information as well as when they must

46
00:02:26,720 --> 00:02:29,280
delete personal information

47
00:02:29,280 --> 00:02:32,160
and we have the right to be forgotten.

48
00:02:32,160 --> 00:02:35,040
That means if we send an email and say

49
00:02:35,040 --> 00:02:38,080
please delete our data, the organization

50
00:02:38,080 --> 00:02:40,720
has to comply.

51
00:02:40,720 --> 00:02:43,840
And in the US, 24 states have adopted

52
00:02:43,840 --> 00:02:47,040
similar laws. And they also give the

53
00:02:47,040 --> 00:02:50,879
right to delete. And here in Australia,

54
00:02:50,879 --> 00:02:53,599
we have the Australian Privacy Act,

55
00:02:53,599 --> 00:02:55,920
Privacy Act that also require

56
00:02:55,920 --> 00:02:59,200
organizations to ensure the security of

57
00:02:59,200 --> 00:03:03,680
data and to destroy or deidentify data

58
00:03:03,680 --> 00:03:07,720
when it's no longer needed.

59
00:03:12,480 --> 00:03:14,080
the different the different

60
00:03:14,080 --> 00:03:18,720
jurisdictions impose similar obligations

61
00:03:18,720 --> 00:03:20,319
there. Um these are the two

62
00:03:20,319 --> 00:03:23,319
commonalities.

63
00:03:25,920 --> 00:03:29,360
First protect the data while you have it

64
00:03:29,360 --> 00:03:32,720
and delete it when no longer need it or

65
00:03:32,720 --> 00:03:35,120
when someone asks.

66
00:03:35,120 --> 00:03:37,040
However, even when the laws are in

67
00:03:37,040 --> 00:03:40,319
place, the compliance and implementation

68
00:03:40,319 --> 00:03:44,200
is still lagging behind.

69
00:03:46,879 --> 00:03:49,280
I am one of those customers in the EU

70
00:03:49,280 --> 00:03:51,760
that have invoked my right to be

71
00:03:51,760 --> 00:03:53,519
forgotten

72
00:03:53,519 --> 00:03:56,239
of writing that annoying email saying,

73
00:03:56,239 --> 00:04:00,000
"Hey, delete my data." And then give the

74
00:04:00,000 --> 00:04:03,680
entire data team a headache.

75
00:04:03,680 --> 00:04:06,239
It's been 10 years since we adopted the

76
00:04:06,239 --> 00:04:09,519
GDPR. Can you imagine that some of these

77
00:04:09,519 --> 00:04:12,319
organizations still haven't returned to

78
00:04:12,319 --> 00:04:15,680
my email? It's such a simple request,

79
00:04:15,680 --> 00:04:17,840
right? Why can't they just press the

80
00:04:17,840 --> 00:04:20,720
delete button?

81
00:04:20,720 --> 00:04:22,800
And that's what I'm here to talk about

82
00:04:22,800 --> 00:04:25,800
today.

83
00:04:26,639 --> 00:04:29,440
I want to address two problems of a lot

84
00:04:29,440 --> 00:04:31,440
of data platforms.

85
00:04:31,440 --> 00:04:34,080
One is security and the other is

86
00:04:34,080 --> 00:04:36,639
deletion.

87
00:04:36,639 --> 00:04:39,120
First security.

88
00:04:39,120 --> 00:04:41,520
This is how data is usually stored in a

89
00:04:41,520 --> 00:04:44,080
warehouse. Sensitive personal

90
00:04:44,080 --> 00:04:47,360
information is exposed in plain text.

91
00:04:47,360 --> 00:04:50,080
Therefore, any employee of that

92
00:04:50,080 --> 00:04:52,639
organization has access to personal

93
00:04:52,639 --> 00:04:54,800
data.

94
00:04:54,800 --> 00:04:58,479
And some companies make a step further

95
00:04:58,479 --> 00:05:02,240
to install role- based access policies.

96
00:05:02,240 --> 00:05:04,800
So this is a solid step that restricts

97
00:05:04,800 --> 00:05:07,919
internal access. However, in the event

98
00:05:07,919 --> 00:05:11,759
of a breach, your data is leaked

99
00:05:11,759 --> 00:05:15,960
regardless of your access policies.

100
00:05:17,120 --> 00:05:19,440
Next one is deletion.

101
00:05:19,440 --> 00:05:22,720
Deletion across every table. Let's say

102
00:05:22,720 --> 00:05:26,240
we have customer number two here, Bob,

103
00:05:26,240 --> 00:05:29,520
who wants their personal data deleted.

104
00:05:29,520 --> 00:05:32,000
Why is it not as simple as just pressing

105
00:05:32,000 --> 00:05:34,880
the delete button?

106
00:05:34,880 --> 00:05:36,880
Because

107
00:05:36,880 --> 00:05:39,199
data doesn't arrive in the shape of how

108
00:05:39,199 --> 00:05:41,600
we use it.

109
00:05:41,600 --> 00:05:44,479
We model and transform data across

110
00:05:44,479 --> 00:05:48,240
different layers from staging to

111
00:05:48,240 --> 00:05:51,440
intermediate to mods and sometimes even

112
00:05:51,440 --> 00:05:54,440
domains.

113
00:05:54,880 --> 00:05:57,840
So the same piece of information is

114
00:05:57,840 --> 00:06:00,800
copied multiple times

115
00:06:00,800 --> 00:06:04,560
across the lineage and

116
00:06:04,560 --> 00:06:08,000
exist in multiple copies. So in order to

117
00:06:08,000 --> 00:06:10,720
delete one person's data through the

118
00:06:10,720 --> 00:06:13,600
conventional delete approach, we have to

119
00:06:13,600 --> 00:06:16,880
scan every table across the system and

120
00:06:16,880 --> 00:06:19,440
locate this customer everywhere and then

121
00:06:19,440 --> 00:06:22,400
we run a delete statement in all of

122
00:06:22,400 --> 00:06:24,880
these tables.

123
00:06:24,880 --> 00:06:26,960
Now why [snorts] do the delete statement

124
00:06:26,960 --> 00:06:30,000
fail? The consequences of the

125
00:06:30,000 --> 00:06:32,880
conventional delete. First disadvantage

126
00:06:32,880 --> 00:06:35,520
is that we cannot guarantee we found

127
00:06:35,520 --> 00:06:39,600
every copy. If we miss one table or one

128
00:06:39,600 --> 00:06:42,639
copy, we failed compliances.

129
00:06:42,639 --> 00:06:45,440
And second, referential integrity and

130
00:06:45,440 --> 00:06:48,720
analytical integrity breaks. After we've

131
00:06:48,720 --> 00:06:52,160
deleted all rows containing Bob's data,

132
00:06:52,160 --> 00:06:54,319
we might be left with often foreign

133
00:06:54,319 --> 00:06:57,919
keys. The joins might not work anymore

134
00:06:57,919 --> 00:07:00,080
and our row counts would change. And

135
00:07:00,080 --> 00:07:02,319
that means all our an analytical

136
00:07:02,319 --> 00:07:05,039
aggregations would also be affected such

137
00:07:05,039 --> 00:07:08,800
as total revenue, average sales, all our

138
00:07:08,800 --> 00:07:10,880
historic historical reports will no

139
00:07:10,880 --> 00:07:14,120
longer reconcile.

140
00:07:14,319 --> 00:07:17,680
And lastly, it does not scale. Say your

141
00:07:17,680 --> 00:07:20,960
organization is growing and maybe you

142
00:07:20,960 --> 00:07:24,240
adopt a data mesh. So multiple domain

143
00:07:24,240 --> 00:07:27,199
teams might be building on top of the

144
00:07:27,199 --> 00:07:29,919
same shared data models. And the more

145
00:07:29,919 --> 00:07:32,400
tables you have, the higher the risk

146
00:07:32,400 --> 00:07:35,520
that you would miss a copy and also the

147
00:07:35,520 --> 00:07:37,520
higher the impact when you do delete

148
00:07:37,520 --> 00:07:40,520
data.

149
00:07:40,960 --> 00:07:46,280
So we need an approach that can scale.

150
00:07:46,319 --> 00:07:48,000
And that's why I want to share with you

151
00:07:48,000 --> 00:07:50,479
a different approach. The crypto

152
00:07:50,479 --> 00:07:53,120
shredding pattern. It turns the data

153
00:07:53,120 --> 00:07:56,160
scanning problem into a key management

154
00:07:56,160 --> 00:07:58,240
problem.

155
00:07:58,240 --> 00:08:00,400
With this approach, we don't need to

156
00:08:00,400 --> 00:08:03,599
find a copy of the data and we don't

157
00:08:03,599 --> 00:08:06,720
even need to delete the data because

158
00:08:06,720 --> 00:08:09,520
data is data stored in the warehouse is

159
00:08:09,520 --> 00:08:13,879
unreadable in the first place.

160
00:08:16,960 --> 00:08:19,120
the fundamental mechanism of crypto

161
00:08:19,120 --> 00:08:22,400
shredding. On the crypto side, we

162
00:08:22,400 --> 00:08:25,840
encrypt data with a key and as long as

163
00:08:25,840 --> 00:08:28,400
we still have the key, we can decrypt

164
00:08:28,400 --> 00:08:30,240
the data.

165
00:08:30,240 --> 00:08:33,519
Then on the shredding side, if we delete

166
00:08:33,519 --> 00:08:36,399
a key, the corresponding data will

167
00:08:36,399 --> 00:08:39,039
become permanently unreadable

168
00:08:39,039 --> 00:08:42,080
and as a result, the original data is

169
00:08:42,080 --> 00:08:44,720
destroyed.

170
00:08:44,720 --> 00:08:47,120
Now this is a fundamental structure of

171
00:08:47,120 --> 00:08:49,279
crypto shredding in highly simplified

172
00:08:49,279 --> 00:08:52,320
terms and when it comes to implementing

173
00:08:52,320 --> 00:08:56,240
this in practice in our data platforms

174
00:08:56,240 --> 00:08:59,839
there are a lot of intricacies involved.

175
00:08:59,839 --> 00:09:01,680
Let me show you how I've designed the

176
00:09:01,680 --> 00:09:05,480
the pipeline architecture.

177
00:09:11,680 --> 00:09:14,399
two principles.

178
00:09:14,399 --> 00:09:17,279
First, encryption during ingestion

179
00:09:17,279 --> 00:09:19,920
before data loads in your warehouse.

180
00:09:19,920 --> 00:09:23,440
This way, sensitive information will not

181
00:09:23,440 --> 00:09:25,600
reach your warehouse.

182
00:09:25,600 --> 00:09:28,560
And secondly, store keys separately

183
00:09:28,560 --> 00:09:31,279
outside your data platform

184
00:09:31,279 --> 00:09:33,839
in a dedicated key store with its own

185
00:09:33,839 --> 00:09:36,640
dedicated access controls.

186
00:09:36,640 --> 00:09:39,200
Do not hold the encryption key and the

187
00:09:39,200 --> 00:09:43,839
encrypted data at the same location.

188
00:09:43,839 --> 00:09:46,640
These two principles combined ensure

189
00:09:46,640 --> 00:09:49,360
that your data is protected even during

190
00:09:49,360 --> 00:09:51,120
a breach.

191
00:09:51,120 --> 00:09:54,240
If and when a bridge happens, what is

192
00:09:54,240 --> 00:09:58,399
leaked is unreadable cipher text and the

193
00:09:58,399 --> 00:10:01,519
original information is safe because our

194
00:10:01,519 --> 00:10:07,360
keys are stored safely somewhere else.

195
00:10:12,080 --> 00:10:14,720
I've been building a

196
00:10:14,720 --> 00:10:17,680
an open-source Python library called the

197
00:10:17,680 --> 00:10:20,560
GDPR officer to simplify the

198
00:10:20,560 --> 00:10:22,800
implementation of this crypto shredding

199
00:10:22,800 --> 00:10:24,800
pipeline architecture.

200
00:10:24,800 --> 00:10:27,040
And with this I give you the delete

201
00:10:27,040 --> 00:10:30,040
button.

202
00:10:32,399 --> 00:10:36,079
There are three core functions

203
00:10:36,079 --> 00:10:40,320
encrypt, decrypt and forget.

204
00:10:40,320 --> 00:10:43,200
Forget comes from the GDPR terminology,

205
00:10:43,200 --> 00:10:45,440
the right to be forgotten. And this is

206
00:10:45,440 --> 00:10:49,000
our delete button.

207
00:10:52,959 --> 00:10:55,040
I'll briefly introduce the encryption

208
00:10:55,040 --> 00:10:57,680
method. I'll use the industry standard

209
00:10:57,680 --> 00:11:00,680
AESGCM.

210
00:11:02,867 --> 00:11:03,760
[snorts]

211
00:11:03,760 --> 00:11:06,880
First we generate a key for each unique

212
00:11:06,880 --> 00:11:09,760
customer or unique person. We check

213
00:11:09,760 --> 00:11:12,079
whether a customer already exists in our

214
00:11:12,079 --> 00:11:15,920
warehouse. If not we generate a key and

215
00:11:15,920 --> 00:11:20,640
otherwise we use the existing key.

216
00:11:20,640 --> 00:11:25,040
Then for each value we encrypt it with a

217
00:11:25,040 --> 00:11:28,320
random nouns a number used once.

218
00:11:28,320 --> 00:11:31,120
And let me explain this

219
00:11:31,120 --> 00:11:34,399
why the random nons matters.

220
00:11:34,399 --> 00:11:38,000
The same value appears multiple times in

221
00:11:38,000 --> 00:11:40,720
our in our data and without the random

222
00:11:40,720 --> 00:11:42,399
nons

223
00:11:42,399 --> 00:11:44,800
uh the same value will will output the

224
00:11:44,800 --> 00:11:48,000
same cipher text. So if an attacker gets

225
00:11:48,000 --> 00:11:50,640
hands on our data,

226
00:11:50,640 --> 00:11:52,880
they will be able to detect a pattern

227
00:11:52,880 --> 00:11:56,079
and use it to target certain individuals

228
00:11:56,079 --> 00:11:59,360
or to infer the representation of the

229
00:11:59,360 --> 00:12:01,760
repeated cipher text using the

230
00:12:01,760 --> 00:12:03,519
statistical distribution of different

231
00:12:03,519 --> 00:12:06,800
values and this undermines the security

232
00:12:06,800 --> 00:12:09,600
of our data.

233
00:12:09,600 --> 00:12:12,560
When we add the random nons, the sign

234
00:12:12,560 --> 00:12:15,440
value will encrypt into different output

235
00:12:15,440 --> 00:12:18,720
to prevent pattern detection. This extra

236
00:12:18,720 --> 00:12:21,760
steps, this extra step protects us from

237
00:12:21,760 --> 00:12:25,720
a false sensor security.

238
00:12:27,920 --> 00:12:31,360
And lastly, we only need the key to

239
00:12:31,360 --> 00:12:34,880
encry to decrypt. The nons is embedded

240
00:12:34,880 --> 00:12:38,079
in the cipher text. And that means we

241
00:12:38,079 --> 00:12:40,320
don't have any additional external

242
00:12:40,320 --> 00:12:44,160
dependencies to store or to manage. We

243
00:12:44,160 --> 00:12:48,760
only need the key to decrypt.

244
00:12:53,440 --> 00:12:56,000
So we need to add one piece of code to

245
00:12:56,000 --> 00:13:00,480
our pipeline and pass two arguments.

246
00:13:00,480 --> 00:13:02,480
First, what is the name of the unique

247
00:13:02,480 --> 00:13:04,800
customer ID column

248
00:13:04,800 --> 00:13:08,480
and also what are the names of the PII

249
00:13:08,480 --> 00:13:12,160
columns that we want to encrypt and PII

250
00:13:12,160 --> 00:13:14,160
stands for personally identifiable

251
00:13:14,160 --> 00:13:16,959
information

252
00:13:16,959 --> 00:13:19,519
and all the other nonPI columns would

253
00:13:19,519 --> 00:13:23,079
pass through unchanged.

254
00:13:24,560 --> 00:13:28,320
So here we've identified the customer ID

255
00:13:28,320 --> 00:13:33,079
column and the PII columns.

256
00:13:41,040 --> 00:13:44,399
Apart from encryption, I've also created

257
00:13:44,399 --> 00:13:46,480
an option to generalize sensitive

258
00:13:46,480 --> 00:13:50,480
columns into nonsensitive data. And I'll

259
00:13:50,480 --> 00:13:52,639
show you later in the demo.

260
00:13:52,639 --> 00:13:54,880
So what what does your data look like in

261
00:13:54,880 --> 00:13:57,120
the warehouse?

262
00:13:57,120 --> 00:14:01,360
The sensitive columns are

263
00:14:01,360 --> 00:14:05,279
are encrypted and the revenue column

264
00:14:05,279 --> 00:14:07,519
which we did not touch earlier pass

265
00:14:07,519 --> 00:14:09,760
through unchanged.

266
00:14:09,760 --> 00:14:11,760
So we can still use these numbers for

267
00:14:11,760 --> 00:14:14,760
analytics.

268
00:14:16,000 --> 00:14:18,399
Now, customer number two, Bob here

269
00:14:18,399 --> 00:14:21,680
requested to have his data deleted. And

270
00:14:21,680 --> 00:14:24,160
we press our delete button by calling

271
00:14:24,160 --> 00:14:26,560
the forget function on customer number

272
00:14:26,560 --> 00:14:31,639
two. And we also log it.

273
00:14:39,675 --> 00:14:40,000
[snorts]

274
00:14:40,000 --> 00:14:42,959
So after we've deleted Bob's encryption

275
00:14:42,959 --> 00:14:45,199
key, let's try and decrypt the data

276
00:14:45,199 --> 00:14:49,440
again. And we call the decrypt function.

277
00:14:49,440 --> 00:14:52,639
We see that other customers data decrypt

278
00:14:52,639 --> 00:14:56,720
as normal. Whereas customer number two,

279
00:14:56,720 --> 00:15:00,560
his personal data stays cipher text. Yet

280
00:15:00,560 --> 00:15:04,360
non-personal data

281
00:15:04,399 --> 00:15:07,360
such as revenue remains. The row counts

282
00:15:07,360 --> 00:15:10,000
do not change and all the aggregations

283
00:15:10,000 --> 00:15:12,720
will still resolve the same numbers.

284
00:15:12,720 --> 00:15:17,160
Analytics is completely intact.

285
00:15:18,079 --> 00:15:22,760
Now let me show you a demo.

286
00:15:40,639 --> 00:15:44,160
So, we've got two two tables here that

287
00:15:44,160 --> 00:15:46,720
contain sensitive information. The

288
00:15:46,720 --> 00:15:50,800
customers table and the invoice table.

289
00:15:50,800 --> 00:15:52,880
And

290
00:15:52,880 --> 00:15:56,240
we encrypt by identifying the customer

291
00:15:56,240 --> 00:15:59,519
ID column and the PII columns that we

292
00:15:59,519 --> 00:16:01,759
want to encrypt.

293
00:16:01,759 --> 00:16:04,320
And we've also added the generalized

294
00:16:04,320 --> 00:16:07,759
option here. We're generalizing the n

295
00:16:07,759 --> 00:16:10,959
nationality column into a new column

296
00:16:10,959 --> 00:16:14,800
called region by providing a mapping of

297
00:16:14,800 --> 00:16:17,959
the values

298
00:16:18,581 --> 00:16:19,759
[snorts]

299
00:16:19,759 --> 00:16:22,720
and we also encrypt the invoices column

300
00:16:22,720 --> 00:16:26,279
invoices table.

301
00:16:28,079 --> 00:16:30,079
So this is how data lands in our

302
00:16:30,079 --> 00:16:32,880
warehouse.

303
00:16:33,759 --> 00:16:38,231
The PI columns are cipher text

304
00:16:38,231 --> 00:16:39,680
[snorts]

305
00:16:39,680 --> 00:16:42,800
and we have customer number two appear

306
00:16:42,800 --> 00:16:46,480
three times in our two tables. The same

307
00:16:46,480 --> 00:16:49,959
email address

308
00:16:50,000 --> 00:16:52,399
they in they they do they encrypt into

309
00:16:52,399 --> 00:16:54,880
three different output.

310
00:16:54,880 --> 00:16:59,680
So this prevents pattern detection

311
00:16:59,680 --> 00:17:02,800
and our revenue and invoice amount

312
00:17:02,800 --> 00:17:05,039
columns which we did not touch earlier

313
00:17:05,039 --> 00:17:07,439
pass through.

314
00:17:07,439 --> 00:17:09,360
And additionally we've created a new

315
00:17:09,360 --> 00:17:12,240
column region generalized from

316
00:17:12,240 --> 00:17:14,559
nationality so that we could still do

317
00:17:14,559 --> 00:17:18,240
analytics on top of a sensitive column.

318
00:17:18,240 --> 00:17:21,280
However, there is one caveat. Keep in

319
00:17:21,280 --> 00:17:24,160
mind while using generalization

320
00:17:24,160 --> 00:17:26,400
because the generalized generalized

321
00:17:26,400 --> 00:17:28,880
column is considered to be nonsensitive

322
00:17:28,880 --> 00:17:32,160
data. So it's not encrypted and it will

323
00:17:32,160 --> 00:17:35,600
survive crypto shredding. And sometimes

324
00:17:35,600 --> 00:17:38,640
the combinations of multiple nonPI

325
00:17:38,640 --> 00:17:41,840
columns can be used together to identify

326
00:17:41,840 --> 00:17:46,160
an individual. So for example, someone

327
00:17:46,160 --> 00:17:48,720
from a certain region does not identify

328
00:17:48,720 --> 00:17:51,600
someone. Someone of a certain age does

329
00:17:51,600 --> 00:17:54,559
not identify anyone and someone who

330
00:17:54,559 --> 00:17:57,120
works in cyber security does not

331
00:17:57,120 --> 00:17:59,679
identify anyone. However, when we put

332
00:17:59,679 --> 00:18:02,640
this together, someone from a certain

333
00:18:02,640 --> 00:18:06,000
region of a certain age who works in

334
00:18:06,000 --> 00:18:10,480
cyber security and etc etc. when we add

335
00:18:10,480 --> 00:18:13,840
these attributes to it, the combination

336
00:18:13,840 --> 00:18:17,120
of them could become uh personally

337
00:18:17,120 --> 00:18:20,400
identifiable even though when isolated

338
00:18:20,400 --> 00:18:23,280
none of the attributes can.

339
00:18:23,280 --> 00:18:24,799
So

340
00:18:24,799 --> 00:18:27,520
while you use generalization

341
00:18:27,520 --> 00:18:29,919
always consult your data privacy officer

342
00:18:29,919 --> 00:18:33,440
and consult your legal team to review

343
00:18:33,440 --> 00:18:36,320
this case by case whether the particular

344
00:18:36,320 --> 00:18:38,799
generalization fulfills compliance

345
00:18:38,799 --> 00:18:41,799
requirements.

346
00:18:47,922 --> 00:18:48,720
[snorts]

347
00:18:48,720 --> 00:18:51,520
Now we can still run analytics straight

348
00:18:51,520 --> 00:18:54,799
from these incre encrypted tables.

349
00:18:54,799 --> 00:18:57,520
Calculate the total number of customers,

350
00:18:57,520 --> 00:19:01,840
the total revenue and and we can also

351
00:19:01,840 --> 00:19:06,320
aggregate by using the region column to

352
00:19:06,320 --> 00:19:10,400
do analytics on top of sensitive data.

353
00:19:10,400 --> 00:19:12,320
And we can also join the two tables

354
00:19:12,320 --> 00:19:15,320
together.

355
00:19:15,840 --> 00:19:18,720
And inside the key store,

356
00:19:18,720 --> 00:19:21,520
we've stored one customer key for each

357
00:19:21,520 --> 00:19:23,840
unique customer.

358
00:19:23,840 --> 00:19:26,720
And the creation time is locked in UTC

359
00:19:26,720 --> 00:19:29,039
as standard. So if you have multiple

360
00:19:29,039 --> 00:19:32,240
teams working from different time zones,

361
00:19:32,240 --> 00:19:36,760
your records stay standardized

362
00:19:38,880 --> 00:19:42,080
and we can decrypt the data

363
00:19:42,080 --> 00:19:45,720
if we need it.

364
00:19:46,640 --> 00:19:49,280
Then let's try and forget customer

365
00:19:49,280 --> 00:19:54,039
number two who requested to be deleted.

366
00:19:55,840 --> 00:19:59,440
So we call the forget function and we

367
00:19:59,440 --> 00:20:03,120
log it down the reason

368
00:20:03,120 --> 00:20:06,799
and inside our key store we've deleted

369
00:20:06,799 --> 00:20:10,559
customer number two's key.

370
00:20:10,559 --> 00:20:13,360
Let's try and decrypt our data again.

371
00:20:13,360 --> 00:20:16,160
And this is what we'll get.

372
00:20:16,160 --> 00:20:18,960
All the other customers decrypt as

373
00:20:18,960 --> 00:20:22,320
normal. Whereas customer number two, his

374
00:20:22,320 --> 00:20:25,200
personally identifiable information

375
00:20:25,200 --> 00:20:28,559
remains cipher text. So all all his

376
00:20:28,559 --> 00:20:31,200
information are forgotten.

377
00:20:31,200 --> 00:20:35,559
What was his name again? I forgot.

378
00:20:36,320 --> 00:20:40,000
Now the revenue still reads the same and

379
00:20:40,000 --> 00:20:42,320
all our aggregations will still resolve

380
00:20:42,320 --> 00:20:44,960
to the same numbers. Our dashboard will

381
00:20:44,960 --> 00:20:48,159
not change

382
00:20:48,159 --> 00:20:49,280
and [snorts]

383
00:20:49,280 --> 00:20:52,080
we only deleted one key. We did not need

384
00:20:52,080 --> 00:20:56,159
to scan all our tables. So one single

385
00:20:56,159 --> 00:21:01,960
action deletion across our system

386
00:21:02,240 --> 00:21:06,440
and that's it. Bob's your uncle.

387
00:21:08,320 --> 00:21:12,440
Let me get back to the slides.

388
00:21:20,539 --> 00:21:21,360
[snorts]

389
00:21:21,360 --> 00:21:23,679
Earlier I suggested to do the encryption

390
00:21:23,679 --> 00:21:26,960
during ingestion and the advantage is

391
00:21:26,960 --> 00:21:29,760
that if you would pre um you would

392
00:21:29,760 --> 00:21:31,760
prevent sensitive information from

393
00:21:31,760 --> 00:21:35,280
landing in your data platform in exposed

394
00:21:35,280 --> 00:21:38,480
plain text. However, if you use a

395
00:21:38,480 --> 00:21:40,799
managed ingestion service like five

396
00:21:40,799 --> 00:21:44,320
trend or stitch or or air bite and you

397
00:21:44,320 --> 00:21:47,039
don't own the ingestion step, then the

398
00:21:47,039 --> 00:21:48,400
encryption would have to come

399
00:21:48,400 --> 00:21:50,320
afterwards.

400
00:21:50,320 --> 00:21:52,080
For this, I suggest an alternative

401
00:21:52,080 --> 00:21:53,840
architecture.

402
00:21:53,840 --> 00:21:56,799
First, we ingest the data into a raw

403
00:21:56,799 --> 00:21:58,880
layer which contains sensitive

404
00:21:58,880 --> 00:22:00,480
information.

405
00:22:00,480 --> 00:22:04,000
Then, we encrypt the data

406
00:22:04,000 --> 00:22:06,960
and store it in a base layer.

407
00:22:06,960 --> 00:22:10,080
And once we've done that, we truncate

408
00:22:10,080 --> 00:22:13,039
the raw layer immediately.

409
00:22:13,039 --> 00:22:16,000
So this is an extra step and it follows

410
00:22:16,000 --> 00:22:19,120
the same principle. We do not expo

411
00:22:19,120 --> 00:22:22,559
expose sensitive data in plain text in

412
00:22:22,559 --> 00:22:25,799
our warehouse

413
00:22:29,440 --> 00:22:31,760
to complement our secure architecture.

414
00:22:31,760 --> 00:22:34,960
We also need um a governance framework

415
00:22:34,960 --> 00:22:39,120
for the keys and these are my advice.

416
00:22:39,120 --> 00:22:42,799
First envelope encryption wrap cosma

417
00:22:42,799 --> 00:22:45,360
keys with a master key in a key

418
00:22:45,360 --> 00:22:48,720
management system

419
00:22:48,720 --> 00:22:51,520
and add an additional layer additional

420
00:22:51,520 --> 00:22:53,039
encryption layer on top of the

421
00:22:53,039 --> 00:22:57,280
encryption keys and this give another

422
00:22:57,280 --> 00:22:59,280
layer of security

423
00:22:59,280 --> 00:23:01,840
as well as enabling key rotation which

424
00:23:01,840 --> 00:23:04,799
is my second point.

425
00:23:04,799 --> 00:23:07,679
Rotate the master keys. Schedule the

426
00:23:07,679 --> 00:23:10,559
rotation of the master key. We don't

427
00:23:10,559 --> 00:23:13,200
need to rotate the individual cosmetic

428
00:23:13,200 --> 00:23:16,000
keys themselves because that would mean

429
00:23:16,000 --> 00:23:19,039
that we need to reenrypt all the data

430
00:23:19,039 --> 00:23:20,960
all over again. So we don't need to do

431
00:23:20,960 --> 00:23:24,159
that. When rotating the master key, we

432
00:23:24,159 --> 00:23:28,640
get the security but not a hassle.

433
00:23:28,640 --> 00:23:32,799
And thirdly, retention and expiration.

434
00:23:32,799 --> 00:23:36,320
Set up an retention policy for data that

435
00:23:36,320 --> 00:23:38,799
has fulfilled its purpose and should no

436
00:23:38,799 --> 00:23:41,039
longer be stored according to the

437
00:23:41,039 --> 00:23:44,080
regulations and expire the key on a

438
00:23:44,080 --> 00:23:47,760
timer based on the policies.

439
00:23:47,760 --> 00:23:50,720
And last but not least, gated access,

440
00:23:50,720 --> 00:23:54,320
gated activity and audit.

441
00:23:54,320 --> 00:23:57,360
Install a role-based policy such as who

442
00:23:57,360 --> 00:24:00,559
has the authorization to decrypt and who

443
00:24:00,559 --> 00:24:03,520
has the authorization to delete. Lock

444
00:24:03,520 --> 00:24:06,400
down every activity and its reason for

445
00:24:06,400 --> 00:24:09,400
audit.

446
00:24:11,360 --> 00:24:13,440
Before I close off, I want to share with

447
00:24:13,440 --> 00:24:16,480
you why this matters. Now, nowadays,

448
00:24:16,480 --> 00:24:18,559
everyone's building something exciting

449
00:24:18,559 --> 00:24:21,600
with AI agents. And why should we care

450
00:24:21,600 --> 00:24:24,240
about such boring topics such as

451
00:24:24,240 --> 00:24:27,520
compliances and privacy?

452
00:24:27,520 --> 00:24:30,640
AI is already involved in every stage of

453
00:24:30,640 --> 00:24:32,799
a workflow.

454
00:24:32,799 --> 00:24:35,279
Developers use AI to write code and

455
00:24:35,279 --> 00:24:38,799
build data pipelines and AI agents read

456
00:24:38,799 --> 00:24:41,520
from our data platform to run analytical

457
00:24:41,520 --> 00:24:44,880
queries and answer business questions.

458
00:24:44,880 --> 00:24:47,840
And that means AI has access to personal

459
00:24:47,840 --> 00:24:50,799
information. Attackers

460
00:24:50,799 --> 00:24:54,400
are also using AI to find loopholes in

461
00:24:54,400 --> 00:24:59,279
their systems and initiate attacks.

462
00:24:59,279 --> 00:25:03,440
IBM published a a cost uh the cost of a

463
00:25:03,440 --> 00:25:06,880
data breach reports just a month ago and

464
00:25:06,880 --> 00:25:10,559
in the report they found 25% of

465
00:25:10,559 --> 00:25:15,600
malicious data breaches are AI enabled

466
00:25:15,600 --> 00:25:18,400
and these breaches cost on average $6

467
00:25:18,400 --> 00:25:22,240
million US each.

468
00:25:22,240 --> 00:25:25,200
Humans make mistakes and AI makes

469
00:25:25,200 --> 00:25:29,840
mistakes. And when humans use AI, the

470
00:25:29,840 --> 00:25:33,919
impact of such mistakes are amplified.

471
00:25:33,919 --> 00:25:36,799
AI can find and exploit

472
00:25:36,799 --> 00:25:40,080
the loopholes in our systems much faster

473
00:25:40,080 --> 00:25:43,360
and at a much larger scale.

474
00:25:43,360 --> 00:25:46,000
Therefore, now more than ever, we need

475
00:25:46,000 --> 00:25:50,240
to build data data foundations that are

476
00:25:50,240 --> 00:25:54,720
secure and solid and can sit through the

477
00:25:54,720 --> 00:25:58,159
storm of AI assisted attack which is on

478
00:25:58,159 --> 00:26:00,000
its way

479
00:26:00,000 --> 00:26:02,320
and I hope today I've given you an idea

480
00:26:02,320 --> 00:26:06,120
to implement that.

481
00:26:09,120 --> 00:26:12,159
So GDPR officer is open source and you

482
00:26:12,159 --> 00:26:14,720
can check it out on GitHub and [snorts]

483
00:26:14,720 --> 00:26:16,603
thank you

484
00:26:16,603 --> 00:26:18,623
[applause]

485
00:26:21,188 --> 00:26:23,208
[applause]

486
00:26:24,559 --> 00:26:27,120
Xiaoan. Thank you so much for coming all

487
00:26:27,120 --> 00:26:28,799
the way from Europe to present your

488
00:26:28,799 --> 00:26:32,400
solution to this very important problem.

489
00:26:32,400 --> 00:26:34,559
Shiaan will answer questions in the

490
00:26:34,559 --> 00:26:37,919
hallway track. So once again, give her a

491
00:26:37,919 --> 00:26:41,039
big thanks and uh here is your mug.

492
00:26:41,039 --> 00:26:44,168
Thank you. [applause]