Name: Live From Runtime: Oligo in 20 Minutes
Uploaded: 2026-04-16T18:46:08.267Z
Duration: 23 min 24 s
Description: Live From Runtime: Oligo in 20 Minutes

Transcript for "Live From Runtime: Oligo in 20 Minutes": Hey, everyone. Welcome. Started in just a few minutes. Feel free to drop in the chat where you're dialing in from. Alright. Let's get started. Hi, everyone, and welcome to Runtime Exploit Blocking. My name is Victoria, and I'll be your moderator for today's webinar. Before we begin, I'd like to start off with a few housekeeping items. You are all automatically muted, but to unmute, feel free to raise your hand and the host will unmute you. At the end of the webinar, there will be a poll question. Please only click your answer once and then to get there, go to the panel on the right. If you have any questions throughout the presentation, please put them in the Q and A chat and we'll be answering them at the end. And you will receive the recording of this webinar within twenty four hours of its completion. Now I'm going to pass it over to Mick McCully, who is Oligo's field CTO. Mick. Awesome. Thanks, Victoria. So welcome, everyone. I'm excited to share with you a new capability and, functionality inside of Allego that we're very proud of, the runtime exploit blocking, which we'll spend the next twenty, thirty minutes or so, going through some of the details of what it is, how it works, and a quick overview in the product. We're definitely excited about it. Wanted to share with you how it works, and some of the impact. We believe that this is definitely some game changing capability that we want to share with the rest of the world. The idea is to be able to provide some exploit prevention inside of applications without disrupting them. Right? Letting businesses continue to function as they should. You'll see the little tagline here, block first, patch second. What's also interesting is patch at all is potentially an option dependent upon your preferences. Like, the idea behind what we do is to provide a layer of protection to keep some of these exploits from happening. So without further ado, let's get into some of the details of why we're having these conversations. It's probably not, it's probably not a surprise to you, right, some of these numbers that you've seen, especially if you're in the security space, that the number of CVEs, the number of detected, discovered, disclosed vulnerabilities just it it continues to rise. The more and more abundance of applications and software as well as the discovery of different types of attack and, techniques keeps creeping up the number of vulnerabilities that are being discovered every year. This, like, puts organizations on their heels. There is I I I read an article just recently. There is what's called a terminal velocity associated with how many things you can fix, and that doesn't change, but the number of vulnerabilities keeps increasing. This creates this massive backlog that organizations struggle with. Add in the fact that that the time to exploit. If you look at any of the breach reports by Mandiant, by Verizon, the time to exploit these vulnerabilities has continuously started to decrease and go down. Anywhere from, you know, having thirty days a month to fix it to five days, and over the last couple of years, less than one day. Meaning, by the time you're getting notified of the vulnerability in the patch that may or may not be available, there are already exploits happening in the field. So the combination of those two is creating this just abundance of risk that organizations are struggling with, trying to figure out different approaches to solve this problem. The other piece to this, unless you live in living in the closet for the last week or so and are in security, you've probably seen the headlines associated with, Project Glasswing and Mythos. Right? This anthropic project where their latest model that has been able to actually, in tests as part of the CyberGym analysis, been able to reproduce vulnerabilities on its own and create proof of concepts. And the accuracy rating is hitting 80 over 83%. And I've even some seen some validation of this by individual and, independent entities where it's even higher than that. You're probably also aware that Mythos project, which has discovered massive numbers of vulnerabilities across every operating system, browsers, you know, in any type of application, is also creating quite a stir in the market. The fact that AI is being used or could be used by adversaries to discover and exploit vulnerabilities faster than that than than organizations can actually, discover and and and patch them on their own. So add in these these facts, and you're up against a wall. And the question is, what do you do? And so the idea behind what we're presenting today is to say, well, there's only one real approach that you can start to take, and that's blocking at runtime. It's actually providing controls to stop these exploits in the first place. And so you may say, well, that's not necessarily a completely novel idea. We've seen approaches in the past, but none of those approaches have been quite as successful as we wanted them to be. And if you look at some of those historical approaches that you see over on the right, you're gonna see that RASP, early in my career, I know had this massive aspiration of achieving these types of goals. But the reality was the technology hindered it from being adopted. It ran in line. It required source code access. You had to instrument the application. It was a potential single point of failure if it broke. Your app broke. And so just the adoption of it didn't take hold. There were too many hindrances against the business that it just couldn't achieve the the goals that it wanted to without impacting the business in a negative way. WaaS, web application firewalls, definitely had promise associated with, like, preventing attacks proactively. However, they're highly dependent upon the payload, knowing what it is, knowing how somebody could create different types of payloads and the infinite number of approaches that have to be blocked in order to prevent attacks from coming through. And the reality is is they do prevent some attacks, but we're still seeing breaches. So WAFs haven't been sort of that silver bullet. The last one we're seeing, and we've seen a surge of this, is some of the cloud response and detection and response. However, the reality of this is it's it's just a different type of outage. It's a self imposed alley outage. You're basically reacting to an exploit and then playing whack a mole by doing things like killing containers and processes, creating your own sort of outage but just trying to control the blast radius of an exploit in real time, not actually preventing the attack from happening in the first place. This is where we come into play. This is one of the things that we're very proud of that Oligo was built. And what we're gonna talk about on the, exploit blocking is built on top of the technology that's extremely unique to Oligo, And it starts with this, what I'm showing you on the screen. Historically, applications have looked like this. Right? You deployed code to your environment, but it was it was a black box. You didn't know what the code was doing. In most organizations, this is exactly how it looks today. Like, the application performs its activities, and then you look for things that are happening on the perimeter. Is there privilege escalation, malware being installed, remote code execution occurring? What we've done is created this layer of transparency of being able to see inside of the code when it's running. Do this without requiring access to the code, without requiring modification of the application, having applicability to first party apps, third party apps, vendor supplied apps, AI, which we'll touch on a little later. When you start looking at the entire digital world, it's all composed of running code. Once you get this layer of transparency of seeing that running code, you can start to do things with it. You can actually start to take actions and prevent things from happening. And this is exactly what we've built with this technology. So how does it work? What are we talking about? What is exploit, runtime exploit blocking? This is a quick snippet into it, but the idea behind it is once you can see that code, you can start to identify the attack inside of the application, inside of the running code, which allows you then to take action when that's occurring. Actually stop the exploit inside of the running code without impacting the application. Still let the application perform the activities it's supposed to, but the nefarious activities that are actually abusing code inside of the application stop those. I'll go through a couple of these types of, attack techniques. But the interesting piece is is what we're doing is actually watching the code, the entire call stack, identifying the functions. We know what they should do and what they shouldn't do, have these deterministic pattern based rules. These are rules that we know exactly what the activity should and shouldn't be, and we basically give those to the operating operating system to enforce those on our behalf. This is the power of it. It is a very, very granular approach of being able to prevent these entire categories of attacks but without impeding the ability for the application to continue to function. That gets into some of the side effects associated with this. Once you figure out approaches and look at some of the attacks that are happening in the industry, JNDI, deserialization, template injection, All of these different types of techniques that are occurring inside of application all come down to the exact same sort of exploitation in the underlying application itself. They may may follow different code paths. They may go through a vendor supplied app, your own bespoke code, open source components. But ultimately, they arrive, and they exploit the exact same thing. A JNDI attack is a specific library with a specific function that starts performing code execution. Once you know that, you can observe that in real time and stop it before it performs those nefarious activities. If it's not performing those bad activities and it's just performing the activities of looking network lookups, let it continue to function. You can build these types of rules and enable the operating system to actually validate and perform those activities for you. What's also interesting, a side effect, these techniques that we've discovered are CDN dependent and map more to CWEs, common weakness enumeration, entire categories of approaches. And what we've seen is you can take a single rule, decertralization in this particular example, that rule has applicability to literally hundreds of different types of attacks. Across our customer base, we see that hundreds of high and critical vulnerabilities in Java and Python all map to the single attack technique. By simply deploying this one blocking prevention rule, you can mitigate hundreds of vulnerabilities instantaneously. And it's some of the power and side effect, and I'll show a little bit of this live in the product as we progress. So why and how is this different? It leverages complete unique technology. We're leveraging the ability to actually get information from the operating system itself as well as giving it the details on how to perform these activities. Because of this, we don't add additional overhead and latency associated with it. We're not proxying things. We're not having to instrument the code. We're not running in line. It's very, very lightweight for us to perform these activities, and we're actually giving those rules to the operating system to actually perform the actions on our behalf. It's also very, very precise. Instead of killing a container or killing an entire process and shutting things down, what we do is simply block the specific function that's performing the wrong activity, but let the application continue to do what it's supposed to. This enables, basically, the ability to prevent that type of exploitation without impacting the application's ability to run. Doesn't require any source code, any instrumentation. What's unique about this is it runs on applications you build or applications you buy. Doesn't matter. Right? Code is code. Where it came from, who built it, AI built it, it doesn't matter. When code is running and you're observing it, the origination of how it was created becomes something that's not important. With that in mind, what's also extremely powerful about it, AI. AI is just code. When you actually execute and run it, the Aginti components, the tools, the MCPs, they're they're all just code. Once you can see the code, you don't care what type of application it is, how it's running. So the applicability of actually seeing these exact same techniques be abused inside of AI is one of the use cases where you can start to apply this capability to prevent those types of attacks incurring inside of those environments. So with that said, I'm gonna use the next couple of minutes to give you a quick introduction into that into the product. There is a lot to unpack here. I don't expect to share all the details with with you all. If there's additional information you wanna delve into, obviously, post some questions. If not, we can also, engage with you afterwards to get some in into the more granular details of exactly how this works. So with that said, I'm gonna jump into the Ologo UI. This is the the dashboard where we present a lot of the telemetry and information that we're sharing and gathering from watching running applications. This is dynamic. As new things happen, this this pops up instantaneously and starts to provide alerts and details. I'm gonna focus in on the blocking piece. Now what's interesting is there's multiple layers associated with this. The first is just the ability to detect those types of attacks. So if you're watching the application, what you can start to do is to identify these types of techniques as they're running inside of the application. This is an example. Latest version of Log four j may or may not have vulnerabilities associated with it, but as soon as it starts to perform activities like a JNDI attack where the JNDI library starts to execute code versus simply do those network, lookups, this is where we can start to identify that information and tell you about an attack that we've identified inside of the application. And then if we're in detection only mode, provide all the details of all that post exploitation activity that you're probably used to getting from other systems, but we can stitch it together and give you the root cause analysis. Once you start to implement blocking rules, which you can either do reactive as part of an attack where it's like, okay. We know something's going on. We want to actually keep this from happening in the future. Or if you've already got those rules set up, we still identify and share and tell you whenever they're triggered. So in this particular case, this is a library, a PyAML library in a particular Kubernetes cluster. It's running inside of a container as part of a Python process. This PyYAML library just misbehaved because an attack made its way through the code and ultimately got to a point where it triggered it to attempt to perform an activity that we know that it's not supposed to. And in this particular case, what we were able to do is to actually block the specific function that attempted to perform that code execution. This is exactly what we're talking about. What's interesting is the PyYAML library can still continue to function, do YAML parsing like it's supposed to. It just cannot perform those nefarious activities. So this is the blocking in real time. All of that revolves around these rules that we built, these techniques where what's interesting about them is you start to look into the details. These are entire categories of CVE. It doesn't matter where this JNDI attack originates. The code you've built, the vendor supply code, an open source component that's newly discovered and disclosed. If it leverages the JNDI library and starts to perform activities like executing code, it's gonna block that before it can occur. If something new is discovered and disclosed tomorrow as zero day, instead of you having to scramble, react, Do we have it? Where is it? Are we exposed? What do we gotta do to to patch it? Is there a patch even available? With these types of rules, that no longer becomes a priority. You've already implemented the protection capabilities to keep those types of attacks, these categories of attacks from happening. Our objective is to wipe out entire categories of CWEs, which then in turn has applicability to the vulnerabilities themselves. What's very intriguing is once you start to implement these rules, you know you have mitigating controls for these components. It then becomes up to you to decide, do you wanna patch it, or if and when you want to update those libraries and perform that patching technique. So the ability to actually apply these rules to vulnerabilities, to take the burden of having to fix that, to interrupt developer workflow that may be focused on generating code that actually generates revenue for the business, what you could start to do is apply these mitigating techniques and then decide if and when you actually perform some of these patches. So I'm gonna jump back to these slides. I know that was a quick sort of introduction. There's, again, a lot of additional detail we can get into, techniques sorry, how we actually perform those techniques, the different types of techniques with each of you individually live in in a, more deep dive. But the whole idea behind this is proactive protection, like the ability to inspect code and try to identify and guess the abuses and the number massive number of of vulnerabilities that are constantly, being discovered, disclosed. Staying on the top of those becomes, the capability that that is an endless task that you'll never get ahead of. Looking for exploits live in production and simply reacting to those by shutting down systems and turning off things also doesn't scale. Implementing these protection capabilities that keeps this attack from happening in the first place is what we're focused on and one of the things that we have, we believe, has powerful potential to actually help a lot of organizations so that they're not chasing these types of activities. Cool. So, Victoria, I think we wanted to do a quick poll, and then we can also look at any of the questions if any of those have popped up. Absolutely. So feel free to go over to the panel, and click on poll at the top to answer, and just remember to click your answer once. A couple people messaged me privately. One of them would be, how do we think about prioritizing which blocking rules to enable first? Oh, good question. So what's interesting about the product is all of those different rules you can start to put in well, most of our customers will start with detection first, the ability just to understand if any of those are firing at any given point, and then you can always implement those protection rules. A lot of them wanna do it just from a conservative nature because once you have that technique in place, the detection piece, you can understand when and how. What's very interesting, they fire just very, very not very often because they are only gonna fire when there is a legitimate attack that's being performed. The detection the protection piece, you have the ability to turn on or off at any given time, and so the ability to apply it to some of those more high severity vulnerabilities and implement those is usually what most of our customers start to do. Great. And then the other person asked, what happens if a blocking rule accidentally blocks legitimate activity? How do we roll back? Good good question. Well, for first of all, the rules that we've built shouldn't block any legitimate activity. The rules themselves have been very, very confined to only perform the activities associated with behavior that we know is known bad. And, again, the particular libraries, the functions should never perform these types of activities. They're the exact process and and the underlying techniques associated with these categories of CWEs. So they're they're pretty rock solid sort of rules. Now if it did for whatever reason, the ability to simply disable that and roll it out to the environment is a very straightforward process, and you can scope it too. So if there's only particular areas that you wanna turn it on or turn it off, the ability to actually apply those, push those rules out. It does take just a couple of minutes to then push all of those out, get the systems to update and reflect those new rules, but it's fairly easy to actually update, either on or off at any given time, individual rules or multiple rules at a time. Awesome. Thank you. It looks like those are the only questions we had. Feel free to reach out to us after the webinar as well if more questions come up. Thank you everyone for joining today and be on the lookout for the recording within twenty four hours. Have a good day. Thanks all.