EN, Windows Incident Response

The Problem with the Modern Security Stack

I read something interesting recently that stuck with me. Well, not “interesting”, really…it was a LinkedIn post on security sales. I usually don’t read or follow such things, but for some reason, I started reading through this one, and really engaging with the content. This piece said that “SOC analysts want fewer alerts”, and went on with further discussions of selling solutions for the “security stack”. I was drawn in by the reference to “security stack”, and it got me to thinking…what constitutes a “security stack”? What is that, exactly? 

Now, most folks are going to refer to various levels of tooling, but for every definition you hear, I want you to remember one thing…most of these “security stacks” stand on an extremely weak foundation. What this means is that if you lay your “security stack” over default installations of OSs and applications, with no configuration modifications or “hardening”, and if you have no asset inventory, and you haven’t performed even the most high-level attack surface reduction, it’s all for naught. It’s difficult to filter out noise and false positives in detections when nothing has been done to configure the endpoints themselves to reduce noise.
One approach to a security stack is to install EDR and other security tooling on the endpoints (all of them, one would hope), and manage it yourself, via your own SOC. I know of one organization several years ago that had installed EDR on a subset of their systems, and enabled in learning mode. Unfortunately, it was a segment on which a threat actor was very active, and rather than being used to take action against the threat actor, the EDR learned that the threat actor’s activity was “normal”. 

I know of another organization that was hit by a threat actor, and during the after action review, they found that the threat actor had used “net user” (native tool/LOLBin) to create new user accounts within their environment. They installed EDR, and were not satisfied with the default detection rules, so they created one to detect the use of net.exe to create user accounts. They were able to do this because they knew that within their organization, they did not use this LOLBin to manage user accounts, and they also knew which app they used, which admins did this work, and from which workstations. As such, they were able to write a detection rule with 100% fidelity, knowing that any detection was going to

[…]
Content was cut in order to protect the source.Please visit the source for the rest of the article.

This article has been indexed from Windows Incident Response

Read the original article: