> For the complete documentation index, see [llms.txt](https://docs.cybaops.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.cybaops.com/modules/detect-and-respond-mdr/self-hosted-soc.md). # Self Hosted SOC This guide is designed for organisations that are self-managing the Detect & Respond module of CybaOps. It walks your analysts through the complete investigation lifecycle, from receiving an alert through to resolution and closure, using CybaOps as the single pane of glass for all detection, investigation and response activity. ## **Overview** CybaOps is built to streamline the management of core cyber security activities. Before working through the investigation workflow, it helps to understand what each area is for and when you will use it. #### **Detect & Respond** The Detect & Respond Dashboard is your snapshot of investigation initiatives. It gives a high-level summary of your incident activity and threat level immediately. Key elements include: * **Threat Level**: a single score reflecting the current health of your estate, influenced by factors such as current open investigations and their severity. * **Date picker**: Defaulted to 30 days, you can customise this to see the below activities for a different period * **Open Incidents**: a count of active incidents with the highest severity level surfaced immediately for quick prioritisation * **The Pipeline:** a visualisation of the flow from raw events through to alerts and then incidents. This is useful for spotting when detection tuning is needed, for example if a high volume of events is generating a disproportionate number of false positive alerts * **MITRE Radar:** a chart that maps current incidents against the ATT\&CK framework, highlighting which tactics are most active across your estate * **Sentry AI:** an AI-generated plain-English summary of current dashboard activity, useful for quick briefings and shift handovers. #### **Managing Your Exposure** We recommend reviewing the datapoints on the dashboard regularly, to spot patterns and see if additional tuning is required. The Pipeline and MITRE Radar in particular can surface patterns that individual incidents do not show on their own. #### Ticket Incident Queue and Case Management The ticket view is where investigation work happens. The queue lists all active incidents. Each incident opens into a full case management view with a timeline, artefacts, MITRE mapping, and the communication tools analysts use throughout an investigation. This is covered in detail in the investigation workflow sections of this guide. #### **Investigate (SIEM)** The Investigate tab your SIEM for querying raw log data. It is used in two ways: during an active investigation to build context around a specific incident, and proactively for threat hunting, searching for indicators of compromise or unusual patterns that have not yet generated an alert. ### **Sentry AI** Sentry AI is an artificial intelligence layer built into CybaOps. It surfaces in two places and serves a different purpose in each. Sentry AI can be turned off for specific tenancies in the organisation settings. #### **On the MDR Dashboard** At the dashboard level, Sentry AI generates a plain-English summary of current activity across your estate. It draws on the same data that populates the dashboard widgets and produces a short briefing that can be read in under a minute. This is particularly useful at the start of a shift, or when a manager needs a quick status update without working through individual cases. #### **On an Individual Case** Within a case, Sentry AI can generate a summary of everything that has happened on that incident so far. It reads the timeline, artefacts, notes and comments and produces a concise overview. This is most useful when: * An analyst is picking up a case that someone else started * A case has been in Pending status for some time and you need to re-orient before continuing * You want a quick sense check of the narrative before writing the final description AI {% hint style="info" %} #### **AI Summary: Orient, Then Verify** Sentry AI provides a summary of information already available in the case. While it can be helpful for getting a quick overview, it may not capture every detail or nuance. It’s best used as a starting point, alongside reviewing the full timeline and applying your own judgement before making decisions or taking action {% endhint %} ### **How Incidents Are Generated** Before an analyst ever opens a case, CybaOps has already done significant work in the background. Understanding this process helps explain why incidents arrive with the artefacts and data they do. {% stepper %} {% step %} #### Ingestion of Event Data CybaOps connects to your security tooling and ingests raw log data from all configured sources. This includes endpoint detection tools, identity platforms, cloud services, firewalls, and any other connectors you have configured. All of this data flows into the platform continuously. To see what connectors are active for your tenancy – navigate to settings, company details and then click connectors. {% endstep %} {% step %} #### Alert Generation Alert generation is the first stage of turning raw data into meaningful security signals. It sits between event ingestion and alert correlation. The platform ingests raw events from connectors (e.g. endpoints, email, identity systems) at this point, these events are unfiltered, high-volume data. After these events have been ingested, they are transformed into a list of alerts through a series of detection engineering rules. These rules decide which events are relevant and which should be turned into alerts. Non-relevant data is dropped at this point. If you have chosen a compliance SIEM solution, all data will be retained for the agreed retention period. Alert generation is driven by Sigma-based detection rules that define patterns such as suspicious logs, mailbox changes and endpoint detection anomalies. Alerts can also pull in additional context from external APIs that enrich the alert dynamically. The output of this process is a structured alert with a defined detection trigger, with relevant artefacts, MITRE mapping and enriched contextual data. Making alerts ready for action and correlation. {% endstep %} {% step %} ### Correlation Correlation After alert generation the correlation engine takes over, and groups alerts based on asset context (user, device, IP) and scores them/combining them. When a threshold is met, then an incident is created. Not all alerts will become incidents, and not all incidents will have multiple alerts, it will all depend on the scoring of the alert. {% endstep %} {% step %} ### Visibility & Control All detection rules and automations that trigger incidents are visible in the ticket case management system view. Where an automation is relevant to a case you are working on, you can: * View the automation and understand what it does * See when it last ran and what it triggered * Manually trigger it if conditions warrant an immediate response * Edit it if your environment requires a different behaviour {% hint style="info" %} #### **What the Initial Data Represents** The artefacts and MITRE mappings that arrive with a new incident reflect what the detection rule fired on. They represent the signal, not the full story. Your investigation may reveal additional artefacts, different techniques, or a broader scope than the initial detection suggests. {% endhint %} {% endstep %} {% step %} ### The Pipeline: Monitoring Detection Health The event-to-alert-to-incident data ingestion is visible on the Dashboard. Beyond being a headline metric, it is a useful diagnostic. If you notice a high ratio of events converting to alerts without those alerts becoming meaningful incidents, it suggests the detection rules may need tuning {% endstep %} {% endstepper %} ### **Investigation Journey Objective** CybaOps enables your analysts to investigate an incident end-to-end in a single platform, producing a clear, auditable outcome that answers four key questions:

Question	What the analyst must establish
What happened?	A factual account of the incident, what was detected, when, and on what system or account.
How it happened?	The attack path or root cause, how the threat actor reached the affected asset.
What we did?	All investigative and response actions taken, documented in the timeline.
How to prevent it?	Recommendations to prevent recurrence, policy changes, detection tuning, user guidance.

Every investigation is enforced through platform-controlled workflow, mandatory state transitions, and audit-ready timelines. {% hint style="info" %} #### **Analyst Accountability** The timeline is a full accountability record. Every action, note, comment, artefact update and status change is logged with a timestamp and attributed to the analyst who made it. Anyone with access to the case can review the complete history at any time. Hold yourself to that standard. Document your reasoning, not just your actions. {% endhint %} ### **Investigation Overview** The suggested CybaOps investigation journey consists of four enforced phases:

Phase	Name	Type	Key Outcome
1	Intake and Ownership	Linear. gated	Case owned, SLA started, investigation clock running
2	Investigation (Core Loop)	Iterative, repeating	Evidence gathered, artefacts assessed, context built
3	Conclusion and Validation	Linear, gated	Analyst can articulate what happened and what to do
4	Resolution and Closure	Linear, automated	Case resolved, outcome written, closure automated

{% hint style="info" %} #### **Important** Phase 2 is the only iterative phase. Phases 1, 3 and 4 are linear and state-enforced. Analysts must not skip steps or attempt to shortcut the workflow {% endhint %} ### **Role-Based Access** CybaOps supports role-based access control, which means different members of your team can be given access to different parts of the platform depending on their function. This is particularly useful if your team includes a mix of people, for example analysts working primarily in the Detect & Respond module and investigation workflow, and more technical engineers who spend most of their time in the automation and SIEM layers. Access can be scoped so each person sees what is relevant to their role without unnecessary exposure to other areas.

Role Type	Typical Access	Notes
SOC Analyst	Incident queue, case management, timeline, artefacts, MITRE mapping, comments	Primary users of this guide
Security Engineer	SIEM, automation, connectors, detection rules, log ingestion	Platform configuration and tuning
Manager / Reviewer	Read access across cases, timelines and reporting	Oversight and audit
MSP / Third Party	Scoped to specific tenancy or function as agreed	Can be given full or limited control

Speak to your CybaVerse Account Manager to confirm the access configuration for your team before adding your users to the platform. ### **Your Views** There are two distinct interfaces for incidents: the incident view, and the ticket case management view. Analysts work in ticket case management view, this includes all information on the incident, including internal notes and comments. Managers and stakeholders may find it more useful to use the incident view from the main Detect & respond module. Artefacts and comments are still visible, but this is a more condensed overview of the incident. #### **What is on the Incidents page** You can access the following areas: * The incidents including an overview, current status and severity * Comments posted by analysts * Replies to those comments * Associated artefacts and their assessment status {% hint style="info" %} #### What is not on the incidents page Internal Notes are not visible on this page. Anything written as an Internal Note stays within the ticket case management system and is never shown on this view. The investigation timeline is also not available within this view. {% endhint %} #### **What is on the ticket case management page** The ticket view of the incident houses all the case management features. This includes a full timeline of the investigation including artefacts, internal notes, comments and status updates. This view is where all the investigation activity needs to happen from and should be where analysts spend most their time. #### **Global queue** If you’re a partner using your own analyst team for multiple customers, you will have an additional view – Global queue. This will be available to all users with the SOC user role and will be where analyst can see and action tickets across all tenancies. ### Views & Licenses


Licence permissions will restrict the views that are available for each tenancy.
Tenancies with CybaEdge will only get the incidents page.
Tenancies with CybaOne will get the incidents and ticket case management page.
Partner Tenancies with a self-managed licence will see all views including the global queue

{% hint style="info" %} #### Comment visibility Every Comment posted in both the ticket management system and the incident page \ is available in the other view and triggers a notification to the relevant parties. It's suggested to use plain language. Avoid technical shorthand and jargon. Users \ may not have a security background and is likely looking to understand what is \ happening and what they need to do, not to interpret log data. Internal Notes are for analyst-to-analyst communication and do not trigger any \ notification. Comments are for analyst-to-stakeholder communication. Keep them \ separate. {% endhint %} ## Phases {% columns %} {% column %} {% content-ref url="/pages/GR3FO01WWCNfkaQYRBPW" %} [Phase 1: Intake & Ownership](/modules/detect-and-respond-mdr/self-hosted-soc/phase-1-intake-and-ownership.md) {% endcontent-ref %} {% content-ref url="/pages/756O8IjEz2SmrqZYguGf" %} [Phase 3: Conclusion and Validation](/modules/detect-and-respond-mdr/self-hosted-soc/phase-3-conclusion-and-validation.md) {% endcontent-ref %} {% endcolumn %} {% column %} {% content-ref url="/pages/Y6WiMMZRivt9qXpB55sN" %} [Phase 2: Investigation: Core Loop](/modules/detect-and-respond-mdr/self-hosted-soc/phase-2-investigation-core-loop.md) {% endcontent-ref %} {% content-ref url="/pages/DeXVCOF44w70c6Gvi3CR" %} [Phase 4: Resolution and Closure](/modules/detect-and-respond-mdr/self-hosted-soc/phase-4-resolution-and-closure.md) {% endcontent-ref %} {% endcolumn %} {% endcolumns %} --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.cybaops.com/modules/detect-and-respond-mdr/self-hosted-soc.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.