Unspoken Security Ep 50: Why Incident Response Keeps Failing

Simplicity is going to make security more effective, but no environment I've been in is massively simple. And so, we need to simplify, yes, but we also need to plan for these unknown unknowns. We need to plan for these risks that we see in an effective way so that when they come up, we also learn from it and we've planned a way to respond in a structured way.

Welcome to Unspoken Security, the raw and gritty podcast for security professionals who are looking to understand the most important issues related to making the world a safer place, including intelligence-driven security, risks and threats in the digital and physical world, and discussions related to corporate culture, leadership, and how world events impact all of us on and off our keyboards. In each episode, host AJ Nash engages with a range of industry experts to dissect current trends, share practical insights, and address the blunt truths surrounding all aspects of the security industry.

Hello and welcome to another episode of Unspoken Security. I'm your host, AJ Nash. I spent 19 years in the intelligence community, mostly at NSA, and I've been building and maturing intelligence programs in the private sector for about 10 years. I'm passionate about teaching, mentoring, public speaking, intelligence, security, all these things, right? I also have a master's degree in organizational leadership from Gonzaga University. Go Zags! So I continue to be deeply committed to servant leadership, as that was a big part of that program. Now this podcast brings all these elements together with some incredible guests to have authentic, unfiltered conversations on a wide range of challenging topics. It's not your typical polished podcast. My dogs make occasional appearances. Full disclosure, it's about 4 in the morning here right now, so they probably won't be on today, but they have shown up before. People argue here, we debate, we even swear here. I certainly do my fair share of that, and that's all okay. I want you to think of this podcast as a conversation you'd over here at a bar after a long day at one of the larger cybersecurity conferences. These are the conversations we usually have when nobody's listening. So today I'm joined by Zoe Rose, SecOps Manager for Canon EMEA. She's a cybersecurity specialist with extensive experience in designing and executing cybersecurity awareness programs and maximizing the value and effectiveness of technical cybersecurity controls across a variety of industries. She's a Cisco Champion, Certified Splunk Architect. She's been included in a list of the 50 most influential women in cybersecurity in the UK. She's also been quoted in media, presented on national news, and been featured in Vogue magazine. And now she's stuck with me today. Anything you want to add to that bio, Zoe?

Zoe?

Not really. You make me sound a lot cooler than I am. I would just say cool.

Well, I mean, the bio certainly sounds pretty cool, and all the prep conversations we've had, I'd say you're pretty cool. We had some conversations that I won't be sharing with others, but I certainly would say that we're cool. You're cool, to say the least. So, and interestingly, today we're going to have a conversation on a topic that I find very interesting. I don't know if everybody thinks it's cool or not. It's certainly a big part of what we all go through. You know, let's talk about how do we improve incident response programs? Now listen, I went through a brief, you know, run of your bio. Like I said, you've been around a lot of different places, right? You've been in different companies, you've been in different countries. I believe you told me you've been in more than you, you know, you worked in more than you can actually list at this point. So over all of that, I'm gonna go ahead and gamble that you've probably seen a lot, both the good, the bad, you know, some large enterprise, small, you know, business, everything in between. How would you describe the current state of incident response programs in general? Or if you wanna talk specifically about, you know, different regions and comparisons, how would you describe the programs we have right now?

I think I'll talk in general because, to be clear, there are some programs that are excellent. They're, you know, very hardworking people. They've put in the work and they're very mature. On a majority amount, I would say that's not the case. The techs, not to discredit the work they've put in, but in a lot of situations, the people actually doing the incident response are probably overwhelmed. They may not be fully supported. And I mean, like, maybe they don't have the right skills, maybe they don't have the right team members, maybe they don't have the right capacity availability because incident response is put on the back burner and it's like, oh, well, you only need to do it when an incident takes place. In reality, that probably means they're under budget or under the required budget, don't have the right tools, don't have the right visibility. So, in a lot of cases that I joined, as again, I was a consultant for a very long time. Well, to me it seems very long, maybe not for other people. But, and so I often was called into organizations either as the incident responder or post an incident or trying to build a secure by default, by design setup. So Target Operating Models, different toolings, all of this. And they're usually in a firefighting state. They're not a, we are continuously improving, we are firefighting. We are trying to keep up with the overwhelming noise of our tooling that has not been tuned, the overwhelming situation where we don't know what's in our environment, we don't have the authority to change it. We are just not set up to succeed. We are literally set up to fail. And so, that I would say is the more likely situation that I've come into. Obviously, I'm talking from my consulting side. I'm not talking from my current situation. I'm quite happy with where I currently am, otherwise I wouldn't still be there. But in an overwhelming majority, I would say, or maybe from my experience, they're not in a mature state. And as I said, they're firefighting. So, I'm dealing with this incident, this other incident is happening at the same time. I only have me to respond to it, you know, like, That's often been a situation that I've seen, and I will be the one called in, and the relationship there is, "Well, I already know this. I've already told senior leadership, you know, you're not telling me anything new," and egos are a big problem. And I'm like, "Whoa, whoa, whoa, I'm here to help you. Tell me what it is that senior leadership is not listening to, because they're paying me a lot of money right now that I can then highlight that, I can make it visible." And so, this change can happen for you. So I think, yeah, on a, maybe things have changed since I've moved into a corporate role. I suspect not, but yeah, it's not a, this is sexy. You know, we've got all these beautiful diagrams and we're responding to this map going pew, pew, pew. No, we're usually like overwhelmed, highly caffeinated and exhausted, working at 3 in the morning, like you are doing right now. Yeah.

Mm-hmm. Well, it's interesting you mentioned some interesting things I wanna jump into on that. So at one point you'd said, you know, it's, we don't really worry too much about it. Well, it's only needed in an emergency, right? So, you know, as you mentioned, like underfunded, underplanned, right? And all I thought of as you were saying that was imagine if that's how like medical services worked, right? Oh, the emergency room. Yeah. We don't really worry about training or funding for that. It's just occasionally when there's an emergency, we'll deal with it. Right. That's the wrong time to start trying to figure things out. Right. In order to handle emergencies, you have to really be well prepared, right? You have to do a lot of training and a lot of education and a lot of tabletop exercises in terms of cybersecurity, you know, incident response, things like that.

What you just said, tabletop exercises, for me, if you don't have the policies, you don't have the documents, you don't have the processes in place, it's really hard to do a tabletop effectively. Because even if you're doing a simulation, there's so many gaps that yes, it's going to help, don't get me wrong, I will never say tabletop will not help, but all of that information is locked in somebody's head. And unless the foundations are there, they have the right tooling, they have the right visibility, they have the right tuning on that tooling, they have the right policies, they have the right awareness, unless that foundation there, they're not going to continuously improve. They're going to be firefighting. And like, think of a situation where, you know, you are an organization, you've been compromised, it's above the capability of your team because to the best efforts of the team, they may be excellent, but there is a limit to their skill, right? There, there's a cap, there's a limit to my skill. And so, in some situations, you have to call in support. But if you call in support and you don't have a baseline, you don't know what your environment looks like, How the bloody hell are they gonna help you? They're gonna spend half the time just figuring out what the fuck is going on. Sorry.

No, you're exactly right. And I think that's, I think that's a key piece, right? Is there's not enough time and effort, money put into the preparation, right? Put into the, the things. I, I think, you know, what I've seen at least is, is there's a challenge. It's a business challenge, I suppose, in that almost everything we do, somebody someplace says, well, what's the return on investment? And, and yeah, when you're dealing with things that are a future state, there's no return on investment today because you have to explain to people why this matters. Well, we'll do it when it's an emergency. Well, that won't work. Like, you will fail if you haven't, like you said, if you don't have these policies and these processes in place. If I don't know the escalation process, if I don't know who to talk to, if I don't know who to bring in and when, and don't have the baselines to hand them. So if they do come in to help, they're all scrambling too, cuz we still don't know anything. You know, you come into an organization and you try to help somebody with instant response and, and you don't have a crown jewels assessment, you don't have,, and a CMDB that you believe in. And, you know, find anybody who does. I'd give you the first organization.

I think that's the way it's too often.

Of course it is. It's exactly what happens. I get on stage and talk to people all the time about that. I'm like, you know, everybody raise your hand if you're comfortable with your CMDB. Uh, and for those who don't know what a CMDB is by any means, it's your entire maps network, right? It's your configuration mapping for everything. So knowing what every system is and what operating system is on it, what version it is, all these things, right? And where everything's located and how everything's connected.

For example.

Yeah, exactly. But a lot of organizations don't, right?

Right.

I stand on stage and say, raise your hand if you're comfortable with it, and everybody just giggles and laughs. Nobody raises their hand. And I think, well, that's tragic. This isn't funny. I'm old school military intel, right? So it's Sun Tzu, like, you know, know yourself, know your environment.

But let's, let's look at media incidents happened that were very public. Yeah, 2013, Target had an incident where they didn't follow principle principle of least privilege. The HVAC company was compromised, they gained access to the sales point of sales, etc. You would think, oh my goodness, 2013, major incident, let's learn from that. Capita recently was fined, what, £14 million because they didn't follow principle of least privilege. They didn't effectively respond to alerts, just like Target. What is that, 10 years maybe more? I don't even know.

Yeah, more now.

Well, I don't remember when Capita's incident was, so it might have been just 10 I don't know.

Oh, you're right.

Either way. Yeah, I think it was 2013, maybe. Anyway, either way, that's 10 years or so that we should have bloody learned and we didn't. And I mean, I don't have insider knowledge on either of those situations, of those techs. I don't know. I imagine they were doing as best they could, but the reality is this is not new. None of this is new. I do, I've been doing public speaking for over 10 years now as well, and, well, I guess maybe 10 years this year, probably. And none of the things that I was saying were new, you know, like it's, I did a talk recently about innovating securely, and I'm talking about, please, just have your foundations. Like, you want to build, you want to be scalable? Well, plan for that. Instead of dress for the job you want, bloody plan for the document for the organization you want. So yeah, it's None of this is new. How do we learn from it? Well, take notes from what's happening in the media. Take your lessons learned. You know, use publicly available— if you don't have a big budget, everybody has a limit to their budget. Don't get me wrong, I have a limit to my budget. I have to do budgeting every year, but I put in place what I can afford. Yeah, because I can't go bankrupt trying to secure the environment, but also I use publicly available resources. You know, maybe the NIS directive, maybe that's not applicable to me, but there's a lot of documentation online if you need to be compliant with it. Make use of that.

What is there?

What are they teaching you? What are those foundations? You know, not everything costs money. A lot of things do, but not everything does.

That's true. I mean, you make, you make a good point there too about, you know, learning from past experience. Right. And I've seen the same thing, right, for years. I still have it occasionally now. You know, people will say, you talk about like, what, what's the best thing I can do? What are simple things I can do to be a more secure environment or more secure individual user, et cetera? And I talk about passwords and people get all mad. Like, don't talk to me about random passwords. Don't talk about password reuse. You know, I've heard about that forever. It's boring. Give me something new. I'm like, well, I'll stop talking about it when you start doing it. How's that? So as long as I continue to find password123 out there, or somebody who has their, the same password for their corporate account as all of their banking accounts and all of their email accounts at home. I'm gonna keep saying it. The reason security experts keep saying this is cuz people don't do it. It's as simple as that. You know, two-factor authentication is a simple solution for a lot of problems. And very few people statistically are doing two-factor authentication, multi-factor authentication, something that would solve so many issues and people still just don't adhere to it. And then you say, well, yeah, I keep telling you things that you've heard before and it's, it's not innovative. It's not new. It's exciting. It's not exciting because you haven't done the basics still. You know, there are so many basic hygiene things. Most, I think most, you might, you, you'll correct me if I'm wrong here. I think most security incidents still end up being a basic hygiene issue. Something, you know, a misconfigured bucket in a cloud instance, for instance, something very simple, right? A bad password. Somebody still had a default password on a router at home. Like, it's all these things that are just very basic things that don't get done. And then people, you know, they're like, well, I've heard that before. I want something sexy and exciting and new and interesting. I'm like, well, I'm not going to tell you all the the third layer of things you need to worry about when you haven't done the most basic things yet. I'm not going to talk to you about building an incredible security, home security system with cameras and, and all these things if you're not locking your front door or closing your windows. There's no point having this discussion, right? And yet people, that's what they want. They get frustrated about hearing these same things over and over again. It's like, well, 10 years, you haven't done anything better about it.

But I think it's because it takes work. So I can implement a sexy tool. I can spend a fuck ton of money on this tool. But if I don't tailor it to my environment, it's gonna be bloody useless. My team, so I'm the security operations manager, yeah? So I've got a team of security analysts that have to respond to all of these events, investigate them, flag it as incident, blah, blah, blah, yeah? If they are continuously getting an insane amount of white noise, their entire day is built around responding to known false positives. That would be shit for them. I mean, they're not going to enjoy that. They're not going to innovate. They're not going to be like, "Oh, I've noticed this massive trend," because they're not going to see the trend because they're going to be drowning in alerts. And so, when I implement tools, I'm not implementing the tool to solve the problem. I'm implementing a tool to then be tailored to our environment, to then solve the problem, to then make the issues visible. That's the goal. It's not, this tool is not going to solve our problems. And also, when people are like, oh, you know, we can use AI, it's gonna solve all of this. Okay.

Yeah.

Okay. Do you know what's going on in your environment? Do you know what to expect? How is AI going to learn if you don't bloody know? You know, it's not going to magically solve the problem if you don't have the foundations, if you don't know what's normal. There are certain things that, tooling can help with. It can build baselines, but again, you've got to edit it. You've got to tailor it. You've got to— this is a false positive. If it's going to learn from this, it's going to be wrong because it's not learned that this is false positive, right? So yeah, I think people are so crazy about, well, what's the new innovative solution? What's the new sexy tool? But they're forgetting The point you made about reusing passwords, I mean, look at Troy Hunt's Have I Been Pwned? His latest data breach was how many, how many accounts? And like an insane amount because it's an appended, appending. Yeah, yeah, it's, it's breach lists that are added together. Yeah, I can't—

right, right, apparently.

Yeah.

And, and so some of them might be new, some might be old, whatever. And if you look at his blog post, it talks about, oh yeah, I use that password like 10 years ago, and there's other persons like, oh, I actively use that, you know. So people are actively reusing passwords that are maybe massively older than me, maybe even. Please don't do that. I mean, I'm not massively old, but I feel like if you're using a password my age, that is massively concerning. Even my children say it. But how do we deal with that? Well, there's password managers. Make sure you have MFA. You know, even if your account is compromised because the password is compromised, you have MFA to stop the malicious actor, or at least delay them so that you can change it. You know, there's a lot of things we can do But if we're not even putting the conscious effort into it, I can talk for hours about this stupid thing called security that I bloody enjoy because it's my, like, hyperfocus, which is my own problem. I get it, I'm a nerd. But if you don't do anything, you're just gonna continuously fall victim to the same things. I mean, I had a client years ago that had an incident. I came, investigated Resolved incident, gave them the report, said, "This is the things you need to remediate." I don't remember how long between, it wasn't a very long time between, another incident came in. I could have copy and pasted the report.

Because they hadn't done anything.

Not only had they done nothing, but it was the same incident. I was like—

Of course.

Did I imagine this?

Like, wait a minute. Right, why did you bring me in?

Yeah.

Why did you bring me in and have me do all the work and give you a report if you weren't gonna take any actions based on that report? But the amount of times they do this.

The amount you're paying me to do this is embarrassing for you. Like, goodness. And, and yeah, it's just like how many pen test reports that— I mean, I don't do pen testing anymore, but when I did, how many pen test reports did I hand over that got put on a shelf and got dusty? Like, why pay me?

Yeah, there's an execution issue there, right? There's people frustrated about this and then bad things happen and you come in and you do your job, or maybe it's preventative, like you said, it's pen testing. And then there's more to it, right? You can't just get a report and go, okay, we see what the problems are. Well, you actually have to execute on that. You actually have to do something about that. And we talked about, you know, going back into the, the crux of this, right? Incident response, right? And, and how to prepare for some of these things. So I, when I first moved into the private sector, I've been, I've been in the private sector now for whatever I said, I don't know, 10 years, give or take. And my first gig in the private sector coming outta the government space was, was at a bank, right? And so I've done a lot of exercises over the years. I was military and then government, so I've done exercises that were cyber related. I've done, you know, exercises that were, you know, kinetic warfare related. I have a background in some of these things, right? And so we were putting together this exercise, right? And it was gonna be a live one, not a tabletop, a full organizational exercise and building scenarios and all the things you have to do, right? And, and to figure out where we were. And I, not to call anybody out, it's a very good group for the most part, but it was interesting at one point as we were going through this and I said, all right, what are we gonna do for a white cell? And for those who may not know the term white cell, cause it might be used differently in the private sector, but in the government space, that's the controlling element basically. For your exercise. You have to have a control element. It's sort of like playing Dungeons and Dragons. You do have to have a dungeon master for anybody who's geeky enough to know what I'm talking about, or it doesn't work. Somebody has to actually be in control because things are going to go off the rails and you have to have somebody who's the hand of God who can kick it back into play and go, okay, well, that person is actually in the bathroom. They're supposed to be answering the phone. They can't right now. We'll come back to them in a minute. Kick it back into play, right? There's gonna be somebody to do that. And so this whole exercise being developed, this whole organization that's, that's was brought in and, and it was internal to the company. They were hired to build and do exercise. And they hadn't planned for a white cell at all. I was like, what are you doing? How's this gonna operate? And it hadn't occurred. I don't know how they brought these people in or what their backgrounds were, but they didn't have anybody to play the dungeon master. They didn't have anybody to be the hand of God, so to speak. And I explained it and they're like, oh, that's brilliant. And you know, so here I am, a hero. I'm brilliant. I'm like, this isn't brilliant. Like, yeah, that's, that was my reaction too. I was very brilliant for a while at that place cuz I kept saying things they hadn't heard of before that I far from invented. But I was like, all right, hold on. We gotta, we gotta change these things. Right? So we did and we, you know, changed the scenario and, and put Whitesell in and built that whole team out. And it was a very interesting day and we failed as you're supposed to, frankly, in these trainings. That's another thing I think people don't gather is you should fail the exercise at least early on your first one. You should fail miserably. That's the whole idea. So you figure out what you have to do and get better. And then you run another one, you run another one, you run another one. And hopefully at some point you get sort of successful. And with everyone you have these learnings, right? And you're able to take these notes and then you have to act on those. To improve them. And I don't know how many organizations do this well. This was a— I mean, anybody can look at my resume, they'll know where it was. It was a very large bank, still one of the largest in the country and one of the largest in the world, I suppose. Plenty of money and plenty of resources and didn't have any idea how to do this. And I'm sure they do now, by the way, for anybody who wants to complain, or if anybody who's at that bank wants to come yell at me, it's been over a decade, so I'm sure they're much better at it now. But it was surprising to see how little people understood about it at the time. And then you have to, as you said, You've gotta document these things and then you gotta act on them. You actually have to make improvements and you have to make changes and policies and processes and continue to exercise and exercise and exercise. You can't just do it once and go, okay, well we did our test, check the box, move on. I don't know any organization, you correct me on this one if you know others, cuz you, you know more than I do. I don't know any organization that regularly does live exercises on like incident exercises. I've been around a while and I don't know many. Well, I'm going to know one apparently, Zoe, you run one. I don't, I haven't run into organizations who do this because from what I've seen, they either aren't prepared to do it or they just don't want the disruption, right? Their days are busy enough.

Or they don't want to pay the cost because it's not free. You know, you're not, one thing that I've noticed coming from a consulting background going into a corporate background is a lot of times they don't consider the cost of time. They consider the cost of tools, but they forget that me, for example, cost more than an analyst because my time is more— not more valuable, but essentially I do cost more because I get paid more, right? So I find that interesting, but which kind of goes against what I just said. But, but they don't want the disruption, yes, but they also don't want the cost because getting all the people in a room, especially when you have to get senior people in a room, that's fucking expensive.

Sorry, it is.

It is expensive.

But you know what else is fucking expensive?

An incident, an incident that you don't have to pay a massive fine for.

That's right, a fine or the ransom or the production loss or all the other things, right?

Not just that, also the trust, the cost of customers' loss of trust in you. That's costly and that's— it's embarrassing, it's costly, you know, there's not an easy way to measure that cost even. So yeah, no, Incidents are costly, yes. Preparing is costly, but not as costly, and done properly can be really effective because you can identify— I've gotten to clients that I identified the tooling they used is so expensive and it doesn't benefit them. It doesn't even meet their needs. So we removed that, got a cheaper one that actually worked better for them. I saw an interesting talk once quite recently about a company, they're an insurance company, and they research their customers and say, you know, Do you have this? Do you have that? Do you have this? To understand over time of the customers they have, the ones that have incidents, what kind of tools do they have? What kind of controls do they have? What kind of policies, procedures? To better understand their risk when they offer it to customers so that they only offer customers that are actually not going to cost them money because they're insurance, obviously.

Right, right, they're insurance, yeah.

Yeah, but what I found interesting in what they said was a smaller organization needs more tools. A larger organization doesn't need as many tools because they have the people and the experience and the skills, or maybe they have more highly skilled consultants, for example. And so, balancing-wise, a small organization should spend more on tooling than a bigger organization. Not more, but like percentage-wise more. And that to me was like, huh, that makes sense, but I never would have thought of it. And so, I think a lot of organizations, they don't know what their threat map is. They don't know what their inherent risk is. I mean, I've gone to organizations that didn't even know what the inherent risk assessment is. And I've gone to organizations that have never done a security, cybersecurity maturity assessment. Yeah, okay, I kind of get not doing that if you've, if you're very immature, possibly. But a very mature organization also would benefit there because if you do a granular assessment, you're going to see where those gaps in the foundations are that you wouldn't see looking. Because I had an organization that had failures, like incidents, and they're like, why do we keep failing? Why do we keep having incidents? And I did a cybersecurity maturity assessment, and they had great programs. They had super innovative solutions, really cool tooling, really cool awareness programs. Like, it was— I was very impressed. But they had small foundational gaps that actually meant that even though they were spending a lot of money over here, the gaps over here were causing continuous failures. And so spending a little bit less over here actually, and spending it more over here, actually improved them. And they were able to go forward and be a lot more structured in their approach. And some of it was boring, boring stuff like writing a document, writing a policy, documenting roles and responsibilities. You know, it's like, yeah, okay, not the sexiest part of security, but knowledge management is actually really, really important. And so, yeah, I think I, I've gone a little bit on a rant here, but I think that, you know, organizations want the quick fix. They want— this is a budget, that's it. But then when an incident happens, they're like, uh-huh, here's a lot more money, spend it. And then they throw money at the problem and they're not solving it. And then the techs are so bloody tired because they're like, I've been telling you this over and over again, and I want to do this, but I don't have the time. I don't have the capacity. I don't have the skill. Maybe I need training. But I'm not going to only blame the company. As a tech, it is also my responsibility to make the issues visible. I don't have the experience maybe that senior leadership do. A business and a business mindset. I have a security mindset. I went into security because I didn't want to be around people. I want to die in the server room, full disclosure. But I had to learn that, and I had to— maybe I'm not the best at it at all times, but I had to learn, and I have to actively build that relationship with the business. So it is still my responsibility as well. KPIs, not sexy but important. Documentation, not sexy but important. Having a coffee with senior leadership— maybe a tea. Well, I do drink coffee here and there, but maybe not my priority. But I need to make it my priority because they need to trust that I have their best interest in heart and we're on the same team. And I— if I say something, they need to trust that my decision took all of those factors into play and A lot of times when I'm going into an organization to do a target operating model, I have to argue that this tech needs authority. And it's like, well, why? They could just tell me. I'm like, okay, middle of Christmas, middle of the night, when they have to take a very, very critical server offline, are you going to answer the phone?

Yeah. Do you want them calling you at 4 in the morning? No, because they're going to get an authority, right? That's the problem. If you can't delegate, then you're going to be working all the time. There's no way around it. Hire people you trust, delegate to them., or just expect to work all the time, right? Because they're going to have to call them.

And they need to be able to override the business because, yes, taking a sales server offline, like a web server offline, that's going to cost money. But so is maybe causing more compromise to your environment or maybe even compromising customers. I don't know what's the issue. We don't want it. We don't want that happening. So give them the authority because they need it.

Yeah, no, it's— I mean, a lot of excellent points, right? It's— I think, um, yeah, too many organizations, you know, it's interesting. I want to go back further here to— you had mentioned reading an article, or there's a talk, I actually forgot the source already, that organizations, small organizations, need more tools and large organizations actually need less tools because they have people, which, as you said, makes a lot of sense, right? The idea of tools, the idea of technology, is force multiplication, Right? If you don't have many people, tech is theoretically gonna help you do some force multiplication, right? I've only got 2 people in the office. I really need, you know, 10 people's worth of work to get accomplished. Automation's gonna get me closer to that, right? If I already got the 10 people in the office, I don't need automation on top of that. I don't need all these other technologies.

I mean, you still want it. You still want it, but it's not as big of an issue.

Yeah, but the irony is the companies with all the money, the big companies with the money are the ones that vendors push really hard to buy the cool, sexy things, right? And they all want to, or a lot of them want to at some point because it's a cool, sexy thing. And it's, you know, it's a brag point. And we've got all these, you know, cutting-edge technologies, et cetera. And a lot of times then, as you said, they don't configure them. So now you've got this cutting-edge technology that you were sold as the solution. It may or may well be.

Might not even fit the problem.

Let's be clear.

Might not, right? That's true. Might not fit at all. But even if it does, if you don't configure it properly, it's just a very fancy, you know, piece of equipment doing nothing for you and you're spending a lot of money on it. But you're also possibly trusting, oh, this problem's solved. We've got tech working on this problem. So now we take people off of this problem cuz we think our technology's got it covered, but the tech was never actually configured properly anyway. So now you have trust in a thing that doesn't, isn't set up to succeed, even if it could be, it's not set up to succeed. And then something bad happens and what happens? They do their incident response and they come through and they figure it out and then they blame the technology. It's like, well, and then the vendor says, you can't blame us. You never onboarded. We've been having onboarding discussions for 6 months with you trying to get you to configure and you haven't configured. You haven't given us, the documents we needed to help configure this to make it work or whatever it might be, right? And so there's this big, you know, pointing of fingers back and forth while the incident continues to go on because you haven't solved the problem. But there's an irony in that the small companies don't necessarily have the money for all the tools, but the tools would help them. The large companies that have the money are buying tools they may or may not need, and if they do need them, they're not configuring them properly in a lot of cases. Why? Because they're too busy again, you know, of course. And so it seems like it comes down a lot of times to, you know, time allotment, budget allotment, and prioritization. Now, I had a question at one point prepped for the show. We've gone far afield of it, which is good, which said— but the question was, you know, what do you see as the biggest challenges security leaders face in terms of incident response? Now, listen, we've done nothing but talk about challenges at this point, so I feel like we've covered a lot of this, but it seems to me it comes down a lot of times to just, again, it's allocation of time and resources, proper allocation of time and resources, and a prioritization, right? Saying you're not worried about incident response, just handle it when it comes up, it's too late. But how do you convince people to spend the time and spend the money to prep, to do the documentation, as you said, to do the exercises, to be prepared to do the proper analysis to decide what tools we should or shouldn't have, to actually audit those tools inside, which ones we should and shouldn't keep. And if we're gonna have them, taking the time and energy to actually configure them properly, which doesn't— it does take more. Now you got to work with your vendor more and have discussions. They need inputs as well to be successful. And then you have to test those technologies too. And it just seems like, as you said, everybody wants a simple answer, right? Everyone wants the quickest solution. So whatever tool somebody comes in and tells you, oh, this is, you know what, it's plug and play, it'll solve all your problems, it's magic. Now it's all AI, right? AI is going to solve everything. You don't even need people anymore. Yeah, just call AI in and AI will do it all, which is not really the case. So what— for anybody who's just wondering, by the way, that is not how things are going to work. Please don't fire everybody and hand it over to the bots. You're not going to be happy with the results. But are there other things I'm missing? And we talk about the biggest challenges security leaders are facing in terms of incident response. It kind of wrapped up what I've heard so far, but are there other things that I missed in there in terms of, you know, allocation of time, resources? What else might be in there, you think?

I think the points that I made briefly needs to be highlighted very much more closely is I am a manager. I don't see the day-to-day. I do rely on my team to make things visible to me. I also don't have the skill set that I used to have. I mean, I used to be hands-on. Well, I'm still hands-on, but not as hands-on. I still would do, you know, I used to do all of the investigative work. Now, more often than not, I say, okay, go get this information. I might do training and teach them how to get the information for more junior people.. But for my more senior people, I expect them to know, I, you need to know step by step what to do and what information to give me and what trends to show me. When it comes to my boss, he's going to be even more further back and then his boss and, or in your case, other cases, maybe it's a lady, maybe it's non-binary, whatever. But that person, the further, the more senior they get, the less hands-on they are, the less likely they'll have security mindset. Or even security knowledge in some cases. And so, for them, we need to be clear. We need to build that relationship so we trust each other, but we need to be clear of what the actual risk is. I cannot go to my boss and say, "You didn't give me budget for this. It's all your bloody fault," if I didn't tell them, "The reality is, if we don't do this, this could be the impact." If I can't make that visible, then they can't make an effective decision. And so, if you're running into a wall where they will not listen, it could be that you're going about it in the wrong way. You're going about it in a way that makes sense to you. What makes sense to them? From a business, you need to talk the business language, which is the language of risk, risk management. Make that visible. Don't say, "I need this sexy tool because this sexy tool is going to solve all of our problems." No, probably won't as well if you take that approach. But you can say, this is our inherent risk, these are our likely threat actors, this is our likely set of— do you have a risk register? A lot of organizations do not.

Oh, risk register, that's a good one too.

That's important, you know. How do I apply what I need to the business risk and make that an understanding, speak that language? I mean, I mean, look at I currently work in EMEA. Okay, do you know how many languages, actual languages, are in EMEA?

Dozens.

Sometimes translation is an issue, you know, get that solved too, because ultimately, if your senior leadership are just not listening, yeah, okay, maybe you're in the wrong organization, but it could also be that you're just expecting them to understand something that is not their area of expertise, and that's also wrong on your side. And then I think also the point about Summation, we cannot throw automation in place if we don't know what it needs to do, if we don't know what's normal, if we don't know what's— where the gaps are. We can't just solve it by saying, mm, this will solve it, this will work. Because you might actually cause an incident yourself. I've seen that happen. And then when it comes to the complexity of outsourcing, you have to retain your accountability there. You know, we didn't talk about that at all, but let's just briefly touch on the shared responsibility model. Like, security simplicity is going to make security more effective. But no environment I've been in is massively simple. And so, we need to simplify, yes, but we also need to plan for these unknown unknowns. We need to plan for these risks that we see in an effective way so that when they come up, we also learn from it and we've planned a way to respond in a structured way.

Well, you make an excellent point about automation, right? That, you know, people say, well, we'll just automate it. The only way you can automate something— yeah, I mean, to say like a Flippant Lab, just automate that. Yeah, that's right. The only way you can automate something is if you can teach the technology or input the technology, however you wanna put it, what the steps are that are done manually now. Like if you're gonna automate something, that means you have to have documentation on how it's done manually first. Exactly.

But also what, what the case is.

Exactly.

And there's a lot of them.

You can't Yeah, well, you can't just say, well, block any account that looks suspicious because I'm sorry, middle of busy, end of, end of month, are we going to just be okay with accounts like finance to be kicked out? No, I would like my money.

Suspicious, right?

Yeah.

What are the criteria for suspicious? What's your, what is your threshold? Does it change at different times of the day or different times of the month as to what's suspicious? You know, activity that's suspicious. Most of the month may not be suspicious at all on the last day of the month.

And you can't just blindly trust technology either, because I've seen situations where, for example, Microsoft says this IP address is coming from this. No, it's not. That, that's actually the wrong country there, Microsoft. And again, not to blame Microsoft. I mean, lots of tools have these, but it's just because there's, there's a limit to the capability that technology has, and it was built by humans. We have a lot of human error. What we build has human error because we built it, right? So you cannot blindly trust things. I mean, I've had techs that have caused incidents themselves because they've made a mistake. It happens. We have to plan for it. Sorry, you're probably very tired.

No, no, no, you're very right. No, I, I think you're very right that that's— I mean, there's, there's— technology isn't the answer to everything. People just We wanna offload it. And again, it's even worse now with AI. It's like, oh yeah, I'll do it. Listen, technology doesn't think. All right. It is derivative of what we put into it, whether it's AI enabled or not. Right. It's derivative. Right. So we have to put it in. We have to put all these different processes in, all these different scenarios in. If you do automation, if you go back and look at like SOAR, when SOAR was first coming up, if you look at all the different playbooks you have to put into SOAR, SOAR could be really great if you have something that runs from, you know, a ticketing system and you can go through your tip and to your SIEM and to the SOAR and, you know, run the whole SOPA model. It can be really successful, but only if you put all the work in to build it up. SOAR doesn't come out of the box, just automate things and do incident responses, you know, do automatic response and all the things. It has to have all these playbooks built out. And all these playbooks have steps after steps after steps in them. It is a lot of effort that comes into sitting down with the analysts who do all these things, or the, the, whatever the security professionals are who do all these things manually now, and documenting each each little step and each little variable to that. Well, what if it's this? Well, now I gotta, I gotta tree it over here, and I gotta— you do all of that stuff. There's a long-term payoff, obviously, if you can plug all those things in. But you can't— it's not like you just buy it out of the box, plug it in, and go, well, that's it, Sors got it covered now, we're good, and walk away.

And also, a lot of times when you're deploying a new solution, you've got to pay double because you've got the old solution in place until the new solution can take over. And absolutely, you've got to pay the person that usually is doing it to do the design and implement. So like, it's bloody costly. I understand why organizations are in this state, I do get it. But how do we go from here? How do we improve? Well, we improve by looking at what is our inherent risk, what is our normal, what compensating controls do we have, where do we need improvements, where do we have gaps. Maybe if we're massively immature, it's actually easier to find the next steps. If we're more mature, it's harder, but it's still required. No, you're right.

You're absolutely right. And then, so how do we tie this all back? You know, I think we've, we've kind of created two different conversations here, which is perfectly fine, right? We came in to discuss, we came in to discuss how to make incident response better. I think we've had a lot of discussion. It's also just been about, you know, standard security practice and how to make security organizations more. But, but it does tie back in, right? Hi, how do we tie this all back in? It's incident response is And I'm gonna answer my own question and ask a different one. But is to, to have all these things in place, right, is, is all about the foundation, right? As we talked about at the beginning, is understanding your environment, your CMDB, and your crown jewels assessment, your risk register is a good example, right? All of your tooling, all of your people that are plugging everything into these tools to know your environment, right? You cannot do effective incident response, effective exercises if you don't know your environment inside and out, which, to be honest with you, I know very few organizations that do. So, you know, that's the reason we've, we've gone far afield a little bit on this, is to talk about that. But bringing that back into the incident response discussion, so how do we improve incident response? Is it just all the things we just discussed? Is there— what are we missing here? I know there's a bunch of things we're still missing in terms of documentation, in terms of process, in terms of communication. You mentioned, you know, language is a big factor here. How do we move past what we see right now today, which is a lot of organizations that are just firefighting and they haven't built the process in place, but they're also just very busy, right? They're overwhelmed. I don't know any organization that has enough time or enough money, money, or enough bodies. So how do we get there? How do organizations get to a state where their incident response programs are properly enabled by all these other things that are, they're dependent upon? So that we can have better incident response in the crisis? You know, how do we make that happen for folks?

Well, besides the foundations, besides the general hygiene, besides understanding your organization, I think you also need to look at what people you have in your organization. Do you— have you ever done a skills gap analysis? Do you have anybody that's actually competent to do incident response? Because incident response is a specific skill set. Understandably, some people cannot do it, and that's okay. But if you don't have anybody there that could do it, you're going to have to outsource it. So you're going to have to figure out, you know, if you have your core competencies, this is the area it makes sense to outsource. I'm not saying outsourcing is a bad idea. In some cases, it is the right idea because a skilled instant responder is expensive. They are not a cheap resource. And they must maintain that skill and continuously develop and build and understand things more. So, maybe you need to outsource, maybe you don't have the skill, that's okay. Maybe you want to build the skill, so training needs to be, you know, you need to invest in your people, maybe you need to hire somebody, I don't know. Maybe you need to outsource. Do you know what your environment looks like? Can you come, can a company come in and say, this is normal, these are where the the unusual activity is. This is not normal. This is the, the points of reference. These are the people I need to contact in an emergency. Does that exist? So how can we improve? Well, besides having your foundations, do you have the capability of responding to an incident? If you do, what's your end? Where, where does your skill end? Where is the cap, including capacity? So you may have a very excellent incident responder, one, but they may need a holiday, they may get sick, they may go, maybe they're in the hospital, I don't know.

Maybe they quit.

Maybe they quit, which is a huge issue. Loss of— when you invest in people and you lose them, you know, retaining a skill is really important and costly, but if you lose them, they may be gone, especially if nothing's documented. They may take all that intelligence out the door with them. So plan for that redundancy. But also, when it comes to getting a third party in, how do you do that in an effective way? You probably have a retainer. You need to know these people. So if you're bringing someone in, they need to know you. They need to know who to contact. They need to know who has the authority to make certain decisions. They need to know the technologies you have in place. Because they need to be able to support it. If they've never used that solution, are you going to let them learn it whilst they're responding? That's costly and not massively effective. So, how do we improve? Well, build the relationship, identify the gaps. It's just like building the foundations in your organization. Do those simulations and figure out where you have those gaps. It could be as simple as a sit-down with a team around a table and say, okay, this has happened, what do we do? This has happened. What do we do? It could be as complex as, we're going to turn all of these off and see what happens, and we're not going to tell anyone. Red teaming is important and actually really quite fun. I am security operations. If a red team happens in my environment, I'm not notified because I need to respond as if it is an incident. And so, when those happen in my environment, I like to guess when they are. And actually, sometimes I'm, I've had situations where I've been like, This is a red team, and I know the team that puts them on, and I'm like, I'm watching you. But it's fun, I like it. But I don't have an ego that's getting in the way because I know how important it is. So if you've got somebody in that's got their ego getting in the way, maybe they're not in the right position as well. So, you know, figure that out, figure out what makes sense for your organization. So how do you improve? I keep saying over and over again, do this, do this, do this. To start with, identify what your current state is, identify where your gaps are, and then identify where you want to be, because you cannot map point A to point B without the point B. And once you've got that, figure out how you get there within budget, within timeframes that are realistic, and with the skill sets and capacity that you currently have in your organization.

Yeah, I think excellent point. The point, you know, point B on a map, right? You can't get someplace you don't know where you're trying to get to. So I think that honest assessment of where are we today, which a lot of organizations don't do, maybe they don't want to do it because they don't want to be honest about where they are. And then where do we want to head to? Exactly. You know, they just, you know, that's for another day, right? You know, CMDB is the best example I can come up with for that. Over and over again, it's comical how bad most organizations' CMDBs are. When you take a look at them, you realize it's like, well, Do you really have this much Windows XP running in your environment? Well, no, of course not. We don't have it anywhere. Well, your CMDB is full of it for some reason. Have you never updated this at all? Like, what are you doing here? You know, why is this showing that you've got Windows 7 running in places? Why is this showing you have systems that are deprecated now? Like entire software systems that don't exist any longer.

Why is the point of contact for this situation a person that retired 10 years ago?

Exactly. Maybe dead. Yeah, yeah, or dead, right? Why do you have these things? Why is the risk register empty?

Why don't I suspect that's not accurate, right? We're good.

Yeah.

Although we built a spreadsheet, we forgot to populate it. Oh, well, that's really useful. You know, why are these things like this? Right.

So why are you protecting— why are you putting in controls to protect against nation-state when your likely threat actor is a bored teenager? You know, like, apply the controls accordingly.

Yeah, that's a really good point. You know, getting very excited about the things— and I, as an intel person, I run that a lot where people, you know, come out of the SOC, they're all ranting and raving, all excited. We've heard about this thing, we're really scared. I'm like, The odds of that happening to us are incredibly limited. Let's have a, a real serious discussion about why that would happen. You know, and, and this adversary is notorious for only going after healthcare.

Mm-hmm.

We're a bank. They've never went after a bank before.

Critical, critical national infrastructure. And exactly. You aren't even big enough to even be classified as that. Yeah.

You're a shoe store.

Yeah.

Like, yeah. But, but it's all over the news. Well, it doesn't mean it actually affects us. So let's have that discussion.

You can still learn from those incidents, to be clear.

100%. Yeah, but you have to change your whole environment.

You don't need to worry about that threat actor. You don't need to worry about that tooling. You don't—

yeah, yeah, yeah. Or exactly, you know, or the report comes out, you're like, well, that's true, but they compromised this piece of software which we actually don't own. We don't have it anywhere in our environment. You know, if a zero-day comes out, it's a scary zero-day, there's all these things. Yeah, but it's not in our environment at all though. We— it is specifically designed for one thing that we don't own. But I mean, we should know about it, but I wouldn't recommend making a ton of changes today because as of today, it's not a threat to us. We should learn more about it and see, can it work? You know, can it morph? Is somebody going to reuse it? Is it, you know, is it recyclable? Is it, is it changeable? But let's not lose our, our heads over something. Yeah, yeah, that isn't affecting us today. The shiny object, the scary thing on the news, isn't always our biggest problem.

No, but also the point you made about CMDB, how many incidents have we seen in the media, uh, or, or, you know, a bit of a go now, but Log4j, and then, uh, what was the latest one? Like, do you have that environment? Like, is— do you have it in there? But also, is it, is it required? Uh, well, I have no idea. So how many organizations spent weeks figuring out if they had it then months figuring out, is it something that they're dependent on?

Or should we have it?

And then more months, yeah, should we have it? And then more months figuring out, well, yes, we're dependent on it, but what version are we dependent on? You know, like software bill of, what is it? Software bill of something, I can't remember what that's called, but it's like a CMDB for our software. What are our dependencies? What do we need? Why do we have this in place? Is it just because it was installed at some point for a testing purpose and never uninstalled, and we don't have a testing environment, so we install everything on production, right?

Which happens unfortunately so often. Oh, so often, right? And it turns out, you know, we're also using a license that's expired, but that's okay, nobody checked on that either.

But also, do we have, do we have a change management process? Because do we decommission Server A that required these firewall rules, added in Server B that didn't require those, but those were never decommissioned, and it was in our development, but our development is a production, therefore this compromise is now there. Not that I've seen that for many customers, but maybe I have seen that for many customers.

Sure, sure. Change management process, another really good one. I hadn't thought about that. That's another piece that people seem to have, you know, on the first panel.

My very first conference talk was talking about configuration management. I, I created a very poorly— like, just to demonstrate it, I made like a little web server that configurations were populated to. Super insecure. Don't use any of the code that I used because I knew it was insecure because I don't know how to code because I'm not a coder. But, but, and I made it really sexy, it was a black with the green text. But like I was talking about, this is so important. This was 10 years ago that I talked about this, so why is it still You could give that same talk today.

It would probably still work out most, most places, unfortunately too.

So also I'm still bad at coding, so it'd probably still be insecure.

It's fine. It would still be fine. It would probably still work. Don't worry. AI will fix it. Don't worry about it. AI will fix it for you.

Yeah.

So all those things, you vibe code it.

Yeah.

You just vibe code the whole thing.

Great idea.

So anyway, so I, I mean, I think a lot of good points here to take away from this, right? It's, it's, there's a lot of prep that needs to be done. I think there's a lot of communication there. I think you make a valid point that there. It's not all about leadership and it's all about budget. It's also about, you know, hands-on keyboard, being able to communicate. I think speaking the language is a very interesting point about speaking language of business versus tech, which is a significant challenge because most people in tech, there's a reason they're not in business. They don't speak the business language on purpose. A lot of people that sit in the SOC don't want to talk about the business, but you have to understand the business impacts because that's what's going to motivate leadership to actually make changes. Again, I need this thing, doesn't motivate them. I need this thing because it's gonna reduce the risk by, by so much, which is gonna, you know, potentially reduce our, you know, exposure, which could be very, very expensive, et cetera. There's gotta be a number attached to it at some point. We've gotta, everybody I know in tech hates that whenever we write anything, it's give me a business justification and put a, you know, that ties it to, to risk and profit.

That's like my every day. What's the business justification? And then my techs are like, and I'm like, okay. Let's break it down. How often does this happen? What's the impact? Yeah, I get it, it's boring. I don't like doing it, but it's very important.

I will say that's an area where AI might help you, for what it's worth. If you can give it enough inputs, if you can talk to any of the— take a platform, ChatGPT, Claude, whatever it might be— if you get enough inputs and say, can you write me a business justification for this, it can. Uh, it might be bullshit.

You know what it is needing to measure.

That's right. That's right. You give it the inputs and it can. Now, I will tell you, it might be bullshit when it comes out, but it will be the bullshit that, that the business will believe and will go forth with. Off the record, don't quote me on this. Well, it's gonna be the origins of much of the world, but yeah, you can bullshit your way through it.

You could also ask your environment, are we secure? And it will say, yeah, you're great. I'm pretty sure I saw a post of one of the industry contacts I have that said, oh yeah, it said I'm 100%. Secure. I can go home now.

That's right. Yeah, yeah, yeah, I'll tell you, you're great.

Yeah, maybe don't trust it blindly, please.

No, it's so sycophantic, it's unbelievable. But, but it will help you write some of these things, which is good if you're not good at turning— translating tech knowledge and tech data and tech information into business terms and into monetary terms. Given the right inputs, the, the AI actually will offer you some decent things.

It can definitely help. Technology can definitely help. Automation can definitely help. Just use it in the context that makes sense. Have the right people that maybe you don't have as many highly skilled people, you have more junior people because you can't afford highly skilled, but you compensate with other things, you know, that just put it in context. And if you've done it properly, it's a lot more effective because you will still have compromises, you will still have incidents. But the impact will be reduced. For example, maybe you still have compromised accounts, but you've got automation in place that blocks it quite quickly so that the impact is much lower, but you need to do it in an effective way.

Yeah. No, I think that's a good point. So, you know, the crux of it is we've got to do a much better job in our documentation. We got to do a much better job in our preparation and not waiting till bad things happen. We've got to do a better job in our communication. Up and down the chain so that everybody's on the same page. And we've really got to take the, take this seriously and invest the time and energy in it and not just hand it willy-nilly off to technology and hope that that's going to solve our problems for us because the tech is very dependent on whatever we put into it. So I think, I think those are all excellent points. I think it gives people hopefully a better idea of what we're currently dealing with in incident response and how to build better programs and also when to bring in, you know, outside help, as you said, whether it's outsourcing, whether it's bringing in, you know, vendors to help, you know, contractors, consultants to help write some of these policies and processes if you don't have the time for it. It might be worth hiring somebody to help come in and do the assessments and write some of these things for you so at least you have the baselines before you try to automate things without baselines. What were you gonna say? I saw you raise your hand there.

I just had a really funny memory of awareness in the incident response process being important. Not just security awareness, but awareness in who to call, because I remember, I remember an incident where the person thought they were being helpful By when something happened, they physically destroyed the device. So no forensic analysis, no incident response could happen because screwdriver through, right?

Just drilled right through the drive.

Yeah, it was hilarious because we're like, okay, don't turn it off so that, you know, because we can't do it because, um, if you turn it off, certain things will change. So don't turn it off. Leave it. We will come investigate. Oh, okay. So it's not in one piece at the moment.

Yeah.

What do you mean it's not one piece? You opened it. It's a laptop.

I've taken some actions.

I solved the problem. It won't cause any more incidents. Yeah. Okay.

I mean, you solved one problem, you create a new one.

Which is not okay.

Valid, you cannot say to a, um, not that it was ever valid before, but you can say to a regulator, yeah, but you can't go to a regulator and say, I don't have the ability to investigate this because it's in fucking 3 pieces. So yeah, awareness on what the appropriate process is and who to contact. Also important.

Well, it's, uh, I've seen a similar story years ago in the government. We had one of those, we had a massive incident and we were Well, I guess it's still classified anyway. The details might be classified, but the broad strokes are not. There was a massive incident in the government and outlying organizations from around the world actually were, were ordered to ship their systems back to be analyzed. And multiple organizations, I don't know if they, they, I'm sure they claimed ignorance, but I'm certain they did this on purpose. We got a whole lot of systems that came back that were completely wiped because nobody wanted to be responsible or end up having any forensics done that showed that their organization was, you know, patient zero, so to speak. So yeah, pallets full of computers came back that were all wiped clean. So there's nothing you could do about it. And there was really, I don't know if there were any repercussions for that. My understanding is there probably weren't. But that's another issue you run into sometimes is nobody wants to be held accountable. And so if you say, oh, we're bringing all the systems back, we're gonna analyze 'em all, we're gonna do forensics. Yeah, well, if they just show up wiped clean, you're like, oh geez, sorry, we just thought, you know, it made sense to clean them before we send 'em back. And, and then nothing ends up being discovered. We still, for what it's worth, for anybody who's curious, we did discover who patients zero was on that one because it wasn't from one of those organizations, as it turns out. It was from another large agency, a large three-letter agency, who was not following procedures, not surprisingly. And so we were able to find out exactly what the original problem was. That happens with executives who don't follow the rules, which happens in the private sector too.

So, yes.

All right, listen, we're running out of time, so we're going to wrap up here. I think for anybody who's, you know, wants to learn more about what we've talked about today, hopefully some of this was very valuable and useful. If not, you know, ping Zoe and make her tell you more. About how to build, build a better incident response organization. But, uh, no, I, I think there's a lot, you know, that we've unpacked here and there's, we could do this, you know, for a lot longer probably. But ultimately I think there's a lot more investment in time and energy and, uh, that needs to be done upfront that, that really isn't happening right now. And a lot more documentation. As you said, a lot of things that are less sexy. Uh, but as we get ready to wrap through here, you know, you get hit with the same thing everybody else does, right? The name of the show is Unspoken Security. So, With that in mind, it's your turn now. You get to tell me something you've never told anybody some, uh, before, something that to this point has been unspoken.

Hmm. Completely unrelated to security. Um, can be.

Hmm. Believe me, Zoe told me a whole bunch of things before we prepped, but apparently those are not unspoken either.

I guess they're not unspoken.

Yeah, those are not unspoken. Zoe, Zoe's pretty open, so this is a tough one. I know. She says everything.

I have no ability to block what I'm saying because essentially I just think, why? You know, here's the things going on in my head. Is any of that interesting to you? Let's chat about it. Let's dive into this very granular topic because I love talking about random stuff. Let me think. Probably not 100% unbroken, but maybe more My accent. My accent is very weird. I get questioned about it constantly. You took the same route everyone takes. They first assume I'm Irish, then they assume I'm British, and then for some reason a lot of people then assume Australian. I don't know why. I don't sound at all Australian.

Not really, no. But there's no relationship between that, I suppose.

So not really. But I'm neither of those things. I did live in Ireland and I did live in the UK. I visited Australia, but I've never lived there, but I've done a conference there. But this is actually from Australia. But no, so my accent, it picks up when I talk to people. And the thing that is unspoken is the more uncomfortable I get, the stronger it gets. It's my sort of like defensive. So, um, if I go, uh, back to where I grew up, um, a lot of times people are like, oh, you start— you like— I know colleagues that when they go or start talking about where they grew up, their home accent picks up. Mine is the opposite. I sound more, in some cases, more posh, more British, some cases more Irish. I don't know, I guess it depends. It probably depends on how long I've been away from those places, maybe, I don't know, but it's my, like, defensive, and so I'll start sounding thicker, and then, and then I realize it, and then I can't stop it, and then it gets even thicker. So it gets to the point where I get really embarrassed because I'm like, I'm not putting on an accent, I promise you, it's just I can't control it. Yeah. And then I want to align with the person I'm talking about. So often if you have a really thick accent, I will then start picking up your accent because I'm like trying to empathize with you. And so yeah, it gets really awkward.

Yeah, it's fascinating. And as you said, like when we first started talking, I was like, well, it sounds like you're Irish, which you're not. I have actually a similar trend, I suppose, or that I'll pick up other people's accents, right? I have friends, I have friends, I have a friend, a good friend of mine from Alabama. And if we talk for any period of time on the phone, anybody can tell who I'm talking to because suddenly I sound like I'm from Alabama. I I have a friend who's from Scotland, and I will pick up his accent in almost no time at all, it seems like. I have friends from the UK. And so, uh, I'm originally from Minnesota, for those who aren't aware, which seems like nobody probably. Um, for years I, I lived out of the state for, for 20-plus years, but for years anybody who was listening to me have a phone conversation could tell if I was talking to somebody from Minnesota because I suddenly would pick up a Minnesota accent, which, as you can tell, I don't actually have. Uh, but given some time on the phone, I would pick up that accent.

I—

you could tell if I was talking to family. So I, I, I have that too. It's not a nervous thing in my case. It's just one of those things that comes naturally. I know there's some people it does. So I do find it interesting when it happens. And I, like you, have had to worry about, is somebody gonna think I'm making fun of them if I start speaking with their accent? They know I'm not from Scotland or I'm not from England or wherever it might be. I'm really not trying to mock somebody. It just comes naturally. It just, I end up mirroring back, you know, as you do obviously. Now in your case, your accent is a, an amalgamation of having been to a lot of places too, cuz you do have some Irish in there and you have some British in there apparently. I don't, I don't hear any Australian. Those people are crazy. But you've, you've been, you've been around and it's sort of picked up. And so I, I do think it's interesting. I think it's, uh, I think it's, it is an interesting thing. It may not be completely unspoken, but it's not a commonly spoken thing, I guess. And so anybody who wants to know now, Zoe is not from Ireland, uh, or the UK. I will not say where she's from cuz she didn't mention it. So I don't know if it's some big secret, but I will tell you that I know where it is and none of you get to find out unless she decides to tell you later.

So, uh, okay. I'm sorry if they look me online, they'll figure it out. So good luck.

That's true.

It's not that difficult.

It's not. If you're into Austin at all, you should have a good idea where Zoe's from. I will tell you this, it is not remarkably far from where I'm from, and I'll leave it at that and you can go figure it out. So listen, I appreciate you taking the time to be on today. This has been a really interesting conversation. I've enjoyed it quite a bit. I hope others have as well. I'm gonna close out the show in a minute. Is there anything you wanna leave? Any last thoughts? Anything you wanna plug? Anything you wanna talk about? Anything at all before we, you know, wrap wrap this up and let people go on with the rest of their lives?

I think the only thing I want to say is everybody's trying their hardest, typically, in an organization. So don't place the blame and think that that's going to solve it. What you need to do is you need to recognize you're all on the same page, on the same team. Sorry, not same page, on the same team. And so go forward together. And the way to do that is to make it safe environment to admit mistakes and limits to capability. And once you're safe and able to acknowledge your limitations or when you made mistakes, because everybody makes mistakes, um, then you can grow together and build further, build those relationships and be a lot more effective when egos and uncertainties are out of the way.

Yeah, I think that's a great closing point and fantastic, right? You have to have a safe environment. It's said, mistakes have to be acceptable. Like, it can't be a one mistake and you're out the door kind of a place, right? Because it's going to happen to everybody. We're all overworked. People are trying really hard. So are the adversaries. You know, it's part of the job, right? And, and they're, they're pretty good at their jobs too. So I think you make an excellent point about, you know, having a safe environment. It's not about pointing fingers, it's about getting better. You know, we're all on the same team, we're all trying to pull the rope in the same direction. So, uh, good closing remarks, really appreciate it. Hope people take that to heart. So again, thank you for being on the show, Zoe. I really appreciate you taking the time to be here. For everybody who's listening or watching, thank you for taking your time. Please feel free to subscribe, to like, to forward this to other people. You know, let people know you like the show. If you don't like the show, shut up. I don't wanna hear about it. No, I'm kidding. I say that all the time, but if you don't like the show, let me know. Let me see how we can improve it. If you know somebody who should be on the show, or if you should be on the show, reach out and let me know that as well. But please continue to give us that feedback and to push to, you know, grow this audience. You know, so we can continue to bring on great people like Zoe to talk about all sorts of stuff and try to make people a little bit smarter and a little bit safer. So with that in mind, I'm going to close it out for today. Again, thank you very much for being here, Zoe. Thank you everybody for watching and listening. This has been another episode of Unspoken Security.

That's a wrap for this episode of Unspoken Security. If you enjoyed this episode, follow us wherever you listen to your favorite podcasts. See you next time.

Legends are made.