1 00:00:00,000 --> 00:00:06,200 Welcome to the Azure Security Podcast, 2 00:00:06,200 --> 00:00:09,360 where we discuss topics relating to security, privacy, 3 00:00:09,360 --> 00:00:13,680 reliability, and compliance on the Microsoft Cloud Platform. 4 00:00:13,680 --> 00:00:16,980 Hey, everybody. Welcome to Episode 35. 5 00:00:16,980 --> 00:00:18,480 This week is myself, Michael, 6 00:00:18,480 --> 00:00:20,160 Gladys, and Mark. 7 00:00:20,160 --> 00:00:22,460 Unfortunately, Sarah can't be with us this week going to 8 00:00:22,460 --> 00:00:25,120 time zone problems. We also have a special guest. 9 00:00:25,120 --> 00:00:26,240 We have Michael McElvish, 10 00:00:26,240 --> 00:00:27,400 who's here to talk to us about 11 00:00:27,400 --> 00:00:29,580 Azure Defender for SQL Threat Protection. 12 00:00:29,580 --> 00:00:31,880 This is part one of a two-part series. 13 00:00:31,880 --> 00:00:36,160 Part two will cover Azure SQL Defender vulnerability assessment, 14 00:00:36,160 --> 00:00:38,360 but that will be on in our next podcast. 15 00:00:38,360 --> 00:00:39,720 But before we get to Michael, 16 00:00:39,720 --> 00:00:41,000 let's turn to the news. 17 00:00:41,000 --> 00:00:42,000 I'll kick things off. 18 00:00:42,000 --> 00:00:45,120 A few things really took my interest over the last few weeks. 19 00:00:45,120 --> 00:00:47,080 The first one is the ability to configure 20 00:00:47,080 --> 00:00:50,240 applications with application configuration and Key Vault. 21 00:00:50,240 --> 00:00:52,280 The purpose of this is that you can store 22 00:00:52,280 --> 00:00:55,120 some sensitive information in app config, 23 00:00:55,120 --> 00:00:58,200 and then the super sensitive stuff such as encryption keys, 24 00:00:58,200 --> 00:01:01,480 and the like can be stored in Key Vault. 25 00:01:01,480 --> 00:01:04,600 App config can seamlessly access 26 00:01:04,600 --> 00:01:06,200 the Key Vault on your behalf, 27 00:01:06,200 --> 00:01:07,480 which is absolutely brilliant. 28 00:01:07,480 --> 00:01:10,400 Next one is part of the YouTube video 29 00:01:10,400 --> 00:01:13,720 from the Microsoft Machine Learning Team. 30 00:01:13,720 --> 00:01:16,560 It's entitled, Securing Machine Learning Environments 31 00:01:16,560 --> 00:01:18,320 on Azure Machine Learning. 32 00:01:18,320 --> 00:01:19,360 This is pretty important. 33 00:01:19,360 --> 00:01:22,360 I mean, if you have models and 34 00:01:22,360 --> 00:01:26,520 data that is used as the input to machine learning, 35 00:01:26,520 --> 00:01:29,480 it's critically important that that data be 36 00:01:29,480 --> 00:01:32,600 clean and correct and not tampered with. 37 00:01:32,600 --> 00:01:34,880 This video goes through some of 38 00:01:34,880 --> 00:01:38,840 the best practices around securing ML data. 39 00:01:38,840 --> 00:01:42,600 I also spotted a Microsoft Identity Learning Path. 40 00:01:42,600 --> 00:01:44,280 I'll give a link to that. 41 00:01:44,280 --> 00:01:46,880 I'm a died-in-the-wall security guy, 42 00:01:46,880 --> 00:01:50,080 and even though I know some of the basics of identity, 43 00:01:50,080 --> 00:01:52,000 I don't pretend to know absolutely everything. 44 00:01:52,000 --> 00:01:54,920 I found this learning path incredibly useful 45 00:01:54,920 --> 00:01:56,760 to fill in some of those knowledge gaps. 46 00:01:56,760 --> 00:01:59,720 In fact, it's led me to spend quite a bit of time 47 00:01:59,720 --> 00:02:03,320 really getting into the bowels of OAuth 2. 48 00:02:03,320 --> 00:02:05,080 I wouldn't recommend that, 49 00:02:05,080 --> 00:02:07,600 but I found myself spending quite a bit of time again, 50 00:02:07,600 --> 00:02:09,680 pulling apart OAuth tokens. 51 00:02:09,680 --> 00:02:12,360 The last thing is that we now have 52 00:02:12,360 --> 00:02:14,080 general availability for 53 00:02:14,080 --> 00:02:17,880 private link with the Azure Managed HSM. 54 00:02:17,880 --> 00:02:23,160 A managed HSM is essentially a Key Vault, 55 00:02:23,160 --> 00:02:25,480 but there's different backend hardware. 56 00:02:25,480 --> 00:02:30,400 It's a FIPS 140-2 Level 3 validated hardware. 57 00:02:30,400 --> 00:02:32,280 It is not a shared resource. 58 00:02:32,280 --> 00:02:35,240 This is your own individual HSM. 59 00:02:35,240 --> 00:02:38,440 For the most part, it's a very specialized piece of 60 00:02:38,440 --> 00:02:41,080 hardware that's used for very specialized requirements. 61 00:02:41,080 --> 00:02:43,040 My general guidance here is, 62 00:02:43,040 --> 00:02:44,320 if you don't know what that means, 63 00:02:44,320 --> 00:02:45,480 then you probably don't need it. 64 00:02:45,480 --> 00:02:47,600 But the point is it's now got 65 00:02:47,600 --> 00:02:50,400 private link support, which is nice to see. 66 00:02:50,400 --> 00:02:53,480 This is Gladys and I wanted to talk about 67 00:02:53,480 --> 00:02:58,120 the ransomware detection that has been added to Azure Sentinel. 68 00:02:58,120 --> 00:03:02,040 As you may know, there has been many capabilities that 69 00:03:02,040 --> 00:03:06,520 Microsoft has added to our services to try to 70 00:03:06,520 --> 00:03:11,600 prevent the loss of data such as OneDrive and Exchange, 71 00:03:11,600 --> 00:03:15,600 saving any data or deleted files or 72 00:03:15,600 --> 00:03:17,680 mailboxes for 30 days, 73 00:03:17,680 --> 00:03:22,960 SharePoint backing up every 12 hours and retaining for 14 days. 74 00:03:22,960 --> 00:03:25,520 Retention policies or even litigation 75 00:03:25,520 --> 00:03:30,800 whole can be set within Office 365 which preserve data. 76 00:03:30,800 --> 00:03:33,640 E-discovery and content searches can be 77 00:03:33,640 --> 00:03:39,680 used in the discovery or recovery of that data. 78 00:03:39,680 --> 00:03:43,640 Azure backups can help backup the data sources and 79 00:03:43,640 --> 00:03:47,120 VM run in Azure. 80 00:03:47,120 --> 00:03:49,840 But how do we speed up the detection of 81 00:03:49,840 --> 00:03:53,920 possible attempts to do ransomware? 82 00:03:53,920 --> 00:03:58,560 Well, many groups within Microsoft including the Microsoft Thread 83 00:03:58,560 --> 00:04:03,680 Intelligence Center or Mystic have collaborated to create 84 00:04:03,680 --> 00:04:07,280 Azure Sentinel Fusion detection for ransomware. 85 00:04:07,280 --> 00:04:09,600 Basically, alerts that are 86 00:04:09,600 --> 00:04:13,640 potentially associated with ransomware activities are 87 00:04:13,640 --> 00:04:18,200 correlated together within this Fusion Machine Learning model. 88 00:04:18,200 --> 00:04:20,120 If something is detected, 89 00:04:20,120 --> 00:04:24,680 it triggers a high severity incident title, 90 00:04:24,680 --> 00:04:29,400 multiple alerts possibly related to ransomware activity detected. 91 00:04:29,400 --> 00:04:32,360 The correlated signal used by 92 00:04:32,360 --> 00:04:36,800 this Fusion Machine Learning model confronts services such as 93 00:04:36,800 --> 00:04:39,640 Azure Defender or Azure Security Center, 94 00:04:39,640 --> 00:04:41,920 Microsoft Defender for Endpoint, 95 00:04:41,920 --> 00:04:44,440 Microsoft Defender for Identity, 96 00:04:44,440 --> 00:04:47,760 and Microsoft Cloud Application Security. 97 00:04:47,760 --> 00:04:52,200 I am really excited about this capability since it really shows 98 00:04:52,200 --> 00:04:55,520 the power of a well-integrated suite of products. 99 00:04:55,520 --> 00:04:57,520 Although in this case, 100 00:04:57,520 --> 00:05:01,480 the integration happens within Microsoft products, 101 00:05:01,480 --> 00:05:04,360 Microsoft services have capabilities of 102 00:05:04,360 --> 00:05:08,000 integrating with many third party vendors. 103 00:05:08,000 --> 00:05:12,200 If you missed a previous postcard where we talk about these, 104 00:05:12,200 --> 00:05:15,880 I recommend looking at the Microsoft Graph and 105 00:05:15,880 --> 00:05:20,320 other integration capabilities within our services. 106 00:05:20,320 --> 00:05:24,360 Those podcasts have really good information. 107 00:05:24,360 --> 00:05:26,760 When it comes to ransomware, 108 00:05:26,760 --> 00:05:30,240 the one thing to remember is that time is 109 00:05:30,240 --> 00:05:32,400 the most important factor in minimizing 110 00:05:32,400 --> 00:05:34,920 impact and possible loss of data. 111 00:05:34,920 --> 00:05:38,040 The sooner alerts are raised to 112 00:05:38,040 --> 00:05:42,440 security analysts with the required details on 113 00:05:42,440 --> 00:05:46,040 various attacker activities, 114 00:05:46,040 --> 00:05:50,960 the faster the ransomware attacks can be contained and remediated. 115 00:05:50,960 --> 00:05:54,040 The next thing that I wanted to talk about is 116 00:05:54,040 --> 00:06:03,320 a blog title ensure compliance using separation of duties checks in access request. 117 00:06:03,320 --> 00:06:08,840 It talks about the separation of duty checks feature that are now 118 00:06:08,840 --> 00:06:13,280 in preview in Azure AD Entitlement Management, 119 00:06:13,280 --> 00:06:15,680 which helps prevent user from 120 00:06:15,680 --> 00:06:20,680 acquiring excessive or incompatible access rights. 121 00:06:20,680 --> 00:06:26,280 An example given is that auditors may know one person that is 122 00:06:26,280 --> 00:06:30,080 in the sales department to be able to change accounting data, 123 00:06:30,080 --> 00:06:35,400 or maybe they don't want IT auditors to also be an IT administrator. 124 00:06:35,400 --> 00:06:39,120 The separation of duty prevents user from receiving 125 00:06:39,120 --> 00:06:44,920 this type of combination of permissions that could lead to misuse. 126 00:06:44,920 --> 00:06:48,080 The last news I wanted to share is 127 00:06:48,080 --> 00:06:51,960 the Azure Security Center compliance over time report. 128 00:06:51,960 --> 00:06:55,640 This is a way to see changes over time on 129 00:06:55,640 --> 00:06:58,680 applying the proper compliance requirement. 130 00:06:58,680 --> 00:07:01,200 A couple of things caught my attention this week. 131 00:07:01,200 --> 00:07:07,440 The first is something I actually contributed to a long time ago when we did the first revision of this. 132 00:07:07,440 --> 00:07:10,920 We have this incident response reference guide was what we put out, 133 00:07:10,920 --> 00:07:16,880 and it was in a downloadable PDF and we converted that and modernized it. 134 00:07:16,880 --> 00:07:23,480 That's out there for folks to learn a little bit of Zen and the art of how to respond to 135 00:07:23,480 --> 00:07:28,880 incidents from a process design perspective and a philosophical perspective, 136 00:07:28,880 --> 00:07:32,400 and how do you think about shaping that so that you're effective on it? 137 00:07:32,400 --> 00:07:34,920 A lot of good advice, a lot of hard one lessons learned from 138 00:07:34,920 --> 00:07:39,160 our dark team, IR team, and many customers as well. 139 00:07:39,160 --> 00:07:42,600 The other thing that I wanted to talk about and share a little this week, 140 00:07:42,600 --> 00:07:46,880 it's a little bit of good news because one of the things that's always frustrating to me is, 141 00:07:46,880 --> 00:07:52,520 how much our industry is so splintered with different points of view that are selling products, 142 00:07:52,520 --> 00:07:55,280 or this or that, or in different ways. 143 00:07:55,280 --> 00:07:59,640 We always end up with this chaos that lands on customers, 144 00:07:59,640 --> 00:08:03,680 or Microsoft's customers, that people have to figure out, 145 00:08:03,680 --> 00:08:06,640 what is the truth amongst all this noise? 146 00:08:06,640 --> 00:08:11,360 One of the things that was inspiring for me a little bit was, 147 00:08:11,360 --> 00:08:13,920 I was part of the NCCOE, 148 00:08:13,920 --> 00:08:17,080 the National Cybersecurity Center of Excellence, 149 00:08:17,080 --> 00:08:20,120 Zero Trust Ever that NIST is hosting. 150 00:08:20,120 --> 00:08:25,680 We got to see pretty much all the different vendors share their point of view on Zero Trust. 151 00:08:25,680 --> 00:08:31,200 It was as diverse as you would imagine it, 152 00:08:31,200 --> 00:08:33,440 it might be with all these vendors and 153 00:08:33,440 --> 00:08:36,960 different security product makers providing their points of view. 154 00:08:36,960 --> 00:08:41,440 The cool thing was, is that I started to see that NIST diagram 155 00:08:41,440 --> 00:08:45,240 started to become a central theme as everyone mapping their stuff to it, 156 00:08:45,240 --> 00:08:47,440 and it created a level consistency. 157 00:08:47,440 --> 00:08:50,920 A nice glimmer of hope there that Zero Trust will help 158 00:08:50,920 --> 00:08:55,200 our industry become a lot more consistent and a lot more, 159 00:08:55,200 --> 00:09:01,360 which of course helps you execute well because you're not arguing over details that aren't as important. 160 00:09:01,360 --> 00:09:03,520 The other thing that occurred to me lately, 161 00:09:03,520 --> 00:09:05,880 I'll do this as quick as I can, 162 00:09:05,880 --> 00:09:08,760 I started to see more and more how important it is for 163 00:09:08,760 --> 00:09:14,080 security to really look at itself through the lens of being a part of the business, 164 00:09:14,080 --> 00:09:21,720 and really partnering much closer with the business lines and the functions of the business. 165 00:09:21,720 --> 00:09:24,040 One of the things I started to realize that has, 166 00:09:24,040 --> 00:09:29,760 I think is at the root of a lot of the challenges that we experience in security organizations, 167 00:09:29,760 --> 00:09:34,320 is that the accountability really isn't in the right place. 168 00:09:34,320 --> 00:09:35,960 When you think about risk, 169 00:09:35,960 --> 00:09:40,080 like something goes wrong or goes right with your car or whatever it happens to be, 170 00:09:40,080 --> 00:09:42,000 you own all the good and the bad of it, 171 00:09:42,000 --> 00:09:44,840 where you park it, how fast you drive it, etc. 172 00:09:44,840 --> 00:09:48,400 But when we look at security and an asset from a business point of view, 173 00:09:48,400 --> 00:09:51,920 oftentimes anything that could go wrong normally, 174 00:09:51,920 --> 00:09:56,240 pretty much lands on the asset owner in the business, 175 00:09:56,240 --> 00:09:58,880 except for security. We're going to blame the security guys for that, 176 00:09:58,880 --> 00:10:03,400 because that's obviously a technical fault that these smart humans did stuff. 177 00:10:03,400 --> 00:10:06,440 We often see this blaming of the CISO and 178 00:10:06,440 --> 00:10:09,400 blaming of the security organization when something goes wrong. 179 00:10:09,400 --> 00:10:15,400 We're talking 30 to 40 or 50 years of decisions were made when security wasn't important, 180 00:10:15,400 --> 00:10:17,760 and whoever in security now inherited that. 181 00:10:17,760 --> 00:10:19,920 So it's really not really that fair, 182 00:10:19,920 --> 00:10:22,560 quite frankly, to put it on security and own that. 183 00:10:22,560 --> 00:10:27,680 It also drives bad behavior because if I don't have to own the security outcomes of 184 00:10:27,680 --> 00:10:29,720 a decision as a business asset owner, 185 00:10:29,720 --> 00:10:32,960 then I'm going to take a lot more risks than I should, 186 00:10:32,960 --> 00:10:34,520 versus if I actually own it, 187 00:10:34,520 --> 00:10:36,560 I'm going to think about it a lot more carefully. 188 00:10:36,560 --> 00:10:39,720 That doesn't mean we're just going to dump the responsibility on these business asset owners 189 00:10:39,720 --> 00:10:41,640 and say, you figure out the cyber, 190 00:10:41,640 --> 00:10:43,000 because they don't know. 191 00:10:43,000 --> 00:10:46,760 But the more that we can security professionals be a bridge, 192 00:10:46,760 --> 00:10:52,560 and or rather build a bridge and help educate them and help them understand in their terms, 193 00:10:52,560 --> 00:10:55,120 what cybersecurity really means to them, 194 00:10:55,120 --> 00:10:57,560 and learn their language and communicate, 195 00:10:57,560 --> 00:11:02,640 I think much better off we will be in cybersecurity in the short term and the long term. 196 00:11:02,640 --> 00:11:04,960 So just a couple of thoughts there. 197 00:11:04,960 --> 00:11:06,520 Well, now we have the news out of the way. 198 00:11:06,520 --> 00:11:08,560 Let's turn attention to our guest. 199 00:11:08,560 --> 00:11:10,600 This week we have Michael McLevich, 200 00:11:10,600 --> 00:11:13,000 who's here to talk to us about 201 00:11:13,000 --> 00:11:15,600 Azure Defender for SQL Threat Protection. 202 00:11:15,600 --> 00:11:17,160 Welcome to the podcast, Michael. 203 00:11:17,160 --> 00:11:20,240 Michael, do you want to give our listeners a little background on what you're doing, 204 00:11:20,240 --> 00:11:22,160 how long you've been at Microsoft? 205 00:11:22,160 --> 00:11:24,440 Thank you, Mikhail. 206 00:11:24,440 --> 00:11:27,320 I've been at Microsoft for three years now. 207 00:11:27,320 --> 00:11:31,840 All of the time I was a product manager for Azure Defender for SQL. 208 00:11:31,840 --> 00:11:33,440 It's been rebranded a few times, 209 00:11:33,440 --> 00:11:37,280 so maybe you remember it is Azure's Advanced Threat Protection, 210 00:11:37,280 --> 00:11:39,200 which is catching attacks. 211 00:11:39,200 --> 00:11:41,240 You bring up an important point there. 212 00:11:41,240 --> 00:11:44,400 We will have a follow-on to this in September, 213 00:11:44,400 --> 00:11:48,560 where we will talk about the other pillar that's not being talked about today. 214 00:11:48,560 --> 00:11:51,400 So before we get stuck into this, 215 00:11:51,400 --> 00:11:56,800 let's welcome a little bit of a historical perspective as to what this product does. 216 00:11:56,800 --> 00:11:58,560 I mean, amongst many other things, 217 00:11:58,560 --> 00:12:00,440 and please correct me if I'm wrong here, 218 00:12:00,440 --> 00:12:04,400 but a big part of what this product detects in real time 219 00:12:04,400 --> 00:12:07,320 is SQL injection vulnerabilities. 220 00:12:07,320 --> 00:12:09,000 Is that a fair comment? 221 00:12:09,000 --> 00:12:14,640 Yes. I think SQL injection is one of the attacks that we catch with the Advanced Threat Detection. 222 00:12:14,640 --> 00:12:21,040 But for sure, it's one of the most popular and famous SQL related attacks. 223 00:12:21,040 --> 00:12:24,120 But it's also a pretty interesting attack because you're attacking, 224 00:12:24,120 --> 00:12:27,280 like you don't need to breach credentials or users, 225 00:12:27,280 --> 00:12:30,280 something like that to exploit SQL injection. 226 00:12:30,280 --> 00:12:36,000 You're doing that through an interface that is aimed for inserting data. 227 00:12:36,000 --> 00:12:41,800 The data is just not cleaned properly, but it makes it pretty unique. 228 00:12:41,800 --> 00:12:43,720 We have also other families of detectors. 229 00:12:43,720 --> 00:12:46,080 We are working on adding new detectors. 230 00:12:46,080 --> 00:12:49,800 From a historic perspective, I think SQL injection for a long time 231 00:12:49,800 --> 00:12:51,360 was our flagship detector. 232 00:12:51,360 --> 00:12:53,360 Yeah, and just to add a little bit of context there. 233 00:12:53,360 --> 00:12:59,200 So back in the day, I worked on our web server, IIS. 234 00:12:59,200 --> 00:13:04,560 Obviously, IIS was used to front-end hundreds of thousands, if not more, 235 00:13:04,560 --> 00:13:06,800 SQL server instances. 236 00:13:06,800 --> 00:13:12,360 One day I got an email from this guy who went by the handle of Rainforest Puppy 237 00:13:12,360 --> 00:13:16,520 saying that he'd found this class of vulnerabilities through IIS, 238 00:13:16,520 --> 00:13:20,720 even though the vulnerability technically wasn't in IIS or SQL server technically. 239 00:13:20,720 --> 00:13:24,680 It was in the way custom code was written to query the database. 240 00:13:24,680 --> 00:13:29,800 That was my first baptism of SQL injection vulnerabilities. 241 00:13:29,800 --> 00:13:31,880 Yes, that was Rainforest Puppy. 242 00:13:31,880 --> 00:13:34,960 In fact, RFP and I have actually hooked up again after all these years. 243 00:13:34,960 --> 00:13:38,320 His real name is Jeff Forrestal, a fantastic guy. 244 00:13:38,320 --> 00:13:42,080 But yeah, I was on the front lines there with cross-site scripting, 245 00:13:42,080 --> 00:13:44,200 SQL injection, memory corruption, 246 00:13:44,200 --> 00:13:46,640 file name canonicalization problems back in the day. 247 00:13:46,640 --> 00:13:49,640 I'm sure that's probably bringing back PTSD for a few people out there. 248 00:13:49,640 --> 00:13:54,040 But I have a long history with preventing SQL injection vulnerabilities. 249 00:13:54,040 --> 00:13:57,120 Back to the product itself. 250 00:13:57,120 --> 00:14:02,240 You want to give us an idea of what versions of SQL server this thing protects? 251 00:14:02,240 --> 00:14:07,320 Yeah. We protect all the SQLs in the Cloud. 252 00:14:07,320 --> 00:14:10,000 That's the first. Azure SQL servers, 253 00:14:10,000 --> 00:14:12,360 SQL databases, managed instance, 254 00:14:12,360 --> 00:14:17,840 SQL servers that are inside the Synapse workspaces used to be SQL data warehouses. 255 00:14:17,840 --> 00:14:20,400 We also have only thread detection without 256 00:14:20,400 --> 00:14:24,800 Azure and ability assessment currently for open source databases in Azure. 257 00:14:24,800 --> 00:14:29,160 It's not exactly SQL, but it's another plan that we have. 258 00:14:29,160 --> 00:14:34,040 Azure, like protecting the Azure Postgres SQL, 259 00:14:34,040 --> 00:14:36,560 Azure MySQL, and MariaDB. 260 00:14:36,560 --> 00:14:39,120 Also, in the last year and a half, 261 00:14:39,120 --> 00:14:42,200 we realized when you protect a database, 262 00:14:42,200 --> 00:14:44,600 you don't want to only protect a database. 263 00:14:44,600 --> 00:14:48,920 You want to protect your entire environment and your entire data environment. 264 00:14:48,920 --> 00:14:53,640 We spread it also to hybrid environments and outside of Azure, 265 00:14:53,640 --> 00:14:57,280 protect SQL servers 2012 and above, 266 00:14:57,280 --> 00:15:01,480 in on-premise on Azure VMs, Amazon EC2s. 267 00:15:01,480 --> 00:15:03,680 Going back to the previous question, 268 00:15:03,680 --> 00:15:06,320 we started already in the Cloud area. 269 00:15:06,320 --> 00:15:13,320 I think a lot of protection and data security solutions started way back then at 270 00:15:13,320 --> 00:15:17,280 the on-premise era and now they're trying to move into the Cloud. 271 00:15:17,280 --> 00:15:18,920 We started in the Cloud. 272 00:15:18,920 --> 00:15:21,880 Our first product was Azure Defender for 273 00:15:21,880 --> 00:15:24,880 Protection of Business for Azure SQL servers. 274 00:15:24,880 --> 00:15:28,520 Then we realized that customers are not doing 275 00:15:28,520 --> 00:15:30,800 or only on-prem or only Cloud, 276 00:15:30,800 --> 00:15:32,280 they're choosing hybrid environments. 277 00:15:32,280 --> 00:15:35,080 So we moved that also those. 278 00:15:35,080 --> 00:15:37,640 An interesting fact that we realized is that 279 00:15:37,640 --> 00:15:40,320 attackers have sometimes different targets. 280 00:15:40,320 --> 00:15:44,120 One target which is maybe the more obvious target, 281 00:15:44,120 --> 00:15:47,840 everyone is calling data the modern crown jewels. 282 00:15:47,840 --> 00:15:49,280 So when you protect SQL, 283 00:15:49,280 --> 00:15:51,320 it's obvious you're trying to protect the data. 284 00:15:51,320 --> 00:15:53,400 We're trying to exfiltrate the data, 285 00:15:53,400 --> 00:15:58,040 and they're trying to take the data out and then lock it in some ransomware manner, 286 00:15:58,040 --> 00:16:00,560 and just sell the data stuff like that. 287 00:16:00,560 --> 00:16:04,320 But when we got ourselves into SQL servers on-prem, 288 00:16:04,320 --> 00:16:06,960 we also realized another interesting pattern, 289 00:16:06,960 --> 00:16:11,680 that is attackers are trying to attack the SQL server not to gain access to the data, 290 00:16:11,680 --> 00:16:13,800 but to gain access to the machine. 291 00:16:13,800 --> 00:16:15,480 SQL servers on-prem, 292 00:16:15,480 --> 00:16:20,320 and they're these big and strong machines with lots of configuration, 293 00:16:20,320 --> 00:16:22,440 which might confuse a few people, 294 00:16:22,440 --> 00:16:28,760 and they're sometimes hard to update or to change because they require a lot of expertise. 295 00:16:28,760 --> 00:16:32,720 What happens there is that attackers try to brute-force all SQL server machines and 296 00:16:32,720 --> 00:16:37,120 using commands like XP command shell or the ability to 297 00:16:37,120 --> 00:16:39,520 write registries from the SQL to the Windows. 298 00:16:39,520 --> 00:16:43,120 They're just jumping from the SQL to the OS layer. 299 00:16:43,120 --> 00:16:45,600 Then they're starting things like crypto miners, 300 00:16:45,600 --> 00:16:47,560 run somewhere attacks on the entire machine. 301 00:16:47,560 --> 00:16:49,200 Actually, you bring up an interesting point there about 302 00:16:49,200 --> 00:16:51,880 XP underscore command shell and tweaking the registry. 303 00:16:51,880 --> 00:16:53,400 I think it's important to understand that. 304 00:16:53,400 --> 00:16:57,320 I think it's important, our listeners understand that those features are not there in 305 00:16:57,320 --> 00:17:03,320 the Azure native, the cloud native versions of, say, Azure SQL DB. 306 00:17:03,320 --> 00:17:06,840 This is an important point because XP underscore command shell, 307 00:17:06,840 --> 00:17:12,800 for those of you not aware, is a way of essentially invoking anything from any command shell. 308 00:17:12,800 --> 00:17:17,880 So command.exe or whatever you need to run from within the context of SQL server. 309 00:17:17,880 --> 00:17:21,440 That can become quite dangerous actually because if you've got a SQL server running 310 00:17:21,440 --> 00:17:23,680 in an elevated environment, 311 00:17:23,680 --> 00:17:26,880 let's say it's running as a system, 312 00:17:26,880 --> 00:17:28,800 which by the way, you should never do. 313 00:17:28,800 --> 00:17:31,720 But let's just take a pathological example and say it is. 314 00:17:31,720 --> 00:17:35,120 Then in theory, XP underscore command shell is now running a system. 315 00:17:35,120 --> 00:17:38,160 That's a very serious vulnerability. 316 00:17:38,160 --> 00:17:41,560 Now, the cool thing is that in the PAS offerings of 317 00:17:41,560 --> 00:17:44,840 Azure SQL DB, that feature is not there. 318 00:17:44,840 --> 00:17:46,440 It's not that you can turn it on, 319 00:17:46,440 --> 00:17:48,160 it's just not there. 320 00:17:48,160 --> 00:17:52,320 Same with other features like being able to write to the registry, 321 00:17:52,320 --> 00:17:54,160 that feature is not there either. 322 00:17:54,160 --> 00:17:57,960 The other aspect which I think is critically important is, 323 00:17:57,960 --> 00:18:03,720 on-prem SQL server, you have complete control over what identity that process runs as. 324 00:18:03,720 --> 00:18:08,200 Whereas in the case of when it's running in the cloud, you don't. 325 00:18:08,200 --> 00:18:11,240 All our PAS offerings run at least privilege. 326 00:18:11,240 --> 00:18:13,800 They always do and you can't configure it, you can't change it. 327 00:18:13,800 --> 00:18:16,840 So these are examples of something we've often referred to as 328 00:18:16,840 --> 00:18:18,040 the shared responsibility model, 329 00:18:18,040 --> 00:18:20,760 where some things are managed by Microsoft and Azure and 330 00:18:20,760 --> 00:18:22,760 some things are managed by the customer. 331 00:18:22,760 --> 00:18:27,400 This is a really good example of where we're handling some of the default configurations. 332 00:18:27,400 --> 00:18:31,480 So you don't have to and you don't potentially run the risk of making 333 00:18:31,480 --> 00:18:35,360 a mistake and exposing this as you point out, 334 00:18:35,360 --> 00:18:38,840 you're exposing this compute power to 335 00:18:38,840 --> 00:18:41,400 attackers because those features are just not there. 336 00:18:41,400 --> 00:18:44,120 Yeah. I couldn't agree with you more, Michael, 337 00:18:44,120 --> 00:18:48,840 on how important it is to look at that shared responsibility model profile and 338 00:18:48,840 --> 00:18:51,920 favor the cloud because it is much better. 339 00:18:51,920 --> 00:18:58,280 But I also love that the SQL Defender capabilities are also hybrid because no matter how much you 340 00:18:58,280 --> 00:19:01,800 love the cloud and you want to get there because of that lower risk, 341 00:19:01,800 --> 00:19:04,760 you do have to always secure the enterprise you got. 342 00:19:04,760 --> 00:19:11,560 So I'm a huge fan of this. I've been following it ever since the SQL Defender ATP or whatever it was 343 00:19:11,560 --> 00:19:14,600 called and it when it launched was out there. 344 00:19:14,600 --> 00:19:17,720 I'm applying UVA technology, the SQL injection detection. 345 00:19:17,720 --> 00:19:19,320 So yeah, love it. 346 00:19:19,320 --> 00:19:22,360 So when Michael and I were talking about this earlier in the week, 347 00:19:22,360 --> 00:19:24,920 he mentioned, I didn't even think about this, 348 00:19:24,920 --> 00:19:32,600 but using SQL Server is essentially another step in the road for pushing out ransomware 349 00:19:32,600 --> 00:19:37,320 and being and using the compute power of these databases as crypto miners. 350 00:19:37,320 --> 00:19:43,480 Is that something that you're seeing or heard of much around SQL databases being used for ransomware? 351 00:19:44,680 --> 00:19:50,440 So we saw it especially with all the SQL servers and sometimes it's interesting because 352 00:19:51,480 --> 00:19:57,640 you see customers that they decide what to protect on based on the sensitivity of the data that is 353 00:19:57,640 --> 00:20:00,440 in the database or if it's production or not production. 354 00:20:00,440 --> 00:20:03,080 But when your goal is a crypto miner, for example, 355 00:20:03,080 --> 00:20:07,000 you don't care about the data in the database or if it's production or not production. 356 00:20:07,000 --> 00:20:08,440 CPU is a CPU for you. 357 00:20:09,800 --> 00:20:15,400 So it's an interesting example where you have a component and that someone is thinking of 358 00:20:15,400 --> 00:20:21,480 protecting only parts of it or protecting it only if it makes some criteria in the gain function that 359 00:20:21,480 --> 00:20:25,400 he sees. The customer wants to protect only the data. 360 00:20:25,400 --> 00:20:27,320 He says, all right, there is no production data there. 361 00:20:27,320 --> 00:20:28,600 There is no sensitive data there. 362 00:20:28,600 --> 00:20:30,520 I want to protect the SQL server. 363 00:20:30,520 --> 00:20:35,560 Then the SQL server is being breached and the SQL server itself, as we mentioned, 364 00:20:35,560 --> 00:20:41,480 doesn't have any interest in the pressure or bounty for the attacker. 365 00:20:41,480 --> 00:20:48,840 But from the SQL server, you can go to the compute power and run a crypto miner or start 366 00:20:48,840 --> 00:20:51,400 a lot of movement inside the network. 367 00:20:51,400 --> 00:20:53,640 Think to circle back to your point. 368 00:20:53,640 --> 00:20:58,520 So those are great points and I didn't mention why we started seeing those 369 00:20:58,520 --> 00:21:03,080 attacks all in on premise because in Azure, they are all blocked. 370 00:21:05,640 --> 00:21:09,080 To be fair, you always need to talk about security together with productivity. 371 00:21:09,080 --> 00:21:11,560 It's always a fine balance between those. 372 00:21:11,560 --> 00:21:17,080 But I think it's also really important to remember that a lot of times what is comfortable for you 373 00:21:17,080 --> 00:21:19,560 is also comfortable for the attacker. 374 00:21:19,560 --> 00:21:25,000 So we see a lot of customers that indeed, I think as you said, Xp CMD shell, 375 00:21:25,000 --> 00:21:30,920 the ability to run commercials from the SQL is by default off also for SQL servers on RAM. 376 00:21:30,920 --> 00:21:33,240 Starting some year, I don't remember at which point. 377 00:21:33,240 --> 00:21:40,200 The idea here is that customers sometimes prefer to go, I would say, the lazy way or the simplest 378 00:21:40,200 --> 00:21:43,400 way and use this tool, although there are other alternatives. 379 00:21:43,400 --> 00:21:46,200 But that's exactly what attackers also want to do. 380 00:21:46,200 --> 00:21:49,800 If it's comfortable for the customer, it would be comfortable for the attacker. 381 00:21:49,800 --> 00:21:52,120 If the customer can easily run things on the machine, 382 00:21:52,120 --> 00:21:56,200 so the attacker would also want to run things easily on the machine. 383 00:21:56,200 --> 00:22:00,440 And we didn't see it happening not too rarely. 384 00:22:00,440 --> 00:22:01,080 Unfortunately. 385 00:22:01,080 --> 00:22:01,640 Yeah. 386 00:22:01,640 --> 00:22:06,360 You know, I remember when it was turned off, when it was turned off by default in the on-prem 387 00:22:06,360 --> 00:22:10,760 version of SQL Server, because I was actually involved, actually sort of actively involved 388 00:22:10,760 --> 00:22:12,920 in many of the conversations that led to that decision. 389 00:22:13,560 --> 00:22:18,440 And my somewhat flippant but serious comment was, look, when you've got a feature in a product 390 00:22:18,440 --> 00:22:22,280 where the number one user of that feature is the attacking community, 391 00:22:22,920 --> 00:22:24,920 then perhaps it's time to turn that feature off. 392 00:22:25,640 --> 00:22:26,920 That wasn't the only thing that was turned off. 393 00:22:26,920 --> 00:22:30,120 It was XP underscore command shell, but also common support was turned off too. 394 00:22:31,000 --> 00:22:35,000 So that way, you know, people weren't writing com objects, you know, if you're doing SQL queries. 395 00:22:35,000 --> 00:22:37,320 We talked about PaaS versus IaaS. 396 00:22:37,320 --> 00:22:42,360 So this, as you mentioned before, this protects all versions of SQL Server, 397 00:22:42,360 --> 00:22:48,840 both on-prem, those running, say, AWS in EC2 instances, as well as our PaaS offerings, 398 00:22:48,840 --> 00:22:52,600 like as you see called DB and as you see called managed instance. 399 00:22:53,240 --> 00:22:55,560 And you also mentioned the productivity aspect. 400 00:22:55,560 --> 00:22:57,640 I think that's always important as well. 401 00:22:57,640 --> 00:22:59,880 What else, what other things, you know, can this is product do? 402 00:22:59,880 --> 00:23:03,720 What other classes of vulnerabilities does this tool sort of detect? 403 00:23:04,760 --> 00:23:05,080 All right. 404 00:23:05,080 --> 00:23:07,000 So we have a few classes. 405 00:23:07,560 --> 00:23:11,320 One that we already mentioned is, of course, SQL injection. 406 00:23:11,320 --> 00:23:13,320 Our flagship for a long time also. 407 00:23:13,320 --> 00:23:17,880 Now we can maybe circle back to our SQL injection algorithm. 408 00:23:17,880 --> 00:23:18,920 And it's pretty interesting one. 409 00:23:18,920 --> 00:23:24,040 It's, we have a few patterns for it and it's more interesting than the basic looking for one equal one. 410 00:23:24,600 --> 00:23:27,000 For those that are familiar with SQL injection. 411 00:23:27,640 --> 00:23:34,840 We have a family of UEBA, which is, which stands for a user entity behavior analysis. 412 00:23:34,840 --> 00:23:40,920 When we find anomalies in the communication with the database or the activity of the database. 413 00:23:40,920 --> 00:23:46,280 We have another algorithm which became kind of a family is the brute force detector, 414 00:23:46,280 --> 00:23:49,400 which we involved into having three layers of brute force. 415 00:23:49,400 --> 00:23:51,160 And that's also an interesting story. 416 00:23:51,880 --> 00:23:55,400 And we have a threat intelligence algorithm based, 417 00:23:55,400 --> 00:23:57,000 which are coming from the vast, 418 00:23:57,000 --> 00:24:03,240 pentatonicus that Microsoft is collecting also by itself and from customers and from vendors. 419 00:24:03,240 --> 00:24:06,680 And we're using all this data to alert you when there is a 420 00:24:08,040 --> 00:24:10,680 suspicious IP is approaching your database. 421 00:24:10,680 --> 00:24:14,680 When I first saw this feature, one of the first things that sort of sprung to mind was, 422 00:24:15,400 --> 00:24:16,440 how does this work? 423 00:24:16,440 --> 00:24:20,280 I mean, is this something that runs in the SQL server process? 424 00:24:20,280 --> 00:24:22,760 I mean, do I have to pay for the compute? 425 00:24:22,760 --> 00:24:26,200 Do I have to, you know, am I going to see a performance hit from running this tool? 426 00:24:27,320 --> 00:24:27,560 All right. 427 00:24:27,560 --> 00:24:29,720 So this is a great question. 428 00:24:29,720 --> 00:24:33,880 And it comes back again to the productivity or some kind of productivity versus security. 429 00:24:34,440 --> 00:24:37,640 You know, the most secure SQL server would probably be a brick, 430 00:24:37,640 --> 00:24:39,560 but you can't do much with the brick, right? 431 00:24:39,560 --> 00:24:41,800 There is always some fine balance. 432 00:24:41,800 --> 00:24:48,120 In the cloud, you actually pay nothing out of your performance, compute, stuff like that. 433 00:24:48,120 --> 00:24:49,960 It's all running in the background. 434 00:24:49,960 --> 00:24:52,600 And so this is another great plus for the cloud. 435 00:24:53,240 --> 00:24:59,880 You just enable it and you can enable it or on the SQL server level or through Azure Security 436 00:24:59,880 --> 00:25:02,440 Center on the entire subscription level. 437 00:25:02,440 --> 00:25:05,480 They just protects all your SQL servers and that subscription. 438 00:25:05,480 --> 00:25:10,360 In the background, we have our own compute side by side with your compute, 439 00:25:10,360 --> 00:25:11,800 but it doesn't affect you. 440 00:25:11,800 --> 00:25:14,120 It's also very not intrusive. 441 00:25:14,120 --> 00:25:20,360 It's reading the queries, the logins after they're happening and analyzing if there are any attacks. 442 00:25:20,360 --> 00:25:22,440 For the SQL servers on machine. 443 00:25:22,440 --> 00:25:24,520 And so the story is a little bit different. 444 00:25:24,520 --> 00:25:30,280 There indeed you need to install an agent and our analysis is running on your machine. 445 00:25:30,280 --> 00:25:33,960 So it takes part of your compute and part of your memory. 446 00:25:33,960 --> 00:25:36,040 We're always doing tests for that. 447 00:25:36,040 --> 00:25:44,680 We are always monitoring for the community of protected customers, what the situation is there. 448 00:25:44,680 --> 00:25:49,000 And when we do deployments, we always check our standards there. 449 00:25:49,000 --> 00:25:52,840 Like for SQL servers on-prem, we don't have much of another option. 450 00:25:52,840 --> 00:25:55,880 You would always pay something out of your compute. 451 00:25:55,880 --> 00:25:59,000 We're trying to make it as minimal as possible. 452 00:25:59,000 --> 00:26:02,600 And we're aiming for less than 5% on average. 453 00:26:02,600 --> 00:26:05,240 But of course, and I don't want to promise you anything, 454 00:26:05,240 --> 00:26:06,840 it really depends on your payload. 455 00:26:06,840 --> 00:26:11,400 It can be much less as much as there is much less to go from 5%. 456 00:26:11,400 --> 00:26:17,000 And it might be more really depending on the workload that you're on. 457 00:26:17,000 --> 00:26:21,960 Michael, so can you explain a little bit how the telemetry comes through? 458 00:26:21,960 --> 00:26:25,880 Is this interconnected into Washer Security Center? 459 00:26:25,880 --> 00:26:26,760 How is it shown? 460 00:26:27,960 --> 00:26:29,560 In the cloud, it's very easy. 461 00:26:29,560 --> 00:26:33,080 The telemetry, we get it from the background process. 462 00:26:33,080 --> 00:26:36,520 We started as part of the Azure SQL team. 463 00:26:36,520 --> 00:26:41,880 So there it's really nicely handled and you don't need to do anything. 464 00:26:41,880 --> 00:26:47,560 The detections themselves go to Azure Security Center for the on-prem version. 465 00:26:47,560 --> 00:26:51,160 So there again, the situation is always a little bit more complicated. 466 00:26:51,160 --> 00:26:57,400 And we get the telemetry from the Log Analytics agent, also known as OMS agent. 467 00:26:57,400 --> 00:27:02,200 That's the current solution, that's the solution that used in Azure Security Center 468 00:27:02,200 --> 00:27:04,120 for a server telemetry. 469 00:27:04,120 --> 00:27:07,080 So we wanted to make sure all aligned there. 470 00:27:07,080 --> 00:27:10,920 The detections and alerts themselves go to Azure Security Center 471 00:27:10,920 --> 00:27:15,160 and can be exported and go from Azure Security Center as any other alert. 472 00:27:15,160 --> 00:27:19,720 And that's in general, a really important principle for us, 473 00:27:19,720 --> 00:27:25,480 to just keep every of the defender solutions aligned with the broader scope. 474 00:27:25,480 --> 00:27:33,560 So Azure Defender for SQL is trying to be as similar in the management point of view 475 00:27:33,560 --> 00:27:36,440 to Azure Defender for servers, Azure Defender for storage, 476 00:27:36,440 --> 00:27:37,880 Azure Defender for app services. 477 00:27:37,880 --> 00:27:39,000 So a last thought from me. 478 00:27:39,560 --> 00:27:44,680 So, I mean, how quickly can this tool respond when it detects anomalous behavior? 479 00:27:44,680 --> 00:27:46,360 I mean, what sort of time frames are we looking at here? 480 00:27:47,480 --> 00:27:53,080 All right, that's a great question and exactly a point that we're working on a lot lately. 481 00:27:53,080 --> 00:27:57,800 Our SQL injection detector is real-time detector. 482 00:27:57,800 --> 00:28:03,480 Our UEBA detectors take some more time and also the computer is done on our pipelines 483 00:28:03,480 --> 00:28:05,800 to not stress your machine currently. 484 00:28:05,800 --> 00:28:07,480 And you need to build a model, right? 485 00:28:07,480 --> 00:28:09,720 You have a lot of data to process there. 486 00:28:09,720 --> 00:28:14,600 So it used to take us around 20 minutes in average 487 00:28:14,600 --> 00:28:17,880 to alert you about anomalous behavior. 488 00:28:17,880 --> 00:28:21,320 And part of that pipeline was our brute force detector. 489 00:28:21,320 --> 00:28:27,320 We realized that letting you know about brute force 20 minutes after it started, 490 00:28:27,320 --> 00:28:30,840 it's way too late, doesn't allow you enough time 491 00:28:30,840 --> 00:28:35,640 or doesn't give you the right time to detect to respond to this detection, 492 00:28:35,640 --> 00:28:37,080 which is what really matters to us. 493 00:28:37,720 --> 00:28:42,520 So we did a lot of work lately and we took our brute force detection 494 00:28:42,520 --> 00:28:46,600 down from being around those 20 minutes to less than a minute. 495 00:28:46,600 --> 00:28:51,160 So currently brute force detections and SQL injection detections are real-time detectors. 496 00:28:51,160 --> 00:28:56,040 And we're working also to bring the other ones closely as possible to light detections. 497 00:28:56,040 --> 00:29:00,840 The idea with brute force is that now you can use other hooks in Azure Security Center 498 00:29:00,840 --> 00:29:05,160 and workflow automation to just block the brute force in the IEP out of the network 499 00:29:05,160 --> 00:29:07,800 and not allow it to continue. 500 00:29:07,800 --> 00:29:10,360 Before we wrap this up, I just thought about something. 501 00:29:10,360 --> 00:29:13,560 When you were talking about Azure Security Center, 502 00:29:13,560 --> 00:29:16,600 one of the nice things about feeding into Azure Security Center is that 503 00:29:16,600 --> 00:29:20,520 there's no extra education that's needed to learn some new tool. 504 00:29:20,520 --> 00:29:24,280 You can use all the reporting and reporting abilities and alerting abilities 505 00:29:24,280 --> 00:29:25,640 that are in Azure Security Center. 506 00:29:26,600 --> 00:29:30,520 I mean, my guess is you could probably even open up a ticket with ServiceNow or something, right? 507 00:29:30,520 --> 00:29:33,400 You could even export it to your scene. Is that a fair comment? 508 00:29:34,920 --> 00:29:38,200 Yeah, for sure. So you can do all of those things as you can do them 509 00:29:38,200 --> 00:29:41,960 for all the alerts in Azure Security Center, even raising the bar here. 510 00:29:41,960 --> 00:29:48,360 So if you already have some connector that opens every Azure Security Center for Server 511 00:29:48,360 --> 00:29:53,000 alert in ServiceNow or sending every Azure Defender for Storage 512 00:29:53,000 --> 00:29:58,280 alert into your scene solution, if you would now enable Azure Defender for SQL, 513 00:29:58,280 --> 00:30:00,920 it would be exactly the same experience, right? 514 00:30:00,920 --> 00:30:04,360 This is the same scheme, the same connector. It's really extendable. 515 00:30:04,360 --> 00:30:07,400 So yeah, you don't need to educate your people again. 516 00:30:07,400 --> 00:30:10,840 And all the automations are really smoothly moving on. 517 00:30:10,840 --> 00:30:14,040 So if you decided to start with only one of the Azure Defender plans 518 00:30:14,040 --> 00:30:17,080 and then go to the others, or you started with all of them 519 00:30:17,080 --> 00:30:22,040 and just want to turn on one, you started with a few relevant and there are the new ones that 520 00:30:22,040 --> 00:30:26,040 coming out. Everything is just fit in. You are part of the same family, 521 00:30:26,040 --> 00:30:28,200 you are part of the same suit. So yeah, it's a great comment. 522 00:30:28,200 --> 00:30:31,560 I've been learning a little bit about the integration. 523 00:30:32,200 --> 00:30:36,520 Does that mean also since we're talking about Azure Security Center, 524 00:30:36,520 --> 00:30:43,240 is it giving guidance as part of the secure score or ways for the customer to know that 525 00:30:43,240 --> 00:30:50,360 certain capabilities are not enabled? So I'm focusing on a SQL thread detection. 526 00:30:51,240 --> 00:30:57,080 We do have some integrations between the alerts and the recommendations. 527 00:30:57,720 --> 00:31:00,600 In the alert page, you can see the recommendations on the same resource. 528 00:31:00,600 --> 00:31:03,560 You can have a resource context, which is also something really strong 529 00:31:03,560 --> 00:31:08,280 that we have in Microsoft. And some other alternatives can't obtain 530 00:31:08,280 --> 00:31:10,840 because they don't have the old cloud context. 531 00:31:10,840 --> 00:31:14,920 But I'm not sure what you meant with the secure score here. 532 00:31:14,920 --> 00:31:20,760 It's just as part of threat protection that I have seen for other products. 533 00:31:20,760 --> 00:31:26,920 Sometimes in order to reduce the risk, we provide guidance. 534 00:31:26,920 --> 00:31:30,840 And I didn't know if SQL, the threat protection portion, 535 00:31:31,400 --> 00:31:37,320 basically surface data that guidance as part of secure scores on where else 536 00:31:37,320 --> 00:31:38,760 in Azure Security Center. 537 00:31:38,760 --> 00:31:45,000 Oh, so yeah. So as we started, there are two pillars for Azure Defender, 538 00:31:45,000 --> 00:31:47,240 threat protection, for Azure Defender for SQL. 539 00:31:47,240 --> 00:31:48,840 Thread protection is only one of them. 540 00:31:48,840 --> 00:31:52,600 We have the threat protection capabilities and the vulnerability assessment. 541 00:31:52,600 --> 00:31:55,000 The ability assessment is used for hardening. 542 00:31:55,000 --> 00:31:57,080 It goes into the security score. 543 00:31:57,080 --> 00:32:00,600 You can find it among the other recommendations in Azure Security Center. 544 00:32:00,600 --> 00:32:04,040 And that gives you the guidance of how to avoid those attacks. 545 00:32:04,040 --> 00:32:08,840 We're talking about learning from that threat protection. 546 00:32:08,840 --> 00:32:12,680 And I guess we're going to hear more next podcast. 547 00:32:12,680 --> 00:32:13,720 Yeah, that's the plan. 548 00:32:13,720 --> 00:32:18,040 Hey, Michael. So one thing we ask our guests is if they had one final thought 549 00:32:18,040 --> 00:32:20,200 to leave our listeners with, what would it be? 550 00:32:21,560 --> 00:32:22,760 Only one last thought. 551 00:32:22,760 --> 00:32:26,840 All right. I think I would say that a nice insight is to think about 552 00:32:26,840 --> 00:32:28,760 that attackers don't just want your data. 553 00:32:28,760 --> 00:32:30,840 They sometimes also want your data. 554 00:32:30,840 --> 00:32:32,600 But for sure, you need to protect your data. 555 00:32:32,600 --> 00:32:34,200 It's a multi-layered approach. 556 00:32:34,200 --> 00:32:35,480 You need to protect your data. 557 00:32:35,480 --> 00:32:37,880 You need to protect the compute benefit. 558 00:32:37,880 --> 00:32:41,320 And you need to protect the whole environment and care for the hygiene 559 00:32:41,320 --> 00:32:44,680 of your data environment to make sure the data is not stolen 560 00:32:44,680 --> 00:32:46,520 and the compute under it is also not stolen. 561 00:32:46,520 --> 00:32:48,200 Hey, Michael. Thank you so much for joining us this week. 562 00:32:48,200 --> 00:32:49,640 We really appreciate you taking the time. 563 00:32:49,640 --> 00:32:51,000 I know you're very busy. 564 00:32:51,000 --> 00:32:52,600 But again, I learned a great deal. 565 00:32:52,600 --> 00:32:56,440 It's always good to sort of go back into talking about SQL injection vulnerabilities 566 00:32:56,440 --> 00:32:59,000 even though this particular feature does one heck of a lot more 567 00:32:59,000 --> 00:33:01,000 than just detecting SQL injection. 568 00:33:01,000 --> 00:33:03,560 And to all our listeners out there, thank you so much for listening. 569 00:33:03,560 --> 00:33:05,240 Take care and we'll see you next time. 570 00:33:05,240 --> 00:33:07,880 Thanks for listening to the Azure Security Podcast. 571 00:33:07,880 --> 00:33:13,720 You can find show notes and other resources at our website, azsecuritypodcast.net. 572 00:33:14,600 --> 00:33:18,600 If you have any questions, please find us on Twitter at azuresecpod. 573 00:33:18,600 --> 00:33:32,440 Background music is from ccmixter.com and licensed under the Creative Commons license.