WithSecure Oyj (WITH) Earnings Call Transcript & Summary

[Audio Gap] before that ransomware is deployed. Means the detection and finding attacker activity so that you can respond effectively. Commonly, there are kind of 2 means that we see that happening at the moment. So the most popular one is an external entity, an organization like the FBI, for example, or the NCSC in the U.K. tapping an organization on the shoulder and making them aware that, "Hey, we've seen some suspicious traffic emanating from your network. You may want to look into it" or, alternatively, perhaps some of the attacker actions being detected by your detection technology. Now when 1 of those 2 things happens, what we're dealing with here is incident response before the attacker has achieved their objective. That then gives us an opportunity to respond effectively and remove the attacker before they achieve their goal. And ultimately, that is what we need to do. And that's what modern response is all about. Obviously, we're not going to touch on detection today. We're focusing on the remediation piece. But I would point you towards our [ Rainbow ] team and white papers, in particular, the purple team white paper and the blue team white paper. These are available on our website and go into much depth on how a detection can be evolved and how your approach can improve. And Arran is going to touch on a few things in that regard in his part of this presentation as well. So the objective of incident response is to stop the attacker before they reach their goal.

Yes. So just adding on to what Matt had said, when we actually accomplish that goal of incident response is often in that containment phase. And it's a really key time window. It's something that I've seen, I don't know, hundreds of investigations. And on a good deal of those, containment is something where we struggle to find the right window to enact it. And that's really because it's such a small window where you have enough information to hit that as hard as you can, but the actor has not had enough time to expand his influence over the network. You can kind of see on the graph on the screen that the strike zone, as we call it, is a really small window. It's a time where the investigators have had enough time to compile information on the actor. They've identified C2 channels. They've identified payloads. They've reverse engineered the malware. Whatever they needed to do on the case is done, but it's also before -- let's say, it's a ransomware attack. It's before the actor has enough influence to deploy ransomware across the network. In the specific scenario I want to talk to you all about today, that was a case where we came in and the actor already had domain admin credentials. The actor already had shells deployed on thousands of boxes across the network, literally thousands, too. I'm not overexaggerating. It's a huge compromise and a huge challenge to effectively contain it. So in order to hit that window and in order to really effectively contain, you need to make sure that you're poised with the right information, the right tools, and the right plan moving forward before you do pull that trigger. And now before I move on to the next slide, I do want to just mention if at any point during what we're presenting here, any of you have any questions you'd like to ask us, feel free to throw those in the chat. At the end of each presentation, we'll be addressing those questions. And they don't have to be about the presentation either. They could just be general questions about incident response, about F-Secure, about the war stories we're talking about, anything like that. So feel free to do that. But anyways moving on. So what exactly is containment? I think a lot of you probably already know this answer, but I really do think the devil is in the details when it comes to this thing because you only get 1 shot. If you get more than 1 shot, you're lucky, but you never want to plan for having more than 1 shot because once you start attacking the attacker, so it were, they're probably going to strike back. I would say 95% of the time when we enact containment, the actor is right there. He's ready and he's -- well, he's mad. They'll come back with a vengeance and do everything they can to kind of get back at you, often very vindictively, if your strategy isn't good and doesn't stop them right in their tracks. So I think what's important to think about when you're thinking about a containment strategy is that you really want to do something that buys you more time. A containment strategy should not be, at least in its initial stages, something that's going to fix whatever problem was exploited permanently. That's just not feasible in the scope of investigation and doing something like a full audit of your active directory or changing domain groups, things like that. It might seem easy enough, but every minute, every hour, he's been doing that is another minute or hour that the actor has to respond and try to undo everything that you've done to try to stop them. So what's really important as far as containment goes is that you want to start with all of the actions that will delay the actor. It will cut off their access, at least temporarily, and either force them to use a different channel or force them to reexploit things to try to get back in. And that time element is key in any incident. It's really a race between you and the actor. They're looking to get to their goal of deploying ransomware or whatever it is, and you're looking to get to the goal of kicking them out of the network. So to that end, too, you can see I have on the slide here, having something like a SIEM or an EDR capability is essential in winning that race. The visibility that something like that -- we have an in-house tool, Countercept, that our MDR team uses, but any tooling like that, that you can leverage in this type of situation is going to be essential as far as beating the actor in this containment phase because it's going to give you that visibility into what they're doing. Say they do see you trying to contain them, that EDR or that SIEM is going to be what gives you that window into their actions, and it will give you a leg up on responding to them. A lot of EDRs, Countercept included, have process blocking capabilities or even the ability to lock out an entire user on a system. While that's only a stopgap, having a measure like that, that you can take during a containment phase can be the difference between stopping them at 1 host and them getting to 100 or even 1,000 hosts when they try to reactivate their payloads. So and then the last point I just want to touch on here is you do want to try to patch any vulnerabilities you might have or do things like those active directory group changes in the containment, if it's essential to stopping whatever the actor had done. But it's only something you want to do towards the end when you've already -- you've put in the delays, you've deployed the metaphorical spike strips to slow them down. And then that's when you want to come in and actually start making those more permanent changes to the network. So as far as the actual war story, I'm sure you all -- we're all waiting after you saw the title, like where is the actual war story? Well, here it is. This incident I'm going to talk about, in particular, was what we call a category 1 incident, which just means that it was a big one. I think the total network size is something around 40,000 hosts, and a good percentage of those were compromised. The actor had used all kinds of different tooling. We saw Dridex. We saw Cobalt Strike. We saw mimikatz. We saw PowerShell Empire. We saw all these different tools being used by them. They had a really diversified portfolio of malware that they were using, which made them difficult to fingerprint and track. And it also gave them a lot of diversified access on the network. So when it says several hosts compromised on the slide, that's almost an understatement what the scope of this was. So in this incident scenario, it was more key than ever that we had an effective containment strategy that would stop the malicious actor in one fell swoop because otherwise, there are just so many bases to cover in a network of that scale. If we missed this opportunity, we would have had to start from square 1 again. So that exactly is why we can't afford to do something like play whackable during an incident. When I say whackable, what I'm talking about is those selective blockings like say the actor is using Dridex, we'll just block the Dridex executable hash across the network. That's really just going to force them to change tactics. And it can actually make it harder for you to respond because once they change tactics, all of the things you established, the TTPs, everything, go out the window because they're going to swap to a different set of malware or they're going to swap to a different set of user credentials, maybe even a different domain, if you have multiple domains in your network. So taking those little incremental containment steps can really endanger the larger plan, and that's really what you need is a plan in these types of scenarios. You want to investigate the actor's actions. You want to figure out what their MO is, figure out how they're attacking the network and sort of each and every channel in which they have to do that and find ways to stop them. You can tell I'm using the word plan a lot, and that's really what it needs to be, is a detailed plan of action when you tackle something like this. So in this incident, in particular, it was such a large network and such a large compromise that we spent several days just coming up with a plan. There were a lot of basis to cover like I said earlier -- sorry about that -- and the stakes were higher than ever, I guess. So as far as what we were trying to tackle with the plan, we broke it down into 12 steps. So the first step was really the first half of the investigation, which is investigation, figuring out what the attacker's plan of attack is. After that, in this scenario and in a lot of scenarios, the attacker's first way in is going to be some kind of exploit. So patching was an essential part of our strategy. It was something that we needed to tackle before anything else. If you're familiar with something like EternalBlue, that's an exploit that requires very little access, very little in the way of credentials, and it gives the attacker a fully privileged shell on any target host that's vulnerable to it. So when you're taking a plan like this into consideration, you always want to hit stuff like that first because otherwise, it can circumvent everything else that you're trying to accomplish. So once we had that handled, we wanted to move into domain hardening, and that's really just removing users from administrative groups that didn't need to be there, getting rid of dangerous trust relationships between networks that would potentially allow actors to jump across different domain controllers and things like that. From there on, that's really when we wanted to close those blast stores. I think Mission Impossible. That's when we wanted to block all of their C2 channels. And just as a quick note, when you're blocking C2 channels, there's almost always going to be 1 or 2 that you miss. And a lot of times, it's because the actor never used it. They had set it up. And again, that's where I want to stress having that EDR or having that SIEM in place during this phase of containment is essential because once you're blocking all those C2s, you close all but 1 door, that last door is where the actor's going to come back in it. You just don't know where it is. So that EDR tool is going to be what used to do -- identify where that C2 is and respond to whatever attack it might be. Finally, after taking those actions and hopefully getting the actor's access out of the network, that's when you want to move into those sort of whack a mollusk steps of the password resets for all of the users that are compromised. You want to remove persistence measures like scheduled tasks and payloads like malware packages from disk. Without those previous steps, those would be essentially useless, right, because the actor would just switch. But in this scenario, he doesn't have any access left. So once you've got those done, something like network controls, blocking specific IP addresses, locking down access between different VPNs and things is something you want to look at. And then finally, two-factor authentication is something we always recommend. It's sort of the, I don't want to say silver bullet, but probably the closest you're going to get to a silver bullet when it comes to stopping a malicious actor because adding that second factor of authentication to any user makes it so much harder for them to do things at scale. Even if they manage to do something like reverse proxy phish or however they want to bypass the 2FA, they have to do that for every single user, and that goes back to slowing them down and hamstringing them. 2FA is something that, that is just invaluable as far as slowing down a malicious actor. And then finally, after all those things are done, that's when we went to the reboot stage, just turn everything off, turn everything back on again, the classic IT [ axiom ]. And then from there, it's a full Kerberos reset. Your mileage may vary as far as whether you need to do this. But if they have domain admin level access, generally, you want to do it as a matter of hygiene, just to make sure that they don't have some kind of way back in like a Golden or Silver Ticket. And then finally, just verifying that everything that you've done was effective, everything worked. And then hopefully, you've been monitoring throughout this process. And if anything did go wrong, this is your chance to correct it. So we generally break these down into 3 steps. And in an engagement like the one I'm talking about, this could be -- each one of these sub steps could still be about an hour or two. Generally, you want to poise something like a containment action to happen in a time when the actor is not going to be active. They're going to be asleep or it's just a time that they don't commonly act on the network. In this specific scenario, we knew based on the time zones when the actor was acting that they were based somewhere in Asia. So we did it during the wee hours of the morning for Asia, which, conveniently enough, is the daytime in the U.S. So we started at 8 a.m. with our preexecution phase. We prepped everybody, made sure everybody knew what was going on. And then we jumped right into those patching steps, hardening controls and really worked throughout the day. And by the time the actor even saw that this was happening, they probably woke up out of their sleep from some notification or something and saw this, we had already removed a lot of their persistence on the network. We had patched the vulnerabilities that they were targeting. So they tried to come in through one of those extra C2 channels I was talking about. And because we had that EDR in place, we were able to just slap them right back down and make sure that they weren't able to reenter the network. So there are a lot of moving parts here. But if you plan this out and you come up with an effective strategy, it really does lead to a single containment rather than a series of them. And that can be the difference between a small amount of damage to your network, a small amount of recuperating and millions or maybe even billions of dollars' worth of damages as far as like time investment and maybe even equipment retrieval, if it's something like ransomware. So taking care of these attacks in the most efficient ways as possible and the most effective ways as possible is really, really important. You always want to have a plan. So just as a quick side point, I always like to mention this. When you do take drastic actions like this, it's important that they're drastic and it's important that they're going to do large-scale things and really force the actor out of the network, but it is going to have an impact on you and all of your users when you do it. So you also want to have a plan for recuperating from that. If you reset a Kerberos ticket overall, it's going to -- every single user is going to be calling the help desk and saying, "Why can't I access my account?" So that's why having everybody in on the plan, ready to respond, even if they're not active security staff, just helps ask people or anybody really that can help with this, is essential. You want to have people looking for users having difficulty or people that see strange behavior on their computer. So no matter what you just want to make sure that everybody is on task and helping with the response effort. So -- and last bit for me at least, recompromise is likely and it's also something that you want to have in your plan. I think the biggest thing you can do against recompromise is, again, have an EDR in place, have a SIEM in place. There's no better [ to make sure ] than having something that can detect any kind of attack. Patching and things like that are always -- affect developments of the security strategy, but ultimately, they're going to only help you against specific attacks, whereas something like a SIEM or an EDR tool is going to help you against everything and can lead to that quick and effective response that I've been harping on so strongly here. So that's probably enough of my spiel. But hopefully, there are some interesting information in there. And again, that plan, I think, is the key point, the key takeaway here. Having a plan when you enact containment is more essential than anything else because the last thing you want to do is try to compose a symphony and not have sheet to go off of and just tell everybody to do their own.

Thanks, Jordan. I just wanted to pick up on 3 key points, really. So in relation to this particular incident that we're discussing here, but this is pretty consistent across the range of different ransomware investigations that we conducted is that, that question, how confident are you in your backups is not often answered in a way that is acceptable when you have an attacker in your network looking to potentially ransomware your entire estate. So in particular as well, where ransomware actors are concerned, they will be looking as they move through the breach to disable things like your security tooling and ultimately destroy your backups potentially, if they're online, to create the biggest impact. So when we're talking about preparation, these things -- it's not just about preparing the process of containment and how you would approach it. It's also thinking about what you can do with what you already have. The point on visibility as well and the EDR agent. So again, in this particular breach, and this is pretty consistent, is that often sort of along the same lines of when we're asking about how confident are the buckets, we ask how much visibility do you have over your endpoints? Often, the answer comes back that they don't. And to be honest, we've had some success with deploying our own EDR tools that's utilized by our MDR service in support of investigations. But as I'm sure you will all know, deploying any kind of software in business as usual is complex. And doing that during a crisis when you have an attack on the network, number one, could not only potentially tip off the attacker to your presence, but also it's incredibly challenging. And at a time when you'd want people focusing on the containment and eradication phase, you may well end up having the vast majority of your resources deploying software and also trying to ensure that pockets are variable. And that's a very dangerous place to be. As well as sort of the EDR component, EDR must be driven, and Arran will touch upon this. And in this particular breach, and we do pretty consistently utilize our expert for hunting team on the MDR side of our business. That's incredibly useful post incident. Because as Jordan alluded to, at that point of eradication, that could often be the most dangerous part. And resurgence of the attacker is common perhaps via different means, if they set up secondary back doors that have been missed, and therefore, that level of hyper care is essential. And you really must evaluate yourselves and understand if you have the expertise available to you. And if you don't, come and speak to people who can. And we'd definitely be interested in speaking to you if you fall into that bracket. So just touching on post incident. So the problem post incident often is that the level of relief is palpable, and particularly when you've successfully eradicated the attacker before they've reached their objective. And often what happens over time, like anything in business, things evolve and things are forgotten and business as usual kind of returns relatively quickly. So as part of your preparation, it's also important to consider how you would conduct the post-incident review. And the core concept here is never let an incident go to waste and ensuring that post incident you can sort of infer that, that heightened state of monitoring is brought forward and it becomes your business as usual. And also then that the lessons learned are taken on. Often containment and eradication is tactical. It's targeted at the particular breach. But that being said, there is often many, many things that need to be addressed post breach and ensuring that you have that post-incident review in place and do it in a consistent and coherent manner. It ensures that should the worse happen to you again, you're in a much better place. So just to cover off the key takeaways from what Jordan and I have been talking about. So incident response these days is not always after the damage has been done. IR ever increasingly is coming in where the attacker is still active and live, and responding to that effectively is incredibly challenging. And your preparation is the key means to ensure that you can do that effectively. And really, the more you can prepare the better you are. But essentially, some preparation is better than none. So if you've gone into a few things, if you only have the capacity and the budget, perhaps, to do a few things, that's going to be better than doing nothing. Crucially as well, without an investigation, it's nearly impossible to remove the threats from the environment. So this is where if you call in an incident response team, they're not going to magically be able just to tell you where the attacker is and be able to remove their access with a click of their fingers. An investigation needs to take place in order to determine that. Now the speed of that investigation is going to be scaled to your level of preparation. We may well have to spend time deploying tooling and to ensure we can conduct that investigation. But without that visibility, we will be unable to eradicate the attacker effectively. So these are things that can be prepared for in advance. EDR and endpoint, for example, logging at the gateway is another very important thing to consider. And all too often, when we're taking down C2 channels, gateway logs for the firewalls and other appliances, for example, can be a very effective way for us to understand the spread of an attack and perhaps how many hosts are impacted, and particularly, if our endpoint visibility is missing at even. And essentially, why gateway logs are concerned, what often happens is that failure logging is only enabled or which means that if only items and traffic that hits against your rule set is going to be logged versus potentially everything. And as we know, attackers like to try and hide in plain sight. And often, if you're not logging effectively, you can miss the opportunity to attain that visibility. And that goes beyond the gateway as well, right, through your approach to logging and detection. It's really important to think about that. But it's about facilitating that investigation so that you have the requisite speed to be able to eradicate and -- contain and eradicate effectively. And importantly, even with the best preparation, often containment and recovery can be and is a best exercise. Sometimes it can just buy you time. Your ability to eradicate effectively, and I'm sounding repetitive here because it's so important, is down to your preparation. Prepare, and you will have a better chance of success. And a question for all of you to take-home with you back to your organizations. Are you prepared? Do you feel that your people, processes and technology are scaled to respond this way? Often, it is said that compromise is inevitable. In our reckoning, most organizations will experience a serious breach every 3 to 5 years. And it's important to understand, particularly if you haven't experienced a breach, as to do you believe you're prepared? Be pragmatic, be honest. We're not suggesting that you go away and redirect your entire budget to preparation, but it's important to do what you can. And as I mentioned, some preparation is better than none.

Thanks, Matt. Yes. So hopefully, that was helpful for everybody. Hopefully, we asked some pointed questions there that can help you rethink your own strategy and kind of prepare for something like a containment action. I want to quickly cover some questions here, but I am conscious of time. I want to give Arran enough time to cover his topic as well.

So first of all, I saw [ Jim Matson ] in the chat, and this is a good question. Will the session be made available for replay? So what we're going to do is we're recording this right now. And then after we're all finished here, you'll see an e-mail come in with the full recording. So you'll be able to review any of this later on if you'd like to. I don't see any other questions in the chat. So I've got some questions on hand here as well. So I'll just run through these quickly. So I've got 1 here. Kerberos resets can be difficult. How can we prepare? I think the best way that you can prepare for something like a Kerberos reset is really make sure that you have a good help desk system in practice, a good plan for something like this, where there's a large-scale user demand and a large-scale sort of solution for doing this. So there are third-party software packages out there that you can use. You can also just do it the good old-fashioned way. However you choose to do it, what's important is just preparing for it and making sure that you're aware that it's a scenario you might have to go through in containment and taking whatever steps are most appropriate for your environment. Another question here. What's the 1 important thing that we can do to prepare? I don't want to sound like a broken record, but it really is have a plan. Even if you don't follow most or even all of what I said in the previous slides as far as how to phrase and create a containment plan, you do still want to have a plan. And that's not just a plan for containment. That's a plan for everything, really. It's a plan for how do you investigate an incident, how do you react when you see something like a ransom note and an encryption on a system. Having those individual playbooks and then a larger plan for incident responses going to be a key element of your strategy. It's going to lead to everybody being coordinated and efficient, which is how you're going to outpace that malicious actor. So I see we also have a question here from [ Mauricio ]. How do you get through the initial panic scenario that leadership management may have during the initial discussion? So I'll start this one by saying your mileage may vary. Speaking with leadership and sort of relaying the scenario as best you can is always going to be your best first step there. But what you also want to do again is have a plan for how you want to communicate this to leadership. Having something in place like incident categorization, something you can use to say just how severe or not severe an incident is and then confidently present your next steps to them is really going to help subdue that panic, help them sort of address and come to terms with that situation. And then finally, I don't want to take too much time for questions, but [ Chris ] also asked, how important is network segmentation? Network segmentation, it depends on your environment I think is the short answer. But a bit of a longer answer would be network segmentation is going to be important if you have something like a key database server or if you have some services exposed to the Internet. Segmenting those from the rest of your infrastructure is just going to add another line of defense against that malicious actor. And that's really something that can help you slow them down and help you effectively contain them or even just detect them before they're able to do too much damage to your network. So I can see we're still getting more questions. We'll address those at the end. I want to give Arran enough time to present. So without further ado, Arran, if you'd like to jump in?

Thanks, Jordan. Thanks, Matt. So I want to talk from the perspective of MDRs, managed detection and response. So it sounds similar to incident response, but I'm talking about how we work together. I'd also want to talk about how some of the post-incident measures, let's say, the phase after Matt and Jordan are speaking about, how they can be assisted by MDR but also how some of those incidents can be prevented. And then I want to finish off with -- if we have time talking about a few of the trends that we've observed within the MDR business unit and how some of our way of working over those trends have been identified through the practice of [ threat enhancing ] that we've been employing for the last several years. So let's start with a relatively content disclaimer that incident response relies on failure. It's a lucrative industry that relies upon some sort of failure of process, a failure of prevention, continued failures of detection. Ever if one finds themselves or an organization finds themselves in this situation, all is not lost, and I'll talk about some of the measures that one can take post incident and how MDR fits at the center of those measures that one or an organization may want to take. So some of these measures that Jordan and Matt spoke about, I just want to talk about how MDR is at the center of all of these. So I'll talk about the key risks or some of the key risks that an organization has to bear in mind post incident. Some of those are reinfection. So in order to have the full or the highest level of sort of state-wide assurance to prevent any further incident from occurring, we want to have a decent or a best possible detection capability in place, which is driven by some sort of managed detection and response service. Time to win controls. I think some of the items, again, that Jordan and Matt spoke about are not simple things to implement. Sure, pretty much everyone on the call has changed advisory boards or committees through whom network changes or any change across the estate have to be verified. That isn't something that can be done overnight, and having a capability in place that assures a level of detection whilst controls are rolled out is something which is assisted or can be provided by MDR. Now similarly, the same technology stack. When managed detection and response spun up several years ago, we started building our own EDR agent. And it was during that time that our collaboration with incident response started. And there was clear similarities in the technology that was employed and how its usage could be multipurpose. It could be used for incident response, for investigative purposes, but also for a persistent service that could be provided. Hence, a lot of our capability is directly mirrored or it is the same as incident response. Hence, the tooling that we utilize is the same. And also what F-Secure as an MDR service are able to provide is the unique way in which we approach our detection work through the hunting work that we carry out, and I'll get to a brief discussion as to how we have gone about trying to define threat hunting. I just want to briefly talk about what MDR capability really looks like. And I want to bring it back to the relatively simple -- this simple image, sorry, of the kill chain. So our methodology has always been around attempting to cover or detect as many attacks as possible at every stage of the kill chain, as you can see here from delivery through intellectual movement. Not only the capability to detect at each phase, but the capability to respond on the fly as an incident occurs or any detection occurs work backwards to identify the previous steps or the techniques employed at any previous step in order to enrich our detection and capability and provide any preventative measures over to a customer. Now I also want to use the image of the kill chain here to discuss some of the items again that Matt -- of some interesting story that Matt and Jordan referred to. I think they had some ransomware incidents and they used, let's say, Travelex as an example. Now some of the methods of deployment or the ways in which a malicious actor ends up getting access to networks is actually relatively simple, and it would be -- MDR would have been a solution that would have been able to prevent some of these measures. If we think about some relatively basic malware families, Necurs, Dridex, TrickBot, items that upon execution leave pretty obvious indicators across an estate execution, command and control and persistence phases. Now originally, these would have been used for backdoor access for the malicious actors themselves but have since turned into or since been transitioned into items that are sold as back doors into large organizations. And it's as easy as a malignant actor to buy access into the target organization and once they have said access be able to deploy ransomware or any further attack that they wanted to. Hence having a capability in place that's able to detect all of these items at the first possible instance means that one is prevented from reaching the stage of the -- or the incidents that Matt and Jordan have been speaking about. I want to brief you again about what the response capability within MDR actually looks like. And I think an awful lot of providers in MDR have [ couple M, couple D ] and maybe [ smaller arc ] because the response capability is not something which lives up up to the -- or is as valid as the detection side of it. But we use response in the exact same way. So what is it? We use it in a similar manner to what IR utilize. We have a joint resource, are able to work both within the detection space and in the response phase. Ultimately, what skills are utilized? Well, take an example, the U.K. NCSCs, the National Cyber Security Centre, an extension of the Home Office, recently released some documentation on managed detection and response. Now their assertion was that it utilizes the exact same skills and should be seen in the same vein as incident response. I think even a phrase that they used was it's like incident response without the incident. So working and attempting to continuously respond to any incidents or incidents that occurs across an estate regardless of severity. That was a point in the direction of recent white paper about continuous response that F-Secure published, which goes into more detail about what continuous response actually is and how we've gone about defining it. And it benefits the customer predominantly because it provides them with the investigative method at all points during their engagement as opposed to receiving any form of, let's say, ticket or escalation. One can rest with the assurance that they are having not only a 24/7 coverage, but if the customer themselves does not have a 24/7 technology at present or a security presence that they can get up in the morning, come into the office, receive a notification that something has been entirely remotely dealt with and that form of incident that they may have had to deal with themselves has been taken away from them because of the remote presence that was or the remote response capability that has been actioned by MDR. Now it benefits us because it provides us with bluntly more interesting work to do. It diversifies the skill set of the people that work within both MDR and incident response. And lastly, it enforces our view of threat hunting. Let's move briefly on to what our definition of threat hunting is. There's a simple analogy I like to use within -- or to offensive security. The notion that a pen test or targeted attack simulation is simply a vulnerability scan, I mean that died long ago. One has to have a human-driven approach, a method of validation during which skilled tester would emulate the type of discrete actions one would associate a pen tester or an attacker, sorry, was conducting in order to produce the results that are most meaningful for the organization. And we try to apply that similar approach and use that within a defensive space. Too many solutions rely upon solely alert-driven detections as being the sole means of delivery service, whereas we once tried and implement a more human-driven approach, and that's where threat hunting came into it. Now that could mean several things. It can mean identifying or looking for new operating systems or brand-new forms of attack that have yet to be identified, hypothesizing ways in which a network could be compromised and then identifying the telemetry sources that best enable detection in order -- enable detection on the hypothesis that has been generated. Now I want to talk briefly about how some of this human-driven approach has led to us identifying various trends that we have observed within the MDR business unit. The first one I want to talk about is the fusion of intelligence. So how our human-driven approach encourages an amount of agility. If you are an industry or work in an organization that is an industry, which is targeted on China's 5-year plan, the likelihood of one would see -- or being a target of cyber espionage will massively increase. Therefore, having the agility to understand the types of threat that one may encounter as a result of cyber espionage enables you to build a more robust detection and response capability. Now I want to use, again, a rigid example. In early January, when Qasem Soleimani was killed in Iran, most of the world I think woke up and thought about the impact that would have on geopolitics or markets or economic markets. When security companies woke up that day and thought about the impact this would have on cyberspace, there were various intelligence companies that started putting up notifications, whether that be to companies associated with the U.S. Department of Defense or other U.S. federal departments to alert them to the discrete actions they would expect to see from Iranian APTs. Therefore, having an agility or the agility in place to be able to react to the kind of threats 1 would associate is a core component of MDR and something that we pride ourselves in being able to do at F-Secure. Now the second of the 3 trends I want to talk about is a supply chain attack. Now if an attacker is targeting a large organization, they can obviously go straightforward the target organization. They could also try and take a slightly more subtle approach, which is maybe go for or to attack a supplier, an organization, which you know has the legitimate access into the ultimate target organization. Now what this does is it reduces the detection or the number of steps in the kill chain at which an organization could feasibly detect, especially if you're using legitimate access from the first organization compromised in order to pivot over into the ultimate target organization. This is something that we have regularly observed, and it does make detection more difficult, and it makes the capability for stealth easier. However, having a decent MDR solution, which is able to pick up all stages of the kill chain, all that means is that it tests our capability to a greater degree and reduces the levels of detection. But ultimately, it still means that a decent solution is capable of picking it up, but it will be centered more on the later stages of the kill chain, the stages at which a user maybe -- may appear to be like a malicious insider, but they're conducting some internal reconnaissance or some natural movement across an estate. Now the last one I want to speak about is pretty simple as well. I believe it was -- 2019 was the first year where there were actually more Apple devices globally than Windows devices. And what that means is that the threat landscape is changing. It's no longer focused solely upon on Windows. We have seen, I think, the Lazarus Group, which is a North Korean APT group, recently proved that they are deploying capability or deploying resource to build malicious capability on macOS. There was a in-memory Mac -- a piece of Mac malware that Lazarus Group published or that was identified, sorry, in December. In-memory meaning that it hides its functionality by loading its malicious functionality into the memory space of a legitimate running process. Hence, the threat landscape is changing. Ultimately, even, I think this broadens up the level or the items that MDR providers are now working on and provides even greater source of information for us to query in order to identify any malignant attackers. I'm conscious of time, but that was -- that's -- brings us to the end of the section that I was speaking about. I'm going to hand back to Jordan for any questions anyone may have.

Sure, yes. And we're definitely conscious of time here. I realize we're already at the top of the hour. So I'm going to say, if you have any questions, please feel free to reach out to us. I've got the URL below, but there's a contact form on the F-Secure site. Feel free to just put in who you are, what your question is, and we'll be happy to speak with you. Hopefully, you found this webinar interesting. We covered a lot of ground today, but there's still a lot more ground to cover. This is part of -- this is actually the first part of a webinar series that we're hosting, all on the IR topic. We've also got other webinars that we're going to be hosting on other topics. So keep an eye out for those as well if you're interested. But otherwise, I'll let everybody get back to their regularly scheduled hopefully not too bad quarantine. And have a good day, everybody.

Thanks, everyone. Stay safe.

Thanks, everyone.