apinan - Fotolia
Precision of language is important in any engineering or technology endeavor. This is complicated by the fact that new terminology arises in cybersecurity all the time -- for example, when a new technology or attack is discovered that requires a new name to differentiate it from previous ones.
Sometimes, terminology and jargon can evolve in ways that make things more opaque rather than more transparent. Security professionals are familiar with certain language from vendors. This marketing-speak can make it hard to understand what products or services actually do and how they work.
One relatively new term that has some practitioners scratching their heads is security operations center as a service, or SOCaaS. This term leads to confusion for a few reasons. First, practitioners may question what the difference is between SOCaaS and other models, like managed security service providers (MSSPs) or managed detection and response (MDR).
Second, the role and scope of a SOC can differ between firms. Which SOC elements are included in the as a service part of these offerings and which aren't? It can be hard for practitioners to know if this is something right for their security program or even if it's new or just marketing lingo for something they already know.
With that in mind, let's explore what SOC as a service is, how it differs from other models and how to evaluate if it's right for your enterprise.
How to define SOCaaS
As the name implies, SOCaaS reflects a service-based model that outsources portions of SOC functions to an external provider. The primary driver for SOC as a service has been increased use of cloud. The transition to the cloud means that security information -- alerts, telemetry, logs and network information -- becomes accessible via different channels compared to on-premises environments.
Security teams get different information at different layers of the stack, via different mechanisms, in a cloud context relative to other environments. How can they reconcile this with information sourced from on-premises or organization-managed tools? This is exactly the challenge that SOCaaS attempts to solve. It does so by using automation to track resources in the environment, flag anomalies and either block or send an alert in response. This can be done in a completely automated fashion or, in some cases, is subject to human analyst review to weed out false positives.
SOC as a service focuses on the monitoring elements of a traditional SOC rather than firm-specific operational elements. This is where SOCaaS differs from a traditional MSSP. MSSPs may have monitoring as part of their service offering but will also typically include the operation of a number of on-premises security tools.
Learn more about traditional SOCs in this video.
Take, for example, the source elements required to accomplish that monitoring. It can include care and maintenance of on-premises security tools, like intrusion detection systems (IDSes) and firewalls; telemetry gathering from devices on the network; and log harvesting from resources. Not only will an MSSP handle some portion of the monitoring, but it typically takes on the maintenance and operation of the physical infrastructure required to accomplish gathering the data it seeks to monitor as well.
By contrast, SOCaaS offerings, as well as MDR, will generally employ analytics, machine learning and other tools or methods to streamline the detection process. This streamlining is more effective than when the data-gathering tool set is disparate, heterogeneous and unique to a given organization.
At this point, some professionals may think that SOCaaS sounds a lot like MDR. There are aspects of each that overlap. Similar to SOCaaS, MDR providers typically use machine learning and analytical tools to help with event detection. They'll often have hooks into multiple customer environments -- cloud, as well as on premises -- to accomplish this. The idea is that a provider, using its own tool set and techniques, can offer economies of scale in the detection and response capability that enable customers to get better insight for less money than if they did it themselves. Unlike a traditional MSSP model, an MDR partner will generally not directly manage or operate security tools like SIEM, IDS, network behavior anomaly detection or network filtering on customer premises.
Note that one universal caveat applies: Not all service providers or offerings are equivalent. There will likely be significant overlap as features develop and players in the space continue to innovate.
How to evaluate if SOCaaS is the right option
To evaluate the best service, organizations should start by unpacking their own requirements. If it's a large organization with one or more MSSP relationships already in place, it's possible that those providers can support monitoring at incremental cost. If an organization has clearly demarcated cloud environments -- for example, expansive use of IaaS within a single provider -- a SOC-as-a-service offering that specifically targets that environment might be a solid option. Organizations may choose to engage an MDR partner to help bolster their response capability in either case. The decision about which is optimal depends on what is already in place and what the company is looking to accomplish, as well as any organization-specific criteria that may influence how that is accomplished.
Start with a systematic understanding and analysis of what it is the security program wants to do. Is the goal to bolster the detection capability to improve detection outcomes? Or is the aim to lower monitoring costs, improve visibility into cloud environments or bolster on-premises or external environments? Answering these questions will clarify which type of service or provider might be the best fit.
When narrowing down a short list of necessary features, organizations should do two things. First, ask to kick the tires. If organizations opt to perform penetration testing -- for example, maybe PCI DSS requires this step -- they should ask to try out a SOCaaS provider during that pen test time frame to verify how the provider performs. This can help identify any unexpected hiccups in delivery. Note, this won't be an option in every case. Some providers will have constraints that limit whether this is practicable. Also, security teams may not want to commit to a forklift upgrade of their entire monitoring infrastructure just to test a particular vendor's capabilities. However, these sorts of requests are familiar to providers, so they might have experience to help prospective customers in their evaluations.
Finally, when evaluating a shortlist of promising features and providers, security teams must maintain oversight before, during and after the onboarding of the service provider. Just like they would maintain oversight of a cloud provider to understand adherence to service-level agreements, transition success or ongoing price and performance, so too must enterprises make sure they keep abreast of how the particular service provider performs over time.