Security teams across the nation are stuck. Security Analysts are overwhelmed with noise, forcing organizations into a never-ending feedback loop to groom and tune their existing security content and retrain their analysts. Unfortunately, evolving threats and new security controls only result in additional alerts, further perpetuating the cycle.
In this post, we will explore the top reasons why security teams are feeling left behind by addressing the root of the problem—static rule based systems.
What are static rules and static rule-based systems?
- Static rules implement detection logic looking for a specific, predetermined outcome or set of characteristics
- A static rule or query based system pertains to all systems deploying logic that does not evolve on its own, requiring human input to both maintain the logic and customize the implementation for the organization over time
Here are the top 3 reasons why static rule-based systems can't keep up:
1. Static rules are burdensome to manage
There is a lifecycle for every rule—they need to be defined, contextualized within the environment, understood by the security analyst team, and constantly tuned. Maintenance is an iterative process, including cross-team daily meetings, repeated training and enablement, and in many cases, expensive consultants. Rule tuning often happens due to false positives from unforeseen circumstances or from changes in attack patterns or vendor signatures. Context is a huge challenge to keep updated (and the topic of one of our future blog posts).
Furthermore, analysts often forget what is in the rules or how they are triggered. So, rules are often silenced or ignored for lack of analyst understanding instead of lack of security effectiveness. In total, management of static rules presents an operational overhead that is not insignificant. Is this what you would like to be spending your money and time on?
2. Security Analysts and Security Engineers are set up for conflict
Analysts are on the receiving end of rules and queries created by security engineers and would prefer to see the alert volume decrease and detection accuracy increase. In many situations, analysts get behind on alert volumes and blame engineers for writing sloppy rules and not having to live with their noisy output.
In contrast, security engineers are incentivized to increase monitoring coverage, not fall behind on the security content roadmap, and keep pace with the ever-expanding attacker tactics and techniques. Analysts often feel they are not being heard or have control of the process. Also, they feel that engineering cannot effectively keep up with requests.
3. Attackers are increasingly 'Living Off the Land'
Attackers who gain a foothold within an enterprise do everything within their power to not be noticed. They leverage existing tools and credentials present in the enterprise and hide their tracks within what appears to be normal administrative or even user activity. Writing rules against legitimate behavior is not a realistic option, since this is incredibly prone to false positives.
Given the above issues, the solution we’ve been waiting for is not necessarily behavioral analytics. While behavioral analytic approaches offer advances in content offerings as compared to legacy SIEM correlation rules, they suffer the same burdensome lifecycles of static rules. Behavioral rules or queries need to be generated to match behaviors, in addition to requiring security engineers learning another platform to apply their intelligence within.
And beforehand, teams must decide the set of behaviors to look for and ask these questions. What do these behaviors mean? What do these behaviors mean specifically within my organization? Overall, organizations still face challenges of integrating, maintaining, and interpreting context.
We’d love to hear what your own experience is here and invite you to play a part in this dialog and welcome your comments.
Tim Wenzlau, Product Manager, Respond Software
Stay up to date with our latest posts by subscribing to our RSS feed: https://respond-software.com/blogs/blogs.atom