Screaming in the Cloud - A Hop, Skip & a Jump to State-of-the-Art Network Analysis with Matt Cauthorn

Episode Date: March 30, 2021

About MattMatt Cauthorn oversees the ExtraHop Security Sales Engineering, and enjoys studying the intersection of business and technology. Prior to ExtraHop, Matt was a Sales Engineering Manager at F5. He’s a passionate technologist and evangelist. He holds an MBA from Georgia State University and a Bachelor of Science degree from the University of Florida. Matt speaks at industry events, has been featured on podcasts, and quoted in industry coverage.Links:ExtraHop cloud solutionsWEBINAR with ExtraHop and Corey: "Secure Your Cloud Against Advanced Attacks with Network Detection and Response"

Hello, and welcome to Screaming in the Cloud, with your host, Chief Cloud Economist at the Duckbill Group, Corey Quinn. This weekly show features conversations with people doing interesting work in the world of cloud, thoughtful commentary on the state of the technical world, and ridiculous titles for which Corey refuses to apologize. This is Screaming in the Cloud. This episode is sponsored by ExtraHop. ExtraHop provides threat detection and response for the enterprise, not the starship.

On-prem security doesn't translate well to cloud or multi-cloud environments, and that's not even counting IoT. ExtraHop automatically discovers everything inside the perimeter, including your cloud workloads and IoT devices, detects these threats up to 35% faster, and helps you act immediately. Ask for a free trial of detection and response for AWS today at extrahop.com slash trial. If your mean time to WTF for a security alert is more than a minute, it's time to look at Lacework. Lacework will help you get your security act together for everything from compliance service configurations to container app relationships, all without the need for PhDs in AWS to write the rules. If you're building a secure business on

AWS with compliance requirements, you don't really have time to choose between antivirus or firewall companies to help you secure your stack. That's why Lacework is built from the ground up for the cloud. Low effort, high visibility, and detection. To learn more, visit lacework.com. Welcome to Screaming in the Cloud. I'm Corey Quinn. One of the problems with being me is that it gets kind of lonely because I stand sort of squarely between the worlds of business and technology. You'd think they might be the same world. They're kind of not.

And one way that I tend to make that isolation a little bit more bearable is to talk to other people who are in similar positions. This episode is promoted by ExtraHop, which is a network security vendor that we're going to dive into because my guest today is Matt Cawthorn, who's the VP of security and cloud at ExtraHop. Matt, thank you for joining me. Yeah, thanks for having me, Corey. Good to be here. So ExtraHop was one of those companies that I became aware of as something to pay attention to. And it's going to sound weird and obnoxious, and I don't even care. But the reason that I started paying attention was because there was an event in the before times here in San Francisco, and I started seeing your name on the side of city buses.

The company, not yours personally. When you see a person's name on a bus, that usually is a different implication. Yeah, I have a feeling it was one of several events that we were involved in. Yeah, it's great. It's great that you discovered it that way. Say what you will about advertising like that. It works. And the problem you run into in some cases is that you aren't able to really convey the depth and intricacy of what a company does. Now, you folks have been a sponsor for a while of my nonsense, and thank you for that. That shows that someone is making excellent decisions on your side. They should be promoted and make more decisions just like that one. But for those who haven't been

paying attention to the world of security and all the various nonsense that I do, what is ExtraHop? What do you folks do over there other than by advertising on buses? So the technical category that we fall into is network detection and response, which effectively means sophisticated network security analytics for the enterprise and the cloud. And if there's a network where we can see the packets and process them, we are able to give very, very sophisticated security analytics on that, as well as support for the incident response workflows and APIs and much more. I'm going to endorsing every sponsor that comes through. But at some point, when you wind up having a sponsor who is next to things that you're doing, over a long enough timeline, you start to become associated with them.

And the problem with security vendors in many respects is they almost invariably start speaking to security folks who are steeped in that world, where a CISSP almost feels like it's a prerequisite to understand what's going on. That's one of the reasons we launched the Meanwhile in Security companion podcast to specifically cut through that mess. But for me, the way I learn is by rolling something out and using it myself. And I did deploy ExtraHop to my test environment. And I was pleasantly surprised by what you folks had built. Oh, thank you. I'm glad to hear it. And you're exactly right.

And I assume your test environment or your environment was up in one of the cloud providers. Is that correct? Yes, AWS, because that's the one that I have the most experience with. Our day job is helping companies fix the horrifying AWS bill. And we sometimes discover how that breaks by incurring one ourselves from time to time, because it's a problem that stalks all of us throughout the course of life. Yeah, I've been on the dubious receiving end of that billing as well in another life. So you're doing a service.

Thank you for that. So yeah, one of the big things that not everyone is familiar with, and I think many, many more, if not everyone who's delivering apps and services in the cloud, is that now, in particular, AWS and the other cloud service providers can send network traffic to target interfaces. And that means vendors like us can process that invoked behavioral analysis on these byte streams and give you transaction analysis and security, forensics, investigation, and detection. It's a very, very powerful and it's purely out of band native to cloud.

So the way you've deployed is using the native facilities up there, and it works really, really well. And I spent a fair bit of time dabbling as a network engineer as a part of that. In fact, during the financial crisis back in 2008, I was stuck in a job because no one was hiring. I'd been there a year. There was no real advancement opportunity. There was a salary freeze. So as I hit my one year, I wasn't able to get a raise. And that led me to be even more disgruntled than I normally am. So my approach to becoming a better systems administrator was to get a CCNA during that timeframe. And it sounds counterintuitive, but the more I understood what was going on in the network, the more the rest of the system made sense to me to the point where now when I start trying to diagnose weird issues, I start from a network-based perspective. The problem is, is so much of that in the

cloud environment is obscured away and not easily discoverable. Yeah. The beauty and danger of the cloud simultaneously are the layers of abstraction that you just described. This is exactly right. You know, on the winning end of it, you get this radical acceleration of traditional infrastructure, deployment workflows, deploy, destroy, all of this stuff. But the price that you pay is that these levels of abstraction take you sort of further and further away from having your finger on the pulse of the environment. And the ultimate, I'll just wear out the metaphor here, Corey, but the ultimate connective tissue is the network itself. And in fact, that's where the preponderance, at least, of the actual behavioral intelligence lies.

It's on that connective tissue. And so without having real awareness of what's happening on the network itself from a behavioral analysis perspective, you really are kind of flying blind. What I want to talk about, too, is just to give folks an example of what's happened. In fact, while I have you on the recording, I just pulled up a view into what's going on in my environment. And it tells me all kinds of interesting views. And honestly, this is one of those visualizations that I wish more companies would discover, because let's be very clear here. What you've built is actually beautiful and a pleasure to use. It almost feels like it's conferenceware, where it's designed to look good in demos rather than actually be usable, except that having played with it a bit, it is in fact usable. And it distills down to the EC2 instances that are in the environment. It tells me what's talking to what, on what port, any sudden spikes, any anomalies. And then it highlights a bunch of different rules here.

And I'm seeing all of this from a purely network perspective. Now, that's great. You can talk to folks about all kinds of tools that do this stuff. All right, so effectively you're implementing Wireshark as a service. Okay, that is certainly a way to think about it, except it's being captured via VPC mirroring.

There was no configuration required on the instance itself. It's something that can be done account-wide. It's something that can be enforced via SCPs within AWS organizations. It's something that can be enforced via SCPs within AWS organizations. It's something that is not, no matter how thoroughly I subvert the EC2 instance that this thing is running on, even if I subvert the entire AWS account itself, as long as I haven't been able to lateral into the management account for the AWS organization itself, you can't turn this off. And it shows up the truth that lives on the wire. Yeah, I love the way you said it. And so I'll add to the wire shark metaphor here in a moment,

but you're exactly right, Corey. One of the strengths, and I would encourage all the listeners, and you've got a very broad listener base here, right? So there's a veritable mix of different skill sets and folks at different parts of the organization. This is all fine. I would encourage everyone listening to think about the role of network visibility as it relates to your application and service delivery. And the network has a couple of unique, several unique properties. One of them is what you just described. It's very, very difficult to evade, and it's very difficult to turn off, and it's very difficult to manipulate. And if the network isn't working effectively, no cloud service is either. Oh,

it's doing an awful lot of calculation. Good for it. If I can't talk to it, what's the point? Exactly right. So what we're doing here, with the modern era of analytics and the state-of-the-art changing so rapidly in the last 10 years or so for network analytics. Think of millions of concurrent Wireshark sessions happening with this subsequent expert analysis and behavioral intelligence with behavioral security detections laid on top. And then if you need to investigate one of those detections that you're seeing right now, Corey, you click through, you see the asset involved, you see the transactions themselves that surfaced to the conclusion that the system came to. And so it's a very, very powerful thing

for just the detection and investigative workflows, but there are far broader use cases as well. The real value as well, I want to be very clear to help paint the picture here. You have a web server or an application server or a database server, if you're still running those yourself, given some of the database services that are offered. I can't say I fault you for that particular choice, but I digress. If suddenly those things start talking externally to random botnet command and control servers, for example, that's atypical behavior, and it's the kind of thing that you sort of would like to know approximately immediately.

It's the sort of thing that emerges of, this is an emergent, aberrant behavior, and it should be investigated. Now, the other side of that is, I set this up back at the beginning of the year. Thank you for the account. It's appreciated. And I wound up getting it dialed in on my environment, and I haven't logged into it in a few months. So now

I've logged back into it for this discussion. There are zero alerts waiting for me. And that's no small thing, because what I do on this development EC2 instance in this account is monstrous. There's no way around it. I install random stuff from Docker Hub, occasionally due to poor life choices, effectively the entire software security supply chain. Oh, that's a funny joke. I don't know anyone who is involved in any aspect of what runs in my stack. I may as well just open it to the world. I have my IRC connection living persistently on this box through IRC. It does a whole bunch of things and talks to other stuff because that's the way the world works. It's messy. When I set this up, it flagged those things immediately and I said, okay, don't alarm on the fact that it's connecting to Freenode with IRC. Great. It hasn't bothered me since as I continue to do monstrous things. There were no alerts waiting for me because the problem of not getting any alerts when things are going wrong is super bad. But getting alerts constantly when things are normal is in many ways worse because when

something happens, it gets masked. 100%. Yeah. So what you experienced is the power of the state of the art of network analysis. And behind your instance is machine learning that runs in the cloud at scale. And what that means is that the system that you're running in your environment right now, Corey, is able to extract, observe transactional features that feed the machine learning. And so initially the IRC were like, wow, we don't normally see this dude. And you're like IRC, we're like, wow, we don't normally see this dude. And you're like, no, don't worry about it, ExtraHop. So what we learn is that

is normal behavior in your environment. And there's just a plethora of different use cases and different machine learning models and implementations. That stuff doesn't really matter for the purposes of this conversation. Suffice it to say, when you think about the network, just if you're looking at it through the pure lens of as a data source itself, well, what kind of data, what sort of information could I mine from that data source? And the answer is, it's staggering. So then the question becomes, how do I present it, which you mentioned earlier, with our UI? There's been a ton of R&D that we've got this wonderful R&D team.

And the UX team has done a great job at distilling the information down that we surface, because we're just analyzing just insane amounts of raw network data in a given environment every single day. So then when you overlay machine learning, it really helps to sort of, you know, there are certain things that machines are really, really good at doing. and extracting features and analyzing those features for real behavioral

analysis is one of them. I also want to point out as well, because again, I approach the entire world through a lens of AWS billing, and there's an awful lot of solutions out there that give horrifying impact to the AWS bill by deploying them to the point where you start doing a cost benefit analysis and realize, huh, I'm reasonably certain an actual data breach would be less expensive. And you wouldn't be far from wrong. I just pulled up last month's bill in the account this is running in, and sure enough, the traffic mirroring that is what powers your solution is a third of my bill. But I want to say that that third of the bill is $10.08. And that does not have traffic volumes attached to it. It is strictly a per hour, one and a half cents per

hour that it's attached, the end. And I've got to level with you, if $10 is meaningful to monitor what's going on on the network in an account, I don't know what to tell you other than perhaps you are not the target customer. And I want to get into that a bit with you because I've long held the opinion that there are different onroads for different companies at different times throughout their growth to start working with vendors. Who should be reaching out to you folks? And more importantly, at what stage of the development process does starting to engage a solution that looks at the network traffic and cares about network visibility make sense in the modern era? Very high-level guidance is this, is that if you

have any infrastructure as a service running in your environment of consequence with risk associated, critical assets with critical services, generally speaking, Corey, it's worth reaching out to us about whether it's cloud or enterprise or hybrid, you know, sort of combinations therein. If there's a network to monitor, we will do that and we don't discriminate in that way. So it's very, very useful also for the enterprise cloud journey folks out there. And there's a lot of them at various different stages. If it's early stage, there's the sort of assessment, the security controls that need to be sort of moved up into cloud.

And a lot of the executives that I talk to, I'm fortunate I get to talk to CISOs and VPs about this exact scope of concerns. And many of them, their feet really aren't firmly under them when it comes to cloud. They've got their enterprise environment locked in and they've got their security controls well-defined, but DevOps is moving and the agility that they're gaining from the cloud, it's moving so, so fast that the CISOs are kind of caught flat-footed and they're not exactly sure what this thing should look like in the cloud. And so for the enterprise folks on the journey into cloud, digital transformation, whatever

buzzword you want to throw at it, that's another wonderful target account for us. An observation slash analogy I've been making for a little while has been that imagine tomorrow I go and I file the paperwork to start Twitter for pets. I already own the dot com, but now it's a real business. And in the next 10 years, it's going to become an S&P 500 component where, great, it has gone from ridiculous social network for pets to consequential social network for pets. And as it grows from ridiculous startup to large enterprise, there has to be a reasonable on-ramp for folks, given the sensibilities of how companies work today. It can't be an enterprise transformation story because anything I start tomorrow is going to be born in the cloud anyway.

And it's no guarantee, or honestly not even that likely for a lot of these use cases, there will ever be a physical data center component. There has to be a point at during that company's growth where there's a natural on-ramp to use a vendor's product or service, because if there isn't one, they are fundamentally serving what is in the very long term, a market that is in decline. And that's always the sort of thing I look forward and cautious about. We wouldn't be having this conversation if I thought you didn't have an option for folks who are in precisely that position. How do you think about that? Well, no, it's a really interesting point. You've got a very unique voice in the space.

Before I continue, I really like the particular angle you're approaching these problems from because these are conversations that have to take place, right? So the operational concern itself bears a certain cost and a certain level of risk and a certain level of opportunity cost. And you're exactly right. At some point in the story arc of a cloud or business's experience as they grow into this,

there's a point of diminishing returns with native tooling or hand-rolled tooling. And you need, beyond a certain point of scale, you need to actually fall back on more broad-based utility, broader coverage of the security requirements, the coverage of your security policy and your controls, and just better alignment. And in many, many cases, that will be vendor-led, and that's okay. But you're exactly right. There is a point beyond which you're really going to want to engage with experts in that particular domain because it's not cost-effective to do so yourself.

One of the most blatantly wrong things that I hear from the world of cloud marketing comes from AWS itself, which is there's no compression algorithm for experience. There absolutely is. You don't have to build all of this stuff yourself from scratch. You can compress that experience into hiring experts who are good at that sort of thing, either as employees or consultants. That's why advisory consultancy is a thing. You can buy products and services that compress all of that hard-won,

hard-fought experience into something that you can buy off the shelf. And it solves the problem far more effectively than you're ever going to be able to build in-house. And that's a valuable and powerful thing. The hard part, of course, is in the security space, you can effectively spend infinite money on security. And even then, there are no guarantees. So it's challenging as companies grow, especially in the early days, to make security a priority because it's always something we'll focus on later until suddenly you really should have been paying attention and now it's too late. Yeah, this is a big one. And I understand how that comes to pass, Corey, as do you and everyone who's listening.

Like, it's very easy to rationalize yourself into that place. And it's very understandable. And in fact, I myself have done it in my past as my prior life in operations. And there is a certain point beyond which the risk calculus alone and the impact of that, it just reverses the polarity of that whole discussion. And then the worst case is something bad happens to you when you've been in limbo before you've implemented your security. We've seen, unfortunately, we've seen this happen with several organizations where they've decided to just freeze budgets on security, whatever, and then bang, there's a compromise and they end up on the news.

I've seen this several different times in the last year alone, as a matter of fact. And so this isn't fear-mongering. And I want to, Corey, part of your brand is calling out things as you see them. And so I think that one of the unfortunate things about the security industry at large is there's lots and lots of fear-mongering, right? And I'm not doing that.

Instead, I'm saying, understand your risk and understand that calculus and your appetite for impact. Let that be your North Star as to when to really get serious about your security controls. And that might be from inception, by the way. And that's a great answer. To an earlier point, it might be a risk that you're willing to make up until some sort of financial threshold beyond which you're not willing to appetite that's a unappetizing risk beyond that forget dozens of visualization tools and view your entire system in one place with new relic explorer the latest addition to new relic one see your system-wide

health at a glance with a dense hex view that has your hosts services containers and everything else you probably shouldn't be monitoring but are anyway, and get in a statewide view of sudden changes so you can theoretically catch issues before they impact customers. But let's be serious, you aren't checking your dashboards until 20 minutes into an incident that has been impacting customers for half an hour beforehand. So go to newrelic.com, sign up for free, and start exploring your system today. Be sure to tell them I sent you so that they can facepalm mightily. It really comes down to risk management. I mean, one of the reasons that I focus on the AWS bill is that that is almost ever a company-ending event. It's, oh, I spent too much money as the cost of not focusing

on it sooner. And that's almost always both okay and survivable. In the absolute worst case of, wow, we normally have $1,000 a month bill and we just got charged $800,000, AWS is a company that understands the longer-term view. You can reach out to them and get it fixed in almost every case. Security does not work that way, and it's much

less tangible as far as being able to sell something effectively into that market. In fact, one of the problems I have is walking around the RSA Expo Hall whenever I was able to do that in the before times, last conference I went to before this whole thing started. And you see what feels past a certain point, the same product being offered again and again and again with different logos and different company names, but the messaging is the same, and it's incomprehensible, and it just looks like there is no winning here. I found that ExtraHop was a breath of fresh air comparatively, but I'm not going to lead you that far down the road. Tell me, what separates you folks out from the industry at large? Not specific vendors,

because no one's going to look great smack in the competition, but there's something refreshing about your approach and how you talk about your approach. Where did that come from? It comes from our pedigree of being network deployed, buted, but application-fluent. So here's a fun fact. So our co-founders years ago invented the modern-day application delivery controller, specifically at F5 Networks. And this was a long time ago, right? So in Inso doing, that device is a very, very, it's a network-deployed device that's deeply application-fluent.

And all of that domain experience and all of that sensibility towards scale, the ability to see inside decrypted packet streams and do analysis, all of that made its way into our product and then fed the beast of network analytics. And our worldview really is steeped in this idea of just network analysis and the various outcomes that you can glean from said analysis, like behavioral detections for security, like asset inventory, your security controls, the visibility that you cited earlier, Corey. It's like many environments, they don't know what's running. And the network will tell you what's running in a way that's deeper than just like the

management console listing the assets and services that you've got, right? And so now down to even the transactions, what types of services, what's the consumption model of this? Who's consuming it? Where's the traffic going? And is this normal? Yes or no? So that's really what makes us different.

Most of the folks in our space focus solely on detections and we believe that the network as a data source can give you much, much more value and so we strive to deliver that. There's an awful lot of value in being able to deliver value upfront and getting customers who have worked with you before to say, yes, this thing is amazing.

And I have problems with that in the space that I'm in, because it turns out that there is a perception that I disagree with, that fixing bills or talking to someone about a cloud bill that was high is somehow a ding on the company. And it's not even about being high. It's about having a lack of visibility or understanding in many cases, but people don't want to talk about it. It's hard enough to get testimonials and logo rights in that context. In a security space, it feels like we are thrilled to wind up buying your product now that we see the value of it. If you ever mention our name in any context ever

again, we're going to drive a wrecking ball through your corporate headquarters, legally speaking. How do you get past that? It's understandable, first of all. And you're right, Corey. In large part, folks are not super eager to talk about security in a very public way. And that's okay. I wish that there was more of it, though, not as a vendor representative where we would be the beneficiaries of it, but just more sharing in general really, really needs to happen. And what we're seeing instead is the big disclosure and the big tech talk like last year with Sunburst, right? It's monster in his catastrophic affliction leveled on the industry. And it was a single point of disclosure, which is wonderful. And then the sharing started. And I feel like there's a lot

more opportunity for information sharing, even with the current frameworks that are out there. There are vehicles to do this in a formal way for a given industry, but we need more. And you're exactly right. It's discussing the state of the art and threats and, God forbid, attempts at compromise or full-fledged compromise. There needs to be more of that so we can collectively level up. I'll even name names on this because I am not a security vendor. The Capital One breach a few years back was fascinating for me because it wasn't just that they had done things badly or irresponsibly, didn't read the instructions on the tin. It was a series of chained together exploits. There was a exploit in the web application firewall, I believe, according to court filings,

that allowed someone to get a foothold. From there, there was an overbroad instance role that allowed them to get access to an S3 bucket that they should not have had access to from that account. It was tying together different things in different ways. And that, in turn, is the sort of attack that is not easy to see coming. And there's a lot of things

you can learn from that. I'm sympathetic to it. The problem, of course, is that first, they're a bank and the lawsuits and the rest means that Capital One at that point, whenever the word cloud comes up, felt like for a while they just put their heads down. There were six more weeks of no talking about cloud whatsoever because they didn't want to talk about it at all. But that's the sort of thing where we can all learn so much from what happened. But the instinct is to button up and never say a word about it, which means that the only people who are able to really go in depth on this is, in fact, security vendors, with the counter argument that as soon as you start talking about that in your marketing, you get accused of

effectively ambulance chasing or that you're using fear, uncertainty, and doubt to wind up selling your products. And yeah, a lot of vendors do exactly that and it's awful, but there are valuable learnings here. And it's not just a sales opportunity for a product, but rather an opportunity to uplift the entire ecosystem. Yeah. And to the extent that the security market in general is a very vendor-weary market as an audience. And I understand why. I was on the receiving end of vendors as well back in my prior life, as I mentioned. And I understand that. And to that, I would say is make us prove it. If there's a decision to be made and you've deemed it necessary to engage with us, then as a good security buyer,

make us prove it. And there's many, many, especially in the cloud area, there's many vehicles at your disposal to test the claims of any given vendor with any given approach, whether it's, you know, a SIM with log analysis or endpoint or network or beyond, right? So, you know, make us prove it. And then you'll get a line of sight to whatever claims are being made around catching breaches or understanding behaviors or beyond. So with all of that in mind, and obviously the way that things used to be and how all of this stuff would tie together, it feels like the old answers aren't right for the new era. So from that perspective, in a more forward-looking sense, what does strategic security tooling look like

in this cloud era that we all find ourselves, willingly or not, enmeshed with it? Okay. That's a super important fact. That's probably like, you've asked a bunch of good questions. This one's at the top of the list as far as I'm concerned. So when you don't know a lot, you get very good at asking good questions because that's how you fix that problem. Amen. I ask a lot of questions myself, so you're in good company. So one of the problems in the traditional terrestrial enterprise is that their tooling strategy looks like a shotgun blast. And that shotgun blast is comprised of point solutions that are loosely federated at best, at best. And the only point of integration is the swivel chair

that an analyst would sit in, or a site reliability engineer or DevOps person. Don't forget the screens upon screens upon screens that show amazing things when someone walks by. But if you think about this for more than half a second, you realize people are going to wind up with repetitive strain injuries from trying to pivot to look at all those things on the screen. And wow,

maybe that much thing to look at all at the same time would be incredibly stressful and unpleasant when you're getting a sun tan from the monitors. That's a problem. No, that's exactly right. The big board of the past in the terrestrial data center, the security operations center or the ops IT center, whatever fishbowl we used to call it and back in my old place you know that really does point to the legacy era now if you hoist that exact same model up and into the cloud or especially in hybrid environments because most or many i don't know about most but many are in this sort of transitionary state they're multi-cloud a or they're at some stage of cloud

adoption with traditional enterprise workloads, right? Well, now what does tooling look like? Because we have a management plane that can do really, really intelligent stuff. And the APIs are very, very consistent. They're very actionable and they happen pretty quickly, not as quickly as I would like sometimes, but these events are easy to trap and they're easy to act on. And so the modern era of security tooling is comprised of, think about your data along the boundaries of its data source. So for example, I care about my containers and so I want some sort of runtime container visibility. Or if I'm running EC2 instances, I want endpoint visibility, right?

Because I want to know what's running in resident memory or if it's whatever, malware, whatever, right? Then I'm going to log because you log a lot in the cloud, it turns out. And so I'm going to need some way to make sense of those logs and wrap that into part of my practice. And then lastly, I want to have visibility into the network because of the three things that I just described, endpoint, say, or agent-based approaches, log-based approaches, those things can be evaded.

They can be disabled. They can be turned off. And in fact, we saw evidence of that, very active evidence last year with Sunburst. And the network is the only one that's truly covert and difficult to evade, manipulate, or disable. And so as part of this collective strategy, now you've got, and we're very complementary to one another, logs are complementary to us where we leave off, as well as endpoint and vice versa. And so we call this the cyber triad. And this is not just our terminology, it's analysts and others that are out there.

Always good when you hear the buzzwords and they didn't come directly from the vendor. In this case, it's not a buzzword. It's actually a genuine strategy because we tended in the past, we haven't thought about our security tooling from a strategic sort of data source perspective. And in the context of cloud, especially, you can wield these data sources in some really, really powerful ways. And in the DevOps or SRE sense, you can do this event-driven security model now where the tooling itself can emit events into the management plane of the cloud, and the cloud in turn can take intelligent action. It's a beautiful and devastatingly powerful new era for real-time security response.

So now in the past, Corey, I would quarantine a process on a system, or maybe if something was really, really bad in a terrestrial, I would just disable that, block it. Maybe I would do virtual patching on the firewall, where I would disable a given service on the firewall. Well, now in the cloud era, and your audience understands this super well, I just call the management plane and redeploy the container. Done. Golden image.

It's fresh. It's clean. I've got, it's got attribution. And I know that if that other one was compromised, I'm just going to get rid of it because cloud and redeploy this thing right in its place. It's beautiful. And so in the modern era, the cloud itself unlocks a set of operational models for security that are really difficult to achieve. Otherwise, it's not

impossible. There's a whole industry dedicated to it. But in the cloud era, it's much, much, much easier. And it's easier to wrangle. And you can hoist it higher up into the dev lifecycle, the CICD lifecycle itself. So it's a really nice time for security ops. It really seems to be. Matt, thank you for taking the time to go through the sometimes befuddling world of InfoSec, especially from a vendor perspective. If people want to learn more about you,

what you're doing, what you're up to, where can they find you? Well, they can find us at extrahop.com. And we've got cloud case studies, use cases. In fact, we've even got an eval that's out there. We've got a live, it's running in the cloud, actually, a live demo where you can sign up and experience the system running in the cloud before your very eyes and see the type of visibility gains you can get and network analysis manifest,

really. It's a real live system up there. So I would strongly recommend that if anyone's interested to have a look at that, because it's quite a powerful model, in my opinion. And if folks have questions, too, feel free to direct them my way. Because remember, the one thing that is never for sale here is my authenticity, for better or worse, which often gets me into serious trouble. Matt, thanks for taking the time to chat with us. I really appreciate it. Yeah, likewise. It's been a pleasure, Corey. Thanks so much. Matt Cawthorn, VP of Security and Cloud at ExtraHop. I'm cloud economist Corey Quinn,

and this is Screaming in the Cloud. If you've enjoyed this podcast, please leave a five-star review on your podcast platform of choice. Whereas if you've hated this podcast, please leave a five-star review on your podcast platform of choice. Whereas if you've hated this podcast, please leave a five-star review on your podcast platform of choice, along with an insulting comment that you will later be able to disavow because no one was tracking what was happening on the network, so it must just be an application bug. If your AWS bill keeps rising and your blood pressure is doing the same, then you need the Duck Bill Group. We help companies fix their AWS bill by making it smaller and less horrifying. The Duck Bill Group works for you, not AWS. We tailor recommendations to your business and we get to the point.

Visit duckbillgroup.com to get started. This has been a HumblePod production. Stay humble.