Security information and event management (SIEM) deployments are becoming more common each day. Companies around the world are investing big dollars to have the best technology available to contend with the increasingly sophisticated cyberattacks happening daily.

There is no denying the power and control an SIEM affords security professionals at any company, but maintaining and tuning this technology is extremely time-consuming. An SIEM solution requires a lot of work to plan, install and, ultimately, mature.

A Bird’s-Eye View

When configured properly, an SIEM system can give security teams enhanced visibility — an eagle eye over a network, if you will. To unlock the full potential of this visibility, analysts must feed the SIEM the right logs for interpretation and correlation.

This sounds like a very simple task, but could become a bit of a mess. It’s common to find that log sources — devices that send data to the SIEM — are not sending information at all. This should be a red flag on any deployment. What good is a domain controller, for example, if it does not log to the SIEM?

Prioritizing SIEM Log Sources

To address this problem, administrators can create reports or rules to alert the team if a log source stops sending events to the SIEM platform. However, this can become a strenuous task in itself.

Say that a security team has 4,000 log sources in its environment and receives an email alert with a list of 500 sources that are not reporting. Is it the best use of the SIEM team’s time to review a list of 500 faulty sources every day? In modern environments, it’s common for some devices, such as standby or secondary devices, to log infrequently or not at all. These sources would likely show up on a device not reporting (DNR) list, and SIEM teams should not waste time investigating them.

To remediate this problem and make DNR reports smarter, security professionals should first sort log sources into four categories:

  1. High priority — Devices that send high volumes of logs to your SIEM at frequent intervals of no longer than three hours.
  2. Medium priority — Devices that log frequently but could go more than three hours without sending any data.
  3. Low priority — Devices that might go days without sending logs, such as routers.
  4. High availability (HA) — All standby or secondary devices that are part of an HA cluster.

Next, analysts should create four log source groups and add each source to the group that corresponds with its priority level. The final step is to create rules for monitoring the categorized log sources:

  1. High priority — If the log sources in this group do not report in three hours, send an email with a list of nonreporting sources so the team can begin to troubleshoot.
  2. Medium priority — Send a similar email if any source in this group does not send logs in eight to 10 hours.
  3. Low priority — Alert the team if any sources haven’t sent logs in two days.
  4. HA — Standby devices should not report unless something happens to the primary device. Therefore, the rule for these log sources should monitor to determine whether any devices in this group have reported in the last 12 hours, which would warrant further investigation.

Guarding the Crown Jewels

These thresholds can be modified to fit any specific environment. It’s also worth noting that rules are not completely necessary; you could work off of reports as well. For your primary devices and/or crown jewels, it is best to configure these sources to generate alerts individually when they are not reporting to the SIEM.

At the end of the day, it is crucial to monitor the sources of information pertaining to the company’s most valuable and sensitive assets. This could make all the difference in the world when it comes to detecting critical threats — or even just passing an audit.

Download the 2017 Gartner Magic Quadrant for SIEM

More from Intelligence & Analytics

Hive0051’s large scale malicious operations enabled by synchronized multi-channel DNS fluxing

12 min read - For the last year and a half, IBM X-Force has actively monitored the evolution of Hive0051’s malware capabilities. This Russian threat actor has accelerated its development efforts to support expanding operations since the onset of the Ukraine conflict. Recent analysis identified three key changes to capabilities: an improved multi-channel approach to DNS fluxing, obfuscated multi-stage scripts, and the use of fileless PowerShell variants of the Gamma malware. As of October 2023, IBM X-Force has also observed a significant increase in…

Email campaigns leverage updated DBatLoader to deliver RATs, stealers

11 min read - IBM X-Force has identified new capabilities in DBatLoader malware samples delivered in recent email campaigns, signaling a heightened risk of infection from commodity malware families associated with DBatLoader activity. X-Force has observed nearly two dozen email campaigns since late June leveraging the updated DBatLoader loader to deliver payloads such as Remcos, Warzone, Formbook, and AgentTesla. DBatLoader malware has been used since 2020 by cybercriminals to install commodity malware remote access Trojans (RATs) and infostealers, primarily via malicious spam (malspam). DBatLoader…

New Hive0117 phishing campaign imitates conscription summons to deliver DarkWatchman malware

8 min read - IBM X-Force uncovered a new phishing campaign likely conducted by Hive0117 delivering the fileless malware DarkWatchman, directed at individuals associated with major energy, finance, transport, and software security industries based in Russia, Kazakhstan, Latvia, and Estonia. DarkWatchman malware is capable of keylogging, collecting system information, and deploying secondary payloads. Imitating official correspondence from the Russian government in phishing emails aligns with previous Hive0117 campaigns delivering DarkWatchman malware, and shows a possible significant effort to induce a sense of urgency as…

X-Force releases detection & response framework for managed file transfer software

5 min read - How AI can help defenders scale detection guidance for enterprise software tools If we look back at mass exploitation events that shook the security industry like Log4j, Atlassian, and Microsoft Exchange when these solutions were actively being exploited by attackers, the exploits may have been associated with a different CVE, but the detection and response guidance being released by the various security vendors had many similarities (e.g., Log4shell vs. Log4j2 vs. MOVEit vs. Spring4Shell vs. Microsoft Exchange vs. ProxyShell vs.…

Topic updates

Get email updates and stay ahead of the latest threats to the security landscape, thought leadership and research.
Subscribe today