Melanie Ensign: It is not a crisis unless you mess it up. if your incident feels like chaos, you're doing it wrong.
Announcer: hello everyone. You're listening to Cloud. Next your go to source for Cloud innovation and leaders insight brought to you by Global Dots.
Ganesh the Awesome: Effective communication during a crisis isn't a luxury. It can be the difference between chaos and control. Our guest today, Melanie Ensign, brings a uniquely practical perspective to the world of security and privacy. After a decade supporting security teams in Silicon Valley, she founded Discernible, a company that helps CISOs and engineering leaders communicate clearly, whether it's with their board product teams or in the middle of an incident. With experience drawn from both cybersecurity and rescue scuba diving, Melanie applies principles of real world preparedness to digital emergencies. I'm Ganesh, the awesome solutions architect at Global Dots, where we research innovations every day so you don't have to. As always, we invite you to join the conversation on LinkedIn. Let us know your thoughts. Melanie, you've coached countless security leaders on how to talk to their boards and engineering teams. What's the biggest mindset shift that they need to be heard and, drive safer outcomes?
Melanie Ensign: Thank you so much for the question. I would say the thing that comes up most often when we're working with security leaders is there's a misunderstanding currently among a lot of security leaders that communicating to their stakeholders starts with translation.
Ganesh the Awesome: Right?
Melanie Ensign: How do I translate this technical concept or technical architecture or solution into something that the business or the product teams will understand? And what we counsel our clients to do is to start with the audience. What does the audience need to hear from you? What do they care about? Why should they care about the thing that you want to talk to them about? And it feels as if security leaders are often trying to force a square peg into a round hole because they're expecting everybody to care about the same things that they care about for the same reasons. And that's usually not the case. We need to better understand the motivations and the incentives that already exist with our audiences and then transform what we're trying to accomplish as a security team in order to align with the decisions and behavior and the goals that already have business support. So I would say that that's the big thing is shifting away from a translation mindset to an audience centric mindset.
Ganesh the Awesome: M so that's a great start point. and nice insight. And we literally, we have to mention the rescue scuba diving because it's such a strange crossover from the, cybersecurity world. And we're going to love to see how these two, like, sides of the bridge meet, basically. But you say you often apply the lessons from rescue scuba diving to incident response, like, what does it mean? and to make executives saveable victims. And, and how does that change the way you prepare for a breach?
Melanie Ensign: So when I first trained to become a rescue scuba diver, the first thing that they teach us in that course is how to be more savable ourselves, right? Because we're also not immune to emergencies or accidents or things that happen, during a dive. And there are things that we can do that can make rescuing ourselves and easier or harder. The same thing is true with executives and leaders during a security incident, where you can make decisions that actually make everything worse, or you can make decisions that make it easier for your technical teams and your communications teams or your legal teams to help you navigate through that incident. There is, I think, a, a symptom of inexperience and immaturity with these types of incidents, where a lot of companies are expecting to just survive the incident, right? To get through as well as could be expected. And they're not really thinking about what could go right. They're just thinking about what could go wrong. Well, if you think about what could go right now, we can reverse engineer the types of decisions and choices that we want to make in advance so that we have the ability to make the types of decisions and opportunities during the incident. And those are principles that I first learned as a rescue scuba diver, where if I don't bring the right equipment with me, I'm limited by what I can do if there's an incident underwater, right. If I don't check certain things before the dive starts or if I deviate from our plan. We have a saying in scuba diving that is plan the dive and dive the plan. And every decision I make when I get up in the morning before I go on a dive, all of that snowballs and compounds and dictates what options I will have if something goes wrong while we're on a dive.
Ganesh the Awesome: Right.
Melanie Ensign: If I forget my extra mask or if I forget a piece of equipment or if I don't check my dive computer. And so I don't actually have, a good read on my depth.
Ganesh the Awesome: Right.
Melanie Ensign: It's one of the reasons why I dive with multiple gauges, for redundancy. So being in a position as a business leader and an executive and knowing what you can do personally so that your technical teams have a better chance of success and so that they have the maximum, volume and quality of options available to them. That's something that executives can learn how to do. But that process starts long before the incident occurs. Because once you're in a situation in what something has gone wrong, most executives get very anxious and want to do a lot of things because they're looking for action to appease their anxiety. And I've seen time and time again where well intentioned executives actually end up disrupting the process for the technical teams and hampering, the experience for their whole company where they could have come out on the other side of that incident even better than they started. but they panic in the middle and they're kind of like, I think of it as a diver who's panicking right now. They're thrashing around. You're infinitely harder to save if you're thrashing around.
Ganesh the Awesome: Right.
Melanie Ensign: so we're trying to teach executives what can you do during those moments so that the experts that you've surrounded yourself with have a better chance of saving you.
Ganesh the Awesome: As an overall concept, it definitely makes sense, you know, if you're, if you're flapping around and you're making bad decisions. But can you give us an example of some of those things that make, you know, an incident not savable or just, just a classic mistake that the companies do when they get a breach or an incident?
Melanie Ensign: One of the most common that we see is executives that expect unrealistic update timelines. They're not familiar with how the investigative process or the forensics process happens and they haven't been properly prepared with the expectations of this is when you can expect an update from the team. This is the kind of information that we need to have so that we can make certain types of decisions. Essentially what I try to do is give executives an assignment that not only can, keeps them busy while, the technical team is running their investigations, but these are assignments that only those executives can actually do.
Ganesh the Awesome: Right.
Melanie Ensign: I need you to be top of your game with a very quick decision when it's your turn. And when they're constantly interrupting the teams that are running the investigations, that slows everything down and it creates a lot more emotional pressure for the individual team members who are participating in the incident response.
Ganesh the Awesome: Yeah, well, that definitely resonates with me because, while I've never been in a sort of a BBC headline news story or something like that, I've shared my fair set of incidents over the past. and the amount of anxiety that was created by update cycles and essentially people just breathing down the neck, it just didn't help whatsoever. It wasn't making anything quicker, it was just making things a lot more stressful because there were red faced people around. so that resonates quite well. It would be interesting to deep dive into the pre process on that. but I wanted to jump into your incident response tabletop exercises because we mentioned in a pre call that you run these 60 minute drills every week which would sound completely crazy to most companies because just the idea of doing one a week, it's just off the scale. but you obviously advocate for that. So what can companies learn from this more frequent approach and what are the benefits of it?
Melanie Ensign: So this is another area where I have adopted something that I've learned from, ah, rescue scuba diving into the security context which is in scuba diving we have this context of task loading which is essentially how many things does your brain have to think about all at once?
Ganesh the Awesome: Right.
Melanie Ensign: there is a reason why more experienced divers and by extension more experienced incident responders and security team members, why they are able to respond with a level of calm sophistication and clear headed decision making compared to some of the folks who are just starting or who haven't experienced these kinds of things before. And when we're teaching a brand new diver how to respond appropriately to certain types of situations, I know that every new thing I'm asking them to do that they haven't done before requires a lot more cognitive load from them than it would for me or another very experienced diver because they are having to think about these things in real time, often for the first time. They, they don't have that muscle memory or that developed instinct for someone like someone who has gone through this many times over. And so doing these drills every week and we only do them for 60 minutes because I'm fully aware that a weekly commitment is difficult. It's difficult for me and I run them. But I know that I need people to be, I need them to have the muscle memory, I need them to not require the maximum cognitive resources for every single task. And so this is helping people get really, really good at the basics so that when an incident happens they can focus their cognitive resources on the nuance and the higher level decision making that needs to happen in order for incidents to reach the outcome that we would want. And so when we do our 60 minute drills, we're not doing an entire incident start to finish. Most incidents, at least in web2 are not going to be completed within an hour's time. But what we give participants is very specific incident communications tasks within the Context of a new scenario every week, along with other community members who have joined that day. and so you're able to try new things in a safe space. You're not doing this with the team that you work with every day. So if you want to try a new idea and throw something out there, it doesn't have an impact on your team.
Ganesh the Awesome: Right.
Melanie Ensign: And also doing this 60 minutes rather than the really big tabletops that happen on a less frequent basis, it also means that it's less disruptive to your whole team.
Ganesh the Awesome: Right.
Melanie Ensign: You can jump in for an hour and then go back to what you were doing before. And so it's low risk, safe environment. And doing it frequently means that when it really matters, you don't have to put all of your cognitive resources into those basic fundamental, communication tasks.
Ganesh the Awesome: It's pretty interesting actually, because, it's less about the actual process of dealing with an incident and more about brain training.
Melanie Ensign: So.
Ganesh the Awesome: So, it's like, and people training.
Melanie Ensign: People training and communicating with other people that are gonna be involved. A lot of the tasks that we go through in these drills is how would you communicate this to your CEO within 15 minutes? Like the briefing's in 15 minutes. You get three bullet points go.
Ganesh the Awesome: Right.
Melanie Ensign: These types of things, so that these things become second nature, so that the security team, you know, can focus on the things that only the security team can do.
Ganesh the Awesome: Yeah, yeah. Makes a lot of sense. You briefly touched on Web two there, and I know that you've worked in a Web three organization. And the difference there is that the incidents happen in minutes, you know, m much quicker. like, what are the lessons from sort of traditional Web two companies should be applying when it comes to those communication coordination?
Melanie Ensign: It's a good question, because I think there's something really important that both sides can learn from each other. On the Web three side, those incidents move quickly within a matter of minutes. So if you don't have a solid procedure for how you make decisions and how you pull in help, regardless of the problem, your funds could be wiped out before you even notice.
Ganesh the Awesome: Right?
Ganesh the Awesome: Yeah. So, yeah, just to focus on that critically, what's the difference in there? The web3 is because you're mostly talking about crypto and the fact that it's money in there.
Melanie Ensign: so mostly because the transactions happen automatically and so quickly, and the attackers are anticipating that once they start their attack, people will notice and people will start looking for it. And so they're able to very quickly move the funds around so that it's harder to Trace them. So, you know, the organizations that I have worked with have been incident responders, in those situations and have actually been able to front run some of those attacks and actually recover the funds before, you know, the attacker is able to clean everything out. But those types of things don't happen by accident. You have to plan for them, you have to enable them. In fact, one of the things that was preventing this from happening for a long time in Web3 was legal protections. If you're a white hat hacker or an ethical security researcher and you have the skills to front run an attack, but you don't have the legal protection to do so, then you're less likely to jump into help because the mechanics of doing this look just like what the attacker is doing.
Ganesh the Awesome: Right?
Melanie Ensign: So if you are afraid that you're going to get sued by the protocol for jumping into help, you're less likely to do it. So now that more and more protocols are actually adopting legal safe harbors for these white hats, we're empowering additional outside help to actually come in and help rescue those funds during an active exploit. But the other thing that I will add that I think Web3 could still learn from Web2 is that Web3 infrastructure is built on top of Web2 infrastructure. And so there's a lot of focus on Web3 exploits, like smart contract exploits, things that are crypto native.
Ganesh the Awesome: Right.
Melanie Ensign: But a lot of times we see that the attacks involve a lot of basic web2 security negligence, whether it's social engineering or phishing or they forgot to put proper multifactor authentication on an account. If you don't have really good basic web 2 security, then you're compounding the risk where in web 3 you could lose your funds in a matter of minutes. And if that happens because you forgot to put 2fa on an admin account or you had a default password on an admin account. The scope and the scale of the damage that can come from the Web three attacks is far greater. But what they really exported was Web2 infrastructure that the Web3 teams often overlook.
Ganesh the Awesome: Yeah, I can imagine that playing out definitely in real time. I mean, if you're highly focused on your Web3 infrastructure, you just take it as a given that people have tightened the screws on Web two. and yeah, the heart goes out to those guys because they have to be the most attacked and the most fished and the most everything of all companies out there. You know, probably aside from maybe Octa or some other identity companies, you know, it's you have to be airtight in that world. And I think it's almost, you know, it's almost nearly impossible. You know, there's that many crypto exchanges and things that have been done over the years that it's, you know, there's only, there's only a handful out there. And I guess you don't know about the incidents that don't break the news because they probably don't tell you about a lot, lot of the stuff that goes on in the background that, that.
Melanie Ensign: You know that if you put yourself in the position of an attacker.
Ganesh the Awesome: Right.
Melanie Ensign: And, and in web 3 we see lots of nation state attacks, but we also see other types of threat actors. But if you put yourself in their position, are you going to spend time, resources and money trying to get into an institution like JP Morgan Chase, which I'm not going to say anybody is 100%, but they have a pretty robust security program over there. Or are you going to look at this exchange that's got X billions of dollars in crypto run by three developers and their dog. Who are you going to attack first? Because everybody has economies of scale and even the most, well financed, nation state actors also have a budget. So where are they going to focus? And I think that's one of the reasons why we have seen so many attacks in the crypto space. And again a lot of it is we saw at the beginning it was a lot of smart contract exploits because people weren't implementing their smart contracts properly. But we're actually seeing a trend that now people are exploiting the Web2 software that the Web3 companies are using.
Ganesh the Awesome: It's an interesting little facet that probably is not widely thought about. so you've mentioned a lot of these. You're constantly doing these drills and you're constantly dealing with companies that are in a crisis situation or a breach situation. If somebody out there is listening and they want to level up their security team, how they communicate, like both internally and externally, like what's a top habit or something repeatable that they can do that they can start with tomorrow, that is, you know, in your tool.
Melanie Ensign: Belt two things for folks that they can do right away. The first is not referring to security communications or incident communications as crisis communications. It is not a crisis unless you mess it up. And the reason this is important from my perspective is because when, when you're in a business setting, you're talking about a crisis, it gives a lot of people unconscious permission to tolerate chaos. And if your incident feels like chaos, you're doing it wrong. Plus, incidents happen on a regular basis, and our goal is actually to disrupt that escalation path so that an incident never becomes, you know, doesn't escalate to the level of a true crisis.
Ganesh the Awesome: Right.
Melanie Ensign: Whether it's a product vulnerability, some drama with a security researcher, maybe it is an actual network compromise and an intrusion, but because we've planned appropriately, this doesn't cascade through the whole system.
Ganesh the Awesome: Right.
Melanie Ensign: So I, don't want people to think that security communications, or even incident communications always is a crisis. And I actually want to encourage folks to steer away from that being the right. You can do this in a calm way that doesn't lead to a massive implosion of your reputation and your systems.
Ganesh the Awesome: Right.
Melanie Ensign: The second thing that I would recommend folks doing is something that's called relationship mapping. So take stock of all of the stakeholders inside and outside your organization whose support, alliance, or permission you need to be successful as a security team. It may not be the people that you think in terms of the organizational chart. It may be somebody's chief of staff, it may be a staff engineer who has all of the institutional knowledge because they have refused to document it into a system somewhere. But you need to identify who are the people whose relationship and support is critical to your success. And you need to develop a strategic plan for building trust and alliances with those stakeholders, because not only is that gonna help you in terms of negotiating security outcomes into things like product roadmaps or engineering protocols, but those are the people who you're gonna have to call a favor. When you are under the microscope during an incident and you're like, I need to know who owns this service, and I need them to do something very quickly. If that's a cold call and they've never heard of you, that takes you three times as long.
Ganesh the Awesome: Yeah, Right.
Melanie Ensign: so just mapping out the relationships that are critical to your team will, you know, get you about halfway to where you need to go.
Ganesh the Awesome: Also, a top piece of advice, actually, while you were saying that, I was thinking that's both ends, actually, because not only the team the to help you out during an incident, but, you know, it's very basic advice. But the, I don't mean what you said was basic advice. What I was about to say was basic advice. But you should be doing that with. With everything that your. Your system is touching. I mean, in the uk, we had two major outages of, high street, like supermarkets, most famous one being Marks and Spencer, and they were down for six weeks. You couldn't get things online, like food, the shops ran out of food and all this kind of. And it took months and months to get to the bottom of it. But it turned out that it was due to some VM backups that were being managed by a Tata consulting group. And someone had fished the service desk and been able to get hold of one of those and then unpack it. And then they had the keys to the kingdom. And it's probably like a long forgotten thing, you know, like just, just oh, we just outsourced that backup procedure to these people. But you know, it's all the, all these little things. And you wouldn't think that just being able to fish someone on the service desk would then would lead to such a dramatic thing. But I think likewise, in the same way that someone on the service desk might lead to a dramatic impact in an incident situation or create the incident, it might, might also help you to unravel that incident later on, you know. So you. Yeah, the mapping out the team is quite interesting and actually I've worked for quite a lot of organizations and there is no org chart. You know, very large orgs don't have an org chart, which is also quite surprising. But yeah, for security people out there definitely helps just to build your own, just so you know where you stand in the world.
Melanie Ensign: Absolutely. And to make sure that you can call on those people when you need them.
Ganesh the Awesome: Right.
Melanie Ensign: And the flip side of that is that if you want to be able to call in favors, you also need to provide favors. Right. So you need to have relationships with these people. and you need to be willing, willing to help them out when they need it as well.
Ganesh the Awesome: Right.
Melanie Ensign: That's how you build the trust. That's how you build the kind of relationship where you will do something for me without asking 20 questions.
Ganesh the Awesome: Right.
Ganesh the Awesome: Yeah. Makes a lot of sense. We always like to ask everybody who comes on the show, it's our DeLorean, ah question, which is if you could go back in time and give yourself one piece of professional advice, what would it be?
Melanie Ensign: I would have told myself not to wait so long for someone else to do it. I think in the early part of my career I really expected the people in charge to do more, I suppose, to recognize the problems, to take on, the political capital, to actually get things to happen. And I trusted that system for too long, in my opinion. And I wish that I had known sooner in my career that I was never going to be able to depend on those people to do the thing that needed to get done. And once I finally realized that, I started my own company. And I think I could have been even more successful in my previous roles if I hadn't expected my leadership to be the ones to take action.
Ganesh the Awesome: Interesting M piece of advice, look to take the action yourself and don't look towards the leadership, which is, yeah, very interesting advice for people out there. Melanie, total pleasure having you on the show. Very interesting. We don't do many episodes that are kind of on this, like, psychological edge of the tech world. So genuinely interesting from my side and I think for the listener side as well. any parting words?
Melanie Ensign: Yeah, actually with your comment about not having a lot of, psychology for focus on some of these conversations, I would just, remind the listeners that technology is one piece of this.
Ganesh the Awesome: Right.
Melanie Ensign: And the rest of it is all people. And so understanding the psychology, understanding how people process information, understanding how we can persuade people who don't report to us, that's actually the job. The technology piece is usually the easier one than the human side. So don't leave out the people part and think about whether or not think about how you can strengthen and develop more skills in your interpersonal interactions in addition to the technical skills that you're developing.
Ganesh the Awesome: I think that's probably the. One of the most excellent things that I've heard as a sign off at the end of the podcast. And, I have to just echo that. Typically it people are the worst people at this game as well. You know, we ended up as a keyboard and mouse type job because we like hiding behind the screen. And it doesn't come innately, but those skills can definitely be learned. and speaking to a lot of tech leaders, you know, that this is something that they realized much, much later in their career that actually they needed to know how to be able to talk to people and how to be able to, you know, read books on NLP and these other things that actually help you along the way, which might seem like sort of snake oil, but really they, they actually help to sort of, grease the wheels, so to speak. Thank you for that, Melanie. Really appreciate it and enjoy the rest of your day.
Melanie Ensign: Thank you. You as well. Thank you so much for having me.
Ganesh the Awesome: That's it for today. Thank you all for listening. If you're ready to rethink your cloud practices and cyber security strategy, then the team and I at Global Dots are at your disposal. We've been doing it for over 20 years. It's what we do, and if I don't say so myself, we do it pretty well. So have a word with the experts. Don't be shy, and remember that conversations are, always for free. I'm Ganesh the Awesome, and this episode was produced and edited by Tomer Mulvidzon, sound editing and mix by Bren Russell. Stay tuned for more episodes.
