1 00:00:00,000 --> 00:00:06,200 Welcome to the Azure Security Podcast, 2 00:00:06,200 --> 00:00:09,380 where we discuss topics relating to security, privacy, 3 00:00:09,380 --> 00:00:13,480 reliability, and compliance on the Microsoft Cloud Platform. 4 00:00:13,480 --> 00:00:16,520 Hey everybody, welcome to Episode 51. 5 00:00:16,520 --> 00:00:20,080 This week, it is myself Gladys and Mark. 6 00:00:20,080 --> 00:00:22,880 Sarah is actually busy with some work stuff. 7 00:00:22,880 --> 00:00:24,400 We also have a special guest, 8 00:00:24,400 --> 00:00:26,520 we have Thomas Weiss, who's here to talk to us about 9 00:00:26,520 --> 00:00:28,940 some of the changes in Cosmos DB security. 10 00:00:28,940 --> 00:00:30,600 Since last time he was on the podcast, 11 00:00:30,600 --> 00:00:32,760 which is June 2020. 12 00:00:32,760 --> 00:00:34,800 Yes, we've been going nearly two years. 13 00:00:34,800 --> 00:00:36,720 In fact, the next episode will be Episode 52, 14 00:00:36,720 --> 00:00:38,420 and that'll be two years. 15 00:00:38,420 --> 00:00:40,480 Before we get to the news though, I want to tell you a little story. 16 00:00:40,480 --> 00:00:43,240 It's actually a really cute little heartwarming story. 17 00:00:43,240 --> 00:00:46,160 So my mother-in-law is actually in assisted living, 18 00:00:46,160 --> 00:00:49,080 and my niece is actually in the same facility, 19 00:00:49,080 --> 00:00:51,160 but she's doing the books. 20 00:00:51,160 --> 00:00:53,880 There's a gentleman in there by the name of Mark, 21 00:00:53,880 --> 00:00:55,760 and he suffers from 22 00:00:55,760 --> 00:00:58,480 a debilitating disease called Huntington's Disease, 23 00:00:58,480 --> 00:01:03,240 which honestly I'd actually never heard of until they said this little story. 24 00:01:03,240 --> 00:01:06,040 Mark's in his 50s, 25 00:01:06,040 --> 00:01:09,600 but the thing with Huntington's is it leaves you relatively 26 00:01:09,600 --> 00:01:13,200 motionless and talking becomes restricted as well. 27 00:01:13,200 --> 00:01:16,760 My niece found out that Mark was actually in cyber security at one point, 28 00:01:16,760 --> 00:01:20,040 and she called my wife and she said, 29 00:01:20,040 --> 00:01:22,320 hey, what's the name of Uncle Michael's podcast? 30 00:01:22,320 --> 00:01:25,560 My wife gave her the name after asking me, 31 00:01:25,560 --> 00:01:28,200 because of course she had no idea what the name of the podcast was. 32 00:01:28,200 --> 00:01:32,240 So my niece found the podcast on Spotify on her phone, 33 00:01:32,240 --> 00:01:33,920 and she put the phone next to Mark. 34 00:01:33,920 --> 00:01:39,240 Mark started smiling and nodding his head as he was listening to this. 35 00:01:39,240 --> 00:01:41,800 Big shout out to Mark. Thank you for listening. 36 00:01:41,800 --> 00:01:44,800 We hope it brings you some joy. 37 00:01:44,800 --> 00:01:47,320 I was really kind of heartwarming when I heard that story. 38 00:01:47,320 --> 00:01:49,640 So with that little episode out the way, 39 00:01:49,640 --> 00:01:51,280 let's turn our attention to the news. 40 00:01:51,280 --> 00:01:53,640 Why don't we kick things off with Mark? 41 00:01:53,640 --> 00:01:55,640 Yeah, and a shout out to the other Mark too. 42 00:01:55,640 --> 00:01:58,080 So doing my best to follow that. 43 00:01:58,080 --> 00:02:03,280 One of the things that I've been waiting for for a little while has finally released. 44 00:02:03,280 --> 00:02:05,800 So there is a new release, 45 00:02:05,800 --> 00:02:09,360 the revision four of the 800-40 from NIST, 46 00:02:09,360 --> 00:02:12,000 the National Institute of Standards and Technology. 47 00:02:12,000 --> 00:02:16,480 This is NIST guidance focused on enterprise patch management. 48 00:02:16,480 --> 00:02:23,840 This work and the conversations for it started around the time just after 49 00:02:23,840 --> 00:02:27,000 the Patea, not Patea type of attacks. 50 00:02:27,000 --> 00:02:30,640 So we went through the government process to get 51 00:02:30,640 --> 00:02:34,480 a NCCOE project, 52 00:02:34,480 --> 00:02:38,560 a National Cybersecurity Center of Excellence project around patch management. 53 00:02:38,560 --> 00:02:44,480 And we need to revisit the higher level guidance as well that guides that work. 54 00:02:44,480 --> 00:02:47,040 And so the two documents, 55 00:02:47,040 --> 00:02:50,120 the 800-40 which is the overall guidance, 56 00:02:50,120 --> 00:02:52,280 including the scenarios that were tested in the lab. 57 00:02:52,280 --> 00:02:58,840 And then the lab document itself and the results from a bunch of vendors came 58 00:02:58,840 --> 00:03:02,640 into the NIST labs and helped take 59 00:03:02,640 --> 00:03:05,080 the current best practices, current knowledge, 60 00:03:05,080 --> 00:03:09,480 and implement it and show how to implement it using their technology. 61 00:03:09,480 --> 00:03:12,680 And so these two documents both came out recently. 62 00:03:12,680 --> 00:03:15,760 And then one of the nice things that's in there is, 63 00:03:15,760 --> 00:03:21,400 it didn't really treat enterprise patch management as just an isolated thing. 64 00:03:21,400 --> 00:03:25,160 It's actually sort of a normal part of how do you do maintenance, 65 00:03:25,160 --> 00:03:28,560 just like you can communicate with a business leader, 66 00:03:28,560 --> 00:03:32,760 like, hey, this is just like changing the oil and otherwise maintaining your fleet 67 00:03:32,760 --> 00:03:34,560 of trucks or planes or whatever. 68 00:03:34,560 --> 00:03:37,120 You need a little downtime, you need to do some maintenance on it. 69 00:03:37,120 --> 00:03:40,760 And so a nice focus on sort of the end-to-end view of patching, 70 00:03:40,760 --> 00:03:42,680 not just a technical practice, 71 00:03:42,680 --> 00:03:49,360 as well as some linkage to zero trust and how it fits into a zero trust concept and context rather. 72 00:03:49,360 --> 00:03:54,000 And so really, really liking that document that came out there. 73 00:03:54,000 --> 00:03:56,320 So we'll send you links for both of those. 74 00:03:56,320 --> 00:03:58,080 And that's what I got for this week. 75 00:03:58,080 --> 00:04:01,600 So, shout out for Mark as well. 76 00:04:01,600 --> 00:04:05,480 I have three news that I want to share. 77 00:04:05,480 --> 00:04:09,600 We actually just released a few days ago, actually. 78 00:04:09,600 --> 00:04:16,040 A few articles that talk about how Microsoft performed tasks 79 00:04:16,040 --> 00:04:19,960 in order to help with the Sea Loader campaign. 80 00:04:19,960 --> 00:04:24,520 One of the articles was named this Mantling Sea Loader. 81 00:04:24,520 --> 00:04:31,000 How malicious that led to disabling security tools and trying somewhere. 82 00:04:31,000 --> 00:04:38,120 I love this article because it's a perfect example of how the partnership that Microsoft is offering, 83 00:04:38,120 --> 00:04:43,320 not only to customers, but overall to the security community. 84 00:04:43,320 --> 00:04:51,560 We are following our mission, right, to empower every person and every organization on the planet to achieve more. 85 00:04:51,560 --> 00:04:58,760 So not only we have a commitment to keep improving our capabilities within our tools 86 00:04:58,760 --> 00:05:07,000 to deal with new threats and risk, which help our customer to protect, detect, respond and recover. 87 00:05:07,000 --> 00:05:12,520 But also we share our findings with the community. 88 00:05:12,520 --> 00:05:17,160 So other customers and vendors can improve their capabilities. 89 00:05:17,160 --> 00:05:20,280 So this is really important. 90 00:05:20,280 --> 00:05:25,880 The article basically goes into explaining how different capabilities, such as Microsoft Edge, 91 00:05:25,880 --> 00:05:32,680 a smart screen can be used to protect services and windows overall. 92 00:05:32,680 --> 00:05:40,440 To also how our services like Defender are using detection capabilities to protect 93 00:05:40,440 --> 00:05:46,520 and help recover if a customer is attacked with this campaign. 94 00:05:46,520 --> 00:05:53,560 The next news that I wanted to share is that this is the fourth consecutive year 95 00:05:53,560 --> 00:06:01,480 that Microsoft 365 led the Mitre and Junity Independent Attack Enterprise Evaluation. 96 00:06:02,680 --> 00:06:09,400 Basically we successfully surfaced Security Operations Center comprehensive incident 97 00:06:09,400 --> 00:06:13,400 for each of the simulated attacks that were performed. 98 00:06:13,400 --> 00:06:19,400 In the spirit of a soon compromise, yes, we provide the capabilities to protect. 99 00:06:19,400 --> 00:06:30,840 But what this shows is how we understand that it is important to detect fast and respond as fast as possible. 100 00:06:30,840 --> 00:06:35,400 And we enable that by interconnecting our products. 101 00:06:35,400 --> 00:06:43,960 So in our near real time, we could control the damage that attackers may do and recover from them. 102 00:06:43,960 --> 00:06:51,480 So by doing so, the article which was named Microsoft 365 Defender Demonstrate Industry, 103 00:06:51,480 --> 00:06:59,960 leading protection in the 2022 Mitre and Junity Attack Evaluations and is in the Microsoft blog, 104 00:06:59,960 --> 00:07:07,720 you will see where Microsoft 365 demonstrated complete technique coverage across attacks 105 00:07:07,720 --> 00:07:13,800 such as Whizzer, Spider and Sandworm. Basically they were leveraging artificial 106 00:07:13,800 --> 00:07:23,000 intelligent adaptive protection. And you see like the attack chain and how we were protecting 107 00:07:23,000 --> 00:07:24,520 those different attacks. 108 00:07:24,520 --> 00:07:31,560 Last I wanted to mention the new Unified Microsoft SIM GitHub community. 109 00:07:31,560 --> 00:07:41,560 This is a good way that Microsoft is providing a lot of information that show our efforts across 110 00:07:41,560 --> 00:07:48,440 a SIM and XDR, basically to enable the SOC team to centrally discover the latest 111 00:07:48,440 --> 00:07:55,800 hunting queries, analytics that can be used both in Microsoft's Sentinel and Defender. 112 00:07:55,800 --> 00:08:03,000 So the first news item I have is we now have some new VM types under the Azure Confidential 113 00:08:03,000 --> 00:08:09,000 Computing banner that use NVIDIA GPUs. Now the nice thing about this is that if you want to use the GPUs 114 00:08:09,000 --> 00:08:14,840 to accelerate artificial intelligence research, we can do it under these confidential compute VMs. 115 00:08:14,840 --> 00:08:20,600 Historically we have these VMs that run with various types of CPU. 116 00:08:20,600 --> 00:08:27,240 Now we have included NVIDIA GPUs as well. For those of you who are not aware, you can write code that 117 00:08:27,240 --> 00:08:34,600 runs across all the hardware threads of the GPU to parallelize the work. So it's great to see that. 118 00:08:34,600 --> 00:08:40,840 Next one is Azure Data Explorer. We talked about Azure Data Explorer a few months ago and it's a way 119 00:08:40,840 --> 00:08:48,280 of offloading, for example, massive logs to something that's a little bit more cost-effective in the 120 00:08:48,280 --> 00:08:55,400 long term. That is Azure Data Explorer. Now we've added conditional access support to 121 00:08:55,400 --> 00:09:01,320 Azure Data Explorer. That's great to see because obviously log files can contain sensitive information. 122 00:09:01,320 --> 00:09:06,760 So now we can apply conditional access policies. So for example, if someone comes in and some 123 00:09:06,760 --> 00:09:11,960 condition exists, someone wants to read this data, then they may be prompted for MFA as an example. 124 00:09:11,960 --> 00:09:20,680 Next one is Azure Load Balancer. Now it allows you to manage port forwarding for the back-end pool. 125 00:09:20,680 --> 00:09:26,520 Going to be honest with you here, I understand what it all means, but I don't necessarily understand 126 00:09:26,520 --> 00:09:33,960 exactly what's why, but managed port forwarding is now available in Azure Load Balancer at the back-end pool. 127 00:09:33,960 --> 00:09:40,360 So for those of you who care about that, you're welcome. Now this next one I do thoroughly understand 128 00:09:40,360 --> 00:09:48,040 and I'm very, very happy to see this. There's a kind of attack called a dangling DNS problem. 129 00:09:48,040 --> 00:09:53,400 And without going into all the horrible details, I will provide some links in the show notes. 130 00:09:53,400 --> 00:09:58,760 But because in Azure, and same with other cloud platforms as well, you're bringing recent services 131 00:09:58,760 --> 00:10:02,600 up because of the whole agility of the cloud, you're bringing services up, you're tearing them down, 132 00:10:02,600 --> 00:10:07,720 you're bringing them up, you're tearing them down, then if you apply a DNS name to that, 133 00:10:07,720 --> 00:10:14,200 well, that DNS name actually live longer than the service exists. And unfortunately, that opens it up 134 00:10:14,200 --> 00:10:22,040 to potential hijacking of that name. And the attacker could actually take on, essentially direct the 135 00:10:23,080 --> 00:10:29,160 DNS name to their IP address. And Microsoft Defender for DNS will actually pick up on this 136 00:10:29,160 --> 00:10:35,960 as a potential issue. However, as an extra layer of defense, we now have this ability 137 00:10:36,840 --> 00:10:43,400 to have DNS reservations. So what that means is the DNS names can actually hang around for a lot 138 00:10:43,400 --> 00:10:47,400 longer. So you can actually register a DNS name. And if you bring a service up, pull it down, 139 00:10:47,400 --> 00:10:53,080 bring it up, pull it down, whatever, the DNS name will basically be associated with that 140 00:10:53,080 --> 00:10:59,000 particular service for a much longer time. And that helps, it really does improve your security 141 00:10:59,000 --> 00:11:08,360 posture substantially. The DNS issues can lead to, well, I often refer to a subdomain takeover, 142 00:11:08,360 --> 00:11:11,560 this can lead to things like cookie harvesting, phishing campaigns, 143 00:11:12,440 --> 00:11:17,880 cross-site scripting, cross-site request forgery, cause, bypass, and even loss of control over the 144 00:11:17,880 --> 00:11:21,960 contents of that subdomain. So it's actually a pretty serious attack. But yeah, so one, 145 00:11:21,960 --> 00:11:27,080 Microsoft Defender for DNS will help catch this, but also we now have something a little bit more 146 00:11:27,080 --> 00:11:32,600 concrete in place as well. The next one is about Azure Monitor Logs. I don't want to go into this 147 00:11:32,600 --> 00:11:37,240 in too much detail because there's actually a lot of announcements here. And again, I'll include the 148 00:11:37,240 --> 00:11:41,560 links in the show notes. There's been a lot of feedback from customers around how they can optimize 149 00:11:41,560 --> 00:11:48,600 their spend with logging. I've seen customers using, let's just say, not particularly cost-effective 150 00:11:48,600 --> 00:11:53,240 mechanisms for storing their log files. And there's lots of options that we have. But essentially 151 00:11:53,240 --> 00:11:59,080 what we're doing here is providing even more options for people to store logs in long-term 152 00:11:59,080 --> 00:12:05,240 storage, storage in such a way that it's optimized just for querying. So that's all available today. 153 00:12:05,240 --> 00:12:09,080 Again, links in the show notes. But if you're finding you've got big log files and perhaps the 154 00:12:09,080 --> 00:12:14,360 cost of retaining and querying those log files is something that's of concern to you, then take 155 00:12:14,360 --> 00:12:18,840 a look at this. We've basically made a whole bunch of options available to you. And the last one 156 00:12:18,840 --> 00:12:23,400 is kind of interesting. So a good friend of mine, Ian Helen, and he and I have worked together 157 00:12:23,400 --> 00:12:29,400 for a long time over the years. And he works on the Mystic Pi team. So we talked about Mystic 158 00:12:29,400 --> 00:12:33,960 Pi some months ago as well. And Mystic Pi is a Python library that basically contains some 159 00:12:33,960 --> 00:12:39,880 cybersecurity tools for hunting and investigation using Jupyter notebooks. Well, Ian has actually 160 00:12:39,880 --> 00:12:46,520 made available a course up on PluralSite, certainly a short course, but well worth looking at if 161 00:12:46,520 --> 00:12:51,320 Mystic Pi is something you're looking at using or kicking the tires on. Then if you already have a 162 00:12:51,320 --> 00:12:57,560 PluralSite subscription, then go and take a look at Ian's class. All right, now we've got the news 163 00:12:57,560 --> 00:13:01,960 out of the way. Let's turn our attention to our guest. This week, we have our very first repeat 164 00:13:01,960 --> 00:13:07,320 guest. It's Thomas Weiss from the Cosmos DB team. Hey, Thomas, thank you so much for joining us this 165 00:13:07,320 --> 00:13:11,800 week for our listeners who didn't hear the first podcast. Would you care to introduce yourself? 166 00:13:11,800 --> 00:13:17,080 Absolutely. Thanks, everyone. Thanks for having me. So I'm Thomas Weiss. I actually used to be a 167 00:13:17,080 --> 00:13:22,520 Cosmos DB PM. I joined the Cosmos DB team close to three years ago. I used to be a PM focusing on 168 00:13:23,080 --> 00:13:27,320 a flurry of different feature areas, security being one of them. The move that happened recently 169 00:13:27,320 --> 00:13:33,080 for me is that I migrated to a new database platform security and governance team. What that 170 00:13:33,080 --> 00:13:37,960 means is, technically, I changed titles and managers, but my day-to-day duties are pretty much the same. 171 00:13:37,960 --> 00:13:43,800 I am looking after security all around for Cosmos DB and I'm leading the delivery of any new security 172 00:13:43,800 --> 00:13:50,600 features on that great platform. So I'm going to get my question in before Michael starts geeking 173 00:13:50,600 --> 00:13:57,960 out and I don't have a chance to get a word in. So tell me, tell us about some of the big changes 174 00:13:57,960 --> 00:14:04,200 that have happened since last we spoke on the podcast. Yeah, well, so much has happened, let 175 00:14:04,200 --> 00:14:10,520 me tell you. It's been 18 months, I think, and we obviously never stop either introducing new 176 00:14:10,520 --> 00:14:16,520 security controls or improving existing security controls. And I think one big driver for us is 177 00:14:16,520 --> 00:14:23,240 to try to catch up with our big brother that is SQL. Those guys, they have two to three decades 178 00:14:23,240 --> 00:14:29,240 head starts and actually it's nice for them to give us the security charter because they kind of 179 00:14:29,240 --> 00:14:35,000 paved the way on what is next that we should tackle. And among those things that SQL has 180 00:14:35,000 --> 00:14:39,560 introduced a while back and that we were lacking was support for client-side encryption, what is 181 00:14:39,560 --> 00:14:45,880 called always encrypted on SQL. This is something that we identified as a gap as customers were 182 00:14:45,880 --> 00:14:50,840 progressively reaching out to us. The Cosmos DB team saying, look, that thing is great on SQL and 183 00:14:51,400 --> 00:14:56,040 this is something that I would need on Cosmos DB as well. They were looking for some kind 184 00:14:56,040 --> 00:15:01,080 of column level encryption, which obviously doesn't directly translate to Cosmos DB because 185 00:15:01,080 --> 00:15:06,200 being a document database and a schema agnostic database, there is no concept of column per se. 186 00:15:06,760 --> 00:15:10,520 Essentially, we understood that what customers were looking for is property level encryption. 187 00:15:11,160 --> 00:15:17,560 So it was an amazing journey for us to start engaging with those customers, understanding 188 00:15:17,560 --> 00:15:22,600 really their requirements end to end, and also engaging with our SQL friends because it would 189 00:15:22,600 --> 00:15:28,280 have been crazy for us to tackle that by ourselves. And so the delivery of always encrypted on Cosmos 190 00:15:28,280 --> 00:15:35,000 DB is the result of a very landmark collaboration between the Cosmos DB and the SQL teams. We 191 00:15:35,000 --> 00:15:40,600 collaborated on a design, our SQL friends reviewed our design and made sure that it made sense. 192 00:15:40,600 --> 00:15:48,280 And we even collaborated very technically in that we actually ended up sharing code. 193 00:15:48,280 --> 00:15:53,400 And so the code that is running in our drivers to provide always encrypted to our customers 194 00:15:53,400 --> 00:15:56,360 is pretty much the exact same code that is running on the SQL drivers. 195 00:15:57,400 --> 00:16:00,600 And I think what's interesting, a quick note for our listeners is that 196 00:16:02,280 --> 00:16:06,600 the way today Cosmos DB encrypts data through client and encryption is pretty much 197 00:16:06,600 --> 00:16:12,120 cipher text compatible with always encrypted on SQL. So that's how far we took it. 198 00:16:12,120 --> 00:16:17,400 We introduced that public preview a while back. I think it was a build last year, sometimes in 199 00:16:17,400 --> 00:16:25,720 Maytime frame. We got great customer feedback and response, a lot of high-profile customers for 200 00:16:25,720 --> 00:16:31,400 which it is very important to put an extra level and extra layer of encryption on top of 201 00:16:31,400 --> 00:16:36,600 extra sensitive data. Those customers obviously were very keen to get started. We went through 202 00:16:36,600 --> 00:16:42,760 that preview program with some changes we brought to the API based on the feedback we got from 203 00:16:42,760 --> 00:16:47,480 the customers. And I'm more than happy to share that actually we were able to make that feature 204 00:16:47,480 --> 00:16:52,280 generally available the last month. And so this is now available for all our customers with 205 00:16:52,280 --> 00:16:56,680 production support. And I think that's an important point is the resulting 206 00:16:57,560 --> 00:17:03,560 cipher suite is the exact same cipher suite as SQL server, right? Which is the 207 00:17:03,560 --> 00:17:13,720 AES256 HMAC SHA256. So it's just kind of funny, right? Because it's not really always encrypted at 208 00:17:13,720 --> 00:17:18,280 all. It's actually always protected, right? Because the encryption is provided by AES. 209 00:17:18,840 --> 00:17:22,520 But there's also an HMAC in there that also makes sure the data has not been tampered with. 210 00:17:22,520 --> 00:17:27,720 That's right. That's right. So when he says the same data format as like the same cipher 211 00:17:27,720 --> 00:17:37,000 text format as SQL server, does that mean in theory that I could say pull some data out of 212 00:17:37,000 --> 00:17:43,640 SQL server without decrypting it? Like say bulk export it and then through some code or something, 213 00:17:43,640 --> 00:17:48,360 turn that into a JSON document without decrypting anything and then insert it into Cosmos DB? 214 00:17:48,360 --> 00:17:53,400 So technically you can. This is not something that today we support as a turnkey feature. 215 00:17:53,400 --> 00:17:59,240 We haven't documented that to be honest. It is on our charter to provide that level of 216 00:17:59,240 --> 00:18:04,680 interoperability to our customers at some point. We just set the foundation for that to happen. 217 00:18:04,680 --> 00:18:08,360 We need to make some improvements on the tooling that would let our customers move the data around. 218 00:18:09,320 --> 00:18:14,920 But technically, I mean, we have done it in our labs and it works. Now the next step for us is to 219 00:18:14,920 --> 00:18:18,680 productize that support and which is something we are going to work on. 220 00:18:18,680 --> 00:18:23,160 Yeah. So I mean, it's impossible to talk about always encrypted in Cosmos DB without 221 00:18:23,160 --> 00:18:29,720 comparing and contrasting with SQL server. Again, to your point, they had a massive head start. 222 00:18:30,360 --> 00:18:36,280 Actually, there's pros and cons to that. From a pro perspective, it's mature technology. From a 223 00:18:36,280 --> 00:18:42,120 comp perspective, SQL server has this internal access model that bears no resemblance to anything 224 00:18:42,120 --> 00:18:48,120 that Azure knows about. So you've got to end up mapping Azure identities and Azure access control 225 00:18:48,120 --> 00:18:53,160 models to work inside of SQL server where you guys were born in the cloud, right? So you 226 00:18:53,160 --> 00:18:59,080 understand that from day one. Yeah, absolutely. But that said, Michael, I think it's no 227 00:18:59,080 --> 00:19:05,160 coincidence or no surprise that we named the feature always encrypted as well because 228 00:19:05,160 --> 00:19:10,840 essentially for our customers, the same approach, it's the same concept in that we get customers 229 00:19:10,840 --> 00:19:15,720 create what we call encryption policies at the container level. So with those encryption policies, 230 00:19:15,720 --> 00:19:22,520 customers can say, I want property one to be always encrypted with key one in a deterministic 231 00:19:22,520 --> 00:19:26,600 fashion and I want property two to always be encrypted with key two in randomized fashion. 232 00:19:26,600 --> 00:19:31,560 So when the customer creates those Cosmos DB containers, we give them that option to 233 00:19:32,200 --> 00:19:37,560 define and provide that encryption policy. And also the way keys are handled is very similar to 234 00:19:37,560 --> 00:19:42,920 what happens on SQL. Always encrypted in that we let our customers create data encryption keys 235 00:19:42,920 --> 00:19:48,360 at the database level. Those data encryption keys are themselves wrapped with a customer 236 00:19:48,360 --> 00:19:54,760 managed key that our customers today can manage from keyboard. And so at the end of the day, 237 00:19:54,760 --> 00:20:00,600 the same security guarantees are provided today on Cosmos DB in that when customers encrypt data 238 00:20:00,600 --> 00:20:06,680 we've always encrypted, they are guaranteed that we Cosmos DB as a service, we never ever see 239 00:20:06,680 --> 00:20:11,080 the plain text data and not only that, but we never ever see the plain text data encryption 240 00:20:11,080 --> 00:20:15,640 keys. And so for customers, we want to have that guarantee that there is absolutely no way for a 241 00:20:16,280 --> 00:20:21,960 Microsoft or a Cosmos DB operator to eventually decrypt the data. That's a guarantee that comes 242 00:20:21,960 --> 00:20:26,440 with the future. Yeah, that's an important point. And that's something that I certainly 243 00:20:26,440 --> 00:20:31,320 talk about heavily with customers is heaven forbid. But in the case of, say, an environment being 244 00:20:31,320 --> 00:20:36,040 compromised, Cosmos DB, an environment being compromised, Cosmos DB doesn't have the keys. 245 00:20:36,040 --> 00:20:40,200 I mean, the attackers are just going to get ciphertext. The key is not there. I mean, it's not 246 00:20:40,200 --> 00:20:44,680 like, you know, I can go and get the key and do it. No, the key is not there. I can't convince 247 00:20:44,680 --> 00:20:49,160 Cosmos DB to decrypt it. It doesn't have the key. It doesn't have access to the key at all. It's a 248 00:20:49,160 --> 00:20:53,640 it is client side encryption, right? So it's the clients that have access to the key and the R back 249 00:20:53,640 --> 00:20:59,080 policies will restrict access, you know, through the through the client, rather than Cosmos DB having 250 00:20:59,080 --> 00:21:03,320 access. And it's interesting because a lot of customers have a they kind of have to stop and 251 00:21:03,320 --> 00:21:07,000 think about that. It's like, yeah, Cosmos DB is not doing the encryption or the decryption. It's 252 00:21:07,000 --> 00:21:13,160 all being done by the Cosmos DB client drivers, not by Cosmos DB itself. And that includes some 253 00:21:13,160 --> 00:21:20,120 kinds of queries, right? That's right. That's right. There is we did our best to let our customers 254 00:21:20,120 --> 00:21:26,200 leverage the full spectrum of database operation when they are using always encrypted. That said, 255 00:21:26,200 --> 00:21:30,840 there were some limitations that today we had to introduce. And those limitations mainly 256 00:21:30,840 --> 00:21:36,200 impact the query ability when customers want to filter on encrypted properties for our listeners 257 00:21:36,200 --> 00:21:40,520 or family encryption, they will probably understand that we bought any support for, you know, 258 00:21:40,520 --> 00:21:46,280 secure enclaves like SQL has today. Today, the only filter construct that we support are 259 00:21:46,280 --> 00:21:52,520 equity filters, meaning that if I have defined an encryption policy where property one is 260 00:21:52,520 --> 00:21:57,560 encrypted and is encrypted in a deterministic fashion, then it is possible for our customers to 261 00:21:57,560 --> 00:22:03,480 write a query where, you know, property one equals ABC. That's totally supported. Anything 262 00:22:03,480 --> 00:22:09,640 more fancy? I think fancier like, you know, range queries, you know, starts with things like that 263 00:22:09,640 --> 00:22:15,160 today, we cannot support because that would require, you know, having a support, secure enclaves, 264 00:22:15,160 --> 00:22:20,200 or some kind of confidential computing, which is something that's definitely on our radar. 265 00:22:20,200 --> 00:22:26,360 It is on our backlog. But I would add that, you know, that those constraints today, they probably 266 00:22:26,360 --> 00:22:32,760 impact a class of workloads that couldn't be today translated to always encrypted. But we need to 267 00:22:32,760 --> 00:22:36,680 keep in mind that there is a very large spectrum of workloads for which those constraints would 268 00:22:36,680 --> 00:22:42,040 still be absolutely fine. We do have a fair amount of customers who are actually using Cosmos DB 269 00:22:42,040 --> 00:22:47,080 as a key value store. The only thing they do are document lookups. And for those operations, 270 00:22:47,720 --> 00:22:56,200 no problem at all. And our situation and our position today is that we GA'd that first milestone, 271 00:22:56,200 --> 00:23:00,680 that first iteration of always encrypted. Now we are just opening our ears and listening to 272 00:23:00,680 --> 00:23:05,880 customers. And if we have substantial feedback from customers saying, look, I'm blocked because, 273 00:23:05,880 --> 00:23:09,800 you know, I need range queries or I need things that today are not possible. This is how we are 274 00:23:09,800 --> 00:23:13,240 going to fuel the next iteration and how we are going to improve the future. 275 00:23:13,240 --> 00:23:17,800 You know, it's kind of funny, right? I've had these conversations with the customers as well. 276 00:23:18,600 --> 00:23:22,280 Here you've got, you know, you look at the job of a database, right? It's to query stuff. 277 00:23:22,280 --> 00:23:27,720 And it's to get data. And then the whole point of encryption is to not get data, right? That's 278 00:23:27,720 --> 00:23:32,520 the whole point. So here we've got these two things that are absolute opposite ends of the spectrum. 279 00:23:33,160 --> 00:23:36,360 And the fact that we're actually doing something in the middle that will, you know, 280 00:23:36,360 --> 00:23:40,680 that will actually allow you to do queries, even as it says substantially small, I should say, 281 00:23:41,320 --> 00:23:45,320 subset of queries, which basically is equality or inequality. The fact that you can do anything 282 00:23:45,320 --> 00:23:53,000 at all over ciphertext without decrypting it is pretty cool. I mean, you know, I have customers 283 00:23:53,000 --> 00:23:56,280 say, well, you know, well, can I just turn on always encrypted and everything will just work. 284 00:23:56,280 --> 00:23:59,560 It's like, no, it probably won't work because you probably have some quick SQL queries that, 285 00:23:59,560 --> 00:24:04,280 as you say, I like things like range queries, right? Something between the first of September 286 00:24:04,280 --> 00:24:08,120 and the third of September, it's not going to work, right? Because you're doing the query over 287 00:24:08,120 --> 00:24:13,640 ciphertext. But the fact that you can do some kinds of queries, especially over, you know, 288 00:24:13,640 --> 00:24:19,080 super sensitive data, that's just, that's just fantastic. I mean, I'm just, and I've seen people 289 00:24:19,640 --> 00:24:24,440 essentially change their schema slightly to accommodate for, for this so that they can 290 00:24:24,440 --> 00:24:28,280 actually do some kinds of queries. But yeah, you know, this is a great example, you know, 291 00:24:28,280 --> 00:24:32,600 as we talk about in our confidential computing literature, you know, this is encryption of 292 00:24:32,600 --> 00:24:37,080 data while it's in use. And so we're actually using it and querying it. And it's just fantastic to 293 00:24:37,080 --> 00:24:42,520 see Cosmos DB, you know, adopt this, adopt this technology, which has been in SQL server for a 294 00:24:42,520 --> 00:24:46,920 while. But as you also point out, SQL server has been around for, you know, for longer. And they 295 00:24:46,920 --> 00:24:54,920 also have the secure enclave technology, which allows them to do more types of queries, because 296 00:24:54,920 --> 00:25:00,760 the query engine runs in a secure enclave, which is for those of you not aware, so secure enclave 297 00:25:00,760 --> 00:25:05,960 in the sort of Azure confidential compute world is takes advantage of virtual machines that run 298 00:25:06,520 --> 00:25:10,760 specific Intel CPUs that have what are called software guard extensions. And essentially, 299 00:25:10,760 --> 00:25:16,200 what we do is we corner off at the CPU level, a chunk of memory, and then the query engine runs 300 00:25:16,200 --> 00:25:20,920 inside that little enclave. That's what's called non-clave. So that is not available today in 301 00:25:20,920 --> 00:25:24,760 Cosmos DB, but it's something like you say you're sort of listening to customers, see if it's of 302 00:25:24,760 --> 00:25:29,640 interest to them. Absolutely. Absolutely. That's our current situation. And that technical solution 303 00:25:29,640 --> 00:25:35,000 is complex, right? Let's say it from an implement implementation standpoint, it's a huge effort 304 00:25:35,000 --> 00:25:40,520 for to embrace a confidential computing and enclaves to add additional query support. And 305 00:25:40,520 --> 00:25:44,360 that's why we are cautious, right? We don't want to engage work that actually our customers wouldn't 306 00:25:44,360 --> 00:25:51,640 be necessarily interested in. So yeah, anyone listening here, if you think that you would need 307 00:25:51,640 --> 00:25:56,280 additional support by all means, you know, funnel that feedback to the Cosmos DB team and we'll take 308 00:25:56,280 --> 00:26:04,280 action on that. So Cosmos DB can talk multiple air quote languages, MongoDB, SQL, Cassandra, 309 00:26:04,280 --> 00:26:11,640 and so on. Is this limited to the SQL drivers or can other drivers handle it as well? 310 00:26:11,640 --> 00:26:17,240 That's a great question. So today, we have a GA always encrypted on our SQL API or core 311 00:26:17,240 --> 00:26:24,040 slash SQL API, which is the native API, the API that we control, right? Now having support for 312 00:26:24,040 --> 00:26:30,200 clients and encryption on the other platforms involves that involves support for their back-end 313 00:26:30,200 --> 00:26:37,160 features that lets the client do that encryption. And I'm glad you bring it up, Michael, because 314 00:26:37,160 --> 00:26:42,920 for example, MongoDB had the support for what I think they call field level encryption on their 315 00:26:42,920 --> 00:26:49,720 drivers for some time. And for some time actually, we couldn't support that in our MongoDB compatible 316 00:26:49,720 --> 00:26:54,920 API because we were missing support for some back-end level features that the drivers are 317 00:26:54,920 --> 00:27:00,680 leveraging in order to deliver a field level encryption. But with our latest iterations and 318 00:27:00,680 --> 00:27:07,320 our latest versions, we no support that. What that means that Cosmos DB users that use the 319 00:27:07,320 --> 00:27:12,040 MongoDB compatible API that want to use the vanilla field level encryption that comes with the 320 00:27:12,040 --> 00:27:16,840 MongoDB drivers now can do that as well. Yeah, as long as people understand that, they understand 321 00:27:18,040 --> 00:27:21,960 some of the limitations. Are there any other limitations like what sort of data can be 322 00:27:21,960 --> 00:27:27,320 encrypted or particular types of data that can't be encrypted? No, when it comes to our MongoDB API, 323 00:27:27,320 --> 00:27:34,520 we support the full range of what field level encryption can do. Not supporting enclaves, 324 00:27:34,520 --> 00:27:38,360 we come with the same limitation when it comes to the type of queries, but in terms of data types, 325 00:27:40,200 --> 00:27:44,600 whatever you can do on MongoDB can also be done through our MongoDB compatible API. 326 00:27:44,600 --> 00:27:47,000 But that is separate technology though, right? It's not always encrypted. 327 00:27:47,000 --> 00:27:53,720 No, it is part of the vanilla MongoDB drivers. So yeah, it is not always encrypted. 328 00:27:53,720 --> 00:27:58,200 So if you're a MongoDB person using Cosmos DB, you'll be familiar with that? 329 00:27:58,200 --> 00:28:03,800 Absolutely. Yeah, this is really exciting stuff. As I don't even know or not, Thomas, but last 330 00:28:03,800 --> 00:28:09,160 week, well, the last time I did the podcast, we had no news on purpose so that Mark could actually 331 00:28:09,160 --> 00:28:16,520 talk about his stuff. But I couldn't help it because Cosmos DB had just GA'd, always encrypted. 332 00:28:16,520 --> 00:28:19,800 So I'm like, well, you know what? We have no news, but hey, you know what? I'm going to talk 333 00:28:19,800 --> 00:28:26,120 about this one thing anyway, even if it means stealing some time from Mark. But yeah, this is 334 00:28:26,120 --> 00:28:32,680 really exciting stuff. I'm such a fan of it. It allows some really interesting zero trust 335 00:28:32,680 --> 00:28:38,360 environments as well because Cosmos DB doesn't have access to the keys. You got strong auditing 336 00:28:38,360 --> 00:28:44,840 of the keys, all the key encryption keys at least, and as a key vault, I just think it's a 337 00:28:44,840 --> 00:28:49,800 fantastic solution. Great to see it, fantastic engineering, elegantly simple as well, which is 338 00:28:50,760 --> 00:28:56,920 not to me that it's easy to implement, but it's just so elegant. I'm a huge fan. And again, 339 00:28:56,920 --> 00:29:02,280 it's not just encryption. There's an HMAC in there as well, so the data can't be tampered with. 340 00:29:03,320 --> 00:29:10,120 So as expected, I sat there listening and learning. Anything else in addition to the 341 00:29:10,120 --> 00:29:13,720 always encrypted goodness? Yeah, absolutely. I think there is another thing I would like to 342 00:29:13,720 --> 00:29:19,560 mention, something that is a bit less new, something that we introduced last year, but that was 343 00:29:19,560 --> 00:29:25,320 another major update to the security controls that we are exposing on Cosmos DB. And this is 344 00:29:25,880 --> 00:29:33,240 the new Azure AD powered data plane RBAC that we introduced for our customers. That's a workstream 345 00:29:33,240 --> 00:29:39,640 that was initiated based on customer feedback, customers where, some of our customers and arguably 346 00:29:39,640 --> 00:29:44,520 the most security conscious customers, we're asking for an alternate way to authenticate 347 00:29:44,520 --> 00:29:50,760 their Cosmos DB database operations. Since the beginning, the only authentication that we supported 348 00:29:50,760 --> 00:29:56,280 was key-based authentication, so customers can fetch a primary and a secondary key, and those are 349 00:29:56,280 --> 00:30:00,440 the keys that they can use when they connect to their Cosmos DB account, which is fine in plenty 350 00:30:00,440 --> 00:30:05,400 of use cases, but we had some customers who arguably wanted something different, and what 351 00:30:05,400 --> 00:30:11,160 we were actually asking for is an Azure AD-based authentication. That was one requirement that 352 00:30:11,160 --> 00:30:16,120 we initially tracked. The second requirement that came from customers is that they wanted to some kind 353 00:30:16,120 --> 00:30:21,960 of granular access control. Another problem that comes with the primary, secondary keys, is that 354 00:30:23,080 --> 00:30:27,400 it's open bar, right? That whoever has the key can pretty much anything on the account, 355 00:30:28,200 --> 00:30:32,760 including management operations. So that puts a lot of pressure on our customers to 356 00:30:32,760 --> 00:30:38,680 handle those keys in the right way, right? What I would like to mention here very briefly is that, 357 00:30:39,400 --> 00:30:44,520 although it is extremely convenient to connect with a primary key, because again, it's just one 358 00:30:44,520 --> 00:30:50,600 shared secret that lets you do anything. Our customers and our listeners here should be mindful 359 00:30:50,600 --> 00:30:57,560 that we've great power, great responsibility, and those keys need to be handled appropriately 360 00:30:57,560 --> 00:31:03,320 if you want to have the best security posture. In particular, it is the best practice to regenerate 361 00:31:03,320 --> 00:31:09,720 and rotate those keys on a regular basis. This is something that, it's not a reflex that many 362 00:31:09,720 --> 00:31:14,840 of our customers have. So we regularly remind our customers that it is the best practice when 363 00:31:14,840 --> 00:31:22,520 you use key-based authentication to perform those upgrades now. That's a side note. We are 364 00:31:22,520 --> 00:31:29,080 actually introducing new APIs to let our customers query what was the date of last generation, 365 00:31:29,080 --> 00:31:33,160 regeneration for those keys so that they can kind of take action on keys that may be stale. 366 00:31:34,440 --> 00:31:40,200 So yeah, that's another feedback we got from the customers, right? They would like to have some 367 00:31:40,200 --> 00:31:45,000 granular access control and they would like to better configure the client to make sure that 368 00:31:45,000 --> 00:31:51,960 client A can only do a subset of operations based on their business rules. And the third and last 369 00:31:51,960 --> 00:31:58,360 requirement we were gathering at the time is that our customers were seeking better auditability of 370 00:31:58,360 --> 00:32:02,840 what's happening on the on the data plane, right? There are situations where the customer would 371 00:32:02,840 --> 00:32:09,160 like to answer questions like, you know, who deleted my data, you know, and when, and that 372 00:32:09,160 --> 00:32:13,960 those are questions that you just can't answer if you are using just a key as the authentication 373 00:32:13,960 --> 00:32:19,160 mechanism because anyone could be using that key. So it is based on that customer feedback that you 374 00:32:19,160 --> 00:32:25,080 have that we have built that brand new data plane RBAC. In terms of API, what we did, 375 00:32:26,440 --> 00:32:31,080 maybe a bit lazily, but I think that that was the best thing to do anyway. We copied over the 376 00:32:31,080 --> 00:32:37,640 concepts from Azure RBAC because that was a a problem model that has been out there for for 377 00:32:37,640 --> 00:32:43,560 quite a while. And so all the typical concepts that you that you can find on Azure RBAC like, 378 00:32:43,560 --> 00:32:49,160 you know, actions that make up a permission model, role definitions, role assignments, those are 379 00:32:49,160 --> 00:32:54,600 those are concepts that we carried over the cost on the Cosmos DB side. And we have introduced new 380 00:32:54,600 --> 00:33:00,280 APIs on the control plane on our control plane to let our customers do that. Right. So now 381 00:33:00,280 --> 00:33:05,160 what our customers can do is that they can either play with data plane built-in roles, we have a 382 00:33:05,160 --> 00:33:10,760 couple of new built-in roles, we have a read only and read write built-in roles, or that we can also 383 00:33:10,760 --> 00:33:17,080 I mean, we also let our customers craft their own specific roles and customers can can can go very 384 00:33:17,080 --> 00:33:21,640 specializing those roles, right? If you if you want to create a role to let the client just, 385 00:33:21,640 --> 00:33:25,640 you know, insert data and not do anything else, not not even being able to read back the data you 386 00:33:25,640 --> 00:33:31,080 have inserted, which makes sense in some scenarios, right? That's possible now and something that 387 00:33:31,080 --> 00:33:36,280 typically wasn't possible at all before. If you want to create a role that, you know, only lets you 388 00:33:36,280 --> 00:34:04,280 read from the change feed, you know, and nothing else that that's that's the kind of thing you can do now. So you can craft your roles, you can then assign your roles to any kind of Azure AD identity, we support obviously the full spectrum from user principles to service principles, including managed identities, which is something I'm very fond of and I always recommend our customers to have a good look at managed identities. Azure AD groups obviously are also on the spectrum. So yeah, that's the role of the client. 389 00:34:04,280 --> 00:34:22,280 So yeah, that's the role assignment part of the of the workflow. And then once this is done, obviously, customers can finally upgrade their client connection to use what's called the token credential instead of the of the primary or secondary key. And so that that token credential, the 390 00:34:22,280 --> 00:34:38,280 authentication essentially is passed to our drivers. And that lets our drivers acquire an Azure AD token on behalf of the identity that the client wants us to use. And then we just use that token to do both the authentication and the authorization of the database requests. 391 00:34:38,280 --> 00:34:54,280 And I know that when I see customers using, you know, these these essentially these secrets to access Cosmos DB, you know, the first question I ask is so okay, so where are those secrets being stored? I don't mean the back end I mean, you know, in your applications that have to access these secrets, it's the classic secret 392 00:34:54,280 --> 00:35:08,280 problem, right? I mean, I had a conversation yesterday with a customer and they're like, they're accessing some back end mainframe and I'm like, so how do you access that? Well, we have an API key. Well, where's the API key? Well, it's stored in this configuration file. But where's the configuration 393 00:35:08,280 --> 00:35:20,280 file? What's over there? Well, how's the API key protected in the configuration file? Well, it's encrypted. So where's the key for the encryption? Well, it's over there. Well, how's that key encrypted? And then you can see them all like looking 394 00:35:20,280 --> 00:35:29,280 between each other is like, how is it how's the final key? You know, how's the key encrypted? It's like, and they didn't know. And the problem is like the five Ys but as applied to five house. 395 00:35:29,280 --> 00:35:47,280 I know. And I look, I understand why it's there. It's been around for a long time. But you know, you've got to make sure those things are protected, especially the primary keys, right? Because they used to, sorry, if I got the name wrong, but the, you know, the essentially the admin key that lets you get into admin 396 00:35:47,280 --> 00:36:03,280 things. So yeah, I'm a huge fan of, you know, AAD RBAC at the data plane. I don't know if you know or not, but just recently we added that recently, probably about a year ago now, we added that in Key Vault as well, right, they had their own authorization model, and now they're going to 397 00:36:03,280 --> 00:36:20,280 use a data plane RBAC model. It's a little harder to configure compared to the old one, but it's also a lot more granular. And you have very strong in auditing as well that goes in there. So again, you know, it's really great to see Cosmos DB listening to customers and adding this this functionality. 398 00:36:20,280 --> 00:36:30,280 It's great to see. Hey, you know, there's something else you guys for probably you guys actually maybe you guys release Microsoft Defender for Cosmos DB. And by the way, this is completely off script. 399 00:36:30,280 --> 00:36:49,280 Oh yeah, that's something that that's an effort in collaboration with the Microsoft Defender team. It is not directly worked on by the Cosmos DB team, it is more of a partnership where we enable the Defender team to implement, you know, those threat models and threat 400 00:36:49,280 --> 00:37:09,280 detections. And yeah, yeah, I'm also glad to share today that we have very recently kind of rebooted those efforts. This is something that used to be exposed to our customers as a preview under the name of advanced threat protection, ATP, that probably rings a bell to some of our listeners here. The ATP team went through both 401 00:37:09,280 --> 00:37:27,280 renaming. So they renamed to Microsoft Defender but also at the same time, they took that opportunity to reboot the efforts. Because until recently, not only was ATP in preview only but also it was only covering a small set of threats, right? I think 402 00:37:27,280 --> 00:37:42,280 initially, what they were covering is suspicious connections, right? If suddenly you get new connections from IPs that you know you've never seen before from locations that you have never seen before, this is something that Defender used to cover as part of their preview. 403 00:37:42,280 --> 00:38:01,280 And I think they also had a threat detection on data exfiltration, right? If suddenly you have massive reads or massive scans across the database, this could be a sign of someone trying to exfiltrate your data to some other place. And so yeah, for quite some time, the preview was running with only those two threats being covered. 404 00:38:01,280 --> 00:38:18,280 And so over the past six to nine months, we kind of rebooted those efforts. And the Defender team has added very interesting new threat to our detections. They are now detecting key extractions, which is also a very common pattern. 405 00:38:18,280 --> 00:38:39,280 So they are looking for access to those keys that we just mentioned, right? Which you can fetch through a list keys operation on the CosmoDB control plane. And they try to detect anything suspicious here, right? If suddenly there is a new IP or a new identity that starts getting the keys that may trigger an alert on their end. 406 00:38:39,280 --> 00:38:58,280 They are also, and I was actually pleasantly surprised that they managed to pull that off. They are also now detecting SQL injections, right? Which we didn't necessarily think about at the beginning, but especially since the SQL dialect that is exposed by CosmoDB is not NC SQL, right? 407 00:38:58,280 --> 00:39:16,280 It is kind of a SQL adaptation that we crafted in order for it to be compatible with the specifics of JSON. But yeah, the team managed to actually craft a detection on potential SQL injections. So that's another great new capability that Defender is now exposing. 408 00:39:16,280 --> 00:39:32,280 So all those new detections have been, as I said, relaunched, rebooted in public preview now. So available for all our customers to try out. And I believe that the Defender team is lining up the GA of Defender for CosmoDB in the next couple of months. 409 00:39:32,280 --> 00:39:46,280 I'm a huge fan of Defender. Actually, before we, by the way, I want to talk about Defender. I don't mean the video game. I mean, Microsoft Defender. Although I am actually back in Redmond, I used to have a Defender stand up console, an original one from the 80s. 410 00:39:46,280 --> 00:39:47,280 Nice. 411 00:39:47,280 --> 00:39:57,280 Yeah. Yeah, it cost me $2,000 worth every penny. No, in all seriousness, I should want to explain something really quickly about the SQL injection stuff because I had a conversation with a customer about this a few days ago. 412 00:39:57,280 --> 00:40:08,280 They said, the guy's like, well, hang on a minute. So you got this brand new product. Well, relatively new product called Cosmos DB, you know, relative to say SQL databases. How come you have SQL injection vulnerabilities? 413 00:40:08,280 --> 00:40:21,280 I'm like, well, hang on. It's not as simple as that. This is not a weakness in Cosmos DB. This is a weakness in client side code where you use string concatenation to build a SQL query where one of the strings comes from an untrusted source. 414 00:40:21,280 --> 00:40:33,280 Cosmos DB just sees a SQL query. It doesn't know how it was constructed. It just sees the SQL query. And if it happens to be a SQL injection SQL query, there's not a lot. It doesn't know a good query from necessarily a bad query. 415 00:40:33,280 --> 00:40:41,280 You know, it's really a coding discipline at the client. It's got nothing to do with Cosmos DB whatsoever. It's not a weakness in Cosmos DB. 416 00:40:41,280 --> 00:40:58,280 So I want to make sure everyone's aware of that. And if you take, for example, in C sharp, as I think a link language integrated query, which can also do SQL queries against SQL server, it is actually resilient against SQL injection vulnerabilities, but only because it is a client side technology. 417 00:40:58,280 --> 00:41:16,280 And it knows how to construct SQL queries from something that's not actually a real SQL query. So it is resilient to SQL injection vulnerabilities. But that doesn't mean that all of a sudden magically SQL server or Cosmos DB or Oracle or DB two or anything else is resilient to SQL SQL injection. 418 00:41:16,280 --> 00:41:28,280 It's got nothing to do with any kind of weakness at the back end. But it's great that defender is detecting some classes of SQL injection. That's really good to see. 419 00:41:28,280 --> 00:41:37,280 Well, Thomas, thank you so much for all of that. I always enjoy listening to you talk about Cosmos DB. It's such a fantastic product. 420 00:41:37,280 --> 00:41:47,280 I think probably 90% of the customers I work with are using Cosmos DB in their workloads, which is fantastic to see when they have so many options available to them and they're choosing Cosmos DB. 421 00:41:47,280 --> 00:42:00,280 Don't tell the SQL guys I said that by the way. So as you know from last time, one thing we ask our guests is if they have one final thought to leave our listeners with, what would it be? 422 00:42:00,280 --> 00:42:16,280 Well, Michael, I would say we have talked about new features that are now generally available. We believe those features are substantially improving the range of security controls we have on Cosmos DB and help our customers adopt a much better security posture. 423 00:42:16,280 --> 00:42:26,280 I guess the call to action is just to go out there and start using them, especially that Chinese new support for always encrypted. As a PM, I do want to hear from our customers. 424 00:42:26,280 --> 00:42:34,280 So by all means, kick the tires, start a quick prototype. It's quite easy to get started with our public documentation. 425 00:42:34,280 --> 00:42:36,280 Feel free to reach out to me if you have any feedback on me. 426 00:42:36,280 --> 00:42:44,280 Thomas, thank you so much for joining us this week. I know that Cosmos DB is going through some exciting changes and I know that you're very busy. 427 00:42:44,280 --> 00:43:02,280 So again, thank you for joining us this week. And to all our listeners out there, thanks again also for listening. Take care and we'll see you next time. 428 00:43:14,280 --> 00:43:19,280 .