Transcript
type of ticket gets created from that. That issue is typically assigned to an analyst. From there, that analyst is going to spend, on average, about 40 minutes investigating that one email. When the security of the organization is on the line, that level of scrutiny makes sense. Every detail has to be checked. But when you keep those 40 minutes in mind, it becomes clear that phishing has two major costs. There's the obvious one, the risk of a breach if something slips through the cracks. And then there's the quieter one. Phishing steadily pulls precious time and attention away from the security team. At the firm we're talking about today, phishing wasn't a rarity. It was a constant. So much so that they were dealing with roughly 1,000 phishing emails every single month. And at that level of volume, it's no longer a question of if something happens. It becomes a question of when. Now, AI and automation have greatly improved this phishing detection. Analysts nowadays have a lot more content to work with than previously. However, the problem lies in that last part, being manual. When you're working at a scale, this model becomes grueling. This is where MSIM changes that approach, and owns the response, and executes it as a system. And in this story we've got today, we're going to break down exactly what happened when an organization made that shift. Our special interview today is with Mor Abraham, a team lead on customer engagements at Unit 42's MDR team. How bad was the phishing volume actually getting before automation was implemented? So before automation was implemented for the SBM team, they were essentially handling roughly 30 to 40 incidents a day, which would amount to about 1,000 a month. And per their information security team, the fact that they had to manually review 30 to 40 incidents a day actually prevented them from focusing on some of the other security efforts that they deemed as more important, because they had to spend all this time manually investigating and attempting to decipher what is a spam, what is an actual phishing attempt, and what is just a user wrongly reporting one. So the situation was quite dire for them, which is why when we went into this proof of value, the first thing that they asked for was, can you guys help us automate our phishing incident? They asked you specifically to focus on phishing, so that was a big problem I assume? Yeah, that was probably one of their biggest problems. They mentioned we have a huge effort, like a project to cover some of our DLP alerts, but we haven't even had time to go around and set up the products or the detection because we spend all this time, again, like I said, manually going through user reported emails. And to us, to myself and my colleagues, it made perfect sense that our effort for the sake of that POV should be focusing on attempting to automate their phishing incident. And so what we did was essentially sit down for what we call a scoping session. We mapped out, okay, what steps are you guys taking manually? We broke it down into five steps that seems to be very redundant and something that can be automated. And then we added one more option for a human in the loop in case the customer wanted manual intervention. It's important to know that detection wasn't an issue here. You had users flagging these emails by reporting them and alerts were firing and being sent off to the SOC team for analysis. This is where traditional MDR typically stops though, simply identifying and escalating the issue to an analyst. The problem lies on what happened after it was delivered to the SOC team. The process to address these emails went a little something like this. The analyst opens the potential phishing email, checks the headers, checks any links, checks the attachments, as well as the sender history, and then they document the conclusions. Do you want to know how long that took? How long that these experts had to spend analyzing emails top to bottom to ensure the safety of the company? Yeah, it's that 40 minutes that I mentioned earlier. With volume being that heavy, what does that do to analysts and how does it impact their workload? Right. So you have to look at, I think, two different things here. One is, first of all, obviously, it's a distraction from some of the more important projects that the customer brought up. Right. They said, there's so much in the pipeline that we want to do, but we just can't get around to it because we spend most of our day manually investigating this incident. And what it does to them as analysts is they're basically saying, from the moment that I open my laptop until the time I go home, all I have to do is manually review emails, run them through certain enrichment tools. After running them through the enrichment tools, if there's a file attached, I have to go in and manually detonate it and doing this, you know, 20, 30 times a day. And sometimes I'll find myself, and this is stuff that the customer actually shared, is that, you know, sometimes, you know, if you're a laptop stack, if you find yourself doing these repetitive tasks, A, you're prone to, you know, more human errors, and B, you know, you can't really get to the projects you really want to do, the stuff you really want to build. And at the end of the day, this doesn't only impact you as a, you know, as a person, right, in terms of making your work tedious and repetitive, it also prevents you from, you know, strengthening or improving the security posture of the organization that you work for. The part that most people miss is that these phishing emails aren't dangerous just because one email gets through. It's dangerous because the analyst's time can slip away. Even with the MDR support, analysts were still responsible for manually investigating and deciding what to do next. So when you have analysts buried under 990 emails that never really escalated, the 10 that might have actually led to something don't look as urgent anymore. That's how these real incidents can slip in. So how did the team go about addressing this problem? Well, instead of hiring more analysts or adding another inbox tool to the long list, the team did something different. They reached out to us and handed the problem over to MSIAM, not just for monitoring, but to engineer the response itself. Instead of these user-reported phishing emails being treated as a ticket, it registered it almost as a trigger. When an email got reported, MSIAM started taking a look. They began by pulling context from Microsoft 365. The user risk began to be evaluated in real time. The IP reputation was checked. Based on the collection of all of that information, the severity would be calculated automatically. This wasn't an analyst reviewing alerts. It was managed XIM executing a playbook that experts had already designed, tested, and tuned. There was no longer waiting. This decision was made swiftly. All by MSIAM. A lot of people tend to be nervous about handing some of the reins over to MSIAM, like trusting that automation. So what did it take for the team to feel confident letting MSIAM act without human decision? Right. And in that sense, even if I were to, before, you know, diving into the specific customer we're talking about, a lot of customers tend to develop this trust over time. So whereas initially they'll allow us to help them with automating the enrichment piece, they will still want to do a manual response. And as they, you know, as the trust grows and as they get themselves familiarized with our methods and practices, they will slowly start trusting us. And we've had, you know, just recently, right, a healthcare customer just hand over the reins of some of their response actions to their phishing playbook, exactly because they've developed this trust with us across, you know, several months worth of engagement. With the customer specifically we're referring to with the phishing incidents, they came from a point where they didn't really have a lot of choice, unfortunately, right? They were at a point where like, we're heading out to the holidays. We're not sure how we're going to handle this volume of alerts or incidents, you know, coming even throughout the holidays, because, you know, attackers never rest. And so they were like, they said, you know what, we want to see what you guys are capable of. We're going to give you full control over this process, and let's see how it goes. When XIM believes an email to be high risk, it doesn't escalate it or wait for confirmation. It just acts and deletes the message. This isn't just from that one inbox either, but from every inbox within the company. That's the key difference here. MDR alerts humans to take action. Managed XIM is trusted to take action itself at machine speed and enterprise scale. What used to take these analysts 40 minutes to do on their own is now being reduced to three minutes. Remember the scale of the phishing emails that they were dealing with? Those emails were being addressed hundreds of times within the month. This ran quietly and consistently in the background, while the SOC could focus on the bigger issues that were out there. Was there a point when their SOC team realized how powerful MSAN was handling these requests? Our goal was to have this automation up and running within 14 days or two weeks of starting the POV, the proof of value. We actually had it live within roughly 10 to 12 days after the initial scoping session. Initially, we got on a call with them and we showed them the automation piece, how we're automatically enriching the incidents, how we extract the IOCs and the headers and present it over to them. They were initially impressed, but where it really hits the spot was, like I said, I would guess two scenarios here. One when we caught the first actual malicious phishing attempt based on our own enrichments using some of actually PAN's tools to determine whether or not the email was indeed a phishing incident. And then the second one, and this is where it really hit home with them, they came back from like, they went on roughly 10, 12 days right off towards the end of starting Christmas really and until New Year's. And they came back after a week and a half out of the office and they see, I think it was around 10, 10 high severity incidents that we actually caught and completely been blocked automatically. And they essentially had no, they didn't have to do anything manually. And they went into the office and they see, oh, wow, you guys handle like, I don't know, 400 incidents over the course of a week and a half, 10 of them were true positives. And we didn't have to do anything, right? You perform the enrichment, you perform the response, you blocked the senders from organization, you deleted the emails across all of the organization, right? So other users may not potentially click those when they come back from the holiday. And we had to do nothing because we were out of office. So that is the part where they really, it really clicked and they're like, oh, wow, this actually works. As time went on, the impact of MCIM was undeniable. The mean time to resolve dropped by more than 90%. This meant that hundreds of hours a month were being given back to the SOC. This wasn't because analysts were working faster, but because there were no longer doing work that could simply be automated, standardized and enforced at scale. With MCIM in their stack, phishing can be one less thing that they have to worry about while the experts can focus on more meaningful threats. These attackers are hoping that someone gets a little too tired to report those emails or that an inbox gets ignored for a little too long. They want these attempts to blend in and go unnoticed. The user reporting of these attempts stopped being a waiting game and instead MCIM took over and took care of the process end to end. This is where Managed XIM goes beyond traditional MDR. It doesn't just support analysts. It also removes an entire class of work from their queue. In a world where attackers are moving quickly and quietly, you need a tool that will do the same. My name is Caden and thanks for watching. Stay safe, stay secure, and I'll see you in the next one.
