Kelly Shortridge, Fastly | RSA Conference 2023

This is texturung TV. Welcome back everybody to rsac 2023 here in San Francisco. It's been an amazing conference.

So many more people here so many people connecting in person. And as well as meeting new people having great conversations about technology all kinds of great stuff of which my next guess is someone I've not met before so I'm really excited about meeting Kelly Shortridge. Welcome and good to have you on the show Welcome Kelly is senior security engineer senior principal engineer with fastly correct?

That is correct. Got it. Well tell us a little bit about yourself and about your role at fastly.

Absolutely. I like to think of myself as a bit of a security provocateur. I like challenging kind of the ingrained assumptions and the industry and actually aligns very well with my look at fastly which is thinking about the future of security.

It's a very lofty goal, but we already do a lot with security like antideos. We have like a great laugh. We're also very much lined with that very hot secure by Design buzzword.

Everybody's talking about right now. I'm thinking about the future of It's how can we do it better? How could we maybe even make security invisible to developers?

So they don't even have to think about it. Wouldn't that be levels be very happy about oh they went. Yeah.

Okay. Well, you're you're also author of your first book. Yes big book and I know from talking with other authors.

I'm not done with myself, but it's a lot of work and you know, you have that passion going in and it's sort of that commitment that gets you through to having the finished product. How's it feel to launch this thing? Honestly, it took me about nine months to write so it feels a little like giving birth and when I saw the coffee mud straight.

Yeah, it's perfect. And when I saw the coffee at the fastly Booth, I was like, oh my God, I made this like, it's just my precious little one, right? So I feel like it's very aligned.

It is a labor of love. You have to have a lot of passion. I don't recommend writing a book just to write a book.

You have to have something that just like really is crying to get out of you. Probably a lot easier to get to the end that way. Yes, so tell us the title of the book what it's about and then You wrote about that topic sure.

It's called security chaos, engineering sustaining resilience and software and systems. I argue the subtitle is a little more indicative reality is that most of our software systems are very complex. They have lots of complex interactions, they're difficult to understand and so the way that we have to sustain resilience, which means the ability to be able to weather storms to be able to respond elegantly to failure to be able to adapt to evolving conditions.

All of those things require different strategies than the ones we have today in security. So fun fact I actually was inspired about, you know, promoting like a resilience revolution in infosac because of a Bertha book on earthquakes because there's a fantastic quote by Susan Elizabeth Howe which says building doesn't care if an earthquake is predicted or not. It'll either withstand the shaking or it won't and I thought well, that's exactly what we want on our systems.

So in some sense this book is really a love letter to resilience and complex systems and we have so many Different opportunities for how to implement this in practice across the software delivery life cycle and more. I'm just excited honestly for everyone to nerd out with me because there's just there's a lot of really cool just systems and security and software quality stuff in there too. And that passion is clear.

Yeah. I love it. Yeah.

Yeah, I'm really curious too because we we always talked about reliability of systems and also in the sense of security but resilience is a very different thing right? It's not just the resistance stay up do they not produce theirs? But what happens when on the unexpected?

Yes when the earthquake happens for the building news coming or not, right? Yeah, and I think there's a there's an often overlooked element, which is that our systems are socio technical. So it's not just even did the technical part of the system withstand equivalent of shaking like in an earthquake.

It's very much. You know, how did the humans respond? Did they get out of the building in time?

Did they have enough notice? I think that's you know, we see like at the vendor Hall here. They're a lot of tools that we built on but Humans able to make use of them and I think that's beautiful thing about thinking about resiliences.

You have to think about that whole system and how it behaves and how it responds to different sorts of adversity. What are some of the things that we might kind of inject into our thinking about resiliency though, but they'll help us with resiliency that just aren't part of our normal lexicon or way. We think about Building Systems or building software.

Do you have an hour? We do just not today. But yes, you want an hour give you an hour.

There's so much. I think the biggest thing is in what I call status quo security. We often think we can prevent failure failure should just never happen people should never click on links now where she'd never be downloaded that's never gonna happen.

The reality in any complex system is not just that failure can happen but it's happening all the time. Most of the time things actually go right? So what we have to do is try to think about how can we design things better?

So they go right we have to not pursue that bolts on sort of warning system and certainly no more punitive controls. We have to think about how do we actually Infuse resilience into the system through the design? How do we reduce the equivalent of hazardous materials or processes?

So the book talks about all that, but I think the key thing is We can't thwart or stop or you know, whatever other buzzword failure We Can't Stop attacks, right? It's not going to happen. We have to be able to respond to them gracefully contain impact and then evolve over time.

We always talk about, you know attackers are fast and ever evolving and they're so sophisticated. Why can't we be fast in every evolving? Right?

That's really what the book is about. So, how do you think about designing a system that's resilient because you think about error, how do we stop errors? How would you prevent things from crashing or you know because systems coming down?

There's ideas about shutting down gracefully and some things like that. But there's also the being able to automatically restart processes or microwave services or whatever might be or maybe capturing data in certain situations where we don't know what's happening both that'll help us Aid is to do diagnostics later the techniques like that that can help us with resiliency. Definitely.

I think isolation is perhaps an underrated design element that we can wax poetic about in the book obviously near and dear to me and fastly we have like equivalent of a serverless platform. We call it an edge compute platform, but from the attackers perspective, you have to perform like a double sandbox Escape, which is just really onerous to do but with that isolation, if you can even let's say like rap components within an application to protect them from each other if an attacker, you know attack some sub component and you can make sure that impact is contained. That's so powerful.

You don't have to bolt on as much anymore. It's a lot of the book talks about opportunities to infuse isolation to think about how we pursue more standardization. And in general it's really thinking about again.

How do we contain impact? How do we assume that failure will happen assume that humans will make mistakes and then kind of design things accordingly. And I think the key thing again is you need those feedback loops between failure happening which can be either a real incident or what we loved roses conducting security.

Chaos experiments. You can start small you don't have to run them production, but that creates this elegant feedback loop for your constantly learning and kind of the operational and incident response cycle and feeding that back into the design and the key thing is don't blame the human first try try and your incident, you know review post mortem always make sure to think okay, if we can't blame the human what's wrong with the system design. Where can we look at that instead in a rarely is a truly one person?

Yeah true because it is the main thing exactly contributed to the incident happening. It's just easy to blame me and it is yeah, it's easy and all scapegoating the one person here appropriately, you know, we we do a show called this Show and we talk a lot about chaos engineering and also about in a testing software testing show. We talked about brake testing is another way of kind of introducing people into if you want to break things.

You want to be the person to break things to see what happens. You're not gonna be able to do everything you could do to break a system or two, you know, cause an incident to happen, but you learn a ton by you yourself doing it. It's like let me try to knock down that wall see how the wall reacts.

Let's see what I can do to make it more resilient. Maybe I need to make a more flexible instead of rigid exactly, right? Yes completely agree.

I think rigidity very rarely grants you resilience and I love the comparison to SRE because I actually think there's a lot of overlap that security people don't realize sres don't like the idea of developers as I say eating around in production systems, right? There's a lot of common ground, but I think something you said is also Really important which is about mental models. So I like to think attackers basically look at our assumptions kind of like a lawyer they poke for loopholes and try to find alternate explanations.

That's what we have to do. We have to do it proactively instead of waiting for the attacker to show us that oh our mental model of the system didn't align with reality right? It's in a way kind of exploiting our own breeds first.

It's history too. The mental models attackers don't make necessarily logical connections like yes, I'm gonna get in here and move laterally and that does happen. But but it's also well I found this exploit but I'm not necessarily going to go for the director with that from that.

I'm gonna do some unexpected things that now can lead me to some outcome that I'm interested in. So we think very logically is Engineers as technical people. That's super helpful, but it's all also the unintended use we never thought of doing that before but somebody did right?

Yeah. One thing we talk about a lot in the book is the Baffling interactions that happen in our systems where they surprise us and they can found us and I think that's again the really kind of elegant thing especially about chaos experiments is you can uncover some of those baffling interactions align your mental model with reality a bit better, but I completely agree we often think that our human users are going to be very logical what is called homo economicus that perfectly rational human that always knows which link is like malicious or not the babes that way exactly and you know, they click on links a thousand times a day flawlessly that doesn't exist just like the perfectly rational attacker doesn't exist. And we often don't even think about attackers in terms of you know, they have budgets.

They have bosses. They have ego. They have their equivalent of resumes.

They're trying to achieve some goal, but we often don't think about that. Fantastic, what was your favorite chapter to write? Which one?

Did you just like I could go write that again. It was just like such a cool topic. What a fabulous question, I think.

You know, that's such a good question. I have to think about it not to pick one you pick up. They're all kind of my favorite but I do love chapter seven, which is about a new potential team or sub organization called platform resilience engineering interesting.

But within it there is a beautiful diagram of the ice cream cone hierarchy of Security Solutions, and I'm very much hoping that guides security strategy a bit better, but it was a lot of fun to think about like, you know with something like an administrative control where you're just prescribing a policy and then punishing people that's at the flimsy base of the ice cream cone. You can't scoop a lot of resilience ice cream into it. So it's kind of a fun heuristic to use when you're thinking about like we talked about how do we design better Security Solutions and Implement better security solution, right?

Very cool. What is sort of the one thing? You know, everybody makes it all through a book right oftentimes.

We read a chapter 2. We'll jump to the one we're interested. What's the one thing you hope people walk away after?

Reading some are all of your book or maybe for the fifth time. They've read it. Whatever it is, you know, if people read it for the fifth time.

I will just be over the moon. Another great question. I think the main takeaway I want is again, we can't stop failure we can prepare for it.

We can pursue strategies by design of it better. I think maybe the simplest way to put it is we need to think more about growth and cultivation and nurturing rather than you know, thwarting and blocking and all of that. It's very much we have to figure out how to align security with growth in understanding that the more we grow.

We actually more resources to dig to security as well. But I think ultimately I would really love if I'm just jostling. How people think about security a little bit just so they think differently I think that's really yeah kind of shake it up a little bit exactly.

Give me some new ideas new precisely. Fantastic. Well Kelly, it's been you've certainly done that for me.

I appreciate it. Thank you so much great conversation. Great questions.

Oh, thank you very much. And this is O'Reilly book. So folks have a subscription to O'Reilly get it.

That way. They can also buy it through O'Reilly or you know, Amazon and whatever okay retailers major retailers is available now. Yes, it's just out just out.

Wow hot off the press. Okay, you could be the one of the early ones in your community to read this, you know, so you show up for coffee or beers next time like hey, I read this great book that like really what book is that Kelly? Oh sure.

Okay. So one of my writing Yes, actually right to make sure people can sound smart and cocktail parties have like little sound bites. There you go.

All right. Well, I definitely need to read this book. All right.

Thank you Kelly. Thank you for talking with you and thanks to the focus that fastly for having you on today. So be sure and check it out.

The title of the book is security chaos engineering sustaining resilience and software and systems. So security chaos engineering probably will get you pretty all the way there pretty close defining the book so or search for Kelly Shortridge find that way. Thanks Kelly.

Thanks everybody for joining us. Be sure and check out the book be sure and check out fastly and they grow great folks there and the Fantastic products that they have. We will be back with other fantastic and engaging and exciting guests.

Just like Kelly. Thank you again. Thank you.