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

X-Force Threat Intelligence Index 2024 reveals stolen credentials as top risk, with AI attacks on the horizon

4 min read - Every year, IBM X-Force analysts assess the data collected across all our security disciplines to create the IBM X-Force Threat Intelligence Index, our annual report that plots changes in the cyber threat landscape to reveal trends and help clients proactively put security measures in place. Among the many noteworthy findings in the 2024 edition of the X-Force report, three major trends stand out that we’re advising security professionals and CISOs to observe: A sharp increase in abuse of valid accounts…

Web injections are back on the rise: 40+ banks affected by new malware campaign

8 min read - Web injections, a favored technique employed by various banking trojans, have been a persistent threat in the realm of cyberattacks. These malicious injections enable cyber criminals to manipulate data exchanges between users and web browsers, potentially compromising sensitive information. In March 2023, security researchers at IBM Security Trusteer uncovered a new malware campaign using JavaScript web injections. This new campaign is widespread and particularly evasive, with historical indicators of compromise (IOCs) suggesting a possible connection to DanaBot — although we…

Accelerating security outcomes with a cloud-native SIEM

5 min read - As organizations modernize their IT infrastructure and increase adoption of cloud services, security teams face new challenges in terms of staffing, budgets and technologies. To keep pace, security programs must evolve to secure modern IT environments against fast-evolving threats with constrained resources. This will require rethinking traditional security strategies and focusing investments on capabilities like cloud security, AI-powered defense and skills development. The path forward calls on security teams to be agile, innovative and strategic amidst the changes in technology…

Topic updates

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