Introduction to SIEM
Last updated
Last updated
A Security Information and Event Management system (SIEM) is a tool that collects data from various endpoints/network devices across the network, stores them at a centralized place to perform correlation.
The above image demonstrates a simple network made up of Linux and Windows Endpoints, one data server and we server. Each component communicates with the other and accesses the internet through a router.
Each network ingredient can have one or more log sources being generated, such as setting up Sysmon with Windows Event logs for better Windows Endpoint visibility. The network can be divided into two logical parts:
1) Host-Centric Log Sources
These are log sources that capture events that occurred within or related to the host. Some log sources that generate host-centric logs are Windows Event logs, Sysmon, Osquery, etc. Some examples of host-centric logs are:
A user accessing a file
A user attempting to authenticate.
A process Execution Activity
A process adding/editing/deleting a registry key or value.
Powershell execution
2) Network-Centric Log Sources
Network-related logs are generated when the hosts communicate with each other or access the internet to visit a website. Some network-based protocols are SSH, VPN, HTTP/s, FTP, etc. Examples of such events are:
SSH connection
A file being accessed via FTP
Web traffic
A user accessing company's resources through VPN.
Network file sharing Activity
Some key features provided by SIEM are:
Real-time log Ingestion
Alerting against abnormal activities
24/7 Monitoring and visibility
Protection against the latest threats through early detection
Data Insights and visualization
Ability to investigate past incidents.
Windows records every event that can be viewed through the Event Viewer utility, assigning a unique ID to each type of log. Event Viewer can be located from the Windows search bar.
Linux OS stores events, errors, warnings, etc in common locations:
/var/log/httpd : Contains HTTP Request / Response and error logs.
/var/log/cron : Events related to cron jobs are stored in this location.
/var/log/auth.log and /var/log/secure : Stores authentication related logs.
/var/log/kern : This file stores kernel related events.
Web servers store requests/responses, useful for potential web attacks. In Linux, Apache logs are stored:
/var/log/apache
/var/log/httpd
All these logs provide a wealth of information and can help in identifying security issues. Each SIEM solution has its own way of ingesting the logs. Some common methods used by these SIEM solutions are explained below:
1) Agent / Forwarder: These SIEM solutions provide a lightweight tool called an agent (forwarder by Splunk) that gets installed in the Endpoint. It is configured to capture all the important logs and send them to the SIEM server.
2) Syslog: Syslog is a widely used protocol to collect data from various systems like web servers, databases, etc., are sent real-time data to the centralized destination.
3) Manual Upload: Some SIEM solutions, like Splunk, ELK, etc., allow users to ingest offline data for quick analysis. Once the data is ingested, it is normalized and made available for analysis.
4) Port-Forwarding: SIEM solutions can also be configured to listen on a certain port, and then the endpoints forward the data to the SIEM instance on the listening port.
SIEM is used to supply correlation on collected data to detect threats. Once detected, or a threshold is crossed, an alert is raised. This alert prepares analysts for suitable action based on investigation in a timely manner.
SIEM starts by collection logs and examining if any event/flow has matched a set condition or crossed a threshold which is why it is a major component of a SOC ecosystem.
Some of the common capabilities of SIEM are:
Correlation between events from different log sources.
Provide visibility on both Host-centric and Network-centric activities.
Allow analysts to investigate the latest threats and timely responses.
Hunt for threats that are not detected by the rules in place.
SOC Analysts utilize SIEM solutions in order to have better visibility of what is happening within the network. Some of their responsibilities include:
Monitoring and Investigating.
Identifying False positives.
Tuning Rules which are causing the noise or False positives.
Reporting and Compliance.
Identifying blind spots in the network visibility and covering them.
Dashboards are the most important components of any SIEM, presenting data for analysis after being normalized and ingested. The summary of these analyses is presented in the form of actionable insights with the help of multiple dashboards. Each SIEM solution comes with some default dashboards and provides an option for custom Dashboard creation. Some of the information that can be found in a dashboard are:
Alert Highlights
System Notification
Health Alert
List of Failed Login Attempts
Events Ingested Count
Rules triggered
Top Domains Visited
Correlation rules play an important role in the timely detection of threats allowing analysts to take action on time. Correlation rules are logical expressions set to be triggered. A few examples of correlation rules are:
If a User gets 5 failed Login Attempts in 10 seconds - Raise an alert for Multiple Failed Login Attempts
If login is successful after multiple failed login attempts - Raise an alert for Successful Login After multiple Login Attempts
A rule is set to alert every time a user plugs in a USB (Useful if USB is restricted as per the company policy)
If outbound traffic is > 25 MB - Raise an alert to potential Data exfiltration Attempt (Usually, it depends on the company policy)
Use-Case 1: Adversaries tend to remove the logs during the post-exploitation phase to remove their tracks. A unique Event ID 104 is logged every time a user tries to remove or clear event logs. To create a rule based on this activity, we can set the condition as follows:
Rule: If the Log source is WinEventLog AND EventID is 104 - Trigger an alert Event Log Cleared
Use-Case 2: Adversaries use commands like whoami after the exploitation/privilege escalation phase. The following Fields will be helpful to include in the rule.
Log source: Identify the log source capturing the event logs
Event ID: which Event ID is associated with Process Execution activity? In this case, event id 4688 will be helpful.
NewProcessName: which process name will be helpful to include in the rule?
Rule: If Log Source is WinEventLog AND EventCode is 4688, and NewProcessName contains whoami, then Trigger an ALERT WHOAMI command Execution DETECTED
Based on the investigation, the analyst determines if it's a True or False positive. Some of the actions that are performed after the analysis are:
Alert is False Alarm. It may require tuning the rule to avoid similar False positives from occurring again.
Alert is True Positive. Perform further investigation.
Contact the asset owner to inquire about the activity.
Suspicious activity is confirmed. Isolate the infected host.
Block the suspicious IP.
In the static lab attached, a sample dashboard and events are displayed. When a suspicious activity happens, an Alert is triggered, which means some events match the condition of some rule already configured.
Click on Start Suspicious Activity, which process caused the alert?
Find the event that caused the alert, which user was responsible for the process execution?
What is the hostname of the suspect user?
HR_02
Examine the rule and the suspicious process; which term matched the rule that caused the alert?
What is the best option that represents the event? Choose from the following: - False-Positive - True-Positive
True-positive
Selecting the right ACTION will display the FLAG. What is the FLAG?
