5 Things to Look for When Buying a SOC as a Service
It is evident now that the approach to cybersecurity is shifting from preventive to proactive. Businesses and organizations are starting to understand that cybersecurity is not only about installing technologies that prevent cyber-attacks, but more importantly, it is about actively hunting for attacks as if they already took place. This shift in mindset and practice gave rise to a series of procedures and processes that collectively fall under the term Security Operations. And as such, a Security Operations Center (SOC) has become a trend followed by many large and sensitive corporates and organizations.
However, implementing a full-blown, well-functioning, and in-house SOC is not inexpensive. Investing in SOC processes, people, and technology, in addition to its management is so much costly — in terms of financial and human resources — that many organizations cannot afford. And because of that, those companies turn to subscribing to a third-party managed SOC — a.k.a., SOC as a Service — where they pay a monthly or annual subscription fee to a third-party cybersecurity firm, which then handles all the hassles of implementing and running the SOC.
If you are in a position to buy a SOC as a Service, I would like to share with you 5 essential qualities to look for and that will help you evaluate which service provider to buy from.
- 24×7 Security Monitoring and Analysis
Cyber attackers are not obliged to conduct their malicious acts from 8am to 5pm. They are attempting to breach your organization all day and all week. They do not take weekends or holidays. You should always assume that there is a malicious hacker somewhere trying break into your network. Some hackers conduct their mischievous acts at midnight when your IT administrator is in bed. Others, ironically, conduct their acts during the busy day as their trails and logs may pass unnoticed along with thousands, if not millions, of other legitimate logs.
This means that any proactive hunting of threats must be around the clock, 24×7. There should be an adequate number of security analysts and incident responders who will be monitoring and ready to respond to any incidents. It is worth mentioning here that SOAR (Security Orchestration, Automation, and Response) solutions will help SOC teams coordinate and automate security tasks efficiently around the clock.
- Swift Mean-Time-To-Detect (MTTD)
Threat Detection is one of two major functions — the other being Incident Response — of a SOC. This is the active hunting of threats and attacks by continuous monitoring, triage, and analysis of event logs. Even though great portion of this work can be automated with proper technology, there always remains a need for meticulous manual analysis. What is really at stake here is the actual time required to unveil an attack from the moment it initially took place. For some attacks, the time it takes the SOC team to detect might be short, while for others, the time is long. The Mean-Time-To-Detect (MTTD) is a quantifiable measurement of the average time needed to detect a single attack, measured over a period of evaluation. The smaller the MTTD is, the better.
A small MTTD means that the SOC has invested a lot in testing, automating detection methods, and manual analysis. This will help your organization spot attacks in their initial phases — sometimes even before they occur — before a substantial damage takes place.
I would suggest you ask your SOC provider the following questions:
- What is their MTTD? Is it in minutes, hours, or days?
- How do they measure their MTTD?
- What are they doing to minimize their MTTD?
- Swift Mean-Time-To-Respond (MTTR)
Just like the MTTD, the Mean-Time-To-Respond (MTTR) is yet another key measurement of the quality of any SOC. The MTTR measures the average time it takes a SOC team to respond to an attack, neutralize it, and recover from it. Detecting an attack is only half the story, the other half is responding effectively to it with the aim of full recovery. If Detection is the role of Security Analysts, Response is the role of Incident Response. A small MTTR means that the SOC Provider has invested in a qualified and skilled team of responders.
When you consider SOC as a Service, make sure that your service provider has skilled professionals who can respond to attacks against the IT technologies deployed at your environment. For example, if your IT infrastructure is mainly UNIX-based, your Service Provider must have Incident Responders for UNIX systems.
Here are few questions that you might ask your provider:
- What is their MTTR? Is it in minutes, hours, or days?
- How do they measure their MTTR?
- What are they doing to minimize their MTTR?
- Multi-Layered and Varied Technologies
Technology is at the heart of SOC, while it is not its only component. The most common technology implemented for Security Operations is the Security Information and Event Management (SIEM). SIEM collects, stores, consolidates, aggregates, and correlates event logs from multiple sources such as, servers, workstations, network devices, and net-flows. There are different SIEM brans and vendors, ranging from free open-source ones, to highly expensive ones. In addition to SIEM, a SOC can also be supplemented with Endpoint Detection and Response (EDR), Vulnerability Assessment (VA) tool, and Security Orchestration, Automation, and Response (SOAR).
When evaluating a managed SOC, it is recommended that there are at least two SIEM brands — one commercial and the other open source — so that they complement each other; what one fails to detect may get detected by the other. Furthermore, supplementing a SIEM with EDR, VA, and SOAR increases the effectiveness, as well as the MTTD and MTTR, of the SOC.
You may want to ask your Service Provider questions like the following:
- What SIEM brands are they using? Open source of commercial?
- Is there one SIEM brand or more?
- Do they have EDR, VA, and SOAR in place?
- Customizable Use Cases and Correlation Rules
Last but not least, your SOC provider should be ready to customize and adapt their threat detection rules to your environment. Your SOC provider should not only rely on built-in, or out of the box, use cases and log correlation rules that ship with any SIEM solution, but should be able to develop new use cases and correlation rules that best fit the requirements of your organization. For example, you might have a crucial need to heavily monitor a certain Database; or, a certain network segment hosting an e-commerce web application may be frequently audited more than other segments. Your SOC provider should be ready to put more emphasis on those sensitive systems and segments.
Developing tailored use cases and correlation rules is not an easy task. It means your network will undergo a testing phase during which your SOC provider will communicate with you to discuss and evaluate their newly developed rules until they reach a mature level.
Here are few questions that you may ask your SOC provider:
- To what extent are they able to customize and develop new use cases?
- How long is the initial testing/evaluation of phase?
Those were the important points you should take into consideration when buying a SOC as a Service. If you are interested in exploring your options, go ahead and check our SOC service at AXON Technologies.