SIEM Use Case Examples
- 1.Critical Host Targeting Known Bad Actor
- 2.DMZ Host Targeting Known Bad Actor
- 3.Enterprise Outbound to Known Bad Actor after Known Bad Actor Inbound to Enterprise4.Enterprise Outbound to Multiple Known Bad Actor
- 5.Internal Host Accessing Known Botnet Domain
- 6.Internal Host Accessing Known Botnet URL
- 7.Internal Host Accessing Known Malware Domain
- 8.Internal Host Accessing Known Malware URL
- 9.Internal Host Accessing Known Phishing Domain
- 10.Internal Host Accessing Known Phishing URL11.Internal Host Targeting Known Bad Actor
- 12.Known Bad Actor Targeting DMZ Host
- 13.Known Bad Actor Targeting Internal Host
- 14.Known Bad Actor (Known Bad Actor) Targeting Critical Host
- 15.Known Phishing Email Detected
- 16.Multiple Internal Hosts Contacting Known Botnet Site
- 17.Multiple Internal Hosts Contacting Known Malware Site
- 18.Multiple Internal Hosts Contacting Known Phishing Site
- 19.Multiple Known Bad Actor Inbound to Enterprise
|Use Case||Description||Status in 2018|
|1 – old||Authentication tracking and account compromise detection; admin and user tracking||Very much alive, also became a popular UEBA use case|
|2 – old||Compromised- and infected-system tracking; malware detection by using outbound firewall logs, proxy, etc||Very much alive, more relevant than before, also an UEBA use case|
|3 – old||Validating intrusion detection system/intrusion prevention system(IDS/IPS) alerts by using vulnerability data, etc||Less relevant today, not common anymore – perhaps a candidate for removal from popular list?|
|4 – old||Monitoring for suspicious outbound connectivity and data transfers by using firewall logs, Web proxy logs, etc||Very much alive, also a popular UEBA use case (related to exfiltration detection)|
|5 – old||Tracking system changes and other administrative actions across internal systems, etc||Very much alive, AD log analysis became more popular, UEBA expands this to insider threats, etc|
|6 – old||Tracking of Web application attacks and their consequences, etc||I’d say alive today, but not that common, not sure why|
|7 – NEW||Cloud activity monitoring, detecting cloud account compromise, cloud access and privilege abuse, other security issues, etc||NEW! Also a use case for UEBA and (in case of SaaS, mostly) CASB, this covers many sub-use cases for AWS, Azure, Office 365, etc threat detection|
|8 – NEW||Detecting threats by matching various logs to threat intelligence feeds||NEW! A popular use case, pushed up by wide availability of low-priced TI feeds of … ahem… tolerable quality|
|9 – NEW||SIEM as “poor man’s EDR” – review of sysmon and similar endpoint data||NEW! As EDR and EPP converge, SIEM can occasionally help with deeper endpoint visibility by utilizing various source of endpoint telemetry; probably not a good STARTER use case though…|
|Use-case Selection||Selected use case is tracking authentication information across systems [what] to detect unauthorized access. [why]|
|Data Collection Needed||Prepare a list of systems such as servers, VPN concentrators, network devices, and others.|
|Log Source Configuration Needed||Contact the team that operates the systems and make them modify the logging configurations in order for the logs to be collected by SIEM.|
|SIEM Content Creation, Preparation and Selection||Review vendor’s content — such as their authentication reports and relevant correlation rules or other “canned” analytics — that deals with the problem and check it for suitability; modify the reports and rules until satisfied.|
|Definition of Operational Processes Required||Review operational processes related to the security use case and check whether additional processes are needed. A process for suspending or disabling user accounts might have to be created.|
|Refinement of the Content and Processes Loop||After reports and correlation rules are deployed and the data is flowing in, review reports, dashboards, and perform the testing of correlation rules on the collected data to see whether incidents will be detected. Simulate password guessing and check whether SIEM detected and sent an alert.|
- Authentication tracking and account compromise detection; admin and user tracking [this is the very use case that I detail in that post]
- Compromised- and infected-system tracking; malware detection by using outbound firewall logs, NIPS alerts and Web proxy logs, as well as internal connectivity logs, network flows, etc
- Validating intrusion detection system/intrusion prevention system (IDS/IPS) alerts by using vulnerability data and other context data about the assets collected in the SIEM[while some say “this is so 2002”, this use case is still here in its modern form of using SIEM for “context-enabling” various alerts]
- Monitoring for suspicious outbound connectivity and data transfers by using firewall logs, Web proxy logs and network flows; detecting exfiltration and other suspicious external connectivity
- Tracking system changes and other administrative actions across internal systems and matching them to allowed policy; detecting violations of various internal policies, etc [and, yes, even the classic “root access from an unknown IP in a foreign country at 3AM, leading to system changes” sits here as well]
- Tracking of Web application attacks and their consequences by using Web server, WAF and application server logs; detecting attempts to compromise and abuse web applications by combining logs from different components.
- Compromised account detection: this is a “classic UBA” usage – study account authentication and usage information to conclude that the account is being used by a malicious party [or, at least, by a different party]; this is often powered by some logic to relate multiple accounts to the same person and/or logic to build sessions of user activity.
- Compromised system/host/device detection: by detecting things like attacker lateral movement, C&C activity, access to bad domains [unknown ones, not just via TI!], various telling host and network anomalies, etc reach a conclusion that a system is under malicious control; this use case covers many data sources and a lot of fairly dissimilar methods of “sense-making”
- Data exfiltration detection: notably, DLP has not fully solved this one (ha!), but has since become a popular UEBA data source; data theft (“exfil”, if you want to sound cool!) detection by trusted insiders and outsiders (as well as their malware) presents a common UEBA tool use case.
- Insider access abuse: this is a fuzziest on the list, this focuses on detecting malicious and risky behavior by legitimate trusted insiders, and includes all forms of privileged access abuse and misuse, among other things; typically powered by user profiling, outlier detection and risk scoring of the results
- Gaining additional insight about the environment: a broad use case where UEBA tools are used for gaining better situational awareness; this also includes improved alerts prioritization and support for triage and investigation activities (yes, if you have to ask, hunting too)
- Custom use case: a good UEBA tool should be able to address a weird client-specific user behavior analytics scenario, ideally without coding and [much] data science knowledge on behalf of a client.
- Define a particular problem to be solved by a SIEM tool in clear, unambiguous terms.
- Review the SIEM functionality (rules, algorithms, reports and dashboards) that is needed to solve the problem.
- Look at the available and potentially available log data that is useful for solving the problem.
- If a correlation rule is the chosen piece of content to be created, analyze what sequence of logged events needs to be tracked and how these events are represented in a SIEM tool; using normalized events and taxonomy categories is highly recommended because they make the rule easier to modify, maintain and apply to additional log sources.
- If using a statistical detection method, review its logic to confirm that it will deliver the result needed.
- Draft correlation rules on paper, and review the logic flow.
- Implement the correlation rule using the SIEM rule interface; some products allow one to click on events and define a rule straight from the observed sequence of events.
- If a product has functionality to test the rule or algorithm on historical data, execute this functionality to determine how often this rule would have fired in the past if it had been enabled.
- Review any alerting process that this rule will trigger, and set up alerts to go to the people who know how to triage them.
- Enable the rule to run on real-time data flow in the production environment.
- Review alerts generated by this rule, review the cases where the rule matches partially (if the SIEM product has such functionality) and refine when the rule is needed.
|Top SIEM Use Case||UEBA Utility for This|
|1||Authentication tracking and account compromise detection||Top UEBA use case; UEBA shines here; this is hard to do well with SIEM|
|2||Compromised- and infected-system tracking; malware detection by using outbound logs, etc||A common UEBA use case; done either via entity profiing or by detecting systems where compromised accounts dwell|
|3||Validating intrusion detection system/intrusion prevention system (IDS/IPS) alerts||UEBA is used for alert validation and triage, but not exactly like SIEM; in fact, UEBA has been used for SIEM alert validation|
|4||Monitoring for suspicious outbound connectivity and data transfers by using logs, etc||Exfiltration detection is a common UEBA use case; done via account activity profiling or via DLP alert analysis|
|5||Tracking system changes and other administrative actions across internal systems, etc||An infrequent UEBA use case, maybe for finding that one worrisome change or access|
|6||Tracking of Web application attacks and their consequences by using Web logs, etc||Not a match to common UEBA use cases|