SOC without SIEM - idiocy or future? Part 1

Part 1 – the idea

Are you using SIEM within your SOC or security department? What is the value added it brings to your organization? What is the effort needed to keep the SIEM up to date, running and creating new monitoring scenarios, searches and dashboards? If your answer is low value added and enormous effort, you may find this article interesting. In other cases, you can consider this article stupid and author pathetic.

Organizations are using SIEM as log management solution very often. This makes no sense, because there are log management solutions that are cheaper and perform log management tasks better/faster than SIEMs. Long story short, if you do not need real time correlation capabilities and you really only need a log storage and searching capabilities, do not buy SIEM.

Now let’s assume that you need SIEM and you have one. Perfect, but organizations often have problems to define monitoring scenarios for SIEM. And if they do, those scenarios are very basic ones. It is no surprise that for situations like audit log cleared or multiple login failures could be also easily monitored by other means than SIEM. You can configure your EDR solution or antivirus to inform/alert you in case such situation happens. Access to prohibited web sites? Phishing email? Your email or web gateway should alert you. Why to transfer all the logs from those devices to SIEM and integrate the threat feeds that are already available in you gateways? One can argue that this could be useful to verify gateways are working as intended. Really? This is similar approach to another funny monitoring scenario which is monitoring firewall denies. Again, you are basically verifying that FW works as intended. And if you argue that you can evaluate trends and number of FW denies in that case, fair enough, but you are not able to monitor this directly on the firewall or FW control center? If not, you should consider replacing your current firewalls. In the end it will be cheaper than the SIEM technology and improve you prevention mechanisms a lot.

You want to monitor organization internal policies? Unauthorized access, sharing of information, downloading of sensitive files? That’s why DLP exists and it can produce very nice alerts by itself. If you are trying to make your own DLP solution within SIEM, good luck.

What I have also seen in many cases that SIEM is used like centralized tool for alerting? What do I mean by that? IPS is producing alerts, NGFW is producing different alerts, DB protection tools with its own rules is producing another type of alerts. All those types of alerts are transferred to a SIEM solution and each of them is just one to one mapped to an SIEM alert? Does this make sense? Do you need powerful SIEM solution with all those correlation capabilities to make such a simple task? Isn’t this one of the reasons why do we have IR (incident response) tools?

Let’s remove SIEM and have everything in incident response platform! I wish it is so easy. One can argue that in SIEM you can eliminate false positives. Agree, but you should be trying to eliminate the generation of false positives as close to the source as possible. Actually, what you can see in many of the implemented SIEMs they are producing mostly false positives which leads to “alert fatigue”. Analysts are then bored with investigating the same alerts again and again. In the end true incident is often missed because of the flood of false positives so in that case SIEM is not our silver bullet either.

I can only recommend eliminating the false positives on the source itself either by the configuration change on the source directly or on the first security platform that protects the source. If you transfer the false positive to SIEM then you are paying for the license (EPS, storage) and for the time to analyze and close the case.

Often you will also find easier to implement monitoring scenario in EDR or NGFW because you usually have experienced administrators familiar with the technology and within few clicks you can have well defined, fine-tuned rule that will alert you in case conditions are met. When trying to implement the same in SIEM, you need to have specific logs from source. You need to understand those logs and know where the information is present. Then you should know how to implement the rule in SIEM and then you are praying logs are still flowing to your SIEM and format hasn’t changed after update/patch. This requires much more cooperation and knowledge, but the output is the same.

In previous paragraph we have touched the problematics of integrations. With SIEM it starts with log source integration. Format, transfer method, parsing, normalization. All of those needs to be monitored, updated, evaluated after updates/patches both on SIEM and log source side. Enormous effort with little value added and unavoidable problems/outages.

But the same will happen if we skip SIEM and send only alerts to incident response platform. Agree, that’s why I consider this setup as a future. Something like common security alerting format (CSAF) should be defined to ease up the implementation and more focus and investments need to be devoted to other prevention and detection technology.

How would SOC without a SIEM look like? How it will influence the SOC organization structure? Let’s try to imagine this in the next part of our article.

At the end I should give 2 valid arguments why organizations need SIEM solution.
One is that you need SIEM to correlate events from endpoints with firewall events, traffic flows and compare it against information from CTI platform. Yes, agree, but honestly, I have never seen an organization with such advanced monitoring scenarios. Usually, you define suspicious activity based on logs or flows itself. It is not a good practice to create complex scenarios where you chain activities to produce an alert. You may miss an alert in case of small deviation from the defined chain of actions. Also, you can check CTI information from IRP if integrated. But yes, in general, that is one valid argument.
Second is. WTF, we have 20+ people in our SOC. Majority of them put their blood, sweat and tears to make SIEM work. We are investing enormous money and effort to operate SIEM. We can’t simply get rid of it. We and CISO would look like idiots in front of the executives. And that I believe is the correct argument why you should keep the SIEM and consider SOC without a SIEM as a pure idiocy.