The fallout from a ransomware attack is every organization’s worst nightmare. But it doesn’t necessarily have to be, if you can respond to an attack effectively. As our guests for episode 54 of Cyber Security Sauna explain, there are things companies can be doing in advance to ensure a proactive response to ransomware when it happens, and to reduce the impact to the company. Incident response experts Jordan LaRose and Matt Lawrence of F-Secure joined the show to discuss.
Janne: Welcome, guys.
Matt: Thanks for having us.
So how is responding to a ransomware attack different than responding to any other type of incident or breach?
Jordan: When we’re talking about ransomware, the kill chain is largely going to be the same, right? The attacker’s going to come in with the same techniques, they’re going to move laterally with the same techniques. It’s just the end goal that’s different. But because of the impact that ransomware can have in an estate and because of how much of a risk that is, there’s no other time where, I suppose, time is of the essence than ransomware.
Response needs to quick, it needs to be organized and it needs to be efficient. Because if you lose 20 minutes creating a JIRA ticket or following some approval process or something, anything that slows you down could be the difference between the entire network going up in flames, and you wiping the sweat off your brow and the attacker meeting that same fate.
So is it actually possible to, sort of, detect and stop a ransomware attack early enough that there is no damage?
Matt: It certainly is, but like any kind of attacker grouping, there’s a broad scale with ransomware actors. I think in a general sense, we will attach them to largely criminal groups that are financially motivated. But there are some outliers and perhaps nation states who have doubled in ransomware-like extortion.
But saying that, from what we’ve seen over the past several years as we’ve seen this kind of change in the way these attacks are conducted, I think the obvious comparison to make is to like a wide-scale attack like WannaCry. People understood that as a piece of malware that’s going to replicate over the network and then slowly encrypt any devices it executes on and can gain access to. But the distribution of that was largely automated from the initial point of compromise.
Whereas what we’re dealing with here is this is human-operated ransomware. This is attackers gaining access by some means, often by any means. And then following that, they then proceed to compromise the environment, proceeding through the kill chain. We’ve seen broad evidence of these groups trying to do things like impair the security technology within the organization they’re targeting to ultimately make it, I suppose, easier for them to deploy their ransomware.
So within that process, if any objective an attacker is working towards, at some point they have to execute something somewhere to achieve their aim. And that always presents potential opportunities for detection.
With ransomware attackers though, and this does change over time as tactics improve, but I would say there are genuinely many opportunities to attack ransomware actors today. They are not the most sophisticated attackers in terms of the things that they’re doing. It’s the equivalent of a kid walking into the kitchen banging pots and pans at times. They’re not necessarily the most stealthy of threat actors. So there are really substantial opportunities, and organizations can do a lot by prioritizing the right things.
That’s reassuring to know that. Because you think that ransomware is happening, like you mentioned WannaCry, it’s happening at the speed of computers. But you’re telling us it’s happening at the speed of humans and sort of they’re spreading by hand, artisanal ransomware. So we have that moment to catch them before it’s all gone.
Matt: For sure. And again, it’s a mix of experience and sophistication across the threat actor groups. But in a general sense, they are detectable, and organizations and individuals can do things to prevent their ultimate demise, which with ransomware, I always say, can be an extinction-level event for an organization.
So does that match what you’re seeing, Jordan? Do you have any advice for what companies could be doing to make it easier for them to catch the bad guys before things have gone too far?
Jordan: When it comes to ransomware, I think one of the most interesting differentiators about it is that ransomware is a business. It’s financially motivated. And that’s something with a lot of other incident types that we struggle with, is finding motivation and finding ways that we can leverage that knowledge to better respond to the incident.
But when it comes to ransomware, it’s just like interacting with another business in a lot of ways. They all have a budget. They all have essentially a valuation of, is it worth it to go after this company? Are we going to make money off of this?
And because of that, one of the best things you can do to stop it is really just throw a bunch of caltrops at them, slow them down. The slower and more annoying you make it for them to ransom your network, the less likely it is that they’re going to be persistent. Because eventually, they’re going to say, “Well, this isn’t worth the money at the end of tunnel. There’s no pot of gold at the end of this rainbow. Let’s move on to the next guy.”
Because there’s an infinite amount of targets out there for them, more or less. The target demographic for them is the entire internet. So if you can make yourself the smallest target possible, you’ve got a much better chance. What’s that saying? It’s like “I don’t need to run faster than the bear. I just need to outrun everybody else,” right? It’s just like that for ransomware.
So what are those caltrops you can use to make it slower and more painful for the attacker?
Jordan: A lot of them are really going to be just your lateral movement stoppers. So things like implementing a local admin password solution on Windows or proper network segmentation, proper use and segmentation of admin accounts versus work accounts. It’s really going to just be anything that makes it one, two, three, four, however many more steps in the kill chain. And as many of those as you can implement, the better.
And the same goes for response as well. A lot of the time when we’re responding to an incident like this, we’ll do things like try to slow down their network traffic, or block off key sluiceways in the network to stop them from spreading quickly. They might still be able to spread, but they can’t do it fast enough to make it worth it for them. And we’ve found that to be really, really effective in essentially getting them to throw their hands up and say, “This isn’t worth it anymore.”
Sure, sure. You’ve argued that incident response shouldn’t be just a postmortem exercise. Can you talk a little bit about what you mean by that?
Matt: In a positive sense for us to change the game here, incident response needs to become a business-as-usual activity. For incident response to be BAU, there are certain things that need to be there. We spend a lot of time in F-Secure talking about the importance of incident readiness. That feeds into the fact that to be able to analyze a compromise and to defeat it, you need to be able to review evidence.
So if we can make sure to the best of our ability that the requisite evidence has got a chance of being available, it means that when detections do happen, you’ve got a much better chance of reacting to them well.
You’ve also got to think about means to regain control of your organization. And so with ransomware attackers, for example, we see situations when they’re midway through their kill chain. They’ve gained an initial insurgency. They’ve started hopping across boxes, laterally moving. By that stage, they’ve probably popped credentials, and they’re kind of moving through their attack path to reach their ultimate goal. Which is generally, in a Windows environment, it’ll be the server infrastructure because generally, that has the greatest level of access to the wider organization.
But through doing that, there are certain things you can do to mitigate further risk once you detected them. I’d say it’s the equivalent of managing a forest fire. If you have an ongoing fire, you need to mitigate the risk of it spreading, and one way of doing that is to implement fire breaks. Often easier said than done, but certainly, much easier to do proactively.
If you’re trying to chop down trees in the midst of a fire to create a fire break, there’s a chance you’re going to get burned in the process of doing so. Whereas if you plan out appropriately and do things months before, perhaps in the rainy season, long before you’re experiencing a forest fire, you’ve got a much better chance of doing it properly and robustly.
And thinking about what you’re going to do when an attacker is inside your network, your cloud infrastructure, whatever it may be, will enable you to ultimately enable your people to take action. And when we can do that, that’s when we can start winning. Because we can turn around the response much quicker. And the quicker we turn around the response, the faster we can contain the threat actor and, ultimately, remediate their presence.
And when we do that, that’s when we’re taking incident response from a exceptional activity running at a time when a business is being severely impaired, to one where it’s happening all the time, but in a controlled fashion and the rest of the organization is able to run.
That makes perfect sense to me. Is that, Jordan, also what you’re seeing? Do you have any recommendations to add for our organizations to sort of help them minimize the impact of a real incident?
Jordan: When it comes to IR, it’s almost too obvious to say that it shouldn’t be postmortem, right? Of course, you want to beat the attacker to the punch, but I think what Matt is saying is really important. Some organizations are thinking oh, we’re just going to lose some data or maybe a couple of hosts will go down. But we see situations where organizations are bombed back to the stone age. I’ve seen clients call us, and they’re walking around with pen and paper and trying to do what servers and computers can do with their own two hands. It’s like you took a time machine back to the 1800s or something.
So getting yourself into that situation is something no company ever wants to do, obviously. But what’s tough about it, and why we see so many organizations struggle with it, is that when it comes to IR, it’s really a question of essentially a chain, right? If any one link in the chain is weak, then the whole chain is weak.
So when it comes to recommendations, it’s really top to bottom. There’s no such thing as too much due diligence. And the biggest challenge that I think you’re going to find is not necessarily what can we do, but more which thing should we do.
Not to drown everybody in metaphors, but I like to think of it as like a drag race, right, like you’re building a drag racing car for this race. The race itself is only going to last 10 seconds or whatever, right, but the time you take to build the car could be years. And when you’re building that car, you don’t want to skimp on any part. Now not everybody can afford to build the best of the best drag racing car, but then it comes to a question of what do I invest in first? Is it the engine? Is it the tires? Is it the pit crew? Who or what do I invest in? And that’s the question that organizations should be asking themselves is more like which, not what.
And just to continue that analogy, too, another thing you have to realize when you’re thinking about this drag race is that the person that fires the starting gun is not going to be some impartial third party. It’s up to you to fire that starting gun, but the trick is that the attacker is going to start as soon as their car is ready to go. They don’t care about when you fire that starting gun. So you have to invest in more than just the car. You’ve got to invest in a good starting gun, too.
Wow. Not only are you an incidence response expert, but you obviously know your way around that quarter mile a lot better than I do. Very impressive. So okay, so how good are companies in this regard? How prepared are they in your experience?
Jordan: It varies wildly. Some of the incidents we see, everything goes really smoothly. The attacker is gone before they even really got a foothold, and it’s all thumbs up, we’re good. And sometimes, nobody’s prepared. Everything’s on fire and the world is ending.
Now what I, unfortunately, can say, is that it is much more often that we see the latter than the former. It’s much more often that people aren’t prepared. And a lot of times before the incident, they think they’re prepared, but when it comes time to actually jump in and deal with something like this, everybody sort of says, “Well, I didn’t expect it to go like that,” or “I didn’t expect this system to get infected,” or “How do we follow our process if the process is broken?”
That’s really why things like readiness exercises, tabletops and, essentially, just hands-on practice are so important. Because when it comes to responding to an incident, you could have the greatest technology and the greatest process in the world, but if you’ve never practiced it, your people might jump in and ruin all of that work you put into building that process and building those technologies.
So like I was saying before, it’s really about being prepared in every aspect, not just putting all of your eggs in one basket, but the million dollar question is how do we spread that out? Where do we put the eggs, if not in one basket?
Yeah, what I also want to know is what’s the difference between the companies who do well and who do poorly? Is it the readiness stuff you mentioned, just the fact that those who do well have taken the time to dig their trenches during peacetime?
Jordan: Yeah, I mean, it’s readiness, but it’s also technological preparations. I was mentioning some technical steps that you can take with Windows AD and things. It’s building up your people, making them stronger.
But another, I mentioned it before, but another key step is the process, right? You need to have a plan to follow. You need to have everybody’s duties preordained because, like I said, that drag race is only going to last 10 seconds. You don’t have time to sit in a room and say, “Okay, you’ll do these tasks and here’s your checklist and here’s everything you do.” Multiply that by a hundred or whatever your response team is, and this meeting is going to take longer than the whole incident is. You need to have all of these things built before the crisis happens.
It’s difficult for organizations to invest in this stuff because there’s no immediate return. You can put millions of dollars into your incident response capacity and see zero return on investment for years, but all it takes is one incident to justify that. It’s not just whether we’re going to get compromised or if we’re compromised. It’s when. So even if you invest in that and you don’t see a return for years, when it does hit you, I can almost guarantee, you’re going to get that return on investment. We’ve seen companies lose not millions, but billions of dollars, or at least have it on the line during an incident.
Matt: I’m trying to coin a new law as a direct competitor to Mikko’s Law. I’m calling it Matt’s Law. It’s very difficult to generalize, as Jordan explained, but generally, the bigger the organization, the worse the readiness…tends to be the case.
Matt: We all know how large organizations can be like massive cruise ships at times…they can be incredibly difficult to maneuver and maybe occasionally get stuck in the Suez Canal. But I think that’s an interesting conundrum and one that we need to continue to tackle as an industry.
But what that says to me, and my experience certainly speaks to this, is that actually to a great extent, smaller organizations, SMEs, actually have a little bit of an advantage here, if they engage and do the right things. Because a smaller organization, generally, you’re dealing with far less complexity in your technology, and perhaps your organization is a bit flatter. There’s less bureaucracy, and perhaps it’s easier to navigate the culture.
‘Cause that’s the other thing with response, is that leadership and culture can actually have a greater impact than technology. Kind of sounds a little bit insane to say that because you’d think well, incident response, if it’s a computer security incident, it’s going to be happening on the technology. How possibly could culture and leadership impact that? An attack’s going to happen or it isn’t.
Well, in large scale breaches, we see the impact of things like strong leadership. In the midst of the crisis, focusing on getting the job done, getting the business back on its feet rather than playing the blame game.
But also the culture, that’s something that all organizations should pay attention to during peacetime. And the themes Jordan discussed there are absolutely spot on. Train, practice, find these things, have the requisite checks and balances in place, and do it proportionately.
We’re not saying boil the ocean here. If only you can do 1% preparedness, if you can only as an organization commit one hour a week – ideally, it’d be more than that – but if you can only do one hour week, that’s going to stack up over time. And you will hugely reap the benefits when you are compromised.
No, that makes sense because there used to be a time when companies used to tell me that we’re just a small company out of the way here. Nobody’s interested in us. But then along came ransomware. Ransomware doesn’t care about how big or small you are. If you look like a target, if the worms or the attackers can get in, they’re going to get in and you’re done. Just the same as any other more interesting company or whatever.
Matt: Yeah. No, for sure. I think labeling it as ransomware is actually somewhat erroneous. Yeah, of course ransomware is ultimately within the attacker’s toolbox, but I think it doesn’t do a good job of describing this type of attack really. It’s more akin to like a protection racket, like the mafia used to run and probably still do in many parts of the world. It’s about preying on the fears of organizations and exposing them to data breaches, reputational damage, regulatory fines. It’s all about fear.
And partially being well prepared and ready to respond can be incredibly empowering when faced with the way of something like a ransomware attack.
You bring up an interesting point. The game has changed. Threat actors are now not just locking your data. They’re stealing it and threatening to release it. So things that we used to recommend companies to do like keeping backups, that’s not the cut and dried solution anymore that it once was. What now? What are companies supposed to make of this?
Jordan: The industry never gets any less complicated, I think. It never gets any easier to respond, but it certainly gets harder. When it comes to how attacks are developing and how you can respond, I don’t think there’s such a thing as an easy solution anymore. There’s no just, oh, well, we’ll put in backups and we’ll be okay. Or rewind 20 years, oh, just get antivirus and we’ll be okay. There’s no single solution. It’s really all about having that robust toolkit, that cycle of people, process, technology, all three of those things that you need in place.
And to break that down, some of the key pieces in each one of those areas, I would say, are EDR. EDR is super important when we’re talking about response, because it’s very hard to do any kind of forensics when you don’t have any evidence, right? You need a crime scene in order to do your detective work.
As far as process goes, an incident response plan is the bare bones minimum, right? You need to have some kind of high level plan of what you’re going to do. Otherwise, it’s going to be pandemonium when you send that email or open that incident bridge and say “Hey, it’s time to respond now.” A lot of people will then say, “Well, what are we supposed to do? We don’t have a plan for this.” And that’s going to be a disaster if you don’t have that in place.
And then finally, when it comes to people, it’s all about training them. It’s about giving them the chance to get their hands dirty, wrangle with an incident or something like it, and learn by doing. When we talk about readiness, I think a lot of people will immediately jump to incident response plans and things, and those are important, but what’s also really important is giving people that opportunity to jump in and be a part of this.
It’s something that a lot of people on your incident response team aren’t even going to have ever thought about before. They could be sysadmins. They could be lawyers. They could be HR people. Incident response is not at the forefront of their mind. It’s probably not even at the back of their mind in their day-to-day. So you really do have to give them a chance to try this stuff and practice it before the entire company is on the line.
The thing I really want to stress is that it’s a complex equation that’s only going to get more complex as we develop. Things like cloud technologies as of late have complicated things immensely. Now when we do forensics on a host, it’s not just about the host, but it’s about all of the containers inside of that host that we have to pull apart and analyze individually. So that’s just an example of how things are developing and how much more complicated things are getting. And unfortunately, it’s never going to get any easier, at least not as far as I can see.
No. And on that topic, a lot of companies are out there trying to buy a piece of technology that will make their lives better. So what about you, Matt, do you have any advice? Is there a piece of technology that you like to see organizations have in place that will help you as an incident responder sort of to do your work more effectively?
Matt: I think EDR, from an incident responder perspective, is the obvious one, because that’s about giving us the visibility and ability to take action.
And readiness isn’t the whole answer, by the way. It’s part of your defense in depth. You cannot just prepare yourself to be ready for response and not have good detection in place. Because ultimately, if you’re going to respond to something, you need to detect it first. So the key is discovery.
But it really all boils down to enabling your people. And I think we need to…Organizations need to take their cues from elite sports teams. The key thing that elite sports people are doing is it’s about the mind. It’s about thinking clearly under pressure. It’s about being able to be calm and precise when faced with taking a penalty in front of 80,000 people.
Well, translate that to a business and incident response. It’s when you’re facing the worst possible moment, it’s about buying yourself time and giving your company option. And then, the ability to execute because your team is well practiced, well trained. They understand what all of the items are and what is at their disposal, and they can activate it.
So I would say, Janne, to answer your question succinctly, the best thing an organization can do to prepare is to start at home and look at what they already have, and improve what they have first and do that quickly, and then move on to adding to it. Because all too often as incident responders, we see organizations that have not used the best of what they already have.
The big one for me, and if everybody can do this, please go and check your gateway logging. Nine times out of ten, it’s switched off because it’s not been looked at since it was installed. And that’s a microcosm of what happens in organizations. Something isn’t visible, it is not obvious that it is there until you need it.
And readiness is about uncovering these things proactively, coming into the situation and evaluating the organization from the lens of being in the midst of a compromise, and then taking steps to improve it. And as I say, any improvement will help. Lots of 1% improvements will add up to an effective approach over time.
Well, I mean yeah, if they’re aligned, and that’s my point. That was some very tangible advice right there, but I feel a lot of this is easier said than done. Where, you know, to be more prepared, you should probably prepare better. So if an organization feels now that they maybe could have a more proactive approach to this, how would you recommend they get started?
Matt: The place to start is looking at your existing plans. Look at what you already have today and stress test it. We think of tabletop exercise as an example of this. Tabletop exercises are not just purely paper-based exercises anymore. They’re not the thing that you do once a year and it’s just to tick box against whatever regulation you have to adhere to. It really is a tool that can be used during the discovery process.
Because remember, this all boils down to people really. The crux of any serious compromise is the people. So if we can look at what we already have, stress test our existing plans, come up with a scenario that’s really going to kick the tires of what we have, and see what happens.
Don’t be nervous about failure, because accept that you are probably going to fail in the early stages. And it can be really an eye-opening experience in the early stages of any planning exercise to put your team through a tabletop.
And make sure it’s well positioned. Make sure they understand why it’s there. We’re not there to catch people out. They’re not being examined. This is a discovery process to understand where the deficiencies are and ultimately, what quick wins we can do to make improvements. And then once you understand where the problems are, you can then begin to improve them.
And I think in particular, every organization needs to think about this over the last year because of the broad escalation to remote work making many legacy response plans obsolete. Things like the physical access safety blanket, the ability just to walk over to the server room and pull a cable out, in many regions has evaporated over the past 12 months. And that’s an example of something that should’ve prompted all organizations to review their response plans.
But start with what you have, authenticate it, and then move on from that point. Because it’s easier to do that than start from a completely blank page.
Makes sense. So we’ve discussed how important preparation is to an incident response. But let’s say for whatever reason my organization hasn’t prepared at all. We’ve not done tabletop exercises. We haven’t created a response plan. We have none of that in place. But now everything’s encrypted. Everything’s hit by ransomware. What do we do next?
Matt: If it’s postmortem, they’ve been hit by ransomware, let’s make an assumption at this stage that the business is severely impaired. The goal, in an incident of that type, is generally we need to get back to business as usual as quickly and safely as possible.
So if we just consider a fairly generic standard corporate organization with several hundred hosts to give us an example here, if they’ve got no planning in place whatsoever, it’s not just a technology issue, it’s not just about getting the network back up and running. It’s about communication. What’s the message to our customers? How are we going to update them? We got a blank page here. We’ve not got a process in place. All of our network’s offline. Our email systems are inaccessible. Our IM systems are inaccessible.
The first thing you’re going to want to be doing is coordinating your people and trying to kind of get them together in some form of coherent means. And once you’ve got your people together, you can then start working your way through the problem, and dividing and conquering.
But it really is a bad situation to be in the midst of a cyber attack and not have any plans in place. But we do see it, and that’s when big mistakes happen. That’s when sometimes an organization will actually shoot itself in the foot and create more impact, sometimes than the attack itself. And that can happen with things like people panicking.
This is why it’s so important that people think clearly under pressure when faced with an attack. Because sometimes by trying to do the right thing, by say, I don’t know, running around and powering off all devices may seem like a good step to take. But actually what you could be doing in the age of fileless malware and other nasties that don’t hit the disk, what you can actually be doing is removing 50% plus of the available evidence that would allow you to sort of chain this back and understand what has happened, which is generally that question is like, what has happened? What has the attacker actually done?
It’s these things that you can workshop, you can get preparation in place. And we see evidence of this. When organizations commit to this and do it properly, actually, a major breach, counterintuitively, can be a situation that builds trust with their customers and enables the organization to maintain their business and to be impaired, experience cost, but ultimately survive.
But to start from nothing these days is a really dangerous place to be. And I’d encourage any organization that hasn’t engaged in this process yet to do so immediately, before it’s too late.
Yeah, instead of just writing that letter where you claim that in the face of all evidence to the contrary, your security if very important to us and we’ve taken all the steps we can to protect your data, which is now gone.
Matt: Yeah, yeah, it’s the same cut and paste line that comes out, isn’t it –
It is, isn’t it? There’s a template out there somewhere.
Matt: Yeah. But you can obviously pre-prepare for these things, right? I don’t think it’s that wild to suggest that if we are compromised, that chances are we’re going to have to inform our customers. So we’re not necessarily going to know what the situation is going to be, but we’re going to probably prepare for the process to doing that on the assumption that a lot of our standard means of communication would be disabled.
Maybe we can…I don’t want to advocate shadow IT because that’s another huge problem, but maybe we can, in partnership with the IT department, we can set up alternative means that are completely offline that give us some facility to then actually start interfacing with our customers and begin the process of returning to business as usual.
I would go as far, Janne, as saying we’re approaching the realm of common sense here, really, and it’s just a lot of the things I see-
I don’t know, I felt you were just talking about PR, computers and Faraday cages, which is far from common sense, but maybe that’s not what you meant.
Matt: (Laughing) No. No, but if you could afford a personal Faraday cage, I would highly recommend it at this stage. No, no. It’s about being proportionate, right? I see many people disengage with this process because it’s IT’s problem, or it’s a difficult issue. It’s somebody else’s problem to solve.
I go against that viewpoint completely and say it really is the responsibility of many people within an organization. I’m not saying that we need to transfer blame to inexperienced users here. What I’m saying is that people who are perhaps not technical natives, for example, have a great deal to give the readiness and preparing for compromise process. Because you can leverage your experience and knowledge that you’ve gained, sometimes from years and years of doing business, to see through this and begin to think of it in the logical steps that you can take that are going to be impactful.
Jordan: One thing that is really crucial in incident response, I don’t want to wax too philosophical here, but as humans, we tend to learn very well from our mistakes. But with incident response, you don’t really have a chance to make a mistake. If you think back to prehistoric times, how do we know that this mushroom is poisonous or not? Oh, well, let’s have Bob go over and eat the mushroom, right? You don’t want to be the guy that eats the mushroom and ends up six feet under.
As a case study.
Jordan: Yeah, exactly. You want to be the one that watched Bob eat the mushroom and said, “Okay, I’m not going to eat that mushroom,” right? You don’t want to have to learn from your own mistakes.
The benefit of living in this era with the internet and all of this information available to us, is learn from everybody else’s mistakes. There are huge incidents that happen day in and day out, with so many valuable lessons that can be learned from them. And that’s really what’s going to save you when you come to an incident, is learning from those lessons, being prepared, and just making sure that you’ve got that mindset and that wherewithal ready so that when this happens, you’re ready to start that sprint.
So, speaking of learning from other people’s mistake, let’s say I’m that individual that I feel that I maybe shouldn’t have clicked on that link, and now everything’s displaying skulls and crossbones and everything’s ransomwared, and it’s probably my fault. What should I do? What shouldn’t I do at that stage?
Jordan: As a user, the best thing you can always do is be honest. You want to escalate. You want to tell people that this is happening. Speed is always going to be of the essence with incident response, and you as an individual are part of that speed. You’re part of that process, and you’re actually one of the most crucial parts, if you’re the one that has the skull and crossbones on your screen, because the five minutes that it takes you to decide whether or not to report this thing could be the five minutes that makes or breaks the incident.
The start and end are very definite points in time, and every single minute that you can contribute to reducing the amount of time that it takes your team to win that race is going to be a huge benefit for you and for your company in the long run. Even if it’s embarrassing to say, “Yes, I did click on this very obvious phishing email.”
Matt: Just remember that phishing emails and the like are designed to deceive. So the best of us at different stages will have clicked a phishing link, I’m sure. Don’t be ashamed or embarrassed of falling victim to these things. Compromise is inevitable. It will happen. They target people for a reason.
And ultimately, the best thing to do is to be as genuine and as open as possible. Because if you can tip off your blue team early, then you’ve got a fighting chance of the organization being able to do something about it.
All right. Well, with that, I want to thank you guys for being with us today. Thank you, Matt and Jordan.
Jordan: Yeah, it was a pleasure.
Matt: Thanks for having us.
That was the show for today. I hope you enjoyed it. Please get in touch with us through Twitter @CyberSauna with your feedback, comments and ideas. Thanks for listening. Be sure to subscribe.