SIEM – USE CASE WRITING GUIDE
After writing my last blog post – https://blueteamblog.com/tips-to-improve-your-siem, I had a lot of requests to write a blog post just on writing use cases; so here we are. This article will take aspects from the previous post and expand upon them, to give you an in depth view of SIEM use case writing and best practices.
It is also worth mentioning the differences between use cases and use case logic / detections / rules etc. Use cases are the overall use case which contains the use case logic, SOC Actions, problem statement etc. Whereas the use case logic itself is just the detection used to detect threats / policy violations etc.
Sections of the article as follows:
- Getting Started
- Understanding Logs
- Thinking of use case ideas
- Writing use cases
- Testing your use cases
- Tuning your use cases
- What next?
The most common thing I get asked is “where do I get started”. Writing rules can be intimidating and confusing, however if you break down the steps it can be made a lot easier.
First off, you want to think of what your most important log sources within your environment are and create detection rules for these. You can think of this in a few ways – which log sources give the most important information and / or which log sources contain critical data which needs to be monitored.
For the first point, we can use the below graph (full article here) which shows us the number of MITRE Sub-Techniques per data source.
From this, we can see that a lot of value can be gathered from collecting Sysmon logs (See this Sysmon cheat sheet if you need help) as process monitoring and process command-line parameters alone have 384 sub techniques. Contrary to this, we can see Digital certificate logs only have 1 current sub technique, and thus provide a lower number of related possible detection’s.
A log sources value cannot just be decided solely by the number of possible detections it can provide, however. You also need to consider log sources, such as databases; which may contain extremely sensitive data and thus require monitoring but at the same time will not have an overall large number of detections.
Overall, it is best to split log sources into two groups.
1. Which log sources provide a large number of detection opportunities.
2. Which log sources are required for monitoring sensitive data.
From there, you can then decide which log sources are most important to you and start developing your SIEM from there. To get you started, here are some very commonly used log types within SIEM deployments. One thing to be very mindful of is event limits or log source limits on SIEM deployments. So be careful to check the event and / or log source limitations on your SIEM platform before deciding which log sources to onboard.
- Active Directory (Authentication Logs)
- Office 365
- IDS / IPS
- Vulnerability Management
Once you have chosen which log sources you will like to onboard, the next step is to understand the logs from these log sources. Here are a list of helpful resources to read commonly used log formats:
Windows Security Event Logs – search Event ID here – https://ultimatewindowssecurity.com/securitylog/encyclopedia/default.aspx…
DNS Logs – https://nxlog.co/whitepapers/dns-logging…
But what about custom log sources?
The only case where there may not be any easy to find documentation around the log source is if you are creating custom log sources for custom applications within your environment. In this case, I would recommend talking to the responsible team / experts for the source and creating a knowledge document for the log source. This should contain what each log file entry means, escalation matrix’ for issues with the log source and the expected detections for the log source (Security or Infrastructure Monitoring based).
Once we have a on boarded log sources and have a good understanding of the logs; we now want to move onto thinking of ideas for use cases.
THINKING OF USE CASE IDEAS
After you have logs in your SIEM and understand what they mean, you then need to start thinking of ideas for use cases. There is a number of ways we can do this.
- The simplest and easiest way is to copy existing use cases from free online repositories. Here are some good ones which cover most log source types:
- https://my.socprime.com/tdm/ (partially free)
2. I also have a large number of use cases on this site, which can be found here – https://blueteamblog.com/category/siem
3. Creating use cases based on threat hunts. If your company has a threat hunting functionality, findings from this should be used to create new use cases for your SIEM.
4. Creating use cases based on public references. You should always look out for reports / information on recent attacks and use these for use case ideas. As an example, https://thedfirreport.com/. Reports from this site and similar will either show you rules which you can implement, or will at least give you ideas.
5. Custom rules. If you have any custom log sources due to custom applications, then you should have meetings with the responsible team and decide between the security team and the application / resource owner for ideas to which use cases should be implemented, either to cover security issues or for infrastructure monitoring.
Once you have some ideas, you then want to move onto writing your use cases.
WRITING USE CASES
Now we are at the stage of actually writing the use case. For this, I recommend following a template as follows.
- Name of the use case. (I recommend mapping them to the MITRE killchain. and including the tactic in the name, for example EXEC for execution or LM for lateral movement.)
- Purpose – Why is the use case being created?
- Problem Statement – What business problem is the use case solving?
- Requirement Statement – What is required to make the use case work?
- Design Specifications – More in depth specification of exactly what needs to be done (Auditing / Logging / Use case design) Who is going to take these actions to makes this a reality?.
- SOC Actions (Playbook) – Which actions are required by the SOC if your use case triggers? How should it be investigated and which information needs reported? Clearly define which team/s the alert should be escalated to and the expected remediation steps.
- Use case logic – Document clearly the exact logic being used for the use case and all variables (References, Log Sources, Asset Data etc)
- Limitations – Are there any known limitations to the use case? Can attackers bypass our detection using other methods? Is the log source we are receiving events from stable?
- Alternative Solutions – Is there any alternative options to creating the use case (Reporting, mitigation’s etc)
- Change notes. If any changes are made to the use case, note them here along with who change the case, why and a date.
- Approvals. It is always worth while having your work double or even triple checked. Before a use case goes into live, get a colleague or two to check your logic and playbooks before signing it off.
To help you, here is a very high level completed example for a basic use case.
- Name of the use case – 001-PE- User Added to Local Administrators (001 is the use case number (first use case in the repo), PE is Privilege Escalation in the MITRE Attack matrix which the use case maps too and User Added to Local Administrators is the use case name.)
- Purpose – The purpose of this document is to show how we will monitor for user accounts being added to Local Administrator Groups. This will be done through monitoring Domain Controller logs in the SIEM and alerting the SOC if any user is added to these groups.
- Problem Statement – Elevated access in Windows Domains is controlled by memberships within Active Directory and local groups. These groups grant privileges to users, and therefore users should only be added to them for legitimate purposes within change control. However, it is a well known attack behaviour for threat actors to add user accounts to local administrator groups to escalate privileges. Therefore, we need to monitor all changes and ensure any users being added to local administrator groups are being done within change control and are legitimate.
- Requirement Statement – Ensure all Domain Controllers are logging correctly to the SIEM platform. Ensure all Domain Controllers are providing logs for users being added to local groups (EventID 4732). Ensure these logs are being parsed correctly in the SIEM and clearly shows who made the change, which account was being added and at what time. Ensure all successful additions are checked by the Security Operations Team to validate that they are legitimate.
- Design Specifications – Configure Domain Controllers to send data to SIEM using syslog feed. Ensure EventID 4732 is being audited and sent to the SIEM via GPO audit policy implementation. Ensure playbook is created and Security Operations Team have clear escalation path for all group modifications.
- SOC Actions (Playbook) – When alert triggers, SOC Analyst shall check the account which is being added (Under member section in the log) and account which is adding (Under subject section in the log). It should also be noted the time which the action occurred and which group the user is being added too. The analyst should check to see if there is currently any incidents or change requests open for this user to be added to this group. If yes, this incident can be closed as Benign. If not, a Security Incident will have to be raised for further investigation to take place for the incident. If the action happens out of hours or if there are any other suspicious factors, the group membership should be revoked and both accounts involved disabled until a clear picture of what has happened can be established.
- Use case logic – Please see example use case logic here – https://github.com/Neo23x0/sigma/blob/master/rules/windows/builtin/win_user_added_to_local_administrators.yml. (This is an example of an existing, free Sigma use case logic which you can just use. If you do create your own logic, I highly recommend creating it in the Sigma format, as I discuss further below.)
- Limitations – Limitations to this use case are that threat actors may be able to raise privileges and perform malicious actions before the SOC can react.
- Alternative Solutions – The Active Directory should be hardened as best as possible to make it difficult for threat actors to gain a level of access to add accounts to groups. (I wrote an article about this a while ago – https://blueteamblog.com/active-directory-security-hardening-auditing-and-detection-rules). Also, only a small number of authorised users should have permissions to add or remove users from groups.
- Change notes. -No changes currently being made to use case. (This section is to be used if you are editing the use case once it is created)
- Approvals. – Approved by John and Doe. (This section should have approvals from at least two other members within the IT department and SOC to validate it is fit for purpose and meets requirements)
For the use case logic section, I really recommend learning Sigma. Sigma is an open standard for rules that allow you to describe searches on log data in generic form. These rules can be converted and applied to many log management or SIEM systems and can even be used with grep on the command line.
Here is a guide for learning how to write Sigma rules – https://www.nextron-systems.com/2018/02/10/write-sigma-rules/
The reason I recommend this is the fact that any rules written in Sigma format can be converted to various other systems using uncoder.io. This is very helpful if you either work at an MSP or have multiple systems which require detection use cases.
TESTING YOUR USE CASES
Once you have created a use case, you will then need to test it. There are two parts to this – testing your use case logic, and testing your SOC Actions.
Firstly, looking at the use case logic. The best way to test this is using a test SIEM environment. You can learn how to set up a test SIEM environment using this article I wrote here. Once it is set up, you can then ingest sample data which analysts can test use case logic with, such as https://vizsec.org/data/ and https://github.com/redcanaryco/atomic-red-team.
Ingest the correct data for your use case and ensure that it triggers correctly if the applicable events are fed into the SIEM. If it doesn’t trigger or has false positives, continue to tune the use case (see next section) using the test platform until it is suitable to go live.
The other thing you need to test is your SOC Actions. Raise an example incident based on the use case and ensure that the whole process goes smoothly. Did the analyst raise the incident correctly? Was it escalated to the correct team? Dd the team respond correctly to the incident?. Ensure that all steps of the test incident go smoothly and edit your SOC Actions as applicable to ensure they are accurate and fit for purpose.
TUNING YOUR USE CASES
Over time, issues will be found with use cases in the SIEM. This could either be a false positive, an expected behaviour that needs tuned out; or the detection missed something. Anyways, a properly defined process needs to exist so that analysts actually have a way to report these issues; or so that your Senior / Engineering teams can discover the issues themselves.
There are three ways I have found to tackle the issue of tuning use cases, I like combining them all. Firstly, you can set up an email template which your monitoring analysts can use to report anything they find to Senior or Engineering teams. This does not need to be anything complicated. Just the name of the use case, the time it triggered and a description of why they think it needs improved; along with recommendations of how to do so, if they think they know exactly what needs fixed. The Senior / Engineering team can then look into the report, perform the fix if required and give feedback to the analyst.
Along with this, I personally run a weekly report automatically which sends me every time an alert has been marked as false positive, along with closure notes. Any time this is used, an analyst should be raising why they believe it is a false positive to Senior / Engineering. If they have, great; we will already know about it and it will either have been, or be getting; dealt with. However, I will also come across cases where this has been used without report being raised. In this case, I instead investigate the alert myself and then discuss with the analyst responsible.
Finally, run a monthly report to review all alerts which have caused false positive triggers throughout the month. Is there a certain alert or type of alert causing this? Dig into why they are happening and fix them! Following these steps will improve the quality of your use cases and lower the amount of false positives you see.
Following the above steps will ensure that you have a well functioning use case function within your SOC or Security Operations Team. This will allow you to onboard the correct log sources, understand the data they provide, implement the correct use cases for these logs and ensure these are of a high quality.
If you require any help with any of the above points, contact me at https://twitter.com/blueteamblog and I will do my best to help.