Skip to content ↓ | Skip to navigation ↓

I’ve decided to write this two-part series on a SIEM, based primarily on how often I get the questions: “What is a SIEM?” or “Why do I need this SIEM technology?”

I will answer both questions, and by the time you get to the end you’ll see the SIEM has always been around. We’ve just applied a term, and then began to use the acronym, which has taken on a life of its own.

I really do love being asked what a SIEM is because outside of the textbook definition, I never have the same answer. This is what confuses people because a SIEM is different things to different people. I will get more into that in the planning and design portion of the series.

To give you the simplest answer, SIEM or Security Information and Event Management is defined as a complex set of technologies brought together to provide a holistic view into a technical infrastructure. Depending on who you talk to, there are about five different popular opinions on what the letters stand for.

Looking at the 10 layered security stack by Michael Oberlaender, with the notion of managing all of it, is enough to make you lose your hair! However, it’s not a train – there is light at the end of the tunnel. That light has come to be known as the SIEM.

security stack
The SIEM gives you a holistic, unified view into not only your infrastructure but also workflow, compliance and log management. A SIEM can provide a multitude of capabilities and services efficiently.

At its core, a SIEM provides:

  • Event and Log collection: This may come in many forms, especially with in-house applications.
  • Layered Centric Views or Heterogeneous: This is usually in the form of dashboards or “views,” referred to as a bird’s-eye view.
  • Normalization: a two-part function. This includes translating computerized jargon to readable data to be displayed, and mapping data to user- or vendor-defined classifications/characterizations. This is sometimes referred to as “field mapping.”
  • Correlation: This essentially gives the data context and forms relationships based on rules, architecture and alerts. This should be either historical or real-time.
  • Adaptability (Scalable): This dumbs down to being able to speak the language regardless of source vendor, format, type, change or compliance requirement.
  • Reporting and Alerting: This may be used to not only show value to executives but also provide automated verification of continuous monitoring, trends and auditing. Some would argue that the auditing aspect is an essential function but the SIEM alone does nothing – like a retired general with no troops or a SQL instance with no tables or data.
  • Log Management: Allowing the capability for storing event and logs into a central location, while also allowing the application of compliance storage or retention requirements. (Again, many would argue this is a separate function, and I would disagree.)

As you can see, the foundation rests on log and/or event data collection. Taking a look at the 10 layers references, potentially, there are different portals, languages (i.e., packets, logs, etc.), methods of collection, drivers, use cases, UIs and often different analysts. Again, SIEM to the rescue…

Within any corporation or even small businesses, there are processes and procedures, which most likely have defined work flows. Let’s use a typical technical support call in any company, any size.

A customer says they are unable to get to the Internet. This essentially means, I am unable to browse to my intended website. Troubleshooting goes through the gambit of layer 1, up to 8. Past that, a number of things could be the cause; meanwhile, going from 1-8, a number of portals, UIs, escalations and personnel are employed towards figuring it all out.

Here, the SIEM can provide everything in one view.  This one view can allow you to hone in on, or focus on your layered view.

data types
Another benefit, is what all your analysts are using, viewing and interacting with the same system, same portal and same dataset. Throw an ITIL wrapper on this, with a clearly defined service catalogue, and it will bring a tear to your eye.

By introducing ITIL, the process above becomes a self-maturing technology, providing continual service and continual improvement. (This I will also touch on in part two of this series.)

Key Takeaways

  • A “SIEM” is defined as a group of complex technologies that together provide a bird’s-eye view into an infrastructure.
  • It provides centralized security event management.
  • It provides correlation and normalization for context and alerting.
  • It provides reporting on all ingested data.
  • It can take in data from virtually any vendor or in-house applications.

I have only nicked the tip of the SIEM, and could go on and on. However, I will follow-up with part two, which we’ll delve much further into what it can do for your organization and why you need it. Until then, feel free to drop any questions in the comments section below!

 

Joe Piggee

About the Author: Joe Piggeé Sr. is a Security Systems Engineer that has been in the technology industry for over 25 years. He works in the eDiscovery and Forensic industries, and is a SIEM specialist and ITLv3 evangelist. He also provides volunteer security awareness, network monitoring, security operations and ITIL training to small businesses and non-profit organizations. I am currently working to achieve my CISSP and CISA.

Editor’s Note: The opinions expressed in this and other guest author articles are solely those of the contributor, and do not necessarily reflect those of Tripwire, Inc.

Title image courtesy of ShutterStock