The challenge of running an effective Security Operations Center far outweighs the effort to build one. This difficulty stems from the fact that the organization will be operating for far longer than the time needed for its implementation, and that the decision points are both more numerous and unanticipated. There are plenty of sources for guidance to help mitigate the effort, but this advice often comes in the form of consensus-driven control frameworks and abstract guidelines. While important, for this post we will assume that you already have a solid foundational understanding of these controls.
We have repeatedly encountered organizations that struggle with the dynamic between relying on the talents of exceptional individuals or methodical application of organizational expertise with structured effort. There are benefits to both methods, but more often than not, organizational culture tends to dictate the approach the Security Operations Center takes. The organization’s experiences with risk management, change, and learning from mistakes can be a powerful influence. Instead of being constrained by these experiences, the SOC can benefit from institutional knowledge by adapting its work to fit more harmoniously with the rest of the organization.
The ThetaPoint Security Reference Architecture is a blend of both methods with a series of motifs that can be adapted by the practitioner or ignored with no consequence. Even if the contents only stimulate a conversation of how a particular approach would never work for you, this should bring some structure to that analysis. Above all, we are confident that this Architecture will provide some tools and concepts for creating consistent outcomes in a domain defined by its deltas.
Three layers comprise the Architecture: People, Process, and Technology. Because there are so many interactions between the layers, understanding what could be useful for your organization requires some familiarity of the whole when analyzing the parts. This section will acquaint you with the major concepts before we dive in to the details in subsequent blogs.
Most people in the technology world hear the word “architecture” and automatically assume a Visio diagram or something equivalent. To consider a technology stack without understanding the user interaction and business processes fostered by this stack would be short-sighted. Our Architecture fits entirely within the domain of Security Operations yet considers the common interaction points with other domains. Its utility is in its specificity and not because it can be used as a generalized blueprint for a complete cyber security function. Specialists with domain-specific knowledge can help you fill in the gaps for some of those complex interactions – especially things like regulatory compliance and IT infrastructure operation. We’re omitting many of those details because we believe them to be sufficiently commoditized for you to acquire that assistance from other experts.
Because individual contributors in a SOC must make so many decisions with ambiguous inputs and outcomes, the organization needs to provide a clearly defined mission to focus on the most important ethical, business, and risk-management factors. The mission provides the focus that enables individual agility and combined effort to converge on consistent outcomes. Most importantly, the mission defines how the individual contributor’s efforts are valued by the organization and by what criteria their judgements are ultimately evaluated. Below is a sample organizational structure for a Security Operations Center, along with the roles and responsibilities of the individuals required.
Sample SOC Organization Chart
Roles and Responsibilities
|Role||Primary Responsibilities||Secondary Responsibilities|
|Operations Analyst||Real-time analysis of automated alert data||Development of analytical use cases|
|Execution of Incident Handling procedures||Reporting and knowledge transfer to the SOC|
|Documentation of investigations and actions taken on shift||Execution of required log and audit reviews|
|Tuning automated analytics||Model maintenance|
|Intelligence Analyst||Automated intelligence collection||Special threat research projects (hunting)|
|Threat actor profile development||Strategic threat analysis and reporting|
|Intelligence sharing||Incident attribution|
|Engineer||Model development||Workflow enablement and automation|
|Real-time monitoring of system health||System implementation and integration|
|Maintenance and other controlled changed||Automated testing and verification|
|Execution of BC/DR procedures|
The Architecture defines 5 general process domains. Each domain contains some essential processes that span functional roles and responsibilities. The core processes are intended to provide essential business services on behalf of the SOC. Not all processes have heavy crossover interactions between functional roles, but all do have a primary function that is responsible for execution and continuous improvement.
Front-line operations work can be tedious, and most of the investigated events (usually) do not result in breach findings. This can introduce analytical biases over time or result in “decision fatigue” as the workday wears on. Piecing together context can also be incredibly repetitive and time consuming. The organization can even exert strong pressure to close cases, either because higher-priority events take precedence, or the analyst’s performance is measured in terms of cases cleared.
These pressures to “satisfice” investigations run directly against the SOC’s mission, so it is critically important to provide relief by making analysis as easy as possible. Most of the SOC functional roles perform some kind of analysis, so these processes are intended to facilitate investigative work by pre-computing event context or making it easier to tune automated alert generation itself to reduce the overall workload.
|Analyst Workflow||Raise alerts for investigation and intervention||Analytical Use Case Development|
|Incident Response||Take consistent actions according to well-defined criteria for coordinated intervention||Technical Investigation|
|Model Management||Create consistent machine-readable specification for digital assets, entities and data||Model Integration|
|Intelligence||Acquire, produce, and share high-quality automated Indicator and Warning data||Automation|
|Administration||Implement systems and ensure their resilient operation||System Health Monitoring|
|Change and Maintenance|
The proliferation of security technologies is often a contributing factor to the diffusion of effort and confusion that can confound decision making in an operational organization. Much like our models of People and Process, we adopt a simplified view of Technology that helps us simplify the concepts and focus our efforts. We call the core Technology stack the Baseline Infrastructure, because once it has been adopted, all further work can proceed as an extension or modification of one of its four components.
An important aspect of the Baseline Technology stack is that it doesn’t include all of the security instrumentation or policy enforcement security products typically associated with a security department. We’re omitting them for good reasons: their value is in the data they produce and is thus handled by the ingest stack, the control surfaces they expose should be abstracted within the workflow stack if they support an analyst workflow, and their configuration, management, and operation isn’t something that directly supports the process of investigation and analysis (and they can be a major distraction).
If your SOC organization must support these kinds of security technology, our Architecture suggests abstracting their interactions with your Analysts through the Ingest and Workflow Components, and their upkeep should be kept within the Engineer roles and responsibilities. This separation of responsibilities keeps the Analyst workload focused on the analytical tasks and ensues their smooth operation. This concept will be expanded upon in subsequent posts, but for now, it helps to box things in so that we are only talking about supporting analysis.
|Primary Function||Secondary Functions|
|Ingest||Collect raw event data and represent as usable data structures||Event collection|
|Abstract ingest infrastructure|
|Primary format parsing|
|Representation of events and metrics|
|Utility||General-purpose manipulation of event and metric data||Event reduction – filter/aggregate|
|Enrich and transform events and metrics|
|Route and replicate data flows|
|Instrument data flows|
|Simple analytics (joins)|
|Provide streaming, windowed, and replay access semantics for event and metrics|
|Workflow||Workflow enablement and control actuation||Primary analytics|
|Alert generation and tuning|
|Case management, knowledge sharing|
|Communication and coordination|
|Data visualization and query|
|Control actuation and workflow automation|
|Model||Machine-readable representation of assets, entities, and relationships||Standardized element-level naming for physical, logical, and abstract entities|
|Structured relationships between entities (hierarchies, taxonomies, schemata)|
|Representation of topology and access|
SOCs are complicated enough – let’s simplify the domain so that we’re not chasing implementation and site-specific differences. Let’s adopt a common set of terms so that we can discuss the ‘How’ of security operations with rigor and specificity
Don’t confuse a product’s market niche with a person’s day job or a service your SOC provides. There will always be room for subject matter expertise, but that level of specificity doesn’t advance the discussion or the profession.
To this day, there’s no standard framework to talk about the analytical use cases or workflows needed to drive a SOC. Some effort has been made for developing taxonomies of attacks, identification of vulnerabilities, and exchanging indicators, but these are only pieces of the puzzle.
Over the coming weeks, we will be publishing the framework in more detail, and we hope to engage you in a collaborative discussion of the challenges we have encountered and the solutions we have developed.
- SRA - Introduction: https://www.theta-point.com/blog/introduction-thetapoint-security-reference-architecture
- SRA - Framework Overview: https://www.theta-point.com/blog/security-reference-architecture-framework-overview
- SRA - People: https://www.theta-point.com/blog/security-reference-architecture-people
- SRA - Process: https://www.theta-point.com/blog/security-reference-architecture-process
- SRA - Technology: https://www.theta-point.com/blog/security-reference-architecture-technology
In addition if you’d like to engage directly, ThetaPoint can partner with your organization to develop tailored solutions to meet your unique needs in the following areas:
- SOC Engineering Services
- Touch-Free SIEM Operations and Maintenance Support
- SIEM Value Assessment and Consulting Services
- SOC Workflow Automation
About ThetaPoint, Inc.
ThetaPoint is a leading provider of strategic consulting and managed security services. We help clients plan, build and run successful SIEM and Log Management platforms and work with the leading technology providers to properly align capabilities to client’s needs. Recognized for our unique technical experience, in addition to our ability to quickly and rapidly solve complex customer challenges, ThetaPoint partners with some of the largest and most demanding clients in the commercial and public sector. For more information, visit www.theta-point.com or follow us on Twitter or Linked-In.