Threats are constant. Organizations are trying to always stay ahead of new methods of attack, APT groups, and other known vulnerabilities. A key component of any Security Operations Center (SOC) is a well-functioning Security Information and Event Management (SIEM) Solution. However, the SIEM is only as good as its rules! Many times rules are broken, leaving you vulnerable to outside threats.
Why should you care about the health of your rules?
Why should you care about rules in the first place? Well, because most of them are probably completely ineffective in achieving their goal of detecting threats. In fact, we conducted an analysis of security analytics platforms, and found that only 16% of the techniques are addressed by rules because they are either due to broken rules, or the health of the rules. . The other 84% of the uncovered techniques are completely under the radar for your SIEM - giving a false sense of security.! Let me say that again - you most likely have a very false sense of security!!!
Why are there so many broken rules?
Our research further shows that most of the broken rules were created and implemented by someone outside of the organization. The usual sources of rules are:
- SIEM built-in rules
- SIEM content packs
- Integrators, professional services, and MSSPs
We have discovered that some service providers dump their entire content library on all their customers creating imperonalized rules which are noisy at best since they were enabled pre-tuning, or they're broken!
Start analyzing these rules before moving on to your custom ones.
Don't be shy - make sure to inform your service provider on any broken rules you find since they should be held accountable for the content they provide.
Start with the Source
Rules will always rely on a log source, and we discovered that the number one reason for broken rules is a malfunctioned log source. Check that the log source exists, enabled, and sends logs regularly to the SIEM. We have seen too many stale or disabled log sources causing rules to break and never trigger.
There is still more though! Security Engineering is doing something really important for your organization, and unfortunately, it isn't easy. You need to think of what the rule is searching for in the payload. Look for the following:
- Parsing issues - the fields which are being searched for are not parsed and (depends on the SIEM) might require field extraction.
- Incompatible field values - operators must operate on the same field types otherwise they will most likely never be true.
- Query helps health - rules often rely on entities such as QRadar reference sets, Splunk look-ups, etc. These entities can be empty or missing.
While these will probably find you 80% of your broken rules, there is more SIEM specific analysis which will find you the rest. A great topic for another blog!
I'm done! What now?
Scanning and fixing rules is not a one-time thing. New rules, as they should, will keep finding their way into your SIEM. New rules are added and need to be constantly checked and old rules can break due to environmental changes.
This of course, depends on how dynamic your environment is but a good best practice will be to repeat this process on a quarterly basis. This will ensure you are addressing threats and optimizing your threat coverage.
Pay attention and try to categorize rules which got broken over time. If these are usually new rules - consider implementing controls pre-deployment. If these are old rules, consider adding controls when changes are made in your SIEM.
Finally, we know this process takes time, effort, and skills. However, it is imperative that you keep at it to maintain and improve your threat coverage.