Top Use Cases for detecting
It is well known that in the field of cyber-security, large amounts of data is collected but not utilized. Most organizations have little to no clue of what is happening with their data.
For the data to be useful, appropriate Use Cases are needed to detect cyber incidents before it’s too late. SIEMs could further develop these Use Cases into specific rules.
Although the available tools in the market are “smart enough” to detect incidents, we still require a set of use cases for the data that is being ingested.
The following are some of the use cases
1) User/Admin credentials compromise
Monitoring should be in place to track both user and administrator credentials. A workflow will enable detecting any password compromise attack such as Brute Force, Rainbow table, pass the hash, MITM, etc. When an incident occurs, there is better insight into how to proceed and prevent further damage.
2) Unexpected Amount of EPS (Events per second)
Whenever data is forwarded to a SIEM, a baseline is established. The baseline is determined by the type and amount of data ingested and the source from which it is obtained.
An increase in the EPS resulting from malicious actors tampering with the data being forwarded to a logging platform can negatively impact the search capability of a SIEM in detecting an abnormal event.
A Use case is necessary that monitors the EPS spikes and alerts the user when the threshold value is reached.
3) Critical service stopped
This is one of the most important indicators of a Cyber Attack. Attackers usually attempt to disable or manipulate some critical services such as Windows Defender, Endpoint protection, svchost, and winlogon. This is one of the most important indicators of a cyber attack.
It is crucial to monitor the uptime of critical services using a reference set or custom list. Analysts can keep a close eye on these significant services and look for unusual behavior that may signal a threat or a compromise.
4) Log source not responding or down
There could be multiple reasons for a log source or a collector to go down. An attack on an asset could be one of the reasons and this may cause a log source or collector to stop working. The SIEM should be set to send an alert as soon as it stops receiving logs or metrics from a specific collector. The CIRT should be able to address the issue as soon as possible after learning the IP and hostname of the machine from the alert.
5) Unusual amount of Admin/ Sudo failures
Generally, a threshold amount is already set to lock the user out for login failures. Additionally, this can be considered as a use case that can log the IP, time, and the source for admin or Sudo failures. This could be considered for both Windows and Linux-based OS.
6) Monitoring Outbound and Inbound connections.
The number of bytes sent and received should not exceed the threshold limit. Large number of outbound packets could be an indicator of a compromise of a BOTNET.
A botnet generally comes in through a backdoor and constantly keeps making a connection to the command and control server. These connections result in high bandwidth and large outbound packets.
7) Brute force and DOS attack on public-facing assets.
DOS (Denial of service) attacks generally come in from multiple IPs and in a very short span of time.
A brute force attack’s IOC can be the usage of random usernames. The use of random usernames can also correlate to a dictionary attack
Some other use cases that can be considered are:
- Login from a country which is not in allow list.
- Phishing email detected.
- Internal hosts connecting to Malicious known IPs / URLs.
- Multiple login failures on Domain controllers.
- Malware signature detected.
Contact us today and learn how we at M87 can secure your infrastructure!