SIEM Correlation Rules: Enhancing Your Threat Detection
Logs represent the real-time activities of every single corner of your enterprise. Each audit log contains the information of a user’s activity, parameters, resources, and timing, making them a veritable goldmine of data. Using these to protect enterprises demands more than just data, though: logs need to be strung together and identified as either safe or malicious – all before the attacker is able to deploy a payload or steal data. This is where correlation rules shine.
In analytics, a correlation is any relationship or connection between two elements – by mapping the relationship between each piece of log data and creating SIEM correlation rules, your SIEM is able to cohesively monitor each datapoint in relation to one another. Finally, these sequences are identified as safe or potentially malicious by adding rules on top of this data. Good traffic is allowed,while bad or suspicious traffic is marked as such – and blocked.
Next-Generation SIEM
Stellar Cyber Next-Generation SIEM, as a critical component within the Stellar Cyber Open XDR Platform...
Experience AI-Powered Security in Action!
Discover Stellar Cyber's cutting-edge AI for instant threat detection and response. Schedule your demo today!
How SIEM Correlation Rules Work
Step 1: Log Centralization
The logs from all of your systems are collected and forwarded to the SIEM. This is made possible by sensors and agents – small pieces of software installed on endpoint devices, networks, and servers that passively monitor the data packets being transferred across a network and the actions running on devices. In this step, the SIEM tool begins the process of pulling these logs into a central analysis engine.
Step 2: Data Normalization
While the logs cover every single angle of your infrastructure – it’s still made up of vastly different applications, servers, and hardware, each with its unique format for listing log entries. Event logs from different sources may have drastically varied information fields and data structures. The second step to SIEM correlation is normalizing these, which works by parsing the different logs into a consistent, standardized format.
The more efficient the normalization of this log data is, the faster the SIEM can begin analyzing and applying threat detection techniques.
Step 3: Data Correlation
With all log data now ingested, the correlation engine is able to see how it conforms to common patterns. Some SIEM tools only go far enough to individually identify single strings, but more advanced offerings like Stellar’s add a second layer of correlation that looks at other attributes – such as request and response parameters. This helps solidify the relationship between the behavior and the entity involved.
This is fairly high-level, so let’s consider data correlation in the context of an actual attack: consider an attacker’s attempts to brute force access to an enterprise via their Identity and Access Management (IAM) provider. The behaviors involved may include a campaign of continuous login attempts to gain access (action A), that is then followed by a successful login (action B). Next, they might proceed to access the admin console and create a new user with elevated privileges – or initiate a slew of port scans to scope out weak areas and sensitive resources. Let’s call this action C.
Rule-based correlation allows for each Technique, Tactic and Procedure (TTP) to be placed into a sequence: these sequential correlations can then trigger a rule action, which is passed onto the analyst via an alert. It’s the way in which these attributes are joined up that defines the identification capability of a SIEM tool.
Rule Based vs Behavioural Correlation
The actions involved in the attack we just went over can be discovered in two ways: the first is via a rule that explicitly states ‘if action A is followed by B and then C, trigger an alert’. This works very well if the analysts are aware of the possibility of this attack ahead of time, and have a rough idea of what TTP an attacker may take.
However, it’s not the only approach: that brute force attack could also be discovered by a more general rule of ‘if a set of actions deviates from the normal authentication behavior of an end user, trigger an alert’. This rule relies on the SIEM having a historical understanding of how an end-user usually acts; now possible thanks to running those centralized logs through a Machine Learning algorithm. With this, it becomes very easy to establish day-to-day patterns of user, device, and traffic behavior – and therefore use behavioral correlation as a base for SIEM rules. Behavioral correlation is often used to produce a ‘risk score’, for which the analysts set an acceptable threshold.
Since we’ve doubled the number of different approaches we can take to identifying threats, it’s more critical than ever to actively keep your SIEM rules pruned and high-functioning – we’ll discuss how best to achieve this below.
Benefits of SIEM Correlation Rules for Threat Detection
Signature-based threat detection
The vast majority of attacks are not particularly unique: opportunistic attackers copy-pasting malicious code is so common that they’ve gained the nickname of ‘script kiddies’. This is why the vast majority of SIEM attack surface protection is via signature-based detection.
The repositories of malware signature sites are ever-expanding: one of the most well-known is the M&TRE ATTACK database. This identifies the specific approaches being taken by attackers, and therefore grants security practitioners an open source database for SIEM rules. These rulesets rely on defining patterns of known malicious behavior.
However, the more widespread the SIEM rule is, the more focus attackers will place on evading it. This places correlation rules in an ongoing race between attacker and security analyst. And, if the security team starts winding up too many rules, they risk being inundated with SIEM false positives.
Stellar Cyber removes the old difficulties faced by pure correlation-based SIEMs by adding another layer of ML analysis. Analysts can cover as many bases as possible with correlation rules, and then the second layer of analysis assesses the wider context of each alert to determine its legitimacy.
Prepopulated Rules for Real-World Threats
Correlation rules are purpose-built to identify common threats that hackers use over and over again to attempt access to resources. A single enterprise’s IT team may not have the most up-to-date understanding of real-world TTPs, however. After all, threat intelligence demands the continuous gathering, processing, and application of data about malicious actors, techniques, and indicators of compromise.
This is why pre-packaged correlation rules are such a benefit: these prepopulated approaches are built from a macro view of your industry and the wider threat space. Each behavior variation is able to be labeled and associated to its alert type, therefore reducing the sporadic nature of log alerts into a more streamlined whole.
Data and Access Compliance
Organizations in virtually every industry have to demonstrate that they adhere to certain laws, rules, and regulations – and these change depending on the industry you’re active within. European branches need to keep an eye on GDPR, while any payment-oriented business needs to conform to PCI DSS.
GDPR is one of the strictest and widest-reaching regulations, demanding data security across an organization’s technical processes. Because SIEM logs account for the entirety of an organization’s assets and user accounts, it’s uniquely well-positioned to achieve this.
This is a true benefit of correlation rules: their universal applicability. By sending out an alert whenever a set of abnormal logs are discovered, it gives analysts an advanced warning on potential compliance issues. The ability to draw up your own rules also allows for compliance regulations to be written into your security structure from the very foundation. If PCI DSS requires you to keep all endpoint anti-malware up to date, implement a SIEM rule that alerts you when an anti-malware solution hasn’t been updated. More advanced SIEM tools let you automate this entire process, while keeping a forensic file on its actions. The acceleration granted by SIEMs is particularly vital in the context of regulations like GDPR, granting a small, 72-hour window in which to inform and address security incidents.
Multi-stage Attacks and Advanced Persistent Threats (APTs) Detection
Individual correlation rules are simple enough, but the sheer granularity of logs allows for far sharper resolution and mitigation. This is where composite rules can be excellent at identifying more advanced threats: these nest multiple rules together to hone in on a specific behavior within a specific context. For example, if X login attempts at the same workstation (and same IP address) fail within X minutes and use different user names – and if a successful login occurs on any computer within the network and comes from the identical IP address – this will trigger an alert.
Composite rules can be vital for cutting off APT entry points. That’s when an intruder gains initial access to an organization’s network, finds a safe point of access, and then just doesn’t do anything with it. While the threat may look dormant, they’re likely just waiting for an opportune time – or even a buyer for the ongoing exploit. When they choose, the intruder can simply waltz past the firewall and steal data or deploy malware, as their account or actions are assumed to be safe.
Simple correlation rules have traditionally been unreliable at discovering APTs; if the analysts aren’t aware of the potential TTP, they’re unlikely to discover the threat.
So, the most reliable approach is one step beyond composite rules: modern behavioral models allow for past actions to be drawn into the analysis engine. The ongoing analysis of incoming and outgoing network traffic then allows for any deviation from the user’s expected actions to be flagged as risky.
Best Practices for Building SIEM Correlation Rules
Prioritize Use Cases
When first adapting a SIEM to your enterprise, SIEM best practices dictate that you have a clear idea of the precise use cases your SIEM will solve. Ranked in order of priority, these use cases need to be honed in on, and the pre-packaged rules assessed for how well they fit your own enterprise. From there, you’re free to start editing or adding to each narrower section of correlation rules.
If you don’t know what specific attack techniques may be leveraged against you, check out MITRE ATT&CK or Lockheed’s Cyber Kill Chain. Both do immense work to catalog attackers’ specific approaches and exploits in extraordinary depth.
Make Use of Your Firewall
-
- A “Rogue Name Server” rule should monitor for any device attempting to access the DNS application with a destination other than the internal corporate DNS servers. Internal devices should be configured to use only the corporate DNS servers, which then reach the Internet as needed to resolve unknown domains.
- A “Rogue Proxy Server” rule should observe perimeter firewalls for any traffic from the LAN subnet headed to the Internet on TCP ports 80/443 or for web browsing and SSL applications. Ideally, only traffic from the designated proxy server should be allowed; any other source IP attempting this type of connection may indicate an attempt to bypass security, whether by a user or malware.
- A “BOTNET Traffic” rule can identify older command and control (C2) software that uses Internet Relay Chat (IRC) for management. While IRC isn’t inherently malicious, its presence in a corporate network is often suspicious. This rule should trigger an alert if any source or destination host is using IRC, though certain network administration computers may need exclusions.
Minimize Open Ports
By default, sensors listening on port 514 analyze incoming logs; this helps identify the source device. Specifying a more targeted port for your log type rather than using port 514 offers several advantages. It accelerates data ingestion and log parsing, improving sensor performance since the sensor can instantly identify the source device. Last but not least, basing a correlation rule off the correct port is massively important to preserving log information.
Instead, select the appropriate port depending on their format:
- Common Event Format (CEF), Log Event Extended Format (LEEF), or JSON: for these log types, forward data to the port assigned for that standard.
- Standard Syslog format logs: use the port designated for the specific vendor.
- For specialized formats such as Syslog combined with regular expressions, key-value pairs, or CSV, utilize vendor-specific ports.
Threat Hunt
Implementing proactive threat hunting alongside a well-configured SIEM system significantly enhances its threat detection capabilities, adding significant weight to the analytical power of automated log analysis. While a properly tuned SIEM can effectively monitor and alert on many known threats, adding automated threat-hunting enables the detection of sophisticated, evolving, or stealthy attacks that might bypass standard correlation rules.
A threat-hunting SIEM like Stellar Cyber simulates the real-world attack potential of an alert or anomaly after it’s been generated: this ongoing validation process helps ensure that correlation rules are precise, adaptable, and effective against emerging attack methods. It also feeds into how alerts are prioritized – and gives a foundation for analysts to manually threat hunt. Analysts can search through the malware sandbox record to identify attempted attacks, giving them a more informed view into the attack leveraged against them.
Integrate for Rapid Response
Integrating a SIEM within the wider tech stack enhances its ability to detect, analyze, and respond to threats effectively. This can include linking the SIEM with tools like endpoint detection and response (EDR), threat intelligence platforms, incident response systems, and security orchestration, automation, and response (SOAR) solutions. Even better, integration with security tools paves the path for automated threat responses – a guiding focus of Stellar Cyber.
Go Beyond Basic Rules with Stellar Cyber’s Cases
Stellar Cyber takes a multi-modal approach to rule creation: offering a stacked deck of correlation rules and ML-driven behavioral analysis, it makes full use of all logs generated across your enterprise. Alerts are created as log data triggers individual rules, but Stellar correlates these into unified cases, each representing a collection of potentially connected alerts within a single data structure. From there, analysts are granted a suite of playbooks and remediation options designed to minimize MTTR.
Stellar Cyber’s cross-verification of alerts grants deeper context, enabling analysts to determine if they’re handling a genuine attack, high-risk behavior, or simply coincidental events. See how to set up automated responses and block malicious traffic immediately with a demo today.
