5 things you should know about SOC

before you decide to invest in it

 

We want to build our own SOC! This is usually first sentence I hear from customers when I ask them about the purpose of the meeting. The more I speak to them the more I have a feeling that they want to have SOC on one click, fully capable from tomorrow and with belief that their employees can do the job together with their current roles. Honor to the exceptions, but as a see SOC becomes trendy buzzword, lot of companies has the feeling that they need to be part of it, no matter what it means and what it costs.

I could be more than happy with this trend and approach. Being a SOC consultant during those days is pretty comfortable, but there is always a dark side of the moon. Customers have non-realistic expectations, we are trying to speed up the delivery as much as possible spending the days and nights on the customer side and the result is that at the end we are super tired, the SOC staff is angry to spend so many overtimes with us, they are usually unable to adopt new methodology in such a short time. At the end customer spends a lot of money and the outcome is some kind of mutated combination of our methodology and customer SOC staff habits and belief. This is usually far from what we had presented before and what customer expected.  

So, if you are considering building your own SOC or to bring some new capabilities into current one, let me share a few words and answer some questions that will help you to better understand the effort needed and align the expectations with reality.

What is SOC? You can find general terms like: “SOC detects, prevents and responds to cybersecurity threats that matter. SOC has the technology, processes, organization and governance needed to detect, prevent and respond to a wide range of cybersecurity threats.” But for me SOC is the last piece that help us to “close the security circle”. You can constantly control organizational policies and processes that is otherwise controlled only during audits. You can detect and respond early to an insider threats, effectively monitor your administrators and many more. In one sentence, SOC is a way how to make security better, smarter, detect faster and respond accurately.

Bellow you can find answers to the questions I usually receive when I talk with executives.

How long does it take to build basic capabilities? Well it differs from organization to organization and industry to industry, but usually it is from 6 to 12 months. We should mention what we consider basic capabilities. From the job roles it is L1, L2, L3 analysts (sometimes L1, L2+ ), Security intelligence and governance. From technology we count SIEM, ticketing system and some kind of use case library (usually Excel sheet at the beginning). And then use case development and incident response processes. One can argue that 12 months seems pretty long, because ticketing system is usually within the company and you can deploy the SIEM within a day. But the most important are people. If you have them they still need to adopt and adapt to new processes. Not only learn them but also gain experience. Analysts needs to undergo few offenses/incidents to understand what is expected from them. Security intelligence guys has to develop quite a lot of use cases for different technologies and applications so they can assign right urgency, priority and develop really valuable organization specific use cases.

If you want to know more about roles in mature SOC roles, please see the article in here: Does it make sense to build my own SOC

How much does it cost? A lot. But in case you are not able to detect incidents, it will cost you even more. To answer how much it cost you need to know your environment. If we start with the bare minimum that we mentioned above, we have 6-10 people (not 24/7 operations) and SIEM. Let’s do not count the cost of ticketing system to achieve better results :-). Calculate the monthly cost for a security professional in your country and the costs for a SIEM. In that case you need to know the expected number of EPS, FPM or number of indexed data to estimate the costs. If you don’t want to stop with the basic capabilities, you should count some more security professionals and tools like incident response and big data platform, automation tools, cognitive analytics, etc. In that case it is better to ask somebody who has made the calculation before.

Is it worth it? You have to decide if you take the risk or you try the SOC journey. But once you start the things will start to make sense and the “security circle closes”. All your policies and settings can be monitored, permanently and online, not once a year during audit. You will unveil “suspicious admin behavior”, configuration mistakes and many more. Over all it will help you to come up with better solutions, understand your complex environment thoroughly and create policies and security settings that make sense, are applicable and enforceable.

My own, outsourced or hybrid? There is no silver bullet or universal answer for this question. It depends if you are able to find the right people or not. How fast you need to start, which roles you want to keep in house and which you can outsource, but I quite like the hybrid solution. If you are able to define your use cases and describe the incident response steps that should be performed, you can outsource L1 analysts. If you are struggling with use case development bring some professionals from outside and help your people grow. If you have no experience and idea, start with fully outsourced SOC and observe what you don’t like and then bring the key roles and responsibilities in house. But to answer this question it is always better asking somebody with the experience to help with the strategy and roadmap.

When can I have mature and fully capable SOC? I don’t want to scare you too much, but in a standard organization it is not sooner than 3 years. To consider SOC mature you should use information about vulnerabilities and risks, network forensics, big data analytics and processing unstructured data, fraud management, predictive threat management and many more.  In fact, SOC is never ending story. If you have optimizing SOC, you are continuously looking for improvement in processes, new metrics, dashboards that will help you to decide, manage and respond to a threat. Also, the threat landscape is and will be evolving so once you start you will be never done. But is an amazing and exciting journey.

Does it make sense to build my own SOC

Let’s assume that you have decided, or you were forced to build a Security Operations Center (SOC) in your organization. Now you should identify if it should be fully outsourced, hybrid or completely in-house solution. To make things a bit simpler we won’t be focusing technology layer (tools, appliances, software etc.). If you want to know more about this topic, you can find some useful information in this article: 5-things you should know about SOC. For now, let’sconsider technology layer as a must have and it only depends if you want to account it as a CAPEX or OPEX and focus on the people and roles.

In the bellow list I would like to introduce roles that you can usually find in mature Security Operations Center with a short description of their key responsibilities. Finally, I will elaborate if the role is typically in-house or outsourced. 

SOC roles 

 

Operations:

·      L1 Threat monitoring – first to receive alert/offense, responsible for checking false positives, enrich context, check duplicates, update severity, escalate. All those activities are usually performed based on “runbook” also known as work instruction. This role is commonly outsourced.

·       L2 Threat triage – if the alert/offense is escalated, those guys should perform technical root cause analysis and decide if the alert was caused by a technical problem like misconfiguration, mistake or it was an incident caused deliberately by an attacker. This role is beginning to be more and more outsourced than it used to be. 

·      L3 Threat response - if the alert/offense is escalated this role usually perform business impact analysis, determine recovery priorities, review security intelligence, enrich incident. Usually in-house, we can see hybrid setup as an emerging trend with some L3’s in house and some outsourced. Completely outsourced role when SOC is outsourced completely as a service.

·      CSIRT and CSIRT management – if CSIRT is part of the SOC as the name imply this role is responsible for incident response, forensic handling and emergency response if not considered as a separate role. If CSIR is a separate department it is a good practice to have CSIRT management within SOC to closely work with L3 guys, SOC management and other SOC roles to synchronize the activities between SOC and CSIRT and speed up the process of transition from detection to incident response activities. CSIRT is rarely outsourced, but consulting support is commonly available.

·      Emergency Response Team (ERT) – some companies have ERT within CSIRT some companies prefer ERT as a separate. Having ERP as a separate role it can imply that company has this role outsourced and using highly skilled professionals to help with major incident support.

·      Security intelligence – this role can be very broad and consist of another sub-roles/functions like Threat hunting, Use case management, IOC management, Active defense (honeypots and honeynets, decoys). The key responsibility is to develop high quality use cases and the above mentioned roles helps to further improve, target the use cases or tailor to the organization needs. This role is typically internal. You can also see hybrid setup with few internal and few outsourced professional. When you are building SOC this role is sometimes contracted as interim with knowledge sharing to internal employees. 

·      Security analytics – this role can be also considered as a data scientist. Their task is to work with big data and big data platform, do data munging, create dashboards and reports, screen threat feeds. This role can be partially outsourced, contracted as an interim with transition to internal staff in long term. The target state is to have this role in-house if you don’t have completely outsourced SOC or SOC as a service.

·      Security integrations – people in this role are responsible for integration of outcomes from vulnerability scanning, vulnerability management, penetration testing and similar. They also try to identify preventable incidents and offer changes to the infrastructure/application to avoid those incidents. Typically, internal function or contracted interim with transition to in-house as a target state. 

·      Development and support team – this role is responsible for rule development (transferring use cases into rules in SIEM), tool integration (SIEM with incident response platform, ticketing system, EDR and many other), device onboarding (typically sending logs and information to SIEM, Big Data platform), SOC device management (SIEM, Big Data, Use case library administrators ...). This function is commonly outsourced.

Governance or management:

·      Service level management – person responsible for tracking and monitoring SLA and whether business objectives are met. This function is usually internal, but could be also provided as part of a managed security services.

·      Service reporting and escalation – person responsible for reporting to executives and escalations (IT, OT cooperation,...). Typically internal function.

·      Operational efficiency – person responsible for collecting and evaluating metrics like CPI (cost per incident), CPA (cost per alert), CE/AE (collected events/analyzed events). Typically internal function.

Very often in small to mid sized SOC these 3 roles are performed by one person, usually SOC manager itself.
 

I hope this article was informative and help you to understand better which roles and capabilities are usually within SOC. Now you can start designing your own SOC and imagine which roles will be performed by your internal employees and which roles will be outsourced. It is obvious that this is not enough to create detailed design of your SOC. There are many aspects that needs to be considered like monitoring 24x7 or 8x5, budget, organization structure and possibilities, target SOC maturity and phases how to get there, but I believe it is a good start.