Do You Know Your SOC’s Vulnerabilities? 5 Critical Points to Consider
Building an in-house Security Operations Center (SOC) is often seen as the hallmark of maturity in an enterprise security operations program. By the time your budget is large enough to support the construction and maintenance of a dedicated facility, along with the people, processes and technology you’ll need to operate it, you probably have a highly capable security analyst team, well-developed processes and a robust assortment of tools on hand. Having a dedicated SOC enables SecOps programs to adopt a proactive and centralized approach to security monitoring, incident response, forensic investigation and breach prevention.
Or so the thinking goes. In reality, many stakeholders are dissatisfied with their SOC’s ability to detect and remediate attacks quickly and effectively. The average cost of maintaining a SOC is high ($2.86 million per year in a recent Ponemon Institute survey), and nearly half of technology leaders feel the ROI of their organization’s SOC is dwindling.
Why is it that an idea with such promise—unifying security operations and providing the function with a single, central point of control and command—so often fails to deliver?
The mission of the SOC is to investigate, analyze and escalate incidents to prevent intrusions from becoming significant breaches that damage the organization. If your SOC has significant vulnerabilities, their presence may impede its ability to achieve this aim.
Consider the five following potential areas of weakness. Some are intrinsic to the SOC paradigm as it’s generally understood today, while others are specific to certain individual security operations programs. But any of these vulnerabilities may be keeping your SOC from achieving efficient and effective performance.
#1: The Human Element
The Security Operations Center is a physical place where your information security organization resides, of course, but it’s also a social environment. Your SOC’s overall performance will always depend upon that of the human analysts who staff it. If they’re tired, biased, or feeling burned out, their on-the-job performance will suffer. In addition, junior analysts spend a large percentage of their time learning the tricks of the trade from their more senior colleagues. If these relationships are poor, the quality of collaboration will suffer, and your SOC won’t work as well as it should.
In reality, the effectiveness of any SOC will always be contingent upon the health, attentiveness, and reliability of the humans who staff it. And it will always be vulnerable to insider threats, including the so-called “resumé hack,” in which attackers deliberately plant a staff member on your team whose loyalty lies with an outside criminal (or even political) organization. Such malicious insiders can do an incredible amount of damage, whether by ignoring malicious activities, erasing evidence, changing configuration settings, or concealing what’s going on in certain parts of the network. Whether they’re inside your SOC because a background check didn’t reveal enough information about their true motivations or because they became disgruntled with your company after being passed over for a raise or promotion, malicious security analysts can bypass or eliminate nearly any security control or protection within your environment. Only a defense-in-depth strategy that includes a good audit and monitoring program can guard against this threat.
#2: Security Tools Can Be Hacked
Application-level vulnerabilities in the security software employed in enterprise-grade SecOps programs certainly do exist. Security teams must be certain that they’re applying all patches quickly—by the time a vendor has discovered a vulnerability and published a fix, it’s a virtual certainty that other parties, including malicious actors, will have discovered it as well. What’s more, once the vendor makes the general public aware of the vulnerability, cybercriminals will be racing to exploit it before patches are deployed.
The security analysts staffing your SOC will not be able to do their jobs well if any of their tools have been compromised. In this situation, cybercriminals can easily move across the network while removing all evidence of their actions.
#3: Tool Sprawl Limits SOC Effectiveness
The average enterprise SOC today is running more than 75 different security tools, most often from multiple vendors. It’s extremely challenging for security teams to learn and administer that many tools—and there’s a vast difference between being freshly certified by a tool’s vendor and becoming a “ninja” or “power user” with a great deal of experience. Because analyst turnover is high in many security operations programs, employee training is often an ongoing challenge, increasing costs if the organization is paying the vendor to supply this training.
Though heterogeneous environments (employing products from multiple different vendors) are the norm—and although they may provide a better picture of actual risk by compensating for things that might be missing in a single vendor’s solution stack—they’re also more difficult to configure and administer.
#4: The SOC’s Maturity May Not Be Optimal
We use a modified version of the Capability Maturity Model Integration (CMMI), which was developed at Carnegie Mellon University, to appraise SOCs’ maturity level.
In this model, Level 1 (called “Initial”) denotes a program that relies mainly on ad hoc operations, with investigations and incident response procedures run according to the judgement and creativity of individual analysts. Level 1 SOCs lack documented processes and often struggle to train new hires since so much organizational knowledge departs along with exiting employees.
Level 2 (called “Managed”) indicates that a security operations team has documented processes in place, and that tribal knowledge resides in a written repository that the team can consult and share.
In Level 3 (called “Defined”), a program not only documents its processes, but also has begun to gather metrics that can be used to assess their effectiveness.
Level 4 (called “Qualitatively Managed”) denotes a program that has measured and controlled processes, which are regularly being improved according to qualitative criteria.
And Level 5 (called “Optimizing”) programs are those that are engaged in a process of continuous improvement.
The optimal maturity level for a security operations program corresponds to CMMI Level 3. Programs operating at Levels 4 and 5 tend to be too rigid and operate according to rigorously defined processes that cannot be adjusted as quickly as cybercriminals’ tactics change. To counter ever-evolving information security threats, SOC teams must be nimble, changing how they operate, research, and collaborate as quickly as the threat landscape shifts.
And SOC programs operating at Levels 1 and 2 will suffer devastating losses each time one of their more senior employees departs. Their lack of maturity and repeatable processes means that the SOC will always be poorly run and less than optimally effective.
#5: Being Event-Focused Rather than Situation-Focused
The majority of security analysts spend their days sitting in front of a console, watching an endless stream of alerts stream across it. It’s a difficult job—it is nearly impossible to do it well, and it’s frustrating to be tasked with “trying to find something important” rather than “working to detect malicious activities.” In this, the event-focused model, security analysts waste a great deal of time, are seldom effective, and rarely contribute to the core mission of the SOC.
In contrast, in a situation-focused security operations program, analysts rely on intelligent and advanced tools like the Respond Analyst, which present them with fully scoped and vetted incidents. Their time is spent conducting deep investigations of these incidents, and their likelihood of detecting true malicious activity is much higher.