Network Security
Vulnerability Management
Privileged Access Management
Endpoint Security
Threat Hunting
Unified Endpoint Management
Email & Collaboration Security
Contents:
In an ideal setup, statistics should favor the defender and not the attacker. However, since cybersecurity, as a whole, is a less than ideal environment, most of the time in accord with its made-up rules, the roles tend to become somewhat interchangeable – defender becoming attacker or rather appropriating the mindset of one in order to create new defense strategies; same thing can happen in the case of an attacker – what better way to outsmart the defender than turning into one? Threat-hunting has its own bargaining chip – intelligence. The more you have (or gather) the better you can predict an impending attack or mitigate the aftereffects of one. In this article, we’re going to deep dive into the world of intel by talking about two emergent approaches – SIEM vs Log Management. Without further ado, let’s make the presentations.
What Is SIEM?
SIEM stands for Security Information and Event Management and it’s the next best thing after Windows’ Event Viewer. Now, I won’t go into specifics with SIEM since my colleague has already covered this topic, but I will mention the fact that every SIEM is a (software) tool stack that allows the defender to gain actionable endpoint-based intel about a specific event or an event chain. However, it’s far more than an event viewer tool – SIEM systems allow you to form strong hypotheses based on log data, correlate certain types of events, retrace the attacker’s steps, aggregate and decipher logs retrieved from different sources, each with its own format and encoding. Another thing that you should keep in mind is that every SIEM you might come across is security-centric. You’ll see why this is important later on in the article. This covers the SIEM part. Now, let’s take a (closer) look at log management.
What Is Log Management?
Every time “log management” pops out, “Every Breath You Take” by The Police starts ringing in my ears. Just like in the lyrics, everything you do on the machine gets logged. Even me writing this article will eventually produce one or more log entries. So, what exactly is a log? In computer sciences, a log is a computer-generated file that encompasses information pertaining to user- or machine-initiated activities. Based on this definition, everything going on in your computer generates a log file. This includes applications, containers, databases, web services, operating systems, kernels, web services, and so on. And just to keep things interesting, each log-generating entity can produce different kinds of logs.
The most common are event logs, files that keep track of notable events that occur during the app’s or component’s ‘work hours. For instance, Microsoft Windows’ Event Viewer can produce event logs pertaining to application ops, security, setup, system, and forwarded events. Apart from event logs, we also have server logs (i.e., records server-specific activities), system logs (i.e., records OS-specifics activities), authorization or access logs (i.e., records activities related to authorization/authentication processes and/or systems), change logs (i.e., records changes in application or service), resource logs (i.e., used to keep tabs on activity related to connectivity or network capacity), and, of course, threat logs, an all-time personal favorite. Threat logs aka the log files that record security-related activities are essential in both SIEM and log management.
Anyway, getting back to the topic at hand, the whole idea behind log management is to find a way to read, display, store, query, and analyze logs, regardless of their source, size, or contents. Sounds easy when you say it like that but, in reality, ‘log-reading’ is quite challenging. First of all, each log-producing entity, be it an application, system, server, or firewall, has its own log-scribbling style. Here’s a quick example.
The picture above represents a generated student log file, detailing each operation he performed while working on the machine from log on to log off. This log has two views: a detailed view, with timestamps to indicate the student’s actions at certain points in time, and a summarized view. As straightforward as they come. Now take a look at this next log file.
Kind of resembles the previous examples, except for the code lines. We have timestamps and dates, but the information it stores is completely different. This is a log file pulled from Monkey Test’s DummyTest utility and is used to register, in text form, cursor interactions with various map elements. You get the idea: a ton of apps produces a ton of log files. So, with this out of the way, let’s see who’s the winner in the SIEM vs Log Management competition.
SIEM vs Log Management
Let’s start by outlining the pitfalls of each approach. In log management, the most obvious challenge is volume. With every application, service, component, and database spewing out logs each odd second, even the most seasoned admin can easily get overwhelmed. The volume also leads to another challenge – storage. Do we have enough space to store this volume of information? Should we store all of it? Can we drop some of these logs? These questions will invariably pop up when you have to deal with this much info. So, how much is ‘too much’? Well, according to an event log management article by Progress, an enterprise is capable of producing up to 4GB of log data per day. And yes, that’s a lot; by comparison, a 30-page eBook takes up 55 KBs. To get around all of these issues, log management was concocted.
Its primary purpose is to handpick these logs, figure out their sources, and find a way to homogenize them. Having logs around is very useful for all kinds of purposes: to investigate incidents, see what your employees are up to, trace a defective application component, conduct internal audits, etc. However, somebody’s got to go through all this data in order to sort things out. Unfortunately, log management is the type of job that can’t be automated mostly due to the fact that all the puzzle pieces need to the shaped out ‘by hand’ to fit the big picture. Enterprises leveraging log management for activities such as internal auditing, compliance, threat-hunting, incident response, and investigation will usually assign a person or an entire team to this project, depending on its complexity. So, if you’re planning on introducing log management to your company, keep in mind that you’ll need at least one dedicated person.
Before we move on to SIEM, there’s one thing you’ll need to keep in mind – log management is not a security-centric approach. Naturally, the logs curated by such a system can serve security purposes as well, but as a whole, it’s more about collecting and storing info. Okay, now on to SIEM.
Compared to log management, SIEM is all about automation. Nothing about this approach can spell out “manual”. While they cannot perform log management functions, SIEM systems can certainly retrieve them from all corners of your enterprise and leverage this data in order to make correlations between outcomes and event-type actions. SIEM also grants the user extra visibility over events since most of them leverage powerful dashboards and they also aid you in converting all of your collected logs into a uniform format.
Again, most of its features revolve around security, whether it’s for forensics purposes, reporting, connecting events based on data, detecting signs associated with impending attacks, and, of course, helping your company devise powerful data-driven defense strategies. SIEM cannot replace log management in the same manner as log management can replace SIEM. Naturally, having a hands-free solution to cater to your security needs is a thought worth entertaining, especially if you’re running an enterprise spanning several hundred devices.
However, SIEM systems do have their limitations. First of all, implementing such a system is quite a difficult task. More than that, the team assigned to this task must possess the necessary tech know-how in order to ensure that everything’s green across the board. Last, but not least, SIEM systems tend to burn a hole in your budget. So, when chalking up your plan, do try to run a short benefit vs. liabilities analysis before making any decision.
Conclusion
Who won the boxing match between SIEM and Log Management? Well, this may come as a surprise, but there’s no winner here. Both approaches serve different purposes and it’s not unusual seeing them working together. So, if you’re looking for something to store, arrange, and make sense of a great volume of data, you should head towards log management. On the other hand, if you’re looking for a way to leverage intel for threat-hunting, IR, or even mitigation, SIEM should be your number one choice. This about covers my article on SIEM vs Log Management. Hope you’ve enjoyed it! As always, stay safe, don’t click on suspicious links, and keep your cybersecurity software stack up to date.
If you liked this article, follow us on LinkedIn, Twitter, Facebook, Youtube, and Instagram for more cybersecurity news and topics.
