[00:00.000 --> 00:02.340] Thank you for attending, uh, this talk. [00:02.460 --> 00:08.120] Excited to talk to you about, um, something new as it, uh, relates to defensive security. [00:08.620 --> 00:10.520] Um, first a little bit about myself. [00:10.760 --> 00:14.940] So I've been an engineer for a long time, uh, worked for a lot of different companies. [00:14.940 --> 00:23.780] Uh, more recently, a lot of cyber vendors, the, the ones that, that sell to large enterprise organizations like banks and those types of things. [00:23.940 --> 00:28.160] So yes, I have been a, uh, kind of a slimy vendor for a long time, I guess. [00:28.340 --> 00:35.000] But, uh, working as an engineer, within those ranks, um, and then more recently, uh, developing products. [00:35.220 --> 00:50.040] And so, this talk is really about my journey over the past, I don't know, decade plus in, in that area of building cyber security products that defend our infrastructure and the types of attacks that have been seen there. [00:50.660 --> 00:55.720] Um, and the new things that we can do, uh, to, to defend our data. [00:55.920 --> 00:59.380] Uh, because I don't know if you guys saw the history of leaks talk. [00:59.900 --> 01:01.980] or, uh, or, uh, have, have been to any of these. [01:02.080 --> 01:05.680] I mean, there's just so much leaked data out in the world today. [01:05.840 --> 01:08.520] And it's, we've become complacent to that. [01:08.840 --> 01:20.980] And, um, one of our, one of my personal missions is to stop that, uh, that, and the way to do it is, is you have to do it with a foundational change in how we're protecting our infrastructure. [01:22.040 --> 01:30.640] Um, recently is, I mean, over the past few years, some of the work I've done has been around, uh, one company, we were unblocking ads through a CDN. [01:30.820 --> 01:38.480] So rewriting the third-party URLs to first party URLs and making those pop through, even if you had an ad blocker turned on to collect that revenue. [01:38.480 --> 01:42.380] I know that's, that's pretty bad, but it's, it's an interesting technical challenge. [01:42.760 --> 01:52.900] Um, and so, uh, after that, uh, went to work for a company called Shape Security, where we, I was an early engineer in Silicon Valley, where we pioneered bot defense. [01:52.900 --> 02:01.040] Um, and, um, I got to come up with the, the signals that we use to detect automation. [02:01.160 --> 02:07.740] So when someone's scripting a site, and, and so back in 2013, 2014, there was a lot of low hanging fruit. [02:07.740 --> 02:12.680] It was easy to write a curl script that could go out and scrape a bunch of data because there was really no protection then. [02:12.820 --> 02:16.520] Uh, but now there are many different products that do that. [02:16.780 --> 02:21.540] Um, and if it, bot defense is really about raising the bar for attackers. [02:21.540 --> 02:31.020] Um, uh, you know, like I said, there was a lot of low hanging fruit, but now it's about sophistication and how sophisticated can you get with the scripts that you write? [02:31.020 --> 02:32.100] Is it a headless browser? [02:32.260 --> 02:33.060] Is it a real browser? [02:33.400 --> 02:35.020] And how advanced can you do that? [02:35.180 --> 02:36.460] Or, well, can you do that? [02:36.920 --> 02:41.600] Um, did some work with card skimmers, uh, digital card skimmers, if you heard of Magecart. [02:41.880 --> 02:51.520] Um, uh, it's, it's really a supply chain vulnerability where, you know, uh, attackers will, uh, go into a third-party JavaScript and, uh, inject a card. [02:51.520 --> 02:56.920] A card skimmer somehow and that pops its way through sites like British Airways or Macy's and those types of sites. [02:57.200 --> 03:05.420] So, um, been on the forefront of all these things, very passionate about network signals and signals that can be generated through a web browser. [03:06.100 --> 03:08.720] So, what we're going to talk about today is modern day defenses. [03:08.900 --> 03:13.440] I'm going to take you on a journey and, uh, I'm going to try to relay a lot of information here to you. [03:13.440 --> 03:14.900] So, uh, be prepared. [03:15.080 --> 03:16.340] It's, it's, it's pretty dense. [03:16.980 --> 03:25.840] Um, so today we have, uh, security solutions that follow architectural patterns that we've had for roughly the past 20 plus years. [03:25.840 --> 03:33.520] Where, you know, there's a perimeter and you've got something sitting there in front of it and that blocks or deflects the noise coming in. [03:33.520 --> 03:38.020] And usually that's signature based and it's, it's, is it a sequel injection attack? [03:38.200 --> 03:45.600] Is it, um, you know, you've got this massive list of signatures that you're feeding to a WAF or some other solution. [03:45.760 --> 03:51.880] Even API security now, which is really kind of like a WAF, um, um, that you're having to manage. [03:51.880 --> 03:56.860] And then there's a ton of false positives and it's, it's no wonder we've, we've got so many leaks today. [03:57.160 --> 04:07.340] Because, uh, what we have defending the front door is usually only, um, deflecting a percentage of the attacks coming in and a percentage of the noise. [04:08.020 --> 04:10.820] And those solutions can be easily bypassed as well. [04:10.960 --> 04:21.060] So, some of the, uh, exfiltration use cases that we're going to cover today are around, um, bypassing perimeter security and how, how that works. [04:21.060 --> 04:27.660] Uh, lateral movements and once you get inside, you scan some targets and you exfiltrate data through internal APIs. [04:27.980 --> 04:36.500] And then unknown leakage where developers, maybe a developer you had on staff five years ago has published something that's now vulnerable and you don't really know about it and it's leaking data. [04:36.680 --> 04:48.440] And so, really the governance and the observability around this problem is, is what we're trying to tackle, uh, at LeakSignal, um, the startup that, that I created roughly two years ago. [04:49.220 --> 05:02.660] So, it all starts with HTTP, uh, whether it's HTTP 1, 2, or 3, uh, we're still dealing with that same constraint of data as it's sent across the Internet, uh, or internally across our networks. [05:03.020 --> 05:06.420] Um, it is how information is sent, it is how sensitive data is sent. [05:06.900 --> 05:15.380] Um, there are other protocols that kind of exist in the long tail of protocols, but majority of the data does come through HTTP along with the attacks. [05:15.380 --> 05:28.100] So, uh, when an attacker wants to send something in and, uh, manipulate the backend system somehow, they'll do it through headers or through the body or through, through some, uh, mechanism in the HTTP protocol. [05:28.100 --> 05:37.920] Um, so, when we deploy an application that accepts this protocol, HTTP, um, it doesn't have, it's naked, right? [05:38.020 --> 05:46.440] You, you, you put something in production, you do the best you can do as a developer to write this most, the, the most secure code. [05:46.620 --> 05:51.900] Um, and, and we put that in production and that is what we have. [05:51.900 --> 05:58.000] And so, with that, you have to bolt on these different tools to gain observability and, and security. [05:58.360 --> 06:06.060] And so, when you're, as a developer, you publish this code or you publish your containers or into a, you, uh, deploy a virtual machine. [06:06.540 --> 06:09.840] From there, it's really the security team's job to handle that, right? [06:09.980 --> 06:13.400] And so, that's what we're going to be talking about today is that disconnect. [06:13.560 --> 06:17.700] When code goes to production, how do we, how do we govern it? [06:17.700 --> 06:21.480] How do we observe the data flows that are happening within that environment? [06:22.720 --> 06:28.100] So, a lot of the bolt-ons that we have today dealing with inline network traffic. [06:28.100 --> 06:35.760] I'm not talking about a bolt-on that goes into your sim or something that, that you deploy in a, in kind of a passive mode. [06:35.760 --> 06:46.040] I'm talking about inline, uh, with network traffic that can see what's going on with the traffic, that can mitigate those attacks or those, the, the, the things that are coming into our environment. [06:46.040 --> 06:51.600] Most of the time, we're dealing with a new scaler. [06:51.780 --> 06:55.480] Um, and it's a lot like dealing with a car with its hood welded shut. [06:55.700 --> 06:57.160] It's, it's closed source, right? [06:57.180 --> 06:58.080] It's a black box. [06:58.180 --> 06:58.940] We don't know what's in it. [06:59.080 --> 07:09.500] We pay the vendor millions of dollars a year, and they protect our environment with, by sending our telemetry to their cloud environment, where that could potentially get breached as well. [07:09.660 --> 07:16.460] So, it's, it's, we really don't, security is really not on-prem with us, and, and we manage that by ourselves. [07:16.460 --> 07:19.220] It's usually done through a vendor through some type of managed service. [07:19.480 --> 07:24.780] Um, and, and some large organizations do manage it themselves, but it's through the tool. [07:24.900 --> 07:25.960] It's through the closed tool. [07:26.300 --> 07:30.560] And so, we're going to talk, or, or we're talking about data flows. [07:30.740 --> 07:35.860] And here, in, in this picture here, we're mainly representing the web data flow. [07:35.940 --> 07:37.100] And sorry for the contrast here. [07:37.140 --> 07:37.660] I didn't realize. [07:38.020 --> 07:47.800] Um, but the, the, the data flow that's occurring is where a user enters data into the web browser, and that data gets submitted to a server and then gets stored in a database. [07:48.140 --> 07:49.700] That is an end-to-end data flow. [07:49.980 --> 07:50.420] Okay. [07:50.820 --> 07:53.260] In production, we have four data flows. [07:53.480 --> 07:57.960] We have that web data flow that goes, stores data in databases. [07:57.960 --> 08:01.000] We have the egress data flow that's going out. [08:01.260 --> 08:04.200] So, developers make a call to a third-party, right? [08:04.460 --> 08:07.400] And, uh, that application, you know, what's this deployed in production? [08:07.520 --> 08:08.420] It's doing its own thing. [08:08.740 --> 08:10.620] Uh, it's, it's a black box to us. [08:10.620 --> 08:15.660] Um, and so, developers have, have written the logic to make third-party calls out. [08:15.860 --> 08:19.480] We don't really know what sensitive data we're sending out with that third-party call. [08:19.860 --> 08:29.320] Um, and then, at the bottom here, logging and, and logging, accidentally logging sensitive data, or accidentally, uh, doing things with logs, right? [08:29.440 --> 08:35.160] So, you've got, uh, these four data flows that an application, these connections that an application makes. [08:35.160 --> 08:41.840] And that's what, um, what I'm focused on today is, is really understanding that and governing those flows. [08:43.160 --> 08:45.980] So, in, just to summarize here, overview. [08:46.680 --> 08:52.580] End-to-end production security is, and, and this, this box on the top right is, is condensed, right? [08:52.660 --> 08:54.460] There's a lot in supply chain security. [08:54.740 --> 09:00.240] But it, if you, if you go all the way back to the beginning, developer rights code, it gets scanned a lot. [09:00.240 --> 09:02.700] It gets security tested, it gets deployed in staging. [09:03.140 --> 09:17.720] That then goes to production, where we've got a security product that has, uh, you know, you may have a runtime security product that sits in that container, or that virtual machine, and then you also have that WAF and API security. [09:17.840 --> 09:28.080] So, there's a lot of hops that happen in between your deploy production app, and the products that are analyzing traffic, uh, before it gets there, and then even after it gets there. [09:30.200 --> 09:37.460] So, with all that said, you have a, only a handful of signals to determine what bad traffic is today. [09:37.780 --> 09:43.380] You've got request headers, and the, and, and the body, maybe a little bit of the body. [09:43.800 --> 09:52.460] Uh, the problem is that, uh, most WAFs and security products only look at the headers, and they may look at a few kilobytes of the body. [09:52.640 --> 09:54.260] Uh, but outside of that, that's it. [09:54.260 --> 10:04.720] That's, that's the only, and, and everything that you can look at in that, it's, it's usually a custom rule or a custom regex that has to be written to kind of do what you want it to do. [10:04.960 --> 10:08.160] So, it's already very, very rigid and frail. [10:08.920 --> 10:15.880] Um, the, one of the more, uh, solid things that, uh, signals that we lean on is IP threat and reputation feeds. [10:15.880 --> 10:17.480] So, is this IP bad? [10:17.940 --> 10:20.100] Uh, you know, what's the reputation of it? [10:20.180 --> 10:22.580] What's, what's the geography, what's the geolocation of it? [10:23.180 --> 10:26.000] And, and so those are kind of the three things that we have. [10:26.160 --> 10:28.720] But there is one more, and that's what I'm presenting here today. [10:29.220 --> 10:32.880] So, we're going to take a step back and look at why we're in this situation. [10:32.920 --> 10:43.260] Because unless you're in this day-to-day, you really don't take a step back and say, why do I only have these three signals, uh, to deal with to block bad traffic? [10:43.920 --> 10:50.160] And so, I'm going to do a, a, a quick run-through of the cyber product ecosystem here. [10:50.340 --> 10:59.500] So, cyber security products, defensive products, are usually driven by some type of standard or some type of governance body. [10:59.860 --> 11:04.040] If you handle credit card data, it's, it, you have to be PCI DSS compliant. [11:04.040 --> 11:10.340] Uh, there's 13, um, uh, kind of pillars of, of PCI DSS. [11:10.860 --> 11:18.720] And, um, understanding where the data's going, tokenizing credit card data, um, checking for card skimmers. [11:18.940 --> 11:21.200] Like, there's all these new things that are just now coming out. [11:21.860 --> 11:23.420] Um, OWASP is another one. [11:23.640 --> 11:26.280] Uh, we were talking about the OWASP top 10 in the last talk. [11:26.620 --> 11:28.680] Uh, I'm going to drill in on that in just a minute. [11:29.160 --> 11:31.920] Uh, NIST is, is, is the Department of Commerce. [11:31.920 --> 11:39.600] Um, they keep track of a lot of our CVEs and NVDs, but they also have a lot of zero trust recommendations and those types of things. [11:39.820 --> 11:42.800] And then the GDPR, they all kind of say the same thing though. [11:42.900 --> 11:52.000] It's, it's, uh, you know, make sure you're doing continuous monitoring, um, do segmentation, um, you know, have a SIM, log everything. [11:52.620 --> 11:57.140] And so I've kind of outlined that list here of what the top recommendations are. [11:57.320 --> 12:04.900] Um, and this is what, if you work on a security team or if you own a security team in a large organization, this is kind of what you have to deal with. [12:05.000 --> 12:05.200] Right? [12:05.300 --> 12:17.680] It's a, it's called a CISO or chief information security officer or a security lead or, or, you know, if you're, if you inherit infrastructure, you're, you're looking at these things and you're understanding them. [12:17.680 --> 12:23.780] Um, and that's what, you know, and that's, this is what drives a lot of the cybersecurity products that we have today. [12:24.700 --> 12:28.980] Another thing that drives cyber products are, is the OWASP top 10. [12:29.180 --> 12:31.440] And I'm not a huge fan of the OWASP top 10. [12:31.600 --> 12:32.520] Yes, it is needed. [12:33.000 --> 12:36.940] Um, there are things in there that's needed and there's, there's great people that work on this project. [12:37.000 --> 12:38.620] And I'm not saying anything bad about it. [12:38.960 --> 12:44.180] I just don't like the way that, that some of these things are formulated. [12:44.180 --> 12:51.560] And from what I hear, they are taking steps to fix, um, a lot of the things that are wrong within OWASP. [12:51.680 --> 12:53.620] But this is an example here. [12:53.760 --> 13:09.280] So if you go and look at who the top 10, who, who the contribute contributors are to the OWASP API security top 10, you're going to see the names of mostly CEOs of startups and vendors in that list. [13:09.280 --> 13:16.200] Um, it's, it's not a bad thing per se, but it's, it's a very controlled ecosystem. [13:16.200 --> 13:18.300] It kind of has a little bit of an odor to it. [13:18.400 --> 13:18.520] Right. [13:18.920 --> 13:23.320] And, and, and we don't, most people don't know that. [13:23.440 --> 13:23.540] Right. [13:23.620 --> 13:30.620] And it's, uh, organizations spend a lot of training budget to train their staff on the OWASP top 10. [13:32.360 --> 13:38.240] And what this is, what this says is it's basically controlled by the vendors. [13:38.240 --> 13:41.420] What we're using in production today is controlled by the vendors. [13:41.940 --> 13:51.800] And it's, as I've kind of created this startup called Leaked Signal over the past couple of years, I've come up in this environment and have said, you know, is it really this way? [13:51.800 --> 14:02.980] Like, uh, there's no other input from anyone else, but you know, this is, this is the community that's driving these top 10 lists and API security. [14:03.320 --> 14:06.200] You know, I talked a bit about WAFs talking about API security. [14:06.560 --> 14:14.500] It's a lot like a WAF and most of them are just doing some type of network tap where they're analyzing traffic and trying to tell you what's wrong. [14:14.540 --> 14:16.260] And that's, that's pretty much it. [14:16.260 --> 14:28.620] Another one is supply chain security where, you know, you've got your source code, you do your commit, you do some type of static code analysis, you do your security testing, and you deploy these things to production. [14:29.000 --> 14:38.400] Well, another OWASP top 10 around the same topic, supply chain security, CICD security, um, was driven by a company called CIDR Security. [14:38.560 --> 14:41.860] And they were recently acquired by Palo Alto Networks for $300 million. [14:42.640 --> 14:49.500] The majority of the people who approved this OWASP top 10 list were either an advisor or an investor of CIDR Security. [14:50.280 --> 14:53.820] So again, we're talking about the OWASP top 10 here. [14:54.240 --> 15:06.640] It's, it's kind of, um, uh, something just really, it, in 2021, 2022, it was easy to get, uh, I guess your company acquired. [15:06.640 --> 15:09.720] If you could hurry up, come up with an idea, put it in the top 10. [15:09.720 --> 15:12.080] It's kind of like AI too, like there's an AI top 10. [15:12.220 --> 15:12.600] There's all the... [15:12.600 --> 15:21.000] So everybody kind of scrambles as a, as a startup or a vendor to get in there, to write these lists, and then to maybe have a good exit. [15:23.000 --> 15:26.140] So we're going to take that with a grain of salt, right? [15:26.300 --> 15:31.440] And we're going to, we're going to come up with a completely new approach to defensive cybersecurity. [15:31.440 --> 15:35.240] And that's, that's what we set out to do at LeakSignal. [15:35.320 --> 15:37.920] And that's what I'm going to show you here in the next couple of slides. [15:39.340 --> 15:40.500] So back to the fight. [15:40.760 --> 15:48.980] So if we talk about how folks are bypassing the products that we're using today, um, they have a few different options. [15:49.120 --> 15:50.160] You've got a lot of tools. [15:50.380 --> 15:56.880] When you're exposed to the Internet, when you're, when you write an API or you put something in production and it's exposed, right? [15:56.880 --> 16:05.340] You've got all, especially today, there's so many different tools that can be used to bypass whatever security you've got in front of your API. [16:05.680 --> 16:10.120] Um, and there's websites that tell you exactly how to do it. [16:10.240 --> 16:13.860] And, uh, every vendor is listed in most of these sites. [16:14.000 --> 16:23.200] So usually the, the WAF or the, the solution is bypassed by encoding the request with certain characters or doing some other type of malicious behavior. [16:24.020 --> 16:26.940] The zero-day community has it pretty easy these days. [16:27.260 --> 16:33.180] Um, so you basically send in a request with a, with a malicious, uh, string. [16:33.500 --> 16:36.600] Here we've got, we're cat on /etc/passwd. [16:37.160 --> 16:44.820] Um, and that just by sending in this very simple request, you can root a device. [16:45.000 --> 16:48.320] You can, it's an article called an RCE or remote command execution. [16:48.320 --> 16:54.440] Um, very easy to do with a lot of the, the, the devices that we have installed today. [16:54.860 --> 16:56.960] Like, for example, Palo Alto networks. [16:57.120 --> 17:03.140] If you heard of Avanti, the, the VPN thing that recently happened, um, move it was a massive one. [17:03.280 --> 17:06.960] You were talking millions of records that were leaked because of these products, right? [17:07.140 --> 17:12.700] Cisco, Citrix, they, all these products are within our infrastructure. [17:13.120 --> 17:17.520] And they all have these zero-day vulnerabilities where you can basically go in. [17:17.600 --> 17:19.660] That's why so many leaks are happening today. [17:20.080 --> 17:26.680] If, if you've been watching the news and you see every week, you know, AT&T was today, I think, uh, or yesterday. [17:27.340 --> 17:34.340] Um, there's just so much going on where these, uh, products are embedded in the DNA of our infrastructure. [17:34.420 --> 17:36.220] And, and so it's hard to rip them out. [17:36.300 --> 17:37.120] You can't just rip them out. [17:37.200 --> 17:38.040] You can't just update them. [17:38.040 --> 17:50.080] Um, however, uh, just this week, Cisco and the FBI is basically telling these vendors to go in and make sure you do input sanitization. [17:50.300 --> 17:57.680] So when, when you receive a request, you sanitize the input and make sure that it's not causing an RCE. [17:58.000 --> 18:00.460] This is a huge problem across the industry. [18:00.620 --> 18:05.540] All of these exploits that are happening, all the data leaks that are happening, that's why we've become so complacent. [18:05.540 --> 18:14.120] And it's really nothing for us to hear that AT&T just, just leaked everybody's cell phone and text records, um, this week. [18:14.320 --> 18:16.360] Uh, so it's like a hundred million. [18:16.600 --> 18:22.840] Um, so again, we're just kind of sitting back and taking this and there is a way to stop it. [18:22.960 --> 18:23.940] There is, there is a way. [18:24.320 --> 18:26.680] So lastly is social engineering. [18:27.360 --> 18:29.220] Um, LastPass was, was breached. [18:29.400 --> 18:34.400] So the, the one, one of the products that a lot of people used, uh, for their passwords was breached. [18:34.400 --> 18:39.780] Um, because a senior engineer was targeted and installed some malware. [18:39.960 --> 18:40.360] All right. [18:40.460 --> 18:44.080] So a lot of different ways to get in and exfiltrate data. [18:44.100 --> 18:46.200] Um, and these are pretty much all the ways. [18:47.760 --> 18:49.460] So identifying the blind spots. [18:49.620 --> 18:51.380] That's the title of this talk. [18:51.560 --> 18:54.440] And, and when we do that, we look at the products we have. [18:54.540 --> 18:55.960] We look at the vendors we're dealing with. [18:56.140 --> 18:57.760] The, the hoods that are welded shut. [18:58.040 --> 19:01.140] Um, all these things that are protecting our infrastructure. [19:01.140 --> 19:03.500] Um, and these are their blind spots. [19:03.720 --> 19:06.980] They, they, they can't fully analyze the request. [19:07.300 --> 19:11.640] Nor do they look at this big yellow mark at the bottom, the response bodies. [19:11.900 --> 19:15.160] And what data is being sent out of an environment. [19:15.420 --> 19:21.000] And that's what we stepped up at LeakSignal to solve in an openly distributed and open-source way. [19:21.000 --> 19:28.200] Is not only to fix the problems with how the ecosystem is today. [19:28.500 --> 19:36.200] But to give anyone, uh, the ability to natively do data classification. [19:36.640 --> 19:39.060] Across both the request and the response. [19:39.840 --> 19:43.200] So today we've got incoming signatures. [19:43.200 --> 19:49.180] Uh, or we, we use signatures to determine if, if incoming traffic is, is bad. [19:49.380 --> 19:49.620] Right? [19:50.140 --> 19:52.220] And that's not working very well. [19:52.800 --> 19:56.680] On top of that, we've got this new architecture with Kubernetes. [19:56.940 --> 19:59.460] That's been happening for the past 10 years called microservices. [19:59.880 --> 20:03.920] And so you take what was built for the old monolith architecture. [20:03.920 --> 20:10.920] And you apply that to the new Kubernetes multi-cloud kind of, uh, serverless architectures. [20:11.740 --> 20:15.380] Um, you've just got to rest, more of a disaster on your hands. [20:15.480 --> 20:15.660] Right? [20:15.740 --> 20:17.800] It's, it's just not going, it's not working now. [20:17.860 --> 20:21.300] It's not going to work when we have newer and better architectures. [20:21.800 --> 20:25.700] So, like I was saying over the past year, this was okay in 2014. [20:26.100 --> 20:27.960] You could, you could get away with the perimeter security. [20:28.620 --> 20:30.640] Um, 2019 things started to grow. [20:30.840 --> 20:33.760] A lot of new categories came out through Gartner. [20:33.760 --> 20:39.000] Uh, in different areas to kind of just patch the holes that, that existed. [20:39.300 --> 20:44.860] Um, one of those was, was scanning our AWS environments for, uh, vulnerabilities. [20:45.240 --> 20:47.020] But that's on the, more on the supply chain side. [20:47.300 --> 20:49.060] But now we get into 2024. [20:49.720 --> 20:54.160] And when we started Leaked Signal, we interviewed a ton of companies. [20:54.320 --> 20:55.780] A ton of large enterprise companies. [20:56.400 --> 21:04.000] Um, everybody has kind of this visibility problem of being able to understand and monitor the data that's leaving their environment. [21:04.540 --> 21:04.980] Okay. [21:05.260 --> 21:09.100] And also coming into it now with LLMs and prompts and whatnot. [21:09.820 --> 21:15.160] So I'm very quickly going to review this microservice architecture and then we'll, we'll jump into the meat of this. [21:15.460 --> 21:18.540] Um, so on the left, we've got monolithic architectures. [21:18.660 --> 21:20.780] That's what we've been dealing with for the past 25 years. [21:20.780 --> 21:28.100] The new microservice architectures have multiple services broken up across clouds or across environments. [21:28.440 --> 21:32.540] Um, and that, that allows the businesses to move faster. [21:32.760 --> 21:38.900] That allows, uh, faster, um, you know, speed of business, more revenue, et cetera. [21:39.180 --> 21:42.960] So microservices are, are, are here and, and it's just going to grow. [21:43.240 --> 21:47.800] And, and code and, and deployments are just going to be more and more scattered across cloud environments. [21:48.460 --> 21:51.060] But there is hope in this architecture. [21:51.420 --> 21:56.460] Um, you know, on the left here, this is kind of what we're dealing with, with the old monoliths, right? [21:56.560 --> 21:59.060] Where you've got all these data flows going all different directions. [21:59.380 --> 22:01.680] With microservices, uh, [22:06.020 --> 22:12.240] all of these data flows within what's called a proxy or sidecar proxy or waypoint proxy. [22:12.240 --> 22:20.200] Um, the, the architecture of this, of this new way of, of microservices has that natively. [22:20.320 --> 22:26.400] And so what we can do is capture that to start classifying data in transit, okay? [22:26.440 --> 22:33.960] This is the new concept of class of classification of sensitive data in transit to determine if something bad is happening. [22:34.920 --> 22:36.180] And we'll get into that. [22:36.320 --> 22:39.180] I just want to, again, distill some of this for you. [22:39.180 --> 22:46.280] So in this complex diagram here, Envoy is the proxy that sits in front of all these services, right? [22:46.420 --> 22:54.500] Because we couldn't do this previously where you could say, okay, holistically, I'm, I'm going to protect all of my infrastructure. [22:54.900 --> 23:00.340] Um, and, and do that with Palo Alto networks or, or Zscaler or something. [23:00.900 --> 23:03.320] Um, they don't go into this environment. [23:03.320 --> 23:14.160] I mean, they, they try to retrofit their products into it, but they don't go into it natively and, and capture, um, the, the essence of, of being able to do this in line with network traffic. [23:14.160 --> 23:21.360] So with Envoy, you can basically tap into this proxy, and you can do really cool things. [23:21.560 --> 23:24.720] Um, it has this thing called, called a WebAssembly virtual machine. [23:25.080 --> 23:32.620] And you can write, uh, uh, with Rust, um, you can write a WebAssembly, uh, something that compiles to WebAssembly. [23:33.260 --> 23:38.960] And it's, uh, roughly two, three megabytes that you can deploy into all of these proxies. [23:39.140 --> 23:45.060] So, some of the, the organizations we deal with have thousands, if not tens of thousands of services. [23:45.320 --> 23:48.000] So how do you protect all 10,000 at scale? [23:48.620 --> 23:49.900] Well, this is the way. [23:50.080 --> 23:50.840] You do it with WebAssembly. [23:51.500 --> 23:55.980] And you do it natively within the proxy that sits in front of all those services. [23:55.980 --> 24:04.180] So you're actually, you have 10,000, you know, WebAssembly modules deployed across all these services that are now mapping what's called data flows. [24:04.180 --> 24:10.300] And having the ability to classify sensitive data as it transits an environment. [24:10.300 --> 24:17.020] And, and to get complete observability on where sensitive data going, is going, and how much of it is being accessed. [24:17.860 --> 24:29.600] So this is a very small example of roughly 11 services that, that are managing and, and that kind of map out the, the flow of data as it's happening. [24:29.740 --> 24:34.760] So you can basically say, I want to see all credit card numbers, uh, and which services handle those. [24:34.880 --> 24:38.200] And you, you get that instantly through in transit classification. [24:38.720 --> 24:42.200] Or I want to see which services are handling customer data, or et cetera. [24:42.200 --> 24:50.280] So, by looking at the data when it's leaving a service, you now know exactly what that service does. [24:50.440 --> 24:51.780] And what type of data it handles. [24:52.020 --> 24:55.180] That is visibility that we don't have today in, in most environments. [24:56.240 --> 25:04.800] And so, the way we do that is we, instead of just looking at the request and the headers, and, and trying to see what the IP address is. [25:04.800 --> 25:05.700] Is it good or bad? [25:05.700 --> 25:12.280] We're going to classify the first name, the email address, the credit card number, and the response. [25:12.520 --> 25:19.340] We're going to look at every single request and response that goes across the wire and classify the data in the, in that. [25:20.200 --> 25:27.160] To understand, you know, if this service emits 10,000 credit cards a day, is it distributed? [25:27.340 --> 25:28.760] Is it all in one big spike? [25:29.000 --> 25:30.780] Is that someone hacking in? [25:30.820 --> 25:33.720] Or is that some type of ETL or, or batch download? [25:34.740 --> 25:42.160] So, understanding how our services are emitting data, and do they stick with the typical ebb and flow of traffic? [25:42.420 --> 25:49.700] Because when I talk about ebb and flow of traffic, you know, users log on in the morning, and then that, that traffic slowly ebbs up. [25:49.840 --> 25:51.580] And then it goes down in the afternoon. [25:51.980 --> 25:53.720] That's typical Internet traffic. [25:54.360 --> 26:00.580] When you don't see that, it's either meant to be that way, because it's some type of internal system. [26:00.580 --> 26:02.420] Or you've got a problem. [26:02.620 --> 26:05.960] And you've got, you know, a lot of malicious activity going on. [26:06.300 --> 26:15.740] So, the only way to determine that is by looking at the, instead of looking for signals of a, and guessing, is this a SQL injection attack? [26:16.140 --> 26:22.520] By classifying sensitive data on the response, you're going to know it's a SQL injection attack. [26:22.520 --> 26:26.720] Because you're going to see a massive dump of data in one big spike. [26:27.340 --> 26:28.960] So, this is an example. [26:29.440 --> 26:32.200] And so, LeakSignal is, like I was saying, openly distributed. [26:32.200 --> 26:33.160] We're open-source. [26:33.160 --> 26:40.540] And what we tried to do is basically write a WebAssembly module that you could plug into a service mesh or any environment. [26:40.700 --> 26:43.740] And emit that data to Prometheus and Grafana. [26:45.040 --> 26:46.820] Completely disconnected from any vendor. [26:47.020 --> 26:50.900] So, you don't have to send your data out to a cloud environment. [26:51.020 --> 26:51.940] You don't have to do anything. [26:52.520 --> 26:56.400] This is purely just a gain observability of sensitive data. [26:56.400 --> 26:59.340] And this is, absolutely, you cannot see this. [26:59.500 --> 27:02.160] This is, so there's dots here. [27:06.600 --> 27:07.540] A few dots you can see. [27:08.660 --> 27:11.180] Those are sensitive data emission. [27:11.200 --> 27:13.540] And I'm going to demo this for you a little bit better. [27:13.640 --> 27:14.960] So, this is what it looks like. [27:15.880 --> 27:23.960] So, when I load this page in the middle with all the fake social security numbers and credit card numbers, you get these little blips in Grafana here. [27:24.180 --> 27:27.740] So, we can see that we've got 10 matches in purple at the top. [27:27.740 --> 27:29.780] Those are bank routing numbers. [27:30.000 --> 27:38.780] And so, if you could see, when you're running a production environment, you can see the flow of sensitive data going out of it. [27:38.920 --> 27:40.940] You're going to be able to see a lot more. [27:41.100 --> 27:43.400] In terms of, number one, data governance. [27:44.220 --> 27:49.040] What, you know, why do we have this massive spike of customer data leaving our environment? [27:50.060 --> 27:54.220] Or, why is this person accessing data in this way? [27:54.400 --> 27:55.780] Here's another example. [27:55.780 --> 27:59.080] So, let's say you get a token, right? [27:59.200 --> 28:04.160] Everybody gets a token when they log in through Okta or any identity provider on the request. [28:04.400 --> 28:06.800] That token is then used to access an API. [28:07.980 --> 28:09.320] What did that API do? [28:09.520 --> 28:14.480] Because right now, identity and access management stops at the API, right? [28:14.720 --> 28:15.640] Did they log in? [28:15.820 --> 28:17.120] Did they MFA? [28:17.380 --> 28:18.320] Okay, they're good. [28:18.600 --> 28:20.380] Now they can access whatever data they want. [28:20.380 --> 28:26.740] Well, now, with this approach, you can map that token to the sensitive data it accessed. [28:26.980 --> 28:35.220] So, you can have very granular visibility into, hey, did one token access 50 distinct customer records? [28:36.580 --> 28:38.260] Can we answer that question today? [28:38.660 --> 28:40.040] Most of the time, the answer is no. [28:40.040 --> 28:49.720] And that's what we are trying to allow the entire world to answer is, you know, how is data accessed? [28:49.860 --> 28:50.580] What's the behavior? [28:50.820 --> 28:55.340] And do we have a vulnerability in our system where a single token can... [28:55.340 --> 28:58.080] Or do you even need a token to access this data? [28:58.740 --> 29:02.340] Are we allowing data be accessed without any authentication? [29:02.340 --> 29:06.920] That's another question that many organizations cannot answer. [29:07.160 --> 29:08.560] So, it's the correlation. [29:08.700 --> 29:14.900] It's that tiny little compute environment that sits in front of the service where you can look at the request. [29:14.900 --> 29:16.660] You can classify what's sensitive in that. [29:16.820 --> 29:17.920] You can look at the response. [29:17.940 --> 29:19.780] And you can do that in real time. [29:19.980 --> 29:24.380] You don't have to mirror the traffic off to do later analysis. [29:24.800 --> 29:29.860] We're doing it in real time in memory without causing any latency hit. [29:29.860 --> 29:37.800] We try to stick within less than a millisecond SLA for the latency to do this type of work. [29:38.500 --> 29:41.930] So, these are the capabilities of data in transit classification. [29:42.620 --> 29:43.600] Number one is regex. [29:43.740 --> 29:45.480] So, does it look like sensitive data? [29:46.460 --> 29:48.440] Regex can produce a lot of false positives. [29:48.440 --> 29:53.860] So, we have to kind of layer down to get to the meat of is this real sensitive data? [29:54.060 --> 29:55.740] So, number one, regex. [29:55.840 --> 29:58.220] Okay, it kind of looks like a credit card number. [29:58.220 --> 30:00.680] Number two, can we do a loon check on it? [30:00.800 --> 30:03.220] So, there's a lot of different checksums you can run on data. [30:03.460 --> 30:07.700] We are exploring all of these and we're looking into other custom ways to do it. [30:07.920 --> 30:13.140] But you can compute a credit card number to see if it is valid in real time. [30:14.920 --> 30:17.280] So, NLP named entity recognition. [30:17.280 --> 30:28.800] So, does this JSON response that's produced by this service uniformly every time, does it have a social security number key? [30:29.080 --> 30:33.520] Then we know that that value is going to be a social security number. [30:33.640 --> 30:37.960] And so, we can see that normal flow of traffic, right? [30:37.960 --> 30:48.580] But when something happens or when there's 10 social security numbers in a response or there's some kind of weird anomaly in the system, you're going to be able to see that for the first time ever. [30:48.580 --> 31:01.340] And then async reconciliation is where you might have a back-end DLP or DSPM product that's already scanned your data. [31:01.460 --> 31:03.440] And so, we can verify... [31:03.440 --> 31:05.980] LeakSignal can verify with that system. [31:06.180 --> 31:07.840] It can whittle down... [31:07.840 --> 31:10.880] It can filter it down as far as it can in real time. [31:10.880 --> 31:16.420] And then it has to go asynchronous at that point to determine, is this real sensitive data? [31:16.640 --> 31:22.240] And so, the goal here is to have a system that does not produce false positives. [31:23.880 --> 31:29.000] And so, these are some of the match rules that we support today. [31:29.040 --> 31:30.080] And this is all open. [31:30.220 --> 31:32.680] You can go out to our docs and look at all this. [31:33.880 --> 31:35.880] So, obviously we do regex. [31:36.400 --> 31:38.340] There's different conditions we can run. [31:38.340 --> 31:42.500] Internal matchers are pretty cool because here we can do... [31:43.740 --> 31:53.400] With Rust and WebAssembly, we can come up with custom computations or just run your known checksums on that data. [31:53.400 --> 32:01.980] So, we can look at, you know, credit cards, phone numbers, different types of error texts and hashes and those types of things. [32:02.580 --> 32:14.380] Another thing that we can do is see bcrypt data or any type of hashed or encrypted data going across the wire and determine what type of encryption is being used. [32:15.000 --> 32:23.140] So that, you know, if someone's doing lateral movement, they get in through some other back door and they're like, oh, hey, I can just download all this data. [32:23.140 --> 32:32.100] Kind of like a bunch of cell phone records from a log server and, you know, and encrypt it in some way. [32:32.260 --> 32:33.920] We're going to see that anomaly as well. [32:34.020 --> 32:46.820] So it's really about having that observability on internal systems, not just that outer perimeter that we talked about in the beginning, but understanding the services and how they act and behave in production. [32:46.820 --> 32:50.380] The final piece of this is classifying exploits. [32:50.540 --> 32:51.720] So a detonated exploit. [32:52.060 --> 32:56.320] This is how a lot of the vendors are being exposed. [32:56.320 --> 32:59.580] All the big vendors we know love and trust and pay millions of dollars to. [33:00.300 --> 33:10.400] We now have this problem where anyone can send in a query string and that will produce a system output on the other side. [33:10.400 --> 33:29.400] So basically what China, Russia and others are doing, the adversaries that want to just scan all of every bit of infrastructure they can get their hands on, is they write a tool, they write a script that has a specific RCE kind of command in it. [33:29.400 --> 33:36.980] So it may be, they may just test the system with an IF config command, with some type of system command. [33:37.140 --> 33:39.560] LS or they may cat etc password. [33:39.720 --> 33:46.840] They'll do something in that initial request and they'll get that signal back that says, hey, this system's vulnerable, we can root it right now. [33:47.760 --> 33:59.240] So that's something else that we look at, that LeakSignal looks at, is really, okay, we're going to classify now, and this at the bottom here is a regex, to classify a system command. [33:59.240 --> 34:05.980] But we can now classify the detonation of an exploit as it's coming back out on the wire. [34:06.180 --> 34:11.580] So this isn't guessing, have we been, do we have a serious problem? [34:11.760 --> 34:13.860] This is a factual yes. [34:14.060 --> 34:19.700] We have a system that has an RCE vulnerability on it, and we can now take action on that. [34:20.640 --> 34:24.040] Here's a few examples of a policy that we created. [34:24.700 --> 34:27.500] You know, are developers sending out private keys? [34:27.500 --> 34:30.860] Did somebody check in on private key and is now being downloaded in production? [34:31.700 --> 34:33.920] What type of system command is being run? [34:34.760 --> 34:38.900] And it's really, it's not a silver bullet, right? [34:39.060 --> 34:51.180] But it's a start into classifying the things that are very dangerous in live traffic, including a mission of tons of sensitive data, along with exploits. [34:51.180 --> 34:53.800] So real quick about leak agent. [34:54.300 --> 34:56.660] This is our open-source project. [34:57.640 --> 35:05.420] Basically, as I was talking about earlier, it deploys in that Envoy proxy where it's very easy to insert. [35:05.560 --> 35:10.440] It goes in cloud native style, very easy to install. [35:10.580 --> 35:14.560] And then that goes, that data, that telemetry is basically sent out to Prometheus. [35:14.560 --> 35:18.700] And as I was showing you earlier, you're going to see these blips of data. [35:18.780 --> 35:30.180] As people pull up a page, it's going to show up in Prometheus and start to give you that observability across all services, what type of data is being emitted. [35:30.180 --> 35:35.360] And then proxy SDK is our SDK that we open-sourced. [35:35.360 --> 35:37.920] And it's basically a way for you to write your own module. [35:38.140 --> 35:41.460] If you want to write your own data classification module, you can do it. [35:42.280 --> 35:45.160] Or really do anything with inline network traffic. [35:45.920 --> 35:48.220] And that is available through GitHub. [35:48.820 --> 35:52.600] One case study real quick on one of the customers that we service. [35:53.500 --> 36:00.000] They are a major airline out of South America and out of El Salvador. [36:00.440 --> 36:07.140] And then, you know, on the left here, you've got, this is a scraper. [36:07.260 --> 36:08.320] It's called Seats.Aero. [36:08.680 --> 36:13.880] And they basically, the guy's very boastful about his activities. [36:13.880 --> 36:19.140] The person that runs Seats.Aero, he makes roughly a hundred K per month. [36:19.140 --> 36:20.000] He posts on LinkedIn. [36:20.280 --> 36:21.600] Here's our ARR. [36:21.780 --> 36:30.320] We're making like $1.2 million a year off scraping airline data and reselling that loyalty data through our website, Seats.Aero. [36:30.820 --> 36:34.480] And so he's like, Air Canada sued him. [36:34.640 --> 36:40.160] And he, you know, he got on LinkedIn and was posting about it and how he really doesn't care. [36:40.380 --> 36:43.820] But for Avianca, he was causing brownouts and blackouts. [36:43.940 --> 36:47.740] So it's one thing to scrape systems and do it for fun. [36:47.740 --> 36:52.240] But when you create a business out of it, you're really taxing that internal system. [36:53.140 --> 36:54.780] And so we were able to... [36:55.820 --> 36:57.820] So Avianca had AWS WAF. [36:57.940 --> 36:59.020] They had Palo Alto networks. [36:59.260 --> 37:07.580] We were able to look at signals out of the response body to be able to say, all right, here's a new signal we can pick up on. [37:07.660 --> 37:08.620] We can rate limit on that. [37:08.740 --> 37:08.860] Done. [37:08.860 --> 37:13.060] First day, they show there's an outage on Avianca. [37:13.420 --> 37:16.200] And by day 12, they completely removed from the system. [37:16.900 --> 37:20.800] This is a new way to protect your infrastructure. [37:21.180 --> 37:23.380] And it's not super easy to understand. [37:23.380 --> 37:28.500] I tried to allow you to download this in a short talk. [37:28.600 --> 37:30.320] This is the first time I've given this talk. [37:31.420 --> 37:33.280] So any feedback is welcome. [37:33.580 --> 37:36.100] If there's anything I can improve on, please let me know. [37:36.840 --> 37:40.760] We wrote a paper with NIST and that's published. [37:41.020 --> 37:43.640] You know, we're trying to give as much of this to the world as we can. [37:44.300 --> 37:45.820] We have commercial customers. [37:45.820 --> 37:49.100] You know, if people want this service, they'll pay for it. [37:49.260 --> 37:49.540] Right. [37:49.640 --> 37:50.960] But we also want to be open-source. [37:50.960 --> 37:56.640] We want to allow anyone to embed this type of observability into their systems. [37:56.640 --> 38:00.260] That is our mission in life with LeakSignal. [38:01.080 --> 38:02.940] And we're also going to be at Black Hat. [38:03.080 --> 38:04.900] We're going to be one of four finalists there. [38:04.900 --> 38:07.380] We just found out this week competing. [38:07.460 --> 38:09.780] So if you're out of Black Hat, please hit me up. [38:09.900 --> 38:11.920] We'll have a little booth in the startup area. [38:12.380 --> 38:14.020] We'd love to talk more. [38:14.380 --> 38:17.200] So thank you, everyone, for coming. [38:17.420 --> 38:18.180] Really appreciate it.