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.