Welcome to the Resilience Revolution, Where Defenders Act More Like Attackers – Source: www.darkreading.com

Dark Reading News Desk interviewed Kelly Shortridge, senior principal at Fastly at Black Hat USA 2023 about her research on fast-ever evolving defenders and the resilience revolution. Check out the News Desk clip on YouTube (transcript below).

Dark Reading, Becky Bracken: What is the resilience revolution? Can you explain that?

Kelly Shortridge: Yes. So I will start with the problem that we have in cybersecurity today. And why we need a revolution. We’re too slow. Attackers are fast, ever evolving. My point is, well, why don’t we start imitating them a little? Why can’t we be nimble and curious?

The resilience revolution is basically a transformation where we can start being a little more like attackers and being fast and ever evolving. Because resilience, if you look across complex systems of any kind, the ability to prepare for respond to and adapt to failure gracefully — that’s something attackers can do. But today, most security teams aren’t the best at it.

DR: Okay, so what does that mean? Is there a playbook tweak you can make? I mean, what what does that entail? That’s a big challenge.

KS: It is. I very much view it as a socio-technical transformation of the organization. The key foundational principle, I think, is instead of trying to prevent failure, trying to prevent attacks, we have to learn how to respond better. Just like an untied shoelace is inevitable, attacks are inevitable. So what we need to do is to minimize impact and improve our ability to respond to attacks better over time to be able to evolve. So that’s a key mindset shift. And then there are a whole bunch of opportunities that you can do in practice to start really implementing that.

DR: Okay, so let’s, if I’m in I’m sitting in my, my SOC, what are some of the first things I’m going to do to help start my team and transfer them into an attacker mindset?

KS: I think a key thing on the incident response side is really making sure that you’re looking at all of the contributing factors to an incident. So we’ll even see on the floor here. Sometimes you blame human error. But human error isn’t very useful. it’s basically a way to, like absolve ourselves of any responsibility and to blame someone else. Well, maybe the design of the system was confusing. Or maybe there were competing priorities, you know, a salesperson clicked on the link, because they’re trying to close a deal. It’s understanding all of the factors that contributed to that attack being successful. And not just settling for the easy answer of oh, well, a human, you know, was lazy, or whatever else. Humans aren’t lazy, right? We need to be a little more respectful and really dig into all of the messy complications that make failure possible.

DR: So besides the upfront work, there is a response that needs to happen. And so how do we nimble that up?

KS: I’m a big fan of automation. So one thing I talked about in my talk was using things like infrastructure-as-code to be able to update things like block lists, or to be able to patch on demand. Because one thing I see a lot even still in cybersecurity is that speed is viewed as the enemy, which isn’t helpful. But if we can move quickly, it means again, we can release security updates and fixes quickly as well. And we can, you know, fight back and again, minimize impacts. So definitely on the response side, we need to be embracing speed more than trying to resist it.

DR: Alright, so what are some of the things we should be stealing from defenders? What are they doing that we can copycat and use against them in kind?

KS: Yeah, so I think one thing with attackers, they’re actually quite good at a few things. Again, one, they’re very speedy, they stay nimble, they leverage automation. They also are pretty good at experimentation. Like they want to really understand, Is my attack going to be successful? And I think that’s something again, we aren’t great on the defense side; at experimenting. So I’m a big fan of chaos experiments to validate that security controls are working using intent.

The other thing I think’s interesting, and what I mentioned in the talk is attackers challenge our this will always be true assumptions, the things we take for granted, like a firewall will always detect a misconfigured port, it probably won’t. So attackers will poke and prod that we need to be doing that proactively too.

DR: Because we are in these institutions where we need to move from thing to thing. And we have, again, (Securities and Exchange Commission) SEC regulation. I mean, there’s no shortage of things bogging down the cybersecurity industry. Is it doable?

KS: I think it is doable. I think it’s doable when we start to think about security as a subset of software quality. And I know CISOs talking about this. I’m a huge fan of what they talk about with secure by design. Okay, fan of that I have an ice cream COVID hierarchy of security solutions that basically says roughly the same thing, we need to prioritize solutions that aren’t bolt-ons, they’re not policies. It’s embedded in the design of the system that allows us to get that grace and that flexibility and to move quickly without having to put in so much manual effort, which I think we all want. We want to reduce that toil. But I think a key thing again, like you mentioned, the SEC regulation is about minimizing impact. It’s making sure that you know, failure is isolated, that you can recover quickly that attackers don’t get anything meaningful, even if they successfully get initial access.

DR: So where would you focus? Is it threat hunting? Is it? There’s been a lot of push about threat hunting is no longer a nice thing to have. It’s a need to have threat hunting, it’s becoming more specialized, it seems in different areas. So is that the key? Or are there other things that should be done earlier?

KS: I’m gonna have a hot take. I don’t think threat hunting is very useful for this. Wow, I know. It’s fun. It’s fun. Threat hunting is so fun talking about a PTS and everything’s so fun. But what we really need again, as we need to think about the design, we need to think about what is going to improve our resilience to attack over time. So we aren’t just encountering the same things as sure we can learn maybe more about like the specific style of attack. But really, there are a lot of design based mitigations, like isolation, or even in my talk, I mentioned message brokers and queues that can help us across a variety of attacks. So really, the particulars of the attack matter less than making sure that, again, based on our design, we’re eliminating or reducing hazards. Again, this is a I call it a revolution because this is a huge mind shift from everything we’re hearing about here.

DR: Well, and of course, the first thing a business division would say is we have invested so much in these legacy systems, like we’re not going to rip it all out and replace it by code. What is the argument? Or what is the path toward getting there?

KS: Are there lots of paths again, this is something where I wish there was more collaboration between security software engineering teams, because what software engineering teams don’t like legacy stuff, either. They’re trying to often modernize stuff, for reliability, for things that make money, and security can kind of glom on to build it in a safer way.

I think actually, if you look at production environments, for instance, nobody wants their what I call the “money printer” of their website, or their application going down. Security tools can put that at risk. Security tools can cause that downtime.

Changing the design instead is a lot in some sense, a less risky proposition than buying some sort of bolt-on tool, depending on the case. So I think, again, it’s less of a lift than you’d think. You don’t have to revolutionize your systems overnight. You do have to revolutionize your revolutionizing mindset. And again, start thinking about this design based solutioning.

DR: Interesting. So maybe to just sort of give us a final thought, Where are the other automation tools? Where do they need to go?

KS: Oh, I think again, there’s a great wealth of tools and approaches from software engineering, we should adopt again, things like infrastructure as code. I think I went through at least like seven or eight benefits in my talk about getting fixing patches faster, faster incident response, stronger change, control, minimize misconfigurations, minimizing environmental drift. To me, that is the tool to really look for is infrastructure as code. It’s declarative. You don’t really have to know how to code. But it means that we can encode certain properties we want in our system, which is just fabulous as a security tool.