Save time with unbiased, independent feedback on vendor solutions.
Watch weekly bite-sized webinars hosted by IANS Faculty.
Security operations centers (SOC) are costly and complex to operate. There is no perfect model for all situations, so the decision to insource, outsource or move to a hybrid model is one that is unique to each organization. Key decision criteria include your specific
monitoring requirements, tooling, staffing and expertise, cost concerns, incident response workflows and more.
With that, security teams recognize the significant challenges involved with running an in-house SOC, but also realizes that outsourced and hybrid SOC models offer cost savings due to economies of scale. This piece aims to help InfoSec teams to better
understand the decision factors involved when choosing one SOC model over another, including:
Fundamentally, organizations can use three different models for a SOC:
Organizations might find it easiest to start with a fully outsourced SOC. Many deployment, training and operational challenges come with starting a SOC. It is possible trying to build an internal SOC (or combine existing SOCs from a merger or acquisition)
from the ground up without assistance could result in a lower value proposition than expected.
For organizations that already have an internal SOC and are considering whether to completely outsource or go to a hybrid model, the biggest considerations are the level of autonomy required (higher autonomy favors a hybrid model) and cost (lower cost
favors a fully outsourced model).
If you are building a fully insourced SOC consider the following:
Using an outsourced or a hybrid SOC where the outsourced provider deploys and maintains the SIEM generally mitigates these time and cost overruns. This works if costs are agreed on upfront and the outsourced provider has experience in SIEM deployments,
allowing it to avoid common pitfalls.
The choice of which SOC model to adopt is also driven by several different factors in the organization. While there certainly are other factors that may impact the choice of SOC model, consider the following:
Before deciding on a SOC model to adopt, you should determine your SOC monitoring requirements. For example:
Smaller organizations will typically have difficulties staffing a 24x7 SOC, so if full coverage hours are required, an outsourced or hybrid SOC model will likely work best. As the number of endpoints being monitored increases, however, fully insourced
SOCs can better control costs.
Typically, outsourced SOCs (both fully outsourced and hybrid) price their offerings based on the volume of alerts and hours of coverage. Sending the outsourced SOC more logs mean the organization will pay more money. While there certainly are additional
costs to adding more logs internally, they end up being a very small fraction of the cost of sending the same log volume to an external service provider.
For organizations that require significant volumes of logs to be monitored, the fully insourced SOC model is usually most appropriate. For example, while a fully outsourced SOC can easily monitor for failed logins, data loss prevention (DLP) alerts and
attempts to visit illicit sites by monitoring the web proxy, it is less likely to have all appropriate logs to find execution patterns that might represent attacker activity.
Having access to the appropriate tools and staff is critical for insourced and hybrid SOCs. If the organization can’t hire (and retain) the appropriate staff, the SOC deployment will fail to yield the desired results. Organizations should not only
focus on the staff they currently have, but also their patterns of retention and the market for hiring replacement staff.
Organizations should also consider how their security needs will grow over time and whether headcount will keep pace with those needs. Often, managers find it easier to absorb unforeseen costs as contract expenses (e.g., an outsourced or hybrid SOC) versus
increases to headcount, even when the costs are likely to continue indefinitely. Changes to regulatory frameworks or contracting requirements with customers and business partners may force the organization to change its resourcing requirements dramatically
These changes are easier with a fully outsourced SOC, but they can be least partially mitigated with a hybrid SOC model. In the case of a fully insourced SOC, changes in requirements may outpace the organization’s ability to react quickly, contributing
to missed commitments or employee burnout.
Before choosing a SOC model, you should consider your CAPEX and OPEX needs. Some organizations can more easily spend one or the other, and this must be considered.
Fully insourced SOC models require the most CAPEX, at least as the SOC is built. This is probably the biggest disadvantage of the fully insourced SOC. In addition to the initial purchases of equipment (servers, workstations, furniture, displays, whiteboards,
etc.) and software licenses, the SOC must budget for replacement costs as these items age. In some organizations, replacement costs can be rolled into OPEX, but many also consider such replacements as CAPEX.
The fully outsourced SOC should not require any CAPEX spending, because all support is provided by a third party and typically no equipment is owned by the organization. Typically, the SIEM system is owned by the third party and simply leased to the organization
for the duration of the service contract. In most cases, this requires only operational expenditures.
In the hybrid model, things can get a more complex in terms of spending. A considerable factor in the hybrid model is who owns the SIEM. If the organization owns the SIEM and it is simply accessed by the provider, this will require the same CAPEX as a
fully insourced model, while also requiring OPEX for the third-party services. If the third-party owns the SIEM, expenditures will be mostly OPEX.
Owning the SIEM in a hybrid model has its advantages and disadvantages. On the plus side, it can make it easier to move to a fully insourced SOC later as the organization matures. It can also make it easier to transition between third-party service providers,
since the SIEM (the most critical tool of any SOC) will remain in place despite the change in providers.
However, having the service provider own the SIEM also has some advantages. Less mature organizations could be less sure of their requirements as they choose a service provider and a SIEM. Most service providers for hybrid SOC operations have a preferred
SIEM vendor and will only support clients using that vendor. Organizations just starting their SOC and choosing a third party for SOC operations (either fully outsourced or hybrid) are effectively simultaneously choosing both the SIEM and the provider.
If the organization later determines the vendor’s chosen SIEM does not meet its needs, it is easier to transition to another vendor if the organization does not own the SIEM.
In general, we recommend organizations adopting a hybrid SOC model own their SIEM rather than lease it. This insulates against the potential need to replace the service provider at some point in the future, ensuring any transition suffers minimal disruption.
When considering which SOC model to adopt, organizations should identify how they will perform investigations after an alert is received. In some outsourced and hybrid models, the service provider just forwards the alarm to the organization and that fulfills
their commitment. In other models, the service provider is responsible for investigating at a deeper level, eliminating false positive alarms and only forwarding true positive alerts.
In models where the service provider is responsible for deeper investigation, the service provider should require more logs to be forwarded to complete the investigation. Of course, this comes at a higher cost, since many costing models price by log volume
and hours of coverage.
Organizations with a hybrid SOC should have access to all the same tools as an internal SOC. Failing to provide the same tooling and access to both entities creates gaps in coverage that typically manifest in frustration for both teams.
An important consideration for all SOC models is who will have unrestricted access to the endpoint detection and response (EDR) system (if one is deployed). An EDR serves both detection and response capabilities, so it is important to understand which
capabilities will be provided to which entities. If a response capability is used inappropriately, this will create a denial-of-service (DoS) condition for the organization. While this is true for both in-house and outsourced SOC models, it is more
difficult for outsourced SOCs to understand factors that might change the response picture.
For instance, the default response action to a server with malware detected might be to utilize the EDR to shut down the server and prevent spread of the malware. However, if the server is currently performing monthly batch processing of critical data,
shutting the server down might do more harm to the business than leaving the infected server online until the processing completes.
It can be difficult to articulate the amount of institutional knowledge an internal SOC possesses that is not communicated effectively to outsourced SOCs. This knowledge gap between internal and external SOC teams (including hybrid SOCs) could potentially
create frustration among stakeholders and is something that should be actively managed from the outset.
One possible method to reduce friction in the hybrid SOC model is to have the internal SOC handle alarms and response actions, while the external SOC only manages alarms. This of course reduces the value proposition of the external SOC, but it also reduces
If you have requirements for threat hunting and will use a provider other than the SOC service provider for this operation, you should gravitate to either a fully insourced model or a hybrid model where the organization owns the SIEM. Coordinating access
to the SIEM for a third party will be extremely difficult (or in some cases even impossible) if a different third party owns and maintains it. Coordination for access to the SIEM in a fully outsourced deployment may be impossible, even if the organization
wants to use an internal team for threat hunting.
Organizations considering a fully outsourced model should be aware that some providers will comingle their data with that of other organizations for monitoring purposes. If this is the case be sure and understand your contractual and regulatory issues
(if any) around data comingling.
A final consideration is data locality. Some cloud-based SIEM solutions favored by fully outsourced SOC providers don’t guarantee which region hosts the data. This may be at odds with some organizations’ contractual and regulatory obligations.
Personnel monitoring the SIEM may also be outside the organization’s country or region, further complicating the job of choosing an outsourcing provider. This is particularly true when considering 24x7 outsourcing providers, which often staff
their operations with a “follow the sun” model.
Your choice of SOC model should begin with analysis of very specific factors unique to your organization:
Although reasonable efforts will be made to ensure the completeness and accuracy of the information contained in our blog posts, no liability can be accepted by IANS or our Faculty members for the results of any actions taken by individuals or firms in connection with such information, opinions, or advice.
February 21, 2024
By IANS Research
Learn why cloud IR is critical to security and not just another box to check. Find guidance to get started building a strong cloud IR program.
February 15, 2024
By Alex Sharpe, IANS Faculty
IANS Faculty member Alex Sharpe discusses the risks around AI adoption and provides governance guidance to make your AI launch safe and mitigate risk.
February 13, 2024
By IANS Faculty
Learn how to how to use NIST to modify secure baseline configurations to account for risk and improve security posture.