Part 2 – Architecture overview
Standard SOC
Let’s have a look at standard Security Operations Center on picture 1. This only simplistic representation of technology and organization domain. As you can see on in the Technology domain, there is usually a SIEM which is also often considered as a core component or the heart and soul of a SOC. Then we have Big data platform for multivariable historical searches. In some cases you can consider data lake or log management solution as a big data platform. More and more you can see incident response platform in the SOC for SOAR tasks. Ticketing tool is usually already utilized organization-wide ticketing system to issue tickets for IT and other departments and request changes. Very broad term is Enterprise Security Tools (EST) which includes antivirus, network firewalls, EDR, database protection tools, web application firewalls and many more security protection tools. Those are usually log sources for a SIEM platform. Last example is CTI platform which for our purpose we can simplify to providing threat information to other security tools. There might be many more tools like use case database, automation tools, customer portal, reporting tool etc. but for now we can be ok with this example.
From the Organization domain we can usually see a large number of L1 or Tier 1 staff. They are responsible for monitoring SIEM alerts, close false positives, enrich context, check duplicates, update severity and escalate. I am sorry to tell that, but those tasks are not very exciting and that’s why we see a high turnover rate in this role or bored people which lead to another problems. Then we have L2 role. Those guys should perform technical root cause analysis and decide if the alert was caused by a technical problem, mistake or it was an incident caused deliberately by an attacker. L3 role is responsible for business impact analysis and determine recovery priorities. The role description is very brief because it makes no sense to talk in detail about them, but if you want to know more, you can find some useful information for example in this article. Next we have SOC platform admins. Most of them are designated and responsible for maintaining the SIEM. And of course, Security Intelligence which in our case cover roles like cyber threat intelligence, threat hunting, forensics, use case developers and others.
Picture 1 - Standard SOC setup, technology and organization only
Different representation of a SOC organization could be seen on Picture 2. Statement within the parentheses means number of employees in each department and in SOC itself. This example could be considered as a mid/large sized SOC with 24/7 monitoring by L1 and L2 working on a shifts (3 shifts a day) and L3 covering 2 shifts.
Picture 2 - SOC organization example with employee numbers
Returning to technology layer, we have mentioned that Enterprise security tools are log sources for our SIEM platform. That means they are sending logs and alerts to SIEM which should correlate those events and produce SIEM alerts/offenses/incidents. In SIEM we can also check matches against our threat feeds that came from CTI platform. Then we can directly raise an incident in our IRP or after first level of investigation done by Tier 1 analysts. Both options have their pros and cons. After all the investigation, automation, orchestration tasks in IRP we can create ticket (if needed) outside of SOC to perform specific changes/tasks on the infrastructure that doesn’t fall under SOC responsibility. This straightforward and simplistic view is indicated on Picture 3 below.
Picture 3 - Information flow, standard SOC
SOC without SIEM
What would happen if we remove the SIEM? Nothing! Let’s do it!
It is not that easy. In that case we have to forget about sending logs and alerts to SIEM. Instead we have to send only alerts to IRP directly. That creates higher demand on the Enterprise Security Tools (EST). They must have the capability to create rules and generate alerts. But most of the current enterprise level tools can do this respectively their management module can. One can argue that he will rather manage one SIEM platform rather than 30 other tools to generate alerts. Agree, but you have to manage those tools anyway. It is usually easier to create rules directly on EST than trying to create them from logs in SIEM. Because this task is difficult, companies usually have very generic and simple rules based on logs in SIEM.
Removing SIEM increases demand on high quality rules with low false positive ratio that must be implemented directly on the EST. Also, the integration between EST and IRP is more complicated when no common security alerting format (CSAF) is present. But if you can achieve this you can focus on the automation and orchestration part in the IRP. In ideal scenario you can automate all the tasks done by the L1 staff. So let’s remove them and have only L2 and L3 for the investigation.
I have to admit that this is not directly related to removing SIEM. You can achieve full automation of L1 tasks even with SIEM and properly configured IRP, but the reality is that SIEM creates so much false positives and unpredictable situations for which you usually have L1 like eliminating false positives and filter out log source outages, parsing problems, decommissioning issues etc. In the end, removing SIEM will help you to eliminate L1 role significantly.
Next we can remove SIEM admins and focus on other tools, integrations, automation and orchestration. Sounds good, right? Finally, we can utilize SIEM use case developers to work closely with EST administrators to produce high quality, low false positive rules. In the end we can have half the people or even less in our SOC. This is great because finding good security people to work in our SOC is one of the most challenging tasks. How the structure can look like and what could be the impact on number of employees is illustrated on the Picture 4 below.
It is not that easy. In that case we have to forget about sending logs and alerts to SIEM. Instead we have to send only alerts to IRP directly. That creates higher demand on the Enterprise Security Tools (EST). They must have the capability to create rules and generate alerts. But most of the current enterprise level tools can do this respectively their management module can. One can argue that he will rather manage one SIEM platform rather than 30 other tools to generate alerts. Agree, but you have to manage those tools anyway. It is usually easier to create rules directly on EST than trying to create them from logs in SIEM. Because this task is difficult, companies usually have very generic and simple rules based on logs in SIEM.
Removing SIEM increases demand on high quality rules with low false positive ratio that must be implemented directly on the EST. Also, the integration between EST and IRP is more complicated when no common security alerting format (CSAF) is present. But if you can achieve this you can focus on the automation and orchestration part in the IRP. In ideal scenario you can automate all the tasks done by the L1 staff. So let’s remove them and have only L2 and L3 for the investigation.
I have to admit that this is not directly related to removing SIEM. You can achieve full automation of L1 tasks even with SIEM and properly configured IRP, but the reality is that SIEM creates so much false positives and unpredictable situations for which you usually have L1 like eliminating false positives and filter out log source outages, parsing problems, decommissioning issues etc. In the end, removing SIEM will help you to eliminate L1 role significantly.
Next we can remove SIEM admins and focus on other tools, integrations, automation and orchestration. Sounds good, right? Finally, we can utilize SIEM use case developers to work closely with EST administrators to produce high quality, low false positive rules. In the end we can have half the people or even less in our SOC. This is great because finding good security people to work in our SOC is one of the most challenging tasks. How the structure can look like and what could be the impact on number of employees is illustrated on the Picture 4 below.
Picture 4 - SOC organization without SIEM
We should mention that in this scenario where we have removed SIEM we have new requirements for our Enterprise Security Tools. Not only they should be able to create rules and generate alerts that can be sent to IRP, but also they should be able integrate with CTI platform as you can see on the Picture 5. That means that EST should be able to send their internal threat feeds (indicators of compromise) to CTI platform or ingest central repository of IoCs. For some protection tools this is not a standard. That’s why the arrow on the picture bellow is dashed. To be fair, this feature is more important for tolls like firewalls, web and email gateways rather than identity and access management tool. And we could find more examples.
Picture 5 - Information flow, SOC without SIEM
At the end this setup is more complicated on the EST side, but if you invest slightly more in this area, you will have much better preventative mechanisms with detective capabilities. Also, the savings on SIEM technology and associated work force will be much more. If you move the detection on the Enterprise Security Tools you can directly block/stop the attack when detected. When SIEM is responsible for detection it creates a delay because SIEM is not usually capable to stop the attack. It is only passively processing incoming logs/flows. Typically, SIEM alerts analysts or Incident Response Platform and then the action can take place. But this delay can be fatal.
If you have a feeling that I am telling you to stop collecting logs, you are wrong. Please, don’t confuse log management tools with SIEM. It is very common mistake that SIEM is used primarily as a log management, but this is silly and expensive. I can definitely recommend collecting and keeping your logs. They are priceless. Continue using your log management solution, data lake or big data platform. Just try to forget about SIEM
So what is your experience with SIEM? If
you think it is costly, complicated, high performance demand tool with
little value added, would you consider trying to live without it? It
seems that this setup has only advantages: cost savings, better
prevention, simplified SOC organization structure. If you decide to
remove SIEM or to design your SOC without it, let me know. I can offer free solution and support for the first one to try. I am kidding. The maximum you can get is minimal discount ;-)
If you have a feeling that I am telling you to stop collecting logs, you are wrong. Please, don’t confuse log management tools with SIEM. It is very common mistake that SIEM is used primarily as a log management, but this is silly and expensive. I can definitely recommend collecting and keeping your logs. They are priceless. Continue using your log management solution, data lake or big data platform. Just try to forget about SIEM
