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