Name: Extending Zero Trust to Enterprise File Data: A Modern Approach to Resilient Storage
Uploaded: 2026-03-31T18:16:13.865Z
Duration: 50 min 52 s
Description: Extending Zero Trust to Enterprise File Data: A Modern Approach to Resilient Storage

Transcript for "Extending Zero Trust to Enterprise File Data: A Modern Approach to Resilient Storage": Alright. Looks like we're all here. Hello, and welcome. My name is Ben Fuller, field CTO at Nasuni. I'm joined by my friend and colleague, Scott Gass, senior solutions engineer at Nasuni. And we're here today to talk with you a little bit about zero trust architecture. And interestingly enough, as Scott and I were preparing for this, we had some very apropos and timely events take place, and that was the very large scale attack that took place at Stryker. So we figured we'd pull an audible. What better way to bring this really down to the ground level, but talk through an actual event, and talk through zero trust and how we might align that to defend ourselves, against future attacks that, are similar. Scott, before we get right in, why don't, you give a quick background on yourself? I know you've been in this space for a while, so I'd love to give you the chance to introduce yourself, sir. Yeah. No. So thanks, Ben. So as Ben said, I'm Scott Goss. I'm a solutions engineer transformation architect here at Nasuni. Prior to Nasuni, I worked at VMware for the last twelve years, primarily in the networking and security space. So I've been doing zero trust literally since it was invented by VMware. I was working with Forrester researchers when we were coining the the frame zero trust network architecture. And I spent most of the time actually, almost all of my time at VMware selling and deploying zero trust network architectures for some of the world's largest organizations. So it gave me a pretty broad background and understanding of the importance of ZTA and specifically how it can help our customers protect against these types of events. Yeah. Absolutely. And, obviously, ZTA kinda growing up in kind of the network space with micro segmentation kinda where it got its legs. But I think what you'll hear today and see certainly with this attack that we're gonna give you an example of, zero trust is much more than security, much more than network, much more than any one of these different fiefdoms, these, you know, disciplines, if you will. It really is a mesh, all of these together, a layered defense, if you will, and we'll talk through that in detail. So here's a little brief look at the agenda. We're gonna go through the striker attack. We're gonna talk about, hey. What exactly happened here? How did it happen? And and what was obviously the impact of what transpired. Gonna kinda reset on zero trust architecture. What is it? What does it mean? What are some of the core tenants of zero trust and and how I can implement that throughout my own environment? And then really get into the bowels of infrastructure and talk about how zero trust needs to align more importantly to the data layer now than than ever before. And really having a data foundation that has zero trust built in is really something that's very important moving forward, assuming breach at every layer and and having that defense built in, not just in the environment and throughout the infrastructure, but also certainly in the data storage layer. We'll we'll spend a little bit of time talking about business outcomes. You know, a lot of folks the the decision to act happens after the event. I think what we're we're trying to signify here and show you really is you need to act before this costs a lot of money for the business and the organization because the the savings is real. You know? Implementing this might be seen as, like, kind of an upfront cost, but the reality is one breach, one attack, this type of solutioning really pays for itself. And then if we have time, we'll we'll we'll talk through any q and a. I'll try and keep a a good look at the q and a throughout the session here, and we'll we'll try and read those in the conversations as they come up and and certainly be vocal. So, Scott, why don't we jump right into it? The Stryker attack. Let's go back in time, getting our time machine, March 11. So this is now twenty days ago. We were we were rather lucky and fortunate that Stryker was very transparent with what happened here, and I think you'll give us a little bit of reasoning behind that. But they really did give very great visibility into what happened, and we're gonna be able to kind of take a a play by play of exactly what transpired. So let me go ahead and pull this up for everyone to see. And, Scott, why don't you jump in here and talk a little bit about exactly what happened at Stryker? Yes, sure. So it's like you said, Ben, it's really appropriate topic for for this specific presentation because it it signifies a pretty significant shift in industry attacks. So prior to Stryker, I would say 99.99% of attacks were for financial gain, where, you know, the files were encrypted, the drives were encrypted, data was stolen, and it was primarily for ransom. And I have no inside knowledge. Right? This is all supposition. But I believe that Stryker came forward because this attack signified a foundational shift in cyber warfare. So we went from cyber attacks to cyber warfare. So this is one nation state that's actually waging war against another nation state and trying to take out infrastructure. So if you look at the striker attack, this was not about encrypting data and gaining ransom. This was about destruction. And that was what's most terrifying as a security professional to me is, you know, in in the past, people were like, oh, I have I have cyber insurance or we'll just pay the ransom. We'll get the data unlocked, and it'll be fine. Well, this was a destruction event. So their goal was to take out a player and do real damage. So if you look at how the attack unfolded, it's classic. Right? There's there's nothing special about this, And that's what's so terrifying. Right? It's not only would is it not some sophisticated attack that was using sophisticated malware attacks or rubber duckies in a in a parking lot. This was just good old fashioned brute force social engineering. Right? So the attackers, according to CrowdStrike, they could see that there was a increase in attacks on Stryker in the the days preceding the event. And what the belief is is that the attackers had actually been in Stryker's network for some period of time. Right? And it's not unusual. So when I was doing this ten years ago, I was in a session held by Forrester, and the Forrester researcher had been part of a forensic analysis team for a company in Europe. And he said at the time, they found that the average time a hacker was in your network before you realized it was nine months. I think we've we've shortened that time span. I think, Stryker, it may have been three to four months, possibly less. I don't know for sure. But, you know, it's still a long time for people to be poking around in your drawers looking for your jewelry. Right? So just having that kind of unfettered access lets an attacker do a lot of different things. Right? In the case of the Forrester Researcher, those attackers were so brazen, they were frustrated by the rate at which they were exfilming data. So as they socially reengineered the Cisco TechX authorization, gained access to the network, and then they socially they they reengineered the physical network so they could steal the data faster. The company figured out something was going on when they started getting calls into the into the call center saying, hey. Look. I don't know what guys did to improve the network, but, man, everything is working great. Right? And that set off alarm bells. So these attackers really can get in there, and they spend long periods of time. And, again, prior to Stryker, primarily what they were doing is they were going out and they were encrypting the primary data, and they're waiting for a trigger event. And then they're going out and they're encrypting, you know, n minus one and n minus two and n up to n minus 10 backups so that there was no fallback for these companies that had their data encrypted. Right? So as I said, this was a this was a fundamental change in how that happened. So in this case, they were in there. They're able to execute a a man in the middle attack. They're able to gain the the credentials for an Azure AD admin. And then from there, it was just standard privilege escalation. Right? So I said there was nothing sophisticated about this attack. This was just an old fashioned social engineering brute force attack. So once they got those Azure credentials, then they were able to escalate up to an Intune administrator. From that Intune administrator, they were able to exfil about 50 terabytes of data. And then once they reached whatever limit they had determined, whether it's fear of getting caught or maximum amount that they wanted to steal, then they started this mass delete. So from that, they used the the godlike power of the Intune admin account, and they'd executed a mass remote wipe of 200,000 devices. So that's pretty significant. Right? That's that's a lot of data. And the white wasn't even geolocated to a specific area. This was across 79 countries, and it was it impacted 56,000 employees. This is not unlike in scope a a customer now that was not a customer at the time. They were a large well, they are a large European company. They have, you know, 900 plus sites around the world. They had a CryptoLocker attack, and they were idled for probably thirty days because email was encrypted. Their shared drives were encrypted. They were doing paper backups until they could get systems recovered. And even then, it was a slow recovery process. So this is this is a very impactful attack. As I said, it was made more impactful because of the way it was executed in terms of deleting data, not just encrypting it. So, you know, no malware was deployed. They weaponized their own Intune platform against them, and they just used basic hacking techniques to try and and execute this attack. So it was a it was a very sophisticated attack. But as we'll talk about, ZTA would have made a pretty big difference, maybe not in terms of preventing the attack, but certainly in terms of limiting the scope or the blast radius as we like to say. Yeah. That's one of the immediate things that comes to mind for me is, you know, how does, you know, a global admin, even at at a privileged level, have such, such power to go and, you know, there's not some sort of safeguard or approval group or authentication. And I think what we found is in Intune, there is this idea of approval groups where there could have been some safeguards set up to prevent a a wipe of this scale or some type of audit or suspended animation could have taken place. But in reviewing the literature, it looks like in some cases, there is an admin, right, that can modify those approval groups. So, you know, it would be as if, hey. I wanna wipe these 200,000 devices. Scott and I both have to approve this. Well, if I'm having a bad day, I can just go into their approval group and remove Scott. And I I would suggest that's probably effectively what happened here. I'm certain that they probably had safeguards built in. But one of the core tenants of zero trust architecture is to assume breach. No longer are you living in this, you know, walled garden where we're gonna have firewalls and prevent every intruder from from entering. We need to assume that they're already inside our network and have protections and safeguards and verification every step of the way. And that includes right all the way down to the data foundation layer here. Exactly. So we'll spend a moment here talking about just the impact here. Right? I think it's quite obvious, but you can you can kind of expound on this. You know, the impact is is massive. Right? And I and we're not even talking about the potential brand impact and impact to the business from a from a real social marketing perspective, but really just the actual hard dollars here. And, Scott, maybe you wanna go into this a little bit more detail as well. Yeah. So this is the other thing that's that's kinda terrifying from a security professional perspective. As I said in the past, you know, it was it was encrypted. You had to pay a ransom, you know, a couple $100,000, you know, and call it a day. So this was this was substantial in its impact because in the course of the trading session, Stryker stock dropped 9%. So the total the total market cap erosion was between 6 and $8,000,000,000, which is massive. This is the kind of event that gets people fired. Right, because it's a breach of fiduciary obligation to your shareholders to allow that to happen when something like ZTA exists that could, in theory, prevent or at least mitigate the amount of damage. As we said, it was 200,000 devices across 79 countries, so this was not even something where it was geolocated. And in the past, what we saw with attacks was as different areas of the world came online, we would see the attack perpetuate into the new time zone. This was pervasive. This happened across almost 80 different countries. And then just the the scope. Right? 56,000 employees all idled at once because all of their devices were wiped. So it's it's it's pretty significant. Right? And then you look at the the revenue at risk. Right? So, you know, we talk about market cap decline. We talk about devices wide, but we didn't talk about what was what what's the ongoing operational cost. Right? So if you look at this from a manufacturing perspective, if every hour a large manufacturing plant is idled, you're talking about millions of dollars in revenue lost. With So Stryker, you could be looking at a potential of 25,000,000,000 in revenue at risk just because of the disruption. Yeah. That's crazy that's crazy to think about, Well, honestly. and then, you know, to compound it, there's 50 terabytes of data that's out there that, if if these hacker groups ever get access to quantum computing, they can start to work and try and decrypt that data, and who knows what sensitive data was stolen. Right? So there's a lot there. Then on top of that, there's the weeks that it takes to recover. Because if you look at traditional tier one storage and traditional tier one backup recovery schemes, you're looking at anywhere from weeks to months in order to recover. As a VMware, and we're looking at Site Recovery Manager, even with NSX to automate the networking and the recovery, you're still looking at days or weeks to try and recover those systems. So and then, you know, in the case of somebody like Erie Hospital, they had an attack a number of years ago now where their servers were were wiped. The attackers went in and they executed an attack that basically crashed the drives. And Dell had to load up a trailer and send them all new compute to try and get them up and running, but they were on paper procedures for over a month until they could recover. So the impact is not immediate. It's immediate and it's lasting. And is the yeah. And I think that's one of the the big reasons why, you know, you need to look at zero trust architecture and extend that to to all bounds of the infrastructure. And most importantly today, in the data layer, It needs to be a first class citizen. It needs to be built in. It needs to be foundational. And if you look at a lot of the traditional backup and recovery, disaster recovery, data protection solutions in the market, they're brilliant at backing up data. Right? Yep. But they'll do anything but restore the data quickly. Right? They'll boot the VM up on their own storage to avoid having to resaturate all that data. So the argument really is that these traditional mechanisms leave a lot to be desired in terms of your mean time to recovery and certainly don't. really help with any type of detection or visibility of the event. And that's really what we're talking about, a defense in-depth strategy and really tying the zero trust architecture to that data foundation layer. So why don't we do this? Why don't we take a step back, and let's just talk a little bit about what the heck is this thing. Right? Zero trust architecture. I know it's went through a lot of revisions. There's been some releases from both the Oval Office through many different presidential terms in terms of updating some of the guidelines here in the architecture. So why don't we take a moment here and just briefly expound on what is this, you know, fairy tale thing of that that I hear people talking about zero trust. Right? One of the things you'll hear quite often is never trust, always verify. Right? Doesn't really tell you much more beyond the zero trust architecture name, I would argue. But, Scott, why don't we go through here? And I think maybe we would suggest these are kind of the the the six pillars of of. a zero trust architecture that you might look to enhance, implement, and certainly investigate as you look to implement zero trust across your environment as a whole. So, Scott, I'll turn it over to you again, sir. Yeah. So it's a good point, Ben. So there's an executive order, I think it was around 2014 or 2015, which was geared towards securing critical infrastructure specifically to prevent against the types of attacks that we just witnessed on Stryker. And then that executive order brought together a consortium of industry experts and educational experts to try and come up with what we thought would be the ideal architecture to secure an environment. Again, the goal being securing critical infrastructure. The executive order was extended to critical infrastructure suppliers to the federal government, so weapons manufacturers, defense contractors, power supply, everything. Right? So it very wide ranging. The outgrowth of that executive order was there are a few different architectures that have evolved, But one of the first ones was the NIST eight hundred-two zero seven, which is the ZTA. And it covers six pretty significant areas, right? One, which we saw with Stryker, was started out with identity and access, right? They're able to get in, they're able to engineer access to an admin account, They were able to escalate the privileges to get higher access to the point where they could do damage. What I did for most of my career was working with zero trust network architectures using VMware's NSX, where we were basically implementing firewalls at the NIC, the virtual NIC layer in the virtual machine. So you can't get any more micro segmented than that. The problem that we see today, especially in the storage arena, is a lot of organizations, a lot of storage manufacturers rely on external perimeter firewalls to secure that infrastructure. Right? Because thought had been for a long time that, well, if everybody's within the walls of the organization and we put firewalls everywhere, as long as they don't leave the organization, then they're secure. What that did take into account was things like remote work. Right? And, you know, there was kind of a joke that we told where VPNs are the superhighway into the data center for a hacker. Right? Because if you look at a lot of other attacks, they don't just they don't try to brute force through your firewall. They usually go through somebody that has access that is a lower effort, like a a third party supplier. Right? Look at Target. Look at Home Depot. Look at Sony Pictures. Right? I think the majority of those were all through a third party supplier. So you'd find who the weakest link is, you get your way in, and then you use VPN access to get into the data center. And without micro segmentation, the data centers were wide open. Even with perimeter firewalls, they're wide open. So the theory behind micro segmentation, which then grew out into zero trust architectures, is never trust, right, always verify, and then make each unit as small as possible. So a great example of why this works is there's a famous hacker named Kevin Bitnick. He was the guy who figured out how to hack the Bell network years ago and get free phone calls by by simulating tones. He was arrested eventually and and jailed. And when he got out of jail, he, you know, put on a white hat, and he started helping companies protect against people like him. So VMware had him look at a couple different providers we were working with and said, see what you'd see what you can find. And he said two of them, I was able to figure out how to get in. You know, I was able to socially engineer my way in. Once I got in, I was able to move my way around. I found all this stuff. But there was one, he said, I was able to engineer my way in, but then I was stuck. There was no firewall for me to circumvent. There was no security tools for me to root. He said, I was stuck in this container and I couldn't get out. That was the only one of the three that we told him about that had zero trust network architecture deployed. Right? So after that, while he wouldn't go and specifically advocate for our solution, What he did do up until he died was he did a world tour where he he advocated very strongly for zero trust architecture. Because to him, if it could thwart him, a world class hacker, then it could provide a lot of value to any organization that went down that path. So identity and access, micro segmentation, device posture. Just making sure that the devices have endpoint protection, that they're compliant, that you don't have one person who has godlike access to all these different devices. So try to limit the blast radius, try to limit who has access to what, and always verify that access. Behavioral analytics is something that's really evolving. Palo Alto has done a lot of work with this in their Cortex product. We also have integrated this into some of our ransomware detection where we don't look at known threats, right? We look at what do we see is occurring now versus what we know to be a normal state, Right? So anything that deviates from what we know to be good is unknown and potentially bad. So if I can layer in rich contextual data from multiple different sources and I can get a better view of what's going on in my environment, then I can make decisions in a much faster way. So one of the things we'll talk about is with NASUNI, how we can take our alerts and the things that we're seeing at the data layer, and we can feed it into the SIEMs and the SOAR tools for the different security providers, and we can give them visibility into an area that they typically do not have visibility into. And that's huge. Right? It's the proverbial canary in the mineshaft. If you see something in the data layer like a mass wipe attempt, you know something's going on in your environment. Likewise, if they see something somewhere else, they can shut it down before it even gets to the data layer. So we're trying to get this three sixty view of what's going on. Having an immutable data layer, like you said in the beginning, is key. This is the foundation for defense and depth. Right? It's the goalie in what pick your sport. Once you get past all the defenders, there's one guy between you and the goal, and that's gonna be whoever's protecting your data layer. And then what's controlling all of this is the policy orchestration. Policy orchestration is probably the most important part of the zero trust architecture, because policy orchestration lets me take and orchestrate the policy across all my different security tools to make sure that my security posture is compliant with zero trust architecture and that I'm always executing my policy accordingly. So these these six pillars are very, very important when they're when they work in concert with each other. Yeah. And I think that's one of the biggest takeaways probably for our audience here today is is zero trust is less about a single tool, a single silver bullet. It really is about going the extra layer deep in every single discipline, in every software solution, in everything that's integrated into the environment, into the infrastructure. It's to assume breach. Assume they got through the firewall. Assume that they got through into the network that they needed to. Assume that they have privileged access. Assume that they have root. Right? What if at each level of the stage and, really, that's what you'll see in a lot of these CMMC audits. It's not a function of a single activity or a single action that you can take, but really a coalescing of a lot of things that you need to layer in defense of the environment, in defense of the infrastructure here. So why don't we make this real? We're talking a lot of wishy washy, you know, high level concepts here. Why don't we go right into the striker attack step by step, and let's try and play out how zero trust might have prevented, thwarted, mitigated some part or maybe put up a, you know, a warning flare. It's some part in the attack so that we could see, hey. Something's happening here or potentially something that would cut that access off and and potentially limit the the blast radius as you said. Yeah. No. It's it's it's a it's a great point. Right? So if we start with the architecture of this specific attack, just the initial access. Right? Setting up a phishing resistant multifactor authentication to try and prevent this type of attack on the Azure admin account and then the escalation of privileges. Right? What we're saying here can they already had sorry to cut you off. So. what we're saying here is, hey. They already had MFA in place, but did. this MFA was compromised in effect. Exactly. Yep. And that there there are potentially ways to further protect that environment is your suggestion here. There's a way to implement MFA maybe in a more secure fashion. Yeah. So I think there's there's any number of things that we can do. You know, FIGHT o two, the efficient resistant MFA, is certainly an improvement over standard MFA. Right? But everything with security comes with a cost. Right? So there's the cost in terms of the product, and there's the cost in terms of time to deploy, and then there's the cost in terms of trying to learn learn it and operationalize it. Sure. Right? So as an industry, we tend to lean towards what we know and what is comfortable to us, and ZTA challenges that. Right? Because it forces us to always evaluate what tools do we have deployed, are they the appropriate tools, and can we do better? Right? So having MFA up until now was usually pretty good. Right? But now we found that MFA in this case failed. So we need to look at now what's what's the next step in MFA? What's a better version of it? So something that will that will block conditional access of strong credentials. Right? So. it it that plus just the structure of the IntuneEd account. Right? Setting it up so that one person can't control everything, that one person can't delete another approver. Right? Setting it up so that you always have multiple people that have to provide conditional access in order to execute something like a mass delete. Yep. And I think that's I think that's the big takeaway there. Right? Here is, hey. We gotta there are ways. They may be annoying in certain cases. Right? But we need to implement conditional access procedures. That is I need. to ask for privilege escalation. I think Scott and I, in getting ready for this webinar, needed to prove this webinar platform so that we could use the accessibility options. Well, guess what? We don't have full admin over our device anymore for obvious. reasons. Right? We don't need to go in and modify mass amounts of system settings. We had to go in and request access, and it was granted to us. And we could activate it and use it for a specific period of time. But that type of control, especially for high end operations like this, could have potentially thwarted the activity altogether, especially. if that request has to go through a SIM, through a SOR, through a set of eyes, Yep. through a system where people look and see what the approvals are. Woah. Woah. Woah. Woah. That doesn't you know? So anything that could potentially limit this, I think. And and here, specifically, in the initial access, we're talking about better MFA. We're talking about conditional access. We're talking about not just role based access because certainly that was in play here. But we're talking about potentially administrative accounts with very least privilege and and. privilege only in an elevated manner when needed. So go on. here. Why don't we talk about the. the. match? It was escalation, which was the next part. Right? So somebody the the attacker got access to the to the admin account, then they use escalating privileges to get access to the Intune administrator. Yep. So under ZTA, admin roles have zero standing permission. Right? So activation always requires approval. So just that simple change could have made a huge difference in this. Right? I mean, it's hard to know, obviously, you know, looking at this forensically. But knowing what we know about zero trust and knowing what we know about a properly executed defense, these mechanisms could very could very easily have prevented, if not mitigated, this attack. The mass wipe execution. Right? As I said, we as an industry have been, I'm gonna say lazy, but we've been leaning towards convenience. Right? It's convenient to have admin access to stuff to get what you need done. Right? And for a long time, it's worked just fine. Right? We've not had issues with it. Well, now all of a sudden, it is a problem. Right? We can we can no longer, as an industry, grant unfettered access to individuals even absent an external attack. You brought it up earlier. What if there's a disgruntled employee? Right? Disgruntled employee that has godlike access to an admin account can do significant damage before it's caught. So, zero trust says, no. We don't have the standing permission anymore. Right? That's everything has to be approved. So like you said, always never trust, always verify. So when we get to the mass wipe, just having multiparty approval. Right? We know Intune has that capability, but we're assuming based on how it was set up was how this was executed. They either didn't have the multiparty or they did the attackers were able to circumvent it somehow. Right? Yes. But having multiparty approval can make a huge difference in terms of preventing this. Absent that, having tools like our ransomware protection that can detect a mass delete event and then quickly cut off the IP address is is, again, that goalie in front of the goal. Right? You slip past the defender, I got one last thing to protect the data before it gets wiped. So but multiparty approval could definitely have made a difference. You know, you opened up with micro segmentation. Right? Micro segmentation at the the MDM plane, right, the managed device plane could have made a big difference. Right? One of the things that I did with ZTA at VMware, and I fought the the MDM guys every step of the way because they I I got, quote, in their way because of my security stuff. But what I kept trying to explain to them and explain to customers was having everybody in a single domain opens you up to incredible amounts of risk. Right? Having your remote users have access to everything in the data center opens you up to incredible risk. You have to reduce that scope of what they have access to to only what they need access to. Nothing more. Right? Yep. So back to the never trust, always verify, limit what people can see to only what they absolutely need access to. Yes. Yep. It can be frustrating sometimes like you and I found when you need to do something and you can't, But, you know, it's a small price to pay for for the security of knowing that we're not gonna face a 6 to $8,000,000,000 market drop. Right? So there's a lot of different things we can do there. You know, having the behavioral SIEMs that are monitoring everything in real time, that are collecting the the the data and building that rich contextual environment can make a big difference. Right? Having us be able to feed alerts into a SIEM saying, hey. Look. We're seeing something going on in the data layer that's a little hinky can alert the SIEM that something's going on here if they can correlate it across multiple different domains. Right? So let's take a look at persistence. so let's take? a look on the big one. in the interest of time, I gotta. keep us moving here. So let's take a look at the overall. This looks a little bit like an eye chart here. I think we just want to flash on the screen to kinda show you potentially where does NASUNI fit in this whole zero trust architecture. Right? Where does the data layer come in? There's a lot of stuff. There's a lot of minutiae that we talked about, different areas of the environment to secure, different, considerations to take. But I think one of the core tenants really is assume breach. Right? Always verify, never trust. Right? Continually verify. Right? And, really, at every step, there needs to be a potential safety mechanism in place. And I think if you look at a lot of the, data infrastructure solutions that exist today in the market, you'll find that they're almost expecting something else to worry about that. Right? Data at rest encryption isn't even a given. Encrypted backups is not a given, and we live in 2026. Right? Separate data plane and control plane doesn't exist in a lot of solutions. Backups and primary storage are oftentimes commingled. We've got our our primary device replicating in real time to our Doctor device. Right? So we've got a lot of things that are set up that kind of assume something else is gonna help us. Something else is gonna tell us where we need to recover from, where we need to recover to, what we need to cut off, what destructive behavior is happening. And I think our argument here is you really need to have this built in is really a part of the solution. The solution needs to implement zero trust in intrinsically within the solution. And if you take a look at, really, Nasuni, it provides a really foundational layer for zero trust. One of the core things that Nasuni provides is an immutable worm file system. That is to say that everything we write on our file system is an append. It's a net new data object. It's a net new metadata object. So right at the foundation, we have a built in mechanism to kinda prevent a mass deletion, a mass wipe event. So let's play it through here. Right? We've got our ransomware detection capabilities. We've got our SIM. We've got our SOAR. We've got all these things deployed, but somehow they've gained elevated access to the environment. Somehow they're in, and they're snooping around. Right? First thing that's gonna happen is we have a detection capability right on the edge appliance itself that provides data access into your environment. And it looks, as Scott mentioned, for these kind of anomalous and destructive behaviors. It looks for patterns of behavior, not necessarily specific signatures like antivirus of of yesteryear. It's looking for behavior. And when it sees behavior that it deems unusual or above a certain threshold, it will actually indicate, it will alert you, and potentially cut off that client, cut off that IP address or user account from the storage completely. At that point, you can send up a flare gun in the environment and let the SIM, let the SOAR know. Hey. Something's going on. Something nefarious needs to be looked at. This this user account needs comp you know, quarantine. This workstation needs, you know, quarantined as well. You can start to take preventative action outside of the data layer so that this doesn't pervasively exist across the entire environment. Secondarily, though, let's say that that gets breached. Right? We're in this defense in-depth strategy. Let's assume that whatever happened didn't raise to the level that it was detected by the appliance. It wasn't detected by this in line ransomware detection. And it actually went out there and deleted, let's say, 50,000 files 50 terabytes of data. Well, because of the foundation of NASUNI is built on this WORM principle, no data would be deleted in the data infrastructure. No data would be deleted. Let me say that again. You would have an event happen where someone went out and wiped out 50 terabytes of data, and the only thing the system would do is write a new metadata statement that represents that data no longer existing. But guess what? I have an immutable timeline of every change that took place within my retention period that I can quickly, if not instantaneously, recover back to. So it's kind of assuming breach at every layer. It's assuming, hey. They've got privileged access. Okay. Let me try and look at them behaviorally. Okay. Let's say that that fails. Okay. Let's have immutable backups kind of built into the platform. Okay. Let's assume that fails. Let's have resiliency and redundancy across many cloud regions. So it really is about building it in as a first class citizen into the data infrastructure and not assuming that, you know, some air gapped copy in Fort Knox is gonna be my key to recovery in these situations. Because my argument would be, you know, the the recovery, the failover, the failback, all these things oftentimes are much more difficult in practice, than they are in principle. And that's to say, hey. The plan looks great on paper, but the reality of restoring these large amounts of data, the reality of failing over my environment to this disaster recovery location, all my clients, all my applications, all the state of databases, and all the consistency, very, very arduous, if not impossible. And you'll find in these ransomware events, not that customers or, you know, companies don't have backups. Oftentimes, they do, but they know that the recovery speed would be so slow that they can't afford it. It would be more expensive for them to take the financial hit that it would take to recover the data naturally than it would just be to pay the ransom. And I think that's one of the things that's most frightening and is right now we've entered kind of this new era, certainly in in cyber warfare where it's not really about money anymore. It's really about, know, destruction and destroying infrastructure. So in that case, really, anybody that is supporting, you know, the government in any capacity really needs to look at these zero trust tenants much more closely than they may have in the past. So one of the one of the biggest strong suits about NASUNI is really that there's security built in every layer, that we've really adopted this zero trust mindset. You know, you've got data separation from the control plane. You've got customer managed encryption keys. You've got immutability. You've got, you know, hardening and default denies. You've got built in auditing. You've got ransomware detection. So you've got all these things layered in that you can assume, hey. At each pass, you're gonna be covered even if the one above it fails. And I think that's one of the things we wanna leave you with here is zero trust isn't like a stamp you can just get based on a a a set of of individual unique actions. It's really a web of different interconnected disciplines that you need to tie together in your environment and across your environment holistically. It's about really driving and creating some of these cross functional relationships, certainly from our from security ops standpoint and security analysts, really work more closely with our application owners, work more closely with our infrastructure providers, and start to provide education and implementation of these principles into the different into the different architectures. I know we're up against it for time here. So let me let me skip ahead a little bit, and we could talk through, you know, potentially how NASUNI might have might have thwarted this and then get to the TCO, Scott. But I'll I'll leave it over to you here if you would take us on. So the the big thing is, you know, with ransomware detection enabled, you know, even and and with the different capabilities within NASUNI, once the masked elite began, we could have detected that pretty quickly. Right? Because, for example, I had a customer a financial customer. They had a Shredder application. It was called Shredder, and it was used to to delete files on laptops. And our ransomware protection flagged it as being ransomware because it was mass deleting files. So they had to, you know, white flag they had to white list it, but until they could get rid of it from their environment. But that it was able to detect something as small as deleting a couple of files and say, hey. Look. This is outside of normal behavior was pretty impressive to to me and to the customer. So just being able to detect that, and then the nice thing about it was not only did it detect it and say, woah. Something's going on, but it immediately moved in to block the IP address of the device that was executing that mass delete. Right? So we're able to to to stop it and prevent it from spreading. Now in this case, it was a benign application, but had it not been benign, because it exhibited all the the characteristics of a ransomware attack, we would have stopped that pretty quickly. Yep. So it's not just the detection, but it's the containment, and then it's just having the data be protected at the back end for recovery. So this leads into we've had. some yeah. We've had some real examples of this. Right? Real customers, real real ransomware. Exactly. And I think we can kinda end on this potentially. Yeah. So API Group is a great great case study, and and they're not the only one. We have a couple of large manufacturing companies that they they deployed NASUNI after their ransomware attack. But in the case of API, they had a CryptoLocker attack. They were already in a a NASUNI customer, and they were able to recover thousands of they were able to cover their data within minutes, save them hundreds of thousands of dollars, you know, eliminating hardware across their sites while increasing their protection and enhancing their protection posture. And, you know, as a result, they're able to recover in minutes versus days or weeks through traditional mechanisms. So these are real world examples of why customers go down this path. And even if you're trying to deploy ZTA and you don't have all the elements in place, having something as foundational as NASUNI in place to act as that protective layer until you can get fully deployed can be a big benefit. Absolute. Absolutely. And I think if you look here, right, you know, at best, people are potentially backing up once a day, couple snapshots hourly. Right? We're talking about introducing a meantime to recovery of less than fifteen minutes, but an RPO potentially is granular as a minute. So. we're able to potentially provide much more granularity in in terms of both your recovery window, how long does it take for me to recover that r r excuse me, that RTO, but also the RPO can be dramatically shrinked. Right? And, you know, if we look at, you know, storage, backup, data replication, disaster recovery, you if I draw that on a whiteboard for someone, we're looking at 300, 400% of my capacity that I'm buying. You know, three, six, a dozen solutions that I'm managing. Right? The reality is we've gotta start to consolidate that. And we've gotta do that with software, and we've gotta do that with cloud storage. And that's really the way you can drive a lot of cost reduction in the environment by taking out a lot of this associated hardware and software. Things that we've done for good reasons. Right? We've duplicated data because we're worried about somebody corrupting it. We've backed it up because we wanna be able to recover it in in operational recovery or bad case. But what our suggestion here is those legacy ways of backing up data, of replicating data, they don't serve you any longer. There's no real way that you're gonna be able to use those to your satisfaction beyond anything like, you know, a benign file recovery. I mean, tell me you're recovering your database back more than just a few minutes ago as with without an associated tail log. Right? You're you're probably not. So a lot of things need to be really baked in and and within the application, within the as a service offering, if you will, and less built. You need to be building less of these and buying more of these as capabilities, certainly. And you can you can you can see the other stuff for ourselves. So let's let's end on this, Scott. I know we're out of time. What what should people do next here? What would what would you think hey. If if I'm worried about zero trust and I'm worried about this thing that happened at Stryker, what can I do internally in my organization, know, depending on my role that that I could potentially look into this further or start to really investigate ZTA in a real way? Yeah. No. It's it's a good question, Ben. So the first thing you can do is conduct a ZTA maturity assessment. There are a number of different organizations out there, companies like Accenture. I think Palo Alto even has a service for their unit 42, if I remember correctly, where they can go out and they can look at your security posture and they can evaluate it against ZTA. At a minimum, you want to understand where are my deficiencies so I can start to do remediation. Then another step would be getting your critical data off of vulnerable tier one storage into a unified file system that has immutable copies like NASUNI. Right? Making sure that until you can get your security posture deployed, that your data is still protected to some degree. For those that are government contractors, pursuing CMMC certification. Right? Making sure that you're adhering to the tenants of CMMC or adhering to the tenants of the NIST ZTE architecture. The integration of SIEM and TOR technology, if you have not done it or if companies haven't done it, would be something I would highly recommend. And then including telemetry from solutions like NASUNI where we have that real time detection and prevention capability that can help build that rich contextual view of your environment. And then lastly, everybody should have an incident playbook that helps walk them through what do I do in these different events. Now we had not anticipated a mass delete event like the striker attack, so I suspect a lot of incident playbooks are gonna have to get updated to protect against that. But having your runbook and then integrating something like our ransomware protection into that runbook could be another big step that you can take in the process. So these are all things I would recommend anybody pursue if they're looking at going down the ZTA path or if they even think this is something they're probably going to need. The problem isn't if you're going to get hacked, the problem is when. We have proven that it doesn't matter who you are, I get notifications almost every day from health insurers saying that they've been compromised and my data may be at risk. So it's not an if, it's. a when. Yeah. So I think we're out of time here, but, hey, let's talk. You can download the full white paper associated with this webinar. I believe it's on our website as well. You can schedule a zero trust review with any of our account team and and certainly can request a live demo at any time. But we appreciate everybody joining us here today. Looking through just a bunch of good comments. John, thanks for joining. Good to hear from you again. But yeah. No. We appreciate everybody's time. Thank you. Ciao. Thanks everybody.