Learn how a security operations center serves as a tactical console for performing complex tasks.
Download SecOps eBookA 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 SOC 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 dedicated to a specific set of security roles for detecting and validating threats within a company or organization's environment.
A SOC does many security-related tasks, including continuously monitoring security operations and incidents and responding to issues that may arise. The various responsibilities within a cybersecurity team can be extremely complex, and a SOC not only serves as the tactical console to empower team members to perform their day-to-day tasks, but also as a strategic center to keep the team aware of bigger, longer-term security trends.
A typical SOC 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.
The SOC then typically investigates and validates the reported threat to ensure 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 SOC as part of an overall threat 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, known as Security Operations Center as a Service (SOCaaS).
The components in a SOC are many in number and must be structured and in place before a SOC is a viable option. Let's take a look at a few:
Three main elements are needed for SOC setup. Regardless of whether the SOC is created in-house or outsourced to a managed provider, preparing these core functions is essential to success.
Understanding 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 – and potentially consider SOC automation where possible – so there’s a clear understanding of who handles high-fidelity alerts, who validates low-fidelity alerts, who escalates alerts, who hunts for emergent threats, etc. Many SOCs operate within a tiered-staffing framework to establish clear responsibilities and hierarchy.
Deciding what technology the SOC uses is where time spent establishing the roles and responsibilities mentioned above will pay off. What technology will they use? Likely, they’ll need to combine tools for log aggregation, user behavior analytics (UBA), 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 processes – and whether new tech will need to replace it. It’s also important to have communication tools in place to enable collaboration among analysts. Other important considerations:
Establishing 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 act as a framework precise enough to ensure 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, so incident management workflows should be established from the start to ensure each step in the process is part of a larger strategy.
The points above still apply when working with an managed 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.