Elastic N.V. (ESTC) Earnings Call Transcript & Summary

Hello, and welcome to Prepare for Tomorrow, Insights from the 2023 Elastic Global Threat Report. We are so excited that you've joined us today. We have a really fantastic webinar planned for you. A couple of really quick introductions. My name is Alyssa VanNice, I am one of the Product Marketing Managers here at Elastic Security. My focus is security intelligence, which means I have the absolute privilege of working with the 2 gentlemen here with me today. Jake King is the Director of Engineering Security Intelligence; and Devon Kerr is the Leader of Elastic Security Labs. They are here to recap some of our really important observations that we saw during this year's analysis. We have a really fantastic lineup of information for you. We're going to take a brief look at how security intelligence is conducted here at Elastic. We're going to go into a little more about Elastic Security Labs and what they do, then we're going to take a look at the adversarial trends and behaviors that we observed during this year's report. And then some of the threat landscape forecast that we have. So we're going to end with the opportunity for some Q&A. The 3 of us are so excited to share all of our insights. We're going to get right into it. Jake, go ahead.

Thanks, Alyssa. It's awesome to see everyone joining on today. And we are super, super excited to share a lot about security intelligence and obviously, the Global Threat Report. As Alyssa mentioned, I'm Jake King. I've spent a lot of my time at Elastic focused around building out content for our products, whether that be rule content, whether that be labs content, whether that be research, whether it be security machine learning tasking. We spent a lot of time building out intelligence discipline at Elastic, really to benefit the customers that use our products, benefit the community through research and efforts like our labs research and obviously share all of that in an open sense as well. Everything from our rules to our content is all open, including many parts of our product as well. And so security intelligence to the Elastic is similar to many organizations, but we have a bit of a different twist because we work in the open with a lot of the things that we do. So first and foremost, first-party threat research. Threat research for us means anything to do with first-party identification of payloads, malware, threat actors. Everything from that kind of effort gets funneled into our labs efforts and obviously into rule development, which is used inside of our Elastic security tools and our product. Of course, machine learning models, development of different tactics and techniques to detect malicious behaviors. Telemetry optimizations, understanding what adversaries are doing and how frequently and how prevalently those attacks are being picked up. You'll see a lot of those figures, in fact, later in Devon's presentation on today's call, too. And then obviously, endpoint and SIEM extensions and capabilities. We spend a lot of our time day-over-day optimizing the way that our platform can detect and better defend against active threats in the community today. We spend a lot of this time really refining ways to efficiently detect malicious actions. And we also spend a ton at that time refining our processes being able to better more efficiently and more early detect threats for all of you. So when we think about first-party research, I kind of alluded to a little bit of what that is. It can be very much high level. It can be very, very deep research and everything in between. We spend a lot of time researching very high-quality indicators of compromise. We understand different threat actors, different malicious payloads and malicious actors. And we present those findings in long and short-form content. So if you're familiar with Elastic Security Labs, you'll be familiar with some of the refs we've released over the year, which you'll be hearing a little bit more about in the next few slides. Of course, our curated artifacts that go alongside those pieces of material that are released as well. So things like our payloads, analysis, different components, and of course, annual reports, which lead us to providing things like our Global Threat Report, which we'll be sharing a little bit more on today. Rule Development is a huge part of this as well. We spent a lot of time taking that curated research and building defenses for our products. I talked a little bit about this generally before, but to get into some more specifics, we have an entire team dedicated to taking much of the research that our labs team and other parts of our security intelligence organization put together and curate them into rules that you can use to defend your networks. This can be anything from living off the land attack defenses to advanced malware detections and many, many things in between. This is all open. It's all completely available in the open under our detection repositories on GitHub, which is super easy to navigate, too. If you're having a hard time finding it, we can definitely help you out on that in the chat. And of course, that culminated so far in around 1,300 prebuilt rules aligned with MITRE ATT&CK, industry standard and well maintained. The visualization you see on the screen here now is actually indicative of our commits and volume of commits over time. We've been committing. We've been updating. We've been improving and releasing new content for many, many years, and that's only getting stronger as we develop better discipline in our research efforts. Of course, it doesn't end there. We take a lot of those rules and identifications and findings, and we funnel it back into feedback for our product. Of course, there's an endpoint team. There's a broader security team, at Elastic that we work very closely with. So when it comes to capabilities like malware protection or ransomware protection, being able to analyze threats in memory or being able to look at malicious behaviors on a host, we provide feedback to the teams building these mechanisms to ensure they're bleeding edge, cutting edge and able to get in front of any of the threat actors that you may observe in your environment. We look at a tax base reduction as a key indicator of our success, how can we make sure that adversary is going to have a harder time getting in front of the systems that were installed on and of course, posting container event collection as well. So we go past just normal security events even into host telemetry, and Devon will get into why some of that is really important in the near future. I've been talking about Devon a lot, and one of my favorite quotes from Devon was shared with me very, very early on at my time at Elastic, which is "Elastic weaponizes defensive technologies to create environments which are hostile to threats." And I couldn't kind of said it any better myself, which is why we use this as one of our kind of guiding lights when we decide to really get into research, build defenses and obviously make it difficult for adversaries to do their thing. We want to make sure that environments that we defend and help defend customers that leverage our technologies, folks that may just use our research can build those hostile environments to threat actors and make their lives a little bit more difficult. So to start things off in a bit of a general place, we released our Global Threat Report last year. We've provided a spring update earlier this year. And of course, that carries through many of the themes of the research that we've been putting together in security intelligence. Everything from adversarial trends, behavioral analysis of those trends, things like malware, endpoint and cloud categorization are talked about in the report. We'll get into a little detail soon. A number of threat profiles were discussed, and these names will be very familiar for some of those readers that have been reading about our labs content over the last 12 months, even for the last 24 months. Threat actors, groups like IcedID, SiestaGraph, RustBucket, JokerSpy, RustBucket, SpectralViper, these are all threat actors and threat profiles that were built, explained and define many characteristics of in the report for this year. So if you're looking to learn a little bit more about how these actors operate and how they move, where they're motivated, you can definitely learn a little bit more in the report. We'll go over some of those findings today as well. And of course, one of the most important things for those that are looking to action some of the intelligence that's provided in the report, forecast of what we perceive is going to be important over the next 12 months and some recommendations as to how you can get in front of some of these threats in your environment and what you can do to defend yourself. So I guess without going any further, Devon, do you want to take over and talk about some adversarial trends and behavior.

Yes. Thanks, Jake. So this section, just to set the stage is probably the broadest category of observation that we make because it includes data representing just about every behavior that we could possibly see from an endpoint, cloud, container, application and many other sources. In this category, you will see a phenomenon like automated behaviors, installing persistent malware as well as interactive behaviors like searching for sensitive files. And we'll break down each of these categories for you. We saw so much malware this year and also so much new malware, so much formerly unknown bad in another way of speaking. When you read 104 signatures here, that is only about 1/4 of our 483 production signatures for Linux, Mac and Windows. What folks may not know is that these signatures can function as a backstop to other features. So there will likely be trends reported by other vendors that reflect maybe different things than we report. It also perfectly illustrates why having so many different industry reports is actually really valuable to understanding the true state of the threat landscape. And of course, we know that there's not really a single monolithic threat landscape. But when we use that term, we need these nearly infinite populations of threat activity that we might collide or intersect with. The largest portion of our visibility is Linux, close to about 92% of all events. And this means that malware observations will be heavily weighted towards Linux. With that in mind, what we see is a really thriving, financially motivated ecosystems, Gafgyt and Mirai, which are 2 of the most prevalent families we observe, both distributed and automated ways, targeting poorly secured IoT devices. That's one of the most common things that we see and of course, permissive default settings, management credentials for these types of device didn't make this any harder, because this is really the most common way that, that class of device may be compromised. But maybe the most important thing and the most interesting to highlight for us is how often things like commercially developed malware appeared. Tools like Meterpreter and Cobalt Strike were routinely used by threats of all kinds. And at the same time, we saw threats leveraging large open source communities, pulling down malware or tools from open sources. In the case of one espionage actor that we studied, almost everything, all but one piece of malware that we discovered had a footprint on a GitHub repo. We can trace that back. And in all likelihood, the other was also from GitHub repo, but unfortunately, the history of these repos is not available to the public. So if it was deleted, it might have been lost. There's also the as-a-service model. And when we think about how capabilities are developed, we've seen rapid developments in quality, cost effectiveness of these malware packages. And that's a great segue to our next section about ransomware families. Most of the ransomware activity we see, almost all of it, in fact, can be attributed to one of several as-a-service networks. The global pandemic seems to have really accelerated the growth, the growth of these criminal enterprises. That's an important word to use because often these threats operate with a high degree of maturity. And they're using affiliates to absorb the liability while they safely collect a percentage of the heist. One reason they might have such a high success rate is that they are constantly underestimated, and we often see organizations misunderstand the threat that some of these organizations wield. But they are not criminal start-ups that are just figuring it out. Unfortunately, the product they sell has a phenomenal return on investment, so we can expect greater expertise in using these capabilities over time. If you're not currently aware of Ransomware-as-a-Service, this is the #1 way that we see ransomware implants distributed to victims. While the majority of malware signals do come from Linux, most of our endpoint data is actually generated by Windows endpoints. And consider that not all of the bad things are obviously malware, like, for example, using an SSH reverse shell connection as a kind of hacky backdoor. You can see why tracking malware is only really part of the narrative here. Now last year, when we reported that defense evasion was the greatest area of threat investment, we inferred that this was because endpoint security made it necessary to get around the obstruction of great endpoint security, well, let's evade those defenses. And if those defenses give you too much trouble, let's try and shut them off entirely. Not quite half the techniques we observed this year were defensive agents. And about half of those, maybe 1/4 of all endpoint event signals that we got leveraged a binary execution proxy. These are generally going to be a native utility that is provided with the operating system and which can be used to launch a script or a binary or some other kind of interpreted content. They are pervasive on every operating system, which makes it kind of ineffective to try and simply remove them as a strategy. Masquerading, which is a slightly different technique was also very common at about 20% of all defense evasion, essentially pretending to be something legitimate to fool human or increasingly a security filter. Now both of these techniques and of course, the entire tactic category of defense evasion are closely related to the execution tactic or executing malicious code. We often see that the evasion is necessary to try and run something that might otherwise be off limits. And so that relationship is pretty consistent throughout this data set. Now to pivot to cloud trends, because so many organizations rely on these enterprise services, it's no wonder they're constantly targeted. For context, our visibility is primarily from Amazon and Microsoft CSPs. We had a minority of data from Google environment, and that's a good thing to consider if you primarily rely on Google Cloud infrastructure. Credential theft, like last year, probably the single most common behavior we observed, this year more than 47% attributed to credential access. And that makes complete sense, especially when you consider that's how almost all valid users access these resources. From a successful login, an adversary can steal data, they can plunder communications and with permissive rights on that stolen account, they can achieve very costly objectives like spinning up cloud compute nodes or deleting critical data. Defense evasion also saw a pretty big spike midway through the year around the time that our interactive GTR was released. And in this particular case, we saw a new type of event tampering with logs, deleting logs. And this is clearly because that's the default kind of visibility CSPs condition us to expect. And it's very easy with the right privileges to be able to destroy that resource. If those events have not been ingested, if you don't have an ability to see the threat that it might represent, then you can otherwise miss that your cloud infrastructure has been compromised and of course, the adversaries they really benefit from that dynamic. If I can turn it over, Jake, let's talk about forecast and recommendations.

Absolutely. I think it's really important to kind of think about observations in the context of how we build defenses around them. And so Devon and I spent a little bit of time, obviously, when crafting the report, Devon's team spent a lot of time while crafting the report, really discerning different recommendations that we had in place and things that we've perceived might be really valuable for readers of the report for folks that are out there on the front lines defending their networks and the systems and perhaps some of the insights that we have that we can kind of read from our crystal ball to kind of go a little bit further. So part of what's really enjoyable about producing the Global Threat Report is being able to hypothesize to be able to theorize the way that adversaries may move through our networks next year over the next 12 months. And we had some pretty good bets last year as well for those that have read the report, I think some of those findings that have come to fruition, at least in the way that we observe them. But one of the things that I think is important to reference here as well is in these forecasts and predictions and obviously, our recommendations behind them are so much based in reality of the data that we observed, it's critical to understand that building defenses is always going to have to be a comprehensive measure. These are going to be part of a security strategy that you build out, not the only parts of your strategy. And more so, you can validate many of our findings and assumptions here throughout the next 12 months as we release our spring update and obviously, subsequent global threat reports. So we'll jump straight into it. I think this is going to be pretty exciting. So the first, I guess, forecast and recommendation that we wanted to put forward was we forecasted that defensive agent is going to remain the top investment and we'll supersede masquerading. Devon, what are your thoughts here? And why is this going to be a forecast for next year?

Yes. Well, if you recall, just a few moments ago, I was talking about the tendency of the adversary to evade defenses by disabling technologies. And it seems very likely that adversaries will pursue that over something a little bit less effective masquerading. And to give you an example, earlier this year, we were looking at a common ransomware implant used to distribute destructive ransomware in a victim environment. This particular piece of software, it looked like the Windows service host. It had a lot of metadata that they -- obviously, they've researched to make it look normal. It was running out the wrong path. That was really the only anomaly. That type of very trivial modification is renaming thing, modifying some metadata. That is not going to work with behavioral analytics, things that look at the structure of binary itself, signature-based analytics that are going to be looking at bit sequences or string sequences of the object. That's very hard to fool, very hard to fool those technical controls. So I think they will begin tampering more. And I think the popularization of certain techniques like bringing one vulnerable driver that really facilitates disabling security technologies because that's a framework that is inherently privileged. It runs at the highest level of privilege. So even security tools can't defend themselves if an adversary gains control of it. And I think we'll probably see Windows exploitation pull that direction.

Yes. I think to extend upon that last point as well, Devon, this is something our team has had a number of unique findings for over the last 12 months. And obviously, we're starting to find some pretty interesting trends in that kind of activity. So what do we do about it? Obviously, organizations should evaluate the sensors that they have in place and their ability to remain tamper resistant. Controls that are in place need to be obviously robust. And you need to make sure that you're thinking about the ways that adversaries may start to use built-in binaries, common repositories of tools that are used to circumvent controls or evade detection, such as GTFOBins or LOLBins for Windows and Linux and really kind of understand that monitoring, living off the land attacks were basically tool-based attacks is going to be really imperative. So that last point that you mentioned, Devon as well, I think there's an immense amount of research going into detection of things like SSH reverse shells, evasion kind of tools and using nonstandard system or standard system binaries rather as opposed to nonstandard system tools for exfiltration, which I think is an exciting trend to observe. Hopefully, we'll see some more research about it this year.

I know I mean I've seen remarkable things, but it's a trend that makes a lot of sense. Introducing foreign software causes security infrastructure to sort of react. If you are pathogen trying to infect the body and you run into a white blood cell, well, what do you do? Well, the best thing is to not get caught. But if you do get caught, have capabilities that allow you to neutralize the security technology so that you can continue to infect the host. And this is a very close parallel to what we see with malware ecosystems, they're trying to bypass the protection in order to infect the host and the safest way to do it is to introduce as little foreign code as possible. We saw this with REF2924 last year and the SiestaGraph implant, which looked like a legitimate web server and communicated with Microsoft Azure APIs. And so it's using Microsoft cloud infrastructure, which the user would probably expect, given the architecture of the infected system, a very clever way to not get caught to not be seen. And I'm sure if there was a security technology that could have neutralized that implant, then they would have worked to disable that technology so that they can continue to complete their mission.

Act on those objectives. Okay. So we've got a second forecast and some recommendations as well. The malware-as-a-service model will become more popular. I couldn't agree with this one more. I think this is a fascinating area of research, specifically for security folks like ourselves Devon where we kind of observed these groups becoming successful, building profitability and obviously accelerating in the way that they're doing things. What are we seeing out there?

Well, I think this model will become popular because it really works. And it works for a couple of reasons. If you're very technically mature, it's less risk for you to develop the capability and license it, which is the same thing that we do on the defensive side, but in the malicious ecosystem, very similar model, benefit from the engineering power of a large team. And some of these criminal organizations have massive research departments. We often think of them as like teenagers in a basement with a coffee table with like the stacks of cash. And for whatever reason, that myth has been popularized, but it doesn't really represent the types of groups we're talking about. These are corporations, criminal corporations that have affiliate networks and licensing agreements, they've got a concept of supply chain where they have to protect their own because they are just as vulnerable as their victims are. That's a very real dynamic we see play out. But this model will continue to make money, I think, for these orgs. And so we have to stop considering the threat to be this immature novice, and we have to really give them some respect. And I think when we prepare for a threat, candidly, we'll do better if we assume that they have great capabilities. Underestimating them, unfortunately, is very common. And at that point, these are very cutthroat organizations. They're going to complete the mission one way or another.

Yes. I think it's important to also reference the fact that really this commoditizes a lot of the, let's say, advanced payloads that are accessible to adversarial groups, and it reduces their cost of a barrier of entry to try and attack different systems. So one of the recommendations or one of the guidances that we've provided to organizations throughout the year is to obviously implement technologies that are going to help you understand what's going on in your systems, better defend against commodity malware and obviously, better understand when these kind of actions may start to take place on your system. It's incredibly kind of scary to understand that we're effectively giving world-class adversarial malware tools and kits to folks that may have very different goals, very different kind of minimum bars for the kind of organizations that they'll attack. And I think as an adjacency to this as well, it's important to understand that the kind of organizations that will be targeted by malware, advanced payloads will likely change as a result of the commoditization of these kind of software payloads out there. I think there's a whole lot to think about when it comes to defense for Malware-as-a-Service.

It's also true that when you have help, you act more confidently. So for, let's say, a group that is not mature, they haven't been exposed in a lot of these environments. They don't know how they're going to react edgy, a lot of nerves, the same things that you would expect an inexperienced person in any field to experience when it's crunch time. Well, that threat actor will make more mistakes than somebody who's got a playbook. And a lot of these affiliate networks, they need to ensure their revenue stream. They're building a capability for somebody else to use. They're going to license that capability of that person or that group, but they still want to make sure that they get that percentage. They actually benefit them to prepare those teams really well. They've got great onboarding docs that give them that framework, which means they move faster. And the problem with faster is that defense is typically not fast. We talked with a number of organizations this year who's got a default response kind of like 4 to 6 hours from alert to response. And part of that included like isolating the system. But if the adversary gets to the complete admission phase and they've stolen data or they destroyed data within an hour, well, your response process is going to lack. So having an interactive capability that is very powerful that lets you reach out and affect the environment, it means that you actually stand a chance. If you need to deploy that capability before you're able to do that or worse work through like large federated organizational process to get that blocked and contained, that adversary just has a much better chance to succeed. And again, this model really caters to that outcome.

Sure it does. Sorry. Going forward a little bit, we've been thinking about -- and obviously, we've talked a little bit about defensive agent, we've talked about malware-as-a-service. Adversaries will become more reliant on open source for implants, tools and infrastructure. When we talk open source, we're commonly talking about it in the context of detection engineering, signatures, software that we may use to defend our systems, adversaries are using the stuff in the same way.

For sure. Just one example. SiestaGraph was based on the OneNote API open source Scala project. That's just one example of an adversary who understood an entire mechanism for potential C2, leveraging an existing cloud framework that was publicly recognized that had hosting of plenty of legitimate things. They gave it a shelter. That's just one example. That same threat group, they borrowed code for [ NAPLIS ] and SOMNIRECORD, which are 2 of their other conventional implants. This is a very common process because it accelerates the technical maturity of these orgs. If I don't have to spend 18 months building the perfect payload, I can spend 18 months using a payload that is acceptable that meets my criteria. And where this, I think, intersects a little bit is there is a massive open source community, building things that we don't necessarily associate with malicious tools, but have a potential malicious dual purpose. And it's those tools that adversaries, I think, are most drawn to because they know it gives them some plausible deniability.

Couldn't agree with you more, Devon. I think there is a huge kind of focus being put on tooling for end-to-end encryption and easy management of systems, and we can only see these tools being, number one, very usable within the enterprise, but at the same time, very, very easily used or repurposed, I should say, by adversarial groups. So there's a few things that organizations can think about in this front. Certainly, looking at the things that are being downloaded into their environment, the tools that are available on their systems and obviously, limiting access to certain things may kind of act as an infiltration or exfiltration kind of channel. Looking for open source within your environment, auditing the tools that are deployed, understanding if there is unusual binary or a package installer in the system, understanding if there is a new tool or a new protocol or a new network interaction over a network. Is that a developer or is that an internal network? Or is that an adversarial group doing something nasty perhaps, but also evaluating the way that adversarial frameworks are being developed, understanding the research, right, getting in front of different topics. Obviously, we dissect and understand different payloads, malware and threat actors that have been produced over the last 12 months. We're going to continue doing that, continue releasing that kind of information. So staying apprised with what's out there and how it's being used is certainly going to be very critical, right?

Absolutely. And just recently, we saw a case where one of these financially motivated actors was literally pulling their script executables right off GitHub as a gist, running it on an endpoint not actually infecting the system, but just very temporarily running that code. And we thought to ourselves for sure, this is the kind of thing that the network layer can be filtered out at the application layer to be filtered out. This is a thing that maybe we can even isolate specific populations of users that we know have a legitimate daily business need to run a command like that and then everybody else, let's treat that as forbidden. And that would give them such a leg up on this particular class of threat. Not all threats, we'll do that. Not all threats will telegraph their intentions. But for the ones that are going to absolutely neutralize that threat. They're giving you every opportunity.

It's an exciting trend and it's one that we'll certainly be watching very closely. Hopefully, this leads to some very easy detection methodologies in the future as well. Reuse of code is something that we observe as threat actors to be able to write signatures for understand behaviors of. And so these are the kind of things that can help us out as defenders to better understand. So the next kind of topic or next recommendation and forecast is one close -- near and dear to my heart. Cloud credential exposure will be a primary source of data exposure incidents. Now first of all, thinking about cloud, it is a different -- obviously, a different landscape. We've included some new resources in this year's report as well. Perhaps you can talk to some of those points, Devon, and maybe go into a little bit of how cloud credentials are being commonly used today and what we think is going to happen next year.

Well, just as adversaries have leveled up to a degree and they understand that exposure is a risk for them, and it's one that they want to avoid. There are extremely mature types of threats that are consistently moving away from where the defense has the best eyes and into those places where they're better concealed. And one of the places that we see them move to is these cloud resources. And there's a couple of reasons for it. But the first is every enterprise uses cloud resources for productivity. It's where e-mail communications are. It's where critical business comps are. It's where all of your critical runtime applications are, your financials, and of course, lots and lots of personal information that could theoretically be monetized. We even see cases where organizations are targeted to get to privately hosted non-publicly accessible resources, which makes it even more complicated, because how many enterprises really consider their cloud attack surface as part of integrated with their enterprise. A lot of the ones that we have talked to certainly don't. And a lot of them actually rely on the vendor to isolate those cloud instances and provide them with most of the types of protections that they are investing in for internal systems. A problem with all of this, of course, is defaults and excessive permissions, organizations that don't segment data. And a lot of them do this, I think, for altruistic reasons, like there's no reason that we couldn't share this across teams, even though we don't see a reason for it to be necessary, but adversaries can take advantage of that permissive culture. This allows them to get access to things they might otherwise not be able to. It allows them to change their targeting strategy because they can get access to a user maybe who is easier to get a foothold in their system, maybe a user even that they've successfully done this with before that allows them to access this premise type of data lake.

Yes. Absolutely.

So limiting -- yes, and limiting that is probably the most effective thing you can do, role-based access controls. It's already built into those systems, just implement them.

It gets them implemented and build discipline around that implementation. These states are constantly in the state of flux, users are going to change their roles, privileges are going to change systems, capabilities of tools that we use are going to change as well. And so understanding least privilege and implementing it in your environment, but also monitoring the exhaust of these systems. In one of the mentions in the report this year was obviously tampering of logs and extraction of logs. And one of the reasons those logs are being tampered with us for this exact purpose, they are abusing privileges, we're abusing actions on different systems, which is really, really critical. Kind of staying within the same theme of cloud, we decided to talk a little bit more about endpoint-related technologies. And obviously, Kubernetes being one of those technologies that we have some insights into over the last year. Excessively privileged Kubernetes pods will compound the damage of container vulnerabilities. When we think about, obviously, the scope of containers and their capabilities, one of the things that I've always been -- I kept a close eye on is some of the fears around overprovisioning a container, providing too many capabilities to it, network access, system access. What are some of the things that we're observing and kind of where do we think those are going to go?

Well, I think ephemeral systems are one of the issues here. In a lot of cases, these container architectures are chosen to support large networks of temporary or ephemeral systems. And we think about risk differently when we think a system is nonpermanent. We think it's going to go away in a few minutes or a few seconds. We treat that like a slightly different kind of system than one that we might expect to be around for like weeks, months or years. And I think because of that, a number of organizations that are using these types of container frameworks, they probably can invest more time in remaining current on patches, because we often see things like automated exploitation, basically using old vulnerable software. And the turnaround time, and this is not a long period of time. We've seen things go from exploit proposed to, in the wild, in very compressed time frames like hours, not days. And with that dynamic, it means that you can have outdated ephemeral infrastructure. You've got to really, I think, make sure that, that is configured properly that things are automatically patched, they're regression-tested because that will become a target for somebody. And all they need to do is they have to hold on one. And if that is an excessively privileged situation, they can target the host object, they could target other containers. It really does make the problems much bigger and once you're on the inside, unfortunately, you have access to quite a lot.