Let’s learn how SIEM correlation rules work!
SIEM are very powerful security tools when deployed properly. We already know that a well-configured SIEM will alert security administrators to which events and trends they should pay attention to.
In your company network, all the endpoints and all network devices such as IDS/IPS, firewalls, switches and routers, are generating a plethora of log data. Thus, there are so many sources of data for a SIEM solution.
If your SIEM solution is configured correctly, it will filter through irrelevant log data to allow your security team to focus on essential and high-risk alerts. Otherwise they’ll be too lost in event log noise to be able to effectively handle possible security threats to their network.
Most modern SIEM solutions now provide out of the box 'correlation rules' and sophisticated models to surface a broad range of abnormal behavior and events. Once you understand how they work, you’ll likely want to customize these resources, while also adding your own rules and models to suit your organization’s unique situation.
The first barrier a SIEM encounters is 'normalizing' the log data, before it can detect and alert your team.
-
What is Data normalization in SIEM?
Your IT infrastructure will consist of different applications, software, network devices, and other hardware equipment. Each of these equipment will have their 'own format' for recording log entries. Event logs from different sources will have different information fields and data formats.
Ideally, a SIEM system is expected to parse these different log formats and normalize them in a standard format so that this data can be analyzed. Here, a SIEM platform attempts to universalize the log entries coming from a wide range of sources. This is known as Normalization of logs!
During the normalization process, a SIEM answers questions such as:
• Which column should contain the protocol name?
• How will SIEM establish a relationship between source IP address for different devices?
• What would be the column label for an IP address? (IP, IP Address, IP Addresses, Source.IP, Destination.IP, Gateway IPs, Public IPs, etc.)
• Should UDP ports get one column and TCP ports get a different column, or should all UDP and TCP ports be in the same column?
• Should every normalized log entry have the name of the manufacturer/vendor?
• Will normalized data support tracking of a security incident from the beginning to the end?
-
One of the key components that a functioning SIEM requires is good and sensible SIEM correlation rules.
If the normalization of log data is efficient, it can streamline the working of your correlation rules without any bottlenecks. As normalization for a SIEM platform improves, false positives decrease, and detection power increases.
While your SIEM normalizes log data after receiving it from the configured sources, you can further arrange data specific to your requirements while defining a new rule for a better presentation of data.
What is a correlation rule?A SIEM correlation rule tells your SIEM system which sequences of events could be indicative of anomalies which may suggest security weaknesses or cyber attack.
When “x” and “y” or “x” and “y” plus “z” happens, your administrators should be notified.
Here are some examples of SIEM correlation rules which illustrate this concept.
1. Detect new DHCP servers in your network by watching for inside or outside connections which use UDP packets (“x”), have port 67 as the destination (“y”), and the destination IP address isn’t on the registered IP list (“z”).
2. Warn administrators if five failed login attempts are tried with different usernames from the same IP to the same machine within fifteen minutes (“x”), if that event is followed by a successful login occuring from that same IP address to any machine inside the network (“y”).
The first example could indicate a cyber attacker establishing a DHCP server to acquire malicious access to your network. Any authorized DHCP server would use one of your registered IP addresses!
The second example could indicate a cyber attacker brute-forcing an authentication vector and then successfully acquiring authentication to your network. It could be a possible privilege escalation attack.
Both SIEM correlation rules could be triggered by honest mistakes and simple user errors or technical glitches. But they’re also key indicators of cyber attack and security administrators should check them out right away!
-
Creating your correlation rules on SIEM
Most SIEM already come with inbuilt correlation rules that are continuously tested and updated by the internal teams of the vendor. If you plan to create new correlation rules, you must ensure that your correlation rules don’t lead to your security team wasting their efforts to filter through false positive alerts.
While it cannot be denied that it is impossible to have zero false positives in any SIEM solution, it is recommended that your customizations should not increase the probability of false positives.
-
When should you use correlation rules?
You might think using models is the best way to handle all threat detection. But there are situations where correlation rules are the best and most straightforward option. Here are some examples best handled by correlation rules:
• Monitoring well-known threats – Correlation rules can easily detect common threats that hackers repeatedly use to attempt access to your resources. Many SIEM solutions come prepopulated with rules to handle these types of threats.
• Compliance violation – Organizations in every industry must demonstrate that they comply with certain laws, rules, and regulations, e.g., GDPR, HITECH, and PCI DSS. Each has requirements you can validate with correlation rules. For example, “Alert if antivirus software is disabled on any network-connected computer.”
• Signature-based threat detection – Malware detection systems have constantly expanding repositories containing hundreds of millions of known threat-identifying signatures. Rules are the best way to detect these.
-
A WORD OF CAUTIONWhen configuring your SIEM correlation rules, you need to strike a balance between reducing false positive alerts and not missing any possible anomalies which could indicate cyber attack.
Some out-of-the-box SIEM correlation rules might not be applicable to your specific network. Deciding which pre-configured rules to disable and which rules should be written from scratch are another challenge.
Improperly filtered SIEM rules can make slow execution time-consuming to your SIEM system. Administrators need to filter the application of rules to determine which data is relevant and which data is irrelevant in your event pipeline.
-
Please let me know of what do you think about this in the comment section. You can also share with all if the information shared here helps you in some manner.
Kindly write your comment on the posts or topics, because when you do that you help me greatly in designing new quality article/post on cybersecurity.This Article Was Written & published by Meena R, Senior Manager - IT, at Luminis Consulting Services Pvt. Ltd, India.
Over the past 16 years, Meena has built a following of IT professionals, particularly in Cybersecurity, Cisco Technologies, and Networking...
She is so obsessed with Cybersecurity domain that she is going out of her way and sharing hugely valuable posts and writings about Cybersecurity on website, and social media platforms.
30,000+ professionals are following her on Facebook and mesmerized by the quality of content of her posts on Facebook.
If you haven't yet been touched by her enthusiastic work of sharing quality info about Cybersecurity, then you can follow her on Facebook:
Click Here to follow her: Cybersecurity PRISM