Transcript
笙ｪ笙ｪ 笙ｪ笙ｪ 笙ｪ笙ｪ 笙ｪ笙ｪ 笙ｪ笙ｪ 笙ｪ笙ｪ Hello, and welcome to Securing Data in the Age of AI. My name is James Blake, and I work for Cohesity as the Vice President of our Cyber Resiliency Strategy, Response, and Consulting Services. So in my role, every single day, what we're going to talk about today is some of the lessons learned from those hundreds of incidents that we've seen over the last couple of years. What are making customers prepared, and what are letting customers down? And we're also going to talk a little bit about the trends that adversaries are doing. So let's first look at the fact that cyber resiliency is a business capability, not a technical capability. So in traditional disaster recovery and business continuity incidents, root causes are very easy to understand. Flood, weather, fire, misconfiguration, power loss, equipment failure. And we have one strategy, instant mass restore all of our previous snapshot either into a primary or a secondary data center. We've also got the fact that we have increasing regulation, and those regulations, as we're going to talk about later, are largely converging around the same areas. Regulators for critical national infrastructure, for financial services, for other areas of highly regulated industry are all converging around the same core principles. And then on top of that, we've got the fact that in a cyber incident, we can't just do that thing on the left there and recover from that last snapshot. We have to recover trust. BCDR is about recovering data as a technical process. And then we have the recovery of trust, which is a business process that requires evidence. It requires confidence. It requires assurance. And then finally, we can recover, which is a business risk decision. So why does this matter now? Well, a couple of things are happening. Ransomware and wiper attacks are prolific around the world. Ransomware as a service has opened up the ability to execute ransomware attacks for anyone, regardless of technical skills. Couple that with the new frontier models that are coming along that are discovering vulnerabilities. And a third of the attacks that we see within Cohesity come in through those vulnerabilities. So we're only going to see the cadence of those attacks increase over time, as well as the number due to this proliferation of ransomware as a service attacks. The geopolitical instability in the world is causing nation state actors and their proxies to launch more destructive attacks against critical national infrastructure and large organizations across the globe. We have the fact that regulators are expecting evidence, not just attestation that you have a capability. They are driving things like demand for realistic tests, not just recovery tests, but the ability to respond to that incident, the ability to handle the investigation, the remediation of threats, and the recovery when your systems are untrusted, when your communication networks are down, and perhaps critical resources and documentation have been encrypted or wiped. And then finally, traditional BCDR assumptions are broken during the cyber events that we're kind of exposed to today. If we just go back to the snapshot from yesterday, we recover elements of the attack. We recover the attack surface that the adversary used to get back in. We are rewinding the doomsday clock to 2359, and you won't be able to stop the bell tolling again at midnight. It's not unusual for me to see customers that take a BCDR approach to recovery after a cyber incident to have repeated recoveries where they are reinfected almost immediately, sometimes 12, 16 times before they stop the insanity and realize that the approach they're taking is wrong and they have to investigate and remediate those threats. So I talked earlier about regulatory regimes. If we look at some of those across the globe that are on the screen now, they all have the same common elements of them. The first thing is they want you to understand your services. Your services are not your applications. There is a difference between them. Your services require people. They may require documentation. They may require certificates. They may require DNS. They may require identities. There is very, very much more involved trying to model your business services top-down than it is to model applications upwards. However, the customers we have seen that model those services downwards are the most successful at recovery. They expect you to understand your impact tolerances for those applications. In some of those standards, they give you mandatory impact tolerances that you must achieve. They want you to be able to demonstrate recovery with this degraded trust and this degraded operational capability. They want you to go through incident response, the proper investigation of that incident, the handing off of that evidence of what has happened, that root cause and that attack surface to your IT team to then be able to remediate those threats. And they want that demonstrated through realistic testing. And then finally, there's third-party risk management, which is a very dominant thing in all of these standards. And in these hybrid delivery environments, there's a shared responsibility model between you and service providers, you and cloud providers. That needs to be understood and baked in to your response and recovery strategy. Now, there's one thing that IT people within your organizations may not understand, and it's really important that you take the time, the security professionals, to reach out to these people. If they take that BCDR strategy to recovery, you are on a road to extended downtime. And that is the fact that encryption in the events that we see, the hundreds we've seen over the last couple of years, happens at the last moment. It's very noisy. It creates CPU utilization. Users get services no longer responding. You get readme.txt files appearing. So adversaries know this. So what they do is they deploy the encryptors or the wipers and then detonate them all simultaneously, typically in the last 15 to 60 minutes of the attack. And then if we look at the adversaries, how long have they been in their environment? Well, a lot of regulated industries face nation-state actors or their proxies, and typically, they will have been in an environment anything up to one or two years. So if you think about it, your retention period is six months. All your backups are going to have elements of attack surface and persistence mechanisms within them. Then we have the targeted ransomware operators. These are the people that really focus on understanding your business operations, stealing your most critical data and your most sensitive data so that they can exert maximum leverage to get their ransoms paid. And those actors are staying in anything from one month to three months before they pull the trigger on those attacks. And then we've got the smash and grab, the ransomware as a service, the highly automated attacks. These, they will get in, grab what they can, encrypt what they can, and leave. Not as much leverage on your data, but their dwell times are typically still one to five days. So this means multiple backups that you have will have persistence elements of those attacks. So that means there is a different recovery point objective for your data, your tables, your documents, than there is for your infrastructure, your networks that may have been compromised, your identities that may have been compromised, your applications, your libraries, your configurations. So what that means is we can recover that data from the last snapshot, but we can't recover that infrastructure without first understanding how that attack happened, without bringing those malicious elements back to bear. And one of the things that's interesting is there are some solutions that claim to be able to automatically find that clean backup for you, a big red button that you just press and it brings it back. But guess what? It goes back to the first point that it saw that attack. So what it means is you're actually losing lots of data. Your recovery point objective goes back to the beginning of the attack because those solutions haven't separated the data, which can be recovered from that last snapshot, from the infrastructure that contains badness. So the best strategy is to understand there is actually two RPOs and then produce a recovery capability that takes that into consideration. So when we go to cyber recovery, we have the 15 stages of MITRE ATT&CK. Lots of variables. I remember when I used to work for a large financial services institution and our CEO asked me, how quickly can I recover from ransomware? And I shrugged my shoulders. And he said, what do you mean? We can recover from a flood and a fire in four hours. And I'm like, there's hardly any variables in that. Have they been in for five months or five days? Have they pivoted through five machines or 5,000? There are so many variables in a cyber attack. Deterministic recovery is difficult. But we do need to identify root cause to remediate that attack surface and those persistent threats. And the thing is, there's a shared responsibility model. Security do that investigation, but IT do that remediation, either through volume-based recovery and then choosing the relevant elements from different snapshots that haven't been impacted or rebuilding systems. And if you look at all incident response best practices, so the major seven ones that I align to in my professional services, they've all got six common steps. And this is what we should be doing. So if we look at that shared responsibility model, the business needs to define those impact tolerances, define those critical surfaces. Do that ahead of time because doing it during the incident is waste time. We need to get that minimum viable company defined. We need to determine and accept risk because there is uncertainty after an incident. If you wait and constantly investigate to try and get rid of all uncertainty, you cause more impact than you do recovering systems where there is a potential for reinfection. Security operations are responsible for the investigation, the recommendations of remediations, and the establishment of the trusted state criteria, whereas IT operations are doing the recovery and the rebuilds, the validation that those recovered systems have been successfully remediated and that they perform functionally as they are expected. So this is a business process as we go through those six steps with a shared responsibility model between these various different people. And if we look at how do we define most critical for us, it's a term that is bandied around a lot, the minimum viable company. What is it and how do we establish it? Well, the minimum viable company is the thing that keeps the organization viable from a financial perspective, from a strategic perspective, and from an operational perspective. And that typically means keeping the public and your staff safe, keeping critical revenue paths coming in, complying with your contractual obligations to third parties and supply chains, and also your regulatory obligations. And a lot of people start from the bottom. They start with what tables do I need? They start with what applications do I have? This is the wrong place to start. None of your revenue streams are served by a database. That is a means to an end. The business services payroll, the business services order fulfillment is logistics. And there's multiple systems and certificates and identities and networks and DNS that support that, all of which can become untrusted. And a lot of those dependencies get forgotten. I walk up in incidents and people haven't thought the door access control systems are a critical business function. Your incident responders are locked out of the building for the first five hours of an incident because they can't get in. That's five hours delay. You see virtual machines recovered to hypervisors that suddenly realize the application is running in new hardware and they ask for a license key. They never backed up the license key. Things like playbooks and contact lists are shared between Confluence, between Jira, between SharePoint. And the problem is all encrypted, all gone. You need to get a hold of these critical assets, vault them, put them on a separate identity plane because if you put them under your production identity plane, you have to recover Active Directory to be able to get into them. And Active Directory is one of the most prolific persistence components that we can have in an organization. So you need to rebuild trust to be able to investigate AD. So break glass is really important. Separate identity plane, vault these things off. The second thing is clean room. A clean room is not just a recovery environment. It is a place to do investigation. Security operations investigate the incident and build evidence. That evidence builds confidence and it reduces that uncertainty and it gives your IT team the direction to remediate those threats. And they can do that by rebuilding systems if you want a deterministic recovery time. And that recovery time can be served by vaulted install images and trusted configurations. And then what we do is we return those mediated systems back into production. So this is an engine. This is a workflow and you can just constantly push your affected workloads through this system in order to recover those services. Maximum utilization of people. It is not just the technology. It is the workflows and the responsibilities, the handoffs, and the decision gates that power this clean room. And then we have to test that clean room. We have to test that vaulted resources, test our people, build that muscle memory. So tabletops test decision making. And often it's at the very top of the organization, very disconnected from the operational people. And then we do recovery tests. And those recovery tests largely test technical capability, the ability of bits to go to point A to point B. But what we need is a clean room drill. We need to go through that entire process, recovery, response, did we restore any persistence artifacts or did we restore any attack surface? We're also building muscle memory, identifying what is weakest so that we can build improvements. So in summary, if you want to build protection against today's AI-driven threats within your organization, understand that cyber resilience is an operational business process, not a technical one. Your IT team may think different, right? So go to them, start this conversation about working together. Model your services, not just your application. Start at the top down. Understand those hidden dependencies, the documentation, the people, the certificates, the identities. Vault those essential resources away on a separate identity plane. Build a clean room with the appropriate processes and responsibilities. And then as you go through the clean room, document the decisions you make, the evidence that drove it because your insurers and regulators will want that. And then leverage your backup, not just as an ability to recover, but there's all sorts of value in that backup. Logs that never made it to the sim. The forensics capability when you've isolated those machines and can no longer image them. There is a lot of value in security use cases. So hopefully that gave you a very high-level overview of how to build this kind of recovery engine that's suitable for today's resilience requirements. Please feel free to connect with me on LinkedIn or send me any questions around this. I'm an operations person, not a technologist. I deal in transformation and operations. Happy to answer any questions that you may have. Thank you for your time today. 笙ｪ笙ｪ笙ｪ
