Welcome to the Resilience Revolution, Where Defenders Act More Like Attackers

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: OK, so what does that mean? Is there a playbook tweak you can make? I mean, 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: OK, so if I'm sitting in 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 them on the floor here. Sometimes you blame human error. But human error isn't very useful. It's basically a way to 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 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 is 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; 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, SEC regulation. I mean, there's no shortage of things bogging down the cybersecurity industry. It just seems like a very difficult task. 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. I have an "ice cream code 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, 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? There's been a lot of push about threat hunting as no longer a nice thing to have, it's a need to have. 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 APTs and everything's so fun. But what we really need is, 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. Sure, we can learn maybe more about 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 what 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: There are 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 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 seven or eight benefits in my talk about getting fixing patches faster, faster incident response, stronger change, control, minimizing misconfigurations, minimizing environmental drift. To me, 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.