SOC-as-a-Service (SOCaaS) is like most of the hype in this industry—easily co-opted and applied to the same old tech in an attempt to capitalize on buzz in the market.
The services that true SOCaaS offers, and how they’re actually provided, can differ. How can you differentiate between the growing field of offerings called “SOC as a Service” to find the best fit for security, protection, and value for your organization?
For many businesses a 24/7 security operations center (SOC) is an essential part of their cybersecurity strategy. But SOC implementations are expensive and very complex. SOC-as-a-Service provides SOC-like human analysis services with the scaled value that the software-as-as-service model achieves.
A recent Ponemon Report shows only 42% of businesses say that their SOC is very effective. It’s why so many are lining up to shift to using SOC-as-a-Service provider. The SOCaaS model covers the majority of what most organizations need, which is: telemetry, monitoring, investigation, analysis, and some measure of response for endpoints. The unique cases that only a physical SOC can handle are becoming less common.
However, it’s easy to fall under the assumption that a SOC-as-as-Service is some sort of completely automated service because of its scalability. A “real” SOC is an operations center staffed by skilled humans. And the most powerful and most important feature of a real SOC-as-a-Service is the people operating it.
Choosing a SOC-as-as-Service partner is important in providing the best cybersecurity service for customers or users.
As a model, SOCaaS comes with a few benefits that a business and its customers should consider, such as: reduction of the overall burden on the customer’s in-house security teams. It also decreases cyber risk while increasing scalability and agility.
Additionally, SOCaaS costs can be considered operating expenses and are typically based on node volume, often making it a more cost-effective solution than an on-prem or dedicated SOC for organizations below a certain size.
What To Look For In A SOC-As-A-Service Partner?
When evaluating potential SOCaaS partners, use these questions as a basis:
1 Is it capturing the right data (and using it correctly)?
The most critical question to ask of a SOC-as-a-Service is whether it’s capturing the right data. Most EDR products in the current market are opaque about the data they’re capturing, and that data is only being analyzed in real time. EDR excels at quick decisions when fast response is necessary. That’s great for quick detection of threats that can be identified with a snap shot, but some threats require a broader time scope; identification of patterns or behavior over a period of minutes, hours, or days to achieve deep analysis.
SIEM vendors have always championed volume. They won’t prescribe what is actually useful data, only how much of it their product can capture and store. They can provide a laundry list of data source and types to collect, but no guidance on what to do with it.
So, what is the right data? Below are few examples of data that a holistic SOCaaS will collect and how it’s utilized:
- File hashes, email addresses, domain names, etc. correlated with petabytes of global data, threat intel, and known breaches to determine good vs bad. This is not a realtime process.
- Libraries, JAR files, embedded components in all your software inventory that produce a software bill of materials (BOM). CVEs aren’t just for the app, it’s for the dozens of libraries buried deep inside the app.
- Correlation of multiple data types and disparate security vendors in the same environment to enrich the data and provide better context of good vs bad
- A good SOCaaS doesn’t rely on IP addresses alone to tell what’s good or bad. Because everything is encrypted anyway, and most traffic will end up at a major cloud provider, IPs are typically useless
- Last but not definitely not least are browser plugins. Users spent approximately 90% of their working day in the browser, making it a critical attack surface. Overly-privileged or malicious browser plugins can represent an extreme risk at the endpoint.
2 Can it handle the scale of its customers?
Can a SOCaaS partner handle the scale of its customers? We’ve just established that a true SOC-as-a-Service requires warm body staffing. How that’s organized is a good indicator of capacity; a sign that a vendor might not be a good fit is when its tenants are not separated out. If they aren’t multi-tenant, it’s definitely a red flag that indicates that it won’t be able to dedicate the scale, time, or people needed to manage the services.
SIEM And EDR Vendors Jumping Into This Space May Not Offer True SOCaaS
For the managed services providers who aren’t large enough to utilize five separate security product vendors, SOC-as-a-service is competing with SIEM, EDR, and other tooling vendors. In fact, many have already merged.
EDR vendors are buying or building SIEMs and SIEM vendors are desperately trying to acquire EDR vendors as a shortcut to offer the tech.
Many traditional vendors are competing as XDR because they’ve been told that SOC services are far too expensive, and they believe this is adequate. The problem is it’s not, because people are still required to do the work.
Therein lies the problem: security businesses trying to run SOCaaS without the people.
In this war of trying to be all tools for all situations, does anyone win? At this point, it’s not clear. An educated guess says EDR vendors are going to win the XDR space because it’s hard to be a good EDR since a lot of the work is marketing and not actual capabilities. SIEM vendors have always been very neutral because of this and they’re coming in very late to the game, which puts them at a disadvantage.
SOC-As-A-Service is not a very mature space. There likely won’t be a clear winner because small groups can declare themselves a SOC-As-A-Service provider and still provide an amazing service, despite being small.
What Tools Should SOC-as-a-Service Implement?
The question is slightly misleading, as the answer is also a question: what shouldn’t they implement? Any tool that allows a team of support analysts, researchers, threat hunters, product engineers, and incident responders to better perform their duties is fair game. Aside from the agent-based telemetry required by a SOC-as-a-Service, there’s no requisite tools or technologies for providing good service. It’s not something a customer should be concerned with.
An exception might be the scrutiny of some tools that originate from unvetted foreign origins, or certain tooling scenarios that might leave a provider vulnerable to a supply chain attack. This is almost impossible to ascertain from the customer point of view though.
Which Product or Service Will Take The Lead?
It’s tough to make the call when the industry is in such a state of flux. The mix of tools and services being labeled as EDR, XDR, SIEM, and SOC-as-a-Service continue to blur the lines of their already ambiguous marketing-confused definitions.
The one clear characteristic that makes any SOC, whether traditional or obscured by the “SaaS” style of delivery, is that tools do not make the service—people do.
Choosing a SOC-as-a-Service partner should be a process that’s not very far removed from choosing a MSSP—it should evaluate the experience in dealing with the service provider and examine their specific capabilities.
The evaluation should compare critical functionality and simulate what it’s like to investigate detections and incidents, and to seek further help or even to begin response. These are the basic roles of a SOC, and SOC-as-as-Service should provide all that while adding flexibility and convenience.