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

RansomExx Upgrades to Rust

IBM Security X-Force Threat Researchers have discovered a new variant of the RansomExx ransomware that has been rewritten in the Rust programming language, joining a growing trend of ransomware developers switching to the language. Malware written in Rust often benefits from lower AV detection rates (compared to those written in more common languages) and this may have been the primary reason to use the language. For example, the sample analyzed in this report was not detected as malicious in the…

Moving at the Speed of Business — Challenging Our Assumptions About Cybersecurity

The traditional narrative for cybersecurity has been about limited visibility and operational constraints — not business opportunities. These conversations are grounded in various assumptions, such as limited budgets, scarce resources, skills being at a premium, the attack surface growing, and increased complexity. For years, conventional thinking has been that cybersecurity costs a lot, takes a long time, and is more of a cost center than an enabler of growth. In our upcoming paper, Prosper in the Cyber Economy, published by…

Overcoming Distrust in Information Sharing: What More is There to Do?

As cyber threats increase in frequency and intensity worldwide, it has never been more crucial for governments and private organizations to work together to identify, analyze and combat attacks. Yet while the federal government has strongly supported this model of private-public information sharing, the reality is less than impressive. Many companies feel that intel sharing is too one-sided, as businesses share as much threat intel as governments want but receive very little in return. The question is, have government entities…

Tackling Today’s Attacks and Preparing for Tomorrow’s Threats: A Leader in 2022 Gartner® Magic Quadrant™ for SIEM

Get the latest on IBM Security QRadar SIEM, recognized as a Leader in the 2022 Gartner Magic Quadrant. As I talk to security leaders across the globe, four main themes teams constantly struggle to keep up with are: The ever-evolving and increasing threat landscape Access to and retaining skilled security analysts Learning and managing increasingly complex IT environments and subsequent security tooling The ability to act on the insights from their security tools including security information and event management software…