A central collector for logs, SIEMs provide an important tool for defenders to monitor for changes and attacks, hunt for ttp’s and ioc’s, and quickly identify if an incident has occurred.
SIEM stands for Security Information and Event Management. SIEMs are a central system that collects and parses log data. This log data can come from nearly anything that’s capable of sending logs, including servers, clients, networking equipment, and native or 3rd party applications.
The SIEM Revolution: More Than Just Log Management
Gone are the days when SIEM was merely a tool for collecting and storing logs. Today’s SIEM solutions are sophisticated powerhouses that form the backbone of proactive cybersecurity strategies. They not only aggregate data from various sources but also provide real-time analysis, threat detection, and automated response capabilities.
Latest SIEM Technologies: Your New Best Friend
The latest SIEM technologies are like having a tireless, ultra-intelligent security analyst working 24/7. Here’s what sets them apart:
- AI-Powered Threat Detection: Modern SIEM solutions leverage artificial intelligence to identify patterns and anomalies that human analysts might miss. Imagine catching a stealthy APT before it even knows it’s been spotted!
- Real-Time Correlation: By analyzing data from multiple sources in real-time, these systems can connect the dots faster than ever before. It’s like having a bird’s eye view of your entire network ecosystem.
- Automated Response: When every second counts, automated response capabilities can be a game-changer. From isolating infected systems to updating firewall rules, modern SIEM tools can react to threats at machine speed.
The Future is Now: SIEM Industry Trends
The SIEM landscape is evolving rapidly. Here are some exciting trends to watch:
- Cloud-Based SIEM: As organizations move to the cloud, so too are SIEM solutions. This offers scalability and reduces the need for on-premises infrastructure.
- Threat Intelligence Integration: SIEM systems are increasingly incorporating global threat intelligence feeds, providing context and enhancing threat detection capabilities.
- User and Entity Behavior Analytics (UEBA): By establishing baselines of normal behavior, SIEM can detect subtle anomalies that might indicate a compromise.
Popular SIEM Systems
- Splunk – Splunk is the most popular SIEM system. It can scale up to any size business, and also offers a free option that can index up to 500 MB/day! Splunk also has a wealth of “apps” which run inside Splunk and come pre-configured. You can also create rich dashboards and visualizations such as a real-time attack map!
- ELK Stack – Another popular option is the ELK Stack, which is an acronym for three open source projects: Elasticsearch, Logstash, and Kibana. Elasticsearch is a search and analytics engine. Logstash is a server‑side data processing pipeline that ingests data from multiple sources simultaneously, transforms it, and then sends it to a “stash” like Elasticsearch. Kibana lets users visualize data with charts and graphs in Elasticsearch. Can be set up on-premise or hosted through “Elastic Cloud”
- LogRythm – Performs broad-based collection and identifies threats with corroboration across one or more security-related activities or integrations. Combines user and entity behavior analytics (UEBA), network traffic and behavior analytics (NTBA) and security orchestration, automation, and response (SOAR) in a single end-to-end solution.
What Data to Log?
One of the most important log sources will be Firewall logs, including any Web Application Firewalls, as well as logs from any business-critical systems or applications, so that you can quickly identify and help troubleshoot/remediate attacks such as Denial of Service and others targeted at your internet-facing infrastructure.
Another source of logs you’re going to want to send to your SIEM is Web Proxy logs. Whatever solution you may be using whether it be Websense, Checkpoint URL-Blade, zscaler etc, you are going to want to be able to quickly search users web browsing activity. This makes it easy to identify any domain/URL based IOCs that are associated with specific malware which you find online, or are seen from alerts in other security products in your environment. For example, if a user reports a phishing email, you can quickly search to see if any of the other recipients have browsed to the phishing URL found in the e-mail.
Logs of emails received and send can be beneficial to ingest as well. These logs can be used to craft alerts regarding attacks such as impersonation, phishing, and malware. From there, analysts can pivot to an internal email security gateway, where the body of the email can be investigated.
In cloud environments such as AWS for example, Guard Duty, CloudTrail, and Config logs can be ingested to create detection and alerting regarding possible malicious activity or configuration changes. Below are some logging strategies provided by AWS: https://aws.amazon.com/blogs/security/logging-strategies-for-security-incident-response/
Successfully defending also means being able to identify the actions of an attacker after they’ve gained access to the network. Some of this can be accomplished by having visibility into Windows Active Directory and Azure logs. This visibility will allow you to spot some attack techniques such as lateral movement, log clearing, and privilege escalation. The logs will also help to spot potential attacks by being able to view trends in authentication failures, which may indicate a brute-force or password spray attack.
Windows Logs
I’ve created the following list of Windows Active Directory Events that would be beneficial to ingest and create use cases and detection and alerting around.
AD Events full list:
Security Logs – Authentication Failures / Lockouts
- Event ID 4624 – Successful Logon
- Event ID 4625 – Failed Logon
- Event ID 4768 – A Kerberos authentication ticket (TGT) was requested
- Event ID 4776 – The domain controller attempted to validate the credentials for an account
- Event ID 4672 – Special privileges assigned to new logon
- Event ID 529 – Logon Failure – Unknown user name or bad password
- Event ID 530 – Logon Failure – Account logon time restriction violation
- Event ID 531 – Logon Failure – Account currently disabled
- Event ID 532 – Logon Failure – The specified user account has expired
- Event ID 533 – Logon Failure – User not allowed to logon at this computer
- Event ID 534 – The user has not been granted the requested logon type at this machine
- Event ID 535 – Logon Failure – The specified account’s password has expired
- Event ID 536 – Logon Failure – The NetLogon component is not active
- Event ID 537 – Logon failure – The logon attempt failed for other reasons
- Event ID 539 – Logon Failure – Account locked out
How to set up logging
Setting up Windows event logging requires a central collection point where the logs will be stored, and then indexed and sent to a SIEM. The collection point can be a virtual or physical server or a collection of servers that cover different geographical regions, which all specified event IDs are sent to, then from there they’re indexed sent to the SIEM. Since there will always be sizing restrictions on how much data you can parse, only specific event IDs that would be beneficial to spot an attacker should be used, and not just all events IDs. Once the event log is able to be searched through on the SIEM, alerts and dashboards can be created and investigated to spot any potential attacker activity.
A good technique of gathering windows logs is to use tools which are built into Windows itself. “Windows Event Forwarding” (WEF) is built into Windows and can be deployed easily with group policy and can collect only specific event IDs that you specify. Logs of only these event IDs are then sent to the central “Windows Event Collector” (WEC) servers, which are then indexed and sent to a SIEM. Using Windows Event Forwarding, you must also enable, through group policy, the WinRM service on all client machines. The service just has to be started, but not configured!
Following is some documentation regarding the use and configuration of Windows Event forwarding, including common questions:
Windows Event Forwarding (WEF)
https://docs.microsoft.com/en-us/windows/security/threat-protection/use-windows-event-forwarding-to-assist-in-intrusion-detection
https://blogs.technet.microsoft.com/jepayne/2015/11/23/monitoring-what-matters-windows-event-forwarding-for-everyone-even-if-you-already-have-a-siem/
https://docs.microsoft.com/en-us/windows/desktop/wec/windows-event-collector
Log Analysis in Action: Real-World Scenarios
Let’s look at some specific scenarios where SIEM shines:
- Detecting Insider Threats:User: JohnDoe
Action: Accessed sensitive financial data
Time: 2:00 AM
Location: Remote IP
A good SIEM system with UEBA would flag this as suspicious activity, potentially catching an insider threat or compromised account.
- Identifying DDoS Attacks:Source IPs: Multiple
Destination: Web Server
Protocol: TCP
Requests/sec: 10,000+
SIEM can correlate this data across multiple devices, identifying and mitigating a DDoS attack in its early stages.
- Compliance Monitoring:File: PatientRecords.db
Action: Accessed
User: MarketingUser
In a healthcare setting, SIEM can alert administrators to potential HIPAA violations by detecting unauthorized access to patient data.
Embracing the SIEM Advantage
In a world where cyber threats are constantly evolving, utilizing a modern SIEM provides the visibility and intelligence needed to stay one step ahead. It’s not just about collecting logs anymore; it’s about turning that data into actionable insights and automated responses.
