Security Operations Center (SOC)

Teams dedicated to detecting and validating threats

At a Glance:

A security operations center, often referred to as a SOC, is a centralized headquarters—either a real, physical place or a virtual organization—for monitoring, detecting, and responding to security issues and incidents that a business may face. There are several models for implementing a SOC as part of a larger incident detection and response (IDR) program, including in-house models, co-managed models, and fully managed or outsourced models.

You might think of a security operations center like a stereotypical movie war room: a dark room filled with complex maps, fancy monitors, and analysts on headsets. However, most SOCs aren't really a physical presence or room; more accurately, they're a formally organized team that's dedicated to a specific set of security roles and responsibilities for detecting and validating threats within your environment.

Who Needs a Security Operations Center?

No matter a company's size or purpose, it’s valuable to have a dedicated organizational-level team whose job is to constantly monitor security operations and incidents and respond to any issues that may arise. The various responsibilities within a cybersecurity team can be extremely complex, and a SOC can not only serve as the tactical console to empower team members in performing their day-to-day tasks, but also as a strategic center to keep the team aware of bigger, longer-term security trends.

A typical security operations center tracks any number of security alerts that an organization might encounter, including potential threat notifications via technologies and tools, as well as employees, partners, and external sources. From that point, the SOC then investigates and validates the reported threat to make sure it's not a false positive (i.e. a reported threat that's actually harmless). If the security incident is deemed to be valid and requires a response, the SOC hands it over to the appropriate persons or teams for response and recovery.

It takes a sophisticated combination of expertise, process, and organization to effectively run a security operations center as part of an overall incident detection and response program. That's why every organization may not be able to support or resource a SOC in-house. Instead, many opt to have their SOC managed by an outside agency or even completely outsourced.

Laying the Groundwork

There are a number of supporting components that must be in place before a SOC is a viable option for an organization. The first is having a good attack surface management program. This includes threat prevention technology for all threat ingress and egress avenues, regular vulnerability scanning (and associated patching), pen testing, user authentication and authorization, asset management, external application testing (with associated patching), and remote access management.

Next is having an incident response plan. Typically, one of the main goals of introducing a SOC into an IDR program is increasing the effectiveness of detecting threats in the organization’s environment. If the incident response processes that follow a breach’s discovery are not in place and tested regularly, you are only addressing some components of an effective IDR program.

Finally, it’s important to have a disaster recovery plan in place. A breach is simply one specific example of a disaster that organizations need to recover from. Once the detected breach has been fully scoped and the affected assets, applications, and users have been contained, there needs to be a plan in place to restore normal business operating processes. This is disaster recovery.

Getting Started

Given a security operation center’s inherent complexity, there are a lot of things to consider when setting one up. Regardless of whether it’s being created in-house or outsourced, preparing for the following three elements is essential to the SOC’s success:

  • People: Understanding the SOC analysts’ roles and responsibilities is an important precursor to selecting the technology that will run your SOC. The teams you create and the tasks you give them will be dependent on your organization’s existing structure. For example, if you’re building a SOC to augment existing threat detection and response capabilities, you’ll want to consider which specific tasks the SOC team members are responsible for and which fall on the non-SOC IDR teams. You’ll also want to divide responsibilities between SOC analysts, so there’s a clear understanding of who handles high-fidelity alerts, who validates low-fidelity alerts, who escalates alerts, who hunts for unknown threats, etc. Many security operations centers operate with a tiered framework for staff to help establish clear responsibilities and hierarchy.
  • Technology: Deciding what technology the SOC uses is where the time spent establishing the roles and responsibilities mentioned above will pay off. What technology will they be using? Likely, they’ll need to combine tools for log aggregation, user behavior analytics, endpoint interrogation, real-time search, and more. It’ll be important to look at how SOC analysts are using your technology and determine whether the existing technology is helping or hindering the SOC processes, and whether new tech will need to replace it. Additionally, it’ll be important to have communication tools in place that enable the analysts to collaborate.
  • Processes: Establishing the processes that the people and technology outlined above will follow is the final component you’ll need to consider when getting started with a SOC. What happens if a security incident needs to be validated, reported on, escalated, or handed off to another team? How will you collect and analyze metrics? These processes must be precise enough to ensure that investigative leads are handled in order of criticality, but loose enough as to not dictate analysis processes. Processes can make or break the effectiveness of a SOC and are worth the effort to get right.

The points above still apply when working with an outsourced SOC provider. A SOC will be a trusted organizational partner, and as such it’s essential they’re proactive and regular in their communications, transparency, feedback, and collaboration with you to make sure your SOC is as successful and effective as possible.