The Power of Use Case
Many organizations are implementing various SIEM technology today in other to have visibility into the security of their network, business processes and IT infrastructure. Getting values from SIEM depend largely on how well the organization can play around Use Cases. SIEM is not a 100% plug-and-play system, it requires some management.
A SIEM will simply collect data from all the number of sources (security devices, network devices, endpoints such as workstation and servers) you can plug to it, do the correlation and logs arrives at the dashboard for the analysts to attend.
The number of alerts that on the SIEM depends on how fast the logs (events) arrives at the SIEM and how fast the SIEM is able to correlate them into events/incidence?
Without the right set of analysts, a better SIEM product with inbuilt capability for threat intelligence and proper definition of use cases, it becomes very difficult to get value out of your SIEM.
If organization is not paying as much attention to how well they can get values from the alerts that arrive at the analyst dashboard, then the SIEM will be rendered to a log management system, as the security analytic (SECOPS) of the SIEM will be rendered ineffective due to overloaded alerts on the analyst (alerts fatigue).
An organization implementing a SIEM should first agree on the scope of implementation which will serve as a direction to what they want to achieve. Scope of implementation comes in three folds. The first implementation target security; the second one target operation and the third one target compliance. We have cases where combinations of these scopes are being implemented depending on the choice of the organization.
Having to know the scope of implementation is one thing, but defining use cases for each of the scopes determines how much value an organization get out of the implementation.
Defining the SIEM relevant to the current threat landscape in the organization’s industry is one big task that defines what you get out of your SIEM (How can we translate the threat landscape to nuts and bolts for SIEM purposes?). Your SIEM product might have documentation for installation, update and upgrade, but it cannot come with Use cases off the box.
It is important to sit with the organizations’ security team to define use cases that are in line with their internal policy, industry’s regulations and compliance objectives before proceeding to implementing a SIEM. With well-defined use cases; implementing, responding to and managing them would become easier and they can eventually become the cornerstone on which a SOC is built for such an organization.
Component of Use Case
Now that we understand how important a use case is to a SIEM and how it can help improve the productivity of analysts in SOC, we can now move forward into defining a use case to see its components and the steps involved in creating one. Components such as requirement, scope, event sources, validation, logic definition, implementation and testing, and response make up a working use case.
The first component of a use case is the requirement, this is something very unique to every organization and it could be for business operation, compliance and regulatory, security.
Once the requirements are finalized, the next move is to define the scope of those identified requirements depending on the organization, which is simply a list of all the asset that needs to be protected and their priority to the organization.
We cannot proceed without getting to know the sources of event that will be a driver for the use case, this would be log and configuration data coming out of the assets under the requirement scope.
We cannot but validate all of the event sources requires to trigger an alert for the use case, by ensuring the right events from the required sources arrived at the SIEM, get parsed and normalized to trigger alerts as it will be defined by the use case logic.
The logic definition is the component that defines exactly what and how much data is needed to trigger an alert along with the attack vector we would like to detect, and the contextual information of the assets that will be involved in such events.
After we have defined the logic for the use case, we move into implementation and testing to ensure it is working as expected, if not we fine-tune it to match our objectives/requirements. The SIEM is set to do what it does the best, correlation and alerting as per defined logic. This is where desired output such as notification, reporting, escalation can be defined.
Once we are done with implementation and testing, and we are cool with our outputs/results. The need to make the use case operational will arise, which is what to do when a use case got triggered to the dashboard. What is expected of the analysts to be done comes under response ranging from actions such as incident recording, alert triaging, and escalation to the IR Team for further responses?
What Does a Use Case look in Real-time?
Let us have a look at one using the example below. Let us define a use case for horizontal privilege escalation detection in a network.
- Horizontal Privilege Escalation Detection. (Security)
- End-User Machines,
- Domain Users, Group Accounts,
- Privilege Accounts,
The Event Sources:
- Events from Domain Controllers – Security Events from DCs (WEF)
- Powershell Monitoring (Sysmon) – Events from malicious PowerShell commands
- Registry Monitoring – Events from the registry to monitor DLL preloading
- IDS/IPS at Network and Host – Signature-Based Detection
- Events from Network Devices and EDR.
The Event Validation:
- All devices logging to SIEM should be normalized and parsed properly so as to enable proper Event Triggering and Alerting on the dashboard for the Analyst
- The required fields for the above Use Case would typically be Machine Hostname, Account Information, Target IP, Host Information of Source and Target, Event Names and Codes.
- A machine generating any of Event ID 4720, 4722, 4740, 4725, 4726, 4738, 4781 at the rate of 5 in 10 minutes.
- A machine generating any of Event ID 4656, 4657, 4660, 4663 at the rate of 5 in 10 minutes.
- Any machine generating Event ID 4703
- Unnecessary network & port scan emanating from a known host in the network.
Implementation and Testing:
- After Implementation of the Use Case, we would need several iterations of Incident Analysis along with data collection to ensure that the Use Case is doing what it is intended to do. This is done at the SIEM level and may involve aggregation, threshold adjustments, logic tightening.
Use Case Response:
- Disallow loading of remote DLLs
- Notify the IT operation to disable affected accounts on identified hosts.
- Check out for misuse of legitimate privileges granted to the other users.
- Enable Safe DLL Search Mode to force search for system DLLs in directories with greater restrictions
- Use auditing tools such as PowerSploit to detect DLL search order hijacking vulnerabilities and correct them
- Review IT systems and ensure UAC protection is set to the highest level, or if this is not possible, apply other security measures. Regularly review which accounts are a local administrator group on sensitive systems and remove regular users who should not have administrative rights.
- The best practice is to assign administrative rights in line with the least-privilege principle, regularly review administrative accounts and revoke them if access is no longer needed.
It is worthy of note that constant fine-tuning and management of use cases is required for an organization to continue to get value from it SIEM, and it is advisable to always retire use cases that are no longer relevant to the organization to help sieve down false positive for the analysts and increased productivity. So the need for SIEM Use Case Roadmap for continuous management.