Remember the show I Love Lucy and the skit in the chocolate factory? Lucy and Ethel can’t keep up – the faster the conveyor belt, the more chocolates to wrap. It kind of reminds me of the challenge many security professionals face – the more logs in a security information and event management (SIEM) system, the more alerts to triage.

Given the volume of indicators published daily and the volume of log data available, you’re fooling yourself if you think you can funnel threat intelligence directly into your existing SIEM or ticketing system and get the results you want.

For more accurate and relevant insights into threats against your organization, you need to consider a threat intelligence platform (TIP).

As a relative new kid on the block (TIPs have come to the forefront in the last couple of years), it is only natural that customers are wondering how a TIP fits into their overall security strategy and respective budget planning. I thought it would be helpful to provide insights into the varying roles of SIEMs, ticketing systems, and TIPs.

The Role of the SIEM

SIEMs have been around for decades, designed to replace manual log correlation in order to identify suspicious network activity by normalizing alerts across multiple technology vendors. SIEMs correlate massive amounts of data from your sensor grid (your internal security solutions, mission critical applications and IT infrastructure). Today that can exceed several terabytes per day (or even petabytes for far-reaching global enterprises), creating scalability and performance challenges when intersected with intelligence.

As with every traditional technology riding the coattails of the “threat intelligence” buzz, SIEMs can do some limited IOC monitoring but fall short as they are purely a tactical correlation engine. SIEMs also lack the necessary data retention to effectively utilize threat intelligence.

In my experience running SOCs, most SIEMs only analyze/correlate one month’s worth of recent activity; anything older is archived.

But as we all know, attacks can slowly evolve over months and as an analyst having that historical data is the fulcrum of a successful threat hunting mission of identifying adversarial patterns and trends.

Another often overlooked aspect, because SIEMs are priced by throughput (whether by number of log sources or the volume of logs) most organizations economize by only funneling “budget friendly” or critical alert logs into the SIEM. [Budget friendly logs are logs that do NOT produce superfluous volumes, i.e. DNS logs or endpoint logs.] This practice, sadly more common than you think, means that threat intelligence that is funneled exclusively into the SIEM will only serve to validate or nullify an attack that has already been “detected” in alert logs. Malicious activity occurring below the alert radar will remain undetected. Years of high-profile intrusions have proven that commercial rules/signatures/etc. don’t work as well as intended, particularly when it comes to stopping advanced and emerging threats.

And, finally, SIEMs are primarily a one-way consumer of information – taking logs in but not distributing critical information to the “worker bee” sensor grid. SIEMs can push data to ticketing systems to pre-populate fields but there’s no refining of detections based on SIEM alerts – an effort left to analysts. SIEMs do play an important role in security, beyond compliance and regulatory checkboxes, but they also have serious limitations when organizations are forcing a round peg into a square hole by trying to leverage them for their threat intelligence reporting.

In my next post I’ll discuss the role of ticketing systems, and explain how a TIP is purpose built for threat intelligence and complements your SIEM and ticketing system so you can get more from your existing resources.