Security Experts:

Shall We Play a Game? It's a SIEM-ple Question.

A simple question that led to a SIEM-ple solution. Well, maybe not so simple.

To understand SIEM (security information & event management), it’s important to first understand when people started to care about network security. And to do that, we need to take a step back in time. 

So c’mon, hop on into my sweet time machine. We’re going back to 1983. When Donna Summer was working hard for the money. Duran Duran was hungry like the wolf. And Matthew Broderick had yet to twist and shout, but was, instead, hacking his way into a military supercomputer. 

Yes, it was 1983 when WarGames was released—mere months after President Reagan had announced the Strategic Defense Initiative (aka Star Wars), an anti-ballistic missile system aimed at countering the Soviet Union’s intercontinental ballistic missiles (ICBMs). Not only did the film make box office bank, but it also made Reagan question: Do I even need to suspend disbelief? Is this plausible?

WarGamesIn fact, it was. As told in Fred Kaplan’s Dark Territory: The Secret History of Cyber War (published earlier this year), the film’s premise proved not so far from reality after all. And though in 1983 mainframes were king, it was at about that time when the network began to take hold (e.g., DARPA had a “network”). With a quick VCR fast-forward in the time machine, let’s jump to 1994 when SSL was invented, the World Wide Web began to take off, and more and more folks realized that this new and vast online realm was ripe for monetization—and exploitation. And as soon as there was value, there was something that needed protection. 

Cue slow-rolling cybersecurity ball to pick up speed.

SIEM – Act 1

Okay so maybe that story isn’t solely applicable to SIEMs, but it gives a (very) quick progressive overview that leads to the creation of the first SIEMs. See, as all manner of security products—antivirus, firewalls, IPS, IDS—began to hit the market, the IT teams using them began to experience management nightmares. They were bombarded by alerts, buried in logs, and they needed to find some form of adjacent technology to help reduce the deluge of IDS and IPS events. 

Well, what better than a SIEM?

Early SIEM technology was developed to reduce the log noise coming from existing security devices by deciphering signal from noise. Unfortunately, these first-generation SIEM products were disappointing—renowned for being complex, unscalable, difficult to integrate and tune for effective alerting, and overly sensitive. So the very tools that had been conceived to save security analysts time were actually creating their own time-consuming management issues. Everything still seemed to raise a red flag and alerts continued to flood people’s inboxes. 

While these tools were good at finding what they were told to find (e.g., This + That + The Other Thing = Alert), security teams really needed a way to uncover unknown risks. Though less a technology and more a process problem, the disparity between requirement and reality meant that SIEMs weren’t a viable security option and, in relatively short order, they were relegated to compliance reporting and forensic analysis. Sure, an organization, if attacked, could still search on the log and event data stores of its SIEM—instead of various devices—to figure out what happened and to help pinpoint information on the attack. It just wasn’t ideal. And it was after the fact.

SIEM – Act 2

If at first you don’t succeed . . . 

Today, it’s almost a fait accompli that the bad guys are breaching perimeters and establishing footholds within networks. This rise in advanced persistent threats (APTs) has led to a shift in focus from prevention to protection and, in turn, a re-emergence of SIEMs. These tools are not only getting back to their security roots, but, in many cases, are becoming a cornerstone of security strategies. 

While traditional SIEM tools may continue to work hard at maintaining compliance, next-generation SIEMs have been purpose-built for high-velocity data input and storage. Formerly broken or inadequate processes are seeing improvement. In SIEM Act 2, metadata, in particular, is taking a lead role to improve visibility, streamline analytics, and enable security analysts to perform more effective and scalable data mining and interpretation of user behavior.

With metadata, it’s not necessary to send every data packet to a SIEM. Instead, analysts can choose to send very specific high-value, low-volume metadata—URL, DNS, SSL certificate info, HTTP/HTTPS response codes—for real-time security analysis. It comes down to being able to go to numerous and varied data sets with a specific problem, pull out the data relevant to that problem, and create single highly enriched summary records that go to the SIEM (the aggregation point baked into the security stack) for real-time situational awareness and anomaly detection.

The game has changed. While in 1983 WarGames may have concluded that the only way to win was not to play, today’s organizations don’t have that choice. They need to play online. And, luckily, SIEMs are back in the security game.

view counter
Erin O’Malley is an incident response delivery support manager at Accenture Security, FusionX, Cyber Investigation and Forensics Response (CIFR), where she teams with incident responders and threat hunters to document and catalog incident report findings and highlight the value of taking an adversary-based approach to minimize the risk, exposure, and damage of cybersecurity incidents. Prior to joining Accenture, Erin was a security solutions marketing manager at Gigamon. Other past roles have included product marketing for virtualization and cloud security solutions at Juniper Networks and customer marketing at VMware. She has written and edited for GE Digital, WSGR, Business Objects, and the TDA Group, and holds a B.A. in French from Penn State University and an M.A. in French from Middlebury College. The opinions and statements in this column are solely those of the individual author, and do not constitute professional or legal advice, nor do they necessarily reflect the views of Accenture, its subsidiaries, or affiliates. No representations or warranties are provided, and the reader is responsible for determining whether or not to follow any of the suggestions or recommendations, entirely at their own discretion.