SIEM Use Case Examples

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
siem-use-case-implementation-mindmap.jpg
338758_0001.png
Use CaseDescriptionStatus in 2018
1 – oldAuthentication tracking and account compromise detection; admin and user trackingVery much alive, also became a popular UEBA use case
2 – oldCompromised- and infected-system tracking; malware detection by using outbound firewall logs, proxy, etcVery much alive, more relevant than before, also an UEBA use case
3 – oldValidating intrusion detection system/intrusion prevention system(IDS/IPS) alerts by using vulnerability data, etcLess relevant today, not common anymore – perhaps a candidate for removal from popular list?
4 – oldMonitoring for suspicious outbound connectivity and data transfers by using firewall logs, Web proxy logs, etcVery much alive, also a popular UEBA use case (related to exfiltration detection)
5 – oldTracking system changes and other administrative actions across internal systems, etcVery much alive, AD log analysis became more popular, UEBA expands this to insider threats, etc
6 – oldTracking of Web application attacks and their consequences, etcI’d say alive today, but not that common, not sure why
7 – NEWCloud activity monitoring, detecting cloud account compromise, cloud access and privilege abuse, other security issues, etcNEW! 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 – NEWDetecting threats by matching various logs to threat intelligence feedsNEW! A popular use case, pushed up by wide availability of low-priced TI feeds of … ahem… tolerable quality
9 – NEWSIEM as “poor man’s EDR” – review of sysmon and similar endpoint dataNEW! 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…
StepDetails
Use-case SelectionSelected use case is tracking authentication information across systems [what] to detect unauthorized access. [why]
Data Collection NeededPrepare a list of systems such as servers, VPN concentrators, network devices, and others.
Log Source Configuration NeededContact 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 SelectionReview 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 RequiredReview 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 LoopAfter 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.
  1. Authentication tracking and account compromise detection; admin and user tracking [this is the very use case that I detail in that post]
  2. 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
  3. 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]
  4. 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
  5. 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]
  6. 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.
  1. 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.
  2. 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”
  3. 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.
  4. 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
  5. 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)
  6. 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.
  7. Define a particular problem to be solved by a SIEM tool in clear, unambiguous terms.
  8. Review the SIEM functionality (rules, algorithms, reports and dashboards) that is needed to solve the problem.
  9. Look at the available and potentially available log data that is useful for solving the problem.
  10. 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.
  11. If using a statistical detection method, review its logic to confirm that it will deliver the result needed.
  12. Draft correlation rules on paper, and review the logic flow.
  13. 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.
  14. 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.
  15. Review any alerting process that this rule will trigger, and set up alerts to go to the people who know how to triage them.
  16. Enable the rule to run on real-time data flow in the production environment.
  17. 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.

chuvakin_RSA_2010_SEIMBC_WP_0810effective-case-modeling-security-information-event-management-33319

Top SIEM Use CaseUEBA Utility for This
1Authentication tracking and account compromise detectionTop UEBA use case; UEBA shines here; this is hard to do well with SIEM
2Compromised- and infected-system tracking; malware detection by using outbound logs, etcA common UEBA use case; done either via entity profiing or by detecting systems where compromised accounts dwell
3Validating intrusion detection system/intrusion prevention system (IDS/IPS) alertsUEBA is used for alert validation and triage, but not exactly like SIEM; in fact, UEBA has been used for SIEM alert validation
4Monitoring for suspicious outbound connectivity and data transfers by using logs, etcExfiltration detection is a common UEBA use case; done via account activity profiling or via DLP alert analysis
5Tracking system changes and other administrative actions across internal systems, etcAn infrequent UEBA use case, maybe for finding that one worrisome change or access
6Tracking of Web application attacks and their consequences by using Web logs, etcNot a match to common UEBA use cases

ELK provide free Use cases for Security

Splunk Use Cases

  • Brute force access detected
  • Brute Force Access Detected over One Day
  • Expected Host Not Reporting
  • High Number of Hosts Not Updating
  • Malware Signatures
  • High Number of Infected Hosts
  • High/Critical Priority Host w/Malware
  • Detected
  • High/Critical Priority Individual Logging into Infected Machine
  • High Volume Traffic from High/Critical
  • Host Observed
  • Host Sending Excessive Email
  • Host with Recurring Malware Infection
  • Host with Multiple Infections
  • Host with Old Infection or Potential Re-Infection
  • Outbreak Detected
  • Potential Gap in Data
  • Threat Activity Detected
  • Vulnerability Scanner Detected (by events)
  • Vulnerability Scanner Detected (by targets)
  • Brute force access detected
  • Brute Force Access Detected over One
  • Day
  • High Volume Traffic from High/Critical Host
  • Observed
  • Host with Recurring Malware Infection
  • Host with Multiple Infections
  • Host with Old Infection or Potential Re-
  • Infection
  • Threat Activity Detected
  • Activity from expired user identity

     

Detecting Lateral movements in Event logs

Detect and Prevent Web Shell Malware

SOC Prime SIGMA Rules;

ELK Detection Rules

https://www.cyber.gov.au/publications/windows-event-logging-and-forwarding

Corelight Use Cases

https://corelight.com/cases/use-cases

https://www.sans.org/cyber-security-summit/archives/file/summit-archive-1569878751.pdf

Leave a comment