1 00:00:00,000 --> 00:00:09,600 Welcome to the Azure Security Podcast, where we discuss topics relating to security, privacy, 2 00:00:09,600 --> 00:00:13,280 reliability and compliance on the Microsoft Cloud Platform. 3 00:00:13,280 --> 00:00:18,580 Hey everybody, welcome to episode 93. 4 00:00:18,580 --> 00:00:22,040 This week is myself, Michael, with Mark and Sarah. 5 00:00:22,040 --> 00:00:23,580 And this week we have two guests. 6 00:00:23,580 --> 00:00:30,280 We have Tony Rice and we have David Ornstein, who are here to talk to us about the continuous 7 00:00:30,280 --> 00:00:34,320 Microsoft Security Development Lifecycle or the continuous SDL. 8 00:00:34,320 --> 00:00:38,160 But before we get to our guests, let's take a little lap around the news. 9 00:00:38,160 --> 00:00:40,800 Mark, why don't you kick things off? 10 00:00:40,800 --> 00:00:46,400 Yeah, so for my news, a couple things coming up for me. 11 00:00:46,400 --> 00:00:53,440 Tampa B-Sides going to be presenting at the main show on Saturday. 12 00:00:53,440 --> 00:00:58,280 And so I'm going to be talking about, I think we called it the No BS Sock, but some real 13 00:00:58,280 --> 00:01:03,620 straightforward truths around security operations and how it works and what good looks like 14 00:01:03,620 --> 00:01:09,520 and how they actually grow from a couple part-time people or one part-time person into a global 15 00:01:09,520 --> 00:01:11,480 kind of 24-7 operation. 16 00:01:11,480 --> 00:01:17,040 And I'm also doing some training, which is still available, some slots there, on the 17 00:01:17,040 --> 00:01:22,860 Friday before, talking about security adoption framework for Microsoft. 18 00:01:22,860 --> 00:01:29,040 So essentially, how are we guiding customers on the overall security modernization piece 19 00:01:29,040 --> 00:01:32,680 and kind of talking through how we guide that and some of the lessons learned, best practices 20 00:01:32,680 --> 00:01:33,680 there. 21 00:01:33,680 --> 00:01:38,160 So that's a two-hour session on the Friday from, I think, three to five. 22 00:01:38,160 --> 00:01:40,880 And then I'm also talking at RSA. 23 00:01:40,880 --> 00:01:44,920 So for folks that are going to be in that area, love to meet you face-to-face. 24 00:01:44,920 --> 00:01:51,840 I've got a couple of theater sessions on the show floor and then a main conference session. 25 00:01:51,840 --> 00:01:53,240 It's actually going to be a really fun one. 26 00:01:53,240 --> 00:01:56,600 It's called You're Doing It Wrong, Common Security Anti-Patterns. 27 00:01:56,600 --> 00:02:02,600 So we're really kind of zooming in on all the things that we see organizations kind 28 00:02:02,600 --> 00:02:07,420 of get wrong, often for all the right reasons and without really knowing that. 29 00:02:07,420 --> 00:02:11,320 But making sure we're calling out, hey, these are the opposite of best practices. 30 00:02:11,320 --> 00:02:13,600 These are the things you need to fix. 31 00:02:13,600 --> 00:02:16,480 And then how to address those with best practices. 32 00:02:16,480 --> 00:02:20,400 And we've got some interesting themes and whatnot that we're going to do there and reveal 33 00:02:20,400 --> 00:02:23,500 some interesting new content there as well. 34 00:02:23,500 --> 00:02:26,000 So that's the news for me. 35 00:02:26,000 --> 00:02:34,100 So I just have one bit of news this time, which is that Trusted Launch is now in preview 36 00:02:34,100 --> 00:02:35,380 for AKS. 37 00:02:35,380 --> 00:02:42,240 So essentially, that means that the Trusted Launch is improving the security of AKS nodes 38 00:02:42,240 --> 00:02:44,320 from persistent attack techniques. 39 00:02:44,320 --> 00:02:49,820 So it means that we're going to have the machines underneath have boot loaders that are verified 40 00:02:49,820 --> 00:02:54,160 and signed and also same for the OS kernels and the drivers. 41 00:02:54,160 --> 00:02:59,840 So of course, you're trying to have an entire boot chain that has been all secured. 42 00:02:59,840 --> 00:03:05,320 So you should go and have a look at that because of course, we love all of our boot chain being 43 00:03:05,320 --> 00:03:06,880 nice and secure. 44 00:03:06,880 --> 00:03:10,520 So go and have a play around with that if you're using AKS. 45 00:03:10,520 --> 00:03:12,080 And that's it from me. 46 00:03:12,080 --> 00:03:16,400 I actually have quite a bit of news this week, but I'll try and keep it brief. 47 00:03:16,400 --> 00:03:19,400 The first one is there's been a huge improvement in Azure Key Vault. 48 00:03:19,400 --> 00:03:23,560 In fact, I was talking to a customer this week who said that they couldn't use Key Vault. 49 00:03:23,560 --> 00:03:29,520 They had to use managed HSM instead because they have a requirement for FIPS 140-2 Level 50 00:03:29,520 --> 00:03:30,520 3 hardware. 51 00:03:30,520 --> 00:03:31,840 Well, guess what? 52 00:03:31,840 --> 00:03:40,280 Azure Key Vault now supports FIPS 140-2 Level 3 if you're using the hardware SKU like the 53 00:03:40,280 --> 00:03:42,160 two variants you can have. 54 00:03:42,160 --> 00:03:47,760 And if you use the non-standard SKU, that one includes support for FIPS 140-2 Level 55 00:03:47,760 --> 00:03:50,640 3 HSM, which is absolutely fantastic. 56 00:03:50,640 --> 00:03:55,880 All you have to do is create new versions of keys and they will roll over to the new 57 00:03:55,880 --> 00:03:57,200 hardware. 58 00:03:57,200 --> 00:04:00,680 There's also something which actually blew me away when I saw this because I did not 59 00:04:00,680 --> 00:04:02,640 know this was coming out. 60 00:04:02,640 --> 00:04:07,920 And that is that the Microsoft Intune Suite now supports the Microsoft Cloud PKI, which 61 00:04:07,920 --> 00:04:13,200 basically means that you can set up your own, essentially a certificate service to issue 62 00:04:13,200 --> 00:04:18,120 your own certificates for your own devices and your own services and so on. 63 00:04:18,120 --> 00:04:20,000 This is really magnificent to see. 64 00:04:20,000 --> 00:04:25,800 So I've got a couple of posts on that information because this is really, really cool because 65 00:04:25,800 --> 00:04:31,360 it means that you can now start, again, issuing your own certificates for your own use as 66 00:04:31,360 --> 00:04:33,680 opposed to using a third party. 67 00:04:33,680 --> 00:04:40,680 The next one is so Meryl Fernandes, who is a product manager over in Entra ID, has a 68 00:04:40,680 --> 00:04:45,640 video called Run a Quick OAuth App Audit of your Tenant Using This Command to Protect 69 00:04:45,640 --> 00:04:46,640 Yourself. 70 00:04:46,640 --> 00:04:51,480 So basically what it is is a tool that he's added to his MS Identity Toolkit. 71 00:04:51,480 --> 00:04:57,160 And it's a PowerShell command that will dump all the app IDs that you're using inside 72 00:04:57,160 --> 00:05:01,200 of your tenant so they can see if they're, are they being used, are they old, do they 73 00:05:01,200 --> 00:05:02,760 need revoking, you know what? 74 00:05:02,760 --> 00:05:06,480 A lot of people don't have a lot of visibility into their applications that are running 75 00:05:06,480 --> 00:05:08,140 with managed identities. 76 00:05:08,140 --> 00:05:12,040 So a big hat tip to Meryl for doing this. 77 00:05:12,040 --> 00:05:14,040 Next one is, actually I'm very proud of this. 78 00:05:14,040 --> 00:05:19,000 This is actually the first feature I've shipped in a Microsoft product in a long time, very, 79 00:05:19,000 --> 00:05:20,600 very long time. 80 00:05:20,600 --> 00:05:26,080 And that is we now have support for iterated and salted hash password verifiers in SQL 81 00:05:26,080 --> 00:05:29,520 Server 2022 Cumulative Update 12. 82 00:05:29,520 --> 00:05:35,920 So historically we stored a password verifier using SHA-512, which is okay. 83 00:05:35,920 --> 00:05:42,920 There's no vulnerability there, but some compliance programs require something even more secure, 84 00:05:42,920 --> 00:05:47,880 which is to perform iterations over that, again, slowing the attacker down. 85 00:05:47,880 --> 00:05:49,760 So we've now added that support. 86 00:05:49,760 --> 00:05:52,560 It's hidden behind a trace flag, so it's not enabled by default. 87 00:05:52,560 --> 00:05:54,000 You must go and enable it. 88 00:05:54,000 --> 00:05:56,920 But basically it's there for compliance purposes. 89 00:05:56,920 --> 00:05:59,040 And yeah, it's really good to see that being added. 90 00:05:59,040 --> 00:06:01,160 We started the work late last year. 91 00:06:01,160 --> 00:06:05,280 And this is driven primarily by customer requirements. 92 00:06:05,280 --> 00:06:11,600 Next one is, unless you've been living under a rock recently, there's been a big discussion 93 00:06:11,600 --> 00:06:18,720 about using Rust versus, say, C and C++ for systems development, or more accurately using 94 00:06:18,720 --> 00:06:20,560 memory safe languages. 95 00:06:20,560 --> 00:06:24,920 And there's a document came out from the government explaining the benefits of using memory safe 96 00:06:24,920 --> 00:06:25,920 languages. 97 00:06:25,920 --> 00:06:29,080 And Rust was called out as an example in there. 98 00:06:29,080 --> 00:06:35,440 Well, then there's a salvo came from the other side, which is from Bjarne Stroustrup and 99 00:06:35,440 --> 00:06:36,440 Herb Sutter. 100 00:06:36,440 --> 00:06:41,200 So Herb works at Microsoft and he's actually on the C++ ISO standardization committee. 101 00:06:41,200 --> 00:06:44,120 And he put out a post which is worth the read. 102 00:06:44,120 --> 00:06:52,480 And it's basically that the White House document ignores all the changes that have been made 103 00:06:52,480 --> 00:06:57,320 in modern C++ over the last half dozen years or so. 104 00:06:57,320 --> 00:06:58,960 So it's well worth looking at these. 105 00:06:58,960 --> 00:07:02,240 Don't get me wrong, I'm actually wearing a Rust t-shirt right now. 106 00:07:02,240 --> 00:07:03,640 I'm a huge fan of Rust. 107 00:07:03,640 --> 00:07:05,860 I really, really am. 108 00:07:05,860 --> 00:07:09,760 But modern C++ is also still worth a look. 109 00:07:09,760 --> 00:07:12,280 It's not your father's C++ anymore. 110 00:07:12,280 --> 00:07:17,280 Unfortunately, a lot of C++ code is still written as essentially a glorified C where 111 00:07:17,280 --> 00:07:21,840 you're dealing with pointers directly and buffers directly and so on and so forth. 112 00:07:21,840 --> 00:07:27,560 Whereas modern C++ abstracts that all away with almost zero performance degradation. 113 00:07:27,560 --> 00:07:31,920 So it's worth reading, especially if you're involved in that space. 114 00:07:31,920 --> 00:07:40,280 Next one, which is my last one, is that Microsoft Entra ID logins is now supported in Azure 115 00:07:40,280 --> 00:07:43,960 SQL Database if they have non-unique display names. 116 00:07:43,960 --> 00:07:50,360 Historically, you had to have a unique display name, which isn't always the case. 117 00:07:50,360 --> 00:07:54,040 It's quite possible you may have two, I don't know, John Smiths. 118 00:07:54,040 --> 00:08:00,360 Now you can actually create a login in Azure SQL Database using create login from external 119 00:08:00,360 --> 00:08:03,120 provider with object ID. 120 00:08:03,120 --> 00:08:06,560 And you can actually put in the GUID for the user as opposed to their name. 121 00:08:06,560 --> 00:08:09,080 So that way you get rid of this essentially this name collision. 122 00:08:09,080 --> 00:08:11,160 That's good to see as well. 123 00:08:11,160 --> 00:08:15,600 Always great to see these kinds of advancements being made in our database platforms. 124 00:08:15,600 --> 00:08:17,080 All right. 125 00:08:17,080 --> 00:08:18,680 That is my news out the way. 126 00:08:18,680 --> 00:08:21,020 So let's turn our attention to our guests. 127 00:08:21,020 --> 00:08:22,920 This week, as I mentioned, we have two guests. 128 00:08:22,920 --> 00:08:28,380 We have Tony and David, who are here to talk to us about Continuous SDL. 129 00:08:28,380 --> 00:08:29,800 So gentlemen, welcome to the podcast. 130 00:08:29,800 --> 00:08:33,080 We'd like to take a moment and introduce yourself to our listeners. 131 00:08:33,080 --> 00:08:34,560 Hi, everyone. 132 00:08:34,560 --> 00:08:35,920 Michael Mark. 133 00:08:35,920 --> 00:08:38,360 Nice to chat with you again. 134 00:08:38,360 --> 00:08:40,560 It's great to meet you, Sarah. 135 00:08:40,560 --> 00:08:41,920 My name is Tony Rice. 136 00:08:41,920 --> 00:08:45,160 I've been with Microsoft for 25 years. 137 00:08:45,160 --> 00:08:46,960 Yes, it's been that long. 138 00:08:46,960 --> 00:08:50,240 I've known Michael for a good fair few of them. 139 00:08:50,240 --> 00:08:55,320 I'm currently in the Digital Security and Resilience Organization. 140 00:08:55,320 --> 00:09:00,680 I'm responsible for Microsoft security policy all up, including the SDL. 141 00:09:00,680 --> 00:09:05,840 In my career throughout Microsoft, I've held various roles, including working in the field 142 00:09:05,840 --> 00:09:08,040 as a security consultant. 143 00:09:08,040 --> 00:09:14,600 More recently, working with the engineering groups, helping them implement the security 144 00:09:14,600 --> 00:09:15,600 development lifecycle. 145 00:09:15,600 --> 00:09:21,440 And that's where I first discovered that it actually needed to be updated. 146 00:09:21,440 --> 00:09:25,280 And so one of the things that we've been working on is something called Continuous SDL. 147 00:09:25,280 --> 00:09:26,520 Hey, everybody. 148 00:09:26,520 --> 00:09:27,520 My name is David Ornstein. 149 00:09:27,520 --> 00:09:30,080 I'm an engineering manager at Microsoft. 150 00:09:30,080 --> 00:09:33,680 I work in the Digital Security and Resilience Organization with Tony. 151 00:09:33,680 --> 00:09:36,400 We're peers in the company. 152 00:09:36,400 --> 00:09:42,440 I've been at Microsoft for 24 years, just sort of chasing Tony's tail along there a 153 00:09:42,440 --> 00:09:45,400 good amount of the time there. 154 00:09:45,400 --> 00:09:50,520 I'm a software engineer more than a security expert, but for the last 15 years or so, I've 155 00:09:50,520 --> 00:09:56,480 been working in the security space, helping run the Trustworthy Computing Initiative for 156 00:09:56,480 --> 00:09:57,480 quite some time. 157 00:09:57,480 --> 00:10:03,040 And then for the last 10 years or so, building tools and systems that are underneath our 158 00:10:03,040 --> 00:10:06,800 implementations of running the SDL at scale in the company. 159 00:10:06,800 --> 00:10:11,560 So I'll kick it off with, I've got gray hair, what little bit of it is left. 160 00:10:11,560 --> 00:10:14,600 So I remember the original SDL and when it kind of got rolled out. 161 00:10:14,600 --> 00:10:19,800 But for our audience, can you just give us kind of an overview of kind of the SDL, what 162 00:10:19,800 --> 00:10:25,520 it is, what the purpose is, and how people should be using it? 163 00:10:25,520 --> 00:10:26,520 So what is the SDL? 164 00:10:26,520 --> 00:10:27,560 That's a great question. 165 00:10:27,560 --> 00:10:35,120 So the SDL is a process that was invented a long time ago, feels weird to be interviewed 166 00:10:35,120 --> 00:10:40,120 by Mr. Howard, one of the grandfathers of SDL. 167 00:10:40,120 --> 00:10:46,520 Its main aim is to help engineers build secure software by helping everyone find security 168 00:10:46,520 --> 00:10:50,640 issues as early as possible in the lifecycle, removing them. 169 00:10:50,640 --> 00:10:54,840 Or if we can't remove them, reducing the severity of those issues. 170 00:10:54,840 --> 00:11:01,640 What we found as we've been progressing over the years is that it's really, really hard 171 00:11:01,640 --> 00:11:05,320 to do things in the ways that we used to. 172 00:11:05,320 --> 00:11:07,840 We used to have a final security review. 173 00:11:07,840 --> 00:11:13,000 We used to run tools occasionally, but now we run them all the time, always. 174 00:11:13,000 --> 00:11:15,560 And this is where the foundation of continuous SDL comes in. 175 00:11:15,560 --> 00:11:22,800 So we're using the data-driven approach to continuously evaluate everything that happens 176 00:11:22,800 --> 00:11:27,680 within both the engineering pipeline and the source code. 177 00:11:27,680 --> 00:11:32,440 And we use that to make decisions for the benefits of security on a daily basis. 178 00:11:32,440 --> 00:11:33,440 It's funny. 179 00:11:33,440 --> 00:11:40,160 First of all, I'm not sure whether to be thankful or what about being referred to as the grandfather 180 00:11:40,160 --> 00:11:41,160 of SDL. 181 00:11:41,160 --> 00:11:42,960 I'm not sure if I'm being called old there or not. 182 00:11:42,960 --> 00:11:48,200 But anyway, it's interesting though, because if you look at the book that Steve Lipner 183 00:11:48,200 --> 00:11:53,200 and I wrote called The Microsoft Security Development Lifecycle, I still think it's 184 00:11:53,200 --> 00:11:56,440 a useful book, it's a good book, but there's a lot missing. 185 00:11:56,440 --> 00:12:01,600 And to your point, David, one word that's missing in there is cloud. 186 00:12:01,600 --> 00:12:04,640 There is nothing about cloud. 187 00:12:04,640 --> 00:12:10,840 We touch on pipelines a little bit, but certainly there is nothing about cloud scale, cloud 188 00:12:10,840 --> 00:12:17,120 deployment, this constant continuous delivery of software. 189 00:12:17,120 --> 00:12:24,080 And to your point, the SDL needs updating just because of that alone, as more practices 190 00:12:24,080 --> 00:12:25,760 become more agile. 191 00:12:25,760 --> 00:12:30,000 Is that a fair comment? 192 00:12:30,000 --> 00:12:34,840 I think you can think about it as two primary drivers, one internal and one external. 193 00:12:34,840 --> 00:12:38,440 The internal one is just the nature of building software and the kinds of things that we're 194 00:12:38,440 --> 00:12:42,800 building and how we're doing it has just changed radically. 195 00:12:42,800 --> 00:12:47,400 The SDL has been pretty much continuously changing for all this time. 196 00:12:47,400 --> 00:12:50,820 Continuous SDL is just a name for the latest sort of wave of changes. 197 00:12:50,820 --> 00:12:57,680 But if you look at the SDL originally, we were releasing products every two or three 198 00:12:57,680 --> 00:12:59,080 years or something like that. 199 00:12:59,080 --> 00:13:03,760 And the way you can think about tackling security when you're doing that is just completely 200 00:13:03,760 --> 00:13:09,300 different than if you're building large complex services where you're releasing them on practically 201 00:13:09,300 --> 00:13:13,200 a continuous basis every day, maybe multiple times a day. 202 00:13:13,200 --> 00:13:15,480 You just have to tackle things differently. 203 00:13:15,480 --> 00:13:18,880 And I think that's sort of the internal side. 204 00:13:18,880 --> 00:13:22,200 And then I would say the external side is just the nature of the threat landscape and 205 00:13:22,200 --> 00:13:26,440 the attackers and the way they are functioning. 206 00:13:26,440 --> 00:13:29,600 Unless you're asleep, unless you're not paying any attention, you understand that the world 207 00:13:29,600 --> 00:13:31,960 is just under some pretty serious threat. 208 00:13:31,960 --> 00:13:34,320 And we are and our customers are. 209 00:13:34,320 --> 00:13:37,520 And so a lot of what we're doing right now is responding to that. 210 00:13:37,520 --> 00:13:43,720 And the changes for continuous SDL have been underway for a couple of years, but are really 211 00:13:43,720 --> 00:13:49,720 being accelerated as part of a broader initiative, which is Microsoft's response to a lot of 212 00:13:49,720 --> 00:13:54,760 what's going on in the outside world called the Secure Future Initiative, which includes 213 00:13:54,760 --> 00:13:58,560 continuous SDL, but includes a range of other things. 214 00:13:58,560 --> 00:14:02,080 By continuous evaluation, I assume you mean essentially tooling, right? 215 00:14:02,080 --> 00:14:04,560 So static analysis and potentially dynamic analysis. 216 00:14:04,560 --> 00:14:08,960 Can you give some examples of what that might look like and perhaps even what customers, 217 00:14:08,960 --> 00:14:11,040 people listening to this could potentially use as well? 218 00:14:11,040 --> 00:14:15,600 OK, well, I'm happy to start with the continuous evaluation component because that's where 219 00:14:15,600 --> 00:14:17,720 we were. 220 00:14:17,720 --> 00:14:24,760 So the number of things that you want to make sure are true about a piece of software has 221 00:14:24,760 --> 00:14:27,480 grown substantially. 222 00:14:27,480 --> 00:14:29,640 We used to want to make sure there were no buffer overruns. 223 00:14:29,640 --> 00:14:33,160 And now there's 10,000 things we want to make sure are true. 224 00:14:33,160 --> 00:14:37,240 Because as the threat landscape has changed and as the attackers have gotten smarter, 225 00:14:37,240 --> 00:14:40,800 there are just more and more ways that they can get in and more and more ways for us to 226 00:14:40,800 --> 00:14:42,480 keep them out. 227 00:14:42,480 --> 00:14:50,360 And so if you think about how long does it take to go sort of take one pass over a fairly 228 00:14:50,360 --> 00:14:54,680 large complex piece of software and figure out whether you're actually meeting all of 229 00:14:54,680 --> 00:15:00,000 those requirements in the SDL, that's a pretty substantial process. 230 00:15:00,000 --> 00:15:05,560 And it originally, because we only released, as I said earlier, we only released, let's 231 00:15:05,560 --> 00:15:11,520 just say infrequently before the world of cloud, you could take some time during the 232 00:15:11,520 --> 00:15:15,760 tail end of the development cycle of a piece of software and sort of have your security 233 00:15:15,760 --> 00:15:19,600 push and have your security focus and do your evaluation. 234 00:15:19,600 --> 00:15:25,760 And that's just not feasible anymore because if you wait for that, what you find is just 235 00:15:25,760 --> 00:15:28,880 an enormous pile of stuff to do at the end. 236 00:15:28,880 --> 00:15:34,680 And in fact, if you find the problems late, they're way more expensive to fix than if 237 00:15:34,680 --> 00:15:36,240 you can find them early. 238 00:15:36,240 --> 00:15:42,280 So the first major part of continuous SDL is continuous evaluation. 239 00:15:42,280 --> 00:15:43,800 And what that's about is using data. 240 00:15:43,800 --> 00:15:46,080 We'll talk more about the data stuff in a little bit. 241 00:15:46,080 --> 00:15:52,000 But that's about basically doing as much evaluation as you can throughout the entire lifecycle, 242 00:15:52,000 --> 00:15:58,280 the design process, code, build, deployment and test environments, all that kind of stuff, 243 00:15:58,280 --> 00:16:03,440 and being able to examine the security state relative to all of the different things that 244 00:16:03,440 --> 00:16:08,200 we're trying to control and manage in SDL, examining that security state on a continuous 245 00:16:08,200 --> 00:16:14,800 basis and then being able to take action really as early as possible. 246 00:16:14,800 --> 00:16:19,200 Some people call it shift left, catching things upstream. 247 00:16:19,200 --> 00:16:24,680 And it really makes it possible to fix things as early as possible and makes it really feasible 248 00:16:24,680 --> 00:16:28,520 to catch them all or hopefully all. 249 00:16:28,520 --> 00:16:29,960 All right. 250 00:16:29,960 --> 00:16:34,080 So let's get stuck into some of the guts of this thing. 251 00:16:34,080 --> 00:16:39,360 So what are the core elements of continuous SDL? 252 00:16:39,360 --> 00:16:42,920 If each of you likes, want to take one topic and just run with it. 253 00:16:42,920 --> 00:16:43,920 Sure. 254 00:16:43,920 --> 00:16:49,040 Well, I mean, some of the most obvious ones are automated tools that look at the code. 255 00:16:49,040 --> 00:16:54,640 So static analysis and dynamic analysis tools, one of the code QL tool, which I think will 256 00:16:54,640 --> 00:17:00,260 probably talk about a little bit more when we get a little bit later on, that's available 257 00:17:00,260 --> 00:17:05,680 to Microsoft customers we run internally and we've been broadly deploying. 258 00:17:05,680 --> 00:17:10,280 And that's a great tool for doing really sophisticated analysis of the code. 259 00:17:10,280 --> 00:17:18,840 But the kinds of security vulnerabilities that exist in the systems that we're building today 260 00:17:18,840 --> 00:17:23,920 go way beyond just the kinds of things that you can find with a static analysis tool by 261 00:17:23,920 --> 00:17:27,240 looking at just at the code. 262 00:17:27,240 --> 00:17:35,120 There are things that involve, let's say, the use of secrets, being able to find all 263 00:17:35,120 --> 00:17:38,480 the places where you're using secrets and the methods of authentication that you're 264 00:17:38,480 --> 00:17:43,080 using and where and how you're managing those secrets and making sure that you don't have 265 00:17:43,080 --> 00:17:47,200 loose secrets in code or loose secrets in text files in your repositories. 266 00:17:47,200 --> 00:17:53,320 And there are a range of tools, some of which we have available in our commercial products 267 00:17:53,320 --> 00:17:56,200 like Azure DevOps and GitHub and Azure. 268 00:17:56,200 --> 00:18:03,240 In fact, a lot of the automatic scanning stuff that we're talking about that we use internally 269 00:18:03,240 --> 00:18:05,040 is available for our customers there. 270 00:18:05,040 --> 00:18:08,560 And so we sort of monitor the status of all of those things. 271 00:18:08,560 --> 00:18:14,120 Plus we have a range of things that are more specific to the kind of products and services 272 00:18:14,120 --> 00:18:18,980 or maybe the engineering infrastructure and tools and systems that we use internally where 273 00:18:18,980 --> 00:18:20,020 we run automation. 274 00:18:20,020 --> 00:18:26,240 So you can imagine a system that wakes up every day or a couple of times a day and sort 275 00:18:26,240 --> 00:18:31,080 of looks left to right across all the telemetry and the exhaust out of all of the different 276 00:18:31,080 --> 00:18:38,280 systems that are sort of part of the engineering environment where we are building, testing, 277 00:18:38,280 --> 00:18:44,920 and operating the services and then applies a set of digital rules to that stuff in order 278 00:18:44,920 --> 00:18:50,240 to figure out, understand as much as possible the sort of the true security state of the 279 00:18:50,240 --> 00:18:51,240 software. 280 00:18:51,240 --> 00:18:52,240 Okay. 281 00:18:52,240 --> 00:19:01,640 So gents, I'm going to ask maybe because I'm the noob of the people on here about SDL. 282 00:19:01,640 --> 00:19:06,320 Of course I know what it is, but I'm definitely not a grandfather of SDL. 283 00:19:06,320 --> 00:19:08,120 That's sorry, Michael. 284 00:19:08,120 --> 00:19:12,160 But why are we updating the SDL now? 285 00:19:12,160 --> 00:19:16,640 Because of course it's been around for a long time, but what's driving the update right 286 00:19:16,640 --> 00:19:17,640 now? 287 00:19:17,640 --> 00:19:19,540 Is there any particular reason? 288 00:19:19,540 --> 00:19:27,960 So I think that's one of the big innovations that we've made if we can claim it as an innovation. 289 00:19:27,960 --> 00:19:35,160 So similar to what we see outside from regulators and governments and the cyber EO, there's 290 00:19:35,160 --> 00:19:44,000 more and more organizations asking for transparency, transparency into what you do, transparency 291 00:19:44,000 --> 00:19:49,540 in the tools you use, transparency into the things that you find. 292 00:19:49,540 --> 00:19:52,040 But similarly, we see the same requests inside. 293 00:19:52,040 --> 00:19:54,600 It's just through a different pivot, through a different eye. 294 00:19:54,600 --> 00:20:00,080 So if we are going to run a tool and we're going to find issues and ask an engineer to 295 00:20:00,080 --> 00:20:06,080 do a repair if necessary, they want to know why. 296 00:20:06,080 --> 00:20:10,920 They want to know what tool was run, when it was run, what particular issues was found, 297 00:20:10,920 --> 00:20:13,040 why was it important? 298 00:20:13,040 --> 00:20:19,080 And so pulling all this information together and being able to say on this day this tool 299 00:20:19,080 --> 00:20:22,880 was run, these issues were found, or none of these issues were found, but all these 300 00:20:22,880 --> 00:20:27,480 rules were tried is a really, really great way to actually bridge the gap internally 301 00:20:27,480 --> 00:20:32,240 for transparency, letting the engineer know why we're asking them to do work. 302 00:20:32,240 --> 00:20:39,720 But also conversely, when we work with auditors and other regulators to say, hey, look, no, 303 00:20:39,720 --> 00:20:44,760 we ran this tool on this day at this moment in time with all these rules and we found 304 00:20:44,760 --> 00:20:45,760 nothing. 305 00:20:45,760 --> 00:20:53,400 And it's a great way to build a traceable evidence path, but also provide transparency 306 00:20:53,400 --> 00:20:56,800 into our processes. 307 00:20:56,800 --> 00:21:00,440 And this is going to be ever so important as we move forward. 308 00:21:00,440 --> 00:21:04,320 You talked about the scale and the speed of deployment in the cloud. 309 00:21:04,320 --> 00:21:10,400 How can any audit that you do in that environment is a point in time? 310 00:21:10,400 --> 00:21:13,440 It was all the minute you've completed it. 311 00:21:13,440 --> 00:21:18,000 And so being able to provide this level of evidence will really go a long way. 312 00:21:18,000 --> 00:21:24,600 There's no way that the, I think you mentioned one of our dear friends before, Mike Steven, 313 00:21:24,600 --> 00:21:31,080 if I would say, the industrial complex for audits and review, there's no way that they 314 00:21:31,080 --> 00:21:32,080 can keep up with this. 315 00:21:32,080 --> 00:21:38,840 No, there's no way that a physical audit at a point in time is valid for other than 316 00:21:38,840 --> 00:21:39,840 that point in time. 317 00:21:39,840 --> 00:21:45,680 But what we're building here is a way to be able to measure things more immediately, 318 00:21:45,680 --> 00:21:47,280 take action more immediately. 319 00:21:47,280 --> 00:21:51,600 And I think it's the way for future compliance. 320 00:21:51,600 --> 00:21:59,040 So you bring up an interesting point there about transparent and traceable evidence. 321 00:21:59,040 --> 00:22:01,040 What does that look like? 322 00:22:01,040 --> 00:22:02,640 What could customers do as well? 323 00:22:02,640 --> 00:22:09,200 Let's say there's a requirement to run static analysis tools to find specific kinds of vulnerabilities. 324 00:22:09,200 --> 00:22:15,520 What do you provide that shows that you did this and these issues were found and these 325 00:22:15,520 --> 00:22:16,520 issues were rectified? 326 00:22:16,520 --> 00:22:18,600 What does that look like? 327 00:22:18,600 --> 00:22:24,520 In our system, and so David's the engineer here, and so he's built a wonderful system. 328 00:22:24,520 --> 00:22:26,880 What that looks like if we pick on, say, CodeQL. 329 00:22:26,880 --> 00:22:32,200 So across Microsoft, there's thousands of products used and tens of thousands of repositories 330 00:22:32,200 --> 00:22:35,080 with different languages in each repository. 331 00:22:35,080 --> 00:22:40,280 The way that we've implemented CodeQL is that we capture all that information, all the scanned 332 00:22:40,280 --> 00:22:46,660 information centrally, and therefore we can measure, was a particular language in a particular 333 00:22:46,660 --> 00:22:52,320 repo scanned, and we also have the catalog of rules that were scanned for. 334 00:22:52,320 --> 00:22:58,120 And so from an external perspective, we know that at this point in time, all the languages 335 00:22:58,120 --> 00:23:03,760 in this, and we put this together in a package, and maybe David could speak more to this. 336 00:23:03,760 --> 00:23:10,120 So I, for instance, I know that 10 repositories of certain language types was scanned on this 337 00:23:10,120 --> 00:23:13,440 day using this rule set and nothing was found. 338 00:23:13,440 --> 00:23:17,160 So that's really good for outside. 339 00:23:17,160 --> 00:23:23,240 Inside, you know, inside of Microsoft, if an issue is found, it's the same for the deal. 340 00:23:23,240 --> 00:23:27,320 We know the evidence that gets provided to an engineer in that case would just be the 341 00:23:27,320 --> 00:23:29,020 issue that gets found. 342 00:23:29,020 --> 00:23:34,720 They would be given actionable information, including potential how to fix the guidance 343 00:23:34,720 --> 00:23:41,560 that we have, and David's working on some innovation around here, is to lead an engineer 344 00:23:41,560 --> 00:23:44,800 down the right path to do things and to do things immediately. 345 00:23:44,800 --> 00:23:50,120 The more we can give them, the more precise we can give them, that we'll actually go, 346 00:23:50,120 --> 00:23:55,220 in our solution, take them straight down to the line of code that needs to be fixed and 347 00:23:55,220 --> 00:23:57,960 suggest a fix. 348 00:23:57,960 --> 00:24:02,640 And in this case, we've captured the fact that there was an issue. 349 00:24:02,640 --> 00:24:08,320 The solution that we built for CodeQL, the issue remains with the code until we get a 350 00:24:08,320 --> 00:24:13,760 evidence, a new update, a new scan, that the code has been fixed and therefore the issue 351 00:24:13,760 --> 00:24:14,760 goes away. 352 00:24:14,760 --> 00:24:18,160 The new evidence pointer doesn't include the issue. 353 00:24:18,160 --> 00:24:23,720 And that's a real benefit for anybody in security assurance because the issue travels with the 354 00:24:23,720 --> 00:24:28,040 code or ideally the code gets fixed and the issue doesn't travel with it. 355 00:24:28,040 --> 00:24:33,640 All too often in old school SDL, an issue would be tracked as a security bug. 356 00:24:33,640 --> 00:24:38,960 It becomes disconnected from the code and trying to keep all those things in sync in 357 00:24:38,960 --> 00:24:43,560 a world of fastly moving software development is nigh on impossible. 358 00:24:43,560 --> 00:24:48,800 And so I think the way that we capture that information and the way that the information 359 00:24:48,800 --> 00:24:55,800 or rather the way that a issue that's been discovered only goes away once it's been repaired 360 00:24:55,800 --> 00:24:58,720 is a big step forward. 361 00:24:58,720 --> 00:25:03,720 I think the short version of my answer to your question, Michael, is you actually have 362 00:25:03,720 --> 00:25:10,120 to design, keeping the evidence in a connected way, you have to design that into your system 363 00:25:10,120 --> 00:25:11,380 on purpose. 364 00:25:11,380 --> 00:25:15,280 So obviously inside of Microsoft, we use a lot of the same tools and systems that are 365 00:25:15,280 --> 00:25:19,140 used outside by a lot of our customers. 366 00:25:19,140 --> 00:25:23,240 But we also have special stuff inside just like everybody does and how they've set their 367 00:25:23,240 --> 00:25:26,080 own things up and custom tools and stuff. 368 00:25:26,080 --> 00:25:31,960 And the systems that Tony is talking about, the reason that we have this transparent and 369 00:25:31,960 --> 00:25:36,600 traceable evidence element of continuous SDL is because it's literally designed in. 370 00:25:36,600 --> 00:25:42,120 So starting right with the SDL, the SDL is comprised of a set of requirements. 371 00:25:42,120 --> 00:25:44,720 Those requirements have identities. 372 00:25:44,720 --> 00:25:49,800 When we perform the data-driven evaluation to figure out whether a particular product 373 00:25:49,800 --> 00:25:56,040 or service is meeting each of those requirements, we record a record that says, this particular 374 00:25:56,040 --> 00:26:01,400 product or service with this identity met this requirement or didn't meet this requirement. 375 00:26:01,400 --> 00:26:02,960 And then there's a list of evidence pointers. 376 00:26:02,960 --> 00:26:07,280 And all of that's in a data structure that is stored and persisted on purpose. 377 00:26:07,280 --> 00:26:11,840 And those pointers to the related evidence point possibly to other claims of conformance 378 00:26:11,840 --> 00:26:12,840 or non-conformance. 379 00:26:12,840 --> 00:26:16,560 And I mean, you literally have to just design a system that's going to keep track of all 380 00:26:16,560 --> 00:26:17,600 of that data. 381 00:26:17,600 --> 00:26:20,680 So it's built in, but not by accident. 382 00:26:20,680 --> 00:26:27,120 So broadly speaking, I think that what I would say is keep that evidence. 383 00:26:27,120 --> 00:26:33,240 If you're a customer building systems and you want to have confidence that they're secure, 384 00:26:33,240 --> 00:26:37,120 just like everybody understands, sometimes when you discover something's wrong, you want 385 00:26:37,120 --> 00:26:40,520 to be able to go back and look and figure out what happened in the past. 386 00:26:40,520 --> 00:26:43,560 That's the same reason we all keep audit logs around and stuff like that. 387 00:26:43,560 --> 00:26:46,560 Keep that evidence around so that you can go back and look at it. 388 00:26:46,560 --> 00:26:53,920 We've made a lot of progress and pretty excited about systematically, in a heterogeneous way, 389 00:26:53,920 --> 00:26:55,600 being able to glue all that stuff together. 390 00:26:55,600 --> 00:26:59,840 But the core idea is you got to keep it and you got to know where it is. 391 00:26:59,840 --> 00:27:05,800 On the next topic, so you mentioned before, David, about data-driven methodology. 392 00:27:05,800 --> 00:27:10,240 So why don't you give us some insight into what that means? 393 00:27:10,240 --> 00:27:15,080 If you think about how most, let's just say broadly speaking, auditing and compliance 394 00:27:15,080 --> 00:27:19,680 work happens, somebody says, okay, well, the standard says you have to do these 10 things. 395 00:27:19,680 --> 00:27:24,080 And then an auditor comes in and they've got a clipboard with a little checklist of 10 396 00:27:24,080 --> 00:27:25,080 things. 397 00:27:25,080 --> 00:27:27,580 And they want to know whether those 10 things got done. 398 00:27:27,580 --> 00:27:32,000 So they go ask some people and they say, did these 10 things get done? 399 00:27:32,000 --> 00:27:38,520 And somewhere, ideally, you would find a document that's a record of those 10 things being done. 400 00:27:38,520 --> 00:27:41,960 So that's a broad concept. 401 00:27:41,960 --> 00:27:48,840 For the SDL, a large portion of our original methodologies were based on what we often 402 00:27:48,840 --> 00:27:56,160 call manual attestation, which is you go ask a developer on the team, hey, for example, 403 00:27:56,160 --> 00:28:01,080 are you using a particular deprecated form of encryption that we no longer think is a 404 00:28:01,080 --> 00:28:03,160 good idea to use? 405 00:28:03,160 --> 00:28:11,060 And our SDL compliance program at scale across the company would rely on that engineer answering 406 00:28:11,060 --> 00:28:12,200 that question correctly. 407 00:28:12,200 --> 00:28:17,120 What we, again, when I said think of it as manual attestation. 408 00:28:17,120 --> 00:28:22,280 The challenge is that the landscape of things that you need to know about your systems now 409 00:28:22,280 --> 00:28:27,680 has become so large that actually it's really not a reliable way for people to do that. 410 00:28:27,680 --> 00:28:30,880 The code, I don't remember how the code I wrote three years ago works. 411 00:28:30,880 --> 00:28:34,840 I can barely remember how the code I wrote six months ago works. 412 00:28:34,840 --> 00:28:38,680 And so the truth comes from data. 413 00:28:38,680 --> 00:28:40,760 The truth comes from looking at logs. 414 00:28:40,760 --> 00:28:42,680 The truth comes from looking at the code. 415 00:28:42,680 --> 00:28:49,280 The truth comes from looking at databases that are records of things that actually happened. 416 00:28:49,280 --> 00:28:53,720 And so that's really what this data-driven methodology is about, is about taking all 417 00:28:53,720 --> 00:28:58,000 the SDL requirements and moving as much as we can away from anything that's based on 418 00:28:58,000 --> 00:29:04,640 manual attestation to actually evaluating data that we know tells the truth. 419 00:29:04,640 --> 00:29:10,160 If you want to know whether every server in a data center associated with a particular 420 00:29:10,160 --> 00:29:17,240 service is keeping up with patching, you don't want to ask a human being that, even if they're 421 00:29:17,240 --> 00:29:21,000 responsible for making sure that that happens, because people can make mistakes. 422 00:29:21,000 --> 00:29:23,000 This landscape is very complicated. 423 00:29:23,000 --> 00:29:27,920 But if you interrogate the scan logs from all of those servers, you will know the truth. 424 00:29:27,920 --> 00:29:34,520 So the data-driven thing is really all about having the evaluation process, the compliance 425 00:29:34,520 --> 00:29:38,840 engine at the middle of all this stuff that's doing the continuous evaluation we were talking 426 00:29:38,840 --> 00:29:43,600 about earlier, using as much as possible using data triggers, looking at the issues that 427 00:29:43,600 --> 00:29:50,480 are found during static analysis with CodeQL, looking at configuration of people's Azure 428 00:29:50,480 --> 00:29:54,640 DevOps instances to figure out whether, yes, actually, every repository is configured to 429 00:29:54,640 --> 00:29:59,140 require two full-time employees to sign off on every pull request. 430 00:29:59,140 --> 00:30:02,800 So each of these things, you can look at the data and find out the truth. 431 00:30:02,800 --> 00:30:05,640 And that's what the data-driven methodology piece is about. 432 00:30:05,640 --> 00:30:08,960 And I suppose it just gives you better insights into whether you're making progress on that, 433 00:30:08,960 --> 00:30:09,960 right? 434 00:30:09,960 --> 00:30:11,640 I mean, if the numbers are going up, that's probably not good. 435 00:30:11,640 --> 00:30:14,960 But if the numbers are going down, then perhaps that's a good thing. 436 00:30:14,960 --> 00:30:15,960 Perhaps we're making progress. 437 00:30:15,960 --> 00:30:16,960 Yeah. 438 00:30:16,960 --> 00:30:18,800 Well, I like to see the numbers go down to zero. 439 00:30:18,800 --> 00:30:21,640 But of course, sometimes you need a glide slope to get there. 440 00:30:21,640 --> 00:30:28,600 I think the other thing is that, going back to the point about evidence and transparency, 441 00:30:28,600 --> 00:30:33,480 if I have a piece of evidence that I've recorded that the reason that we decided that somebody 442 00:30:33,480 --> 00:30:41,760 didn't have any of a certain kind of vulnerability was because somebody said they didn't, that's 443 00:30:41,760 --> 00:30:42,760 evidence. 444 00:30:42,760 --> 00:30:43,960 But it's not very strong evidence. 445 00:30:43,960 --> 00:30:49,520 Whereas, if I can say, well, here were the static analysis rules that we ran with CodeQL 446 00:30:49,520 --> 00:30:50,520 against the source code. 447 00:30:50,520 --> 00:30:53,320 And it was this version of the commits in this repository. 448 00:30:53,320 --> 00:30:56,240 And really, really detailed. 449 00:30:56,240 --> 00:30:58,760 You know what actually happened. 450 00:30:58,760 --> 00:31:00,800 That's stronger evidence. 451 00:31:00,800 --> 00:31:05,880 And so increasingly, this being data driven, it enables these different pieces are all 452 00:31:05,880 --> 00:31:06,880 sort of tied together. 453 00:31:06,880 --> 00:31:12,680 This enables the transparent evidence collection and organization as well. 454 00:31:12,680 --> 00:31:21,260 I think if I was going to add one additional thing, perhaps, would just be that it enables 455 00:31:21,260 --> 00:31:24,360 us also to see where we can still make improvements. 456 00:31:24,360 --> 00:31:27,720 So to your point, it might go up. 457 00:31:27,720 --> 00:31:29,320 You introduce a new tool. 458 00:31:29,320 --> 00:31:31,120 You introduce a new rule. 459 00:31:31,120 --> 00:31:34,680 You get to immediately see that across the entirety of the estate because we're taking 460 00:31:34,680 --> 00:31:35,880 the data driven approach. 461 00:31:35,880 --> 00:31:37,620 And it's there. 462 00:31:37,620 --> 00:31:43,800 And so we can immediately tell from our implementation what the cost is to Microsoft, what the cost 463 00:31:43,800 --> 00:31:50,080 is to an individual engineering group, and help them come up with a plan to address the 464 00:31:50,080 --> 00:31:54,100 issues if they're indeed our issues, if we bring a new ruling. 465 00:31:54,100 --> 00:31:58,000 From time to time, we have a incident. 466 00:31:58,000 --> 00:32:03,360 And in some cases, it was maybe because we didn't have a correct rule, or it might even 467 00:32:03,360 --> 00:32:06,080 be a new attack pattern that we're not aware of. 468 00:32:06,080 --> 00:32:12,400 And so when we add that to our tooling, whether that's CodeQL or another tool, the fact that 469 00:32:12,400 --> 00:32:17,740 we can take a broad data driven view across the entirety of the Microsoft estate and see 470 00:32:17,740 --> 00:32:22,760 what the impact that has before we take action is a benefit to everyone. 471 00:32:22,760 --> 00:32:24,000 And that's an important point, right? 472 00:32:24,000 --> 00:32:30,280 The fact that this is continuous is as we see new vulnerability classes or new variants 473 00:32:30,280 --> 00:32:33,720 of existing vulnerability classes, we can adapt quickly, right? 474 00:32:33,720 --> 00:32:38,640 We're not like we're waiting two years to update some tools or some education or whatever, 475 00:32:38,640 --> 00:32:39,640 right? 476 00:32:39,640 --> 00:32:43,920 This whole thing is designed to be updated rapidly as new threats evolve. 477 00:32:43,920 --> 00:32:51,040 It was always the case that the SDL team were tightly connected to the MSRC team for the 478 00:32:51,040 --> 00:32:57,020 Microsoft Security Response Center team for learning about new variants of issues. 479 00:32:57,020 --> 00:32:59,880 But now we're even more tightly integrated with those things. 480 00:32:59,880 --> 00:33:04,380 And from a, the tool that's closest to my heart is the CodeQL tool. 481 00:33:04,380 --> 00:33:11,760 We can literally have a new rule in place and scan it for a new incident and a new variant. 482 00:33:11,760 --> 00:33:16,840 We can have a new CodeQL rule in place in the afternoon, say if we find something in 483 00:33:16,840 --> 00:33:21,120 the morning and we can have scanned all of Microsoft by the following day and have the 484 00:33:21,120 --> 00:33:23,080 results. 485 00:33:23,080 --> 00:33:27,160 It's pretty impressive feedback loop in terms of just how fast we can respond these days. 486 00:33:27,160 --> 00:33:30,440 So you're on the CodeQL topic and I really don't want to spend too much time on CodeQL 487 00:33:30,440 --> 00:33:34,520 right now, but one of the things I love about CodeQL is the fact that it is, in the overall 488 00:33:34,520 --> 00:33:37,760 scheme of things, relatively easy to write new rules. 489 00:33:37,760 --> 00:33:38,760 That just blows me away. 490 00:33:38,760 --> 00:33:42,480 In fact, I don't even go as far as to say it democratizes writing rules because you 491 00:33:42,480 --> 00:33:49,800 don't need to go to some person who will quite happily relieve you of $100,000 to write some 492 00:33:49,800 --> 00:33:53,920 new rule for some bespoke static analysis tool. 493 00:33:53,920 --> 00:33:57,320 There's something you can do yourself if you're using CodeQL. 494 00:33:57,320 --> 00:34:02,680 I'm not saying that it is really, really easy, but it's certainly a heck of a lot easier 495 00:34:02,680 --> 00:34:05,120 than writing your own compiler in the first place. 496 00:34:05,120 --> 00:34:07,040 I've written CodeQL rules. 497 00:34:07,040 --> 00:34:11,800 I'm not going to say they're awesome, but there's things that I've seen and I've written 498 00:34:11,800 --> 00:34:17,760 simple CodeQL queries to help me narrow down where vulnerabilities may exist. 499 00:34:17,760 --> 00:34:22,160 So I'm a huge fan of CodeQL and I think we should at some point get someone probably 500 00:34:22,160 --> 00:34:26,920 from the CodeQL team on the podcast to really go through it in detail because this isn't 501 00:34:26,920 --> 00:34:29,160 a tool that's just Microsoft only. 502 00:34:29,160 --> 00:34:33,960 This is available on GitHub and you can run it on repos that you own. 503 00:34:33,960 --> 00:34:40,560 Yeah, this is a really great tool, which kind of is a nice segue actually into the next 504 00:34:40,560 --> 00:34:42,000 section, which is modernized practices. 505 00:34:42,000 --> 00:34:45,800 David, do you want to give us the lowdown on modernized practices? 506 00:34:45,800 --> 00:34:49,760 Actually, I'm going to let Tony take that one because it's much more in his area. 507 00:34:49,760 --> 00:34:53,920 It struck me, you know, Sarah's question at the very start was, you know, why are you 508 00:34:53,920 --> 00:34:55,280 just updating the SDL now? 509 00:34:55,280 --> 00:34:57,240 And the answer is it's not just now. 510 00:34:57,240 --> 00:35:00,280 We've been updating the SDL for the longest time. 511 00:35:00,280 --> 00:35:02,000 It gets updated all the time. 512 00:35:02,000 --> 00:35:07,880 We've just been talking about how incidents, new classes of issues, variants of issues, 513 00:35:07,880 --> 00:35:10,320 how they affect the requirements and tooling. 514 00:35:10,320 --> 00:35:13,480 So we're updating all things all the time. 515 00:35:13,480 --> 00:35:17,520 The requirements that we have are constantly being updated. 516 00:35:17,520 --> 00:35:21,960 But we see things happening in the ecosystem at large. 517 00:35:21,960 --> 00:35:28,000 And so if anyone's taken time to read the white paper, they'll know that we've updated 518 00:35:28,000 --> 00:35:29,720 six requirements last year. 519 00:35:29,720 --> 00:35:32,180 I think, well, sorry, we added six requirements last year. 520 00:35:32,180 --> 00:35:34,160 So what was all that about? 521 00:35:34,160 --> 00:35:40,880 So some of it was around issues that we just needed to pull out that were already embedded 522 00:35:40,880 --> 00:35:41,880 within a requirement. 523 00:35:41,880 --> 00:35:46,360 But you wanted to pull it out to bring it into focus for the rest for all of Microsoft 524 00:35:46,360 --> 00:35:50,040 so we can really focus just in on one issue. 525 00:35:50,040 --> 00:35:52,360 But the other issues around engineering system. 526 00:35:52,360 --> 00:35:58,480 So we've seen over the years and recently that adversaries also don't just go after 527 00:35:58,480 --> 00:36:00,960 the code, they go after the infrastructure the code is built on. 528 00:36:00,960 --> 00:36:07,480 And so we spent a lot of time looking at what we could do in the environment to help improve 529 00:36:07,480 --> 00:36:10,760 the security of the systems that we engineer on. 530 00:36:10,760 --> 00:36:14,000 And so that was one of the things that we do. 531 00:36:14,000 --> 00:36:16,200 The SDL now is all encompassing. 532 00:36:16,200 --> 00:36:18,400 It's the software that gets created. 533 00:36:18,400 --> 00:36:21,600 It's the operational environment that the software is released into. 534 00:36:21,600 --> 00:36:26,560 And it's also the engineering systems that the software is built from. 535 00:36:26,560 --> 00:36:31,200 But we've also constantly looking at what's happening in terms of Microsoft, where the 536 00:36:31,200 --> 00:36:32,480 innovation is going, what we need to do. 537 00:36:32,480 --> 00:36:36,160 And of course, AI is on the tip of everyone's tongue right now. 538 00:36:36,160 --> 00:36:37,800 And so we're deeply embedded. 539 00:36:37,800 --> 00:36:44,320 People on my team are embedded in the AI group, the artificial generative intelligence and 540 00:36:44,320 --> 00:36:46,400 security team inside of Microsoft. 541 00:36:46,400 --> 00:36:51,120 And so as a team, it's being pulled together looking at all the potential threats that 542 00:36:51,120 --> 00:36:54,960 come along and vulnerabilities that come along with AI. 543 00:36:54,960 --> 00:37:00,240 And we're planning about them together as a group and bringing that back into the SDL. 544 00:37:00,240 --> 00:37:06,080 And so we've made updates both in terms of how we pen test, how we go about looking and 545 00:37:06,080 --> 00:37:11,360 finding practically vulnerabilities in new innovation around there, but also things such 546 00:37:11,360 --> 00:37:13,480 as threat modeling. 547 00:37:13,480 --> 00:37:16,640 How do you effectively threat model AI systems? 548 00:37:16,640 --> 00:37:22,760 So we continually look across everything that we do and always think about how we can improve 549 00:37:22,760 --> 00:37:25,160 all our requirements based on what's changing. 550 00:37:25,160 --> 00:37:30,680 Okay, gents, so I know that you've been prepped for this, but something that we always ask 551 00:37:30,680 --> 00:37:36,320 our guests at the end of the podcast episode is for your final thoughts, something that 552 00:37:36,320 --> 00:37:38,600 you'd like to leave our listeners with. 553 00:37:38,600 --> 00:37:42,960 Well, I'll just toss in, this is David, I'll toss in my thought, which is really in some 554 00:37:42,960 --> 00:37:48,260 ways just a recapitulation of what we talked about earlier, which is that the nature of 555 00:37:48,260 --> 00:37:52,880 building software is changing internally and the threats are constantly changing around 556 00:37:52,880 --> 00:37:53,880 us. 557 00:37:53,880 --> 00:37:59,320 And the four areas in continuous SDL that we're driving at Microsoft, the continuous 558 00:37:59,320 --> 00:38:06,800 evaluation part, being data driven, having evidence and transparency and continually 559 00:38:06,800 --> 00:38:10,360 modernizing practices, those are absolutely essential for us. 560 00:38:10,360 --> 00:38:15,920 And I think pretty much no company and no set of software really lives as an island 561 00:38:15,920 --> 00:38:16,920 anymore. 562 00:38:16,920 --> 00:38:23,160 So all of our customers and all of our partners around the world who are building systems 563 00:38:23,160 --> 00:38:26,680 to some degree or another have to actually be thinking about all these things. 564 00:38:26,680 --> 00:38:31,540 So some of these lessons about continuous stuff, data driven and so forth, I would recommend 565 00:38:31,540 --> 00:38:32,540 you internalize. 566 00:38:32,540 --> 00:38:35,480 You can read more about the stuff that we talked about here today. 567 00:38:35,480 --> 00:38:42,200 I think the white paper that we've been chatting about today is linked in the podcast web page. 568 00:38:42,200 --> 00:38:45,280 All right, so let's bring this episode to an end. 569 00:38:45,280 --> 00:38:48,520 Gentlemen, thank you so much for joining us this week. 570 00:38:48,520 --> 00:38:55,840 It's just fantastic seeing SDL alive and kicking and being updated, especially in light of 571 00:38:55,840 --> 00:39:01,360 the new threat landscape, new development tools, new attack techniques, new everything. 572 00:39:01,360 --> 00:39:03,760 So it's really good to see. 573 00:39:03,760 --> 00:39:05,520 So again, thank you so much for joining us. 574 00:39:05,520 --> 00:39:09,920 And to all our listeners out there, we hope you found this episode of use. 575 00:39:09,920 --> 00:39:16,920 Stay safe and we'll see you next time.