Losing the Endpoint Recovery Gap With IGEL

[00:00:00] AI agents are only as strong as the data that they're given. When provided with an outdated data set, your agents could end up doing more harm than good. But not with Denodo. With an AI data layer built within your platform, your agents are provided with real-time data changes. So with Denodo, your agents can finally make the right business decisions. Simply visit denodo.com to learn more.

[00:00:27] If your applications and data are back online after an incident, kudos. But can your employees really get back to work? Because an encrypted laptop or a device under investigation can leave people disconnected, even when the infrastructure is back and available.

[00:00:53] So business continuity ultimately depends on the endpoint as well as the systems behind it. And actually accounts for identity, access and the work employees actually need to perform. That's all anyone cares about when everything comes back. Can I get back on and do my work? Well, today I'm joined by Sterling Wilson. He's the Global Field CTO for Business Continuity and Disaster Recovery at IGEL.

[00:01:21] So today we're going to discuss its emergency mode capability and the role of an alternative operating environment, while security teams investigate those affected Windows devices. So Sterling's going to explain today why access recovery actually belongs alongside containment, and how organisations can prioritise business functions and ultimately what should they be testing

[00:01:49] before an incident. Yeah, we're going to get proactive today. And I'm going to ask a few questions around what success looks like, whether systems are restored or when people can resume the services their organisation is providing. We've got a lot to get through in a relatively short amount of time. So buckle up and hold on tight, because I'm going to beam your ears all the way to San Diego today,

[00:02:12] where Sterling is waiting to speak with us. Thank you for joining me on the show today. Can you tell everyone listening a little about who you are and what you do? Absolutely. It is a pleasure to be here with you, Neil. My name is Sterling Wilson. I'm the Global Field CTO for Business Continuity and Disaster Recovery here at IGEL. I've spent, whoa, more than 17 years in the data protection and recovery industry. And during that time, I've really watched backup go from,

[00:02:42] you know, sort of an IT checklist to really into a security discipline because attackers have made it that target. And I believe we're seeing that same shift happen with our endpoint here today. So my job here at IGEL is to make sure that endpoint recovery is part of the plan, a governed part of resilience and not an afterthought. Love it. It's a real honor to have you sit down with me today. So much that I want to talk with you about. And I think companies have invested heavily in endpoint

[00:03:10] security and recovery tools, but downtime can still cost millions of dollars an hour. We've seen many examples of that throughout the year, but where is it that recovery process usually breaks down? What are you seeing here? That's a great question. It really breaks down at the last mile. Most organizations are really good and they can bring the recovery site up in minutes. The systems come back, but the people still can't connect. So the employee is still sitting at their laptop that's encrypted, unstable,

[00:03:40] or worse yet under investigation, which we'll talk about here in a little bit. So when you think about what normally I think our customers really think about, they think about things like re-imaging and how they can bring an image back down either from the cloud or just reinstall or restore. Sometimes because of forensics, they don't really have the ability to restore that image. That image must maintain or must maintain that state. And so, you know, if you're talking, whether you're

[00:04:06] talking to a nurse, for instance, a contact center agent, you know, just re-imaging that device many times isn't realistic. And so that's where the recovery breaks down. The infrastructure is covered, but yet when the endpoint isn't considered, your business is still down. Yeah. And before you join me on the show today, I did a little bit of research and quickly found a quite scary stack because IGEL has cited research showing that only 4% of leaders

[00:04:33] feel confident that they could recover from a major disruption. So why is confidence so low despite years of spending on cybersecurity? It's lower and it's getting more stressful, isn't it? I mean, if there was another one right next to it is, how stressed do you feel thinking about those things that would have been off the charts, right? That research that you're talking about, it actually measured whether organizations could

[00:04:57] guarantee clean, restorable data for all of their critical apps. And only 4% really thought that they could. And, you know, AI and AI attacks and our data being leveraged by AI really only makes that worse. So most plans recover what we call the RTO or the recovery time objective, a target that's on paper. What we deal with here with it, IGEL is we make sure that the customer really, really measures

[00:05:23] their RTA or recovery time actual. That's the time that it actually takes people to get back to work. And so when you test those and when you can be confident in that plan, that's when your confidence actually rises to the fact that you can get people your data back cleanly, which we've done better, but your endpoints clean as well that can actually touch that data that they need. And of course, emergency mode from IGEL can reboot a compromised window device into a lockdown

[00:05:51] operating environment, something that I've learned from having many conversations, including with your CEO, Klaus there, an incredible guy too. But what can an employee, what can they safely do in that environment while the wider investigation continues and people are asking IT for updates? That's a great question. And succinctly answering the question first, they can do the work that matters. They can work on the same device with the same sign-in that they had. As you already know,

[00:06:18] IGEL OS is a read-only OS. It's immutable, never touches the Windows partition. So during that process, nothing is compromised and nothing can compromise or touch that Windows partition. So the employee doesn't need to make any recovery decisions. They stay in IGEL OS until the administrator releases that device from the emergency mode and they reach what IT has pre-approved. So think about the normal web and SaaS apps. Think about email, collaboration tools,

[00:06:49] and virtual desktops should they need them. The employee should be able to continue their work while the forensics team and the other teams can do what they need to do on the Windows side of that partition. And what you're talking about here is so important and often underestimated because I've been right in the heart of the eye of the storm when an attack hits or there's a P1 incident, for example, and the board are continuously coming out to IT every two minutes. Where are we? When

[00:07:17] are we going to get another update? And a cyber attack is even worse because the business needs to operate as normal. So just taking that out is a huge plus point because recovery teams face that pressure to restore quickly, but most importantly, without destroying evidence of the attack. So how does a company balance speed, security, and forensic integrity? Because I can't remember a time where we've had all three, to be honest with you. Yeah, I get that. And that's, um, it's not

[00:07:44] only a tough balance, but in my opinion, I'd answer that a little bit differently is we need to reframe them. um, I think we need to stop treating them as a trade-off. You know, if you re-image fast, you destroy the evidence. If you preserve the evidence, the business can't do anything until, you know, you finish it. And so what we want to do is to provide the, the, the customer really the best of both worlds. And so for the listeners out there, emergency mode quite, quite simply is a

[00:08:11] pivot. It's not a recovery. You know, we don't fix or touch windows. The windows partition stays untouched and preserved for investigations. And once again, with emergency mode, that device stays locked in the iGel OS until released. So even through, even through reboots, it will return right to that iGel OS to guarantee that the customers can continue to work and work safely. You definitely don't want them rebooting back into a compromised environment. So you basically can

[00:08:38] avoid restoring an image that re could infect you. You could, if you could continue to work and you can allow the forensic investigation to happen in the timetable that it needs to take. And when we're talking about this emergency mode, almost a, a big red button, and especially for people listening and hearing about it for the first time, where, where should that sit within a wider incident response plan? How does it work alongside maybe other endpoint protection, identity controls and, and backup systems?

[00:09:07] That's a great question. And I just want to say thank you for that call out because when a customer is going through an incident, they're on what I like to, what I like to call an arc, meaning it's not about one vendor or one system. They're a collection of systems that have to work together and they've implemented these, these, these, these in certain positions. Of course, we've liked to think that they've tested it. We'll probably talk about that in a little bit because that's just as important

[00:09:33] as having the system. But ultimately right when that, when that response starts, it should be right after the containment decision. We like to make sure that everybody knows that IGEL doesn't detect attacks, detect attacks. That's deliberate. Detection belongs to your security tools. Once they make the call, an administrator moves the affected devices into the IGEL OS from one console. So identity still

[00:09:57] controls govern and governs who gets in backup and DR restores the data, the apps, VDI, whatever they need to get into. Every layer still does this job. We fill that gap in between them. So it should be right after that containment decision. So during a large disruption, let's say a P1 incident, go straight into incident planning. How should an organization decide which employees, which devices

[00:10:23] and which business services need to return first? Any examples you could just help bring that to life too? Yeah. You know, we have this discussion a lot of times, especially when we're talking to our customers about what their appetite for risk is, what their uptime is, what rules that they are governing themselves by. And of course the outside governance as well, the safest plan or the safest path for everyone to ask themselves are, what does your business look like? Because these decisions

[00:10:51] should be based on business function, not necessarily an org chart. So life, safety, customer facing roles need to come first. The continuity of care, the continuity of business transactions. So think clinical, contact center, point of sale payments. Those should be positioned to actually come up first. Cash and supply chain come right behind. So the orders, the shipping, the invoice, the payroll, those types of things need to come closely after. And then of course, the communications. Once again,

[00:11:21] you have your business continuity plans that have to be put into effect. And these are very methodical teams that have to trigger different sets that go into motion at different times. So we need to define the recovery units like a ward, a branch or production line, and really mirror them as groups in the console itself. All in all, Neil, I'll have to say the worst time to decide this stuff is in the middle of a crisis. You know what I mean? Yeah, it really is. Because I think it was old Mike Tyson quote, everyone's got a plan until they're

[00:11:50] smacked in the face and everything goes out of the window. But what should companies be testing before that incident so that they know that their recovery plan will work when states change, when there's real pressure on rather than just on paper? Anything that they should be doing before? You know what? Readiness. We hear this a lot. The actual testing of the recovery capability, making sure that the different tools, solutions, plans that you've installed and put into place

[00:12:16] actually work, actually plan. And you have to plan them and test them around true circumstances. And of course, test the recovery time actual, please. We have a bunch of plans that are, you know, the recovery time objective. And on the, you know, the data center side, the apps, we've gotten pretty good to being close to those. But when are you solvent again? When can you provide patient care? Or when can you provide financial transactions or go back to those

[00:12:43] sales? That's your recovery time actual, when they're actually working from that point of when the decision was made. Some other things to test and consider is the authority. Can the right person make the decision at the right time when you fail over to different systems or when you put certain incidents into play? Can people sign in and connect to their critical apps? And of course, after the incident, how can you return back to where you want to be? Whether that is to remain on

[00:13:11] your IGEL operating system or whether to move back to the Windows OS as well. So another thing to test is, what if everything is unreachable? What can you do then? Many plans are predicated upon bringing down some sort of a Windows image, which we know from forensics may not be possible, but they can also have a Windows golden image that has been tainted, that has been messed with. So what does your offline case look like? You know, resilience is proven through planning, preparedness and practice,

[00:13:38] I always say. So these things need to be taken into consideration and practice like a real scenario before the real scenario really hits. You must have heard a lot of stories and heard a lot of conversations and also experienced a lot of things in the industry. I'm curious from everything that you've seen and heard, what kind of mistakes do leadership teams make when they treat business continuity as just an IT responsibility rather than that wider operational issue? Do you have any stories

[00:14:06] or experiences around that? You know, when it's treated as the IT problem, the plans measures that the system's restored? You know, once again, not the people, not the RTA. That's the biggest issue when making it an IT problem. And it goes to say, you know, when you're talking about BC, business continuity, and you're talking about DR, disaster recovery, also data resilience, these are different disciplines.

[00:14:31] They think about different things. Disaster recovery restores the technology itself. The business continuity, well, they keep the organization operating, working, and moving forward. So when it's treated as IT's problem, the people that are not working isn't truly considered. And so when nobody clearly owns the endpoint, it falls in between the teams. And so that's really the, where the ownership really needs to be shared here.

[00:14:58] The CIO for continuity, the CISO for the trusted access, and the resilience leaders to actually make sure that those things go into effect. And that's really what we talk about when we talk about the recovery time actual. We notice many plans really focus on bringing up those core systems and business continuity side, thinking about who are the VIPs that really should be notified and things

[00:15:24] like that. But when you're really talking about the continuity of your business, that's when we're talking about making sure that business units are recovered at the appropriate time. So when that is, the RTA is considered, the recovery time actual is considered, that's when people start to realize where their gap lies. And most times it's right at the endpoint, the trusted endpoint. And for people listening that are non-techies, maybe business leaders,

[00:15:50] I think the best way of visualizing IGEL's emergency mode is that big red button. It's a business continuity and disaster recovery feature. But you hit that red button there, you reboot affected Windows devices into that secure, lightweight IGEL OS environment. So you can get up and running straight away while the tech teams investigate cyber attacks, ransomware instance, et cetera. And with all that in mind, for people listening that would just like to dig a little bit

[00:16:15] deeper on this. Maybe it's a business leader saying, I heard about this on a tech podcast. Can you go and check it out for me? Where should they go? Where should everyone go to find out more information? You know, you can always reach out to me. I love having these conversations and we can tell you a little bit more about the endpoint gap, ways to uncover what your gap or your appetite for risk in your business may be. And we can help tailor some solutions that fit well to cover that. If you want to

[00:16:42] speak with me, you can find me on LinkedIn. That's Sterling Wilson at IGEL. For IGEL and information on the IGEL secure endpoint platform, you can visit IGEL.com and look for business continuity and disaster recovery. For the emergency mode announcement in particular, the brief are in there as well. And you'll find some really cool information and even some snippets and videos around that as well. And if you're more technical, the technical people that are listening to us now,

[00:17:09] we have an IGEL knowledge base that walks you through not only the deployment, but things to consider within your own environment as well. Awesome. So for everyone listening, if you go over to techtalksnetwork.com, there will be a blog post associated with this episode. I'll include all the links. I'll try and embed a video as well, just to help bring it to life. It's incredible work what you're doing here and I can save a lot of time and money. So I urge people to check that out. Other than

[00:17:36] that, I will, I believe, be attending your conference in February. So hopefully we can record something in person. But thanks very much for explaining this today in a language that everyone can understand. Really is important work. So thank you. Thank you very much. It was my pleasure. I think Sterling's distinction between a recovery target and the time that people actually return to work, I think that gives leaders a way to better assess their plans. Because restoring

[00:18:03] infrastructure is ultimately just one milestone, but resuming an essential business function, that is a whole other kettle of fish. So today's conversation, I think, made it clear that endpoint continuity actually sits alongside detection, identity controls, backups, and investigation. And all these responsibilities, they all remain part of a wider response. Even when employees can

[00:18:32] use an alternative environment to reach approved resources. So practical takeaway for me is rehearse the decisions as well as the technology. Who can authorise the action? Which business functions need to return first? And what happens if a dependency is unavailable? Lots for you to take away and think about there. A big thank you to Sterling from IGEL for joining me on Tech Talks Daily and sharing his

[00:19:00] insights. You'll find his profile on the product announcement technical resource in the episode notes. But I really want to hear more from you. What did your organisation last test? Yeah, be honest. Did you test whether people could actually resume work after an incident? Did you know straight away who to bring back online first? I want to hear your thoughts. The good, the bad, and the ugly. So drop by techtalksnetwork.com. You can send me a DM over there, or you can send me an audio

[00:19:30] message. But I'm afraid we're out of time today. So thanks for listening as always. Time for me to go. Bye for now.