WEBVTT 00:00:03.750 --> 00:00:06.230 Welcome to the Azure Security Podcast, where 00:00:06.230 --> 00:00:08.769 we discuss topics relating to security, privacy, 00:00:09.050 --> 00:00:11.470 reliability, and compliance on the Microsoft 00:00:11.470 --> 00:00:15.869 Cloud Platform. Hey everybody, welcome to episode 00:00:15.869 --> 00:00:18.530 131. This week it's myself, Michael, with Mark 00:00:18.530 --> 00:00:21.530 and Sarah. And our guest this week is Tae -Soo 00:00:21.530 --> 00:00:23.670 Kim, who's here to talk to us about M -Dash. 00:00:23.989 --> 00:00:26.429 If any of you watched Microsoft Build, you would 00:00:26.429 --> 00:00:28.350 have seen Sarah actually at the keynote with 00:00:28.350 --> 00:00:31.899 Satya, demonstrating M -Dash. But before we get 00:00:31.899 --> 00:00:33.899 to our guest, let's take a little lap around 00:00:33.899 --> 00:00:36.539 the news. I'll kick things off. Funnily enough, 00:00:36.700 --> 00:00:38.700 all my news this week is post -quantum crypto. 00:00:38.960 --> 00:00:43.100 What a surprise. So first of all, unless you've 00:00:43.100 --> 00:00:44.479 been living under a rock, there was actually 00:00:44.479 --> 00:00:47.280 a blog post that came out last week by the Azure 00:00:47.280 --> 00:00:50.240 CTO, Mark Rasinovich, called Accelerating the 00:00:50.240 --> 00:00:54.259 Quantum Safe Timeline. Basically, Microsoft and 00:00:54.259 --> 00:00:56.920 others in the industry, we have moved up the 00:00:56.920 --> 00:01:02.460 date for air quotes Q Day. to 2029, which has 00:01:02.460 --> 00:01:04.879 been a big change since 2040, which was like 00:01:04.879 --> 00:01:07.200 the original kind of Q day back in the day. But 00:01:07.200 --> 00:01:10.079 yeah, we're up to 2029 now. Perhaps that may 00:01:10.079 --> 00:01:13.569 accelerate. Further, I don't know, but 2029 it 00:01:13.569 --> 00:01:16.829 is. On that topic, there was also a executive 00:01:16.829 --> 00:01:20.250 order signed by the White House requiring key 00:01:20.250 --> 00:01:24.189 encapsulation by 2030 to be quantum secure and 00:01:24.189 --> 00:01:27.450 digital signatures to be quantum secure by 2031. 00:01:27.750 --> 00:01:30.170 So again, we've got some really interesting dates 00:01:30.170 --> 00:01:32.930 that are all sort of coalescing around that 2029, 00:01:33.069 --> 00:01:38.879 2031 timeframe. Next one is I wrote a blog post. 00:01:39.120 --> 00:01:43.140 The first of many, I hope. It's a technical blog 00:01:43.140 --> 00:01:46.540 on post -quantum crypto. And the first one out 00:01:46.540 --> 00:01:49.799 the gate was on crypto agility. One of the problems 00:01:49.799 --> 00:01:52.000 with crypto agility is every person and their 00:01:52.000 --> 00:01:54.659 dog says, thou shalt do crypto agility. And everyone 00:01:54.659 --> 00:01:56.739 leaves out one little tiny little part of it. 00:01:56.760 --> 00:02:00.840 And that is how. So this particular blog post 00:02:00.840 --> 00:02:03.599 actually goes through examples of how Microsoft 00:02:03.599 --> 00:02:06.040 Office does it with the OpenOffice XML file format. 00:02:06.400 --> 00:02:10.419 Also how Azure SQL and SQL Server do always encrypted. 00:02:10.759 --> 00:02:14.000 And also how Azure Storage does client -side 00:02:14.000 --> 00:02:16.780 crypto and how they all maintain crypto agility. 00:02:17.020 --> 00:02:18.520 So everything is derived from that. There's lots 00:02:18.520 --> 00:02:20.759 of code in there as well, as well as anti -patterns. 00:02:21.280 --> 00:02:25.900 And the last one is a collection of links in 00:02:25.900 --> 00:02:29.879 the show notes. Active Directory Certificate 00:02:29.879 --> 00:02:33.259 Services, which, by the way, I worked on back 00:02:33.259 --> 00:02:35.419 in the day. I was actually interviewed to be 00:02:35.419 --> 00:02:38.039 the original PM for this little product called 00:02:38.039 --> 00:02:39.900 Microsoft Certificate Server back in the day. 00:02:40.020 --> 00:02:44.159 I ended up working on IIS instead. Anyway, so 00:02:44.159 --> 00:02:46.680 Active Directory Certificate Services now actually 00:02:46.680 --> 00:02:49.960 has support for MLDSA. So if you're not familiar, 00:02:50.099 --> 00:02:55.449 MLDSA is the quantum resistant. digital signature 00:02:55.449 --> 00:02:59.469 algorithm that has been blessed by NIST and Azure 00:02:59.469 --> 00:03:02.050 Directory Certificate Services supports it out 00:03:02.050 --> 00:03:04.650 of the box now. And that is GA. It is a version 00:03:04.650 --> 00:03:07.530 that you can run today. So fantastic to see. 00:03:07.689 --> 00:03:09.409 I've been experimenting with it and kicking the 00:03:09.409 --> 00:03:12.909 tires and it works really, really nicely. Certainly 00:03:12.909 --> 00:03:16.250 brought back a lot of memories from when I first 00:03:16.250 --> 00:03:18.250 worked on it back in the day. All right, Mark, 00:03:18.330 --> 00:03:20.780 what do you got? Thanks. Yeah, that's definitely 00:03:20.780 --> 00:03:22.319 bringing back some memories because I was on 00:03:22.319 --> 00:03:24.080 the support team helping support certificate 00:03:24.080 --> 00:03:30.719 services back in the day. So I just got back 00:03:30.719 --> 00:03:34.990 from a long vacation. Most of my news is just 00:03:34.990 --> 00:03:37.090 some stuff that I launched just before I left. 00:03:37.530 --> 00:03:39.849 There is now a Zero Trust Playbook site kind 00:03:39.849 --> 00:03:42.490 of describing the Zero Trust Playbook and all 00:03:42.490 --> 00:03:44.889 that and the contents of it and how it's working 00:03:44.889 --> 00:03:48.830 and how we're approaching the new security operations 00:03:48.830 --> 00:03:51.629 playbook as well is on there. And then I also 00:03:51.629 --> 00:03:54.949 launched a YouTube channel. And so I'm going 00:03:54.949 --> 00:03:58.810 to be kind of showing my ugly face as I talk 00:03:58.810 --> 00:04:03.780 about things on YouTube. So look for more to 00:04:03.780 --> 00:04:06.659 come. I just ordered up some new cameras and 00:04:06.659 --> 00:04:09.759 lights to do my best to make it more pleasant 00:04:09.759 --> 00:04:13.879 for you all. So that's my news for now. Okay, 00:04:13.939 --> 00:04:17.199 so now we've done the news, we'll move on to 00:04:17.199 --> 00:04:22.500 our guest, Teisu, who is our VP of Security Research. 00:04:23.500 --> 00:04:28.779 Welcome, Teisu. Now, I know who you are because... 00:04:29.469 --> 00:04:32.230 I've been annoying you on Teams for the last 00:04:32.230 --> 00:04:35.569 couple of months about various things. But would 00:04:35.569 --> 00:04:38.509 you like to introduce yourself to our listeners? 00:04:39.110 --> 00:04:41.769 Yeah, thank you for having me. My name is Taesu 00:04:41.769 --> 00:04:45.529 Kim. I have multiple hands. I'm VP at Microsoft 00:04:45.529 --> 00:04:49.689 and also I'm professor at Georgia Tech. I actually 00:04:49.689 --> 00:04:53.290 recently joined Microsoft, maybe January, I believe. 00:04:53.629 --> 00:04:57.259 And today's my... half year anniversary at Microsoft. 00:04:58.199 --> 00:05:01.319 So we've been working very hard to launch M -Dash 00:05:01.319 --> 00:05:05.779 project. Right. Yes. So there we can launch straight 00:05:05.779 --> 00:05:08.639 into it. Congratulations on six months at Microsoft. 00:05:09.199 --> 00:05:12.899 And also, I guess some of our listeners will 00:05:12.899 --> 00:05:15.300 know, but let's go back to the beginning. What 00:05:15.300 --> 00:05:19.379 is M -Dash for anyone who has not heard of it 00:05:19.379 --> 00:05:23.779 and been living under a rock? So M -Dash. I recall 00:05:23.779 --> 00:05:27.740 it stands for multi -modal agent scanning tool, 00:05:27.959 --> 00:05:31.519 I believe. You can come up with a letter between, 00:05:31.800 --> 00:05:34.959 you can make an em dash. But the idea there is 00:05:34.959 --> 00:05:37.860 that by leveraging AI, particularly large language 00:05:37.860 --> 00:05:40.259 model, we're going to analyze the repository 00:05:40.259 --> 00:05:44.300 and achieve professional hacking level security 00:05:44.300 --> 00:05:47.790 auditing service. By purely leveraging LLM with 00:05:47.790 --> 00:05:49.730 the combination of all these traditional tools 00:05:49.730 --> 00:05:53.230 together, we're going to push the boundary of 00:05:53.230 --> 00:05:58.269 what we call AI scanning tool. What is, let's 00:05:58.269 --> 00:06:02.569 go back one. What is a harness, just in case? 00:06:02.569 --> 00:06:05.920 Because I have to say that before... I read your 00:06:05.920 --> 00:06:08.540 first blog post on M -Dash and I discovered what 00:06:08.540 --> 00:06:11.819 it was. I hadn't heard the phrase harness before. 00:06:12.019 --> 00:06:14.660 So maybe we should just explain what that is 00:06:14.660 --> 00:06:17.740 before I quiz you more on M -Dash specifically. 00:06:18.379 --> 00:06:21.600 So large language model, when we say AI tool 00:06:21.600 --> 00:06:25.319 is backed by the model itself, there is a scaffolding 00:06:25.319 --> 00:06:29.279 around. It means that not just model at the end, 00:06:29.279 --> 00:06:31.740 it's just a token by token completion at the 00:06:31.740 --> 00:06:35.399 end, right? But it is not enough. for most of 00:06:35.399 --> 00:06:38.540 the daily tasks like particularly when you're 00:06:38.540 --> 00:06:42.040 analyzing source code token completion at the 00:06:42.040 --> 00:06:45.100 end is not enough because you have to look for 00:06:45.100 --> 00:06:48.540 another symbols what is definition of the symbol 00:06:48.540 --> 00:06:52.000 what is a call graph all these tools around work 00:06:52.000 --> 00:06:55.500 together to achieve the goal that you want when 00:06:55.500 --> 00:06:59.819 we say hardness it's a driver of the model behind 00:06:59.819 --> 00:07:03.720 so you can think of in the simple term co -pilot 00:07:03.720 --> 00:07:06.810 CLI is one of the great harnesses generally proposed 00:07:06.810 --> 00:07:11.389 is built for writing source code and like for 00:07:11.389 --> 00:07:14.589 the software development etc but when we say 00:07:14.589 --> 00:07:17.170 harness in the context of security auditing we 00:07:17.170 --> 00:07:21.430 provide all this workflow behind the scene in 00:07:21.430 --> 00:07:23.410 a way that they can interact with with the model 00:07:23.410 --> 00:07:26.230 but we provide all the tools necessary for source 00:07:26.230 --> 00:07:29.449 code analysis that's what we mean by harness 00:07:30.280 --> 00:07:32.759 So if I could put it another way, just to make 00:07:32.759 --> 00:07:35.220 sure I'm fully understanding. So if you like 00:07:35.220 --> 00:07:37.019 to ask a model to do something, it's like asking 00:07:37.019 --> 00:07:39.079 one person to do the job of a team. And they 00:07:39.079 --> 00:07:41.420 can do one task really well, but it's really 00:07:41.420 --> 00:07:44.339 hard for them to do like 10 or 12 specialized 00:07:44.339 --> 00:07:46.720 things. And so the harness kind of allows the 00:07:46.720 --> 00:07:49.920 agents to work together almost like a team with 00:07:49.920 --> 00:07:51.939 like a project manager or manager. Is that a 00:07:51.939 --> 00:07:54.839 good analogy? I think harness is kind of an overloaded 00:07:54.839 --> 00:07:58.279 term. Staffing agent is another way to look at 00:07:58.279 --> 00:08:01.339 it. the harness anything beyond the model itself 00:08:01.339 --> 00:08:06.220 and get most out of the model. What is this? 00:08:06.439 --> 00:08:09.240 You can create the thinking logics in between. 00:08:09.439 --> 00:08:11.259 This is another way to leverage the model itself. 00:08:11.540 --> 00:08:13.699 Again, at the end, the model just provides the 00:08:13.699 --> 00:08:16.420 token completion at the end. But when you say 00:08:16.420 --> 00:08:18.459 harness, we're going to maximize the utility 00:08:18.459 --> 00:08:21.740 of the model. What are those? It depends on the 00:08:21.740 --> 00:08:26.170 tasks. For the coding tasks, People figured it 00:08:26.170 --> 00:08:30.529 out, coding agent or CLI work the best. MDash 00:08:30.529 --> 00:08:33.970 is a harness, the beyond model, that provide 00:08:33.970 --> 00:08:37.129 a way to achieve the security tasks, particularly 00:08:37.129 --> 00:08:41.710 source code auditing. So I guess coming back 00:08:41.710 --> 00:08:46.649 to MDash specifically then, Taesu, what is, well, 00:08:46.769 --> 00:08:48.529 I know you've released a couple of blog posts, 00:08:48.610 --> 00:08:50.389 which we will link to in the show notes, but 00:08:50.389 --> 00:08:54.450 what is so exciting about MDash? What is it? 00:08:54.759 --> 00:09:00.500 do? And why is it better than other similar tools? 00:09:02.720 --> 00:09:06.320 Mdash leverages multiple models, what we call 00:09:06.320 --> 00:09:09.679 ensembling techniques. Depending on the tasks, 00:09:09.940 --> 00:09:12.080 we figure out what's the best way to utilize 00:09:12.080 --> 00:09:15.279 the model in that context. We are not liable 00:09:15.279 --> 00:09:19.080 to use the best performing model like, say, Optus 00:09:19.080 --> 00:09:24.960 and GPT 5 .4, 5 .5 even. we select the best model 00:09:24.960 --> 00:09:27.659 for the job. That's one of the big innovations 00:09:27.659 --> 00:09:30.519 that we did. And for a particular scanning purpose, 00:09:30.899 --> 00:09:33.720 we have hundreds of specialized agents running 00:09:33.720 --> 00:09:36.960 currently, but we are not activating them everything 00:09:36.960 --> 00:09:40.120 at once because it costs like ten hundred times 00:09:40.120 --> 00:09:43.379 more than what we provide with a single agent. 00:09:43.679 --> 00:09:46.580 But we have a particular dispatcher routine that 00:09:46.580 --> 00:09:49.059 figured it out. Given these functions context, 00:09:49.299 --> 00:09:53.139 we just need these four specialized agents. They 00:09:53.139 --> 00:09:55.480 look for the particular vulnerability they're 00:09:55.480 --> 00:09:58.039 good at. I think the way we construct everything, 00:09:58.360 --> 00:10:02.740 we unload many of the cognitive load of the agent 00:10:02.740 --> 00:10:04.980 in a way that they're really good at one single 00:10:04.980 --> 00:10:07.759 job, particularly finding a specific type of 00:10:07.759 --> 00:10:10.279 vulnerability. I think at the end, we actually 00:10:10.279 --> 00:10:13.600 achieve really professional -grade auditing services, 00:10:13.659 --> 00:10:16.379 what I call pen testing. One of the things that 00:10:16.379 --> 00:10:18.360 we demonstrated as part of the blog posting, 00:10:18.539 --> 00:10:22.100 and then we actually won MDash against Windows 00:10:22.100 --> 00:10:25.600 TCP IP stack. When we say TCP IP stack, it's 00:10:25.600 --> 00:10:27.919 an extremely stable codebase you can think of 00:10:27.919 --> 00:10:33.799 in the Windows. And they really get regular pentesting 00:10:33.799 --> 00:10:36.159 from the external vendors and internal team. 00:10:36.440 --> 00:10:38.879 And when we actually won MDash, they were very 00:10:38.879 --> 00:10:41.899 skeptical about we find anything with AI -based 00:10:41.899 --> 00:10:44.049 tools. They're the professionals. They've been 00:10:44.049 --> 00:10:46.990 auditing every year, every quarter. But in fact, 00:10:46.990 --> 00:10:49.409 when we run them, we find a number of vulnerabilities 00:10:49.409 --> 00:10:52.710 in these stores. Out of the box, I mean, does 00:10:52.710 --> 00:10:57.149 the product have a set of air quotes, prompts, 00:10:57.490 --> 00:11:01.250 or vulnerabilities to look for? Is that kind 00:11:01.250 --> 00:11:03.289 of how it works? It's like, here's sort of an 00:11:03.289 --> 00:11:05.889 anti -pattern. Here's a prompt to say, hey, if 00:11:05.889 --> 00:11:09.769 you see this kind of thing. then you may have 00:11:09.769 --> 00:11:12.730 these kinds of issues in your code. Is that kind 00:11:12.730 --> 00:11:14.669 of how it works? And it comes to like a whole 00:11:14.669 --> 00:11:16.830 bunch of different prompts to run over the code? 00:11:17.629 --> 00:11:21.210 That's great questions. We break many of the 00:11:21.210 --> 00:11:24.169 security auditing practices into multiple phases. 00:11:24.990 --> 00:11:27.990 Not just one simple way to do the pen testing 00:11:27.990 --> 00:11:30.509 these days, giving the coding agent, hey, find 00:11:30.509 --> 00:11:33.350 the bugs. That's one way. And agent will figure 00:11:33.350 --> 00:11:36.009 it out what to mean by bugs. and explore the 00:11:36.009 --> 00:11:39.929 code bases and co -pilot CLI might identify some 00:11:39.929 --> 00:11:42.149 of the bugs and provide, hey, this is probably 00:11:42.149 --> 00:11:46.549 the report and POC. While we approach, we break 00:11:46.549 --> 00:11:50.570 down the details of what pen testers are doing, 00:11:50.750 --> 00:11:53.929 how security professionals are approaching this 00:11:53.929 --> 00:11:56.629 problem. We start with the repository structure. 00:11:56.990 --> 00:12:00.350 We review past the history of the repository. 00:12:00.990 --> 00:12:03.549 For example, we are scanning all this Git history. 00:12:04.159 --> 00:12:06.139 and figure it out what are the potential CVE 00:12:06.139 --> 00:12:08.399 around, what are the security patch that they 00:12:08.399 --> 00:12:11.120 create, what are the root cause of them, and 00:12:11.120 --> 00:12:14.460 shape the thread model around first. So that, 00:12:14.500 --> 00:12:16.240 hey, these are potential attack factors that 00:12:16.240 --> 00:12:19.740 developer care about, and this is another scope 00:12:19.740 --> 00:12:22.580 of the vulnerability or scope of the repository 00:12:22.580 --> 00:12:25.860 that we have to tackle separately. We do the 00:12:25.860 --> 00:12:28.379 recomp process even before starting the scanning. 00:12:28.860 --> 00:12:31.620 And then once we construct the thread model, 00:12:32.159 --> 00:12:34.259 threat boundary, what type of asset we care, 00:12:34.559 --> 00:12:38.059 and then we construct the repository structure 00:12:38.059 --> 00:12:42.220 so that we can make the rest of the agent easily 00:12:42.220 --> 00:12:45.179 explore the code bases by using those guidelines 00:12:45.179 --> 00:12:48.220 that we provide. In terms of scanning, again, 00:12:48.299 --> 00:12:51.399 we have hundreds of specialized agents looking 00:12:51.399 --> 00:12:55.059 for a particular vulnerability that include some 00:12:55.059 --> 00:12:57.580 of the variant checker based on the past vulnerability 00:12:57.580 --> 00:13:00.700 existing in the previous repository. We are looking 00:13:00.700 --> 00:13:03.440 for a similar type of vulnerability. And we also 00:13:03.440 --> 00:13:06.519 have a spec checker. We have very specialized 00:13:06.519 --> 00:13:08.899 integer all four checker for certain languages. 00:13:09.340 --> 00:13:12.220 And then we construct those specialized agent 00:13:12.220 --> 00:13:15.419 by using deep research that we are creating inside 00:13:15.419 --> 00:13:18.039 our research team. So I have two follow -on questions. 00:13:18.320 --> 00:13:22.259 The first one is... If you look at classic static 00:13:22.259 --> 00:13:24.940 analysis, like CodeQL, for example, which is 00:13:24.940 --> 00:13:28.259 up on GitHub, it does data flow analysis or can 00:13:28.259 --> 00:13:30.460 do data flow analysis. You don't have to use 00:13:30.460 --> 00:13:32.720 data flow analysis, but you can. And when you 00:13:32.720 --> 00:13:35.720 do data flow analysis, you end up getting much 00:13:35.720 --> 00:13:38.019 higher quality results because I can say, hey, 00:13:38.039 --> 00:13:40.240 this data came from an untrusted source, for 00:13:40.240 --> 00:13:42.919 example. So that's question number one. Does 00:13:42.919 --> 00:13:45.919 MDash support data flow analysis? That's number 00:13:45.919 --> 00:13:50.980 one. And number two is, can I add my own, My 00:13:50.980 --> 00:13:53.220 own rules. I mean, can I add my own things that 00:13:53.220 --> 00:13:54.940 I care about? I mean, I'll give you an example. 00:13:55.720 --> 00:14:00.019 It's not a vulnerability per se, but let's say 00:14:00.019 --> 00:14:03.899 I want to migrate a large old code base over 00:14:03.899 --> 00:14:09.600 to be post -quantum secure. For example, I want 00:14:09.600 --> 00:14:14.360 to support TLS 1 .3 with hybrid crypto. So for 00:14:14.360 --> 00:14:17.559 example, MLChem, which is the post -quantum algorithm. 00:14:18.360 --> 00:14:20.690 But let's say I... I've got a whole bunch of 00:14:20.690 --> 00:14:22.669 old code and I've got S -channel in there, which 00:14:22.669 --> 00:14:25.950 is the Windows DLL for handling TLS. And there's 00:14:25.950 --> 00:14:28.169 certain settings. If I have those settings set, 00:14:28.309 --> 00:14:31.330 there's no way I'm going to be able to run TLS 00:14:31.330 --> 00:14:34.649 1 .3 with post -quantum crypto, even if it's 00:14:34.649 --> 00:14:37.590 available. So I can define like an anti -pattern. 00:14:37.590 --> 00:14:39.309 You know, hey, if you see this kind of thing 00:14:39.309 --> 00:14:41.590 in S -channel, these flags being set in S -channel, 00:14:41.629 --> 00:14:43.860 then hey, I've got a problem. Can you do that 00:14:43.860 --> 00:14:46.899 kind of thing as well? So one, does it do data 00:14:46.899 --> 00:14:49.100 flow analysis? And two, can I write my own rules? 00:14:50.919 --> 00:14:53.460 That's a great question. In terms of data flow, 00:14:53.740 --> 00:14:57.360 in fact, we are not just removing any traditional 00:14:57.360 --> 00:15:00.340 scanning tool. For example, CodeQL. If there 00:15:00.340 --> 00:15:02.500 is a CodeQL database ready for the repository, 00:15:02.860 --> 00:15:06.340 we actually leverage them. For example, if there 00:15:06.340 --> 00:15:08.899 is a code graph that is already constructed out 00:15:08.899 --> 00:15:11.419 of the CodeQL database, we actually have a... 00:15:11.639 --> 00:15:14.179 particular tool that we provide to the agent. 00:15:14.320 --> 00:15:17.039 In a way, the agent can navigate the source code 00:15:17.039 --> 00:15:20.039 based on the code graph. Not only that, we actually 00:15:20.039 --> 00:15:23.279 annotate our source code bases by using data 00:15:23.279 --> 00:15:26.960 flow, not just a data flow, or we even resolve 00:15:26.960 --> 00:15:29.620 the indirect call in memory -unsafe languages 00:15:29.620 --> 00:15:32.720 like C, for example. Many of them are extremely 00:15:32.720 --> 00:15:35.320 hard, almost impossible problem to solve in larger 00:15:35.320 --> 00:15:38.440 scale, like even with the code pair. For those 00:15:38.440 --> 00:15:41.629 cases, we leverage the LLN in a way that, hey, 00:15:41.669 --> 00:15:44.889 these are the probabilistic list of the indirect 00:15:44.889 --> 00:15:47.950 call target, for example. And this is probably 00:15:47.950 --> 00:15:52.669 the data flow that human observe beyond how static 00:15:52.669 --> 00:15:55.110 analyzer can provide. So we consider all those 00:15:55.110 --> 00:15:58.850 together and create a nicely annotated source 00:15:58.850 --> 00:16:01.509 code. And most of the agents are running on top 00:16:01.509 --> 00:16:04.710 of those source code that we annotate. So annotate 00:16:04.710 --> 00:16:08.549 here is not just a taint analysis, data flow. 00:16:09.049 --> 00:16:12.210 and beyond that. And in terms of customization, 00:16:12.690 --> 00:16:15.669 we actually provide lots of different ways to 00:16:15.669 --> 00:16:19.129 extend our system that include customized thread 00:16:19.129 --> 00:16:22.110 model and some of the deployment setting, some 00:16:22.110 --> 00:16:24.769 of the things that you care or, hey, these are 00:16:24.769 --> 00:16:27.230 the scope that I really want to tackle. I don't 00:16:27.230 --> 00:16:29.289 care about the rest of the system. We provide 00:16:29.289 --> 00:16:32.009 lots of extension points to the MDash project. 00:16:32.289 --> 00:16:34.750 So the developer who really want to scan the 00:16:34.750 --> 00:16:38.240 source code, we actually meet their taste. what 00:16:38.240 --> 00:16:41.080 type of vulnerability they care, what the places 00:16:41.080 --> 00:16:44.679 in the source code they have to audit. I have 00:16:44.679 --> 00:16:46.840 one other follow -on question. I realize I'm 00:16:46.840 --> 00:16:48.899 hogging all the time here. But you said threat 00:16:48.899 --> 00:16:53.200 model. So if I have two API endpoints, and one 00:16:53.200 --> 00:16:55.220 is anonymous and remotely accessible to the internet, 00:16:55.340 --> 00:16:58.639 as per the threat model, and the other one is 00:16:58.639 --> 00:17:00.940 locked behind a firewall with strong authentication, 00:17:01.360 --> 00:17:04.440 strong authorization, restricted set of IP addresses, 00:17:04.480 --> 00:17:05.980 and so on. So it's got a really small attack 00:17:05.980 --> 00:17:09.170 surface. Can M -Dash take that into consideration 00:17:09.170 --> 00:17:13.089 as well? Yes. We have multiple sources that we 00:17:13.089 --> 00:17:16.349 construct a threat model. For example, if there 00:17:16.349 --> 00:17:19.710 is a security guideline in the repository or 00:17:19.710 --> 00:17:23.009 documentation, our agent deep into it and summarize 00:17:23.009 --> 00:17:26.450 the scope of the threat model. We extract the 00:17:26.450 --> 00:17:29.930 list of the public -facing entry point to the 00:17:29.930 --> 00:17:32.190 source code. If you're analyzing web service, 00:17:32.410 --> 00:17:35.190 these are the starting point. But if you're analyzing 00:17:35.190 --> 00:17:37.740 external library... we construct a different 00:17:37.740 --> 00:17:40.299 threat model. Typically in the external library, 00:17:40.640 --> 00:17:43.920 we consider all the external facing API are entry 00:17:43.920 --> 00:17:46.779 point for the attack. So we have all these scope 00:17:46.779 --> 00:17:50.740 out even before starting the scanning. I don't 00:17:50.740 --> 00:17:54.980 know if people realize just how important and 00:17:54.980 --> 00:17:57.200 incredible this is. I think we've just met the 00:17:57.200 --> 00:18:00.380 static analysis singularity. The fact that you're 00:18:00.380 --> 00:18:02.759 taking all of this data into consideration, taking 00:18:02.759 --> 00:18:06.490 output potentially, output from CoQL. you know, 00:18:06.529 --> 00:18:08.609 sort of exposure information through a threat 00:18:08.609 --> 00:18:11.529 model, as well as the code vulnerabilities. That's 00:18:11.529 --> 00:18:14.450 everything, like all basically piled together 00:18:14.450 --> 00:18:18.029 into one universal tool. That's, for anyone listening, 00:18:18.309 --> 00:18:21.869 if they didn't get how important the last couple 00:18:21.869 --> 00:18:24.769 of sentences was, just rewind and just listen 00:18:24.769 --> 00:18:27.170 to that again. That's actually really, really 00:18:27.170 --> 00:18:29.549 incredible. I think that's great to hear. It's 00:18:29.549 --> 00:18:32.069 very exciting, incredibly exciting. Do you want 00:18:32.069 --> 00:18:36.109 to hear more exciting news? We run mdash against 00:18:36.109 --> 00:18:40.490 TCP IP and we backtest it. You can think of TCP 00:18:40.490 --> 00:18:42.930 IP stack on the Windows, not just a complex, 00:18:43.190 --> 00:18:46.670 never been used for the training in the model. 00:18:46.809 --> 00:18:49.910 This is the first time model and our harness 00:18:49.910 --> 00:18:52.250 actually saw the proprietary source code basis. 00:18:52.829 --> 00:18:55.390 We have all this history of what type of vulnerability 00:18:55.390 --> 00:18:57.930 that we discover in TCP IP stack at Microsoft. 00:18:58.769 --> 00:19:03.440 We backtest every single one of them. Discovered 00:19:03.440 --> 00:19:05.779 by human, discovered fuzzing, all these previous 00:19:05.779 --> 00:19:10.599 tools and stuff. Amdash discovered 100 % of them. 00:19:10.859 --> 00:19:15.019 We didn't miss any single vulnerability from 00:19:15.019 --> 00:19:17.599 those tools. Let me repeat what you just said 00:19:17.599 --> 00:19:19.339 to make sure I understood precisely what you 00:19:19.339 --> 00:19:21.440 just said. By the way, the reason I'm hogging 00:19:21.440 --> 00:19:24.599 all this is I'm a huge CoQL fan. I'm a huge static 00:19:24.599 --> 00:19:27.769 analysis fan. I'm a huge fan of fuzzing. For 00:19:27.769 --> 00:19:29.349 those who are not aware, back in the day, I actually 00:19:29.349 --> 00:19:32.349 owned all the unmanaged requirements in the Microsoft 00:19:32.349 --> 00:19:35.650 Security Development lifecycle. So I'm well aware 00:19:35.650 --> 00:19:38.569 of all these things. We use them in anger. So 00:19:38.569 --> 00:19:40.369 what you just said, make sure I got this right, 00:19:40.569 --> 00:19:43.490 is you looked at a whole bunch of old bugs in 00:19:43.490 --> 00:19:46.309 the Microsoft TCP IP stack and running MDash, 00:19:46.430 --> 00:19:51.109 you found all those bugs and more. So you took 00:19:51.109 --> 00:19:53.089 a vulnerable version, like an older version of 00:19:53.089 --> 00:19:55.980 the TCP IP stack. Whether those bugs were found 00:19:55.980 --> 00:19:57.500 through code review, static analysis, dynamic 00:19:57.500 --> 00:20:00.220 analysis, fuzz testing, someone just found, you 00:20:00.220 --> 00:20:02.779 found 100%. This is amazing. It doesn't mean 00:20:02.779 --> 00:20:05.339 that we are going to find all of them in the 00:20:05.339 --> 00:20:07.920 future, right? But still, it was surprising that 00:20:07.920 --> 00:20:10.380 we actually discovered all of them with 100%, 00:20:10.380 --> 00:20:14.400 near 100 % accuracy. That is incredible. So what 00:20:14.400 --> 00:20:16.240 other languages do you focus on? What other languages 00:20:16.240 --> 00:20:18.420 can you look at, like C Sharp, Rust, Python? 00:20:19.319 --> 00:20:22.369 So we are a professional hacker. And we care 00:20:22.369 --> 00:20:24.569 about the complex infrastructure software such 00:20:24.569 --> 00:20:28.289 as memory -unsafe languages. So we start with 00:20:28.289 --> 00:20:31.109 those memory -unsafe languages like C and C++ 00:20:31.109 --> 00:20:33.750 and browsers and whatnot. That was our initial 00:20:33.750 --> 00:20:39.509 direction. In fact, we actually support officially 00:20:39.509 --> 00:20:42.470 many other languages. You mentioned Rust, TypeScript, 00:20:42.650 --> 00:20:45.369 and whatnot. We support all of them. We actually 00:20:45.369 --> 00:20:49.920 run M -Dash against Rust standard library. Meaning 00:20:49.920 --> 00:20:53.420 we actually found many of bugs. But our tool, 00:20:53.559 --> 00:20:55.599 one nice thing about our tool, we are not just 00:20:55.599 --> 00:20:59.420 looking for exploitable vulnerability. We actually 00:20:59.420 --> 00:21:02.819 find we were pushing our MDash very closer to 00:21:02.819 --> 00:21:06.059 the developer lifecycle. So while you're developing, 00:21:06.339 --> 00:21:08.839 we're running MDash on the background. We are 00:21:08.839 --> 00:21:11.940 running MDash in the latest modification that 00:21:11.940 --> 00:21:16.000 you have. We found many of the bugs in the standard 00:21:16.000 --> 00:21:19.460 library even, which is well -ordered. So were 00:21:19.460 --> 00:21:22.900 the bugs in the Rust standard library in Rust, 00:21:23.119 --> 00:21:25.700 or were they calling out to unsafe code from 00:21:25.700 --> 00:21:28.640 Rust? It's an unsafe code in the Rust, meaning 00:21:28.640 --> 00:21:32.319 that we can crash. Okay. Even if Rust compiler 00:21:32.319 --> 00:21:35.640 says it's safe from any memory safety issue, 00:21:35.819 --> 00:21:38.579 because we found the bugs in, whenever we found 00:21:38.579 --> 00:21:41.660 the bugs in unsafe dialect of the Rust, you can 00:21:41.660 --> 00:21:43.339 crash the program. Well, not just crash, right? 00:21:43.500 --> 00:21:46.849 Not just crash. I'm going to step in. I'm going 00:21:46.849 --> 00:21:49.410 to step in here, Michael. Michael, do we have 00:21:49.410 --> 00:21:51.710 to nerd about Rust that much? Yes, we need to 00:21:51.710 --> 00:21:56.630 nerd about this whole topic. So Sarah set this 00:21:56.630 --> 00:21:59.069 meeting up with Teisu to talk about this stuff. 00:21:59.269 --> 00:22:01.829 And I did not realize that I would actually be 00:22:01.829 --> 00:22:05.359 so excited about this. I knew, I knew, Michael. 00:22:05.460 --> 00:22:08.180 I didn't think you realized because you're too 00:22:08.180 --> 00:22:10.599 busy with your post -quantum crypto nowadays. 00:22:10.799 --> 00:22:13.839 But I knew that when we set up this call and 00:22:13.839 --> 00:22:16.259 do this recording, you were going to completely 00:22:16.259 --> 00:22:19.460 nerd out and that I wasn't going to say very 00:22:19.460 --> 00:22:23.579 much. Do you want to hear more about the story 00:22:23.579 --> 00:22:28.680 behind Rust? Our group at Georgia Tech, about 00:22:28.680 --> 00:22:34.859 2022, 2023. we start reviewing all the vulnerability 00:22:34.859 --> 00:22:38.220 in the Rust ecosystems all the libraries in Rust 00:22:38.220 --> 00:22:46.099 we discover 50 % of the entire Rust unsafe given 00:22:46.099 --> 00:22:49.259 all these Rust packages and including standard 00:22:49.259 --> 00:22:52.180 libraries and there's a crate inside the Rust 00:22:52.180 --> 00:22:56.859 we discover 50 % of all memory unsafe issue in 00:22:56.859 --> 00:23:00.420 Rust ecosystems at the moment That includes like 00:23:00.420 --> 00:23:05.700 200, 300 CVE from our group. Hey, so what about 00:23:05.700 --> 00:23:08.240 deserialization bugs, like in C -sharp? There 00:23:08.240 --> 00:23:11.880 is a deserialization agent in our system that 00:23:11.880 --> 00:23:15.180 focuses on C -sharp and Java, and these are typical 00:23:15.180 --> 00:23:17.900 sources. So if anyone's not aware, deserialization 00:23:17.900 --> 00:23:21.200 is actually a really serious problem in air quotes, 00:23:21.319 --> 00:23:24.339 memory -safe languages. Huge problem. Yeah? Yeah. 00:23:24.440 --> 00:23:29.170 And PHP and any XML -related... serialization 00:23:29.170 --> 00:23:32.650 issue even like some serializations in python 00:23:32.650 --> 00:23:35.569 like whenever you pick up like there are tons 00:23:35.569 --> 00:23:38.029 of issues you can see and we have a very specialized 00:23:38.029 --> 00:23:41.009 agent that's just looking for this serialization 00:23:41.009 --> 00:23:45.509 serialization issue um i wanted to ask like so 00:23:45.509 --> 00:23:47.490 like i'm thinking about myself as head of an 00:23:47.490 --> 00:23:49.529 appsec program right putting myself in that persona 00:23:49.529 --> 00:23:54.700 like if i've already got sassed tools integrated 00:23:54.700 --> 00:23:57.859 in my CICD pipeline and generating bugs and work 00:23:57.859 --> 00:24:02.000 and all that kind of stuff. Is this complementing 00:24:02.000 --> 00:24:04.880 it? Is it side by side? Is it replacing it? Help 00:24:04.880 --> 00:24:08.460 me sort of understand how we think this tool 00:24:08.460 --> 00:24:12.519 should be used to actually protect the stuff 00:24:12.519 --> 00:24:14.640 that I have source code control over. I think 00:24:14.640 --> 00:24:18.460 traditional SaaS tools tend to suffer from high 00:24:18.460 --> 00:24:21.539 false positives, meaning that many of the reports 00:24:21.539 --> 00:24:26.250 are warning. or informative guideline in a very 00:24:26.250 --> 00:24:28.710 simple way. Even though CodeCare pushed the boundaries 00:24:28.710 --> 00:24:31.329 significantly, right? You can do all this crazy 00:24:31.329 --> 00:24:34.210 data for analysis and so that ultimately you 00:24:34.210 --> 00:24:37.750 can reduce down for its positive. But Amdash 00:24:37.750 --> 00:24:42.490 tool or most of the AI -based tool have much 00:24:42.490 --> 00:24:45.430 deeper understanding. In fact, we talked about 00:24:45.430 --> 00:24:48.369 these AI hallucinations maybe five months ago 00:24:48.369 --> 00:24:51.529 for a very short period of time. If you see the 00:24:51.529 --> 00:24:55.750 bug report from M -Dash these days, we rarely 00:24:55.750 --> 00:24:59.829 see almost 0 % hallucinations in the code bases. 00:25:00.109 --> 00:25:02.190 Because of all these safeguards and pipelines 00:25:02.190 --> 00:25:05.750 that we created, whenever we say bug, it's an 00:25:05.750 --> 00:25:08.950 extremely likely bug. But at the same time, we 00:25:08.950 --> 00:25:11.130 are not simply saying it's a bug. We provide 00:25:11.130 --> 00:25:15.329 a guideline. These are the assumptions that we 00:25:15.329 --> 00:25:19.130 make. As far as you enable this compilation flag, 00:25:19.519 --> 00:25:22.859 that this is a bug. As far as this precondition 00:25:22.859 --> 00:25:25.420 met, because we don't know anything about how 00:25:25.420 --> 00:25:29.180 it thinks deployed, hey, your reverse proxy has 00:25:29.180 --> 00:25:31.319 some of the gate control and firewall and stuff, 00:25:31.500 --> 00:25:34.519 probably not a bug. But as far as attacker can 00:25:34.519 --> 00:25:38.480 do A and B and C, this is likely a bug. Because 00:25:38.480 --> 00:25:40.759 of all these preconditions that we explicitly 00:25:40.759 --> 00:25:44.079 specified, we can drastically reduce down the 00:25:44.079 --> 00:25:46.079 force project. And so I would assume like most 00:25:46.079 --> 00:25:47.420 customers are very conservative. They're going 00:25:47.420 --> 00:25:49.519 to keep the SAST in it for now. They'll do a 00:25:49.519 --> 00:25:52.259 comparison. They'll also put the MDash in there. 00:25:52.619 --> 00:25:55.640 Now, does MDash, you know, does it actually generate 00:25:55.640 --> 00:25:59.440 like a proposed fix or anything like that? Or 00:25:59.440 --> 00:26:01.819 like, can you talk about like the workflow integration 00:26:01.819 --> 00:26:06.000 part? So one nice feature of MDash is that we 00:26:06.000 --> 00:26:08.539 actually reason about each of the findings in 00:26:08.539 --> 00:26:12.240 multi -dimensional, meaning that... We are aggregating 00:26:12.240 --> 00:26:15.259 multiple bugs as a single source, meaning there 00:26:15.259 --> 00:26:18.519 can be multiple symptoms can happen because of 00:26:18.519 --> 00:26:21.119 the bug that we found, but likely they can be 00:26:21.119 --> 00:26:24.099 just one fix that can address all these symptoms 00:26:24.099 --> 00:26:27.099 together. And we aggregate together and generate 00:26:27.099 --> 00:26:31.400 a fix or a suggestion so that the user of mDash 00:26:31.400 --> 00:26:34.180 is part of the Defender portal. They can even 00:26:34.180 --> 00:26:38.940 create a PR, the pull request to the GitHub repository 00:26:38.940 --> 00:26:42.799 they connect to. to the Defender portal. I think 00:26:42.799 --> 00:26:46.039 they're not just getting the suggested fix, they 00:26:46.039 --> 00:26:49.539 can create the PR for you, not just from the 00:26:49.539 --> 00:26:52.000 M -Dash, with the tight integration with the 00:26:52.000 --> 00:26:55.819 autofix features of GitHub as well. Very cool. 00:26:56.059 --> 00:26:59.539 Now, Taesu, you mentioned you'd only been at 00:26:59.539 --> 00:27:02.700 Microsoft for about six months, but you and your 00:27:02.700 --> 00:27:05.240 team, you have a very interesting... How can 00:27:05.240 --> 00:27:08.599 I put it? Origin story. So do you want to tell 00:27:08.599 --> 00:27:14.400 us how you came to be? Well, at Microsoft, but 00:27:14.400 --> 00:27:18.539 also what you did to end up at Microsoft. That's 00:27:18.539 --> 00:27:23.099 great. DARPA has been organizing grand challenges. 00:27:23.460 --> 00:27:25.680 You probably heard self -driving car challenge 00:27:25.680 --> 00:27:29.000 or urban challenge at the time. And there was 00:27:29.000 --> 00:27:32.339 a humanoid competition to build a humanoid robot 00:27:32.339 --> 00:27:36.410 for rescue missions. Three years ago, Dalpa announced 00:27:36.410 --> 00:27:40.230 a huge challenge. Hey, by leveraging the AI frontier 00:27:40.230 --> 00:27:42.769 model, what are the things that we can do in 00:27:42.769 --> 00:27:46.269 security? Particularly, how to find and fix those 00:27:46.269 --> 00:27:49.089 vulnerabilities in the context of infrastructure 00:27:49.089 --> 00:27:52.170 source code, open source project, like Linux 00:27:52.170 --> 00:27:56.029 kernel and Nginx and whatnot. Given those complex 00:27:56.029 --> 00:27:59.589 VOR source code, how can you find bugs? There 00:27:59.589 --> 00:28:02.569 was competition organized by the Alpha and Alpha 00:28:02.569 --> 00:28:06.529 H three years ago. It was multi -year journey. 00:28:06.650 --> 00:28:10.049 Together with Microsoft and all these frontier 00:28:10.049 --> 00:28:14.109 AI companies, including Google, Anthropian, OpenAI, 00:28:14.390 --> 00:28:17.730 they sponsor those competition together. They 00:28:17.730 --> 00:28:20.390 organize, and our job is just to find the vulnerability. 00:28:20.869 --> 00:28:24.809 And we organize team from Georgia Tech side so 00:28:24.809 --> 00:28:27.089 that we have a bunch of people working for this 00:28:27.089 --> 00:28:30.849 competition. And we won at the end last year. 00:28:31.049 --> 00:28:33.829 And we talked about where to join at the end. 00:28:34.369 --> 00:28:37.150 But Microsoft suggested a very interesting proposal. 00:28:37.609 --> 00:28:42.069 Say, what about you just enable this AICC artifact 00:28:42.069 --> 00:28:46.589 into the world of GitHub? We have tons of customers 00:28:46.589 --> 00:28:49.049 you can approach. You can think of you enable 00:28:49.049 --> 00:28:51.970 this AI -based tool in the context of GitHub. 00:28:52.130 --> 00:28:55.210 All these customers, all these users of the GitHub 00:28:55.210 --> 00:28:57.779 get benefit from it. what we call Real World 00:28:57.779 --> 00:29:00.920 AI Cycle Challenge. So we love this opportunity. 00:29:01.299 --> 00:29:04.859 So majority of team members join Microsoft together 00:29:04.859 --> 00:29:08.740 with me. So Taesu, that is a very cool story 00:29:08.740 --> 00:29:11.400 and we are so glad you picked Microsoft because 00:29:11.400 --> 00:29:13.920 I completely agree that it's a great way to impact 00:29:13.920 --> 00:29:18.930 the world at large. So say I'm a customer I'm 00:29:18.930 --> 00:29:23.849 interested. How would I go about this? Is this 00:29:23.849 --> 00:29:27.009 like a private preview thing? How does this work? 00:29:27.289 --> 00:29:30.809 So we have a link that you guys can request access 00:29:30.809 --> 00:29:35.450 to M -Dash. If you are already a customer of 00:29:35.450 --> 00:29:40.789 Microsoft under our Defender product, our customer 00:29:40.789 --> 00:29:43.410 engagement team will reach out to you after you 00:29:43.410 --> 00:29:46.910 file the application. Awesome. Thank you. Nice. 00:29:46.910 --> 00:29:51.269 And we'll put a link in the show notes to the 00:29:51.269 --> 00:29:55.589 blogs where you can get the links for that. Well, 00:29:55.710 --> 00:29:59.009 Tezu, before we finish, we always ask our guests 00:29:59.009 --> 00:30:03.269 a couple of questions, which is, firstly, what 00:30:03.269 --> 00:30:07.430 does a day in the life of Tezu look like? Apart 00:30:07.430 --> 00:30:12.069 from working on M -Dash, working very hard. I 00:30:12.069 --> 00:30:16.980 think my... My day life starts at night, meaning 00:30:16.980 --> 00:30:20.380 that before I go to sleep, I make sure my agent 00:30:20.380 --> 00:30:24.059 can work for the next eight hours. So I think 00:30:24.059 --> 00:30:26.819 about, hey, what is the right way to drive this 00:30:26.819 --> 00:30:29.740 agent working while I'm sleeping? And then I 00:30:29.740 --> 00:30:32.220 make sure it has a continuous number of work 00:30:32.220 --> 00:30:35.380 that they have to do. When I wake up, I check 00:30:35.380 --> 00:30:39.230 the completed tasks that I... signed to the agent. 00:30:39.529 --> 00:30:43.869 And many of my daily work at Microsoft is how 00:30:43.869 --> 00:30:47.109 to handle all these completed tasks and nicely 00:30:47.109 --> 00:30:49.630 push to the M -Dash. We're also thinking about 00:30:49.630 --> 00:30:51.970 what is the next potential direction that we 00:30:51.970 --> 00:30:55.130 can take as a team. We're going to announce a 00:30:55.130 --> 00:31:00.130 new interesting team in the coming months. So 00:31:00.130 --> 00:31:02.329 we're preparing for those big announcements as 00:31:02.329 --> 00:31:05.650 well. And one final thing, following on from 00:31:05.650 --> 00:31:09.450 Sarah, is if you had one final thought to leave 00:31:09.450 --> 00:31:12.710 our listeners with, what would it be? I think 00:31:12.710 --> 00:31:18.410 because of the AI velocity and volume that it 00:31:18.410 --> 00:31:22.210 enables, I think it's a really good time to think 00:31:22.210 --> 00:31:26.150 about what your attackers and what are your powerful 00:31:26.150 --> 00:31:28.970 attackers who have access to AI. I think we are 00:31:28.970 --> 00:31:32.150 not just advertising M -Dash itself. It's more 00:31:32.150 --> 00:31:35.869 like... is everything changed because of the 00:31:35.869 --> 00:31:39.529 recent capability of the LOM. And this is much 00:31:39.529 --> 00:31:42.369 more significant than we think because attackers 00:31:42.369 --> 00:31:45.890 now have this powerful tool and high intelligence 00:31:45.890 --> 00:31:50.309 entity that what you call AGI or not. And once 00:31:50.309 --> 00:31:53.329 you release your software, it doesn't have to 00:31:53.329 --> 00:31:57.329 be the source code, just binary or website, attacker 00:31:57.329 --> 00:32:00.690 can just attack immediately after. All these 00:32:00.690 --> 00:32:04.259 powerful attackers can attack your systems. I 00:32:04.259 --> 00:32:06.680 think this is an alarming moment for security 00:32:06.680 --> 00:32:09.900 researchers and everyone in the world because 00:32:09.900 --> 00:32:13.019 of this high intelligence entity now become an 00:32:13.019 --> 00:32:16.140 attacker if they want. And it's a good time to 00:32:16.140 --> 00:32:18.359 think about how to protect your systems starting 00:32:18.359 --> 00:32:21.200 from source code. I truly believe that Defender 00:32:21.200 --> 00:32:24.900 has much benefit at the end after these chaotic 00:32:24.900 --> 00:32:27.819 periods for a couple of years because we have 00:32:27.819 --> 00:32:31.200 now access to those tools as well as the source 00:32:31.200 --> 00:32:34.099 code. and as a defender we can adjust the release 00:32:34.099 --> 00:32:37.019 day and before putting those source code to the 00:32:37.019 --> 00:32:39.920 outside you have opportunity to check and address 00:32:39.920 --> 00:32:43.000 all these problem in larger scale thanks to AI. 00:32:43.240 --> 00:32:46.039 I think I truly believe this moment that defender 00:32:46.039 --> 00:32:50.880 will ultimately win this cat and mouse game and 00:32:50.880 --> 00:32:53.059 then we have a more opportunity to protect our 00:32:53.059 --> 00:32:55.700 system and have a better life up at the end. 00:32:56.359 --> 00:32:57.960 Man I could have been here another couple of 00:32:57.960 --> 00:33:00.470 hours I think just talking about it but We don't 00:33:00.470 --> 00:33:03.349 have that time. Anyway, look, Tacey, thank you 00:33:03.349 --> 00:33:05.470 so much for joining us this week. As with every 00:33:05.470 --> 00:33:08.430 episode, I always learn something. But this has 00:33:08.430 --> 00:33:11.569 been definitely something that is, I don't just 00:33:11.569 --> 00:33:13.789 learn a lot, I'm incredibly excited by it. This 00:33:13.789 --> 00:33:16.430 is really cool. And I made a comment somewhat 00:33:16.430 --> 00:33:18.869 jokingly about the singularity, but we may be 00:33:18.869 --> 00:33:22.680 there. So this is really, really cool to see. 00:33:22.779 --> 00:33:24.339 So again, thank you so much for joining us this 00:33:24.339 --> 00:33:26.359 week. I know all of us really appreciate you 00:33:26.359 --> 00:33:27.519 taking the time. And I know you're incredibly 00:33:27.519 --> 00:33:29.680 busy, especially with the product, you know, 00:33:29.680 --> 00:33:31.680 essentially just getting started. So all the 00:33:31.680 --> 00:33:33.019 best of luck with it. And I hope it goes incredibly 00:33:33.019 --> 00:33:35.819 well. I know it will. And to all our listeners 00:33:35.819 --> 00:33:38.160 out there, hopefully you're as excited as I am 00:33:38.160 --> 00:33:40.539 for this thing. If not, doesn't matter. Stay 00:33:40.539 --> 00:33:42.839 safe. And we'll see you next time.