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

What makes a trailblazer? Inspired by John Mulaney’s Dreamforce roast

4 min read - When you bring a comedian to offer a keynote address, you need to expect the unexpected.But it is a good bet that no one in the crowd at Salesforce’s Dreamforce conference expected John Mulaney to tell a crowd of thousands of tech trailblazers that they were, in fact, not trailblazers at all.“The fact that there are 45,000 ‘trailblazers’ here couldn’t devalue the title anymore,” Mulaney told the audience.Maybe it was meant as nothing more than a punch line, but Mulaney’s…

New report shows ongoing gender pay gap in cybersecurity

3 min read - The gender gap in cybersecurity isn’t a new issue. The lack of women in cybersecurity and IT has been making headlines for years — even decades. While progress has been made, there is still significant work to do, especially regarding salary.The recent  ISC2 Cybersecurity Workforce Study highlighted numerous cybersecurity issues regarding women in the field. In fact, only 17% of the 14,865 respondents to the survey were women.Pay gap between men and womenOne of the most concerning disparities revealed by…

Protecting your data and environment from unknown external risks

3 min read - Cybersecurity professionals always keep their eye out for trends and patterns to stay one step ahead of cyber criminals. The IBM X-Force does the same when working with customers. Over the past few years, clients have often asked the team about threats outside their internal environment, such as data leakage, brand impersonation, stolen credentials and phishing sites. To help customers overcome these often unknown and unexpected risks that are often outside of their control, the team created Cyber Exposure Insights…

Topic updates

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