Why Active Response is Vital in Security Monitoring

Over the last couple of years we've had a multitude of updates for just about everything from PCs, Macs, phones & tablets, to routers and even switching devices which have included malware.  We've also had manufacturer source codes released, and a ton of breached account information posted to the dark web.

But you already knew about all of this...so why am I stating the obvious?

Because most organizations have bought into some of the EDR, XDR, and even MDR offerings which are really nothing more than just glorified SIEM solutions.  They send alerts and notifications which are usually performed by some sort of Artificial Intelligence (AI) or Machine Learning (ML) engine which may or may not have been reviewed by an actual threat analyst.  But the harsh reality is most of these services are nothing more than an alert that you or your team still has to take action on.  Were you sold on an active response service but just getting another alerting mechanism?

Please don't misinterpret what I'm saying, there's nothing wrong with a SIEM.  They are extremely valuable in the grand scheme of all things security.  But if you think a SIEM or SIEM service provider would prevent an actual attack...think again.  These are notification and alerting systems, not reactionary policy or configuration management solutions. And I'm not aware of a SIEM having the ability to lockdown a compromised system.  So unless your SIEM can verify and validate the activity being seen is an actual attack, then update or change a policy or configuration as a response to that specific attack...it is only a notification.  While there are a couple of vendors and service providers who take this information and act on it on your behalf, you need to verify what they're actually seeing isn't legitimate actions being performed by your administrators or users.

Practically every person managing a SIEM, this includes SIEM service providers, will filter out events based on suppression rules.  If there's a noisy event that constantly triggers an alert, it'll get suppressed and subsequently ignored.  If a signed and, what should be, trusted file or driver is doing something...it usually gets ignored and filtered out just because it's signed.  At least until it leads to an actual security incident and is found to be the origination of an attack during the RCA (root cause analysis).  But by then it's already too late and the business has been impacted.  We all know it happens, and more than we'd like to believe.  And yet some reason people will continue to do the same thing over an over again while expecting different results.

Many EDR, MDR, and even XDR services and solutions are the same way.  They utilize suppression rules to reduce the noise so it becomes "manageable", and just like a SIEM, most are only designed to send alerts or notifications when something triggers.  I don't know about you, but I always thought the R stood for Response.  What sort of response are you getting from your EDR/MDR/XDR solution that's different from what you can get from your SIEM?  Granted, XDR should have integration with other solutions, but are they actually stopping and preventing anything?  Or again...creating more alerts?

Active monitoring should be done by real people with some AI and ML assistance.  These analysts should actually respond according to an agreed upon set of responses (i.e. a playbook).  An EDR/MDR or whatever DR solution should not be a glorified SIEM that only runs events  through an AI filter and spits out alerts.  Some of these service providers even state their service only offers "professional security advice and recommendations".  So it's still the customer's responsibility to act, react, make the changes, and hopefully avoid whatever incident is underway before it impacts their entire organization. 

I've said it before - When minutes count, your response shouldn't be hours away!  Any service with "Response" in the name shouldn't be just an automated alert.  That is not a response!  Take the time after reading this blog to find out what sort of response you are actually getting from your solution or service.  If you have an EDR or MDR solution or service and it's just another alert mechanism which relies on you or your team to respond to, contact me.  If you aren't sure, or they say they do offer a response and you want to test it...contact me.  We can simulate an attack an test their responses.  Not only is it an eye opening experience, it's actually kind of fun.

The last couple of years have provided some great examples for SIEM, MDR and EDR failures.  Just think about Colonial Pipeline, JBS Foods, Ireland Healthcare, KIA Motors, and Solarwinds.  What do they all have in common?  They all either used SIEMs and or had some sort of MDR/EDR service.  A couple (believe it or not) had both.  So why were they successfully attacked, breached, and ransomed?  Because they went with a service or solution that was only designed to notify them when something was wrong...not one that took real actions to protect and defend their systems.

I'm going to say it again, SIEMs are great and have their place in the security ecosystem.  Especially when it comes to determining the RCA for and event.  But they are not an MDR solution, and any EDR/MDR/XDR solution which is only as good as a SIEM...well, we've all seen how well that works.