Last Updated on

Reading Time: 3 minutes

Experts agree: if you want to set your Security Information Event Management (SIEM) program up for failure, configure the SIEM tool to alert on a huge range of event data. Then good luck finding the signal amidst the noise.

This and other key considerations for SIEM deployment were covered in a recent episode of The Virtual CISO Podcast, which features Pivot Point Security’s CISO and Managing Partner, John Verry, speaking with Danielle Russell, Director of Product Marketing at AT&T Cybersecurity.

It’s a widespread misconception that a SIEM can “… automagically help us to do good threat detection and incident response,” says Danielle. “It’s a means by which you can detect and respond to threats, but there are so many other elements that come into play.”

These “elements” in large part are the logs and other data and events that your SIEM captures. That could include a range of heterogeneous data sources, such as firewalls and other security devices; routers, switches and other network hardware; servers; applications (including cloud applications) and more.

What data should your SIEM gather?

That’s “… a big ‘It depends,’” Danielle quips. “… It’s good to start with the question of risk.”

“The question that I think an SMB could start by asking is, ‘Where is our sensitive information?’,” Danielle continues. “’What is that information or that data or those systems or processes that we simply can’t afford to lose or we simply can’t afford to be breached or to be exposed?’”

Those assets that are transmitting, storing and processing that critical data are what SMBs should be monitoring “first and foremost,” according to Danielle. “It’s a matter of risk and criticality and from there, it’s a question of just how much makes sense for your organization.”

To decide how much data is enough and how much is too much, Danielle recommends striking a balance between what’s vital to protect and the level of bandwidth and automation you have to process the inputs. “Some SIEM providers and security analysts might have the impression that more data is better, and so we should collect all of the information that we can, good or bad, dump it into a SIEM and then start searching through it looking for trends, looking for correlations, looking for anomalies.”

“For most organizations, that is just creating that environment where you’re looking for needles in a big haystack,” emphasizes Danielle.

John couldn’t agree more:

“I’ve been involved in a lot of SIEM projects over a lot of years. … If you look holistically across all of those projects, many of them failed, and the reason that they failed was exactly what you just said—‘We got a SIEM; let’s dump all the data we can into there.’ It becomes an endless log consolidation process.”

“We never really get to what the objective was,” John clarifies. “What risk are we trying to mitigate? What compliance are we trying to prove?” What is it that we’re looking to actually accomplish? What’s the objective of implementing the SIEM?”

In other words, let your core security goals and business drivers set your priorities for what data you most need to correlate in your SIEM. Start at a manageable level to support success, and expand your data collection as you go, if a wider swath of input is needed or desired.

This blog post is based on an episode of The Virtual CISO Podcast, featuring Danielle Russell. To hear this episode in its entirety and many others like it, you can subscribe to The Virtual CISO Podcast here.

If you don’t use Apple Podcasts, you can find all our episodes here.

Penetration Test Trail

When your network goes through a penetration test, it’s a little like taking a journey on The Oregon Trail… Think of your network as an eager adventurer looking to prove its prowess and demonstrate to its administrators that it can “securely” traverse the treacherous terrain of today’s threat landscape.

Download our Penetration Test Trail now!