WEBVTT - A Conversation With Sarit Tager from Prisma Cloud 0:00:00.840 --> 0:00:04.960 Unsupervised Learning is a podcast about trends and ideas in cybersecurity, 0:00:05.000 --> 0:00:09.960 national security, AI, technology and society, and how best to 0:00:10.000 --> 0:00:18.880 upgrade ourselves to be ready for what's coming. All right, well, 0:00:19.040 --> 0:00:24.400 welcome to unsupervised learning. Ethan. Yeah. Can you give a 0:00:24.400 --> 0:00:27.600 little bit of background about yourself and what you're working on? 0:00:28.440 --> 0:00:33.000 Yes. So I'm Sarita Jara and project management for application security. 0:00:33.000 --> 0:00:36.760 And SBM is part of Cortex Cloud in Palo Alto Networks. 0:00:38.000 --> 0:00:41.240 I can kind of come from a background of engineering 0:00:41.400 --> 0:00:47.120 and product, uh, from several, uh, different areas. Uh, mostly 0:00:47.120 --> 0:00:50.959 in the last years, cloud security and application security. Um, 0:00:51.440 --> 0:00:53.600 I always say that I come to the application security 0:00:53.600 --> 0:00:57.200 space from handling or kind of using all these different 0:00:57.200 --> 0:01:01.190 tools of application security and trying to write or have 0:01:01.230 --> 0:01:04.870 the right experience for both developers and security people to 0:01:04.910 --> 0:01:07.149 kind of, I don't know if to laugh, but at 0:01:07.150 --> 0:01:11.309 least like security to be able to actually, uh, solve 0:01:11.350 --> 0:01:14.070 the problem for the security people and not have so 0:01:14.069 --> 0:01:19.350 much problems on the production, production, uh, sites, but also 0:01:19.470 --> 0:01:21.869 make sure developers understand what they need to fix and 0:01:21.870 --> 0:01:23.070 why they need to fix it. 0:01:23.750 --> 0:01:27.030 Okay. That's great. And I was looking at the, um, 0:01:27.470 --> 0:01:30.750 at the site in the platform prior to joining. It 0:01:30.750 --> 0:01:33.990 seems like it's it's becoming quite cohesive with all the 0:01:33.990 --> 0:01:37.790 different pieces. And I heard, uh, somewhere else that you're 0:01:37.790 --> 0:01:40.869 looking to, like, unify into, like a single data lake, 0:01:40.870 --> 0:01:43.830 which is something that I'm really excited about. I would 0:01:43.830 --> 0:01:45.149 love to hear more about that. 0:01:46.150 --> 0:01:49.110 So basically, uh, Palo Alto Networks had a product called 0:01:49.110 --> 0:01:53.270 Prism Cloud, which handled cloud security or, and also application security, 0:01:53.550 --> 0:01:58.230 another product called cortex that handled the, the Siem and 0:01:58.230 --> 0:02:01.570 the SoC sock side of things. And, um, in the 0:02:01.570 --> 0:02:05.010 last few months, we actually merged these two into one 0:02:05.010 --> 0:02:07.850 data lake, in which you can do everything. All the 0:02:07.850 --> 0:02:10.930 information you need is just residing in one data lake, 0:02:11.090 --> 0:02:14.530 whether these are attacks coming from the SOC or, uh, 0:02:14.570 --> 0:02:19.089 cloud posture findings or application security ones. And think about 0:02:19.090 --> 0:02:21.610 the potential of having everything within the same data lake 0:02:21.650 --> 0:02:24.810 like in one click. You can ask questions that in 0:02:24.810 --> 0:02:28.130 the past, it wasn't as simple to do that because 0:02:28.169 --> 0:02:31.370 the information reside on different systems. You don't necessarily have 0:02:31.370 --> 0:02:34.489 the context. And if you think about application security, in 0:02:34.490 --> 0:02:38.370 this sense, the thing that application security, uh, lacks the 0:02:38.370 --> 0:02:40.930 most is the context. Like I see so many things, 0:02:41.410 --> 0:02:43.970 which is not good, but I don't know if they 0:02:43.970 --> 0:02:47.450 are really going to production or they're going to be exploitable. 0:02:47.650 --> 0:02:50.810 Are they going to be used by my application? So 0:02:50.810 --> 0:02:53.530 one of the things in application security is that you 0:02:53.530 --> 0:02:57.210 have just too many issues. Usually developer just either ignore 0:02:57.320 --> 0:03:00.080 them or they get mad. On the security people because 0:03:00.080 --> 0:03:02.799 they block them or on an on every build or 0:03:02.800 --> 0:03:06.680 PR and you kind of there is no balance in understanding, okay. 0:03:06.720 --> 0:03:09.079 These are the things that need to be fixed. And 0:03:09.400 --> 0:03:13.399 when we introduce uh, cortex cloud and then we will 0:03:13.400 --> 0:03:16.880 introduce uh, aspm as well. We actually say we bring 0:03:16.880 --> 0:03:20.000 everything together. You don't need to, uh, you know, look 0:03:20.000 --> 0:03:23.000 at different things, whether you have different scanners, whether you 0:03:23.000 --> 0:03:27.560 have different, uh, version control or different CI, CD systems. Uh, 0:03:27.560 --> 0:03:29.640 if you want to see whether you have different clouds, 0:03:29.639 --> 0:03:31.520 if you want to see everything, you can come to 0:03:31.520 --> 0:03:35.320 our environment, come to our solution and have the platform 0:03:35.320 --> 0:03:39.360 you need for, uh, um, everything within the same place, 0:03:39.360 --> 0:03:41.360 it means that we give the context. We get, we 0:03:41.400 --> 0:03:43.320 get from the cloud. It's not just, you see things 0:03:43.320 --> 0:03:46.600 for application for for the code side of things, but 0:03:46.600 --> 0:03:49.200 you see things that are code side. But then they 0:03:49.240 --> 0:03:51.440 are connected into the cloud one and the cloud one 0:03:51.440 --> 0:03:54.000 are being connected to the SOC one. So it's actually 0:03:54.040 --> 0:03:58.420 one system that covers everything that a security person cares 0:03:58.420 --> 0:04:01.900 about with regards to how you see things within, within cloud. 0:04:01.900 --> 0:04:05.100 And we also acknowledge the fact that cloud is, uh, 0:04:05.140 --> 0:04:08.300 is growing very fast and application to cloud is growing 0:04:08.300 --> 0:04:12.100 very fast. AI is bringing, you know, bunch of more 0:04:12.100 --> 0:04:16.100 code into the, into, uh, the environment. Many of our 0:04:16.100 --> 0:04:20.659 colleagues been written by different, uh, models. All of these 0:04:20.660 --> 0:04:24.260 things also bring security issues, and they don't solve the 0:04:24.260 --> 0:04:28.339 problem of having a lot of problems before production. But 0:04:28.339 --> 0:04:31.179 what we bring to this one is saying you have 0:04:31.180 --> 0:04:34.539 a lot of risk. We will help you to prioritize them, 0:04:34.540 --> 0:04:37.900 but not just to prioritize them, but also to prevent them. 0:04:38.180 --> 0:04:42.380 Because most of the solutions say, I will prioritize everything 0:04:42.380 --> 0:04:45.900 for you, which is great, but the funnel keeps growing. 0:04:45.940 --> 0:04:48.539 You know, you cannot kind of manage it. And what 0:04:48.540 --> 0:04:51.820 we are saying, we will allow you to actually do 0:04:51.860 --> 0:04:55.680 a much more flexible and recommended prevention. How do I 0:04:55.680 --> 0:04:58.760 do the right guardrails within my pull request? How do 0:04:58.760 --> 0:05:04.360 I do the right guardrails within my build? And this 0:05:04.360 --> 0:05:07.080 is using all the things we know from production and 0:05:07.080 --> 0:05:11.279 from the actual runtime environment, whether it's actually deployed, whether 0:05:11.279 --> 0:05:15.119 it's open to the internet, whether it's had an access 0:05:15.120 --> 0:05:18.000 to sensitive data, all the questions you can think of 0:05:18.000 --> 0:05:21.320 on how my application will go will look in production. 0:05:21.400 --> 0:05:24.360 This is something that we have natively because we have 0:05:24.400 --> 0:05:28.120 everything on the data lake and the potential is huge. 0:05:29.040 --> 0:05:33.640 Yeah, that is absolutely wonderful. I'm so excited to hear this. Um, 0:05:34.040 --> 0:05:36.320 I was wondering, like, who's going to kind of move 0:05:36.320 --> 0:05:39.800 in this direction first? This is very exciting. So a 0:05:39.800 --> 0:05:43.000 good example of this, um, that I always go to, um, 0:05:43.160 --> 0:05:47.279 I was at Robinhood doing, uh, vulnerability management and, um, 0:05:47.320 --> 0:05:50.320 application security. I was in charge of those two groups 0:05:50.480 --> 0:05:54.910 during log4j2. And so what everyone had to do was 0:05:54.910 --> 0:05:59.070 get their spreadsheets ready and start pulling down manual lists 0:05:59.070 --> 0:06:04.110 and trying to cross-reference where in the actual technical infrastructure 0:06:04.110 --> 0:06:07.190 it is. Okay, which app is that? Okay. Who actually 0:06:07.190 --> 0:06:09.870 owns that app? Who do I actually ping to try 0:06:09.870 --> 0:06:12.470 to go out here and I'm like, what we actually 0:06:12.470 --> 0:06:15.510 need is a single place where this stuff is located 0:06:15.870 --> 0:06:20.110 that actually understands. Is this live right now? Is it 0:06:20.270 --> 0:06:22.349 is it a system that's running, or is it a 0:06:22.350 --> 0:06:25.710 system that we could turn on? Um, what version of 0:06:25.710 --> 0:06:29.469 the actual application or the library is enabled? Right. Because 0:06:29.470 --> 0:06:31.870 it could be that one of the versions is vulnerable 0:06:31.870 --> 0:06:35.070 and one of them isn't. Right. Who's the owner? All 0:06:35.070 --> 0:06:39.030 of these things. So like asset management just being natively 0:06:39.029 --> 0:06:44.670 built into it, understanding ownership, being natively built into it, um, 0:06:45.110 --> 0:06:50.150 just really exciting. So so do you have also like the, 0:06:50.150 --> 0:06:53.580 the business understanding potentially that you could bring in. So 0:06:53.580 --> 0:06:56.940 for example, we're worried about these things because we're in 0:06:56.940 --> 0:07:00.740 this particular industry. We're in this particular country. Um, we 0:07:00.779 --> 0:07:05.380 are particularly concerned about the exfil of particular data because 0:07:05.380 --> 0:07:09.500 we're in defense or something like that. Um, which to 0:07:09.540 --> 0:07:13.420 me is really interesting because it can automatically do what 0:07:13.420 --> 0:07:16.260 we've been trying to do in information security for so 0:07:16.260 --> 0:07:22.540 long is prioritization of Vulns before we're using vulnerability information 0:07:22.540 --> 0:07:25.860 to prioritize vulns. But when we should, what we should 0:07:25.900 --> 0:07:28.980 have been doing is saying no. What are our actual assets? 0:07:29.020 --> 0:07:31.380 What do we actually care about as a business that 0:07:31.380 --> 0:07:33.980 automatically does it for you if you have that context? 0:07:35.660 --> 0:07:40.020 So very good question. And just reiterating about log for J. Yes, 0:07:40.020 --> 0:07:42.700 it usually comes at the worst case being Christmas on 0:07:42.700 --> 0:07:46.380 the on the log for J one. Uh, and um, 0:07:46.420 --> 0:07:49.380 it's a, it's a good example because people mostly didn't 0:07:49.380 --> 0:07:54.720 understand where they're where they look for Jay is actually located, 0:07:54.720 --> 0:07:58.080 like where they use the actual, uh, vulnerable, uh, package 0:07:58.120 --> 0:08:01.400 or the version actually. And whether it's just on the 0:08:01.400 --> 0:08:04.600 code or also in production and all of these different 0:08:04.600 --> 0:08:08.360 things are super, uh, um, complicated when you have to 0:08:08.360 --> 0:08:11.360 do it, um, when you have to do it in, 0:08:11.360 --> 0:08:13.160 you know, in, uh, in a lot of stress and 0:08:13.160 --> 0:08:16.640 you already know that there is an exploit, uh, available 0:08:16.640 --> 0:08:19.440 and people try to exploit. So, so it's super, uh, 0:08:20.000 --> 0:08:21.800 I would say too late in the process. And you 0:08:21.800 --> 0:08:24.920 mentioned another thing which is super important, trying to figure 0:08:24.920 --> 0:08:28.640 out from the cloud, uh, who is the owner. 0:08:29.000 --> 0:08:29.360 Is. 0:08:30.160 --> 0:08:33.360 Good, but it's, it takes too much, like it's too 0:08:33.360 --> 0:08:37.040 much to too long to understand. Who is the owner? Uh, 0:08:37.040 --> 0:08:40.360 you probably the developer already did like several other things 0:08:40.360 --> 0:08:44.400 between now and then. Uh, and it's, uh, it's really 0:08:44.440 --> 0:08:47.040 kind of, if you think about it, you try not 0:08:47.040 --> 0:08:50.400 to block to be able to make the developer velocity, uh, 0:08:50.470 --> 0:08:53.310 very fast, but in the end, because you kind of 0:08:53.350 --> 0:08:56.790 bother him with problems from production, you kind of bring 0:08:56.790 --> 0:09:00.110 him tasks that were not planned originally to be solved. 0:09:00.110 --> 0:09:04.710 So while you try to make the developer velocity, uh, fast, 0:09:04.750 --> 0:09:07.550 you actually make it slower by trying to figure out 0:09:07.550 --> 0:09:11.110 who is the owner. And, uh, owners tend to not 0:09:11.110 --> 0:09:14.030 be that simple of understanding who the one, you know, 0:09:14.070 --> 0:09:16.310 when you see a CV within a package, like, who 0:09:16.309 --> 0:09:20.510 is the one that's that's only the last one that changed. Uh, 0:09:20.790 --> 0:09:23.790 the the fight may change like different version. The one 0:09:23.790 --> 0:09:28.189 that actually added this package into the, into, uh, the code. 0:09:28.190 --> 0:09:30.470 So it can be a lot of different owners. And 0:09:30.510 --> 0:09:33.070 when you are close to the code, it's much easier 0:09:33.070 --> 0:09:34.950 to understand who is the owner because he's the committer 0:09:34.950 --> 0:09:38.230 of the things and he can block things before even 0:09:38.230 --> 0:09:42.590 going into production. Going back to your question about the business, uh, 0:09:42.910 --> 0:09:45.910 impact of things, and also, uh, what we can say 0:09:45.910 --> 0:09:50.489 about the industry or the industry are in. So one. Yes. 0:09:50.730 --> 0:09:53.329 One of the things we always say about SVM is 0:09:53.330 --> 0:09:55.610 the is that it's kind of connect the business with 0:09:55.610 --> 0:09:58.250 the security. If you think about all the evolution of 0:09:58.290 --> 0:10:03.050 the different, uh, SVM stuff, it's always about infrastructure, about network, 0:10:03.090 --> 0:10:07.650 about identity, about data, but application is about actually connecting. 0:10:07.650 --> 0:10:11.610 What the customer knows about is application and the honoring 0:10:11.650 --> 0:10:14.770 the business owner, the criticality of the the business, the 0:10:14.770 --> 0:10:18.810 fact that, for example, I can later understand whether this 0:10:18.809 --> 0:10:24.370 application is, uh, mostly vulnerable, for example, for um, for 0:10:24.370 --> 0:10:28.970 data theft. So probably try to, uh, to harden it 0:10:29.210 --> 0:10:33.170 based on this type of, uh, of, um, of, uh, 0:10:34.170 --> 0:10:36.569 kind of what application is doing versus what are the 0:10:36.570 --> 0:10:40.810 potential of being exploited within. And this is something we're 0:10:40.809 --> 0:10:43.929 also going to add more, uh, in the future and 0:10:43.929 --> 0:10:47.170 trying to understand what is the application inside and allow 0:10:47.170 --> 0:10:50.800 you to bring the relevant guardrails to to help you 0:10:50.840 --> 0:10:54.600 solve this, uh, problem. So, yes, business is a very 0:10:54.600 --> 0:10:57.760 important part. We are going to make sure it's going 0:10:57.760 --> 0:11:00.800 to be very, uh, aligned with what we do on 0:11:00.800 --> 0:11:03.480 the security side. I think application is the first time 0:11:03.840 --> 0:11:07.160 it's actually connects everything. And when we talk about application, 0:11:07.160 --> 0:11:09.720 and this is one of the things which is super, uh, 0:11:10.880 --> 0:11:14.280 exciting about what we are doing, is that while in 0:11:14.280 --> 0:11:17.000 other places you can define application for the code, you 0:11:17.000 --> 0:11:20.640 can define application for the runtime. What we do is 0:11:20.679 --> 0:11:23.040 say we don't care what you where you start to 0:11:23.080 --> 0:11:25.920 build your application. You can start from the runtime. You 0:11:25.920 --> 0:11:29.240 can start from the code. The system will automatically enrich 0:11:29.240 --> 0:11:33.960 everything up for you and actually connect all the relevant 0:11:33.960 --> 0:11:38.400 assets into one, uh, into one application. And you mentioned 0:11:38.679 --> 0:11:43.600 something which is also, uh, important. Um, if you think about, uh, 0:11:44.280 --> 0:11:46.880 whether am I like, for example, you said I want 0:11:47.020 --> 0:11:49.620 to find all, all the places I have, look for, 0:11:50.460 --> 0:11:55.140 look for J. Think about a repository that you didn't scan. 0:11:55.700 --> 0:11:56.100 Yeah. 0:11:56.140 --> 0:11:58.340 So you don't even know if it's if you have 0:11:58.340 --> 0:12:00.860 this problem or not. And one of the things we 0:12:00.860 --> 0:12:03.420 invest in our solution is making sure that you have 0:12:03.420 --> 0:12:06.179 a good visibility of what you are actually doing. Yeah. 0:12:06.220 --> 0:12:08.460 Because if I see a risk and I don't know 0:12:08.500 --> 0:12:11.860 what is the coverage, then the risk may not be correct. 0:12:11.860 --> 0:12:14.580 So it's not it's not the right place to go. 0:12:15.340 --> 0:12:18.020 Yeah. So so for that piece are you talking about 0:12:18.059 --> 0:12:24.740 like continuous discovery. Continuous like, um, monitoring external attack surface 0:12:24.860 --> 0:12:27.819 to just like be aware and then bring that into 0:12:27.820 --> 0:12:30.900 the context into the data lake if it's not already there. 0:12:31.780 --> 0:12:33.740 So it's already it's already there. It's part of the 0:12:33.740 --> 0:12:37.100 solution having the attack surface as well. Um, as I mentioned, 0:12:37.100 --> 0:12:40.980 we kind of brought all these different, all these different models, 0:12:41.020 --> 0:12:45.620 different signals, signals into the same place. And then beside 0:12:45.730 --> 0:12:48.850 providing insight by our self to our customers, we also 0:12:48.850 --> 0:12:52.210 allow the customers to query things they care care about. 0:12:52.210 --> 0:12:54.730 They can kind of do it via the graph, or 0:12:54.730 --> 0:12:57.570 they can do it via like our query language and 0:12:57.570 --> 0:13:00.090 they can query basically everything. You know, one of the 0:13:00.090 --> 0:13:04.010 discussion is that if you think about the amount of 0:13:04.010 --> 0:13:06.610 different things we have within the system, whether it's the 0:13:06.610 --> 0:13:10.530 SOC environment, the Appsec persona, the runtime, the posture management, 0:13:10.770 --> 0:13:13.970 they can create something that will be kind of an 0:13:13.970 --> 0:13:19.330 overlap kind of overlay of everything. The system brings some 0:13:19.330 --> 0:13:22.130 of its own, but it's also open for the for 0:13:22.130 --> 0:13:25.329 everyone that wants to query it. So very exciting. And 0:13:25.330 --> 0:13:28.330 we have a lot of, uh, uh, super cool things 0:13:28.330 --> 0:13:32.130 that are planned as part of our SPM solution. I 0:13:32.130 --> 0:13:35.729 really believe that if we think about the next generation 0:13:35.890 --> 0:13:39.370 application security and how it connects within the cloud and 0:13:39.370 --> 0:13:42.450 the fact that everything is super fast, this is the 0:13:42.450 --> 0:13:46.790 way to go, kind of connect between the things. Bring insights. Um, 0:13:46.950 --> 0:13:49.429 you know, I think, uh, one of the things we 0:13:49.429 --> 0:13:51.630 see is that people don't have, like, they don't want 0:13:51.630 --> 0:13:54.710 to search within, uh, a search engine. They prefer to 0:13:54.710 --> 0:13:58.150 ask a question. Yes. And in my opinion, one of 0:13:58.150 --> 0:13:59.910 the things we are doing on the ASP team is 0:13:59.910 --> 0:14:02.790 trying to give the answers instead of kind of let 0:14:02.790 --> 0:14:06.830 you go into different tables or different places to look 0:14:06.830 --> 0:14:09.750 for your information, but rather give you insights on what 0:14:09.750 --> 0:14:12.270 the things you can do and the recommendation on how 0:14:12.270 --> 0:14:15.590 to prevent it. And you know, in theory, I would 0:14:15.590 --> 0:14:17.830 like to make sure that we have a very good 0:14:17.830 --> 0:14:20.670 prevention in which what you see in cloud was only 0:14:20.670 --> 0:14:23.750 created in cloud and not something that was kind of 0:14:23.790 --> 0:14:24.950 created by code. 0:14:25.390 --> 0:14:30.710 Mhm. Yeah. That's really interesting. So I mean what I 0:14:30.710 --> 0:14:32.910 see kind of happening from this is like you could 0:14:32.910 --> 0:14:37.150 roll this out and suddenly you all of a sudden 0:14:37.150 --> 0:14:40.470 your users are way larger than the security team. Because 0:14:40.470 --> 0:14:44.540 this is so vastly important to the entire company because 0:14:44.580 --> 0:14:47.660 they likely don't have a place, a universal place, to 0:14:47.700 --> 0:14:50.460 go and ask questions. And what you what you're likely 0:14:50.460 --> 0:14:53.220 to end up with, uh, as you know, is like, 0:14:53.260 --> 0:14:56.020 you're going to have the best asset management in the 0:14:56.020 --> 0:14:59.220 company is going to be this tool. So people who 0:14:59.220 --> 0:15:02.140 aren't even thinking security necessarily, they're going to be like, 0:15:02.140 --> 0:15:05.180 I need the current list of this. What's facing the internet? 0:15:05.180 --> 0:15:07.900 Like lots of different users could potentially need this. 0:15:09.300 --> 0:15:12.100 And again, in the context of the business, like, yes, 0:15:12.140 --> 0:15:14.540 these assets that are part of my application, it's not 0:15:14.540 --> 0:15:17.620 just an asset. I can know that this asset is 0:15:17.620 --> 0:15:20.580 part of an application and the application is owned by someone. 0:15:20.580 --> 0:15:22.340 This is the business owner of it. This is the 0:15:22.340 --> 0:15:25.500 one that needs to fix things. Um, we're also talking 0:15:25.500 --> 0:15:28.380 about the option to kind of group things based on applications. 0:15:28.380 --> 0:15:31.700 So you can see that you can see based on 0:15:31.940 --> 0:15:34.380 the permission you have, the application you want to see. 0:15:34.700 --> 0:15:37.340 And all of this is is coming into the context, 0:15:37.380 --> 0:15:39.980 the code context, the cloud context, the things we have 0:15:39.980 --> 0:15:43.080 from the runtime and also the one we give from 0:15:43.120 --> 0:15:47.000 a get from the business application. So yes, you are correct. 0:15:47.040 --> 0:15:50.160 This data lake in a way is our secret for 0:15:50.160 --> 0:15:53.040 this is and the, um, the things we do with 0:15:53.040 --> 0:15:55.840 the data, which is based on AI and the ability 0:15:55.840 --> 0:15:59.320 to actually learn from the data, is what will make 0:15:59.320 --> 0:16:03.360 the what makes the, the the solution, um, to be, uh, 0:16:05.160 --> 0:16:08.680 such an, uh, a potential for, as you mentioned, like 0:16:08.880 --> 0:16:12.720 security people. In the end, they cannot chase, uh, risks. 0:16:12.720 --> 0:16:15.760 They need someone to be able to, uh, fix things 0:16:15.760 --> 0:16:18.880 before they do that. They don't do policies today because 0:16:18.880 --> 0:16:22.840 it's hard. Because it's not because developers tend to, uh, say, no, 0:16:22.840 --> 0:16:25.640 you just blocked us. We cannot bring velocity. We cannot 0:16:25.640 --> 0:16:29.560 bring more, uh, um, application into, you know, more business 0:16:29.560 --> 0:16:32.960 value to our customers. And we want to say no, if, 0:16:33.000 --> 0:16:35.360 you know, if you do it right and you do 0:16:35.360 --> 0:16:38.720 the right guardrails and you will do prevention in mind, 0:16:38.760 --> 0:16:41.510 but in, in a way that you have all the context. 0:16:41.790 --> 0:16:46.190 Then your velocity will be increased and not decreased. 0:16:46.430 --> 0:16:49.190 Yeah, I am really excited about this. So so what 0:16:49.190 --> 0:16:52.910 I've been telling everybody is so, um, customers or whoever 0:16:52.950 --> 0:16:56.310 is asking, they want to know what AI is going 0:16:56.310 --> 0:16:59.270 to do for attackers and what specifically they're going to 0:16:59.310 --> 0:17:02.870 try to build. And what I'm telling everyone is, um, 0:17:02.870 --> 0:17:05.630 that thing that I sent you, that USC thing is 0:17:05.630 --> 0:17:10.350 that attackers are going to build unified context for targets. 0:17:10.950 --> 0:17:12.390 So what they are going to do is they're going 0:17:12.430 --> 0:17:15.230 to send out agents, they're going to find your list 0:17:15.230 --> 0:17:19.270 of employees, they're going to pull all their social media, um, 0:17:19.310 --> 0:17:21.149 they're going to find all your DNS, they're going to 0:17:21.150 --> 0:17:23.310 pull all your domains and your subdomains, and they're going 0:17:23.350 --> 0:17:27.150 to start pulling all those different assets. Um, and then 0:17:27.150 --> 0:17:31.030 they can start interrogating them for open ports and blah, blah, blah. 0:17:31.030 --> 0:17:36.830 So they are essentially building a unified data lake for 0:17:36.830 --> 0:17:40.129 you as the target. And then the next time they 0:17:40.130 --> 0:17:42.450 have a new target, they go and do the exact 0:17:42.450 --> 0:17:45.050 same thing. And then they have agents that say, okay, 0:17:45.090 --> 0:17:47.929 given the context that you have, how do we attack? 0:17:48.690 --> 0:17:52.770 What social engineering campaign do we write? What, uh, you know, exploit, 0:17:52.810 --> 0:17:56.530 do we launch on this application? So my my whole 0:17:56.530 --> 0:18:01.050 thing to everyone is attackers are building this to attack you. 0:18:01.410 --> 0:18:04.890 You need to have a better version for yourself. And 0:18:04.890 --> 0:18:10.010 I just absolutely love. Yeah, I absolutely love that that, 0:18:10.210 --> 0:18:13.250 you know, you have such a prominent company in Palo 0:18:13.250 --> 0:18:16.650 Alto actually doing this and doing this quickly. I thought 0:18:16.650 --> 0:18:18.850 it was going to take much longer. I'm really, really 0:18:18.850 --> 0:18:19.890 happy to hear this. 0:18:20.810 --> 0:18:24.489 Yes. So it's actually already available. Uh, it's already on 0:18:24.490 --> 0:18:28.050 the same platform. Um, which is kind of the data 0:18:28.090 --> 0:18:31.050 lake is there. We're just adding more and more content 0:18:31.090 --> 0:18:35.410 into it. And, um, I really believe that while this 0:18:35.410 --> 0:18:39.510 data lake improves, uh, cloud posture Posterior improves SOC. It 0:18:39.510 --> 0:18:43.869 also improves appsec to be able to really, you know, um, 0:18:43.910 --> 0:18:46.710 make sure you don't get into production and wait for 0:18:46.710 --> 0:18:48.790 a lot of time to kind of get the fix, 0:18:48.790 --> 0:18:51.230 understand who is the person, try to figure out if 0:18:51.230 --> 0:18:54.310 it can fix the issues and deploy back and then, uh, 0:18:54.350 --> 0:18:57.070 you know, do testing and then deploy back, kind of 0:18:57.109 --> 0:19:00.950 shorten this, uh, cycles and making sure that, uh, we 0:19:00.950 --> 0:19:03.669 will provide you with all the information you need to 0:19:03.710 --> 0:19:07.109 remediate stuff, but also make sure you prevent in the 0:19:07.109 --> 0:19:10.630 future similar, uh, similar problems. 0:19:11.190 --> 0:19:14.109 Yeah, it's really powerful. So tell me again, all the 0:19:14.109 --> 0:19:18.629 different controls that we have in the platform. So you 0:19:18.630 --> 0:19:22.550 have the ability to, um, monitor incoming code and like, 0:19:22.990 --> 0:19:26.149 inspect and reject, like, what are the other control points 0:19:26.150 --> 0:19:28.590 that you have based on something that you see in 0:19:28.590 --> 0:19:29.110 the lake? 0:19:29.710 --> 0:19:32.869 Yes. So we have a lot of, uh, different controls. 0:19:32.910 --> 0:19:39.100 We start from the ID like the developer Environment. When 0:19:39.100 --> 0:19:42.580 it writes the code, it can see everything we know 0:19:42.820 --> 0:19:45.980 within that. Of course, it's limited to what is currently editing, 0:19:45.980 --> 0:19:48.580 but this is the first time you will find the 0:19:48.580 --> 0:19:52.060 system and the inputs and the outputs and inputs. The 0:19:52.060 --> 0:19:54.619 second one will be when you try. Well, there is 0:19:54.619 --> 0:19:56.939 another one before the commit, but it's very special to 0:19:56.980 --> 0:20:00.940 specific use cases. Uh, this the second one will be 0:20:00.940 --> 0:20:02.659 when you do the pull request. This will be the 0:20:02.660 --> 0:20:05.859 second one. We can, uh, check and kind of enforce. 0:20:06.260 --> 0:20:08.980 The other one is just monitoring and understanding what it is. 0:20:08.980 --> 0:20:11.859 But you can enforce things when you go into the 0:20:11.859 --> 0:20:15.380 PR and say, I don't want to, uh, do critical 0:20:15.380 --> 0:20:18.500 CVE for, uh, a repo that goes to production. And 0:20:18.500 --> 0:20:20.700 I know this one is, uh, open to the network. 0:20:21.660 --> 0:20:26.300 The third one will be around build. I can do, uh, uh, 0:20:26.660 --> 0:20:28.540 block the builds, put it as a step in the 0:20:28.540 --> 0:20:31.980 CI and have all the context of understanding, uh, on 0:20:31.980 --> 0:20:35.540 what I'm actually blocking. And, of course, you have all 0:20:35.580 --> 0:20:39.650 the different monitoring of having like the periodic scanning on 0:20:39.650 --> 0:20:41.490 a branch and on history. So you have a lot 0:20:41.530 --> 0:20:44.330 of things you can do and get all this information, 0:20:44.930 --> 0:20:47.210 and you also have the option to do some of 0:20:47.210 --> 0:20:49.530 it on the image side of things and even in 0:20:49.530 --> 0:20:52.649 the future. Also for admission control, if you do do 0:20:52.690 --> 0:20:57.850 it for, uh, um, this kind of, uh, of, um, uh, software. 0:20:58.010 --> 0:21:01.530 So we have different options to guard. So put the 0:21:01.530 --> 0:21:06.090 guardrails in place. And as mentioned before, um, we are 0:21:06.850 --> 0:21:09.570 we are we are a great believer in platformization and 0:21:09.570 --> 0:21:13.090 the open the option to actually, uh, pull information from 0:21:13.090 --> 0:21:17.489 different other scanners so we don't limit ourselves to the 0:21:17.490 --> 0:21:20.410 things that come only from our system. We actually collect 0:21:20.410 --> 0:21:23.850 everything we have from the different, um, it can be 0:21:23.850 --> 0:21:28.770 different application security solutions. It can be, uh, different version control. 0:21:28.770 --> 0:21:32.530 It can be different CI, CD systems. We collect everything 0:21:32.530 --> 0:21:37.710 in and uh, provide our enrichment. So it's very important 0:21:37.710 --> 0:21:40.190 for us not, you know, to give the value. Even 0:21:40.190 --> 0:21:43.470 before you use the scanners, make sure that you have 0:21:43.470 --> 0:21:46.909 all the value in the enrichment, the option to create applications, 0:21:47.230 --> 0:21:50.430 all this coverage, things I talked, I talked about and 0:21:51.270 --> 0:21:54.350 give value to our to our customers, I would say 0:21:54.390 --> 0:21:55.390 in minimal time. 0:21:56.070 --> 0:21:59.429 Yeah that's really powerful. And then other components in the 0:21:59.430 --> 0:22:02.150 ecosystem are also adding to the data lake. Right. So 0:22:02.150 --> 0:22:03.590 you also have that richness. 0:22:04.270 --> 0:22:06.390 So uh, so let's start from the beginning. The first 0:22:06.390 --> 0:22:09.710 one will be the code that we bring into, uh, the, 0:22:10.310 --> 0:22:12.949 the lake, the, the code finding. I would say different 0:22:12.950 --> 0:22:16.590 code finding can be open source, first party, uh, code, uh, 0:22:16.590 --> 0:22:21.830 secrets misconfiguration, all of these things APIs. The second one 0:22:21.830 --> 0:22:25.629 will be, uh, everything we bring, uh, from the CI 0:22:25.630 --> 0:22:29.590 CD systems, uh, and the version control like posture management. 0:22:29.630 --> 0:22:32.510 Think about the fact that I see, uh, a secret 0:22:32.550 --> 0:22:36.060 on a version control. It's not, um, it's not protected 0:22:36.060 --> 0:22:41.300 by by, uh, let's say, um, MFA, for example. So 0:22:41.300 --> 0:22:44.700 this also kind of where the, the code goes into 0:22:44.740 --> 0:22:47.580 is also another signal. We have all the, the signals 0:22:47.580 --> 0:22:51.420 of the cortex cloud, as we say, the identity, the data, 0:22:51.460 --> 0:22:55.100 the network, the infrastructure, everything we have, which is part 0:22:55.100 --> 0:22:57.859 of a solution for setup. And then all the things 0:22:57.859 --> 0:23:01.699 we have from our endpoints, from our agents within the 0:23:01.700 --> 0:23:04.100 cloud and all the things we have from the attackers 0:23:04.100 --> 0:23:07.940 perspective for the SOC. So everything you can think of 0:23:07.980 --> 0:23:11.260 in this area is through our to our environment. It's 0:23:11.260 --> 0:23:14.580 a very big data lake with a lot of options 0:23:14.580 --> 0:23:15.500 to do the query. 0:23:15.900 --> 0:23:18.500 That's really powerful. So you can like you can build 0:23:18.500 --> 0:23:22.500 basically an entire program off of constructing a really high 0:23:22.500 --> 0:23:26.940 quality set of questions, and then and then basically have 0:23:26.940 --> 0:23:32.100 the answers to those questions trigger different, uh, pipeline or workflows. 0:23:33.040 --> 0:23:37.960 Exactly. And also kind of, uh, um, lead users to 0:23:38.000 --> 0:23:41.840 improve their security posture by creating the right journey. Because 0:23:41.840 --> 0:23:44.399 we have all these different information, we can kind of 0:23:44.440 --> 0:23:46.760 guide them to say, if you want to do in 0:23:46.760 --> 0:23:51.359 this place, do that one and then, uh, do it, uh, in, 0:23:51.359 --> 0:23:53.040 in kind of a stages of phases. 0:23:53.640 --> 0:23:58.800 Um, well, sorry, this is super, super exciting. I'm going 0:23:58.840 --> 0:24:01.680 to go and actually research a lot more about this. Um, 0:24:01.840 --> 0:24:04.280 and I can't wait to see updates. Where can people 0:24:04.280 --> 0:24:07.119 learn more about the platform and what you're releasing and 0:24:07.119 --> 0:24:08.360 what's already released? 0:24:09.520 --> 0:24:12.919 So our so, uh, everything that we already released is 0:24:12.920 --> 0:24:15.960 in our site. And the second one will be about 0:24:16.000 --> 0:24:19.760 our announcement. Announcement of the new product, uh, going on 0:24:19.800 --> 0:24:22.000 on the 25th July. 0:24:22.560 --> 0:24:26.760 Oh, great. Yeah, we will, uh, look forward to that. And, uh, yeah. 0:24:26.800 --> 0:24:28.080 Anything else you want to add? 0:24:29.560 --> 0:24:31.200 No, I think I just want to say that I'm 0:24:31.200 --> 0:24:34.620 super exciting. As I mentioned, kind of coming back to 0:24:34.660 --> 0:24:37.100 my background, I feel that this is part of my 0:24:37.100 --> 0:24:40.740 mission to make developers and security, like, more friendly to 0:24:40.780 --> 0:24:43.979 each other and kind of make sure the developer doesn't 0:24:43.980 --> 0:24:47.980 see security as something that they need to, uh, something 0:24:47.980 --> 0:24:50.340 they need to do or ignore, but actually have this, 0:24:50.340 --> 0:24:53.180 this as part of their workflow and make sure security 0:24:53.220 --> 0:24:55.700 have all the information to be able to do the 0:24:55.700 --> 0:24:57.140 right security decisions. 0:24:58.220 --> 0:25:00.979 Awesome. Well, I think this will definitely move us in 0:25:01.020 --> 0:25:03.420 that direction. Thanks for your time. 0:25:03.980 --> 0:25:04.900 Thank you very much. 0:25:07.380 --> 0:25:10.980 Unsupervised learning is produced on Hindenburg Pro using an SM 0:25:10.980 --> 0:25:14.540 seven B microphone. A video version of the podcast is 0:25:14.540 --> 0:25:18.300 available on the Unsupervised Learning YouTube channel, and the text 0:25:18.300 --> 0:25:23.740 version with full links and notes is available at Amazon.com newsletter. 0:25:24.380 --> 0:25:25.379 We'll see you next time.