Our Story

Be Informed. Be Smart. Be Sure.
Lorem ipsum dolor sit amet, consectetur adipiscing elit. Aenean feugiat dictum lacus, ut hendrerit mi pulvinar vel. Fusce id nibh at neque eleifend tristique at sit amet libero. In aliquam in nisl nec sollicitudin. Sed consectetur volutpat sem vitae facilisis. Fusce tristique, magna ornare facilisis sagittis, tortor mi auctor libero, non pharetra sem ex eu felis. Aenean egestas ut purus nec vehicula. Morbi eu nisi erat. Nam mattis id lectus sit amet mattis. Suspendisse eget tristique neque

Working Hours

Monday - Friday 09:00AM-17:00PM
Saturday - Sunday CLOSED

Latest News


Security Reference Architecture – Framework Overview

Framework Overview

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.

Architectural Layers

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

RolePrimary ResponsibilitiesSecondary Responsibilities
Operations AnalystReal-time analysis of automated alert dataDevelopment of analytical use cases
Execution of Incident Handling proceduresReporting and knowledge transfer to the SOC
Documentation of investigations and actions taken on shiftExecution of required log and audit reviews
Documentation of investigations and actions taken on shiftExecution of required log and audit reviews
Intelligence AnalystAutomated intelligence collectionSpecial threat research projects (hunting)
Threat actor profile developmentStrategic threat analysis and reporting
Intelligence sharingIncident attribution
Historical investigation 
EngineerModel developmentWorkflow enablement and automation
Real-time monitoring of system healthSystem implementation and integration
Maintenance and other controlled changedAutomated 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.

Process Breakdown

  Purpose Core Processes
Analyst Workflow Raise alerts for investigation and intervention Analytical Use Case Development
Event Analysis
Incident Response Take consistent actions according to well-defined criteria for coordinated intervention Technical Investigation
Contact Investigation
Model Management Create consistent machine-readable specification for digital assets, entities and data Model Integration
Model Synthesis
Model Validation
Intelligence Acquire, produce, and share high-quality automated Indicator and Warning data Automation
Intelligence Cycle
Intelligence Sharing
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.

Baseline Technology

  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

Key Takeaways

  1. 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
  2. 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.
  3. 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.

What’s Next

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.

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:

  1. SOC Engineering Services
  2. Touch-Free SIEM Operations and Maintenance Support
  3. SIEM Value Assessment and Consulting Services
  4. 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 clients 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