What are the different types of correlation rules in SIEM?

Hi,

Please find the different types of correlation rules in SIEM.

1)Detection of Possible Brute Force Attack:

With the evolution of faster and more efficient password cracking tools, brute force attacks are on a high against the services of an organization. As a best practice, every organization should configure logging practices for security events such as invalid number of login attempts, any modification to system files, etc., so that any possible attack underway will get noticed and treated before the attack succeeds. Organizations generally apply these security policies via a Group Policy Object (GPO) to all the hosts in their network.

2)Malware Check

These days, organizations believe in protecting their network end to end, i.e. right from their network perimeter with devices like firewall, Network Intrusion Prevention System (NIPS), till the endpoints hosts with security features like antivirus and Host Intrusion Prevention System (HIPS), but most organizations collect reports of security incidents from these security products in a standalone mode, which brings problem like false positives, etc.

Correlation logic is the backbone of every SIEM solution, and correlation is more effective when it is built over the output from disparate log sources. For example, an organization can correlate various security events like unusual port activities in firewall, suspicious DNS requests, warnings from Web Application firewall and IDS/IPS, threats recognized from antivirus, HIPS, etc. to detect a potential threat. Organizations can make following sub-use case under this category.

• Unusual network traffic spikes to and from sources.
• Endpoints with maximum number of malware threats.
• Top trends of malware observed; detected, prevented, mitigated.
• Brute force pattern check on Bastion host.

3)Detection of Anomalous Ports, Services and Un patched Hosts/Network Devices

Hosts or network devices usually get exploited because they often left unhardened, unpatched. Organizations first must develop a baseline hardening guideline that includes rules for all required ports and services rules as per business needs, in addition to best practices like “default deny-all”.

4)Unexpected Events Per Second (EPS) from Log Sources

Another common pattern found among compromised log sources is that attackers tends to change the configuration files of endpoint agents installed and forward a lot of irrelevant files to the SIEM manager, causing a bandwidth choke between the endpoint agent and manager. This affects the performance of real time searches configured, storage capacity of underlying index for storing logs, etc. Organizations must develop a use case to handle this suspicious behavior of log sources. For example, below is the search (SPL) created in Splunk which can detect unusual forwarding of events from log sources in one day.

5)Suspicious Behavior of Log Source

Expected Host/Log Source Not Reporting

Log sources are the feeds for any SIEM solution. Most of the SIEM solution these days comes with an agent-manager deployment model, which means that on all the log sources, light weight SIEM agent software is installed to collect logs and pass them to a manager for analysis. An attacker, after gaining control over a compromised machine/account, tends to stop all such agent services, so that their unauthorized and illegitimate behavior goes unnoticed.

• Rogue Name Servers. User devices should be configured to use the internal corporate DNS servers. The local DNS servers should be able to get out to the Internet to find domains they don’t have information on. This correlation rule should monitor for any source address accessing UDP/TCP port 53 (or even better the DNS application), where the destination is NOT the internal DNS servers.
• Rogue Proxy Servers. From your perimeter firewalls, you should only see traffic from the LAN subnet coming from the proxy server to anywhere on TCP port 80/443 or application web browsing and SSL.  Anything else could be an attempt to subvert this control by an employee or contractor or malware configured to do so. If the source IP is NOT your proxy, and the destination application is web browsing or SSL, trigger an alert.
• BOTNET Traffic. Older command and control software would leverage Internet Relay Chat (IRC) for management. While IRC is not necessarily more risky than any other instant messaging protocol, it is bad more often than not when seen in a corporate network. Just be prepared to create filters from some of your network admin computers. If the source and destination are any host, and the application in use is IRC, trigger an alert.
• SPAM bot. All corporate email will be delivered through the corporate SMTP relays. If SMTP traffic is seen from a system using a different SMTP server, there is a good chance that the host is infected with software designed to send SPAM. If the source is any host on your LAN, the destination is any host other than your SMTP servers, and the application is SMTP, trigger an alert.
• Server Compromise. The basics of client server technology are clients connected to servers on TCP ports up to 1024, using a source port of 1024-65535. When someone connects to a web server, they will be using a port between 1024-65535 and connecting to TCP 80 or 443. That is what should be showing up in the firewall logs. If the source is your web server(s), and the source port is not TCP 80 or 443, trigger an alert. This means that your web server is initiating the connection, which it should not be doing. Some tuning will have to be done to allow for software installation and updates. The same logic could be applied to any type of server.
• Misuse of Administration Account. While not firewall log related, this one is great. All systems have some form of administrator or root account. Best practice for administrators is for them to have the same level of privilege on their own account. This provides accountability of the changes administrators make, rather than seeing a generic account name in the logs. Once this is complete, if there is a successful login, and the username is “administrator” or “root” or any other generic device administrator, trigger an alert. Someone is likely trying to make unauthorized changes.