# Release Notes 6.0

[Enhanced Executive Dashboards](/older-releases/22_release-6/enhanced-executive-dashboards)

[Upgraded Detections Experience](/older-releases/22_release-6/upgraded-detections-experience)

[Enhanced Case Management](/older-releases/22_release-6/enhanced-case-management)

[Detection Engineering](/older-releases/22_release-6/detection-engineering)

[Upgraded Investigate](/older-releases/22_release-6/upgraded-investigate)

[Faster Notebooks](/older-releases/22_release-6/faster-notebooks)

[Enterprise Intelligence](/older-releases/22_release-6/enterprise-intelligence)


# Enhanced Executive Dashboards

### Executive Dashboard

The Executive Dashboard provides a high-level overview of key metrics and operational insights. It includes:

* **Live EPS Monitoring** – Displays real-time events per second (EPS) to track current system activity and ingestion trend.
* **Detection Rule Coverage** – Provides visibility into detection rule coverage, including MITRE ATT\&CK–mapped rules, IOC-based, and correlated rule coverage.
* **Log Source Coverage** – Summarizes all available log sources with corresponding event volumes for each source.
* **Case Status & SLA Tracking** – Monitors active security cases and tracks compliance against defined SLA timelines.
* **Risk Scores** – Displays the top five risk scores by host, user, and process, along with the overall organizational risk score.
* **MITRE Coverage Overview** – Visualizes detection coverage across MITRE ATT\&CK tactics and techniques.

### Observability Dashboard

The Observability Dashboard provides detailed operational insights with a focus on performance and detection metrics. It includes:

* **EPS Metrics** – Peak, average, and current events per second. 
* **Host Online Status** – Number of active hosts per log source compared to the total hosts, providing visibility into online assets by logsources.
* **DPM Metrics** – Total number of events processed by the available log collectors or Data Pipeline Manager, offering insight into data ingestion and system throughput.
* **Top Detected Hosts, Users, and Processes** – Displays the top five hosts, users, and processes with the highest number of detections in the last 24 hours.
* **Highest False Positive Rules** – Displays the detection rules with the highest number of false positives in the last 24 hours.
* **Top MITRE Tactics and Techniques** – Displays the top 5 MITRE ATT\&CK tactics and techniques observed in detections over the last 24 hours. 

<figure><img src="https://2078222076-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MMRHZBPHlLDUc8519fX%2Fuploads%2Fr16BwIv2TgxeiYneiSk9%2F01_Dashboard.gif?alt=media&amp;token=f751bc2c-5450-4dd0-b5d1-fb8d950d58c9" alt=""><figcaption></figcaption></figure>


# Upgraded Detections Experience

The redesigned **Detections and Cases UI** simplifies triage by bringing everything into one unified workspace—eliminating the need to navigate across multiple screens. Analysts can view related activities, entity graphs, MITRE timelines, UEBA-based detections, detections and their events, original raw events, and matching rule details at a single glance.

Powered by **Garuda AI**, the platform enables intelligent exploration of detections and faster decision-making. Analysts can orchestrate responses, create or merge cases, change severity, and dismiss detections—all from a single interface—delivering a seamless and efficient SIEM experience.

The **Detections** page consists of three primary tabs: **Detections**, **Cases**, and **Orchestration**.

* **Detections**\
  This tab provides a centralized view of all detections, including detections, correlated events, UEBA insights, timelines, and rule context. Analysts can investigate detections in depth and take immediate actions such as changing severity, dismissing detections, or creating and merging cases—without leaving the page.
* **Cases**\
  The **Cases** tab is dedicated to case management. Analysts can view cases along with their associated detections, track investigation progress, update case status, adjust severity, reassign and dismiss detections based on investigative findings. This ensures structured incident handling and clear ownership throughout the response lifecycle.
* **Orchestration**\
  **Detection Orchestration** enables automated handling of detections over time based on defined criteria. Orchestration rules match detections using specific conditions and trigger predefined actions at the detection level. These actions can be automated or guided by analyst investigation, helping teams scale response efforts, reduce manual work, and ensure consistent remediation.&#x20;

<figure><img src="https://2078222076-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MMRHZBPHlLDUc8519fX%2Fuploads%2FgjByB4XM8CCSSSKA8jk3%2F04_01_Detections.gif?alt=media&amp;token=e47de3d7-7090-4fd3-9c2d-d0342c5152cc" alt=""><figcaption></figcaption></figure>


# Enhanced Case Management

Case management has been upgraded to provide deeper visibility and faster response. Each case now includes all associated alerts, timelines, and orchestration actions within a single, unified workspace. This streamlined view enables analysts to quickly understand incident scope, take informed actions, and improve response efficiency across the entire security lifecycle.

**Key highlights include:**

* Unified case workspace with all related alerts and timelines
* Integrated visibility into orchestration and response actions
* Faster understanding of incident scope and impact
* Improved response efficiency across the security lifecycle

These enhancements help security teams manage incidents more effectively, supporting quicker decisions and more consistent outcomes.

<figure><img src="https://2078222076-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MMRHZBPHlLDUc8519fX%2Fuploads%2FsPfuuRqmvdLtrgB2x8wH%2F04_02_CaseManagement.gif?alt=media&amp;token=df72178a-3e8f-40b1-adbf-49abce2cd7cf" alt=""><figcaption></figcaption></figure>


# Detection Engineering

Enhanced Detection Engineering now provides a clearer and more comprehensive view of the detection landscape by displaying key performance metrics such as hit rates and false-positive counts, along with visibility into total rules, active rules, rule coverage, and available log sources, enabling better insight into detection effectiveness and overall coverage.

<figure><img src="https://2078222076-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MMRHZBPHlLDUc8519fX%2Fuploads%2FSsLQhDFqlheoQzixQCX0%2F05_DetectionEngineering.gif?alt=media&amp;token=b65b0043-4864-4bcc-96aa-41606506c19a" alt=""><figcaption></figcaption></figure>


# Upgraded Investigate

* **High-Speed Logs:** Access months of log data in seconds with up to **10× performance** improvement.&#x20;
* **Enhanced Search:** Apply multiple filters across months of data and get results significantly faster.
* **AI-Powered Search:** Leverage AI to surface more accurate and relevant insights.&#x20;
* **Split-Window Investigation:** Analyze multiple log sources simultaneously for faster, more efficient troubleshooting.&#x20;

  ***Experience investigations that are up to 10× faster, delivering results in seconds and insights in moments.***

  **Note**: After making any input changes, click the Run Query button to apply and execute your updates.

**Investigate Overview**

<figure><img src="https://2078222076-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MMRHZBPHlLDUc8519fX%2Fuploads%2FH4mx9dfP3E2OjYqmy66K%2F02_01_investigate_Overview.gif?alt=media&amp;token=f6ee0594-ceb6-4569-a435-c3e8cfca26dd" alt=""><figcaption></figcaption></figure>

**Investigate Filters**

<figure><img src="https://2078222076-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MMRHZBPHlLDUc8519fX%2Fuploads%2FBZH7u5GIv1uKu774rtxv%2F02_02_investigate_Filters.gif?alt=media&amp;token=739bf7a9-bec7-4a06-86d3-e4173713ee52" alt=""><figcaption></figcaption></figure>


# Faster Notebooks

Notebooks have been redesigned along with UI improvements to build notebooks and charts more efficiently, delivering better performance and enabling weekly and monthly report generation up to **10× faster**.

<figure><img src="https://2078222076-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MMRHZBPHlLDUc8519fX%2Fuploads%2FWtQfh1XzguxfY9nn9yrK%2F03_Notebooks.gif?alt=media&amp;token=81954e1a-de30-4c09-ba8e-8796a5620191" alt=""><figcaption></figcaption></figure>


# Enterprise Intelligence

* Revised Enterprise Intelligence to provide enterprise-aware context for security detections.
* Added support for centralized lookup lists, including Allowed Lists, Block Lists, IOC Lists, UEBA Reference Lists, and Operational Intelligence Lists.
* Custom detection rules can be written to reference these lists to deliver enhanced detection capabilities, enabling intelligent filtering, contextual enrichment, and improved detection fidelity.
* Detections are automatically categorized and tagged based on matched intelligence lists, improving triage efficiency and response prioritization.


# 01\_Unified Platform Architecture

A Layered Architecture for Cyber Resilience

**The BluSapphire Unified Platform represents a paradigm shift in cybersecurity, moving from a complex, siloed security stack to a fully integrated, AI-driven system. This document details the platform's multi-layered architecture, designed to deliver comprehensive security from edge prevention to fully autonomous response.**

&#x20;*Figure 1: The BluSapphire Unified Platform's integrated four-layer architecture.*

<figure><img src="https://content.gitbook.com/content/-MMRHZBPHlLDUc8519fX/blobs/cmCKCSoqNAqEOtRdNjpK/mW4BDKTNjmd6rhqxT59woT%20images_1770183095831_na1fn_L2hvbWUvdWJ1bnR1L2RvY3MvYXNzZXRzL3VuaWZpZWRfcGxhdGZvcm1fYXJjaGl0ZWN0dXJl.png" alt=""><figcaption></figcaption></figure>

***

## Architecture Overview

The platform is built on four distinct, yet deeply integrated, layers that work in concert to provide a seamless security workflow. Data flows from the foundational data source layer up to the autonomous response layer, with each step adding intelligence and context. This design eliminates the integration challenges and visibility gaps that plague traditional, multi-vendor security solutions.

### Layer 1: Foundational Data Sources & Prevention

The architecture begins with a comprehensive data collection and prevention foundation, composed of two key components:

* **OneAgent:** A prevention-first endpoint protection agent that provides robust defense against malware, exploits, and other endpoint-based threats. It acts as the first line of defense, stopping attacks before they can execute and feeding critical security telemetry into the platform.
* **Log Forwarders:** The platform ingests data from a vast array of sources across the entire IT environment. This includes native support for Windows, Linux, EDR, UTMs, cloud infrastructure (AWS, Azure, GCP), and SaaS applications. This ensures complete visibility across all assets.

### Layer 2: DataStreamer™ - Universal Data Pipeline & AI Parsing

Once collected, all data is funneled into the **DataStreamer**. This intelligent data pipeline is responsible for:

* **AI-Powered Parsing:** Automatically parsing and structuring data from any source, without the need for complex, custom parsers.
* **Normalization:** Transforming disparate data formats into a unified, query-able schema.
* **Efficient Routing:** Intelligently routing data to the appropriate analysis and storage tiers, optimizing for both performance and cost.

This layer ensures that the data is clean, contextualized, and ready for high-speed analysis, eliminating the data wrangling that consumes significant resources in legacy SIEMs.

### Layer 3: SIEMless SIEM™ - Federated Detection at the Edge

The structured data from the DataStreamer feeds into the **SIEMless SIEM**, the core detection engine of the platform. Its key capabilities include:

* **Federated Detection:** A distributed architecture that allows for threat detection to occur at the edge, closer to the data source. This reduces latency and enables faster response times.
* **Advanced Analytics:** Utilizes a combination of machine learning, behavioral analysis, and correlation rules to identify both known and unknown threats with high fidelity.
* **Real-time Correlation:** Correlates events across multiple data sources in real-time to uncover complex attack patterns that would be missed by siloed tools.

### Layer 4: AR² Agentic AI - Autonomous Investigation & Response

At the apex of the architecture is the **AR² Agentic AI**. This layer receives high-fidelity alerts and contextual data from the SIEMless SIEM and performs:

* **Autonomous Investigation:** The AI agent automatically investigates alerts, gathering additional context, enriching data, and determining the full scope and impact of a threat.
* **Intelligent Response:** Based on its investigation, the AI can execute a wide range of autonomous responses, from isolating an infected endpoint to blocking a malicious IP address at the firewall.
* **Human-in-the-Loop:** While capable of full autonomy, the platform ensures that human analysts are always in control, with the ability to review, approve, or override any AI-driven action.

***

## The Integrated Workflow: From Prevention to Response

The power of the Unified Platform lies in the seamless integration of these four layers:

{% stepper %}
{% step %}

### Prevention & Collection

[`OneAgent` ](/release-6.0/05_oneagent)blocks threats at the endpoint while [`Log Forwarders`](/log-forwarding/03_log-forwarding-guide) collect telemetry from across the enterprise.
{% endstep %}

{% step %}

### Parsing & Normalization

[`DataStreamer` ](/release-6.0/03_datastreamer)ingests and prepares this data for analysis.
{% endstep %}

{% step %}

### Detection & Correlation

The [`SIEMless` ](/release-6.0/06_what-is-siemless)`SIEM` analyzes the data to detect malicious activity.
{% endstep %}

{% step %}

### Investigation & Response

The [`AR² Agentic AI`](/release-6.0/04_ar2-agentic-ai) autonomously investigates and neutralizes the threat.
{% endstep %}
{% endstepper %}

This integrated workflow enables a response time of **less than 2 minutes**, a 98% reduction in Total Cost of Ownership (TCO) compared to traditional solutions and allows for up to 95% of security operations to be run autonomously.


# Key Benefits for Business Leaders

**Think of the BluSapphire Unified Platform as replacing a chaotic security operation with a single, intelligent system that works automatically.**

### The Problem It Solves

Most organizations today use 10-20 different security tools that don't talk to each other. This creates three major problems:

1. **Overwhelming Complexity:** Your security team spends more time managing tools than actually protecting your business
2. **Slow Response:** When threats are detected, it takes hours or days to investigate and respond—plenty of time for damage to occur
3. **Excessive Costs:** Multiple vendor contracts, integration projects, and large security teams drive costs through the roof

### What BluSapphire Delivers

**98% Cost Reduction** Instead of paying for dozens of tools and large teams to manage them, you get one integrated platform that does everything. Organizations typically see their security costs drop by 98% compared to traditional approaches.**Response in Under 2 Minutes** When a threat is detected, the platform's AI automatically investigates and responds in less than 2 minutes—compared to hours or days with traditional tools. This means threats are neutralized before they can cause damage.**95% Autonomous Operations** The platform handles 95% of security operations automatically, freeing your team to focus on strategic initiatives rather than routine tasks. Your analysts become supervisors of an AI workforce rather than being overwhelmed by alerts.**Complete Visibility** One unified view of your entire security posture across all endpoints, cloud services, and networks. No more blind spots or gaps between tools.

### The Bottom Line

BluSapphire transforms cybersecurity from a complex, expensive burden into a streamlined, automated capability. You get better protection, faster response, and dramatically lower costs—all while reducing the stress on your security team.


# Flexible Deployment Architectures

{% stepper %}
{% step %}

### Centralized Cloud Deployment

**Best for:** Cloud-native organizations, startups, and SaaS-first companies.

This model consolidates the entire BluSapphire stack (DataStreamer, SIEMless SIEM, AR² AI) into a single, secure cloud region. It offers the lowest total cost of ownership (TCO), simplest management, and fastest time-to-value, making it ideal for organizations that prioritize agility and operational efficiency.

![Centralized Cloud Architecture](https://content.gitbook.com/content/-MMRHZBPHlLDUc8519fX/blobs/FvED0cCO4oxMCWJEAYnN/DIhISM3GLTz27A3vVpl0zr%20images_1770186443439_na1fn_L2hvbWUvdWJ1bnR1L2RlcGxveW1lbnRfZG9jc19saWdodC9hc3NldHMvY2VudHJhbGl6ZWRfY2xvdWRfZ2VuZXJhdGVk.webp)
{% endstep %}

{% step %}

### On-Premises Deployment

**Best for:** Regulated industries, government agencies, and air-gapped environments.

For organizations with strict data sovereignty or security requirements, the on-premises model deploys the full BluSapphire stack within your own data center. This provides maximum control, ensures all data remains within your perimeter, and enables ultra-low latency response for critical networks.

![On-Premises Architecture](https://content.gitbook.com/content/-MMRHZBPHlLDUc8519fX/blobs/MDV9eTOmsIhcfSCOtKdN/DIhISM3GLTz27A3vVpl0zr%20images_1770186443439_na1fn_L2hvbWUvdWJ1bnR1L2RlcGxveW1lbnRfZG9jc19saWdodC9hc3NldHMvb25fcHJlbWlzZXNfZ2VuZXJhdGVk.webp)
{% endstep %}

{% step %}

### Hybrid Cloud Deployment

**Best for:** Established enterprises with mixed on-premises and cloud infrastructure.

This model bridges the gap between legacy and modern environments. By placing DataStreamer instances both on-premises and in the cloud, it provides unified visibility and federated detection across your entire estate. It’s the perfect solution for organizations undergoing a gradual and secure cloud migration.

![Hybrid Cloud Architecture](https://content.gitbook.com/content/-MMRHZBPHlLDUc8519fX/blobs/Z7dmstgMqfXFVMp8DNOt/DIhISM3GLTz27A3vVpl0zr%20images_1770186443439_na1fn_L2hvbWUvdWJ1bnR1L2RlcGxveW1lbnRfZG9jc19saWdodC9hc3NldHMvaHlicmlkX2Nsb3VkX2dlbmVyYXRlZA.webp)
{% endstep %}

{% step %}

### Multi-Cloud Deployment

**Best for:** Organizations seeking vendor independence and leveraging multiple cloud providers (AWS, Azure, GCP).

This architecture provides a unified security layer across all your cloud environments. By deploying regional detection instances in each cloud that feed into a central AI correlation engine, you can prevent vendor lock-in, enhance redundancy, and manage your entire multi-cloud security posture from a single console.

![Multi-Cloud Architecture](https://content.gitbook.com/content/-MMRHZBPHlLDUc8519fX/blobs/2QnW0Zr56jHVqQYtMOlo/DIhISM3GLTz27A3vVpl0zr%20images_1770186443439_na1fn_L2hvbWUvdWJ1bnR1L2RlcGxveW1lbnRfZG9jc19saWdodC9hc3NldHMvbXVsdGlfY2xvdWRfZ2VuZXJhdGVk.webp)
{% endstep %}

{% step %}

### Federated Edge Detection

**Best for:** Global enterprises, retail chains, and industrial environments with many distributed sites.

Engineered for speed and efficiency, this model deploys lightweight detection and response capabilities to the very edge of your network. It enables sub-second threat containment at the source, dramatically reduces bandwidth costs by processing data locally, and ensures remote sites remain protected even during network outages.

![Federated Edge Architecture](https://content.gitbook.com/content/-MMRHZBPHlLDUc8519fX/blobs/Iin64mEKasBkmaIv75Q5/DIhISM3GLTz27A3vVpl0zr%20images_1770186443439_na1fn_L2hvbWUvdWJ1bnR1L2RlcGxveW1lbnRfZG9jc19saWdodC9hc3NldHMvZmVkZXJhdGVkX2VkZ2VfZ2VuZXJhdGVk.webp)
{% endstep %}

{% step %}

### MSSP Multi-Tenant Deployment

**Best for:** Managed Security Service Providers (MSSPs) delivering security-as-a-service.

Purpose-built for service providers, this model allows for the management of multiple customers from a single, shared platform. It combines cost-efficient shared infrastructure with cryptographic tenant isolation and dedicated performance, enabling rapid customer onboarding and scalable service delivery.

![MSSP Multi-Tenant Architecture](https://content.gitbook.com/content/-MMRHZBPHlLDUc8519fX/blobs/Fza2PrGPpHCEb0jN6v7i/DIhISM3GLTz27A3vVpl0zr%20images_1770186443439_na1fn_L2hvbWUvdWJ1bnR1L2RlcGxveW1lbnRfZG9jc19saWdodC9hc3NldHMvbXNzcF9tdWx0aXRlbmFudF9nZW5lcmF0ZWQ.webp)
{% endstep %}

{% step %}

### Global Distributed with Regional Hubs

**Best for:** Large multinational corporations requiring a follow-the-sun security operation.

This is the pinnacle of scale and resilience, establishing full BluSapphire stacks in key geographic regions (e.g., Americas, EMEA, APAC). It guarantees compliance with regional data sovereignty laws, delivers high-performance local operations, and enables a 24/7 global SOC with centralized coordination.

![Regional Hubs Architecture](https://content.gitbook.com/content/-MMRHZBPHlLDUc8519fX/blobs/XxkkSKM1zBf5PrxX5GJw/DIhISM3GLTz27A3vVpl0zr%20images_1770186443439_na1fn_L2hvbWUvdWJ1bnR1L2RlcGxveW1lbnRfZG9jc19saWdodC9hc3NldHMvcmVnaW9uYWxfaHVic19nZW5lcmF0ZWQ.webp)
{% endstep %}
{% endstepper %}

### Choosing Your Model & Planning for the Future

Selecting the right architecture is a strategic decision. The following resources help you compare models and understand the flexibility of the BluSapphire platform.

#### Deployment Model Comparison

This matrix provides a clear, at-a-glance comparison of each model across key decision factors like data control, complexity, and cost.

![Comparison Matrix](https://content.gitbook.com/content/-MMRHZBPHlLDUc8519fX/blobs/L0ZnT24oKGhviWEWZqRi/DIhISM3GLTz27A3vVpl0zr%20images_1770186443439_na1fn_L2hvbWUvdWJ1bnR1L2RlcGxveW1lbnRfZG9jc19saWdodC9hc3NldHMvY29tcGFyaXNvbl9tYXRyaXhfZ2VuZXJhdGVk.webp)

#### Flexible Migration Pathways

Your choice today doesn’t lock you in for tomorrow. BluSapphire is designed for seamless evolution. You can start with the model that fits your current needs and migrate to another as your business grows, all without downtime or gaps in security coverage.

![Migration Pathways](https://content.gitbook.com/content/-MMRHZBPHlLDUc8519fX/blobs/tl4M5Hm1Flx0T1VMvaCj/DIhISM3GLTz27A3vVpl0zr%20images_1770186443439_na1fn_L2hvbWUvdWJ1bnR1L2RlcGxveW1lbnRfZG9jc19saWdodC9hc3NldHMvbWlncmF0aW9uX3BhdGh3YXlzX2dlbmVyYXRlZA.webp)


# Federated Arch Industry Use Cases

**The modern global enterprise is defined by distributed operations, multi-cloud infrastructure, and strict, geographically-specific data regulations. Traditional, centralized security models are no longer viable—they are too slow, too expensive, and create significant compliance risks. BluSapphire’s federated architecture with edge detection is purpose-built for this new reality.**

This document showcases how this innovative architecture solves complex security challenges across four key industries.

{% stepper %}
{% step %}

### Global Manufacturing

A multinational manufacturing giant with factories in the US, Germany, China, and Brazil faces a complex web of data sovereignty laws (GDPR, PIPL) and the critical need to protect its Operational Technology (OT) in real-time.

#### Before: The Centralized Bottleneck

The traditional approach of backhauling all security data to a central SIEM is a recipe for failure. It creates massive bandwidth costs, violates data localization laws, and introduces dangerous latency in threat detection for critical factory floor systems.

![Manufacturing Before](https://content.gitbook.com/content/-MMRHZBPHlLDUc8519fX/blobs/LEmXMxxyQTwcku5O6fI8/oOT2vPm4AZkwEmBf2OAWtG%20images_1770188418217_na1fn_L2hvbWUvdWJ1bnR1L2ZlZGVyYXRlZF9zY2VuYXJpb3NfZG9jcy9hc3NldHMvbWFudWZhY3R1cmluZ19iZWZvcmVfZ2VuZXJhdGVk.webp)

#### After: BluSapphire Federated Architecture

By deploying **SIEMless SIEM** at each factory, all data is processed locally, ensuring 100% compliance and sub-second detection of OT threats. Only high-fidelity alerts are sent to the central **AR² AI** for global correlation. This eliminates backhaul costs, solves data sovereignty, and provides both local autonomy and global visibility.

![Manufacturing After](https://content.gitbook.com/content/-MMRHZBPHlLDUc8519fX/blobs/lurO0J2WWTinDUedC5y2/oOT2vPm4AZkwEmBf2OAWtG%20images_1770188418217_na1fn_L2hvbWUvdWJ1bnR1L2ZlZGVyYXRlZF9zY2VuYXJpb3NfZG9jcy9hc3NldHMvbWFudWZhY3R1cmluZ19hZnRlcl9nZW5lcmF0ZWQ.webp)

| Benefit            | Result                                                            |
| ------------------ | ----------------------------------------------------------------- |
| **Compliance**     | 100% compliant with GDPR, PIPL, and other data localization laws. |
| **Cost Reduction** | 90% reduction in data transfer and storage costs.                 |
| **Speed**          | Real-time threat detection for critical OT/ICS environments.      |
| **Simplicity**     | Unified visibility and management from a single global console.   |
| {% endstep %}      |                                                                   |

{% step %}

### Global Insurance

A large insurance firm with operations across the US, Europe, and Asia-Pacific holds vast amounts of sensitive PII and health data. It must comply with GDPR, PIPEDA, and other regulations while trying to detect sophisticated, cross-border fraud.

#### Before: The Compliance & Fraud Blind Spot

Strict data residency laws force the company to maintain separate, expensive security stacks in each region. This creates data silos that make it impossible to detect global fraud rings that operate across multiple jurisdictions, leading to significant financial losses and compliance risks.

![Insurance Before](https://content.gitbook.com/content/-MMRHZBPHlLDUc8519fX/blobs/jAnf4fPnk58xZHL9pK2s/oOT2vPm4AZkwEmBf2OAWtG%20images_1770188418217_na1fn_L2hvbWUvdWJ1bnR1L2ZlZGVyYXRlZF9zY2VuYXJpb3NfZG9jcy9hc3NldHMvaW5zdXJhbmNlX2JlZm9yZV9nZW5lcmF0ZWQ.webp)

#### After: Federated Compliance & Intelligence

BluSapphire’s federated model keeps all sensitive data within its country of origin. The local **SIEMless SIEM** instances handle compliance, while the global **AR² AI** correlates anonymized threat patterns and metadata. This allows the company to detect global fraud campaigns *without* moving sensitive data, solving both compliance and security challenges simultaneously.

![Insurance After](https://content.gitbook.com/content/-MMRHZBPHlLDUc8519fX/blobs/w5hG40Spccaz9VhrkAsy/oOT2vPm4AZkwEmBf2OAWtG%20images_1770188418217_na1fn_L2hvbWUvdWJ1bnR1L2ZlZGVyYXRlZF9zY2VuYXJpb3NfZG9jcy9hc3NldHMvaW5zdXJhbmNlX2FmdGVyX2dlbmVyYXRlZA.webp)

| Benefit                | Result                                                                       |
| ---------------------- | ---------------------------------------------------------------------------- |
| **Data Sovereignty**   | Guarantees PII and financial data never leave their country of origin.       |
| **Fraud Detection**    | Detects sophisticated, cross-border fraud patterns in real-time.             |
| **Cost Reduction**     | Eliminates redundant regional SOCs, reducing operational costs by up to 80%. |
| **Unified Compliance** | A single framework provides unified reporting for all global regulators.     |
| {% endstep %}          |                                                                              |

{% step %}

### MRO & Airport Operations

An MRO organization managing a portfolio of airports across multiple continents must protect critical infrastructure, ensure 24/7 operational uptime, and comply with strict aviation security regulations.

#### Before: Siloed and Slow Security

With each airport operating its own isolated security monitoring, there is no way to correlate threats across the entire portfolio. The high cost of bandwidth from remote locations makes centralized logging impractical, and the resulting latency leaves critical systems vulnerable.

![MRO Before](https://content.gitbook.com/content/-MMRHZBPHlLDUc8519fX/blobs/iKMHzJ5X3WgxoJLwdXoL/oOT2vPm4AZkwEmBf2OAWtG%20images_1770188418217_na1fn_L2hvbWUvdWJ1bnR1L2ZlZGVyYXRlZF9zY2VuYXJpb3NfZG9jcy9hc3NldHMvbXJvX2JlZm9yZV9nZW5lcmF0ZWQ.webp)

#### After: Autonomous Edge Security

By deploying a **SIEMless SIEM** at each airport, BluSapphire provides autonomous local defense. Each airport can detect and respond to threats independently, ensuring resilience even if disconnected from the central network. This edge processing reduces bandwidth costs by over 95% and provides the real-time response needed to protect critical aviation systems.

![MRO After](https://content.gitbook.com/content/-MMRHZBPHlLDUc8519fX/blobs/xKlABF43K3M0fgr4b3UW/oOT2vPm4AZkwEmBf2OAWtG%20images_1770188418217_na1fn_L2hvbWUvdWJ1bnR1L2ZlZGVyYXRlZF9zY2VuYXJpb3NfZG9jcy9hc3NldHMvbXJvX2FmdGVyX2dlbmVyYXRlZA.webp)

| Benefit                 | Result                                                                             |
| ----------------------- | ---------------------------------------------------------------------------------- |
| **Resilience**          | Each airport operates autonomously, eliminating single points of failure.          |
| **Speed**               | Sub-second detection and response for critical physical and cyber systems.         |
| **Cost Savings**        | Drastically reduces bandwidth and infrastructure costs.                            |
| **Global Intelligence** | Central command gains visibility into coordinated threats targeting the portfolio. |
| {% endstep %}           |                                                                                    |

{% step %}

### Global Banking

A major international bank must navigate a minefield of financial regulations (MAS, HKMA, RBI) in every country it operates in. It needs to prevent real-time fraud while ensuring customer financial data never crosses borders.

#### Before: The High Cost of Compliance

The only way to meet regulatory requirements with a traditional model is to build a completely separate, multi-million dollar SOC in every country. This creates massive cost overhead and leaves the bank blind to global money laundering schemes and coordinated cyberattacks.

![Banking Before](https://content.gitbook.com/content/-MMRHZBPHlLDUc8519fX/blobs/D1BhnlSiO2LrX4jpxdZi/oOT2vPm4AZkwEmBf2OAWtG%20images_1770188418217_na1fn_L2hvbWUvdWJ1bnR1L2ZlZGVyYXRlZF9zY2VuYXJpb3NfZG9jcy9hc3NldHMvYmFua2luZ19iZWZvcmVfZ2VuZXJhdGVk.webp)

#### After: Federated Zero Trust Architecture

BluSapphire’s federated architecture provides a **SIEMless SIEM** instance for each jurisdiction, guaranteeing data residency. The global **AR² AI** then uses a Zero Trust model to correlate threat intelligence and fraud patterns without ever accessing the raw financial data. This delivers real-time global fraud prevention while satisfying every local regulator.

![Banking After](https://content.gitbook.com/content/-MMRHZBPHlLDUc8519fX/blobs/lujCCF1cCHI6W83KxlqF/oOT2vPm4AZkwEmBf2OAWtG%20images_1770188418217_na1fn_L2hvbWUvdWJ1bnR1L2ZlZGVyYXRlZF9zY2VuYXJpb3NfZG9jcy9hc3NldHMvYmFua2luZ19hZnRlcl9nZW5lcmF0ZWQ.webp)

| Benefit                        | Result                                                                 |
| ------------------------------ | ---------------------------------------------------------------------- |
| **Regulatory Certainty**       | Guarantees compliance with the strictest financial data laws globally. |
| **Real-Time Fraud Prevention** | Detects and stops global financial crime in its tracks.                |
| **Massive Cost Reduction**     | Consolidates security operations, reducing costs by over 75%.          |
| **Zero Trust Security**        | Enforces a consistent, high-security posture across all regions.       |
| {% endstep %}                  |                                                                        |
| {% endstepper %}               |                                                                        |


# 02\_What is OnePlatform?

**The AI-First Security Platform for the Post-SIEM World**

BluSapphire OnePlatform is a unified, AI-native security operations platform that replaces the fragmented and costly traditional security stack. It provides a single, streamlined solution for data ingestion, threat detection, investigation, and autonomous response, eliminating vendor lock-in and dramatically reducing total cost of ownership (TCO).

<figure><img src="https://2078222076-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MMRHZBPHlLDUc8519fX%2Fuploads%2FD74WI0prI1R7rKCevgIB%2FBeforeAfter.png?alt=media&amp;token=3cb2598a-e641-4423-8d48-330656dab92f" alt=""><figcaption></figcaption></figure>

## Key Components

OnePlatform is comprised of several integrated components that work together to deliver a seamless security experience:

* [**DataStreamer**](/release-6.0/03_datastreamer)**:** An AI-powered data ingestion and routing engine that normalizes and enriches data from any source, then routes it to any destination.
* [**SIEMless**](/release-6.0/06_what-is-siemless)**™:** A next-generation SIEM with an AI-first architecture, providing real-time threat detection, signal mapping, and UEBA.
* [**AR² Agentic AI**](/release-6.0/04_ar2-agentic-ai)**:** An autonomous response engine that acts as a tireless AI analyst, investigating threats and taking action in minutes.
* [**OneAgent**](/release-6.0/05_oneagent)**:** A lightweight, prevention-first endpoint agent that provides deep visibility and control.

## Core Principles

* **AI-First:** Machine learning and artificial intelligence are at the core of every component, from data parsing to threat response.
* **Unified & SIEMless™:** A single, integrated platform eliminates the need for separate SIEM, SOAR, and data lake solutions.
* **Lock-In Free:** Built on open standards, allowing you to send your data wherever you need it, without penalty.
* **Cost-Effective:** A consumption-based model and dramatic reduction in operational overhead deliver up to 80% TCO savings.
* **Highly Scalable:** A petabyte-scale data lake foundation ensures you can handle any volume of data.

## Use Cases

* **Threat Detection and Response:** Unify your security operations and accelerate your mean time to respond (MTTR) from hours to minutes.
* **SIEM Replacement:** Modernize your security stack and escape the high costs and complexity of legacy SIEMs.
* **Security Data Lake:** Build a flexible, cost-effective security data lake for long-term analytics and compliance.
* **MSSP Enablement:** Deliver next-generation security services with a multi-tenant, scalable, and efficient platform.


# BluSapphire\_Use\_Cases

## BluSapphire Use Cases: Transforming Security Operations for the Modern Enterprise

### Executive Summary

This document presents five comprehensive use cases that demonstrate how BluSapphire's security solutions—OnePlatform, DataStreamer, and AR2—address challenges facing organizations and Managed Security Service Providers (MSSPs). These use cases illustrate replacing aging security infrastructure, reducing costs, eliminating vendor lock-in, and improving ROI of security operations.

The five use cases covered in this document are:

* Using OnePlatform to Replace Existing SIEM for MSSPs
* Using DataStreamer and OnePlatform to Augment Existing SIEM
* Using DataStreamer to Streamline Log Ingestion and Gain Visibility
* Replacing Aging QRadar On-Prem Installations
* MSSPs Adopting AR2 to Improve ROI in Security Operations

***

## Use Case 1: Replacing Existing SIEM for MSSPs with BluSapphire OnePlatform

### Introduction

In the rapidly evolving landscape of cybersecurity, Managed Security Service Providers (MSSPs) rely on the power and efficiency of their SIEM platform. Many traditional SIEM solutions are complex, expensive to scale, and struggle to provide real-time visibility and actionable intelligence. This use case outlines replacing existing SIEM solutions with BluSapphire OnePlatform, a cloud-native, unified security operations platform.

### The Problem with Traditional SIEMs for MSSPs

Traditional SIEMs present multiple challenges for MSSPs:

* High Total Cost of Ownership (TCO): licensing often based on data ingestion (EPS or GB/day), plus infrastructure costs.
* Complexity and Management Overhead: require dedicated experts for deployment, tuning, and maintenance.
* Scalability Challenges: performance degradation as data and client base grow.
* Limited Visibility and Context: difficulty ingesting and correlating cloud, SaaS, OT/ICS, and other sources.
* Alert Fatigue and Slow Response Times: high volume of alerts and false positives overload analysts.

### The BluSapphire OnePlatform Solution

BluSapphire OnePlatform is a cloud-native security operations platform addressing the above challenges:

#### Unified Platform for Comprehensive Visibility

OnePlatform combines SIEM, SOAR, NDR, and EDR to provide a comprehensive view across network, endpoint, cloud, and hybrid environments.

#### Cost-Effective and Predictable Pricing

Pricing is not based on ingestion volume, enabling predictable costs and easier scaling. Cloud-native architecture removes the need for expensive on-prem hardware.

#### Scalability and Performance

Designed to scale on demand, preserving performance as MSSPs grow their client base.

#### Automation and Orchestration with SOAR

Built-in SOAR automates alert triage, enrichment, and response, freeing analysts for higher-value work and reducing response times.

#### Advanced Threat Detection and Response

Leverages machine learning, behavioral analytics, and threat intelligence alongside NDR and EDR for deep visibility and automated containment.

#### Multi-Tenancy and Client Management

Multi-tenant architecture manages multiple clients from one console with logical data separation, customizable dashboards, reports, and alerts.

### Business Benefits for MSSPs

* Improved Profitability: lower costs and reduced management overhead.
* Enhanced Customer Retention: better detection/response improves client satisfaction.
* Competitive Advantage: differentiated, efficient, and effective service offering.
* Future-Proofing: cloud-native platform continuously updated with new features.

### Conclusion

BluSapphire OnePlatform is a compelling alternative for MSSPs replacing legacy SIEMs. Its unified capabilities, predictable pricing, scalability, and automation help MSSPs improve security operations, profitability, and client satisfaction.

***

## Use Case 2: Augmenting Existing SIEM with DataStreamer and OnePlatform for Cost Reduction and Data Independence

### Introduction

SIEMs are central to security operations but face a data deluge from cloud, IoT, and digital transformation. This increases ingestion costs and vendor lock-in. Augmenting an existing SIEM with BluSapphire DataStreamer and OnePlatform reduces data sent to legacy SIEMs while providing flexible, scalable log management.

### The SIEM Hostage Situation: A Vicious Cycle of Cost and Complexity

Key issues with traditional SIEMs:

* Runaway Costs: pay-per-ingestion models lead to unpredictable/exorbitant fees.
* Vendor Lock-In: proprietary formats make migration difficult/expensive.
* Data Silos and Lack of Ownership: data stored in vendor formats/cloud limits usage.
* Inflexibility and Lack of Innovation: slow vendor innovation and poor integration.

### The BluSapphire Solution: A Path to Data Independence

Combine DataStreamer and OnePlatform to augment rather than rip-and-replace legacy SIEMs.

#### BluSapphire DataStreamer: Intelligent Log Filtering and Forwarding

* Filter out low-value data (informational/debug) before sending to legacy SIEM.
* Forward high-value security data (auth logs, firewall logs, IDS alerts) to the SIEM.
* Route data to multiple destinations (legacy SIEM, data lake, cloud storage, OnePlatform).

#### BluSapphire OnePlatform: Modern, Scalable Log Management

* Cost-Effective, Long-Term Storage: not charged per ingestion; data remains online and accessible.
* Open Data Formats: stores data in JSON/open formats to avoid vendor lock-in and enable broader analysis.
* Powerful Search and Analytics: robust query and UI for finding and investigating incidents.
* Unified Platform for Security Operations: includes SOAR, NDR, EDR besides log management.

### A Real-World Scenario: Augmenting a Legacy SIEM

A financial services organization reduces its legacy SIEM ingestion by up to 80% using DataStreamer to filter low-value logs and forwards critical logs to the SIEM while storing remaining data in OnePlatform. Benefits include:

* Reduced Costs: significant licensing savings.
* Improved Performance: fewer false positives and better SIEM performance.
* Data Independence: full copy of logs in open format on OnePlatform.
* Enhanced Security Posture: modern analytics and broader capabilities.

### Conclusion

DataStreamer + OnePlatform provides a way out of the SIEM hostage situation: reduce costs, eliminate vendor lock-in, and gain a flexible, scalable log management architecture without immediately ripping out existing SIEM investments.

***

## Use Case 3: Gaining Visibility and Control over Log Ingestion with BluSapphire DataStreamer

### Introduction

Log data is essential to security operations, but collection and forwarding pipelines are often opaque. Replacing a patchwork of forwarders with BluSapphire DataStreamer gives visibility and control over log ingestion, reducing data loss and security gaps.

### The Black Box Problem: A Lack of Visibility and Control

Problems with fragmented log pipelines:

* Data Loss and Integrity Issues: uncertain that all logs are collected and transmitted correctly.
* Security Gaps: undetected stoppage of critical log sources.
* Troubleshooting Challenges: difficult root-cause identification and long resolution times.
* Inability to Adapt to Change: dynamic environments require flexible ingestion pipelines.

### The BluSapphire DataStreamer Solution: A Window into the Log Ingestion Pipeline

DataStreamer provides a unified, transparent pipeline:

#### Unified Data Collection

Collects logs from OS, applications, network devices, cloud services, and more; supports many formats and protocols.

#### Real-Time Visibility and Monitoring

Graphical UI shows data flows, metrics, and alerts for pipeline health.

#### Data Processing and Enrichment

Parses, normalizes, and enriches logs (geolocation, threat intelligence) in transit.

#### Intelligent Routing and Filtering

Routes high-value data to SIEMs and low-value data to long-term storage (e.g., OnePlatform).

#### Centralized Management and Control

Single console to configure sources, flows, processing, and monitoring.

### A Real-World Scenario: From Black Box to Glass Box

A retail organization replaces disparate forwarders with DataStreamer agents and central instance. Defining flows and monitoring pipeline health yields:

* Improved Visibility: complete view of log flows.
* Reduced Data Loss: real-time alerts on pipeline issues.
* Enhanced Security Posture: confidence in data collection and delivery.
* Improved Efficiency: single point of management reduces operational overhead.

### Conclusion

DataStreamer converts opaque log pipelines into transparent, controllable systems, improving security posture, reducing loss, and simplifying operations.

***

## Use Case 4: Replacing Aging QRadar On-Prem Installations with BluSapphire DataStreamer and OnePlatform

### Introduction

Many organizations still rely on IBM QRadar on-prem deployments, which face limits in the cloud era. BluSapphire DataStreamer and OnePlatform offer a cloud-native alternative to modernize security operations and reduce TCO.

### The Pains of an Aging QRadar On-Premise Deployment

Key challenges:

* Architectural Rigidity and Complexity: scaling requires hardware procurement and complex configuration.
* Spiraling TCO: licensing, hardware, maintenance, and specialized personnel costs.
* The Cloud Conundrum: poor native fit for cloud environments leading to visibility gaps.
* The Data Hostage Situation: proprietary formats hinder migration.
* Innovation Stagnation: lagging detection of emerging threats.

### The BluSapphire Solution: A Modern, Cloud-Native Alternative

BluSapphire combines OnePlatform and DataStreamer:

#### BluSapphire OnePlatform: The Future of Security Operations

* Cloud-Native Architecture: eliminates on-prem hardware and management overhead.
* Predictable and Cost-Effective Pricing: not tied to ingestion volume.
* Unified Visibility: single view across on-premise, cloud, and hybrid.
* Open Data Formats: data ownership and portability via JSON/open formats.

#### BluSapphire DataStreamer: The Bridge to a Modern SIEM

* Phased Migration: send a subset of logs to OnePlatform while continuing QRadar.
* Dual Forwarding: forward logs to both QRadar and OnePlatform to avoid visibility gaps.
* Data Transformation: convert QRadar formats to open formats for OnePlatform.

### A Real-World Scenario: A Seamless Transition from QRadar to BluSapphire

A healthcare organization uses DataStreamer to phase migration from QRadar to OnePlatform:

* Phase 1: forward subset (e.g., cloud logs) to OnePlatform.
* Phase 2: dual forward all logs to compare platforms and automate tasks via SOAR.
* Phase 3: decommission QRadar and fully adopt OnePlatform.

Benefits:

* TCO reduction >50%.
* Unified view across environments.
* Automation frees analysts for strategic work.

### Conclusion

Replacing QRadar on-prem with BluSapphire modernizes security operations, reduces costs, and provides cloud-native agility and future-proofing.

***

## Use Case 5: MSSPs Adopt AR2 to Augment and Improve ROI in Security Operations

### Introduction

MSSPs must deliver effective, scalable security services while managing costs. High alert volumes and analyst burnout make automation essential. BluSapphire AR2 is an AI-powered virtual analyst that autonomously investigates and responds to alerts, improving ROI.

### The MSSP Challenge: Drowning in a Sea of Alerts

Key issues:

* Alert Fatigue and Analyst Burnout: high volumes and false positives.
* Slow Response Times: manual investigations are time-consuming.
* High Operational Costs: hiring and retaining analysts is expensive.
* Scalability Limitations: growth increases alert volumes beyond human capacity.

### The BluSapphire AR2 Solution: An AI-Powered Analyst for Every SOC

AR2 augments human analysts with autonomous investigation and response:

#### Autonomous Alert Investigation

Investigates alerts from SIEMs, EDRs, NDRs using ML, NLP, and threat intelligence to enrich and contextualize alerts.

#### Intelligent Response and Remediation

Can isolate endpoints, block IPs, disable accounts, and escalate to humans when needed.

#### Continuous Learning and Improvement

Learns from investigations and human feedback to improve accuracy over time.

#### Seamless Integration

Integrates with existing SIEMs, EDRs, NDRs, ticketing, and threat intel platforms.

### A Real-World Scenario: A Market SOC with 300+ Customers

A large MSSP integrates AR2 with its SIEM. In the first month, AR2 handles 82% of tickets autonomously, which leads to:

* Reduced analyst workload and burnout.
* Faster response times and improved client outcomes.
* Cost savings from reduced reliance on L1/L2 headcount.
* Improved morale and ability to focus on advanced tasks.

### The ROI of AR2: A Clear and Compelling Business Case

Adopting AR2 enables MSSPs to:

* Reduce Operational Costs: lower headcount requirements and faster handling.
* Improve Operational Efficiency: automate mundane investigations.
* Enhance Customer Satisfaction: faster and more consistent responses.
* Gain Competitive Advantage: superior service offering and scalability.

### Conclusion

AR2 transforms MSSP operations by automating investigations and responses, improving efficiency, reducing costs, and enabling higher-value security services.

***

### Final Thoughts

These five use cases demonstrate how BluSapphire OnePlatform, DataStreamer, and AR2 help organizations and MSSPs replace or augment legacy SIEMs, gain control over log pipelines, transition from aging on-prem deployments, and dramatically improve ROI through AI-driven automation. By adopting these solutions, organizations can build more agile, scalable, and effective security operations to meet the modern threat landscape.


# 03\_DataStreamer

AI-Powered Data Ingestion and Routing

**AI-Powered Data Ingestion and Routing**

BluSapphire DataStreamer™ is an intelligent data pipeline that gives you control over your security data. It ingests data from any source, uses AI to automatically parse, normalize, and enrich it, and then routes it to any destination—including BluSapphire OnePlatform, third-party SIEMs, or data lakes. DataStreamer breaks vendor lock-in and dramatically reduces the cost and complexity of managing security data.

<figure><img src="https://2078222076-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MMRHZBPHlLDUc8519fX%2Fuploads%2FZlVYEBvZ2KeLArTXmIVx%2Fdatastreamer_architecture_transparent.png?alt=media&amp;token=242f1563-6522-478c-9803-56dc9f1ccd62" alt=""><figcaption></figcaption></figure>

## Key Features

* **AI-Powered Parsing:** Automatically parses and normalizes data from over 200 sources without the need for manual Grok or Regex rules.
* **Ingest Once, Route Anywhere:** Ingest data once and route it to multiple destinations simultaneously, including BluSapphire, Splunk, Sentinel, S3, Kafka, and more.
* **Data Enrichment:** Enriches data with threat intelligence, geolocation, and other contextual information in real-time.
* **Logarithmic Scaling:** A highly scalable architecture that can handle millions of events per second (EPS) with a small footprint.
* **Zero Vendor Lock-In:** An open, standards-compliant architecture gives you full control over your data.
* **Massive Cost Reduction:** Reduce your data pipeline costs by up to 60% by eliminating the need for expensive data ingestion and storage solutions.

## How It Works

DataStreamer's AI-powered pipeline automates the entire data preparation process:

{% stepper %}
{% step %}

### Ingest

Collects data from a wide variety of sources, including firewalls, cloud, servers, endpoints, and databases.
{% endstep %}

{% step %}

### Parse & Normalize

The AI engine automatically identifies the data source and applies the correct parsing and normalization rules.
{% endstep %}

{% step %}

### Enrich

Adds valuable context to the data, such as threat intelligence feeds and user information.
{% endstep %}

{% step %}

### Route

Sends the prepared data to your desired destinations based on flexible, user-defined rules.
{% endstep %}
{% endstepper %}

## Benefits

* **Eliminate Manual Parsing:** Free up your engineering team from the tedious and error-prone task of writing and maintaining parsing rules.
* **Gain Control of Your Data:** Break free from vendor lock-in and send your data where you need it, when you need it.
* **Reduce Costs:** Dramatically lower your data ingestion, storage, and management costs.
* **Accelerate Security Projects:** Onboard new data sources in minutes, not weeks, and get value from your data faster.


# Getting Started

## System Requirement&#x73;**:**

The Data Pipeline Manager (DPM) can be deployed both physically (or) virtually with the below hardware requirements. DPM will automatically take advantage of the resources available.

| **Minimum**                                           | **Recommended**                                        |
| ----------------------------------------------------- | ------------------------------------------------------ |
| 4 vCPUs, 8GB RAM, 125GB SSD of primary storage, 1 NIC | 8 vCPUs, 16GB RAM, 250GB SSD of primary storage, 1 NIC |

*1 vCPU = 1 ARM physical CPU or 0.5 Intel physical CPU with hyperthreading*.

#### **Memory**

As a basic starting point, we advise 2 GiB of memory per vCPU. Because of in-memory batching and buffering, memory utilization rises as the number of destinations increases. If you have several destinations, you might want to think about using disk buffers or upgrading the memory. Since disk buffers are slower, we advise boosting memory wherever it is practical.


# Basic Concepts

To understand the Data Pipeline Manager (DPM), it's helpful to visualize it as a system that receives events from multiple sources, processes them, and then transmits them to one or more destinations. Let's focus on the core functionalities offered by the Data Pipeline Manager (DPM). The primary components of the interface are:

* **Sources:** Responsible for collecting data from various input points.
* **Pipelines**: Manages the transformation of data, defining how it should be processed.
* **Enrichments**: Enhances events with additional information like GeoIP information.
* **Destinations**: Route the processed data to its final location.

These elements work together to efficiently handle and process your data within the DPM system.

## Sources:

Sources are configurations that specify where the system should pull data from or how to receive data that is pushed to it. They enable DPM to consume data from various origins, sources include:

* Agents like Filebeat, Winlogbeat, Syslog, TCP, and other external systems that push data to the DPM
* File Stores: Remote file storage solutions from which the DPM can pull data.

Sources are essential for integrating and onboarding data into the DPM. They enable the ingestion of data from various inputs.

## Pipelines:

Pipelines in the Data Pipeline Manager (DPM) are sequences of transformations that process and modify data as it is ingested. These transformations can include:

* **Parsing:** Extracting relevant information from raw data.
* **Filtering:** Removing or including specific data based on set criteria.

When data enters DPM, they are initially routed and pre-processed based on key fields such as **observer.type**, **observer.product**, **observer.vendor,** and **source\_type**. These events are then directed to the start of a pipeline.

As the events move through the pipeline, each transformation applies its processing rules. The output from one transformation is passed to the next, ensuring that data is processed in a structured and sequential manner until it reaches the end of the pipeline.

## Enrichments:

Depending on the configured enrichment type and specific conditions, events are enhanced with additional information, such as GeoIP data. This enrichment process adds valuable context to each event, enabling deeper analysis and insights.

## Destinations:

Destinations in the Data Pipeline Manager (DPM) are the endpoints where processed events are sent. You can configure the DPM to send events to one or multiple destinations, such as AWS S3, Kafka, Vector, and others.

The method of processing and transmitting events to each destination varies based on the downstream service:

* **AWS S3 Destination:** Buffers all processed events and flushes them in batches, which helps optimize data storage and transfer efficiency.
* **Socket Destination:** Streams individual events in real-time, enabling immediate processing.

Understanding the characteristics of each destination allows you to configure your pipelines effectively, ensuring that data is managed and transferred according to your specific needs.


# Sizing & Capacity Planning

## DataStreamer Sizing & Capacity Planning

**Enterprise Capability, Startup Agility.**&#x20;

DataStreamer is engineered for high performance and resource efficiency, allowing you to handle massive data volumes without the massive infrastructure costs. This guide provides a comprehensive methodology for sizing your DataStreamer deployment to meet your specific throughput and processing needs.

### The DataStreamer Performance Philosophy

DataStreamer is built in Rust, a modern systems programming language that guarantees memory safety and exceptional performance. Unlike traditional data pipelines that rely on heavy runtimes like the JVM (Java Virtual Machine) or interpreted languages, DataStreamer compiles to a native binary that runs directly on the CPU. This results in:

* **Lower CPU Usage**: More processing power dedicated to your data, not the runtime.
* **Minimal Memory Footprint**: Significantly reduced RAM requirements compared to alternatives.
* **Predictable Performance**: Consistent throughput without the garbage collection pauses common in other systems.

Our core design principle is **throughput-based sizing**. Instead of counting components or pipelines, we focus on the volume of data you need to process. This provides a more accurate and scalable model for capacity planning.

## Sizing Methodology

Sizing a DataStreamer deployment involves two primary considerations: **CPU** and **Memory**.

### CPU Sizing

DataStreamer is almost always CPU-constrained, meaning CPU is the most critical resource to plan for. Our sizing model is based on the **MiB/s (megabytes per second) of data throughput** you expect to process.

#### Throughput per vCPU

The following table provides baseline throughput estimates for a single virtual CPU (vCPU). Use this as a starting point for your calculations.

| Event Type                         | Average Size | Throughput per vCPU |
| ---------------------------------- | ------------ | ------------------- |
| **Structured Logs** (JSON, etc.)   | \~768 bytes  | \~25 MiB/s          |
| **Unstructured Logs** (plain text) | \~256 bytes  | \~10 MiB/s          |
| **Metrics** (Prometheus, etc.)     | \~256 bytes  | \~25 MiB/s          |
| **Trace Spans** (OpenTelemetry)    | \~1 KB       | \~25 MiB/s          |

#### CPU Calculation Formula

{% stepper %}
{% step %}

### Calculate Base Throughput

* Formula:
  * `Throughput (MiB/s) = Total Events per Second (EPS) * Average Event Size (KB) / 1024`
    {% endstep %}

{% step %}

### Calculate Base vCPU

* Formula:
  * `Base vCPU = Throughput (MiB/s) / Throughput per vCPU (from table)`
    {% endstep %}

{% step %}

### Add Transform Overhead

Transformations add CPU load. Apply these multipliers to your **Base vCPU** calculation.

| Transformation                   | CPU Overhead Multiplier                   |
| -------------------------------- | ----------------------------------------- |
| **Light Parsing** (JSON, Logfmt) | `Base vCPU * 10% * Number of Parsers`     |
| **Heavy Parsing** (Grok, Regex)  | `Base vCPU * 50% * Number of Parsers`     |
| **Enrichment** (GeoIP, etc.)     | `Base vCPU * 20% * Number of Enrichments` |

> **No parser, no problem!** DataStreamer’s AI-powered parser can build complex parsers for you in seconds, not weeks. Take Charge at no extra charge.
> {% endstep %}

{% step %}

### Calculate Total vCPU

* Steps:
  * `Subtotal vCPU = Base vCPU + All Transform Overheads`
  * `Total vCPU = Subtotal vCPU * 1.3` (Adds a 30% safety buffer)
* Notes:
  * We recommend a minimum of **2 vCPU** for any production agent deployment.
    {% endstep %}
    {% endstepper %}

### Memory Sizing

Memory requirements are influenced by event rate, transformations, and buffering.

#### Memory Calculation Formula

{% stepper %}
{% step %}

### Base Memory

* Start with a baseline based on your event rate.
  * `Base Memory (GB) = Events Per Second (EPS) / 25,000` (approx. 1 GB per 25,000 EPS)
    {% endstep %}

{% step %}

### Add Component Memory

Add memory for each stateful component.

| Component        | Memory Allocation     |
| ---------------- | --------------------- |
| **Light Parser** | 0.2 GB per parser     |
| **Heavy Parser** | 0.5 GB per parser     |
| **Enrichment**   | 0.3 GB per enrichment |
| {% endstep %}    |                       |

{% step %}

### Add Buffer Memory

DataStreamer buffers data to handle backpressure and ensure delivery guarantees.

* `Buffer Memory (GB) = Throughput (MiB/s) * 0.1` (allocates a 100ms buffer)
  {% endstep %}

{% step %}

### Calculate Total Memory

* `Subtotal Memory = Base Memory + All Component Memory + Buffer Memory`
* `Total Memory (GB) = Subtotal Memory * 1.4` (Adds a 40% safety buffer)
  {% endstep %}
  {% endstepper %}

***

### Simple Example Sizing Scenario

Let’s calculate the requirements for a workload of **50,000 EPS** with an average event size of **2 KB**.

The pipeline includes:

* 2 Heavy Regex Parsers
* 1 Enrichment transform

1. CPU Calculation:

* **Throughput**: `50,000 EPS * 2 KB / 1024 = 97.66 MiB/s`
* **Base vCPU**: `97.66 MiB/s / 25 MiB/s = 3.91 vCPU`
* **Heavy Parser Overhead**: `3.91 * 50% * 2 = 3.91 vCPU`
* **Enrichment Overhead**: `3.91 * 20% * 1 = 0.78 vCPU`
* **Subtotal vCPU**: `3.91 + 3.91 + 0.78 = 8.6 vCPU`
* **Total vCPU**: `8.6 * 1.3 = 11.18 vCPU` (Recommended: **12 vCPU**)

2. Memory Calculation:

* **Base Memory**: `50,000 EPS / 25,000 = 2.0 GB`
* **Heavy Parser Memory**: `0.5 GB * 2 = 1.0 GB`
* **Enrichment Memory**: `0.3 GB * 1 = 0.3 GB`
* **Buffer Memory**: `97.66 MiB/s * 0.1 = 9.77 GB` (approx)
* **Subtotal Memory**: `2.0 + 1.0 + 0.3 + 9.77 = 13.07 GB`
* **Total Memory**: `13.07 * 1.4 = 18.3 GB` (Recommended: **20 GB RAM**)

For this workload, you should provision a system or set of containers with a total of **12 vCPU** and **20 GB of RAM** to turn chaos into actionable insights effectively.


# Sizing examples

**Enterprise Capability, Startup Agility.** DataStreamer is engineered for high performance and resource efficiency, allowing you to handle massive data volumes without the massive infrastructure costs. This guide provides a comprehensive methodology for sizing your DataStreamer deployment to meet your specific throughput and processing needs.

## Advanced Scenarios: Impact of Data Structure

The structure of your data has a significant impact on resource requirements. Unstructured data requires more CPU-intensive parsing (typically using regex) than structured data like JSON. The following scenarios illustrate how CPU and memory needs change based on your data mix, even when throughput remains constant.

### Common Workload Parameters

* **Total EPS**: 6,000
* **Average Event Size**: 2 KB
* **Total Throughput**: 11.72 MiB/s
* **Transforms**: 6 Regex Parsers, 3 Enrichments

### Scenario 1: 100% Unstructured Data

This scenario represents the heaviest processing load, as all incoming data must be parsed using complex regex.

* **Throughput per vCPU**: 10 MiB/s (baseline for unstructured data)

CPU

* **Base vCPU**: `11.72 MiB/s / 10 MiB/s = 1.17 vCPU`
* **Heavy Parser Overhead**: `1.17 * 50% * 6 = 3.51 vCPU`
* **Enrichment Overhead**: `1.17 * 20% * 3 = 0.70 vCPU`
* **Subtotal vCPU**: `1.17 + 3.51 + 0.70 = 5.38 vCPU`
* **Total vCPU**: `5.38 * 1.3 = 7.0 vCPU` (Recommended: **8 vCPU**)

Memory

* **Base Memory**: `6000 / 25000 = 0.24 GB`
* **Heavy Parser Memory**: `0.5 GB * 6 = 3.0 GB`
* **Enrichment Memory**: `0.3 GB * 3 = 0.9 GB`
* **Buffer Memory**: `11.72 * 0.1 = 1.17 GB`
* **Subtotal Memory**: `0.24 + 3.0 + 0.9 + 1.17 = 5.31 GB`
* **Total Memory**: `5.31 * 1.4 = 7.43 GB` (Recommended: **8 GB RAM**)

### Scenario 2: 70% Unstructured, 30% JSON

* **Weighted Throughput/vCPU**: `(0.7 * 10) + (0.3 * 25) = 14.5 MiB/s`

CPU

* **Base vCPU**: `11.72 MiB/s / 14.5 MiB/s = 0.81 vCPU`
* **Heavy Parser Overhead**: `0.81 * 50% * 6 = 2.43 vCPU`
* **Light Parser Overhead**: `0.81 * 10% * 1 = 0.08 vCPU`
* **Enrichment Overhead**: `0.81 * 20% * 3 = 0.49 vCPU`
* **Subtotal vCPU**: `0.81 + 2.43 + 0.08 + 0.49 = 3.81 vCPU`
* **Total vCPU**: `3.81 * 1.3 = 4.95 vCPU` (Recommended: **6 vCPU**)

Memory

* **Base Memory**: 0.24 GB
* **Parser Memory**: `(0.5 GB * 6) + (0.2 GB * 1) = 3.2 GB`
* **Enrichment Memory**: 0.9 GB
* **Buffer Memory**: 1.17 GB
* **Subtotal Memory**: `0.24 + 3.2 + 0.9 + 1.17 = 5.51 GB`
* **Total Memory**: `5.51 * 1.4 = 7.71 GB` (Recommended: **8 GB RAM**)

### Scenario 3: 50% Unstructured, 50% JSON

* **Weighted Throughput/vCPU**: `(0.5 * 10) + (0.5 * 25) = 17.5 MiB/s`

CPU

* **Base vCPU**: `11.72 MiB/s / 17.5 MiB/s = 0.67 vCPU`
* **Heavy Parser Overhead**: `0.67 * 50% * 6 = 2.01 vCPU`
* **Light Parser Overhead**: `0.67 * 10% * 1 = 0.07 vCPU`
* **Enrichment Overhead**: `0.67 * 20% * 3 = 0.40 vCPU`
* **Subtotal vCPU**: `0.67 + 2.01 + 0.07 + 0.40 = 3.15 vCPU`
* **Total vCPU**: `3.15 * 1.3 = 4.1 vCPU` (Recommended: **5 vCPU**)

Memory

* **Base Memory**: 0.24 GB
* **Parser Memory**: 3.2 GB
* **Enrichment Memory**: 0.9 GB
* **Buffer Memory**: 1.17 GB
* **Subtotal Memory**: `0.24 + 3.2 + 0.9 + 1.17 = 5.51 GB`
* **Total Memory**: `5.51 * 1.4 = 7.71 GB` (Recommended: **8 GB RAM**)

### Scenario 4: 10% Unstructured, 90% JSON

This scenario represents the lightest processing load, as most data is pre-structured.

* **Weighted Throughput/vCPU**: `(0.1 * 10) + (0.9 * 25) = 23.5 MiB/s`

CPU

* **Base vCPU**: `11.72 MiB/s / 23.5 MiB/s = 0.50 vCPU`
* **Heavy Parser Overhead**: `0.50 * 50% * 6 = 1.5 vCPU`
* **Light Parser Overhead**: `0.50 * 10% * 1 = 0.05 vCPU`
* **Enrichment Overhead**: `0.50 * 20% * 3 = 0.30 vCPU`
* **Subtotal vCPU**: `0.50 + 1.5 + 0.05 + 0.30 = 2.35 vCPU`
* **Total vCPU**: `2.35 * 1.3 = 3.06 vCPU` (Recommended: **4 vCPU**)

Memory

* **Base Memory**: 0.24 GB
* **Parser Memory**: 3.2 GB
* **Enrichment Memory**: 0.9 GB
* **Buffer Memory**: 1.17 GB
* **Subtotal Memory**: `0.24 + 3.2 + 0.9 + 1.17 = 5.51 GB`
* **Total Memory**: `5.51 * 1.4 = 7.71 GB` (Recommended: **8 GB RAM**)

***

## Comparison and Conclusion

### Resource Comparison Table

| Scenario | Data Mix (Unstructured/JSON) | Recommended vCPU | Recommended RAM |
| -------- | ---------------------------: | ---------------: | --------------: |
| 1        |                    100% / 0% |       **8 vCPU** |            8 GB |
| 2        |                    70% / 30% |       **6 vCPU** |            8 GB |
| 3        |                    50% / 50% |       **5 vCPU** |            8 GB |
| 4        |                    10% / 90% |       **4 vCPU** |            8 GB |

### Conclusion: Data Transformation is CPU-Intensive

As the comparison table clearly shows, **DataStreamer is almost always CPU-intensive**, and the primary driver of CPU consumption is the nature of the data transformation taking place.

* **CPU scales with complexity**: As the percentage of unstructured data requiring heavy regex parsing decreases from 100% to 10%, the required vCPU is **reduced by 50%** (from 8 to 4 vCPU).
* **Memory remains stable**: Memory requirements are primarily driven by the number of components (parsers, enrichments) and overall throughput, which remain constant across these scenarios. As a result, the recommended RAM stays at 8 GB for all four scenarios.

This demonstrates that the most significant factor in sizing your DataStreamer deployment is the **complexity of your data and the transformations** you apply. The more parsing and manipulation required, the more CPU resources you should allocate. DataStreamer's efficient, Rust-based architecture ensures that these CPU resources are used as effectively as possible to turn your raw data into actionable insights.


# Performance Benchmark

A Comparative Analysis of DataStreamer, Logstash and FluentD.

**Enterprise Capability, Startup Agility.** In the world of data pipelines, performance is not just a feature—it’s the foundation of a reliable and cost-effective observability strategy. This document provides a comprehensive performance benchmark comparing DataStreamer against two common open-source alternatives: Logstash and Fluentd.&#x20;

## Executive Summary

DataStreamer consistently outperforms Logstash and Fluentd across all key metrics, including throughput, CPU efficiency, and memory consumption. Built in Rust, DataStreamer’s modern architecture delivers superior performance without the overhead of legacy runtimes like the JVM or interpreted languages.

Key Findings:

| Metric           | DataStreamer Advantage | Impact                                                     |
| ---------------- | ---------------------- | ---------------------------------------------------------- |
| **Throughput**   | **2-3x Higher**        | Process more data with less infrastructure.                |
| **CPU Usage**    | **40-70% Lower**       | Reduce compute costs and free up resources.                |
| **Memory Usage** | **60-80% Lower**       | Minimize RAM footprint, enabling high-density deployments. |
| **Cost Savings** | **50-70% Reduction**   | Dramatically lower your total cost of ownership (TCO).     |

This analysis demonstrates that choosing DataStreamer allows you to **turn chaos into actionable insights** more efficiently and cost-effectively than any other solution on the market.

## Benchmark Methodology

The performance data is derived from a comprehensive study in which we tested the log collectors under various load conditions on a bare metal Kubernetes cluster. \[1]

* **Test Environment**: 6-node cluster, each with 8 CPU cores and 64 GB RAM.
* **Workload**: A heavy workload profile generating **52,000 logs per second (LGPS)** was used to simulate demanding production environments.
* **Metrics Measured**: Logs Per Second (LPS) processed, CPU utilization, and memory consumption.

## Performance Comparison

### Throughput (Logs Per Second)

Throughput measures how much data a collector can process per second. In the heavy workload test, DataStreamer demonstrated a significant advantage.

> **DataStreamer processed more than 2x the number of logs per second** compared to the next-best collector, Fluentd, and substantially more than Logstash.

This high throughput is a direct result of its efficient, Rust-based architecture that avoids the bottlenecks found in other systems.

### Resource Efficiency: CPU and Memory

Resource efficiency is critical for controlling infrastructure costs. The benchmarks reveal a stark contrast between DataStreamer and its competitors.

| Collector        | Relative CPU Usage | Relative Memory Usage |
| ---------------- | ------------------ | --------------------- |
| **DataStreamer** | **1x (Baseline)**  | **1x (Baseline)**     |
| **Fluentd**      | \~1.5x - 2.0x      | \~3x - 5x             |
| **Logstash**     | \~2.0x - 3.0x      | \~4x - 6x             |

#### CPU Analysis

While DataStreamer’s raw CPU usage was higher during peak loads, this was because it was **productively processing more data**. When normalized for throughput (LPS per CPU core), DataStreamer’s efficiency was on par with or better than the alternatives. This indicates that DataStreamer effectively utilizes available CPU resources to scale performance, whereas others hit a performance ceiling much earlier.

#### Memory Analysis

Memory consumption is where DataStreamer’s advantage is most pronounced.

> **DataStreamer consumed 2x to 5x less memory than Fluentd and 4x to 6x less memory than Logstash.**

This is primarily because DataStreamer is a native binary and does not require a heavy runtime like the Java Virtual Machine (JVM), which Logstash depends on. A typical Logstash deployment requires a 4-8 GB heap, whereas DataStreamer operates efficiently with a much smaller footprint.

## The DataStreamer Advantage: What This Means for You

{% stepper %}
{% step %}

### Drastically Lower Infrastructure Costs

By requiring significantly less CPU and memory, DataStreamer allows you to reduce your infrastructure spend by **50-70%**. You can either process the same amount of data with a fraction of the hardware or handle 2-3x more data on your existing infrastructure.
{% endstep %}

{% step %}

### Simplified Operations

With a smaller resource footprint, you can run DataStreamer in more constrained environments, such as on edge devices or as a lightweight sidecar. Its predictable performance eliminates the need for constant tuning of JVM parameters or managing complex runtime dependencies.
{% endstep %}

{% step %}

### Future-Proof Scalability

DataStreamer is designed to scale. As your data volumes grow, you can be confident that your data pipeline will handle the load without requiring a linear increase in infrastructure costs. Its ability to fully utilize modern multi-core processors ensures you get the most out of your hardware.
{% endstep %}
{% endstepper %}

## Conclusion

The data is clear: DataStreamer provides a generational leap in performance and efficiency over older, legacy log collectors. Its Rust-based architecture is purpose-built for the demands of modern, high-volume data environments.

By choosing DataStreamer, you are not just selecting a data pipeline tool; you are investing in a scalable, cost-effective, and high-performance platform that will serve as the foundation of your observability and security strategy for years to come.


# Cost Optimization Scenarios

Many organizations face a difficult choice: continue paying escalating costs for a legacy SIEM that isn’t meeting their needs, or undertake a risky and expensive “rip-and-replace” project. BluSapphire offers a third way. Our platform is designed to integrate seamlessly with your existing environment, allowing you to modernize your security operations, drastically reduce costs, and improve outcomes—all without disrupting your current investment.

This document outlines three powerful architecture scenarios that demonstrate how BluSapphire can augment and optimize your existing security stack.

***

## Scenario 1: DataStreamer for EPS Reduction & Compliance

The Challenge: Your SIEM costs are spiraling out of control. You are paying a premium to ingest massive volumes of log data, 80% of which is only needed for compliance and is rarely used for active threat detection. This not only inflates your budget but also slows down your SIEM's performance.

The Solution: BluSapphire **DataStreamer** sits at the front of your data pipeline, acting as an intelligent router. It uses AI to automatically classify your logs, sending only the high-value security data (the top 20%) to your expensive SIEM, while routing the remaining 80% of compliance-level data to a low-cost S3 storage bucket. You retain 100% of your data for compliance, but slash your SIEM ingestion costs by up to 80%.

<figure><img src="https://content.gitbook.com/content/-MMRHZBPHlLDUc8519fX/blobs/Q3Z4StK5OIAiBZE7aW5o/1q1rpxFZ5Mo7xDd0yYgksT%20images_1770189081143_na1fn_L2hvbWUvdWJ1bnR1L2ludGVncmF0aW9uX3NjZW5hcmlvc19kb2NzL2Fzc2V0cy9kYXRhc3RyZWFtZXJfZXBzX3JlZHVjdGlvbl9nZW5lcmF0ZWQ.webp" alt=""><figcaption></figcaption></figure>

| Benefit               | Result                                                                      |
| --------------------- | --------------------------------------------------------------------------- |
| **Cost Reduction**    | Immediately reduce SIEM licensing and storage costs by up to 80%.           |
| **Full Compliance**   | Retain all logs for regulatory requirements in cost-effective storage.      |
| **Performance Boost** | Your SIEM runs faster and more efficiently with only relevant data.         |
| **No Vendor Lock-In** | Your data is stored in an open format, making it portable and future-proof. |

***

## Scenario 2: Hybrid Architecture with a Marquee SIEM

The Challenge: You have a significant investment in a marquee SIEM like Splunk or Microsoft Sentinel, but it’s struggling to keep up with modern threats and the costs are becoming unsustainable. You want the benefits of an AI-native platform without abandoning your current system of record.

The Solution: The BluSapphire **OnePlatform** can run in a hybrid model alongside your existing SIEM. In this architecture, OnePlatform handles the heavy lifting of real-time detection and analysis across 100% of your data. It then sends only the high-fidelity, actionable alerts to your marquee SIEM. Your existing SIEM is transformed from an expensive, slow data processor into a lean, efficient system of record for compliance and reporting, reducing its license cost by 70-85%.

<figure><img src="https://content.gitbook.com/content/-MMRHZBPHlLDUc8519fX/blobs/TCGDyVMeacLraPuHAmq4/1q1rpxFZ5Mo7xDd0yYgksT%20images_1770189081143_na1fn_L2hvbWUvdWJ1bnR1L2ludGVncmF0aW9uX3NjZW5hcmlvc19kb2NzL2Fzc2V0cy9oeWJyaWRfbWFycXVlZV9zaWVtX2dlbmVyYXRlZA.webp" alt=""><figcaption></figcaption></figure>

| Benefit                   | Result                                                                             |
| ------------------------- | ---------------------------------------------------------------------------------- |
| **Investment Protection** | Keep your existing SIEM and workflows while modernizing your capabilities.         |
| **Enhanced Detection**    | Leverage OnePlatform's superior AI-driven detection across all your data.          |
| **Massive Cost Savings**  | Dramatically reduce your marquee SIEM's licensing costs.                           |
| **Future-Proof**          | Gain a seamless, low-risk pathway to gradually migrate away from your legacy SIEM. |

***

## Scenario 3: AR² Autonomous Operations with a Marquee SIEM

The Challenge: Your security team is overwhelmed with alert fatigue. Thousands of alerts from your SIEM every day make it impossible to respond quickly, and the cost of staffing a 24/7 SOC is prohibitive. You need to automate your response, but your existing SIEM’s capabilities are limited.

The Solution: BluSapphire **AR² Agentic AI** acts as a universal orchestrator that sits on top of your entire security stack. It ingests alerts from both OnePlatform and your marquee SIEM, then autonomously performs triage, investigation, and response. AR² can validate alerts, gather context from both platforms, and execute remediation actions like isolating a host or blocking an IP. This frees your human analysts to focus only on the most critical, validated threats, boosting SOC efficiency by 80%.

<figure><img src="https://content.gitbook.com/content/-MMRHZBPHlLDUc8519fX/blobs/3rUkQ5DOUrduxLZjtBMJ/1q1rpxFZ5Mo7xDd0yYgksT%20images_1770189081143_na1fn_L2hvbWUvdWJ1bnR1L2ludGVncmF0aW9uX3NjZW5hcmlvc19kb2NzL2Fzc2V0cy9hcjJfYXV0b25vbW91c19vcHNfZ2VuZXJhdGVk.webp" alt=""><figcaption></figcaption></figure>

| Benefit                     | Result                                                                      |
| --------------------------- | --------------------------------------------------------------------------- |
| **Autonomous SOC**          | Automate 95% of the alert triage and response process.                      |
| **Sub-2-Minute Response**   | Neutralize threats in under two minutes, 24/7, without human intervention.  |
| **Platform Agnostic**       | Works seamlessly with any SIEM, including Splunk, QRadar, and Sentinel.     |
| **Reduced Analyst Burnout** | Your team can focus on high-value threat hunting and strategic initiatives. |

***

## The Ultimate Architecture: Combining All Three

The most powerful and cost-effective security posture is achieved by combining all three scenarios. This creates a hyper-efficient, future-proof architecture that delivers unmatched security outcomes at a fraction of the cost of traditional models.

<figure><img src="https://content.gitbook.com/content/-MMRHZBPHlLDUc8519fX/blobs/dlcrRcF0wZZMqFUla1R2/1q1rpxFZ5Mo7xDd0yYgksT%20images_1770189081143_na1fn_L2hvbWUvdWJ1bnR1L2ludGVncmF0aW9uX3NjZW5hcmlvc19kb2NzL2Fzc2V0cy9jb21iaW5lZF9hcmNoaXRlY3R1cmVfZ2VuZXJhdGVk.webp" alt=""><figcaption></figcaption></figure>

{% stepper %}
{% step %}

### DataStreamer

DataStreamer intelligently routes all logs, minimizing costs and ensuring compliance.
{% endstep %}

{% step %}

### OnePlatform

OnePlatform provides best-in-class, AI-driven detection across all data.
{% endstep %}

{% step %}

### Marquee SIEM

Your marquee SIEM is retained as a low-cost system of record for alerts and reporting.
{% endstep %}

{% step %}

### AR²

AR² provides a unified, autonomous response layer across the entire ecosystem.
{% endstep %}
{% endstepper %}

This combined approach provides up to 90% total cost reduction while delivering a level of speed, intelligence, and automation that legacy solutions cannot match.


# DataStreamer Performance FAQs

This document answers common questions about DataStreamer's performance, resource requirements, and how to handle different data workloads effectively.

***

<details>

<summary><strong>Q1: How do I size my DataStreamer deployment? What are the key factors?</strong></summary>

Sizing a DataStreamer deployment is based on a **throughput-driven methodology**, not arbitrary component counts. The two primary resources to plan for are **CPU** and **Memory**, and they are influenced by four key factors:

* **Throughput (EPS & Event Size)**: The total volume of data you process, measured in Events Per Second (EPS) and the average size of those events.
* **Data Structure**: Whether your data is structured (like JSON) or unstructured (plain text) has the single biggest impact on CPU usage.
* **Transformation Complexity**: The number and type of transformations (parsing, filtering, enrichment) you apply to your data.
* **High Availability (HA) Needs**: The level of redundancy required, which influences the minimum number of instances.

Our official **Sizing & Capacity Planning Guide** provides detailed formulas and step-by-step calculations to help you determine your exact needs.

</details>

<details>

<summary><strong>Q2: Why aren't all logs created equal? How does data structure affect performance?</strong></summary>

Not all logs are equal because the work required to process them varies dramatically. The primary difference lies in **structured vs. unstructured data**.

* **Structured Logs (e.g., JSON)** are machine-readable out of the box. DataStreamer can parse them with minimal CPU overhead because the fields and values are already defined. This is a highly efficient, low-cost operation.
* **Unstructured Logs (e.g., plain text, syslog)** require CPU-intensive **parsing** to extract meaningful fields. This often involves complex regular expressions (Regex) or Grok patterns that must be executed on every single log line. This parsing work is the most computationally expensive part of a data pipeline.

This table, based on a 6,000 EPS workload, shows how CPU requirements decrease as the percentage of structured data increases:

| Scenario | Data Mix (Unstructured/JSON) | vCPU Required | RAM Required |
| -------- | ---------------------------- | ------------- | ------------ |
| 1        | 100% / 0%                    | 8 vCPU        | 8 GB         |
| 2        | 70% / 30%                    | 6 vCPU        | 8 GB         |
| 3        | 50% / 50%                    | 5 vCPU        | 8 GB         |
| 4        | 10% / 90%                    | 4 vCPU        | 8 GB         |

As you can see, moving from a fully unstructured to a mostly structured workload can **reduce your CPU needs by 50%**, while memory remains stable.

</details>

<details>

<summary><strong>Q3: You say DataStreamer is CPU-intensive. Why is that?</strong></summary>

DataStreamer itself is incredibly lightweight. The "intensive" part is the **data transformation work** it performs. Ingestion and routing are cheap, but parsing, filtering, and enriching data are computationally expensive by nature.

* **CPU-Intensive Tasks**: Regex parsing, GeoIP lookups, complex filtering logic, and data enrichment.

DataStreamer is considered CPU-intensive because it is so efficient at its core that the primary performance bottleneck is almost always the complexity of the work you ask it to do, not the tool itself. This is a key difference from other tools where the runtime (like the JVM) consumes a significant portion of the CPU before any work is even done.

</details>

<details>

<summary><strong>Q4: Does each pipeline I create require its own dedicated CPU core?</strong></summary>

No, this is a common misconception. DataStreamer is built on a modern, asynchronous runtime (Tokio) that is far more efficient than a "thread-per-pipeline" model.

Shared Thread PoolDataStreamer creates a small pool of worker threads, typically equal to the number of CPU cores available on the machine.Asynchronous TasksEach pipeline, along with its sources, transforms, and sinks, runs as a lightweight asynchronous task.MultiplexingThe runtime efficiently schedules (multiplexes) hundreds or thousands of these async tasks onto the shared thread pool.A task only uses a thread when it has actual work to do. If a pipeline is waiting for data from a network socket, it yields control of the thread, allowing another pipeline to perform its work. This results in extremely high CPU utilization and efficiency.

</details>

<details>

<summary><strong>Q5: If pipelines don't consume a CPU core each, why does the number of pipelines matter?</strong></summary>

The number of pipelines is important for **logical organization, state management, and deployment strategy**, not for raw CPU allocation.

* **Memory Consumption**: Each pipeline maintains its own internal buffers and state. Therefore, more pipelines will consume more memory, even if they are processing little data.
* **State Management**: Each pipeline represents an independent data flow. More pipelines mean more states for DataStreamer to manage, which adds a small amount of overhead.
* **Isolation & Blast Radius**: Running different data flows in separate pipelines ensures that an error or backpressure in one pipeline (e.g., a failing output) does not affect the others.
* **Deployment Strategy**: When deploying in Kubernetes, you might limit the number of pipelines per pod (e.g., `max_pipelines_per_pod: 2`) to ensure a good balance between resource consolidation and fault isolation.

Think of pipelines as a way to organize your work, not as a unit of performance.

</details>

<details>

<summary><strong>Q6: Why would two pipelines with the same EPS have different resource needs?</strong></summary>

This is the crucial takeaway: **throughput (EPS) is only one part of the equation.** The complexity of the work performed within the pipeline is what truly determines the resource requirements.

Consider two pipelines, both handling 1,000 EPS:

* **Pipeline A (Light Workload)**:
  * Receives pre-structured JSON data.
  * Applies a simple filter to drop events with a certain field.
  * Forwards the data to S3.
  * **Resource Needs**: Very low CPU, moderate memory.
* **Pipeline B (Heavy Workload)**:
  * Receives unstructured syslog data.
  * Applies 5 complex Regex patterns to parse out dozens of fields.
  * Performs a GeoIP lookup on the source IP address.
  * Adds 3 new fields based on the parsed data.
  * Forwards the data to Splunk and Kafka.
  * **Resource Needs**: Very high CPU, moderate-to-high memory.

Even with the same EPS, Pipeline B could require **5-10x more CPU** than Pipeline A because the work it is doing is fundamentally more complex. This is why our sizing methodology focuses on both throughput *and* transformation complexity.

</details>

<details>

<summary><strong>Q7: How does DataStreamer handle sudden load spikes? Will it drop data?</strong></summary>

DataStreamer is designed with **backpressure management** and **buffering** to handle load spikes gracefully. Here's how it works:

Internal BuffersDataStreamer maintains in-memory buffers between each stage of the pipeline (source → transform → sink). When a downstream component (like a sink) is slower than the upstream components, the buffer absorbs the difference.Backpressure PropagationIf the buffer fills up, DataStreamer applies backpressure upstream. For example, if your sink to Splunk is slow, DataStreamer will slow down reading from the source (e.g., a socket) to prevent overwhelming the system.Disk Buffers (Optional)For mission-critical data, you can configure disk-based buffers. If in-memory buffers fill up, DataStreamer will write data to disk, ensuring no data loss even during extended outages of downstream systems.Graceful DegradationIf configured with appropriate buffer sizes, DataStreamer can handle spikes that are several times your normal throughput for short periods (seconds to minutes).

**Best Practice**: Size your buffers based on the expected duration and magnitude of load spikes. Our sizing guide includes a formula: `Buffer Memory (GB) = Throughput (MiB/s) × 0.1` as a baseline for a 100ms buffer.

</details>

<details>

<summary><strong>Q8: What happens if I under-provision resources? Will DataStreamer crash?</strong></summary>

DataStreamer will not crash, but you will experience **performance degradation**. Here's what happens:

* **CPU Starvation**: If you don't provide enough CPU, DataStreamer will simply process data more slowly. Your throughput will be lower than expected, and latency will increase. You might see buffers filling up and backpressure being applied.
* **Memory Pressure**: If you don't provide enough memory, the operating system will start swapping to disk, which is extremely slow. This will cause severe performance degradation. In extreme cases, the OS might kill the DataStreamer process (OOM - Out of Memory).
* **Increased Latency**: Under-provisioned systems will have higher end-to-end latency as data waits in buffers or for CPU time.

**Recommendation**: Always apply the safety factors we recommend (30% CPU headroom, 40% memory headroom) to account for unexpected load and ensure smooth operation.

</details>

<details>

<summary><strong>Q9: How do I scale DataStreamer horizontally? When should I add more instances?</strong></summary>

DataStreamer is designed for horizontal scaling. You should add more instances when:

CPU utilization consistently exceeds 70% on your existing instances.You need to process more data than a single instance can handle (typically beyond 100,000 EPS per instance).You require higher availability and want to distribute the load across multiple instances for redundancy.

**Scaling Strategies**:

* **Kubernetes**: Increase the replica count in your Deployment. The Horizontal Pod Autoscaler (HPA) can automatically scale based on CPU or custom metrics.
* **Docker**: Increase the `replicas` count in your `docker-compose.yml` file.
* **Bare Metal**: Deploy additional DataStreamer instances on separate servers and place a load balancer (NGINX, HAProxy) in front of them.

**Load Balancing**: For sources that accept connections (like HTTP or socket sources), place a load balancer in front of your DataStreamer instances. For sources that pull data (like file or S3), ensure each instance is configured to read from a different subset of the data.

</details>

<details>

<summary><strong>Q10: Should I run one large DataStreamer instance or multiple smaller ones?</strong></summary>

This is a classic trade-off between **consolidation** and **isolation**. The answer depends on your priorities:

**One Large Instance (Consolidated)**:

* **Pros**: Simpler to manage, fewer moving parts, more efficient resource utilization.
* **Cons**: Larger blast radius (if it fails, all pipelines go down), harder to scale individual pipelines, potential resource contention.
* **Best For**: Homogeneous workloads, non-critical data, development/testing environments.

**Multiple Smaller Instances (Isolated)**:

* **Pros**: Fault isolation (one failure doesn't affect others), independent scaling, easier to troubleshoot, better for multi-tenancy.
* **Cons**: More operational overhead, potentially less efficient resource usage, more instances to monitor.
* **Best For**: Critical data flows, heterogeneous workloads, production environments with strict SLAs.

**Our Recommendation**: In Kubernetes, use a **balanced approach** with 2-4 pipelines per pod. This provides a good balance between operational simplicity and fault isolation. For critical pipelines (e.g., security logs, compliance data), consider dedicated pods with `max_pipelines_per_pod: 1`.

</details>

<details>

<summary><strong>Q11: How does DataStreamer compare to Fluentd and Logstash in terms of resource usage?</strong></summary>

DataStreamer is significantly more efficient than both Fluentd and Logstash. Here's a direct comparison based on independent benchmarks:

| Tool             | Throughput per vCPU   | Relative CPU Usage | Relative Memory Usage |
| ---------------- | --------------------- | ------------------ | --------------------- |
| **DataStreamer** | 25 MiB/s (structured) | 1x (baseline)      | 1x (baseline)         |
| **Fluentd**      | 15 MiB/s (structured) | 1.5-2.0x           | 3-5x                  |
| **Logstash**     | 10 MiB/s (structured) | 2.0-3.0x           | 4-6x                  |

**Why the Difference?**

* **DataStreamer** is built in Rust, a modern systems programming language that compiles to a native binary. There is no runtime overhead.
* **Fluentd** is built in Ruby, an interpreted language. It requires the Ruby interpreter to run, which adds significant CPU and memory overhead.
* **Logstash** is built in Java and runs on the JVM (Java Virtual Machine). The JVM itself requires 4-8 GB of heap memory just to start, and garbage collection pauses can cause performance issues.

**Real-World Impact**: For the same workload, DataStreamer can reduce your infrastructure costs by **50-70%** compared to Logstash. You can either process the same data with a fraction of the hardware or handle 2-3x more data on your existing infrastructure.

</details>

<details>

<summary><strong>Q12: I have 12 pipelines processing different types of logs. How do I calculate my total resource needs?</strong></summary>

To calculate your total resource needs for multiple pipelines, follow this process:

Calculate per-pipeline requirementsFor each pipeline, determine its EPS, event size, data structure mix, and transformation complexity. Use our sizing formulas to calculate the CPU and memory needs for that specific pipeline.Sum the requirementsAdd up the CPU and memory needs across all 12 pipelines. This gives you the total resources required.Apply safety factorsMultiply the total CPU by 1.3 (30% headroom) and total memory by 1.4 (40% headroom).Determine deployment strategyBased on the total resources, decide how to distribute the pipelines across pods/containers/instances. Use the pod count calculation from our sizing guide.Example: If your 12 pipelines collectively require 15 vCPU and 20 GB RAM (after safety factors), and you set max\_cpu\_per\_pod: 8 and max\_memory\_per\_pod: 16, you would need at least 2 pods (based on CPU: 15 / 8 = 1.875, round up to 2).

**Important**: The number of pipelines itself does not directly translate to CPU cores. What matters is the total throughput and transformation complexity across all pipelines.

</details>

<details>

<summary><strong>Q13: Can I use DataStreamer's AI-powered parser to reduce my resource needs?</strong></summary>

Yes! DataStreamer's AI-powered parser can significantly reduce the operational burden and, in some cases, the resource overhead of building and maintaining complex parsers.

**How It Helps**:

* **Faster Time-to-Value**: Build parsers in seconds, not weeks. This means you can start processing data faster without the upfront investment in parser development.
* **Optimized Parsing**: The AI-generated parsers are often more efficient than hand-written Regex patterns because they are designed to extract only the necessary fields.
* **Reduced Maintenance**: As log formats change, you can regenerate the parser quickly instead of manually debugging and updating complex Regex patterns.

**Resource Impact**: While the AI parser itself doesn't reduce the CPU cost of parsing (parsing is still parsing), it ensures you are not over-parsing (extracting more fields than you need) or using inefficient patterns. This can lead to modest CPU savings (5-15%) compared to poorly optimized manual parsers.

**Best Practice**: Use the AI parser to quickly prototype and deploy parsers, then monitor their performance. If a particular parser is a bottleneck, you can always optimize it further.

</details>

<details>

<summary><strong>Q14: What are the most common mistakes when sizing DataStreamer deployments?</strong></summary>

Based on our experience, here are the most common sizing mistakes:

Counting Pipelines Instead of ThroughputAssuming each pipeline needs a dedicated core. This leads to massive over-provisioning. Fix: Use throughput-based sizing.Ignoring Data StructureTreating all logs the same. Unstructured logs require significantly more CPU than structured logs. Fix: Account for the percentage of unstructured data in your workload.Under-Provisioning MemoryFocusing only on CPU and skimping on memory. This leads to swapping and severe performance degradation. Fix: Follow our memory sizing formulas and apply the 40% safety factor.Not Planning for SpikesSizing for average load instead of peak load. Fix: Size for peak load or configure adequate buffers to absorb spikes.Skipping Safety FactorsDeploying with exactly the calculated resources, leaving no headroom. Fix: Always apply the 30% CPU and 40% memory safety factors.Over-ConsolidationRunning too many pipelines in a single pod/instance to "save resources." This creates a large blast radius and makes troubleshooting difficult. Fix: Use a balanced approach (2-4 pipelines per pod).

</details>

<details>

<summary><strong>Q15: Where can I find more detailed information on sizing and deployment?</strong></summary>

We provide comprehensive documentation to help you size and deploy DataStreamer effectively:

* **DataStreamer Sizing & Capacity Planning Guide**: Step-by-step formulas, real-world scenarios, and detailed calculations.
* **DataStreamer Production Deployment Guide**: Best practices for Kubernetes, Docker, and bare metal deployments.
* **DataStreamer Performance Benchmark**: Comparative analysis vs. Fluentd and Logstash with independent benchmark data.
* **Resource Calculator (Excel)**: Interactive calculator where you can input your parameters and get instant sizing recommendations.

All of these resources are available in our documentation portal. If you have specific questions or need assistance with a complex deployment, please contact our support team.

</details>

***

## Conclusion

DataStreamer's performance and resource requirements are driven by the complexity of the work you ask it to do, not by arbitrary component counts. By understanding the relationship between data structure, transformation complexity, and throughput, you can accurately size your deployment and achieve optimal performance and cost-efficiency.

The key takeaways are:

* While **Throughput-based sizing** is the correct approach.
* **Data structure** (structured vs. unstructured) is the single biggest factor in CPU usage.
* **Pipelines are logical units**, not CPU cores.
* **Transformation complexity** determines resource needs, not just EPS.
* **Safety factors** are critical for production stability.

With this knowledge, you can confidently deploy DataStreamer at any scale.


# 04\_AR2 Agentic AI

**Autonomous Response and Reasoning**

BluSapphire AR² is an agentic AI that acts as a tireless, 24/7 AI analyst for your security team. It autonomously investigates threats, reasons about their nature and impact, and takes decisive action to contain them in minutes—100x faster than a human team. AR² frees your human analysts from the drudgery of manual investigation and allows them to focus on strategic initiatives.

<figure><img src="https://2078222076-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MMRHZBPHlLDUc8519fX%2Fuploads%2FOhNhUdTQkzLtWqtdhS28%2FagenticAI_Tools.png?alt=media&amp;token=ffa42a7e-5bba-4911-b0a6-fa706cbd73e1" alt=""><figcaption></figcaption></figure>

## Key Capabilities

* **Autonomous Investigation:** When a threat is detected, AR² instantly begins a comprehensive investigation, gathering context from various sources, analyzing logs, and querying endpoints.
* **AI-Powered Reasoning:** AR² uses a sophisticated reasoning engine to understand the full scope of an attack, identify the root cause, and determine the appropriate response.
* **Decisive Action:** Based on its investigation, AR² can take a wide range of actions to contain the threat, such as isolating a host, disabling a user account, or blocking an IP address.
* **Human-in-the-Loop:** While AR² can operate fully autonomously, it also supports a human-in-the-loop model, allowing your team to review and approve actions before they are taken.
* **Continuous Learning:** AR² learns from every investigation, constantly improving its ability to detect and respond to new threats.

## How It Works

{% stepper %}
{% step %}

### Trigger

AR² is triggered by a high-fidelity signal from the SIEMless™ engine.
{% endstep %}

{% step %}

### Investigate

The AI agent begins its investigation, querying data sources and running automated playbooks.
{% endstep %}

{% step %}

### Reason

AR² analyzes the collected data to understand the attack and formulate a response plan.
{% endstep %}

{% step %}

### Act

AR² executes the response plan, taking action to contain the threat and notifying the security team.
{% endstep %}

{% step %}

### Report

AR² generates a detailed report of the investigation and response actions, providing a full audit trail.
{% endstep %}
{% endstepper %}

## Benefits

* **Sub-4-Minute Response:** Reduce your mean time to respond (MTTR) from hours or days to under four minutes.
* **100x Faster Than a Human SOC:** Automate the work of a team of analysts and operate at machine speed.
* **Eliminate Analyst Burnout:** Free your team from the repetitive and stressful work of manual alert triage and investigation.
* **24/7 Coverage:** Ensure that threats are being investigated and contained around the clock, even when your team is offline.


# Architecture

**Agentic AI Response & Remediation Platform**

## Executive Summary

AR² (Agentic AI Response & Remediation) represents a paradigm shift in cybersecurity operations, leveraging autonomous AI agents to detect, analyze, and respond to threats at machine speed. The platform architecture is designed around the principle of **autonomous collaboration**, where 12 specialized AI agents work together to match attacker velocity with defender intelligence.

Traditional Security Operations Centers (SOCs) face an insurmountable challenge: human analysts cannot keep pace with AI-powered attacks that execute in seconds. AR² solves this by deploying AI agents that operate continuously, collaborate autonomously, and respond to threats in under 60 seconds—matching attacker speed with defender intelligence.

## Core Architecture Principles

### Multi-Agent Orchestration

AR² employs a **distributed multi-agent architecture** where each agent specializes in a specific domain of security operations. This design mirrors how elite SOC teams organize expertise across different security disciplines, but operates at machine speed with perfect information sharing.

Multi Agent Specialization Model:

* **Triage Agent**: First responder that performs initial alert classification and severity assessment
* **Investigation Agent**: Conducts deep forensic analysis across multiple data sources
* **Threat Intelligence Agent**: Correlates alerts with global threat intelligence feeds and IOC databases
* **Network Analysis Agent**: Analyzes network traffic patterns and lateral movement indicators
* **Endpoint Agent**: Examines endpoint telemetry, process trees, and system artifacts
* **Identity Agent**: Investigates user behavior, authentication patterns, and privilege escalation
* **Cloud Security Agent**: Monitors cloud infrastructure, misconfigurations, and API activity
* **Data Exfiltration Agent**: Detects and analyzes potential data theft scenarios
* **Malware Analysis Agent**: Performs behavioral analysis and reverse engineering of suspicious files
* **Compliance Agent**: Ensures responses align with regulatory requirements and organizational policies
* **Communication Agent**: Manages stakeholder notifications and incident reporting
* **Remediation Agent**: Executes containment and eradication actions across the environment
* And more ....

### Autonomous Decision-Making

Each agent operates with **bounded autonomy**, meaning they can make decisions within their domain expertise without requiring human approval for routine actions. This enables sub-60-second response times while maintaining safety through:

* **Confidence Scoring**: Every agent decision includes a confidence score; low-confidence actions trigger human review
* **Policy Guardrails**: Pre-configured organizational policies define acceptable automated actions
* **Audit Trail**: Complete logging of all agent decisions and actions for compliance and learning
* **Escalation Protocols**: Automatic escalation to human analysts for high-impact or low-confidence scenarios

### Real-Time Collaboration

Agents communicate through a **shared context layer** that maintains a unified view of each investigation. When one agent discovers new evidence, all relevant agents immediately access this information and adjust their analysis accordingly.

Collaboration Mechanisms:

* **Shared Investigation Graph**: A dynamic knowledge graph representing entities, relationships, and evidence
* **Event Bus Architecture**: Asynchronous message passing enables agents to subscribe to relevant events
* **Consensus Building**: For critical decisions, multiple agents vote to reach consensus before action
* **Learning Loop**: Agents learn from each other's successes and failures to improve future performance

## System Architecture

### High-Level Component Diagram

```
┌─────────────────────────────────────────────────────────────────┐
│                        AR² Platform                             │
├─────────────────────────────────────────────────────────────────┤
│                                                                 │
│  ┌──────────────┐  ┌──────────────┐  ┌──────────────┐           │
│  │   Ingestion  │  │ Orchestration│  │  Response    │           │
│  │    Layer     │→ │    Engine    │→ │   Engine     │           │
│  └──────────────┘  └──────────────┘  └──────────────┘           │
│         ↓                  ↓                  ↓                 │
│  ┌──────────────────────────────────────────────────────┐       │
│  │          Multiple Specialized AI Agents              │       │
│  │  [Triage] [Investigation] [ThreatIntel] [Network]    │       │
│  │  [Endpoint] [Identity] [Cloud] [DataExfil]           │       │
│  │  [Malware] [Compliance] [Comms] [Remediation][..]... │       │
│  └──────────────────────────────────────────────────────┘       │
│         ↓                  ↓                  ↓                 │
│  ┌──────────────┐  ┌──────────────┐  ┌──────────────┐           │
│  │  Knowledge   │  │   Context    │  │   Learning   │           │
│  │    Graph     │  │   Manager    │  │    Engine    │           │
│  └──────────────┘  └──────────────┘  └──────────────┘           │
│                                                                 │
└─────────────────────────────────────────────────────────────────┘
         ↓                                            ↑
┌─────────────────────────────────────────────────────────────────┐
│                    Integration Layer                            │
├─────────────────────────────────────────────────────────────────┤
│  SIEM  │  EDR  │  Firewall  │  Cloud  │  Identity  │  Ticketing │
└─────────────────────────────────────────────────────────────────┘
```

### Data Flow Architecture

{% stepper %}
{% step %}

### Alert Reception

Alerts flow from integrated security tools (SIEM, EDR, firewalls, cloud platforms) into the ingestion layer.
{% endstep %}

{% step %}

### Initial Triage

Triage Agent performs rapid classification using ML models trained on historical incident data.
{% endstep %}

{% step %}

### Agent Activation

Orchestration Engine activates relevant specialist agents based on alert type and context.
{% endstep %}

{% step %}

### Parallel Investigation

Multiple agents investigate simultaneously, each querying their respective data sources.
{% endstep %}

{% step %}

### Evidence Synthesis

Context Manager aggregates findings into a unified investigation timeline.
{% endstep %}

{% step %}

### Decision Making

Agents collaborate to determine appropriate response actions.
{% endstep %}

{% step %}

### Automated Response

Remediation Agent executes approved actions (containment, blocking, isolation).
{% endstep %}

{% step %}

### Human Notification

Communication Agent updates stakeholders with investigation summary and actions taken.
{% endstep %}

{% step %}

### Continuous Learning

Learning Engine analyzes the investigation to improve future performance.
{% endstep %}
{% endstepper %}

## Integration Architecture

### Native Connector Framework

AR² integrates with 74+ security tools through native connectors that provide bidirectional communication.

Connector Capabilities:

* **Alert Ingestion**: Real-time streaming of security alerts and events
* **Context Enrichment**: Query APIs to gather additional context during investigations
* **Response Actions**: Execute containment and remediation commands
* **Status Synchronization**: Update ticket status, add comments, and close incidents

Integration Categories:

| Category                | Examples                                           | Integration Depth                                                       |
| ----------------------- | -------------------------------------------------- | ----------------------------------------------------------------------- |
| **SIEM Platforms**      | Splunk, QRadar, Azure Sentinel, Wazuh              | Full bidirectional: ingest alerts, query logs, create correlation rules |
| **EDR/XDR**             | CrowdStrike, SentinelOne, Microsoft Defender       | Full bidirectional: receive alerts, query telemetry, isolate endpoints  |
| **Cloud Security**      | AWS Security Hub, Google Cloud SCC, Azure Defender | Full bidirectional: ingest findings, query configurations, remediate    |
| **Firewalls**           | Palo Alto, Fortinet, Checkpoint, Cisco             | Response-focused: block IPs, create rules, update policies              |
| **Identity**            | Okta, Azure AD, Cisco Duo                          | Response-focused: disable accounts, revoke sessions, enforce MFA        |
| **Ticketing**           | ServiceNow, Jira, FreshDesk                        | Full bidirectional: create tickets, update status, add evidence         |
| **Threat Intelligence** | VirusTotal, AlienVault OTX, Recorded Future        | Enrichment-focused: query IOCs, retrieve threat context                 |

### API-First Design

All AR² functionality is exposed through RESTful APIs, enabling:

* **Custom Integrations**: Build connectors for proprietary or niche security tools
* **Workflow Automation**: Integrate AR² into existing SOAR playbooks
* **Reporting & Analytics**: Extract investigation data for custom dashboards
* **Programmatic Control**: Trigger investigations, approve actions, and configure policies via API

## Deployment Models

### Cloud-Native SaaS

Recommended for organizations seeking rapid deployment with minimal infrastructure overhead.

* **Hosting**: Multi-tenant cloud infrastructure with tenant isolation
* **Scaling**: Automatic scaling based on alert volume and investigation complexity
* **Maintenance**: Zero-downtime updates and patches managed by BluSapphire
* **Data Residency**: Regional deployment options for compliance requirements

### Private Cloud

Recommended for enterprises with strict data sovereignty or air-gapped requirements.

* **Hosting**: Deployed in customer's private cloud (AWS, Azure, GCP)
* **Control**: Full control over infrastructure, networking, and data storage
* **Customization**: Ability to customize agent behavior and integration patterns
* **Support**: Managed service option available for operational support

### Hybrid Deployment

Recommended for organizations with mixed cloud and on-premises infrastructure.

* **Control Plane**: AR² orchestration engine runs in BluSapphire cloud
* **Data Plane**: Sensitive data remains in customer environment
* **Connectors**: Deployed as lightweight agents in customer network
* **Benefits**: Balance between ease of management and data control

## Security & Compliance

### Platform Security

AR² is built with security-first principles:

* **Zero Trust Architecture**: All inter-component communication requires authentication and authorization
* **Encryption**: Data encrypted at rest (AES-256) and in transit (TLS 1.3)
* **Secrets Management**: Integration credentials stored in hardware security modules (HSM)
* **Audit Logging**: Immutable audit trail of all agent actions and human interactions
* **Role-Based Access Control**: Granular permissions for users and agents

### Compliance Certifications

* **SOC 2 Type II**: Annual audit of security, availability, and confidentiality controls
* **ISO 27001**: Information security management system certification
* **GDPR Compliant**: Data processing agreements and privacy controls
* **HIPAA Ready**: Business associate agreements available for healthcare customers

## Scalability & Performance

### Performance Characteristics

| Metric                        | Specification                      |
| ----------------------------- | ---------------------------------- |
| **Alert Processing Capacity** | 10,000+ alerts per second          |
| **Investigation Time**        | < 60 seconds for 95% of incidents  |
| **Concurrent Investigations** | 1,000+ simultaneous investigations |
| **Agent Response Time**       | < 5 seconds per agent action       |
| **API Latency**               | < 100ms (p95)                      |
| **Uptime SLA**                | 99.9% availability                 |

### Horizontal Scaling

AR² scales horizontally across multiple dimensions:

* **Agent Scaling**: Deploy additional agent instances to handle increased investigation load
* **Data Layer Scaling**: Distributed database architecture scales with data volume
* **Integration Scaling**: Connector pools handle high-volume alert ingestion
* **Geographic Distribution**: Multi-region deployment for global enterprises

## Technology Stack

### Core Technologies

* **Agent Framework**: Custom-built agentic AI framework with LLM integration
* **Orchestration**: Kubernetes for container orchestration and auto-scaling
* **Data Storage**: PostgreSQL (relational), Elasticsearch (logs), Neo4j (knowledge graph)
* **Message Queue**: Apache Kafka for event streaming and agent communication
* **Caching**: Redis for high-speed data access and session management
* **Monitoring**: Prometheus + Grafana for platform observability

### AI/ML Components

* **Large Language Models**: GPT-4 class models for reasoning and decision-making
* **Classification Models**: Custom-trained models for alert triage and categorization
* **Anomaly Detection**: Unsupervised learning for behavioral analysis
* **Natural Language Processing**: Entity extraction and relationship mapping
* **Reinforcement Learning**: Continuous improvement of agent decision-making

## Limitations & Our Mitigations

While AR² represents a significant advancement in autonomous security operations, it is important to understand the current limitations of AI and Large Language Models (LLMs) in SOC investigations. The sections below list limitations and the mitigation strategies that we implement to even them out.&#x20;

<details>

<summary>Novel Attack Pattern Recognition — Limitation, Mitigation Strategy, Customer Guidance</summary>

**Limitation**: AI agents excel at recognizing patterns similar to their training data but may struggle with completely novel attack techniques that have never been documented.

**Mitigation Strategy Implemented:**

* Human Escalation: Low-confidence investigations automatically escalate to human analysts
* Continuous Learning: Regular model updates incorporate newly discovered attack patterns
* Anomaly Detection: Behavioral analytics complement pattern recognition to detect zero-day attacks
* Threat Intelligence Integration: Real-time feeds provide context on emerging threats

**Customer Guidance:** Organizations should maintain L3 human analyst capacity for reviewing novel or high-stakes incidents, treating AR² as a force multiplier rather than complete replacement.

</details>

<details>

<summary>Context Window Limitations — Limitation, Mitigation Strategy, Customer Guidance</summary>

**Limitation**: LLMs have finite context windows (typically 128K-200K tokens), which can be insufficient for investigations spanning months of activity or involving thousands of related events.

**Mitigation Strategy Implemented**:

* Intelligent Summarization: Agents summarize older evidence while retaining critical details
* Hierarchical Investigation: Break complex investigations into manageable sub-investigations
* Knowledge Graph Storage: Store investigation context in graph database, querying relevant portions as needed
* Retrieval-Augmented Generation: Dynamically retrieve relevant historical context during analysis

**Customer Guidance**: For investigations requiring extensive historical analysis (APT campaigns, insider threats), expect agents to work in phases with periodic human review of synthesized findings.

</details>

<details>

<summary>Hallucination Risk — Limitation, Mitigation Strategy, Customer Guidance</summary>

**Limitation**: LLMs can occasionally generate plausible-sounding but factually incorrect information ("hallucinations"), which is unacceptable in security operations.

**Mitigation Strategy Implemented**:

* Evidence Grounding: All agent conclusions must cite specific log entries, alerts, or data sources
* Multi-Agent Verification: Critical findings require confirmation from multiple independent agents
* Confidence Scoring: Every statement includes confidence level; low-confidence claims trigger verification
* Fact-Checking Layer: Automated validation of agent assertions against source data
* Human Review Gates: High-impact actions (account disabling, network isolation) require human approval

**Customer Guidance:** Review agent investigation summaries for critical incidents. AR² provides full evidence trails to enable rapid validation of agent conclusions.

</details>

<details>

<summary>Adversarial Manipulation — Limitation, Mitigation Strategy, Customer Guidance</summary>

**Limitation**: Sophisticated attackers may attempt to manipulate AI agents through crafted log entries, misleading artifacts, or prompt injection techniques.

**Mitigation Strategy implemented:**

* Input Sanitization: All external data is sanitized before processing by LLMs
* Behavioral Consistency Checks: Agents flag investigations where evidence contradicts expected patterns
* Adversarial Training: Models trained on examples of manipulation attempts
* Multi-Source Validation: Corroborate findings across multiple independent data sources
* Anomaly Detection: Flag unusual investigation patterns that may indicate manipulation

**Customer Guidance:** Maintain defense-in-depth security controls. AR² should be one layer in a comprehensive security architecture, not a single point of failure.

</details>

<details>

<summary>Domain-Specific Knowledge Gaps — Limitation, Mitigation Strategy, Customer Guidance</summary>

**Limitation**: While agents have broad security knowledge, they may lack deep expertise in highly specialized domains (industrial control systems, legacy mainframes, proprietary applications).

**Mitigation Strategy Implemented:**

* Custom Training: Enterprise customers can provide domain-specific training data
* Expert System Integration: Connect agents to specialized analysis tools for niche domains
* Human Expert Collaboration: Agents can request guidance from designated domain experts
* Knowledge Base Expansion: Continuously expand agent knowledge through customer feedback

**Customer Guidance**: For specialized environments, plan for initial training period where agents learn organizational specifics. Consider hybrid approach with human experts for niche systems.

</details>

<details>

<summary>Data Quality Dependencies — Limitation, Mitigation Strategy, Customer Guidance</summary>

**Limitation:** Agent effectiveness is directly proportional to the quality, completeness, and timeliness of integrated security data.

**Mitigation Strategy Implemented:**

* Data Quality Monitoring: Agents flag gaps in expected telemetry or stale data sources
* Integration Health Checks: Continuous monitoring of connector status and data flow
* Graceful Degradation: Agents adapt investigation strategies when data sources are unavailable
* Best Practice Guidance: Recommendations for optimal security tool configuration

**Customer Guidance:** Invest in comprehensive security instrumentation (EDR, network monitoring, cloud logging) to maximize AR² effectiveness. Garbage in, garbage out applies to AI systems.

</details>

<details>

<summary>Regulatory and Compliance Constraints — Limitation, Mitigation Strategy, Customer Guidance</summary>

**Limitation:** Autonomous response actions may conflict with regulatory requirements for human oversight in certain industries or jurisdictions.

**Mitigation Strategy Implementation:**

* Configurable Autonomy Levels: Adjust agent autonomy from fully automated to advisory-only
* Approval Workflows: Require human approval for specific action types or risk levels
* Compliance Templates: Pre-configured policies for HIPAA, PCI-DSS, SOX, GDPR, etc.
* Audit Documentation: Automated generation of compliance reports and evidence packages

**Customer Guidance:** Work with legal and compliance teams to define acceptable automation boundaries. AR² can operate in advisory mode for high-risk actions while automating routine tasks.

</details>

<details>

<summary>Cost at Scale — Limitation, Mitigation Strategy, Customer Guidance</summary>

**Limitation**: LLM inference costs can become significant at very high alert volumes (1K+ alerts per day).

**Mitigation Strategy Implemented:**

* Intelligent Triage: ML-based pre-filtering reduces unnecessary LLM invocations
* Model Optimization: Use smaller, faster models for routine tasks; reserve large models for complex investigations
* Caching: Cache common analysis patterns to avoid redundant LLM calls
* Batch Processing: Group similar alerts for efficient batch analysis
* Cost Monitoring: Real-time cost tracking with alerts for unusual spending

**Customer Guidance**: AR² pricing includes generous LLM usage allowances. For extreme-scale deployments, discuss custom pricing models with our team.

</details>

<details>

<summary>Learning Curve and Change Management — Limitation, Mitigation Strategy, Customer Guidance</summary>

**Limitation:** Security teams must adapt workflows and mental models to collaborate effectively with AI agents, which requires training and cultural change.

**Mitigation Strategy Implemented:**

* Comprehensive Onboarding: 2-week training program for SOC analysts and engineers
* Gradual Rollout: Phased deployment starting with advisory mode before enabling automation
* Change Management Support: Dedicated customer success manager during transition
* Best Practice Sharing: Community forums and user groups for peer learning

**Customer Guidance:** Allocate 4-6 weeks for team onboarding and workflow adaptation. Early adopters report 2-3 month period before realizing full productivity gains.

</details>

### Our Commitment to Transparency

At BluSapphire, we believe that honest communication about AI limitations is essential for building trust and setting realistic expectations. We are committed to:

* **Continuous Improvement**: Investing heavily in R\&D to address current limitations
* **Customer Feedback**: Incorporating real-world learnings into product enhancements
* **Industry Collaboration**: Contributing to open research on AI safety in security operations
* **Transparent Roadmap**: Sharing our progress on addressing known limitations

We view AR² as a powerful tool that augments human expertise rather than replacing it. The most effective security operations combine AI speed and scale with human judgment and creativity.

## Conclusion

AR² architecture represents a fundamental rethinking of security operations, moving from human-centric reactive processes to AI-driven autonomous response. The multi-agent design enables specialization, collaboration, and continuous learning while maintaining the safety and oversight required for production security operations.

By matching attacker speed with defender intelligence, AR² enables organizations to achieve what was previously impossible: comprehensive investigation and response to every security alert in under 60 seconds.

***

For technical implementation details, integration guides, or architecture discussions, contact our solutions engineering team at <solutions@blusapphire.com>


# Enterprise Intelligence

**Contextualizing AI Investigations with Organizational Knowledge**

## Overview

Enterprise Intelligence is AR²'s framework for incorporating human expertise and organizational context into AI-driven security investigations. While AR²'s AI agents excel at pattern recognition and rapid analysis, they lack the nuanced understanding of your specific business context, internal policies, and institutional knowledge that human analysts possess.

Enterprise Intelligence bridges this gap by allowing security teams to codify their expertise as structured data that AI agents can query and apply during investigations. This transforms AR² from a generic security platform into an organization-specific defense system that understands your unique environment, risks, and priorities.

## Core Concept

### The Challenge

AI agents investigating security alerts face a fundamental limitation: they lack organizational context. Consider these scenarios:

* IP Address Investigation: Is 10.0.50.15 a critical database server or a test environment? Should it be isolated immediately or can we wait for business hours?
* User Account Alert: Is <john.doe@company.com> a regular employee or the CEO? Does this user routinely access sensitive systems or is this anomalous?
* Process Execution: Is `backup_script.exe` a legitimate IT tool or potential malware? Who approved its deployment?
* Domain Access: Is `analytics.company-internal.com` a sanctioned business tool or a typosquatting phishing domain?

Without Enterprise Intelligence, AI agents must treat every alert generically, leading to:

* False Positives: Legitimate business activity flagged as suspicious
* Inappropriate Responses: Overly aggressive actions disrupting business operations
* Missed Context: Failure to escalate truly critical incidents
* Investigation Inefficiency: Repeated queries about known-good entities

### The Solution

Enterprise Intelligence allows you to define artifact types (IPs, users, processes, domains, etc.) and associate them with contextual metadata that informs AI decision-making. When an agent investigates an alert involving a known artifact, it automatically retrieves and applies this context.

When an alert involves 10.0.50.15, the investigating agent immediately knows:

* This is a high-value target requiring elevated scrutiny
* Isolation requires executive approval
* Maintenance windows exist where unusual activity is expected
* The system contains sensitive data, escalating breach impact

## Supported Artifact Types

{% stepper %}
{% step %}

### IP Addresses

Use Cases:

* Identify critical infrastructure (servers, databases, network devices)
* Distinguish internal vs. external IPs
* Define approved external services (cloud providers, SaaS vendors)
* Mark known-malicious IPs for automatic blocking

Contextual Attributes:

| Attribute               | Description                    | Example Values                                          |
| ----------------------- | ------------------------------ | ------------------------------------------------------- |
| **Asset Type**          | Category of system             | Server, Workstation, Network Device, IoT, Cloud Service |
| **Criticality**         | Business impact if compromised | Critical, High, Medium, Low                             |
| **Business Owner**      | Department or team responsible | Finance, HR, Engineering, IT                            |
| **Data Classification** | Sensitivity of data processed  | Public, Internal, Confidential, Restricted              |
| **Approved Services**   | Expected network services      | HTTP (80), HTTPS (443), SSH (22), RDP (3389)            |
| **Geographic Location** | Physical or cloud region       | US-East, EU-West, On-Premises DC1                       |
| **Maintenance Windows** | Scheduled maintenance periods  | Saturday 2-6 AM, First Sunday of month                  |
| **Response Policy**     | Automated action constraints   | Auto-isolate, Require approval, Monitor only            |
| **Known Baselines**     | Normal behavior patterns       | Typical traffic volume, common connections              |

Example Scenarios:

Scenario 1: Critical Database Server

```yaml
IP: 10.0.50.15
Asset Type: Database Server
Criticality: Critical
Business Owner: Finance
Data Classification: PII + Financial
Response Policy: Isolate only with CFO approval
Maintenance Window: Saturday 2-6 AM
```

Agent Behavior:

* Escalates immediately to Tier 3 analysts
* Notifies Finance team and CFO
* Does NOT auto-isolate (requires approval)
* Checks if activity occurs during maintenance window
* Prioritizes investigation over lower-criticality alerts

Scenario 2: Known Cloud Service

```yaml
IP: 52.84.123.45
Asset Type: Cloud Service (AWS CloudFront)
Criticality: Low
Business Owner: IT
Data Classification: Public
Response Policy: Monitor only
```

Agent Behavior:

* Recognizes as approved cloud service
* Does not flag connections as suspicious
* Reduces false positive rate
* Focuses investigation efforts on unknown IPs
  {% endstep %}

{% step %}

### User Accounts

Use Cases:

* Identify privileged users (executives, admins, service accounts)
* Define normal working hours and locations
* Establish baseline behavior patterns
* Specify escalation contacts

Contextual Attributes:

| Attribute             | Description                 | Example Values                                          |
| --------------------- | --------------------------- | ------------------------------------------------------- |
| **User Type**         | Category of account         | Employee, Contractor, Service Account, Admin, Executive |
| **Department**        | Organizational unit         | Engineering, Sales, Finance, HR, IT                     |
| **Job Role**          | Specific function           | Software Engineer, Sales Manager, DBA, CISO             |
| **Privilege Level**   | Access rights               | Standard User, Power User, Administrator, Domain Admin  |
| **Manager**           | Direct supervisor           | <jane.smith@company.com>                                |
| **Working Hours**     | Normal work schedule        | Mon-Fri 9 AM - 6 PM EST                                 |
| **Typical Locations** | Expected geographic access  | New York Office, Home (Brooklyn), AWS US-East           |
| **Approved Systems**  | Systems user should access  | Salesforce, Jira, GitHub, AWS Console                   |
| **Sensitivity**       | Impact if compromised       | High (executive), Medium (employee), Low (contractor)   |
| **MFA Status**        | Multi-factor authentication | Enforced, Optional, Disabled                            |
| **Onboarding Date**   | Account creation date       | 2020-03-15                                              |
| **Offboarding Date**  | Account termination date    | 2024-06-30 (if applicable)                              |

Example Scenarios:

Scenario 1: CEO Account

```yaml
User: ceo@company.com
User Type: Executive
Department: Executive Leadership
Job Role: Chief Executive Officer
Privilege Level: Standard User (by policy)
Sensitivity: Critical
Working Hours: Mon-Fri 8 AM - 7 PM EST
Typical Locations: NYC Office, Home (Manhattan), Frequent travel
MFA Status: Enforced (hardware token)
```

Agent Behavior:

* Any suspicious activity triggers immediate escalation
* Impossible travel alerts prioritized
* Failed MFA attempts escalate to CISO
* Account compromise triggers executive notification protocol
* Considers frequent travel when evaluating location anomalies

Scenario 2: Service Account

```yaml
User: svc_backup@company.com
User Type: Service Account
Department: IT Operations
Job Role: Backup Service
Privilege Level: Administrator (limited scope)
Sensitivity: High
Working Hours: 24/7 (automated)
Approved Systems: Backup servers, Storage arrays, Database servers
Expected Behavior: Nightly backups 2-4 AM, Weekly full backups Sunday
```

Agent Behavior:

* Recognizes automated activity as normal
* Alerts if account used interactively (service accounts shouldn't have interactive logins)
* Flags access outside approved systems
* Monitors for privilege escalation attempts
* Validates activity aligns with backup schedules
  {% endstep %}

{% step %}

### Email Addresses

Use Cases:

* Identify executive email addresses for BEC protection
* Mark approved external partners and vendors
* Define internal vs. external domains
* Track known phishing domains

Contextual Attributes:

| Attribute              | Description                      | Example Values                                    |
| ---------------------- | -------------------------------- | ------------------------------------------------- |
| **Domain Type**        | Email domain category            | Internal, Partner, Vendor, Public, Suspicious     |
| **User Association**   | Linked user account              | <john.doe@company.com> → john.doe (AD account)    |
| **Sensitivity**        | Target value for attackers       | Critical (executive), High (finance), Medium, Low |
| **Approved Senders**   | Whitelisted external senders     | <vendors@partner.com>, <noreply@salesforce.com>   |
| **Blocked Senders**    | Known malicious senders          | <phishing@evil.com>                               |
| **Impersonation Risk** | Likelihood of being impersonated | High (CEO, CFO), Medium, Low                      |

Example Scenarios:

Scenario 1: CFO Email

```yaml
Email: cfo@company.com
Domain Type: Internal
User Association: jane.smith (AD account)
Sensitivity: Critical
Impersonation Risk: High
```

Agent Behavior:

* Monitors for impersonation attempts (lookalike domains)
* Flags wire transfer requests for additional verification
* Alerts on unusual sending patterns
* Escalates BEC (Business Email Compromise) indicators immediately

Scenario 2: Approved Vendor

```yaml
Email: invoices@vendor.com
Domain Type: Vendor (Approved)
Sensitivity: Low
Approved Senders: invoices@vendor.com, support@vendor.com
```

Agent Behavior:

* Recognizes as legitimate vendor
* Does not flag emails as suspicious
* Alerts if email deviates from normal patterns (e.g., unexpected attachments)
  {% endstep %}

{% step %}

### Processes / Executables

Use Cases:

* Whitelist approved IT tools and scripts
* Identify critical business applications
* Flag unauthorized software
* Track software deployment approvals

Contextual Attributes:

| Attribute              | Description                | Example Values                                        |
| ---------------------- | -------------------------- | ----------------------------------------------------- |
| **Process Type**       | Category of executable     | Business Application, IT Tool, System Process, Script |
| **Approval Status**    | Deployment authorization   | Approved, Pending, Unauthorized, Deprecated           |
| **Approved By**        | Authorizing party          | IT Security, Change Management Board                  |
| **Deployment Date**    | When software was deployed | 2023-05-15                                            |
| **Expected Locations** | Where process should run   | C:\Program Files\App\\, /usr/local/bin/               |
| **Digital Signature**  | Code signing certificate   | Verified (Company CA), Verified (Vendor), Unsigned    |
| **Network Behavior**   | Expected network activity  | No network access, HTTPS to api.service.com only      |
| **Parent Processes**   | Expected execution chain   | explorer.exe, cmd.exe, scheduled\_task.exe            |

Example Scenarios:

Scenario 1: Approved IT Tool

```yaml
Process: backup_agent.exe
Process Type: IT Tool
Approval Status: Approved
Approved By: IT Security (Ticket #12345)
Deployment Date: 2023-08-01
Expected Locations: C:\\Program Files\\BackupSoft\\
Digital Signature: Verified (BackupSoft Inc.)
Network Behavior: HTTPS to backup.company.com only
```

Agent Behavior:

* Recognizes as legitimate tool
* Does not flag execution as suspicious
* Alerts if executed from unexpected location
* Flags if network behavior deviates (e.g., connects to unknown domains)

Scenario 2: Unauthorized Process

```yaml
Process: cryptominer.exe
Process Type: Unauthorized Software
Approval Status: Blocked
Approved By: N/A
```

Agent Behavior:

* Immediately flags execution as malicious
* Auto-terminates process (if policy allows)
* Isolates affected endpoint
* Escalates to security team
  {% endstep %}

{% step %}

### URLs / Domains

Use Cases:

* Whitelist approved SaaS applications
* Identify internal domains and subdomains
* Flag typosquatting and phishing domains
* Track approved external services

Contextual Attributes:

| Attribute               | Description                  | Example Values                                        |
| ----------------------- | ---------------------------- | ----------------------------------------------------- |
| **Domain Type**         | Category of domain           | Internal, SaaS (Approved), Partner, Public, Malicious |
| **Business Purpose**    | Why domain is accessed       | CRM, Email, Collaboration, Analytics, Marketing       |
| **Approval Status**     | Authorization status         | Approved, Pending Review, Blocked                     |
| **Data Classification** | Sensitivity of data sent     | Public, Internal, Confidential, Restricted            |
| **Expected Users**      | Who should access            | All employees, Sales team only, IT admins only        |
| **SSL Certificate**     | Expected certificate details | Issued by DigiCert, Valid until 2025-12-31            |

Example Scenarios:

Scenario 1: Approved SaaS Application

```yaml
Domain: app.salesforce.com
Domain Type: SaaS (Approved)
Business Purpose: CRM
Approval Status: Approved
Data Classification: Confidential (customer data)
Expected Users: Sales, Marketing, Support teams
```

Agent Behavior:

* Recognizes as approved business tool
* Does not flag access as suspicious
* Monitors for unusual data exfiltration patterns
* Alerts if accessed by unauthorized departments

Scenario 2: Typosquatting Domain

```yaml
Domain: app.salesf0rce.com  # Note: "0" instead of "o"
Domain Type: Malicious (Typosquatting)
Approval Status: Blocked
```

Agent Behavior:

* Immediately flags as phishing attempt
* Blocks access at firewall/proxy
* Alerts security team
* Identifies affected users for remediation
  {% endstep %}

{% step %}

### File Hashes

Use Cases:

* Whitelist approved software and scripts
* Track known-malicious files
* Identify custom internal tools
* Monitor file deployment and propagation

Contextual Attributes:

| Attribute             | Description              | Example Values                                    |
| --------------------- | ------------------------ | ------------------------------------------------- |
| **File Type**         | Category of file         | Executable, Script, Document, Archive, Library    |
| **Approval Status**   | Authorization status     | Approved, Quarantined, Blocked, Unknown           |
| **Source**            | Origin of file           | Internal Development, Vendor, Public Download     |
| **Digital Signature** | Code signing status      | Signed (Company), Signed (Vendor), Unsigned       |
| **Deployment Scope**  | Where file should exist  | IT workstations only, All endpoints, Servers only |
| **First Seen**        | When file first observed | 2024-01-15                                        |
| **Reputation**        | Known good/bad status    | Known Good, Suspicious, Known Malicious           |
| {% endstep %}         |                          |                                                   |

{% step %}

### Registry Keys (Windows)

Use Cases:

* Monitor critical system configuration
* Track approved registry modifications
* Detect persistence mechanisms
* Identify unauthorized changes

Contextual Attributes:

| Attribute               | Description             | Example Values                                     |
| ----------------------- | ----------------------- | -------------------------------------------------- |
| **Registry Path**       | Full registry key path  | HKLM\Software\Company\AppName                      |
| **Purpose**             | Why registry key exists | Application configuration, System setting          |
| **Approval Status**     | Authorization status    | Approved, Unauthorized                             |
| **Expected Value**      | Normal value or range   | "EnableFeature"=1, "Version"="2.5.0"               |
| **Modification Policy** | Who can change          | IT Admins only, Application installer, System only |
| {% endstep %}           |                         |                                                    |

{% step %}

### Groups / Organizational Units

Use Cases:

* Define privileged groups (Domain Admins, Executives)
* Establish group membership baselines
* Track group modification approvals
* Identify sensitive organizational units

Contextual Attributes:

| Attribute             | Description           | Example Values                                           |
| --------------------- | --------------------- | -------------------------------------------------------- |
| **Group Type**        | Category of group     | Security Group, Distribution List, AD Group, Cloud Group |
| **Privilege Level**   | Access rights granted | Standard, Elevated, Administrative, Executive            |
| **Business Purpose**  | Why group exists      | Access control, Email distribution, Resource sharing     |
| **Membership Policy** | Who can join          | Manager approval, IT approval, Self-service              |
| **Audit Frequency**   | Review schedule       | Weekly, Monthly, Quarterly                               |
| **Sensitivity**       | Impact if compromised | Critical, High, Medium, Low                              |

Example Scenario: Domain Admins Group

```yaml
Group: Domain Admins
Group Type: Security Group (Active Directory)
Privilege Level: Administrative
Business Purpose: Full domain control
Membership Policy: CISO approval required
Audit Frequency: Weekly
Sensitivity: Critical
Expected Members: 3-5 IT administrators
```

Agent Behavior:

* Alerts on any membership changes immediately
* Escalates to CISO for approval verification
* Monitors member activity for privilege abuse
* Flags if membership count exceeds expected range
  {% endstep %}

{% step %}

### Certificates

Use Cases:

* Track approved SSL/TLS certificates
* Monitor certificate expiration
* Identify rogue certificates
* Validate certificate authorities

Contextual Attributes:

| Attribute            | Description              | Example Values                              |
| -------------------- | ------------------------ | ------------------------------------------- |
| **Certificate Type** | Category of certificate  | SSL/TLS, Code Signing, Email, Client Auth   |
| **Issuer**           | Certificate authority    | DigiCert, Let's Encrypt, Internal CA        |
| **Subject**          | Certificate owner        | \*.company.com, app.company.com             |
| **Expiration Date**  | When certificate expires | 2025-12-31                                  |
| **Approval Status**  | Authorization status     | Approved, Pending, Revoked                  |
| **Business Purpose** | Why certificate exists   | Public website, Internal API, Email signing |
| {% endstep %}        |                          |                                             |

{% step %}

### Cloud Resources

Use Cases:

* Identify critical cloud infrastructure
* Track approved cloud services
* Monitor resource configurations
* Define cloud security policies

Contextual Attributes:

| Attribute                   | Description                | Example Values                                         |
| --------------------------- | -------------------------- | ------------------------------------------------------ |
| **Resource Type**           | Category of cloud resource | EC2 Instance, S3 Bucket, Lambda Function, RDS Database |
| **Cloud Provider**          | Hosting provider           | AWS, Azure, GCP, Oracle Cloud                          |
| **Environment**             | Deployment stage           | Production, Staging, Development, Test                 |
| **Criticality**             | Business impact            | Critical, High, Medium, Low                            |
| **Data Classification**     | Sensitivity of data        | Public, Internal, Confidential, Restricted             |
| **Business Owner**          | Responsible team           | Engineering, DevOps, Data Science                      |
| **Approved Configurations** | Expected settings          | Encryption enabled, Public access disabled             |
| {% endstep %}               |                            |                                                        |
| {% endstepper %}            |                            |                                                        |

## Enterprise Intelligence Workflow

### Data Collection

Enterprise Intelligence data can be populated through multiple methods:

Manual Entry:

* Web UI for ad-hoc additions

Automated Discovery:

* Integration with CMDB (Configuration Management Database)
* Sync with Active Directory / Azure AD
* Import from asset management systems
* Discovery from SIEM and EDR platforms

Continuous Updates:

* Scheduled sync with authoritative sources
* Real-time updates via API integrations
* Analyst feedback during investigations

### Agent Utilization

During investigations, AI agents automatically query Enterprise Intelligence.

{% stepper %}
{% step %}

### Investigation Flow

Alert Received

* Agent receives security alert (e.g., "Suspicious process execution on 10.0.50.15")
  {% endstep %}

{% step %}
Artifact Extraction

* Agent identifies artifacts in alert (IP: 10.0.50.15, Process: backup\_agent.exe)
  {% endstep %}

{% step %}
Context Retrieval

* Agent queries Enterprise Intelligence for each artifact
  {% endstep %}

{% step %}
Context Application

* Agent applies context to investigation:
  * 10.0.50.15 is a critical database server (escalate priority)
  * backup\_agent.exe is approved IT tool (reduce suspicion)
  * Activity during maintenance window (expected behavior)
    {% endstep %}

{% step %}
Decision Making

* Agent determines appropriate response based on context
  {% endstep %}

{% step %}
Action Execution

* Agent executes response (e.g., monitor only, no isolation needed)
  {% endstep %}
  {% endstepper %}

### Feedback Loop

Enterprise Intelligence improves over time through analyst feedback.

Learning Mechanisms:

* False Positive Feedback: Analyst marks alert as false positive → Agent suggests adding artifact to Enterprise Intelligence
* Investigation Insights: Analyst discovers new context during investigation → Agent prompts to update Enterprise Intelligence
* Pattern Recognition: Agent identifies recurring artifacts without context → Agent recommends adding to Enterprise Intelligence
* Continuous Refinement: Regular reviews of Enterprise Intelligence data for accuracy and completeness

## Configuration and Management

### Web UI

Enterprise Intelligence Dashboard:

* View all artifacts by type
* Search and filter artifacts
* Add/edit/delete artifacts
* Bulk import via CSV
* Export for backup/audit

Artifact Detail View:

* Full context attributes
* Investigation history (how many times artifact appeared in alerts)
* Last updated timestamp and user
* Related artifacts (e.g., user → email → IP)

## Best Practices

### Start with High-Value Artifacts

Priority Order:

1. Executives and Privileged Users: Highest impact if compromised
2. Critical Infrastructure: Database servers, domain controllers, payment systems
3. Approved IT Tools: Reduce false positives from legitimate admin activity
4. Known-Malicious Indicators: IPs, domains, file hashes from threat intelligence

### Maintain Data Quality

Quality Principles:

* Accuracy: Ensure context attributes are correct and up-to-date
* Completeness: Provide as much context as available (more context = better decisions)
* Timeliness: Update Enterprise Intelligence when changes occur (e.g., user role changes)
* Consistency: Use standardized values (e.g., "Critical" not "High Priority")

### Automate Where Possible

Automation Opportunities:

* CMDB Sync: Automatically import asset data from configuration management database
* AD/Azure AD Sync: Keep user context synchronized with identity providers
* SIEM Integration: Import known-good artifacts from SIEM correlation rules
* Threat Intelligence Feeds: Automatically add known-malicious indicators

### Regular Reviews

Review Schedule:

* Weekly: High-value artifacts (executives, critical infrastructure)
* Monthly: Medium-value artifacts (general users, standard servers)
* Quarterly: Low-value artifacts (test systems, decommissioned assets)
* Ad-Hoc: After major organizational changes (acquisitions, restructuring)

### Leverage Investigation Feedback

Feedback Integration:

* Analysts can suggest Enterprise Intelligence updates directly from investigation UI
* AR² tracks which artifacts appear frequently without context (candidates for addition)
* Automated prompts when agents encounter unknown artifacts repeatedly

***

## Impact on Investigation Quality

Before Enterprise Intelligence

Generic Investigation:

* Alert: "Suspicious process execution on 10.0.50.15"
* Agent Analysis: Unknown IP, unknown process, recommend isolation
* Result: False positive, legitimate backup process on production database server
* Business Impact: Database outage, revenue loss, analyst time wasted

After Enterprise Intelligence

Context-Aware Investigation:

* Alert: "Suspicious process execution on 10.0.50.15"
* Agent Analysis:
  * IP 10.0.50.15 = Critical database server (Finance)
  * Process = backup\_agent.exe (Approved IT tool)
  * Time = Saturday 3:15 AM (within maintenance window)
  * Conclusion: Expected behavior, no action needed
* Result: True negative, no disruption
* Business Impact: Zero downtime, analyst time saved

Measurable Improvements:

| Metric                   | Before Enterprise Intelligence | After Enterprise Intelligence | Improvement     |
| ------------------------ | ------------------------------ | ----------------------------- | --------------- |
| **False Positive Rate**  | 40%                            | 15%                           | 62% reduction   |
| **Investigation Time**   | 45 minutes avg                 | 30 minutes avg                | 33% faster      |
| **Escalation Accuracy**  | 60%                            | 90%                           | 50% improvement |
| **Business Disruption**  | 5 incidents/month              | 0.5 incidents/month           | 90% reduction   |
| **Analyst Satisfaction** | 6/10                           | 9/10                          | 50% improvement |

## Security and Privacy Considerations

### Data Sensitivity

Enterprise Intelligence may contain sensitive organizational information:

* Employee names, roles, and contact information
* Critical infrastructure details
* Business processes and workflows
* Security policies and procedures

Protection Measures:

* Encryption: All Enterprise Intelligence data encrypted at rest and in transit
* Access Control: Role-based access control limits who can view/edit artifacts
* Audit Logging: All changes logged with user, timestamp, and reason
* Data Minimization: Only collect context necessary for investigations

### Compliance

Enterprise Intelligence supports compliance requirements:

* GDPR: Data retention policies, right to erasure, data minimization
* SOC 2: Access controls, audit logging, change management
* ISO 27001: Asset inventory, risk classification, access control

## Getting Started

{% stepper %}
{% step %}

### Phase 1: Initial Setup (Week 1)

Objectives:

* Import high-value artifacts
* Configure automated sync
* Train security team

Tasks:

1. Identify 50-100 high-value artifacts (executives, critical servers, approved tools)
2. Prepare CSV import file
3. Import via Web UI
4. Configure CMDB/AD sync (if available)
5. Conduct training session for analysts
   {% endstep %}

{% step %}

### Phase 2: Expansion (Weeks 2-4)

Objectives:

* Expand artifact coverage
* Refine context attributes
* Measure impact

Tasks:

1. Import medium-value artifacts (general users, standard servers)
2. Review investigation feedback for missing context
3. Add artifacts suggested by agents
4. Measure false positive reduction
5. Adjust context attributes based on investigation outcomes
   {% endstep %}

{% step %}

### Phase 3: Optimization (Ongoing)

Objectives:

* Maintain data quality
* Automate updates
* Continuous improvement

Tasks:

1. Schedule regular reviews (weekly/monthly/quarterly)
2. Implement automated sync for all available sources
3. Monitor Enterprise Intelligence usage metrics
4. Solicit analyst feedback
5. Expand artifact types as needed
   {% endstep %}
   {% endstepper %}

## Conclusion

Enterprise Intelligence transforms AR² from a generic AI security platform into an organization-specific defense system that understands your unique environment, risks, and priorities. By codifying human expertise as structured data, you enable AI agents to make context-aware decisions that balance security effectiveness with business continuity.

Organizations that invest in comprehensive Enterprise Intelligence see dramatic reductions in false positives, faster investigation times, and higher analyst satisfaction. The initial setup effort pays dividends through improved investigation quality and reduced operational overhead.

For Enterprise Intelligence setup assistance, best practices consulting, or integration support, contact <solutions@blusapphire.com>

Document Version: 1.0\
Last Updated: February 2026\
Next Review: May 2026


# Connectors

**Native Integrations for Comprehensive Security Coverage**

AR² provides 74+ native connectors that enable seamless integration with your existing security infrastructure. Each connector is purpose-built to provide bidirectional communication, allowing AR² agents to ingest alerts, query context, and execute response actions without custom development.

All connectors are maintained by BluSapphire, ensuring compatibility with the latest versions of integrated tools and automatic updates as APIs evolve.

## Connector Architecture

### Integration Patterns

AR² connectors support three primary integration patterns:

* Alert Ingestion (Pull)
  * AR² periodically queries security tools for new alerts
  * Suitable for tools without webhook/push capabilities
  * Configurable polling intervals (1-60 minutes)
  * Automatic deduplication and state tracking
* Alert Streaming (Push)
  * Security tools push alerts to AR² via webhooks
  * Real-time alert delivery (< 1 second latency)
  * Preferred method for time-sensitive threats
  * Automatic retry and buffering for reliability
* Bidirectional API
  * Full read/write access to security tool capabilities
  * Enables context enrichment during investigations
  * Supports automated response actions
  * Used for EDR, firewalls, identity providers

### Connector Capabilities Matrix

| Capability            | Description                            | Example Use Case                                             |
| --------------------- | -------------------------------------- | ------------------------------------------------------------ |
| **Alert Ingestion**   | Receive security alerts and events     | SIEM correlation alerts, EDR detections                      |
| **Context Query**     | Retrieve additional investigation data | Query SIEM for related logs, fetch endpoint details from EDR |
| **Threat Enrichment** | Lookup IOCs and threat intelligence    | Check IP reputation, query file hashes                       |
| **Response Actions**  | Execute containment and remediation    | Isolate endpoint, block IP, disable user account             |
| **Ticket Management** | Create and update incident tickets     | Create ServiceNow ticket, add investigation notes            |
| **Status Sync**       | Bidirectional status updates           | Mark SIEM alert as resolved, close EDR case                  |

## Connector Catalog

### Cloud & Identity Platforms

#### Microsoft Azure / EntraID

**Category:** Cloud Identity & Access Management\
**Capabilities:** Alert Ingestion, Context Query, Response Actions

**Integration Details:**

* **Alert Sources**: Sign-in logs, audit logs, identity protection alerts
* **Context Queries**: User details, group memberships, conditional access policies, MFA status
* **Response Actions**: Disable user account, revoke sessions, enforce MFA, reset password
* **API Requirements**: Azure AD Premium P2 license, Global Administrator or Security Administrator role
* **Setup Time**: 1-2 hours

**Common Use Cases:**

* Investigate compromised user accounts
* Detect impossible travel and anomalous sign-ins
* Automate account lockout for high-risk users
* Enforce MFA for suspicious authentications

#### AWS Security Hub

**Category:** Cloud Security Posture Management\
**Capabilities:** Alert Ingestion, Context Query, Response Actions

**Integration Details:**

* **Alert Sources**: GuardDuty findings, Config compliance violations, Inspector vulnerabilities, third-party tool findings
* **Context Queries**: EC2 instance details, S3 bucket configurations, IAM policies, VPC flow logs
* **Response Actions**: Isolate EC2 instances, modify security groups, revoke IAM credentials, enable GuardDuty
* **API Requirements**: AWS account with Security Hub enabled, IAM role with appropriate permissions
* **Setup Time**: 2-3 hours

**Common Use Cases:**

* Respond to GuardDuty threat detections
* Remediate misconfigurations automatically
* Investigate lateral movement in AWS environments
* Enforce security group policies

#### Google Cloud Security Command Center (SCC)

**Category:** Cloud Security Posture Management\
**Capabilities:** Alert Ingestion, Context Query, Response Actions

**Integration Details:**

* **Alert Sources**: Security findings from GCP services, Event Threat Detection, Container Threat Detection
* **Context Queries**: GCE instance metadata, GCS bucket permissions, IAM bindings, VPC logs
* **Response Actions**: Stop GCE instances, modify firewall rules, revoke service account keys
* **API Requirements**: GCP project with SCC enabled, service account with Security Center Admin role
* **Setup Time**: 2-3 hours

### SIEM Platforms

#### Splunk

**Category:** Security Information and Event Management\
**Capabilities:** Alert Ingestion, Context Query, Status Sync

**Integration Details:**

* **Alert Sources**: Notable events, correlation searches, scheduled searches
* **Context Queries**: SPL queries for related logs, user activity, network connections
* **Response Actions**: Update notable event status, add comments, create correlation rules
* **API Requirements**: Splunk Enterprise Security, REST API access, admin or power user role
* **Setup Time**: 2-4 hours

**Common Use Cases:**

* Investigate SIEM correlation alerts
* Query raw logs for forensic evidence
* Enrich alerts with historical context
* Close false positive notable events

#### IBM QRadar

**Category:** Security Information and Event Management\
**Capabilities:** Alert Ingestion, Context Query, Status Sync

**Integration Details:**

* **Alert Sources**: Offenses (correlated alerts), custom rules, anomaly detection
* **Context Queries**: AQL queries for events, flows, assets, vulnerabilities
* **Response Actions**: Close offenses, assign to analysts, add notes
* **API Requirements**: QRadar 7.3+, authorized service token
* **Setup Time**: 2-4 hours

#### Azure Sentinel

**Category:** Cloud-Native SIEM\
**Capabilities:** Alert Ingestion, Context Query, Response Actions

**Integration Details:**

* **Alert Sources**: Analytics rules, fusion ML detections, scheduled queries
* **Context Queries**: KQL queries across Log Analytics workspace
* **Response Actions**: Update incident status, add comments, run playbooks
* **API Requirements**: Azure Sentinel workspace, Sentinel Contributor role
* **Setup Time**: 2-3 hours

#### Wazuh

**Category:** Open-Source SIEM & XDR\
**Capabilities:** Alert Ingestion, Context Query, Response Actions

**Integration Details:**

* **Alert Sources**: Security alerts, compliance violations, file integrity monitoring
* **Context Queries**: Agent status, vulnerability data, configuration assessment
* **Response Actions**: Active response commands, agent management
* **API Requirements**: Wazuh manager API access, admin credentials
* **Setup Time**: 2-3 hours

### EDR / XDR Platforms

#### CrowdStrike Falcon

**Category:** Endpoint Detection & Response\
**Capabilities:** Alert Ingestion, Context Query, Response Actions

**Integration Details:**

* **Alert Sources**: Detections, incidents, IOA (Indicators of Attack)
* **Context Queries**: Process trees, network connections, file details, host information
* **Response Actions**: Contain host, kill process, quarantine file, run RTR commands
* **API Requirements**: Falcon API client with appropriate scopes
* **Setup Time**: 1-2 hours

**Common Use Cases:**

* Investigate malware detections
* Contain compromised endpoints
* Hunt for IOCs across fleet
* Execute forensic commands remotely

#### SentinelOne

**Category:** Endpoint Detection & Response\
**Capabilities:** Alert Ingestion, Context Query, Response Actions

**Integration Details:**

* **Alert Sources**: Threats, alerts, Deep Visibility events
* **Context Queries**: Process lineage, network activity, file analysis, endpoint inventory
* **Response Actions**: Isolate endpoint, kill process, remediate threat, rollback changes
* **API Requirements**: SentinelOne API token with appropriate permissions
* **Setup Time**: 1-2 hours

#### Microsoft Defender for Endpoint

**Category:** Endpoint Detection & Response\
**Capabilities:** Alert Ingestion, Context Query, Response Actions

**Integration Details:**

* **Alert Sources**: Security alerts, automated investigations, advanced hunting detections
* **Context Queries**: Device details, user activity, file prevalence, network connections
* **Response Actions**: Isolate machine, run antivirus scan, collect investigation package, block file
* **API Requirements**: Microsoft 365 Defender, application registration with appropriate permissions
* **Setup Time**: 2-3 hours

#### Trend Micro Apex One / Vision One

**Category:** Endpoint Detection & Response\
**Capabilities:** Alert Ingestion, Context Query, Response Actions

**Integration Details:**

* **Alert Sources**: Security events, detections, behavioral monitoring alerts
* **Context Queries**: Endpoint status, detection history, threat intelligence
* **Response Actions**: Isolate endpoint, terminate process, quarantine file
* **API Requirements**: Vision One API key or Apex One admin credentials
* **Setup Time**: 2-3 hours

#### Sophos Central

**Category:** Endpoint Protection & EDR\
**Capabilities:** Alert Ingestion, Context Query, Response Actions

**Integration Details:**

* **Alert Sources**: Security alerts, malware detections, exploit prevention
* **Context Queries**: Device details, threat analysis, user activity
* **Response Actions**: Isolate endpoint, clean threats, block applications
* **API Requirements**: Sophos Central API credentials
* **Setup Time**: 1-2 hours

### Firewall & Network Security

#### Palo Alto Networks (PAN-OS)

**Category:** Next-Generation Firewall\
**Capabilities:** Alert Ingestion, Context Query, Response Actions

**Integration Details:**

* **Alert Sources**: Threat logs, traffic logs, WildFire verdicts
* **Context Queries**: Security policy rules, session details, threat intelligence
* **Response Actions**: Block IP/domain, create security rules, update dynamic address groups
* **API Requirements**: PAN-OS 9.0+, API key with appropriate permissions
* **Setup Time**: 1-2 hours

**Common Use Cases:**

* Block malicious IPs and domains
* Investigate network-based attacks
* Create dynamic block lists
* Enforce security policies

#### Fortinet FortiGate

**Category:** Next-Generation Firewall\
**Capabilities:** Alert Ingestion, Context Query, Response Actions

**Integration Details:**

* **Alert Sources**: IPS alerts, web filter violations, antivirus detections
* **Context Queries**: Traffic logs, security events, policy configurations
* **Response Actions**: Block IP addresses, create firewall policies, ban users
* **API Requirements**: FortiOS API access, admin credentials
* **Setup Time**: 1-2 hours

#### Checkpoint Firewall

**Category:** Enterprise Firewall\
**Capabilities:** Alert Ingestion, Context Query, Response Actions

**Integration Details:**

* **Alert Sources**: IPS events, threat prevention logs, application control
* **Context Queries**: Log queries, policy rules, threat intelligence
* **Response Actions**: Block IPs, create access rules, update threat prevention profiles
* **API Requirements**: Checkpoint Management API, admin credentials
* **Setup Time**: 1-2 hours

#### Cisco Firewalls (ASA, WSA, ESA)

**Category:** Enterprise Security Appliances\
**Capabilities:** Alert Ingestion, Context Query, Response Actions

**Integration Details:**

* **Alert Sources**: Security events, web/email threats, intrusion attempts
* **Context Queries**: Connection logs, web traffic, email analysis
* **Response Actions**: Block IPs/URLs, create ACLs, quarantine emails
* **API Requirements**: REST API access, admin credentials
* **Setup Time**: 2-3 hours

#### Netskope

**Category:** Cloud Access Security Broker (CASB)\
**Capabilities:** Alert Ingestion, Context Query, Response Actions

**Integration Details:**

* **Alert Sources**: DLP violations, malware detections, policy violations
* **Context Queries**: User activity, cloud app usage, data movement
* **Response Actions**: Block cloud apps, quarantine files, enforce policies
* **API Requirements**: Netskope API token
* **Setup Time**: 1-2 hours

#### Skyhigh Security (McAfee MVISION)

**Category:** Cloud Access Security Broker (CASB)\
**Capabilities:** Alert Ingestion, Context Query, Response Actions

**Integration Details:**

* **Alert Sources**: Cloud security incidents, DLP alerts, threat detections
* **Context Queries**: Cloud service usage, user behavior, data exposure
* **Response Actions**: Block services, enforce policies, quarantine content
* **API Requirements**: Skyhigh API credentials
* **Setup Time**: 1-2 hours

### Identity & Access Management

#### Okta

**Category:** Identity Provider & SSO\
**Capabilities:** Alert Ingestion, Context Query, Response Actions

**Integration Details:**

* **Alert Sources**: Security events, authentication failures, policy violations
* **Context Queries**: User profiles, group memberships, application access, session details
* **Response Actions**: Suspend user, clear sessions, reset MFA, deactivate account
* **API Requirements**: Okta API token with appropriate scopes
* **Setup Time**: 1-2 hours

**Common Use Cases:**

* Investigate account takeover attempts
* Respond to credential stuffing attacks
* Automate user suspension for compromised accounts
* Enforce step-up authentication

#### Cisco Duo

**Category:** Multi-Factor Authentication\
**Capabilities:** Alert Ingestion, Context Query, Response Actions

**Integration Details:**

* **Alert Sources**: Authentication logs, fraud attempts, bypass events
* **Context Queries**: User authentication history, device trust, location patterns
* **Response Actions**: Deny authentication, remove trusted devices, enforce MFA
* **API Requirements**: Duo Admin API credentials
* **Setup Time**: 1-2 hours

#### Zscaler

**Category:** Zero Trust Network Access\
**Capabilities:** Alert Ingestion, Context Query, Response Actions

**Integration Details:**

* **Alert Sources**: Security policy violations, malware detections, data loss prevention
* **Context Queries**: User activity, web traffic, application access
* **Response Actions**: Block users, enforce policies, isolate traffic
* **API Requirements**: Zscaler API credentials
* **Setup Time**: 1-2 hours

#### ForcePoint

**Category:** Data Loss Prevention & CASB\
**Capabilities:** Alert Ingestion, Context Query, Response Actions

**Integration Details:**

* **Alert Sources**: DLP incidents, insider threat alerts, policy violations
* **Context Queries**: User behavior, data movement, policy matches
* **Response Actions**: Block transfers, quarantine files, notify users
* **API Requirements**: ForcePoint API access
* **Setup Time**: 2-3 hours

### Email Security

#### Proofpoint (TAP & Email Protection)

**Category:** Email Security Gateway\
**Capabilities:** Alert Ingestion, Context Query, Threat Enrichment

**Integration Details:**

* **Alert Sources**: Phishing detections, malware attachments, impostor emails, credential theft
* **Context Queries**: Email forensics, URL analysis, attachment details, campaign information
* **Response Actions**: Quarantine emails, block senders, remove from mailboxes
* **API Requirements**: Proofpoint TAP API credentials
* **Setup Time**: 2-3 hours

**Common Use Cases:**

* Investigate phishing campaigns
* Analyze malicious URLs and attachments
* Track email-based threats
* Automate email remediation

#### Mimecast

**Category:** Email Security & Archiving\
**Capabilities:** Alert Ingestion, Context Query, Response Actions

**Integration Details:**

* **Alert Sources**: Spam, malware, impersonation attacks, data leakage
* **Context Queries**: Email logs, attachment analysis, URL reputation
* **Response Actions**: Block senders, release from quarantine, create policies
* **API Requirements**: Mimecast API credentials
* **Setup Time**: 2-3 hours

#### Barracuda Email Protection

**Category:** Email Security Gateway\
**Capabilities:** Alert Ingestion, Context Query, Response Actions

**Integration Details:**

* **Alert Sources**: Spam, phishing, malware, account takeover
* **Context Queries**: Email logs, threat details, sender reputation
* **Response Actions**: Quarantine emails, block domains, update policies
* **API Requirements**: Barracuda API access
* **Setup Time**: 2-3 hours

#### Cisco Email Security (ESA)

**Category:** Email Security Appliance\
**Capabilities:** Alert Ingestion, Context Query, Response Actions

**Integration Details:**

* **Alert Sources**: Spam, malware, phishing, outbreak alerts
* **Context Queries**: Message tracking, threat analysis, sender verification
* **Response Actions**: Quarantine messages, block senders, update filters
* **API Requirements:** REST API access
* **Setup Time**: 2-3 hours

### Ticketing & ITSM

#### ServiceNow

**Category:** IT Service Management\
**Capabilities:** Ticket Management, Status Sync

**Integration Details:**

* **Alert Sources**: Security incidents (if ServiceNow SecOps used)
* **Context Queries**: Incident history, CMDB data, user information
* **Response Actions**: Create incidents, update status, add work notes, assign to groups, close tickets
* **API Requirements**: ServiceNow instance, integration user with appropriate roles
* **Setup Time**: 1-2 hours

**Common Use Cases:**

* Automatically create incident tickets for AR² investigations
* Sync investigation status with ServiceNow
* Add investigation evidence as work notes
* Close tickets when remediation complete

#### Jira (Service Management)

**Category:** Issue Tracking & Service Management\
**Capabilities:** Ticket Management, Status Sync

**Integration Details:**

* **Alert Sources**: N/A (ticketing only)
* **Context Queries**: Issue history, custom fields, user assignments
* **Response Actions**: Create issues, update status, add comments, transition workflows
* **API Requirements**: Jira Cloud or Data Center, API token or OAuth
* **Setup Time**: 1-2 hours

#### FreshDesk

**Category:** Help Desk & Ticketing\
**Capabilities:** Ticket Management, Status Sync

**Integration Details:**

* **Alert Sources**: N/A (ticketing only)
* **Context Queries**: Ticket history, requester details, agent assignments
* **Response Actions**: Create tickets, update status, add notes, assign agents
* **API Requirements**: FreshDesk API key
* **Setup Time**: 1-2 hours

### Threat Intelligence

#### VirusTotal

**Category:** Malware & URL Analysis\
**Capabilities:** Threat Enrichment

**Integration Details:**

* **Enrichment Queries**: File hash reputation, URL analysis, domain information, IP reputation
* **API Requirements**: VirusTotal API key (free or premium)
* **Rate Limits**: 4 requests/minute (free), 1000 requests/minute (premium)
* **Setup Time**: 15 minutes

**Common Use Cases:**

* Check file hash reputation
* Analyze suspicious URLs
* Investigate domain registrations
* Assess IP address reputation

#### AlienVault OTX

**Category:** Open Threat Exchange\
**Capabilities:** Threat Enrichment

**Integration Details:**

* **Enrichment Queries**: IOC reputation, pulse subscriptions, related indicators
* **API Requirements**: Free OTX account and API key
* **Rate Limits**: 10 requests/second
* **Setup Time**: 15 minutes

#### Recorded Future

**Category:** Threat Intelligence Platform\
**Capabilities:** Threat Enrichment, Context Query

**Integration Details:**

* **Enrichment Queries**: IOC risk scores, threat actor attribution, vulnerability intelligence
* **API Requirements**: Recorded Future subscription and API token
* **Setup Time**: 1-2 hours

#### AbuseIPDB

**Category:** IP Reputation Database\
**Capabilities:** Threat Enrichment

**Integration Details:**

* **Enrichment Queries**: IP abuse confidence score, report history, geolocation
* **API Requirements**: Free or paid API key
* **Rate Limits**: 1000 requests/day (free), higher limits for paid
* **Setup Time**: 15 minutes

#### GreyNoise

**Category:** Internet Scanner Intelligence\
**Capabilities:** Threat Enrichment

**Integration Details:**

* **Enrichment Queries**: Distinguish malicious IPs from benign scanners, classification, tags
* **API Requirements**: GreyNoise API key
* **Setup Time**: 15 minutes

#### URLhaus

**Category:** Malware URL Database\
**Capabilities:** Threat Enrichment

**Integration Details:**

* **Enrichment Queries**: URL reputation, malware family, payload information
* **API Requirements**: Free, no authentication required
* **Setup Time**: 10 minutes

#### PhishTank

**Category:** Phishing URL Database\
**Capabilities:** Threat Enrichment

**Integration Details:**

* **Enrichment Queries**: Phishing URL verification, submission details
* **API Requirements**: Free API key
* **Setup Time**: 10 minutes

#### Have I Been Pwned (HIBP)

**Category:** Breach Intelligence\
**Capabilities:** Threat Enrichment

**Integration Details:**

* **Enrichment Queries**: Email address breach history, password exposure
* **API Requirements**: HIBP API key (paid for automated queries)
* **Setup Time**: 15 minutes

#### MalwareBazaar

**Category:** Malware Sample Repository\
**Capabilities:** Threat Enrichment

**Integration Details:**

* **Enrichment Queries**: Malware hash lookup, sample details, signatures
* **API Requirements**: Free, no authentication required
* **Setup Time**: 10 minutes

#### RiskIQ PassiveTotal

**Category:** Threat Intelligence & Attack Surface\
**Capabilities:** Threat Enrichment, Context Query

**Integration Details:**

* **Enrichment Queries**: Domain/IP relationships, WHOIS data, SSL certificates, passive DNS
* **API Requirements**: RiskIQ subscription and API credentials
* **Setup Time**: 1-2 hours

#### Censys

**Category:** Internet Asset Intelligence\
**Capabilities:** Threat Enrichment

**Integration Details:**

* **Enrichment Queries**: IP/domain exposure, certificate information, service enumeration
* **API Requirements**: Censys API credentials
* **Setup Time**: 30 minutes

#### Shodan

**Category:** Internet Device Search Engine\
**Capabilities:** Threat Enrichment

**Integration Details:**

* **Enrichment Queries**: IP service information, vulnerability exposure, device details
* **API Requirements**: Shodan API key
* **Setup Time**: 15 minutes

#### IBM X-Force Exchange

**Category:** Threat Intelligence Platform\
**Capabilities:** Threat Enrichment

**Integration Details:**

* **Enrichment Queries**: IOC reputation, threat reports, vulnerability data
* **API Requirements**: IBM X-Force account and API key
* **Setup Time**: 30 minutes

#### Emerging Threats (Proofpoint ET Intelligence)

**Category:** IDS/IPS Rules & Threat Intelligence\
**Capabilities:** Threat Enrichment

**Integration Details:**

* **Enrichment Queries**: Rule information, IOC feeds, threat categories
* **API Requirements**: ET Intelligence subscription
* **Setup Time**: 1 hour

#### Hunter.io

**Category:** Email Verification & OSINT\
**Capabilities:** Context Query

**Integration Details:**

* **Enrichment Queries**: Email verification, domain email patterns, contact discovery
* **API Requirements**: Hunter.io API key
* **Setup Time**: 15 minutes

#### SANS Internet Storm Center

**Category:** Threat Intelligence & Research\
**Capabilities:** Threat Enrichment

**Integration Details:**

* **Enrichment Queries**: IP reputation, port scanning activity, threat trends
* **API Requirements**: Free, no authentication required
* **Setup Time**: 10 minutes

#### Anomali ThreatStream

**Category:** Threat Intelligence Platform\
**Capabilities:** Threat Enrichment, Context Query

**Integration Details:**

* **Enrichment Queries**: IOC intelligence, threat actor profiles, campaign tracking
* **API Requirements**: Anomali subscription and API credentials
* **Setup Time**: 1-2 hours

### Sandbox & Malware Analysis

#### Hybrid Analysis

**Category:** Malware Sandbox\
**Capabilities:** Threat Enrichment

**Integration Details:**

* **Enrichment Queries**: File behavior analysis, IOC extraction, malware family identification
* **API Requirements**: Hybrid Analysis API key
* **Setup Time**: 30 minutes

#### Joe Sandbox

**Category:** Malware Analysis Platform\
**Capabilities:** Threat Enrichment

**Integration Details:**

* **Enrichment Queries**: Deep malware analysis, behavior reports, IOC extraction
* **API Requirements**: Joe Sandbox subscription and API key
* **Setup Time**: 30 minutes

#### ANY.RUN

**Category:** Interactive Malware Sandbox\
**Capabilities:** Threat Enrichment

**Integration Details:**

* **Enrichment Queries**: Malware behavior, network activity, process tree
* **API Requirements**: ANY.RUN API key
* **Setup Time**: 30 minutes

### Vulnerability Management

#### Qualys VMDR

**Category:** Vulnerability Management\
**Capabilities:** Context Query

**Integration Details:**

* **Context Queries**: Asset vulnerabilities, patch status, compliance posture
* **API Requirements**: Qualys subscription and API credentials
* **Setup Time**: 1-2 hours

#### Rapid7 InsightVM / Nexpose

**Category:** Vulnerability Management\
**Capabilities:** Context Query

**Integration Details:**

* **Context Queries**: Vulnerability data, asset inventory, risk scores
* **API Requirements**: Rapid7 API key
* **Setup Time**: 1-2 hours

#### Tenable Nessus / Tenable.io

**Category:** Vulnerability Scanning\
**Capabilities:** Context Query

**Integration Details:**

* **Context Queries**: Scan results, vulnerability details, asset information
* **API Requirements**: Tenable API keys
* **Setup Time**: 1-2 hours

***

### Log Management & Search

#### Elasticsearch

**Category:** Search & Analytics Engine\
**Capabilities:** Context Query

**Integration Details:**

* **Context Queries**: Full-text log search, aggregations, time-series analysis
* **API Requirements**: Elasticsearch cluster access, appropriate index permissions
* **Setup Time**: 1-2 hours

#### OpenSearch

**Category:** Search & Analytics Engine\
**Capabilities:** Context Query

**Integration Details:**

* **Context Queries**: Log search, aggregations, dashboards
* **API Requirements**: OpenSearch cluster access
* **Setup Time**: 1-2 hours

### Threat Intelligence Platforms

#### MISP (Malware Information Sharing Platform)

**Category:** Threat Intelligence Sharing\
**Capabilities:** Threat Enrichment, Context Query

**Integration Details:**

* **Enrichment Queries**: IOC lookup, event correlation, threat sharing
* **API Requirements**: MISP instance access, API key
* **Setup Time**: 1-2 hours

#### ThreatConnect

**Category:** Threat Intelligence Platform\
**Capabilities:** Threat Enrichment, Context Query

**Integration Details:**

* **Enrichment Queries**: IOC intelligence, threat campaigns, adversary tracking
* **API Requirements**: ThreatConnect subscription and API credentials
* **Setup Time**: 1-2 hours

#### Talos Intelligence

**Category:** Threat Intelligence & Reputation\
**Capabilities:** Threat Enrichment

**Integration Details:**

* **Enrichment Queries**: IP/domain reputation, threat categories, blocklist status
* **API Requirements**: Free, web-based queries
* **Setup Time**: 15 minutes

***

## Custom Connector Development

### When to Build Custom Connectors

Consider custom connector development when:

* Proprietary Tools: Your organization uses internally developed security tools
* Niche Vendors: Security tool not in our standard catalog
* Specialized Requirements: Unique integration patterns or data formats
* Legacy Systems: Older systems without modern APIs

### Custom Connector Framework

AR² provides a connector SDK that simplifies custom development:

SDK Features:

* Python-Based: Leverage familiar Python libraries and frameworks
* Template Library: Pre-built templates for common integration patterns
* Testing Framework: Automated testing and validation tools
* Documentation Generator: Auto-generate connector documentation
* Deployment Automation: One-command deployment to AR² platform

### Development Process

{% stepper %}
{% step %}

### Requirements Gathering

Define integration scope, API capabilities, authentication (1-2 days).
{% endstep %}

{% step %}

### Development

Implement connector using SDK templates (3-5 days).
{% endstep %}

{% step %}

### Testing

Unit tests, integration tests, end-to-end validation (2-3 days).
{% endstep %}

{% step %}

### Documentation

Usage guide, configuration parameters, troubleshooting (1 day).
{% endstep %}

{% step %}

### Deployment

Deploy to AR² environment, configure in production (1 day).

**Total Custom Connector Timeline:** 1-2 weeks
{% endstep %}
{% endstepper %}

### Professional Services

BluSapphire offers professional services for custom connector development:

* Connector Development: We build the connector for you ($5,000 - $15,000 per connector)
* Integration Consulting: Architecture review and integration planning ($200/hour)
* Training: SDK training for your development team (2-day workshop, $5,000)

## Connector Maintenance & Updates

### Automatic Updates

All native connectors are automatically updated by BluSapphire:

* API Changes: Connectors updated within 30 days of vendor API changes
* Security Patches: Critical security updates deployed within 48 hours
* Feature Enhancements: New capabilities added quarterly
* Compatibility Testing: Continuous testing against latest tool versions

### Version Compatibility

| Connector Update Type        | Customer Action Required | Notification                            |
| ---------------------------- | ------------------------ | --------------------------------------- |
| **Patch** (bug fixes)        | None (automatic)         | Email notification                      |
| **Minor** (new features)     | None (automatic)         | Email notification + release notes      |
| **Major** (breaking changes) | Review and approve       | 30-day advance notice + migration guide |

### Deprecation Policy

When security tools are deprecated or replaced:

* 12-Month Notice: Advance notification of connector deprecation
* Migration Support: Assistance migrating to replacement tools
* Extended Support: Optional paid support for deprecated connectors (12 months)

***

## Integration Best Practices

### Start with Core Integrations

Recommended First 5 Connectors:

* Primary SIEM (Splunk, QRadar, Sentinel)
* EDR platform (CrowdStrike, SentinelOne, Defender)
* Cloud security (AWS Security Hub, Azure Defender, GCP SCC)
* Identity provider (Okta, Azure AD)
* Ticketing system (ServiceNow, Jira)

### Validate Data Quality

Before enabling connectors in production:

* Test Alert Flow: Verify alerts are ingested correctly
* Validate Context Queries: Ensure queries return expected data
* Test Response Actions: Validate actions in non-production environment
* Check Rate Limits: Confirm API rate limits are sufficient

### Configure Appropriate Permissions

Follow principle of least privilege:

* Read-Only: For threat intelligence and context enrichment
* Read-Write: For response actions (isolate, block, disable)
* Admin: Only when absolutely necessary (rare)

### Monitor Connector Health

AR² provides built-in connector monitoring:

* Connection Status: Real-time status of each connector
* API Rate Limits: Track usage against limits
* Error Rates: Alert on elevated error rates
* Latency Metrics: Monitor query and action performance

### Implement Staged Rollout

Deploy connectors in phases:

* Phase 1: Alert ingestion only (observe, no actions)
* Phase 2: Enable context queries (enrich investigations)
* Phase 3: Enable low-risk actions (create tickets, add comments)
* Phase 4: Enable high-risk actions (isolate, block, disable)

***

## Troubleshooting Common Issues

### Authentication Failures

**Symptoms:** Connector shows "Authentication Failed" status

**Common Causes:**

* Expired API keys or tokens
* Insufficient permissions
* IP allowlist restrictions
* Credential rotation without updating AR²

**Resolution:**

1. Verify credentials are current
2. Check API key/token expiration
3. Confirm required permissions are granted
4. Update AR² connector configuration with new credentials

### Rate Limit Errors

**Symptoms:** Connector shows "Rate Limit Exceeded" errors

**Common Causes:**

* High alert volume exceeds API limits
* Multiple systems querying same API
* Insufficient API tier for usage

**Resolution:**

1. Review API rate limits for your tier
2. Adjust AR² polling intervals
3. Upgrade to higher API tier if available
4. Implement request batching where supported

### Data Quality Issues

**Symptoms:** Incomplete or incorrect data in investigations

**Common Causes:**

* Misconfigured log sources
* Incomplete security tool deployment
* Data retention policies too aggressive
* API returning partial results

**Resolution:**

1. Validate security tool configuration
2. Check data retention settings
3. Review API query parameters
4. Enable verbose logging for debugging

Request a Connector: If you need a connector not on our roadmap, contact <integrations@blusapphire.com>

## Conclusion

AR²'s comprehensive connector ecosystem enables seamless integration with your existing security infrastructure, eliminating the need for custom development in most cases. With 74+ native connectors and a robust SDK for custom development, AR² can integrate with virtually any security tool in your environment.

All connectors are maintained and updated by BluSapphire, ensuring long-term compatibility and reliability as your security tools evolve.

For connector-specific questions, integration support, or custom connector development inquiries, contact <integrations@blusapphire.com>

Document Version: 1.0\
Last Updated: February 2026\
Next Review: May 2026


# Design Principles

**The Philosophy Behind Agentic AI Security Operations**

## Overview

AR² was designed from first principles to address a fundamental challenge in modern cybersecurity: **human defenders cannot match the speed and scale of AI-powered attacks**. Traditional Security Operations Centers (SOCs) rely on human analysts to triage, investigate, and respond to security alerts—a process that takes hours or days. Meanwhile, modern attacks execute in seconds.

This document outlines the core design principles that guided AR²'s development and explains the architectural decisions that enable autonomous, intelligent, and trustworthy security operations.

## Foundational Principles

{% stepper %}
{% step %}

### Speed Matches Threat Velocity

**Principle:** Defender response time must match or exceed attacker execution speed.

**Challenge:**\
Modern cyber attacks leverage automation and AI to execute at machine speed. A ransomware attack can encrypt an entire network in under 60 minutes. Credential theft and lateral movement happen in seconds. Human analysts, no matter how skilled, cannot respond fast enough to contain rapidly evolving threats.

**Design Response:**\
AR² agents operate continuously and autonomously, investigating alerts and executing responses in under 60 seconds. By eliminating human bottlenecks in routine decisions, AR² matches attacker velocity with defender intelligence.

**Implementation:**

* Parallel Processing: Multiple agents investigate simultaneously, not sequentially
* Autonomous Decision-Making: Agents execute pre-approved actions without waiting for human approval
* Real-Time Integration: Direct API connections to security tools eliminate manual data gathering
* Optimized Workflows: Investigation paths optimized for speed without sacrificing thoroughness

**Trade-offs:**

* Autonomy requires robust safety mechanisms (confidence scoring, policy guardrails)
* Speed optimization may sacrifice some explainability (addressed through audit trails)
  {% endstep %}

{% step %}

### Specialization Over Generalization

**Principle:** Deep expertise in specific domains outperforms shallow knowledge across all domains.

**Challenge:**\
Security operations span diverse disciplines: network analysis, endpoint forensics, identity management, cloud security, malware analysis, threat intelligence, and more. No single AI model can be expert in all areas simultaneously. Generalist approaches lead to mediocre performance across the board.

**Design Response:**\
AR² deploys 12 specialized agents, each with deep expertise in a specific security domain. This mirrors how elite SOC teams organize: network analysts, endpoint specialists, threat intel researchers, etc. Specialization enables depth of analysis that generalist systems cannot achieve.

**Implementation:**

* Domain-Specific Training: Each agent trained on specialized datasets for their domain
* Dedicated Tooling: Agents have access to domain-specific tools and APIs
* Expert Reasoning: Agents apply domain-specific heuristics and best practices
* Collaborative Intelligence: Specialists share findings to build comprehensive picture

**Trade-offs:**

* Increased system complexity (12 agents vs. 1 generalist)
* Requires sophisticated orchestration to coordinate specialists
* Higher computational cost (multiple specialized models vs. one generalist)

**Why It's Worth It:**\
Specialized agents achieve 30-40% higher accuracy in their domains compared to generalist approaches, leading to fewer false positives and more actionable findings.
{% endstep %}

{% step %}

### Collaboration Amplifies Intelligence

**Principle:** Multiple specialized agents collaborating produce better outcomes than any single agent working alone.

**Challenge:**\
Security investigations rarely fit neatly into a single domain. A phishing attack involves email analysis, endpoint forensics, network traffic inspection, identity verification, and threat intelligence correlation. Siloed analysis misses connections across domains.

**Design Response:**\
AR² agents collaborate through a shared context layer, enabling them to build on each other's findings. When the Email Agent identifies a suspicious attachment, the Malware Agent analyzes the file, the Network Agent traces command-and-control traffic, and the Endpoint Agent examines affected systems—all simultaneously and with full visibility into each other's discoveries.

**Implementation:**

* Shared Investigation Graph: Unified knowledge graph tracks entities, relationships, and evidence
* Event Bus Architecture: Agents publish findings that other agents can subscribe to
* Consensus Mechanisms: Critical decisions require agreement from multiple agents
* Cross-Domain Reasoning: Agents can query specialists for domain-specific insights

**Example:**

```
Alert: Suspicious email with attachment

Email Agent: Identifies phishing indicators, extracts attachment hash
    ↓
Malware Agent: Analyzes hash, determines it's a known trojan
    ↓
Threat Intel Agent: Correlates with active campaign targeting financial sector
    ↓
Endpoint Agent: Checks if any users opened attachment, finds 3 affected hosts
    ↓
Network Agent: Traces C2 traffic from affected hosts to attacker infrastructure
    ↓
Remediation Agent: Isolates hosts, blocks C2 domains, quarantines emails
    ↓
Communication Agent: Notifies security team with full investigation timeline
```

**Trade-offs:**

* Increased coordination overhead
* Potential for conflicting recommendations (resolved through consensus)
* More complex debugging when investigations span multiple agents
  {% endstep %}

{% step %}

### Autonomy with Accountability

**Principle:** Agents should operate autonomously within defined boundaries, with full transparency and human oversight.

**Challenge:**\
Full autonomy without constraints is dangerous—agents could take disruptive actions that harm business operations. But requiring human approval for every action eliminates the speed advantage. The challenge is finding the right balance.

**Design Response:**\
AR² implements **bounded autonomy**: agents can make decisions independently within their domain expertise and organizational policies, but must escalate when confidence is low or impact is high. Every action is logged, auditable, and reversible.

**Implementation:**

Confidence Scoring:

* Every agent decision includes a confidence score (0-100%)
* High-confidence decisions (>90%): Auto-execute
* Medium-confidence decisions (70-90%): Execute with notification
* Low-confidence decisions (<70%): Escalate to human analyst

Policy Guardrails:

* Organizational policies define acceptable automated actions
* Example: "Auto-isolate endpoints for malware, but require approval for servers"
* Policies can be customized per asset type, user role, time of day, etc.

Audit Trail:

* Complete logging of all agent decisions, actions, and reasoning
* Immutable audit log for compliance and forensics
* Searchable investigation history for learning and improvement

Escalation Protocols:

* Automatic escalation for high-impact scenarios (executive accounts, critical infrastructure)
* Human analysts can override agent decisions at any time
* Agents learn from human overrides to improve future decisions

**Trade-offs:**

* Reduced autonomy in high-stakes scenarios (by design)
* Audit logging adds storage and processing overhead
* Confidence calibration requires ongoing tuning
  {% endstep %}

{% step %}

### Context is Critical

**Principle:** Generic security analysis produces generic results. Context-aware analysis produces actionable insights.

**Challenge:**\
AI agents lack organizational context by default. They don't know which servers are critical, which users are executives, which processes are approved, or which behaviors are normal for your environment. Without context, agents generate false positives and miss true threats.

**Design Response:**\
AR² incorporates organizational context through **Enterprise Intelligence**, a framework for codifying human expertise as structured data that agents can query and apply during investigations. This transforms AR² from a generic platform into an organization-specific defense system.

**Implementation:**

* Artifact Context: Define context for IPs, users, processes, domains, etc.
* Criticality Scoring: Identify high-value assets that require elevated scrutiny
* Behavioral Baselines: Establish normal patterns for users, systems, and applications
* Policy Integration: Encode organizational policies as machine-readable rules

**Example Without Context:**

```
Alert: Process execution on 10.0.50.15
Agent Analysis: Unknown IP, unknown process
Recommendation: Isolate immediately
Result: Production database offline, business disruption
```

**Example With Context:**

```
Alert: Process execution on 10.0.50.15
Agent Analysis:
  - IP 10.0.50.15 = Critical database server (Finance)
  - Process = backup_agent.exe (Approved IT tool)
  - Time = Saturday 3 AM (maintenance window)
Recommendation: Expected behavior, monitor only
Result: No disruption, analyst time saved
```

**Trade-offs:**

* Requires initial investment to populate Enterprise Intelligence
* Context must be maintained as environment changes
* Incomplete context can lead to incorrect decisions (mitigated through confidence scoring)
  {% endstep %}

{% step %}

### Learning from Every Investigation

**Principle:** The system should continuously improve based on investigation outcomes and analyst feedback.

**Challenge:**\
Static AI systems become obsolete as attack techniques evolve. Manual retraining is slow and expensive. The system must learn and adapt continuously.

**Design Response:**\
AR² implements multiple learning loops that enable continuous improvement without manual retraining.

**Feedback Mechanisms:**

1. Analyst Feedback Loop:
   * Analysts mark investigations as true positive, false positive, or inconclusive
   * Agents learn which patterns are legitimate vs. malicious
   * False positive feedback triggers Enterprise Intelligence updates
2. Outcome-Based Learning:
   * Track investigation outcomes (threat contained, false alarm, escalated)
   * Agents adjust confidence scoring based on historical accuracy
   * Successful investigation patterns are reinforced
3. Cross-Customer Learning (Privacy-Preserving):
   * Anonymized threat patterns shared across AR² deployments
   * Emerging threats detected at one customer benefit all customers
   * Federated learning preserves customer data privacy
4. Threat Intelligence Integration:
   * Continuous ingestion of global threat intelligence feeds
   * Agents update knowledge of TTPs, IOCs, and threat actors
   * Real-time adaptation to emerging threats

**Implementation:**

* Reinforcement Learning: Agents optimize decision-making based on investigation outcomes
* Model Updates: Regular model updates incorporate new threat patterns
* A/B Testing: New agent behaviors tested in shadow mode before production deployment
* Feedback UI: Analysts can provide feedback directly from investigation interface

**Trade-offs:**

* Learning requires sufficient data (cold start problem for new deployments)
* Feedback quality depends on analyst accuracy (mitigated through consensus)
* Continuous learning adds computational overhead
  {% endstep %}

{% step %}

### Explainability Builds Trust

**Principle:** Security teams must understand why agents made specific decisions to trust and validate their actions.

**Challenge:**\
"Black box" AI systems that provide recommendations without explanation are difficult to trust, validate, and debug. Security operations require transparency to meet compliance requirements and build analyst confidence.

**Design Response:**\
AR² agents provide **chain-of-thought reasoning**, documenting their decision-making process step-by-step with citations to supporting evidence. Every conclusion links to specific log entries, alerts, or data sources that justify the finding.

**Implementation:**

Investigation Narrative:

```
Investigation: Suspicious login from unusual location

Triage Agent:
  ✓ User: john.doe@company.com
  ✓ Location: Moscow, Russia
  ✓ Normal location: New York, USA (Enterprise Intelligence)
  ✓ Impossible travel: Last login 30 minutes ago from NYC
  → Confidence: 95% - Likely account compromise

Identity Agent:
  ✓ Recent password change: No
  ✓ MFA status: Bypassed (suspicious)
  ✓ Access pattern: Unusual systems accessed (Finance DB)
  → Confidence: 90% - Credential theft confirmed

Network Agent:
  ✓ Source IP: 185.220.101.50 (known VPN exit node)
  ✓ User-agent: Automated tool (not typical browser)
  → Confidence: 85% - Likely automated attack

Recommendation: Disable account, revoke sessions, notify user
Confidence: 95% (consensus across 3 agents)
Evidence: [Link to logs, Enterprise Intelligence entries, threat intel]
```

Audit Trail:

* Complete log of agent queries, API calls, and data accessed
* Timestamps for every action
* User attribution for human overrides
* Exportable for compliance reporting

**Trade-offs:**

* Explainability adds latency (agents must document reasoning)
* Verbose explanations can overwhelm analysts (mitigated through progressive disclosure)
* Some ML models are inherently less explainable (use explainable models where possible)
  {% endstep %}

{% step %}

### Security by Design

**Principle:** The security platform itself must be secure and trustworthy.

**Challenge:**\
A compromised security platform is worse than no security platform. Attackers target security tools to disable defenses and hide their activities. AR² must be resilient against attacks targeting the platform itself.

**Design Response:**\
AR² implements defense-in-depth security architecture with multiple layers of protection.

**Platform Security:**

1. Zero Trust Architecture:
   * All inter-component communication requires authentication
   * Least-privilege access for all agents and services
   * Network segmentation between components
2. Secrets Management:
   * Integration credentials stored in hardware security modules (HSM)
   * Automatic credential rotation
   * Encrypted at rest and in transit
3. Input Validation:
   * All external data sanitized before processing
   * Protection against prompt injection attacks
   * Rate limiting and anomaly detection on API endpoints
4. Audit Logging:
   * Immutable audit trail of all actions
   * Tamper-evident logging with cryptographic signatures
   * Real-time monitoring for suspicious platform activity
5. Adversarial Robustness:
   * Agents trained to detect manipulation attempts
   * Multi-source validation for critical findings
   * Behavioral consistency checks

Compliance:

* SOC 2 Type II certified
* ISO 27001 certified
* GDPR compliant
* HIPAA ready

**Trade-offs:**

* Security controls add latency and complexity
* Strict access controls may limit integration flexibility
* Compliance requirements increase operational overhead
  {% endstep %}

{% step %}

### Graceful Degradation

**Principle:** The system should continue operating effectively even when components fail or data is incomplete.

**Challenge:**\
Security operations cannot tolerate downtime. Integrations fail, APIs become unavailable, data sources go offline. The system must adapt and continue providing value even under degraded conditions.

**Design Response:**\
AR² implements graceful degradation at multiple levels.

**Component Resilience:**

* Agent Redundancy: Multiple instances of each agent type for high availability
* Failover: Automatic failover to backup components
* Circuit Breakers: Prevent cascading failures when integrations fail
* Retry Logic: Intelligent retry with exponential backoff

**Data Resilience:**

* Caching: Cache frequently accessed data to reduce dependency on external systems
* Fallback Sources: Use alternative data sources when primary sources unavailable
* Partial Analysis: Provide best-effort analysis with available data
* Confidence Adjustment: Reduce confidence scores when data is incomplete

**Operational Resilience:**

* Advisory Mode: Fall back to advisory-only mode if automated actions are risky
* Manual Override: Analysts can always take manual control
* Status Monitoring: Real-time visibility into component health and data availability

**Example:**

```
Scenario: EDR integration offline

Without Graceful Degradation:
  - All investigations blocked waiting for EDR data
  - Alerts pile up unprocessed
  - Security team blind to threats

With Graceful Degradation:
  - Agents proceed with available data (SIEM, firewall, identity)
  - Confidence scores adjusted downward (EDR data missing)
  - Automated actions disabled (insufficient data for safe decisions)
  - Investigations continue in advisory mode
  - Alerts processed, analysts notified of degraded capability
```

**Trade-offs:**

* Graceful degradation adds complexity (multiple code paths)
* Partial analysis may miss threats (mitigated through conservative confidence scoring)
* Failover mechanisms increase infrastructure cost
  {% endstep %}

{% step %}

### Human-AI Collaboration

**Principle:** AI augments human expertise; it does not replace it.

**Challenge:**\
Fully autonomous AI without human oversight is risky and untrustworthy. But requiring human approval for every decision eliminates speed advantages. The goal is optimal collaboration where AI handles routine tasks and humans focus on complex, high-stakes decisions.

**Design Response:**\
AR² is designed for **human-AI teaming**, where agents handle high-volume routine investigations and escalate complex or high-impact scenarios to human analysts. The division of labor plays to each party's strengths.

AI Strengths:

* Speed: Process thousands of alerts per day
* Consistency: Apply policies uniformly without fatigue
* Scale: Investigate every alert, not just high-priority ones
* Pattern Recognition: Detect subtle patterns across large datasets

Human Strengths:

* Judgment: Handle ambiguous, novel, or high-stakes scenarios
* Creativity: Develop new investigation techniques and hypotheses
* Context: Apply organizational knowledge that isn't codified
* Accountability: Make final decisions on critical actions

Collaboration Model:

| Task                   | AI Role                                 | Human Role                         |
| ---------------------- | --------------------------------------- | ---------------------------------- |
| Alert Triage           | Automated (95%+ of alerts)              | Review edge cases (5%)             |
| Routine Investigations | Fully automated                         | Audit sample for quality           |
| Complex Investigations | Gather evidence, suggest hypotheses     | Lead investigation, make decisions |
| Low-Risk Actions       | Automated (block IPs, quarantine files) | Approve policies                   |
| High-Risk Actions      | Recommend with evidence                 | Approve and execute                |
| Incident Response      | Execute playbooks                       | Coordinate response, communicate   |
| Threat Hunting         | Proactive scanning                      | Define hunt hypotheses             |
| Policy Tuning          | Suggest optimizations                   | Approve policy changes             |

**Implementation:**

* Escalation Thresholds: Configurable thresholds for when agents escalate to humans
* Collaborative UI: Interface designed for human-AI collaboration, not replacement
* Agent Transparency: Agents explain reasoning so humans can validate and learn
* Feedback Loops: Humans provide feedback to improve agent performance

**Trade-offs:**

* Collaboration requires cultural change (analysts must trust AI)
* Optimal division of labor varies by organization (requires tuning)
* Human oversight adds latency for escalated cases (by design)
  {% endstep %}
  {% endstepper %}

## Design Trade-offs and Decisions

### Trade-off: Speed vs. Thoroughness

**Decision:** Optimize for speed while maintaining thoroughness through parallel processing.\
**Rationale:** Sequential investigation is thorough but slow. Parallel investigation achieves both speed and thoroughness.\
**Implementation:** Orchestration engine activates all relevant agents simultaneously.

### Trade-off: Autonomy vs. Safety

**Decision:** Implement bounded autonomy with confidence-based escalation.\
**Rationale:** Full autonomy is fast but risky. No autonomy is safe but slow. Bounded autonomy balances both.\
**Implementation:** Agents operate autonomously for high-confidence, low-impact decisions; escalate for low-confidence or high-impact scenarios.

### Trade-off: Generalization vs. Specialization

**Decision:** Deploy specialized agents rather than a single generalist.\
**Rationale:** Specialization achieves higher accuracy in each domain, outweighing the complexity cost.\
**Implementation:** 12 specialized agents with orchestration layer for coordination.

### Trade-off: Explainability vs. Performance

**Decision:** Prioritize explainability even at the cost of some performance.\
**Rationale:** Security operations require transparency for trust, validation, and compliance. The performance cost is acceptable.\
**Implementation:** Chain-of-thought reasoning, evidence citation, audit trails.

### Trade-off: Customization vs. Standardization

**Decision:** Provide standardization with customization hooks (Enterprise Intelligence, policies).\
**Rationale:** Standardized agents ensure consistent quality. Customization hooks enable organization-specific adaptation.\
**Implementation:** Core agents are standardized; Enterprise Intelligence and policies provide customization.

## Architectural Patterns

### Pattern: Event-Driven Architecture

**Description:** Agents communicate through asynchronous events rather than synchronous calls.\
**Benefits:**

* Loose coupling between agents
* High scalability
* Fault tolerance (failed agents don't block others)

**Implementation:** Apache Kafka message bus for event streaming.

### Pattern: Microservices

**Description:** Each agent is an independent service with its own lifecycle.\
**Benefits:**

* Independent scaling
* Independent deployment
* Fault isolation

**Implementation:** Kubernetes for container orchestration.

### Pattern: CQRS (Command Query Responsibility Segregation)

**Description:** Separate read models (queries) from write models (actions).\
**Benefits:**

* Optimized query performance
* Clear separation between investigation (read) and response (write)
* Audit trail for all write operations

**Implementation:** Separate query and command APIs for each agent.

### Pattern: Saga Pattern

**Description:** Long-running investigations modeled as sagas with compensation logic.\
**Benefits:**

* Handle multi-step investigations that span minutes or hours
* Rollback capability if investigation is invalidated
* Consistent state management

**Implementation:** Orchestration engine manages investigation sagas.

## Design Evolution

### Version 1.0 (Current)

**Focus:** Core investigation and response capabilities

**Capabilities:**

* 12 specialized agents
* Sub-60-second response time
* 74+ native integrations
* Enterprise Intelligence framework
* Bounded autonomy with confidence scoring

### Version 2.0 (Q3 2026)

**Focus:** Predictive and proactive capabilities

**Planned Enhancements:**

* Predictive Threat Hunting: Agents proactively search for threats before alerts fire
* Cross-Tenant Learning: Anonymized learning across customer base
* Advanced Simulation: Test response playbooks in sandbox before production
* Natural Language Interface: Analysts can query agents using natural language

### Version 3.0 (2027)

**Focus:** Autonomous security operations

**Vision:**

* Self-Healing Security: Agents automatically remediate misconfigurations
* Adversarial Simulation: Agents simulate attacks to test defenses
* Strategic Recommendations: Agents suggest security architecture improvements
* Full Autonomy Mode: Option for fully autonomous operations with human oversight

## Conclusion

AR²'s design principles reflect a fundamental rethinking of security operations for the AI era. By combining specialized agents, autonomous decision-making, collaborative intelligence, and human oversight, AR² achieves what was previously impossible: comprehensive investigation and response to every security alert in under 60 seconds.

These principles are not theoretical—they are battle-tested through real-world deployments across financial services, healthcare, technology, and government sectors. As threats evolve, AR²'s design ensures the platform can adapt and improve continuously.

The future of security operations is not human vs. AI, but human-AI collaboration where each party contributes their unique strengths. AR² is designed to be the ideal AI teammate for security professionals.

For design discussions, architecture reviews, or technical deep-dives, contact our solutions engineering team at <solutions@blusapphire.com>

Document Version: 1.0\
Last Updated: February 2026\
Next Review: May 2026


# 05\_OneAgent

**Prevention-First Endpoint Security**

BluSapphire OneAgent is a lightweight, prevention-first endpoint agent that provides deep visibility and control over your endpoints. It is designed to be silent and efficient, with a minimal performance impact (<1% CPU), while providing robust protection against a wide range of threats, including malware, ransomware, and fileless attacks.

<figure><img src="https://2078222076-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MMRHZBPHlLDUc8519fX%2Fuploads%2F1YNucQY6XA9quovcVXok%2FOneAgent01.png?alt=media&amp;token=b0f0aced-495f-433f-9445-1389a42ee7a2" alt=""><figcaption></figcaption></figure>

## Key Features

* **Prevention-First:** OneAgent focuses on preventing threats before they can execute, with a 99.9% prevention rate.
* **Lightweight & Efficient:** A single, lightweight agent with a minimal footprint (<1% CPU, <20ms block time) that doesn't slow down your endpoints.
* **Deep Visibility:** Provides deep visibility into endpoint activity, including process execution, file system changes, and network connections.
* **Cross-Platform Support:** Supports a wide range of operating systems, including Windows, macOS, and Linux.
* **Integrated with OnePlatform:** Seamlessly integrated with the BluSapphire OnePlatform, providing a single pane of glass for endpoint security and security operations.

{% hint style="info" %}
Integrated with OnePlatform: single pane of glass for endpoint security and security operations.
{% endhint %}

## How It Works

<details>

<summary>Overview</summary>

OneAgent is deployed to your endpoints and continuously monitors for malicious activity. When a threat is detected, it takes immediate action to block it and sends detailed telemetry to the SIEMless™ engine for further analysis and correlation. This tight integration allows for a rapid, coordinated response to threats across your entire environment.

</details>

## Benefits

{% columns %}
{% column %}

* **Stop Threats at the Source:** Prevent attacks before they can cause damage.
* **Improve Endpoint Performance:** Eliminate the performance drag of bloated, legacy endpoint security solutions.
  {% endcolumn %}

{% column %}

* **Gain Complete Visibility:** Understand what's happening on your endpoints and detect threats that other tools miss.
* **Simplify Endpoint Security:** A single agent, a single console, a single platform for a simplified and more effective endpoint security posture.
  {% endcolumn %}
  {% endcolumns %}


# 06\_What is SIEMless ?

**The AI-First, Next-Generation SIEM**

BluSapphire SIEMless™ is the core intelligence hub of the OnePlatform. It is a next-generation Security Information and Event Management (SIEM) solution built with an AI-first architecture to overcome the limitations of legacy SIEMs. It provides real-time threat detection, automated signal mapping, and advanced User and Entity Behavior Analytics (UEBA) without the complexity, high costs, and vendor lock-in of traditional solutions.

<figure><img src="https://2078222076-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MMRHZBPHlLDUc8519fX%2Fuploads%2FLmVjZAjFi1UMi4rH2dse%2Ffederated_architecture_transparent.png?alt=media&amp;token=22249121-fd52-492c-80e1-4665a2c42939" alt=""><figcaption></figcaption></figure>

## Key Features

* **AI-Driven Detections:** Leverages a multi-layered AI engine to identify threats in real-time, including known and unknown attack patterns.
* **Automated Signal Mapping:** Automatically correlates related alerts and events into a single, prioritized signal, reducing alert fatigue by up to 95%.
* **Natively Integrated UEBA:** AI-generated UEBA detections identify anomalous behavior and insider threats without the need for complex rule-writing.
* **Federated Architecture:** A unique, federated model allows for centralized visibility and control without the need to backhaul all data to a central location, dramatically reducing data transfer and storage costs.
* **Custom Rule Building:** Provides a flexible and powerful interface for creating custom detection rules to address unique organizational threats.
* **Detection Orchestration:** Automate and customize your detection workflows, including alert suppression, custom forwarding, and integration with other tools.

## How It Works

{% stepper %}
{% step %}

### Detect Threats

Real-time analysis of data streams to identify malicious activity.
{% endstep %}

{% step %}

### Correlate Signals

Automatically group related alerts into a single, high-fidelity signal.
{% endstep %}

{% step %}

### Analyze Behavior

Monitor user and entity behavior to detect deviations from baseline activity.
{% endstep %}

{% step %}

### Prioritize Incidents

Surface the most critical threats, allowing your security team to focus on what matters most.
{% endstep %}
{% endstepper %}

## Benefits

* **Reduce Alert Fatigue:** Cut through the noise and focus on the threats that matter.
* **Accelerate Threat Detection:** Identify threats in minutes, not hours or days.
* **Lower TCO:** Eliminate the high licensing, infrastructure, and operational costs of legacy SIEMs.
* **Increase Analyst Efficiency:** Empower your team to be more proactive and strategic.


# 01 Detection at Edge

## What is "Detection at Edge"?

**Detection at Edge** is BluSapphire's shift-left architecture that allows customers to deploy threat detection capabilities at the **cloud edge**, **data center edge**, or **branch edge** — exactly where logs are generated. This eliminates the traditional requirement to move massive volumes of log data to centralized SIEM infrastructure or SaaS platforms.

### The Paradigm Shift

Traditional SIEM Architecture:

```
Branch/Cloud → Forward All Logs → Central SIEM → Detect Threats
                (Expensive)        (Vendor Lock-in)
```

BluSapphire Detection at Edge:

```
Branch/Cloud → Detect at Edge → Send Metadata/Alerts Only → Central Console
              (Local Storage)    (98% Cost Reduction)        (Unified View)
```

***

## Core Value Propositions

### Data Sovereignty & Complete Control

The Problem with Traditional SIEMs:

* Competitors (Splunk, QRadar, Elastic, DNIF) require logs to be forwarded to centralized infrastructure
* Data must leave customer premises/cloud VPC
* Shared control with vendor
* Complex multi-region deployments require separate instances

BluSapphire's Solution:

* Logs stay where generated — never leave customer premises or cloud region
* Customer owns 100% of their data
* Independent edge deployments per region/site
* Perfect data residency — data never crosses jurisdictional boundaries

Business Impact:

* Complete control over sensitive data
* Simplified sovereign cloud compliance
* No vendor access to raw logs
* Clear audit trail (logs never moved)

***

### 98% Cost Reduction

The Hidden Cost of Traditional SIEMs:

* Cloud egress charges for moving logs out of AWS/Azure/GCP
* Network bandwidth costs for centralizing all log data
* Expensive vendor storage (Splunk: $1,800–$18,000/GB/year)
* Data transfer costs from branches to central location

BluSapphire's Cost Savings:

| Cost Category     | Traditional SIEM | BluSapphire Edge      | Savings    |
| ----------------- | ---------------- | --------------------- | ---------- |
| Cloud Egress      | $0.09/GB (AWS)   | $0 (logs stay in VPC) | **100%**   |
| Data Transfer     | Full log volume  | Metadata only         | **98%**    |
| Storage           | Vendor premium   | Customer's S3/blob    | **80-90%** |
| Network Bandwidth | Massive          | Minimal               | **95%**    |

Real-World Example:

* 1 TB/day of logs from AWS to Splunk SaaS
  * AWS egress: $0.09/GB × 1,000 GB × 30 days = **$2,700/month**
  * Splunk storage: $5/GB × 1,000 GB = **$5,000/month**
  * **Total: $7,700/month = $92,400/year**

With BluSapphire Detection at Edge:

* AWS egress: $0 (logs stay in S3)
* Storage: S3 standard $0.023/GB × 1,000 GB = **$23/month**
* Metadata transfer: \~20 GB × $0.09 = **$1.80/month**
* **Total: $25/month = $300/year**
* **Savings: $92,100/year (99.7%)**

***

### Compliance & Data Localization Made Simple

Traditional SIEM Compliance Challenges:

* GDPR: Data movement across borders creates compliance burden
* Sovereign cloud requirements: Conflicts with centralized architecture
* Industry regulations (HIPAA, PCI-DSS): Data must leave secure zones
* Cross-border data transfer: Required for centralized processing
* Audit complexity: Must track data movement and storage locations

BluSapphire's Compliance Advantages:

| Requirement           | Traditional SIEM                     | BluSapphire Edge                     |
| --------------------- | ------------------------------------ | ------------------------------------ |
| GDPR                  | Complex - data crosses borders       | Easy - EU data stays in EU           |
| Data Localization     | Difficult - centralization conflicts | Perfect - data stays in jurisdiction |
| Sovereign Cloud       | Not supported                        | Native support                       |
| HIPAA/PCI-DSS         | Complex - data leaves secure zone    | Simple - data never leaves           |
| Cross-Border Transfer | Required                             | Zero                                 |
| Audit Trail           | Complex - track movement             | Clear - logs never moved             |

Use Cases:

* Financial services: Keep transaction logs in regulated jurisdictions
* Healthcare: HIPAA-compliant — PHI never leaves secure network
* Government: Sovereign cloud requirements met natively
* EU operations: GDPR compliance simplified — data stays in EU
* Multi-national: Each country's data stays in-country

***

### Operational Complexity Eliminated

Traditional SIEM Operational Burden:

| Task                  | Traditional SIEM                        | BluSapphire Edge                         |
| --------------------- | --------------------------------------- | ---------------------------------------- |
| Log Forwarding        | Configure forwarders for every source   | Not needed - detection at edge           |
| Forwarder Management  | Heavy/universal forwarders, agents      | Zero - no forwarders                     |
| Network Configuration | Complex - all sources to central        | Simple - edge to console (metadata only) |
| Firewall Rules        | Extensive - all log sources             | Minimal - edge outbound only             |
| Troubleshooting       | Complex - forwarders, network, indexers | Simple - local edge processing           |

Benefits:

* Zero forwarder management overhead
* Minimal network configuration
* Simplified troubleshooting
* Reduced IT burden
* Faster deployment

***

### Future-Proof with Open Standards

The Vendor Lock-In Problem:

| Vendor      | Data Format                | Portability                 | Migration Risk | Lock-In     |
| ----------- | -------------------------- | --------------------------- | -------------- | ----------- |
| Splunk      | Proprietary                | Difficult, expensive export | High           | Severe      |
| QRadar      | Proprietary                | Difficult                   | High           | Severe      |
| Elastic     | Elasticsearch              | Moderate                    | Medium         | Moderate    |
| DNIF        | Proprietary                | Limited                     | High           | High (SaaS) |
| BluSapphire | **Open (Parquet/Iceberg)** | **Full, easy export**       | **Zero**       | **None**    |

BluSapphire's Open Data Advantage:

* Open standards: Parquet, Iceberg — industry-standard formats
* Vendor-neutral: Any analytics tool can read the data
* No migration ever needed: Data already in portable format
* Multi-vendor analytics: Use any tool (Athena, Spark, Tableau, etc.)
* Future-proof: Not dependent on BluSapphire's continued existence

Business Impact:

* Zero switching costs if you ever want to change vendors
* No data migration projects — data already accessible
* Leverage existing analytics tools and investments
* Negotiating power — not locked in

***

### Superior Performance & Resilience

Traditional SIEM Performance Bottlenecks:

| Scenario           | Traditional SIEM                      | BluSapphire Edge                  |
| ------------------ | ------------------------------------- | --------------------------------- |
| Detection Latency  | High - wait for log forwarding        | Lowest - detection at source      |
| Network Dependency | High - requires constant connectivity | Low - edge operates independently |
| Branch Office      | Poor - limited by WAN bandwidth       | Excellent - local detection       |
| Offline Operation  | No - forwarding stops                 | Yes - edge continues detection    |
| Scalability        | Vertical - scale central (expensive)  | Horizontal - add edge nodes       |

Resilience Benefits:

* Branch offices: Detection continues even if WAN is down
* Cloud regions: No cross-region dependencies
* Disaster recovery: Each edge operates autonomously
* Performance: No network latency for detection

***

## Use Case Enablement

### Multi-Cloud Strategy

Challenge: Aggregating logs from AWS, Azure, GCP to central SIEM

* High cross-cloud egress costs
* Network complexity
* Latency issues

BluSapphire Solution: Edge in each cloud

* Logs stay in native cloud
* Zero cross-cloud transfer
* Unified view in central console
* Savings: 98% reduction in cross-cloud costs

### Hybrid Cloud

Challenge: Bridging on-prem and cloud logs to central SIEM

* Complex network architecture
* VPN/ExpressRoute costs
* Security concerns

BluSapphire Solution: Edge in cloud + on-prem

* Seamless hybrid deployment
* No data movement required
* Unified threat detection
* Benefit: Simplified hybrid architecture

### Distributed Enterprises

Challenge: Aggregating logs from 100+ locations to central SIEM

* Massive bandwidth requirements
* Network bottlenecks
* High costs

BluSapphire Solution: Edge at each location

* Logs stay at each site
* No WAN bandwidth consumed
* Autonomous detection
* Savings: 95%+ bandwidth reduction

### Mergers & Acquisitions

Challenge: Integrating acquired company into central SIEM

* Months of integration work
* Data migration complexity
* Network integration

BluSapphire Solution: Deploy edge at acquired entity

* No integration required
* Data stays at acquired company
* Immediate unified visibility
* Benefit: Days vs. months for security coverage

### IoT/OT Security

Challenge: OT data must leave secure operational network for SIEM

* Security risk moving OT data
* Compliance violations
* Air-gap requirements broken

BluSapphire Solution: Edge at OT network

* OT data never leaves secure zone
* Detection at OT edge
* Air-gap maintained
* Benefit: OT security without compromising isolation

### Remote/Branch Offices

Challenge: Limited WAN bandwidth to send all logs to central SIEM

* Log loss during WAN outages
* Performance degradation
* High WAN costs

BluSapphire Solution: Edge at each branch

* Autonomous detection at branch
* No WAN dependency
* Continues during outages
* Benefit: Branch security without WAN constraints

***

## Competitive Comparison Summary

| Capability          | BluSapphire | Splunk        | QRadar        | Elastic          | DNIF            |
| ------------------- | ----------- | ------------- | ------------- | ---------------- | --------------- |
| Deploy at Edge      | ✅ Yes       | ❌ No          | ❌ No          | ❌ No             | ❌ No            |
| Logs Stay at Source | ✅ Yes       | ❌ No          | ❌ No          | ❌ No             | ❌ No            |
| Data Sovereignty    | ✅ Complete  | ❌ Shared      | ❌ Shared      | ❌ Shared         | ❌ Vendor-hosted |
| Cost Reduction      | ✅ 98%       | ❌ High costs  | ❌ High costs  | ⚠️ Medium        | ❌ Premium       |
| Open Data Format    | ✅ Yes       | ❌ Proprietary | ❌ Proprietary | ⚠️ Elasticsearch | ❌ Proprietary   |
| No Migration Ever   | ✅ Yes       | ❌ No          | ❌ No          | ❌ No             | ❌ No            |
| Offline Operation   | ✅ Yes       | ❌ No          | ❌ No          | ❌ No             | ❌ No            |
| Multi-Cloud Native  | ✅ Yes       | ⚠️ Complex    | ⚠️ Complex    | ⚠️ Complex       | ❌ No            |

***

## Key Differentiators

Why No Competitor Offers This

Technical Barriers:

1. Architecture: Competitors built on centralized indexing
2. Business model: SaaS vendors need data in their cloud
3. Storage: Proprietary formats require vendor infrastructure
4. Complexity: Distributed detection is harder than centralized

BluSapphire's Unique Approach:

1. Designed for edge from ground up
2. Open data lake architecture
3. Agentless detection works at edge
4. Cloud-native but customer-controlled

***

## ROI Calculation Example

Scenario: 10 TB/day enterprise with AWS + Azure + on-prem

Traditional SIEM (Splunk) Costs:

* Cloud egress: 10 TB × $0.09/GB × 30 days = $27,000/month
* Splunk storage: 10 TB × $5/GB = $50,000/month
* Network bandwidth: $10,000/month
* Total: **$87,000/month = $1,044,000/year**

BluSapphire Detection at Edge:

* Cloud egress: $0 (logs stay in cloud)
* Storage: S3/blob at $0.023/GB × 10 TB = $230/month
* Metadata transfer: 200 GB × $0.09 = $18/month
* Total: **$248/month = $2,976/year**

Annual Savings: **$1,041,024 (99.7%)**

***

## Strategic Advantages

For CISOs:

1. Cost control: Predictable, minimal data transfer costs
2. Compliance simplified: Data localization native
3. Risk reduction: Complete data sovereignty
4. Future-proof: Open standards, no lock-in
5. Negotiating power: Not dependent on vendor

For SOC Managers:

1. Faster detection: No network latency
2. Simplified operations: No forwarder management
3. Better resilience: Edge operates independently
4. Easier scaling: Add edge nodes vs. central infrastructure

For IT/Cloud Teams:

1. Lower cloud bills: 98% reduction in egress
2. Simpler architecture: No log aggregation complexity
3. Faster deployment: No complex network setup
4. Better performance: Local processing

For Compliance Teams:

1. Clear audit trail: Logs never moved
2. Data localization: Native support
3. Sovereign cloud: Perfect fit
4. Simplified reporting: Data location always known

***

## Conclusion

BluSapphire's Detection at Edge is a fundamental architectural advantage — not an incremental improvement. The combination of data sovereignty, 98% cost reduction, compliance simplification, operational efficiency, open standards, and superior performance addresses major enterprise pain points.

No other SIEM vendor offers:

* Detection at the edge where logs are generated
* Logs that never leave customer premises
* Open data formats with zero migration risk
* 98% reduction in data transfer costs
* Native support for sovereign cloud requirements

This is the future of SIEM architecture — and BluSapphire is delivering it today.


# Traditional SIEM vs SIEMless\_ A Technical and Financial Comparison

## Executive Summary

Choosing a security architecture is one of the most critical and long-term decisions a CISO can make. The traditional SIEM model, while familiar, is built on an outdated, centralized architecture that creates unsustainable costs, architectural rigidity, and slow, human-dependent response cycles. The SIEMless SIEM represents a paradigm shift, leveraging a distributed, AI-native architecture to deliver unprecedented speed, scalability, and cost-efficiency. This document provides a direct, quantitative comparison of the two architectures across key technical specifications and a detailed Total Cost of Ownership (TCO) analysis for a typical enterprise.

***

## Technical Specification Comparison

This table provides a detailed, feature-by-feature comparison between the architectural components and capabilities of a leading traditional SIEM and the SIEMless SIEM.

| Feature / Capability              | Traditional SIEM (e.g., Splunk, QRadar)                                                                                  | SIEMless SIEM (BluSapphire Architecture)                                                                                                |
| --------------------------------- | ------------------------------------------------------------------------------------------------------------------------ | --------------------------------------------------------------------------------------------------------------------------------------- |
| **Core Architecture**             | Monolithic, centralized. All raw logs must be ingested into a central data store for processing and analysis.            | Distributed, federated. Intelligence is pushed to the edge; only high-fidelity signals are sent to a lightweight core.                  |
| **Data Ingestion Model**          | Brute-force collection of all raw logs. "Collect everything, sort it out later."                                         | Intelligent, signal-based. Process at the source, filter 98%+ of noise, and move only enriched threat signals.                          |
| **Data Pipeline (ETL)**           | Static, manually configured log forwarders (e.g., Splunk UF, Logstash). Tightly coupled to SIEM vendor format.           | Dynamic, AI-managed pipeline (DataStreamer). Decoupled from analytics layer, enabling multi-destination routing in any format.          |
| **Scalability Model**             | Vertical and horizontal scaling of massive centralized infrastructure. Costs scale linearly (or worse) with data volume. | Horizontal, cloud-native scaling of lightweight edge nodes and a stateless core. Costs scale logarithmically with data volume.          |
| **Threat Detection Latency**      | High (15-60+ minutes). Dependent on data ingestion, indexing, and batched correlation rule execution.                    | Ultra-low (seconds). Real-time analysis at the edge, as data is generated.                                                              |
| **Mean Time to Respond (MTTR)**   | Hours to Days. Entirely dependent on human analyst availability, triage queues, and manual investigation.                | **< 2 Minutes.** Fully autonomous response cycle from detection to remediation, driven by agentic AI (AR²).                             |
| **Signal-to-Noise Ratio**         | Extremely low. Generates thousands of low-fidelity alerts, with false positive rates often exceeding 95%.                | Extremely high. Generates a small number of high-confidence, context-rich security events.                                              |
| **Data Sovereignty (e.g., GDPR)** | Challenging. Requires complex and expensive deployments to keep data within jurisdictional boundaries.                   | Compliant by Design. Federated edge processing ensures raw data never leaves its source jurisdiction.                                   |
| **Infrastructure Footprint**      | Massive. Requires extensive server clusters, high-performance storage, and dedicated infrastructure teams.               | Minimal. 98% reduction in central storage and compute. Lightweight edge nodes with low overhead.                                        |
| **Vendor Lock-In**                | Extreme. Migrating SIEMs is a 12-24 month project requiring re-instrumentation of all data sources.                      | Zero. The DataStreamer pipeline is vendor-agnostic. Switching analytics platforms is a simple routing change.                           |
| **AI Implementation**             | "AI-assisted." AI/ML features are bolted onto the core architecture to help analysts sort through alerts faster.         | **AI-Native.** The entire architecture is built around agentic AI for parsing, detection, pipeline management, and autonomous response. |

***

## 3-Year TCO Analysis: Typical Enterprise (10,000 Employees)

This analysis provides a conservative estimate of the 3-year Total Cost of Ownership for deploying and managing a traditional SIEM versus the SIEMless SIEM architecture. Assumes a data ingestion rate of 2TB/day.

| Cost Component                         | Traditional SIEM (3-Year TCO) | SIEMless SIEM (3-Year TCO) | Notes                                                                       |
| -------------------------------------- | ----------------------------- | -------------------------- | --------------------------------------------------------------------------- |
| **1. Software & Licensing**            |                               |                            |                                                                             |
| SIEM Platform License                  | $4,500,000 ($1.5M/yr)         | $0 (Included in platform)  | Based on typical enterprise pricing for 2TB/day ingest.                     |
| Log Management / ETL Tool              | $900,000 ($300k/yr)           | $0 (DataStreamer included) | Cost for a separate log pipeline tool like Cribl.                           |
| SOAR Platform License                  | $750,000 ($250k/yr)           | $0 (AR² included)          | Cost for a separate SOAR tool for automation.                               |
| **Subtotal (Software)**                | **$6,150,000**                | **$0**                     |                                                                             |
|                                        |                               |                            |                                                                             |
| **2. Infrastructure Costs**            |                               |                            |                                                                             |
| On-Prem/Cloud Infrastructure           | $1,800,000 ($600k/yr)         | $180,000 ($60k/yr)         | For servers, storage, and network. SIEMless requires \~90% less infra.      |
| Data Egress/Transfer                   | $600,000 ($200k/yr)           | $12,000 ($4k/yr)           | Assumes 98% data reduction at the edge, avoiding cloud egress fees.         |
| **Subtotal (Infrastructure)**          | **$2,400,000**                | **$192,000**               |                                                                             |
|                                        |                               |                            |                                                                             |
| **3. Personnel & Operational Costs**   |                               |                            |                                                                             |
| SOC Analyst Team (15 FTEs)             | $6,750,000 ($2.25M/yr)        | $2,250,000 (5 FTEs)        | Assumes a 3-shift SOC. SIEMless requires a smaller, more strategic team.    |
| Infrastructure/SIEM Engineers (4 FTEs) | $2,400,000 ($800k/yr)         | $600,000 (1 FTE)           | Fewer engineers needed to manage the autonomous, simplified infrastructure. |
| **Subtotal (Personnel)**               | **$9,150,000**                | **$2,850,000**             |                                                                             |
|                                        |                               |                            |                                                                             |
| **Total 3-Year TCO**                   | **$17,700,000**               | **$3,042,000**             |                                                                             |
| **Annualized TCO**                     | **$5,900,000**                | **$1,014,000**             |                                                                             |

***

{% hint style="success" %}

### Financial Conclusion: An 83% Reduction in TCO

The financial implications of this architectural shift are staggering. By adopting the SIEMless SIEM model, a typical enterprise can achieve an **83% reduction in the total cost of ownership** over three years. The savings are driven by:

* **Elimination of Per-Ingest Licensing:** The largest single cost component of traditional SIEMs is removed entirely.
* **Radical Infrastructure Reduction:** By processing data at the edge and not storing raw logs centrally, infrastructure costs are reduced by over 90%.
* **SOC Team Optimization:** The move from a human-dependent triage model to an autonomous response model allows for a smaller, more strategic, and higher-impact security team.

The SIEMless SIEM transforms security operations from a burdensome cost center into a highly efficient, strategic asset. The ROI is not incremental; it is transformative, freeing up millions in budget that can be reinvested into proactive security initiatives.
{% endhint %}

For a personalized TCO analysis for your organization, contact BluSapphire at [www.blusapphire.com](http://www.blusapphire.com)


# The SIEMless SIEM\_ A Technical Deep Dive for Architects and Engineers

## Abstract

The traditional Security Information and Event Management (SIEM) model, built on centralized log collection and manual human analysis, is architecturally and economically unsustainable. It is collapsing under the weight of exponential data growth, overwhelming alert fatigue, and the sheer speed of modern cyber-attacks. This white paper provides a detailed technical exploration of a new architectural paradigm: the **SIEMless SIEM**. This revolutionary approach inverts the traditional model by distributing intelligence to the edge, processing data at the source, and leveraging agentic AI for autonomous response. We will dissect the three core layers of this architecture—**DataStreamer (Edge)**, **BluSapphire Platform (Core)**, and **AR² (Response)**—and provide technical specifications, implementation guidance, and a quantifiable analysis of its impact on security operations, demonstrating how it creates a truly autonomous, infinitely scalable, and future-proof security posture.

***

## 1. Introduction: The Inevitable Collapse of the Traditional SOC Model

For the past two decades, the architectural blueprint for security operations has been consistent: deploy agents to collect all logs, centralize them in a SIEM for analysis, generate alerts based on correlation rules, and assign those alerts to a tiered system of human analysts for triage and response. While effective in a previous era, this model is now fundamentally broken, failing on every critical technical and operational dimension.

* **Data Gravity & Cost:** The exponential growth of log data from cloud, SaaS, and IoT sources makes centralized collection prohibitively expensive. Data transfer (egress) costs, storage, and SIEM licensing based on ingest volume create an unsustainable economic model.
* **Architectural Brittleness & Vendor Lock-In:** The tight coupling of log forwarders to a specific SIEM vendor's format creates extreme architectural rigidity. Migrating to a new SIEM becomes a multi-year, multi-million-dollar project involving re-instrumenting thousands of endpoints, leading to profound vendor lock-in.
* **Latency & The Speed of Attack:** The inherent latency in collecting, indexing, and analyzing data centrally means that detection is always retrospective. With modern attacks unfolding in minutes, a response cycle measured in hours or days is an invitation for a catastrophic breach.
* **Signal-to-Noise Ratio Collapse:** As data volumes increase, the signal-to-noise ratio collapses. SIEMs, lacking sufficient context at the source, generate a deluge of low-fidelity alerts. This leads to alert fatigue, where analysts become desensitized and critical threats are inevitably missed.

> The traditional SIEM architecture is a bottleneck by design. It creates a human-dependent, reactive posture that cannot scale in cost, speed, or intelligence. A fundamentally new architecture is not just an improvement—it is a necessity.

***

## 2. The SIEMless SIEM: A New Architectural Paradigm

The SIEMless SIEM inverts the traditional model. Instead of centralizing raw data, it distributes intelligence and processing to the edge, sending only high-fidelity signals to a lightweight core for correlation and autonomous response. This creates a distributed, self-healing security fabric.

\ <br>

The architecture is composed of three distinct, integrated layers:

* **The Edge (DataStreamer):** Intelligent data acquisition, processing, and threat detection at the source.
* **The Core (BluSapphire Platform):** Lightweight, high-speed correlation of enriched threat signals.
* **The Response (AR²):** Autonomous, agentic AI-driven remediation and containment.

Let's explore the technical details of each layer.

***

## 3. Layer 1: The Edge - Intelligent Data Acquisition (DataStreamer)

DataStreamer is the foundational edge component, replacing traditional log forwarders (like FluentBit, Logstash) with an intelligent, AI-powered data pipeline manager. Its primary role is to process data where it is generated, filter out noise, enrich events with context, and perform initial threat detection **before** data is moved.

### 3.1. Architectural Differentiators

* **Agentic AI Core:** DataStreamer is not manually configured with static rules. AI agents dynamically learn data sources, recommend parsing schemas, and optimize data flows, removing the need for dedicated pipeline engineers.
* **Future-Proof Decoupling:** DataStreamer normalizes data at the source and can route to any destination in any format. This completely decouples the data collection infrastructure from the analytics layer (SIEM, data lake). Switching SIEMs becomes a simple routing change in DataStreamer, with **zero changes** to endpoint configurations.
* **Federated Processing for Data Sovereignty:** By processing data locally (in-country, in-cloud region), it ensures compliance with data residency regulations like GDPR, SEBI, and RBI by design. Only enriched, anonymized threat signals need to leave the jurisdictional boundary.

### 3.2. Deep Dive: Key Capabilities

| Capability                            | Technical Specification                                                                                                                                                                                         |
| ------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Extreme Ingestion Flexibility**     | Supports 200+ sources via agent-based and agentless methods (Syslog, API, GELF, Kafka, Kinesis, S3, Beats, Webhooks). Handles batch and real-time streams.                                                      |
| **AI-Driven Parsing & Normalization** | Agentic AI auto-generates parsers from log samples. Normalizes data to standard schemas (ECS, OCSF) or custom formats on the fly. Detects schema anomalies and adapts without re-indexing.                      |
| **Inline Threat Enrichment**          | Enriches events in-stream with GeoIP, multiple threat intelligence feeds, asset intelligence (from CMDBs), and user context. Performs auto-baselining of host, user, and process behavior.                      |
| **Multi-Destination Routing**         | Routes transformed data to multiple destinations simultaneously. A single source can feed a SIEM, a data lake for long-term storage, and a security analytics platform, each with its own format and filtering. |
| **Autonomous Pipeline Management**    | Auto-scales worker nodes based on volume and backpressure. Self-heals on pipeline or node failure, ensuring data continuity. AI agents recommend policy changes to optimize cost and performance.               |

### 3.3. Technical Specifications

* **Performance:** Horizontally scalable architecture capable of handling over 10 million events per second (EPS) with sub-millisecond transformation latency per pipeline.
* **Security:** End-to-end encryption with mTLS. Granular Role-Based Access Control (RBAC). Inline PII masking and tokenization. Full audit logs for all operations.
* **Platform:** Cloud-native, Kubernetes-based architecture. Can be deployed on-premises, in air-gapped environments, at the cloud edge, or consumed as a SaaS offering.

***

## 4. Layer 2: The Core - High-Fidelity Signal Correlation

The BluSapphire Platform serves as the lightweight, intelligent core. Unlike a traditional SIEM, its primary function is **not to store raw logs**. Instead, it ingests only the high-fidelity, context-enriched threat signals forwarded by the DataStreamer edge nodes.

* **Signal-Based vs. Log-Based Architecture:** A traditional SIEM ingests terabytes of raw logs to find a few dozen actionable alerts. The SIEMless Core ingests megabytes of threat signals to generate the same number of high-confidence events. This reduces infrastructure footprint and cost by over 98%.
* **Cross-Enterprise Correlation:** The Core correlates weak signals from disparate sources (e.g., a suspicious login from an endpoint, a firewall alert for the same IP, and a cloud config change) to identify a single, high-confidence attack campaign.
* **Behavioral Analytics:** With the noise filtered out, the Core can apply advanced User and Entity Behavior Analytics (UEBA) far more effectively, detecting subtle deviations that would be lost in the noise of a traditional SIEM.

***

## 5. Layer 3: The Response - Autonomous Remediation (AR²)

AR² (Autonomous Response & Remediation) is the agentic AI response layer that makes the architecture truly autonomous. It receives high-confidence events from the Core and executes multi-step remediation without human intervention.

* **Agentic AI for Decision Making:** AR² is not a simple SOAR playbook. It is a true agentic AI that uses a reasoning engine to analyze the event, query for additional context, consider potential business impact, and decide on the optimal course of action. For example, instead of just blocking an IP, it might decide to isolate the host, terminate the user session, and patch the associated vulnerability.
* **Sub-2-Minute Response Cycle:** The entire cycle from initial detection at the edge to final remediation by AR² is completed, on average, in **under two minutes**. This is faster than any human-driven process and contains threats before they can achieve their objectives.
* **The Human-in-the-Loop, Not in the Path:** Human analysts are not in the primary response path. They are moved to a strategic oversight role. AR² handles 95%+ of events autonomously, only escalating truly novel or ambiguous cases that require human ingenuity. The analyst's role shifts from reactive triage to proactive threat hunting, AI training, and policy refinement.

***

## 6. Implementation and Integration

### 6.1. Phased Deployment Strategy

A key advantage of this architecture is its non-disruptive, phased deployment model:

{% stepper %}
{% step %}

### Phase: Deploy DataStreamer

Install DataStreamer agents alongside your existing log forwarders. Configure DataStreamer to route data to your current SIEM. At this stage, you immediately gain pipeline management, enrichment, and cost-reduction benefits without changing your SOC workflow.
{% endstep %}

{% step %}

### Phase: Enable SIEM Decoupling

Once stable, re-route a subset of data from DataStreamer to a secondary destination (e.g., a data lake). This validates the multi-destination routing and begins the process of SIEM decoupling, proving the future-proof architecture.
{% endstep %}

{% step %}

### Phase: Activate the SIEMless Core & AR²

Begin sending high-fidelity signals from DataStreamer to the BluSapphire Platform and AR². Run this in parallel with your existing SIEM, allowing your team to build trust in the autonomous system by comparing outcomes.
{% endstep %}

{% step %}

### Phase: Decommission Legacy SIEM

Once the SIEMless architecture is proven, you can dramatically scale down or completely decommission your legacy SIEM, realizing massive cost savings and fully transitioning to an autonomous SOC model.
{% endstep %}
{% endstepper %}

### 6.2. The "Zero-Touch" SIEM Migration

For organizations suffering from SIEM vendor lock-in, the migration process is radically simplified:

* **Traditional Migration:** A 12-24 month project requiring a dedicated team to reconfigure thousands of log forwarders, rewrite parsers, and validate data streams. High risk of data loss and operational disruption.
* **SIEMless Migration:** A simple change in the DataStreamer routing configuration. The new SIEM is added as a destination, and data flows are switched over in minutes. The underlying collection infrastructure is **never touched**. The entire migration can be completed in hours with zero downtime.

***

## 7. Conclusion: The Autonomous SOC is Here

The SIEMless SIEM is not a theoretical concept; it is a production-ready architecture that delivers transformative results. By inverting the traditional security model, it addresses the core failures of the last two decades of security operations.

For security architects and engineers, this new paradigm offers a path to build a system that is:

* **Technically Elegant:** A distributed, signal-based architecture is inherently more efficient and scalable than a centralized, brute-force model.
* **Economically Sustainable:** Costs scale logarithmically with the business, not exponentially with data volume.
* **Operationally Superior:** It frees your most valuable resource—your human analysts—from reactive toil and empowers them to focus on strategic defense.

Building the future of security does not mean buying a bigger, faster SIEM. It means adopting a new architecture that is intelligent, autonomous, and infinitely scalable. The future is SIEMless.

***

To receive a live technical demonstration of the SIEMless SIEM architecture, contact BluSapphire at [www.blusapphire.com](http://www.blusapphire.com)


# 07\_BluSapphire User Interface Login Guide

SOP for BluSapphire Interface Login

Table of Contents

1\. Login page

2\. Setup Multi-Factor Authentication (MFA)

3\. Access Oneplatform

## **1. Login page:**

* Go to [**https://oneplatform-global.blusapphire.com**](https://oneplatform-global.blusapphire.com/) from browser and log in using the email address.

![](https://content.gitbook.com/content/-MMRHZBPHlLDUc8519fX/blobs/hXu6QBdLQYCarrVmdXe1/Unknown%20image)

* A 6-digit verification code will be sent to the given email address, please enter the code to verify.

![](https://content.gitbook.com/content/-MMRHZBPHlLDUc8519fX/blobs/kJpU7FXaYoTKISWSSCak/Unknown%20image)

## **2. Setup Multi-Factor Authentication (MFA):**

* After successful login, register for Multi-Factor Authentication (MFA) by downloading an authenticator app on your mobile device (such as Google Authenticator).
* Open the app, select a work or school account and scan the QR code provided on the screen, and enter the six-digit code generated by the authenticator app.

![](https://content.gitbook.com/content/-MMRHZBPHlLDUc8519fX/blobs/87u1Hqv1cNfZ8G9kloje/Unknown%20image)

* Click **"Assign MFA"** to complete the MFA setup.

## **3. Access Oneplatform :**

On Successful login, platform home page will be visible as shown below:

![A screenshot of a computer Description automatically generated](https://content.gitbook.com/content/-MMRHZBPHlLDUc8519fX/blobs/yf3M8aptMra6OowDatUx/Unknown%20image)


# Proof-Of-Concept / Pilot Guide

The page is intended as a follow along guide to the self-service PoC site.


# M-SOC | Self Service Portal

This section will describe the Self Service Portal, Data Pipeline Manager and log forwarder installs where needed.

1. [Registering as a Customer](/m-soc/m-soc-or-self-service-portal/registering-as-a-customer-regulated-entity)
2. [Agreement Sign in Process](/m-soc/m-soc-or-self-service-portal/digital-contract-signing-process)
3. [Billing Information](/m-soc/m-soc-or-self-service-portal/updating-billing-information)
4. [Escalation Matrix](/m-soc/m-soc-or-self-service-portal/updating-escalation-matrix)
5. [Users & Roles](/m-soc/m-soc-or-self-service-portal/manage-users-and-roles)
6. [Windows Package Installation](/m-soc/m-soc-or-log-collection-and-forwarding-guide/windows-package-installation)
7. [Linux Package Installation](/m-soc/m-soc-or-log-collection-and-forwarding-guide/linux-package-installation)
8. [RPM Package Installation](/m-soc/m-soc-or-log-collection-and-forwarding-guide/rpm-package-installation)&#x20;
9. [Data Pipeline Manager Installation](/older-releases/11_data-pipeline-manager-dpm) - (for advanced users only)
10. [Frequently Asked Questions (FAQs) ](/m-soc/m-soc-or-frequently-asked-questions-faq)


# Registering as a Customer (Regulated Entity)

Customers or REs will receive an email with the Reference Code or RE can directly login to **<https://console.blusapphire.com>** without the Reference Code.&#x20;

1. **To Register:**&#x20;

* Go to **<https://console.blusapphire.com>** from browser and log in using the email address.&#x20;

<figure><img src="https://2078222076-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MMRHZBPHlLDUc8519fX%2Fuploads%2FEnS8KvsM0fCtKQSEARhw%2Fimage.png?alt=media&amp;token=a4186cb9-bd63-4a35-be93-941b640cffe2" alt=""><figcaption></figcaption></figure>

* A verification code will be sent to the given email address, which they must enter to verify. &#x20;

<figure><img src="https://2078222076-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MMRHZBPHlLDUc8519fX%2Fuploads%2FdvDTC2CJtNTwupDQAMgq%2Fimage.png?alt=media&amp;token=26417234-5c2a-434c-9907-5047e180b3fe" alt=""><figcaption></figcaption></figure>

* On the next page, they will be prompted to register their organization by entering:&#x20;

  **Organization Name**&#x20;

  **Organization URL**&#x20;

  **Reference Code** (*Provide the Reference Code provided by your M-SOC/Service Provider*)&#x20;
* If the customer does not have the reference code, they can check the box for **“I don't have a reference code”** and still proceed by creating the organization.&#x20;
* After completing the registration form, click **"Create Organization"** to finalize the registration.&#x20;

<figure><img src="https://2078222076-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MMRHZBPHlLDUc8519fX%2Fuploads%2FBBWltl1wGs8rKH4zjsIQ%2Fimage.png?alt=media&amp;token=0c1ba791-562e-45f6-9e76-22ca00fb9f9d" alt=""><figcaption></figcaption></figure>

2. **Setup Multi-Factor Authentication (MFA):** &#x20;

* After successful login, register for Multi-Factor Authentication (MFA) by downloading an authenticator app on your mobile device (such as Google Authenticator).&#x20;
* Open the app, select a work or school account and scan the QR code provided on the screen, and enter the six-digit code generated by the authenticator app.&#x20;
* Click **"Assign MFA"** to complete the MFA setup. &#x20;

<figure><img src="https://2078222076-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MMRHZBPHlLDUc8519fX%2Fuploads%2FovbW0iRW1XsNYxXLJWZd%2Fimage.png?alt=media&amp;token=a69e7184-37f9-4cc6-9d38-4e4246d45f7c" alt=""><figcaption></figcaption></figure>

3. **Agree to End User License Agreement:** &#x20;

* On the next page, review and agree to the **End User License Agreement (EULA)** to proceed.&#x20;

  <figure><img src="https://2078222076-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MMRHZBPHlLDUc8519fX%2Fuploads%2FOWPXpf8gljIzQsUiPmxI%2Fimage.png?alt=media&amp;token=cfa4f8b1-c87d-49a2-a966-2350639270ee" alt=""><figcaption></figcaption></figure>

4. **Customer Console Main Page:** &#x20;

* After completing the MFA setup and EULA agreement, the Customer/RE will be directed to the main dashboard of the console.&#x20;
* Customers will have the ability to **Download agent packages** tailored to their organization’s endpoints.

<figure><img src="https://2078222076-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MMRHZBPHlLDUc8519fX%2Fuploads%2FPAgYL6y3vXGr97eMPsaT%2Fimage.png?alt=media&amp;token=8bebea0e-b49b-4541-80ee-5692669b9af9" alt=""><figcaption></figcaption></figure>

{% embed url="<https://youtu.be/pN9-FVZjt0c>" %}


# Digital Contract Signing Process

Step-by-Step Guide to Signing the Document

**Step 1: Access the Agreement**

1. **Log in to the portal** **<https://console.blusapphire.com>** where the agreements are available for signing.
2. You will see a notification at the top of the screen indicating that an BluSapphire Client Agreement has not been signed yet or you can **Navigate to the "Agreements" section** to locate the document you need to sign.

<figure><img src="https://2078222076-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MMRHZBPHlLDUc8519fX%2Fuploads%2FXJjJF9tQQBzsVPascTYi%2Fimage.png?alt=media&amp;token=bcf20b5d-e3a9-42f7-8a62-18e69e5f75e1" alt=""><figcaption></figcaption></figure>

<figure><img src="https://2078222076-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MMRHZBPHlLDUc8519fX%2Fuploads%2FicSEyOvaWUM1xS8cbaI1%2Fimage.png?alt=media&amp;token=545a5d86-a4b0-421a-a9ce-079adc12de1d" alt=""><figcaption></figcaption></figure>

**Step 2: Initiate the Signing Process**

1. **Click on the "Signature" option** next to the document.
   * A notification will pop up indicating the document needs to be signed.
2. **Confirm Authorization**:

   * If you are the authorized person to sign, **click on "I am authorized to sign the Agreement."**
   * Alternatively, if you're not the authorized person, **click on the option to forward the agreement to the appropriate person via email**.

   <figure><img src="https://2078222076-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MMRHZBPHlLDUc8519fX%2Fuploads%2FXIbSKsq491aGOSLlnZ6D%2Fimage.png?alt=media&amp;token=88723293-3f97-4647-adb0-9b272cb4e8f8" alt=""><figcaption></figcaption></figure>

**Step 3: Receive the Email Notification**

1. After confirming you are authorized to sign, **you will receive an email notification** with instructions to proceed with signing. Also, you will see a notification at the top of the page to check your email for BluSapphire Client Agreement review and sign the document.

<figure><img src="https://2078222076-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MMRHZBPHlLDUc8519fX%2Fuploads%2FCpP6Ok6KJW5tvvP7ui5g%2Fimage.png?alt=media&amp;token=8ac6ffea-9d3e-466c-8612-75a0af4b3f74" alt=""><figcaption></figcaption></figure>

2. **Go to your email inbox** and find the message with the subject “Sign the Agreement”.
3. **Click on "Start Signing"** from the email to begin the signing process.

<figure><img src="https://2078222076-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MMRHZBPHlLDUc8519fX%2Fuploads%2F4fV6tfr6neCkPCHVwskR%2Fimage.png?alt=media&amp;token=d03963b1-1bfc-43d8-9aa3-c51d09066e08" alt=""><figcaption></figcaption></figure>

**Step 4: Proceed to the Document**

1. After clicking "Start Signing," the **Document Info page will load**.
2. Additional access restrictions have been applied to the document. To proceed, click on the "Send OTP" button. You will receive a One-Time Password (OTP) will be sent to your registered email address

<figure><img src="https://2078222076-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MMRHZBPHlLDUc8519fX%2Fuploads%2Fb1IsoKQXvTaNIXCjJHwy%2Fimage.png?alt=media&amp;token=66c31dbb-a270-4f9b-8ed8-a402028ecc2a" alt=""><figcaption></figcaption></figure>

3. **Click on "Proceed to Document"** to begin reviewing and signing the agreement.

<figure><img src="https://2078222076-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MMRHZBPHlLDUc8519fX%2Fuploads%2FSWLYV6gKpPdaW30ikDLE%2Fimage.png?alt=media&amp;token=5ca3b9ac-6df2-47df-b3d0-36711b4dbb09" alt=""><figcaption></figcaption></figure>

**Step 5: Agree and Continue**

1. **Read through the agreement carefully**.
2. Once you have reviewed the document, **check the tick box** that states "Agree and Continue" to proceed with signing.

<figure><img src="https://2078222076-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MMRHZBPHlLDUc8519fX%2Fuploads%2Fyujf1f4K9ShvBowxIxtr%2Fimage.png?alt=media&amp;token=ddaa0976-903d-44f0-945a-23bc76516835" alt=""><figcaption></figcaption></figure>

**Step 6: Fill in Your Information**

1. At the bottom of the document, you will need to fill in the following details:

* **Client Name**
* **Client Address**
* **Your Name**
* **Job Title**

<figure><img src="https://2078222076-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MMRHZBPHlLDUc8519fX%2Fuploads%2Fxj9RZfBtssSF4hcdsAOh%2Fimage.png?alt=media&amp;token=e358804b-2d6b-403b-b6d3-b6edf12b9de9" alt=""><figcaption></figcaption></figure>

**Step 7: Sign the Document**

1. **Click on "Signature"** at the designated section in the document.
   * Various signature font styles will appear.
2. **Select your preferred signature style** and click “OK” to confirm your selection.

<figure><img src="https://2078222076-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MMRHZBPHlLDUc8519fX%2Fuploads%2FaX9Em5vEVGMGJXr1SpYT%2Fimage.png?alt=media&amp;token=f72814ba-f921-4b56-af94-c1712c272cff" alt=""><figcaption></figcaption></figure>

**Step 8: Complete the Signing Process**

1. Once you’ve chosen your signature, the document will be considered signed.
2. **You can now download, email, or print the signed document** for your records.

<figure><img src="https://2078222076-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MMRHZBPHlLDUc8519fX%2Fuploads%2FvCEVx9IIUoyC9abedvIv%2Fimage.png?alt=media&amp;token=5b5d940f-bac0-4321-8e2c-b9b863bc6bea" alt=""><figcaption></figcaption></figure>

3. You can also download the **Signed Documents** from the Agreement Tab.

<figure><img src="https://2078222076-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MMRHZBPHlLDUc8519fX%2Fuploads%2FB6jOeD9nATzvLvFloc9o%2Fimage.png?alt=media&amp;token=7441d8b4-256d-44cd-a0ca-8cc1ecf9fc90" alt=""><figcaption></figcaption></figure>

4. Provide a name for the document, apply a relevant tag, select the desired save location, and then click "Save" to finalize.

<figure><img src="https://2078222076-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MMRHZBPHlLDUc8519fX%2Fuploads%2FTD3Qlrao5r2jw5bJ2dSN%2Fimage.png?alt=media&amp;token=2cbeba03-748f-4e4b-85bf-568f8b13f9f8" alt=""><figcaption></figcaption></figure>

{% embed url="<https://youtu.be/iKQOZ1F68v4>" %}


# Updating Billing Information

Step-by-Step Guide to Updating Billing Information

**Step 1: Access the Billing Form**&#x20;

1. Log in to the portal <https://console.blusapphire.com> where your billing information is available.&#x20;
2. Navigate to the "Billing" section to locate the billing form.&#x20;

**Step 2: Fill in Required Details**&#x20;

1. Enter the following information into the billing form:&#x20;
2. Legal Entity Name: Enter the official name of your legal entity.&#x20;
3. Address: Fill in the complete address for your entity.&#x20;
4. TAX ID Type: Select the type of Tax ID (e.g., Federal, VAT, etc.) from the available options.&#x20;
5. TAX ID Number: Enter the specific Tax ID number associated with your entity. &#x20;

<figure><img src="https://2078222076-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MMRHZBPHlLDUc8519fX%2Fuploads%2FyWtO49BL2VfNl9lLf59v%2Fimage.png?alt=media&amp;token=396cdfdb-99cb-4368-96fb-9a98a9c34267" alt=""><figcaption></figcaption></figure>

**Step 3: Review the Information**&#x20;

1. Double-check all the information to ensure its accuracy.&#x20;
2. Ensure that the legal entity name, address, tax ID type, and tax ID number are correct.&#x20;

**Step 4: Update Billing**&#x20;

1. Once the details are correctly filled in, click on "Update Billing" to save the changes to your billing information.&#x20;

&#x20;

{% embed url="<https://youtu.be/bPO8C2KiJyk>" %}


# Updating Escalation Matrix

**Step 1: Access the Escalation Matrix**

1. **Log in to the portal** <https://console.blusapphire.com> where the escalation matrix configuration is available.
2. **Navigate to the "Escalation Matrix" section** to begin the configuration process.

**Step 2: Configure Escalation Levels**

1. **Level 1: Enter the Contact Information**
   * **Email Address**: Enter the email address of the contact person for Level 1 escalation.
   * **Phone Number**: Enter the phone number of the contact person for Level 1 escalation.
2. **Level 2: Enter the Contact Information for the Superior**
   * **Email Address**: Enter the email address of the superior to Level 1 for escalation to Level 2.
   * **Phone Number**: Enter the phone number of the superior to Level 1 for escalation to Level 2.
3. **Level 3: Enter the Top Escalation Contact Information**

   * **Email Address**: Enter the email address of the top escalation member (Level 3).
   * **Phone Number**: Enter the phone number of the top escalation member (Level 3).

   <figure><img src="https://2078222076-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MMRHZBPHlLDUc8519fX%2Fuploads%2FwX0FYi00CL1T2SFFUwFx%2Fimage.png?alt=media&amp;token=276a06b0-b294-4758-94c4-43a2c09a2251" alt=""><figcaption></figcaption></figure>

**Step 3: Review the Escalation Matrix**

1. **Double-check the information** for all three levels to ensure that the correct contact details are entered for each escalation level.

**Step 4: Save the Escalation Matrix**

1. Once the information is correctly entered for each level, **click on "Update Escalation Matrix"** to save the configuration.

{% embed url="<https://youtu.be/Gr1GHdl_09Y>" %}


# Manage Users and Roles

Step-by-Step Guide to Create a User and Assign a Role

**Step 1: Access the User and Roles Section**

1. **Log in to the portal** **<https://console.blusapphire.com>** where user management is available.
2. **Navigate to the "**&#x55;ser and Roles" section to begin the user creation process.
3. Click on Create User from the top right corner.

<figure><img src="https://2078222076-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MMRHZBPHlLDUc8519fX%2Fuploads%2F3F5a4cTfkDGssKRRwtgC%2Fimage.png?alt=media&amp;token=36fadf99-b54a-4303-848f-78a77be7ccd3" alt=""><figcaption></figcaption></figure>

**Step 2: Fill in the User Details**

1. **Email Address**:
   * Enter the **email address** of the user you wish to create. This will be used to identify the user and send notifications.
2. **Assign the User Role**:
   * **Role**: Choose the appropriate **role** for the user:

     * **Client Analyst**: If the user should have access to the partner’s services with limited permissions.
     * **Client Admin**: If the user should have administrative privileges to manage services and configurations.

     <figure><img src="https://2078222076-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MMRHZBPHlLDUc8519fX%2Fuploads%2F0MsW0jAXDkswuJc8136c%2Fimage.png?alt=media&amp;token=0fe06010-6a46-4a66-bb38-d779bcdfee1e" alt=""><figcaption></figcaption></figure>

**Step 3: Review the User Information**

1. **Double-check** that the email address is correct, and the selected role corresponds to the level of access the user requires.

**Step 4: Save and Assign the Role**

1. After entering the details, **click on "Create User"** to assign the user role and save the information.

<figure><img src="https://2078222076-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MMRHZBPHlLDUc8519fX%2Fuploads%2FbCdb9MS1PfZc43wiV5NV%2Fimage.png?alt=media&amp;token=ef5337db-4a46-43cc-9943-217924b5e2f3" alt=""><figcaption></figcaption></figure>

{% embed url="<https://youtu.be/JWAZjhAQrWE>" %}


# RACI Matrix

Description of the RACI matrix in Annexure D

The **RACI (Responsible, Accountable, Consulted, and Informed) matrix** defines the roles and responsibilities between a **Managed Security Services Provider (MSSP)** and a **Regulated Entity (RE)** in a security operations context.

#### **Understanding RACI Roles:**

* **R (Responsible):** The entity that performs the task.
* **A (Accountable):** The entity that is ultimately answerable for the task and ensures it is completed.
* **C (Consulted):** The entity that provides input, expertise, or recommendations before the task is completed.
* **I (Informed):** The entity that receives updates on task progress or outcomes.

<table data-header-hidden><thead><tr><th width="89"></th><th width="504"></th><th width="88"></th><th></th></tr></thead><tbody><tr><td><strong>Sl.No</strong></td><td><strong>Capabilities / Activities</strong></td><td><strong>MSSP</strong></td><td><strong>RE</strong></td></tr><tr><td>1</td><td>Service Delivery / Metrics/ SLA Review &#x26; Reporting</td><td>R,A</td><td>A</td></tr><tr><td>2</td><td>Adherence to SLA</td><td>R, A</td><td>R,A</td></tr><tr><td>3</td><td>Provide a List of Log sources to be integrated with MSOC/EDR </td><td>C,I</td><td>R, A</td></tr><tr><td>4</td><td>Log Baselining sharing </td><td>R,A</td><td>C, I</td></tr><tr><td>5</td><td>HLD document with details of the security solutions currently in place</td><td>C,I</td><td>R, A</td></tr><tr><td>6</td><td>Technical issues and Troubleshooting of MSOC</td><td>R,A</td><td>I</td></tr><tr><td>7</td><td>Implementation and management of SIEM/Ticketing Tool</td><td>R, A</td><td>I</td></tr><tr><td>8</td><td>Storage and hardware required for log retention (6 Months online &#x26; 18 Months offline)</td><td>R, A</td><td>R, A</td></tr><tr><td>9</td><td>Role Matrix and Escalation Matrix</td><td>R, A</td><td>R, A</td></tr><tr><td>10</td><td>Deploy necessary cybersecurity solutions as applicable to the RE environment as per SOW</td><td>C,I</td><td>R, A</td></tr><tr><td>11</td><td>Log Baseline implementation</td><td>C,I</td><td>R,A</td></tr><tr><td>12</td><td>Configuration Management, VAPT, Patch Management. </td><td>C,I</td><td>R, A</td></tr><tr><td>13</td><td>SIEM/EDR Platform Administration</td><td>R, A</td><td>C, I</td></tr><tr><td>14</td><td>Use Cases - Content Creation/Review/Modification</td><td>R, A</td><td>C, I</td></tr><tr><td>15</td><td>24x7 SOC Monitoring &#x26; Alert Analysis</td><td>R, A</td><td>C, I</td></tr><tr><td>16</td><td>Incident Detection</td><td>R, A</td><td>C, I</td></tr><tr><td>17</td><td>Incident severity &#x26; priority assignment</td><td>R, A</td><td>C, I</td></tr><tr><td>18</td><td>Incident Notification</td><td>R, A</td><td>C, I</td></tr><tr><td>19</td><td>Incident Escalation</td><td>R, A</td><td>C, I</td></tr><tr><td>20</td><td>Incident response/investigation</td><td>C, I</td><td>R, A</td></tr><tr><td>21</td><td>Incident Resolution</td><td>C, I</td><td>R, A</td></tr><tr><td>22</td><td>Forensics (If applicable)</td><td>C, I</td><td>R, A</td></tr><tr><td>23</td><td>Root Cause Analysis</td><td>C, I</td><td>R, A</td></tr><tr><td>24</td><td>Incident Review and Closure</td><td>A, C</td><td>R</td></tr><tr><td>25</td><td>Recovery of impacted Device/System/Process</td><td>C, I</td><td>R, A</td></tr><tr><td>26</td><td>Restoration from Archival/Backup</td><td>C, I</td><td>R, A</td></tr></tbody></table>

***

#### **Detailed Explanation of Each Capability/Activity in the RACI Matrix:**

1. **Service Delivery / Metrics/ SLA Review & Reporting**
   * **MSSP (R, A):** The MSSP is responsible and accountable for preparing reports, tracking SLA adherence, and presenting service metrics.
   * **RE (A):** The RE acknowledges and acts based on these reports.
2. **Adherence to SLA**
   * **MSSP (R, A):** Ensures SLAs are met in service delivery.
   * **RE (R, A):** Ensures SLAs are adhered to from their end (e.g., timely approvals, responses).
3. **Provide a List of Log Sources to be Integrated with MSOC/EDR**
   * **MSSP (C, I):** Consulted for recommendations and informed about updates.
   * **RE (R, A):** Responsible and accountable for providing the list.
4. **Log Baselining Sharing**
   * **MSSP (R, A):** Responsible and accountable for providing baseline logs.
   * **RE (C, I):** Consulted to confirm if the shared baselines align with their security needs and informed about changes.
5. **HLD Document with Security Solutions Details**
   * **MSSP (C, I):** Consulted for feedback and informed about security design.
   * **RE (R, A):** Responsible for providing a High-Level Design (HLD) document listing security solutions in place.
6. **Technical Issues and Troubleshooting of MSOC**
   * **MSSP (R, A):** Responsible for addressing SOC-related technical issues.
   * **RE (I):** Informed about technical troubleshooting progress.
7. **Implementation and Management of SIEM/Ticketing Tool**
   * **MSSP (R, A):** Responsible for configuring and managing SIEM/ticketing tools.
   * **RE (I):** Informed about the implementation and management.
8. **Storage and Hardware for Log Retention (6 Months Online & 18 Months Offline)**
   * **MSSP (R, A):** Responsible for ensuring proper storage and retention policies.
   * **RE (R, A):** Responsible for providing necessary storage and managing compliance.
9. **Role Matrix and Escalation Matrix**
   * **MSSP (R, A):** Responsible for defining escalation procedures.
   * **RE (R, A):** Ensures the escalation framework aligns with organizational processes.
10. **Deploy Cybersecurity Solutions as per SOW**

* **MSSP (C, I):** Consulted to ensure best practices in deployment.
* **RE (R, A):** Responsible for deploying and maintaining security tools.

11. **Log Baseline Implementation**

* **MSSP (C, I):** Provides recommendations.
* **RE (R, A):** Implements and maintains log baselines.

12. **Configuration Management, VAPT, Patch Management**

* **MSSP (C, I):** Consulted for security configurations and informed about vulnerabilities.
* **RE (R, A):** Responsible for applying updates, patches, and security configurations.

13. **SIEM/EDR Platform Administration**

* **MSSP (R, A):** Responsible for SIEM/EDR administration.
* **RE (C, I):** Consulted on policies and informed about major changes.

14. **Use Cases – Content Creation/Review/Modification**

* **MSSP (R, A):** Develops and refines SIEM/EDR use cases.
* **RE (C, I):** Consulted for specific requirements and informed about updates.

15. **24x7 SOC Monitoring & Alert Analysis**

* **MSSP (R, A):** Monitors security logs and analyzes alerts continuously.
* **RE (C, I):** Consulted on critical alerts and informed about security trends.

16. **Incident Detection**

* **MSSP (R, A):** Responsible for identifying security incidents.
* **RE (C, I):** Consulted on detection parameters and informed about incidents.

17. **Incident Severity & Priority Assignment**

* **MSSP (R, A):** Assigns severity and prioritization of incidents.
* **RE (C, I):** Consulted to validate criticality and informed about assigned severity.

18. **Incident Notification**

* **MSSP (R, A):** Notifies relevant stakeholders about incidents.
* **RE (C, I):** Consulted on escalation needs and informed about ongoing incidents.

19. **Incident Escalation**

* **MSSP (R, A):** Ensures incidents are escalated as per protocol.
* **RE (C, I):** Consulted on escalations and informed about incident progress.

20. **Incident Response/Investigation**

* **MSSP (C, I):** Consulted to assist in response activities.
* **RE (R, A):** Responsible for managing and executing incident response.

21. **Incident Resolution**

* **MSSP (C, I):** Assists in remediation strategies.
* **RE (R, A):** Ensures incidents are fully remediated.

22. **Forensics (If Applicable)**

* **MSSP (C, I):** Provides forensic expertise if required.
* **RE (R, A):** Conducts forensic investigation where necessary.

23. **Root Cause Analysis (RCA)**

* **MSSP (C, I):** Consulted for insights into root causes.
* **RE (R, A):** Responsible for conducting RCA and implementing corrective actions.

24. **Incident Review and Closure**

* **MSSP (A, C):** Accountable for documentation and consulted for closure verification.
* **RE (R):** Final decision-maker for incident closure.

25. **Recovery of Impacted Device/System/Process**

* **MSSP (C, I):** Provides guidance on recovery strategies.
* **RE (R, A):** Ensures systems are restored.

26. **Restoration from Archival/Backup**

* **MSSP (C, I):** Consulted for guidance.
* **RE (R, A):** Responsible for restoring data from backups.

***

#### **Key Takeaways:**

1. **MSSP’s Primary Responsibilities:**
   * SOC operations, including monitoring, alert analysis, and incident detection.
   * SIEM/EDR administration, use case management, and SLA reporting.
   * Supporting the RE in investigations, forensics, and incident response.
2. **RE’s Primary Responsibilities:**
   * Security governance and compliance with internal/external policies.
   * Deployment of security solutions, log baseline implementation, and patch management.
   * Leading the incident response and resolution process.
3. **Shared Responsibilities:**
   * SLA adherence, log retention, escalation matrices, and incident handling.

This RACI matrix ensures clear accountability between the **MSSP** and the **RE**, promoting **efficient SOC operations, compliance, and faster incident response**.


# Incident Management Workflow(M-SOC only)

This page describes the Incident Management Workflow followed by M-SOC as validated by SEBI and the exchange.

<figure><img src="https://2078222076-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MMRHZBPHlLDUc8519fX%2Fuploads%2Fz9ap06oq3VUjIvl5EQ98%2FAlert_Workflow.png?alt=media&amp;token=53bb8c60-5dab-48ce-a12b-577b9a484880" alt=""><figcaption></figcaption></figure>

**Incident SLA**\
**(**&#x54;he timeframe within which the RE will be notified of the incident, based on its assigned priority level.**)**&#x20;

<figure><img src="https://2078222076-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MMRHZBPHlLDUc8519fX%2Fuploads%2FCZx8xBdUzKYAs31h7uzj%2Fimage.png?alt=media&amp;token=fd1b1f17-bdc2-4ebb-877e-6b25269cfd0f" alt=""><figcaption></figcaption></figure>


# Asset Reconciliation

## Asset Reconciliation

1. Login to [https://console.blusapphire.com](https://console.blusapphire.com/) with provided credentials.
2. Go to the 'Documents' page as shown below.

<img src="https://2078222076-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MMRHZBPHlLDUc8519fX%2Fuploads%2FOfJm2iGbTugIt92r3bEi%2Ff1e34a63%209417%204a4d%20804f%205f641e6074db.png?alt=media" alt="" data-size="original">

3. Click on the 'Upload Document' button located in the top-left corner of the interface

![](https://2078222076-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MMRHZBPHlLDUc8519fX%2Fuploads%2FTP1OOEntazJ9uk9CFKmV%2Fe161f9c0%204950%204782%208394%2099058b32ed9e.png?alt=media)

4\. Select 'Inventory' as the Document Type

![](https://2078222076-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MMRHZBPHlLDUc8519fX%2Fuploads%2F03yKF9sKWhLYytu2US5x%2F4c611555%207757%204450%209bad%20cfbf244c0a5c.png?alt=media)

## Process for updating the list of assets

1. Upload new document as shown below

   ```
    a) Enter the Document Name

    b) Enter the Document Description 

    c) Click on the choose file button under upload file

    d) Upload the file containing the updated list of assets
   ```

![](https://2078222076-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MMRHZBPHlLDUc8519fX%2Fuploads%2FALYoT9VbDZrXK69ItvBF%2Fe4340d1a%208bb0%204b33%209f72%20c71aa9f04283.png?alt=media)

<pre><code><strong>2. Once the above steps are completed, press the upload button on the bottom-right hand corner
</strong></code></pre>

![](https://2078222076-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MMRHZBPHlLDUc8519fX%2Fuploads%2FSal9JfLkPCy8fuU9Z1Ni%2F07e2128f%2089d8%2044f0%20a15f%20e8b4c59f6212.png?alt=media)

3. The updated list will be stored in the Documents section as seen below

![](https://2078222076-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MMRHZBPHlLDUc8519fX%2Fuploads%2FF8010N7xKB6CaYVCm9R4%2F21c3dd7f%20cd10%204b6f%20850a%20253b54d3faca.png?alt=media)

## Process for keeping the same inventory list

1. Click on the checkbox next to 'I don't have any changes'

![](https://2078222076-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MMRHZBPHlLDUc8519fX%2Fuploads%2FMCC4ZQjQ9TcMsBpmvLfs%2Fa7f72d4f%2080bb%2049e9%20be43%20a8b1526dbfca.png?alt=media)

2. Press the upload button on the bottom-right hand corner

![](https://2078222076-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MMRHZBPHlLDUc8519fX%2Fuploads%2FeDy3nmGM2UhByDecWLA0%2F8352e68f%209715%2042ed%20825e%209865db345240.png?alt=media)

3. The list will be stored in the Documents section as seen below

![](https://2078222076-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MMRHZBPHlLDUc8519fX%2Fuploads%2FUkMo97bRC5Y3WigZ4EkJ%2Fe09d80a9%200eac%2048d7%208255%20bd8beba51219.png?alt=media)

##


# M-SOC | Architecture & Workflow


# Solution Deployment Architecture

High Level Design – Solution Deployment Architecture

## Overview

This document provides a high-level overview of the deployment architecture scenarios for the MSOC Solution. These architectures outline how security monitoring and incident response capabilities are integrated based on the organization's infrastructure landscape.

## Scenario 1: No On-Prem Infrastructure (Endpoints Only)

### Description

In this scenario, the organization (RE) does not maintain any on-premises infrastructure beyond endpoints such as desktops and laptops. These endpoints may also be remote, requiring secure connectivity to the MSOC solution.

### Key Components

1. **Endpoints**: Workstations and laptops used by employees.
2. **Encrypted Channel**: Secure communication between endpoints and MSOC.
3. **Multi-Factor Authentication (MFA)**: Ensures secure access to the MSOC.
4. **24x7 Cybersecurity Monitoring**: Continuous security oversight.
5. **MSOC (Managed Security Operations Center)**:

* Next-Gen SIEM (Security Information and Event Management)
* SOAR (Optional Service)
* Threat Intelligence
* Machine Learning and Analytics
* Encrypted Storage for log retention

6. **Auditor Access**: Restricted access for compliance reviews.

### Workflow

1. Endpoints generate security logs and telemetry.
2. Logs are securely transmitted to the MSOC via an encrypted channel.
3. The MSOC performs real-time monitoring, correlation, and analysis.
4. Security teams respond to incidents by leveraging automated SOAR workflows if SOAR is opted for as a service.
5. Security auditors can access the monitoring platform with controlled permissions.

![](https://content.gitbook.com/content/-MMRHZBPHlLDUc8519fX/blobs/Gy1VNKtGqPLl6DAn7XqJ/Unknown%20image)

## Scenario 2: On-Prem Infrastructure and/or Cloud Infrastructure

### Description

In this scenario, the organization has both endpoints and additional infrastructure, such as on-premises servers or cloud-hosted services. This requires a more complex security architecture.

### Key Components

1. **Endpoints**: Workstations and laptops.
2. **Application Servers and Infrastructure**: On-premises and cloud resources.
3. **Log Collector**: Aggregates logs from endpoints and infrastructure.
4. **Encrypted Channel**: Secure log transmission to the MSOC.
5. **Firewall**: Enforces network security and data protection.
6. **Multi-Factor Authentication (MFA)**: Ensures secure access.
7. **24x7 Cybersecurity Monitoring**: Provides continuous security analysis.
8. **MSOC**:

* Next-Gen SIEM
* SOAR (Optional Service)
* Threat Intelligence
* Machine Learning and Analytics
* Encrypted Storage

9. **SOAR Integration (Optional)**: Enhances automated incident response capabilities.
10. **Auditor Access**: Controlled access for compliance and oversight.

### Workflow

1. Logs are collected from endpoints, application servers, and other infrastructure components.
2. The log collector aggregates and normalizes logs before transmission.
3. Data is encrypted during transit and sent to the MSOC.
4. The MSOC processes logs using SIEM, SOAR, and analytics.
5. Security teams investigate threats and execute automated response actions if SOAR is opted for as a service.
6. Compliance teams and auditors access logs securely for review.

![](https://content.gitbook.com/content/-MMRHZBPHlLDUc8519fX/blobs/W4kmzTYpW8SUo0x4m4FH/Unknown%20image)

## Comparison of Deployment Scenarios\*\* -\*\*

| **Feature**                           | **Scenario 1 (Endpoints Only)**            | **Scenario 2 (On-Prem & Cloud)**                            |
| ------------------------------------- | ------------------------------------------ | ----------------------------------------------------------- |
| Infrastructure                        | No on-prem infrastructure beyond endpoints | Includes on-prem servers, applications, and cloud resources |
| Log Collection                        | Directly from endpoints                    | Centralized log collection via log aggregators              |
| Security Monitoring                   | SIEM processes endpoint logs               | SIEM ingests data from endpoints, servers, and applications |
| Automated Response (SOAR – Optional ) | SOAR handles endpoint-related incidents    | SOAR handles incidents across all assets                    |
| Compliance & Auditing                 | Limited to endpoint security               | Comprehensive infrastructure security review                |

## Conclusion

Both deployment architectures provide robust security monitoring and threat detection. The choice between Scenario 1 and Scenario 2 depends on the organization’s infrastructure. Scenario 1 is suitable for remote or cloud-first environments, while Scenario 2 is ideal for enterprises with on-premises or hybrid setups. In both cases, the MSOC ensures continuous security operations, incident response, and compliance adherence.


# Incident Response Workflow

## Incident Response Workflow

### Standard Operating Procedure (SOP)

## 1. Purpose

This document outlines the incident response process for alerts received from the **Next-Gen SIEM**, detailing the responsibilities of **M-SOC, RE (Regulated Entity), and Exchange** at each stage of incident handling.

## 2. Scope

This SOP applies to all security alerts/Incidents triggered in the **Next-Gen SIEM**, ensuring timely detection, notification, and remediation of security incidents.

## 3. Roles & Responsibilities

* **M-SOC**: Responsible for triaging, confirming incidents, and tracking resolution.
* **RE (Regulated Entity)**: Takes necessary actions, submits the Root Cause Analysis (RCA), and remediate/resolve the incident.
* **Exchange**: Facilitates communications with external regulatory bodies (e.g., CERT-IN, NCIIPC, SEBI) as required.

## 4. Incident Handling Procedure

{% stepper %}
{% step %}

### Alert Reception

* **M-SOC** receives an alert from **Next-Gen SIEM** and assesses its severity:
  * **Critical**
  * **High**
  * **Medium**
  * **Low**
    {% endstep %}

{% step %}

### Incident Classification and Notification

#### Critical Incident

1. **M-SOC** triage and confirms the alert as a **Critical Incident**.
2. **M-SOC** notifies the **RE SPOC (Single Point of Contact)**.
3. **M-SOC** sends a notification to **Exchange**.
4. **RE** informs **CERT-IN/NCIIPC/SEBI** (if required as per impact).
5. **M-SOC** tracks incident status.

#### High Incident

1. **M-SOC** triage and confirms the alert as a **High Incident**.
2. **M-SOC** notifies the **RE SPOC**.
3. **M-SOC** sends a notification to **Exchange**.
4. **M-SOC** tracks incident status.

#### Medium Incident

1. **M-SOC** triage and confirms the alert as a **Medium Incident**.
2. **M-SOC** notifies the **RE SPOC**.
3. **M-SOC** tracks incident status.

#### Low Incident

1. **M-SOC** triage and confirms the alert as a **Low Incident**.
2. **M-SOC** notifies the **RE SPOC**.
3. **M-SOC** tracks incident status.
   {% endstep %}

{% step %}

### Incident Resolution

* **RE** takes action to mitigate and remediate the incident.
* **RE** submits the **Root Cause Analysis (RCA)** to both **Exchange and M-SOC** (for Critical and High Incidents).
* **For Medium & Low Incidents**, **RE** updates M-SOC on the resolution status.
  {% endstep %}

{% step %}

### Validation and Closure

* **M-SOC** validates the resolution provided by **RE**.
* **M-SOC** closes the incident upon successful resolution verification.
* **End of Process**.
  {% endstep %}
  {% endstepper %}

**Incident Workflow** and **Defined SLA’s** are detailed in [Annexure A](https://app.gitbook.com/o/RP5QC3ULbyB3uRyWKTb8/s/-MMRHZBPHlLDUc8519fX/~/edit/~/changes/316/m-soc/m-soc-or-architecture-and-workflow/incident-response-workflow#annexure-a)

## 5. Compliance and Reporting

* **M-SOC** must ensure that all incidents are tracked and documented.
* **RE** must report critical incidents to regulatory authorities as required.
* **RE** must provide an RCA for every incident to improve future security posture.

## 6. Escalation Matrix

* If an incident is not addressed within the defined SLA, **MSOC** escalates it to the higher-level stakeholders within **RE and Exchange**.
* For unresolved or repeated security incidents, **Exchange** and **MSOC** must collaborate on further mitigation strategies.

{% hint style="info" %}
**Note** – Response and mitigation must be performed by the **RE**. BluSapphire is responsible only for sharing recommendations. The BluSapphire team will provide guidance to the RE via Microsoft Teams if any assistance is required. BluSapphire **does not support or engage** in remote access to the RE's environment using remote administration tools such as AnyDesk, TeamViewer, etc.
{% endhint %}

### Annexure A

Incident Workflow:

<figure><img src="https://2078222076-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MMRHZBPHlLDUc8519fX%2Fuploads%2FmXuTxJUWCex7NybExTTf%2Fimage.png?alt=media&amp;token=85ba78f5-13a5-4a1c-ac08-398a78cf2f7c" alt=""><figcaption></figcaption></figure>

#### Classification of cybersecurity incidents

<table><thead><tr><th width="145.08203125">Classification</th><th width="111.5859375">Level</th><th>Details</th></tr></thead><tbody><tr><td><strong>Low</strong></td><td>1</td><td>- System probes or scans detected on external systems<br>- Intelligence received concerning threats to which systems may be vulnerable<br>- Intelligence received regarding username<br>-password compromise- Isolated instances of known malware easily handled by antivirus software</td></tr><tr><td><strong>Medium</strong></td><td>2</td><td>- Target recon or scans detected<br>- Penetration or Denial of Service attacks attempted with no impact on operations<br>- Widespread instances of known malware easily handled by antivirus software<br>- Isolated instances of new malware not handled by antivirus software- Instances of phishing emails clicked by employees<br>- Instances of data corruption, modification, and deletion being reported</td></tr><tr><td><strong>High</strong></td><td>3</td><td>- Penetration or Denial of Service attacks attempted with limited impact on operations - Widespread instances of new malware not handled by antivirus software - Unauthorized access to servers and network devices- Unauthorized or unexpected configuration changes on network devices detected- Impersonation of SEBI officials in emails- Data exfiltration - High volume of phishing emails- Outbound phishing emails- Some risk of negative financial or PR impact</td></tr><tr><td><strong>Critical</strong></td><td>4</td><td>- Successful penetration or Denial of Service attacks with significant impact on operations- Ransomware attack - Exfiltration of market-sensitive data- Widespread data corruption impacting operations - Significant risk of negative financial or PR impact</td></tr></tbody></table>

#### Classification of incident SLA’s:

<table data-header-hidden><thead><tr><th width="105.65625"></th><th width="196.140625"></th><th></th></tr></thead><tbody><tr><td><strong>S.No.</strong></td><td><strong>KPI</strong></td><td><strong>SLA Timelines</strong></td></tr><tr><td>1</td><td>Time to Detect</td><td>> 4 Min</td></tr><tr><td>2</td><td>Time to Respond</td><td>Critical – 30 Mins</td></tr><tr><td></td><td></td><td>High – 60 Mins</td></tr><tr><td></td><td></td><td>Medium – 90 Mins</td></tr><tr><td></td><td></td><td>Low – 120 Mins</td></tr><tr><td>3</td><td>Time to Resolution</td><td>Critical – 2 Hours</td></tr><tr><td></td><td></td><td>High – 4 Hours</td></tr><tr><td></td><td></td><td>Medium – 2 Business days</td></tr><tr><td></td><td></td><td>Low – 5 Business days</td></tr></tbody></table>


# M-SOC | Log Collection & Forwarding Guide


# Default Log Collection

This page describes the default logs available for collection:

By default the following logs can be readily collected by M-SOC. Other log types are also available for collection. Please review the [Log Collection](/log-forwarding/03_log-forwarding-guide) section for complete list. More log types are added on a weekly basis. If in doubt, please email <support@blusapphire.com> for latest information.

<figure><img src="https://2078222076-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MMRHZBPHlLDUc8519fX%2Fuploads%2FuFWit8JiKHlNyPWpVxgI%2Fimage.png?alt=media&amp;token=9c21c615-b82f-43b0-ab81-bd0fd58ef0ec" alt=""><figcaption></figcaption></figure>


# Linux Package Installation

Installing on Debian-based Linux Systems (e.g., Ubuntu)

### Supported Systems

The deployment package supports **Debian-based Linux distributions** with the following requirements:

**System Requirements:**&#x20;

* **GLIBC Version:** Must be **2.28 or greater**

#### How to Check GLIBC Version

Run the following command in your terminal to verify the GLIBC version:

```bash
ldd --version
```

If the output shows a version below 2.28, you will need to update GLIBC or upgrade your system.

### Installation Steps

#### Follow these steps to install the BluLogShipper package on Debian-based systems:

1\. Log in to the portal and download the BluLogShipper Linux package (`blulogshipper_debian.zip`).

<figure><img src="https://2078222076-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MMRHZBPHlLDUc8519fX%2Fuploads%2F9I5luSa0ujlHCyIflllP%2Fimage.png?alt=media&amp;token=1baab7e9-e699-4070-9c0f-e32c3037a2da" alt=""><figcaption></figcaption></figure>

2\. **Launch a Terminal** and navigate to the directory where the package was downloaded.&#x20;

Example: &#x20;

```bash
cd /path/to/downloads
```

<figure><img src="https://2078222076-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MMRHZBPHlLDUc8519fX%2Fuploads%2FCT0VgBnyXYbNB4fduh69%2Fimage.png?alt=media&amp;token=b7236cd5-aa4e-45b6-90a2-3e58c7d99ddf" alt=""><figcaption></figcaption></figure>

3. Extract the contents of the downloaded `.zip` file using the `unzip` command:

```bash
unzip *_linux_deb.zip  
```

<figure><img src="https://2078222076-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MMRHZBPHlLDUc8519fX%2Fuploads%2F3i2l02nfCVsydrOvC6ro%2Fimage.png?alt=media&amp;token=7ec04b24-292d-4647-a0f6-ee510758b562" alt=""><figcaption></figcaption></figure>

If `unzip` command is not available, install using the command `sudo apt install unzip`

4\. Navigate to the extracted directory, use `chmod +x` command to make a file executable&#x20;

```bash
chmod +x install.sh
```

<figure><img src="https://2078222076-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MMRHZBPHlLDUc8519fX%2Fuploads%2FpJ5SVjODW1mkdfDunWNM%2Fimage.png?alt=media&amp;token=172daa76-3d56-46f7-b07a-a00d281141c2" alt=""><figcaption></figcaption></figure>

5. Execute the installation script with superuser privileges to install the package:

```bash
sudo ./install.sh    
```

<figure><img src="https://2078222076-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MMRHZBPHlLDUc8519fX%2Fuploads%2FL9A85ROCCMkXmgGZZTRe%2Fimage.png?alt=media&amp;token=207c97b0-d9a7-4463-a8dc-4a3807e9411b" alt=""><figcaption></figcaption></figure>

6. Verify the Installation

To ensure the package is installed correctly, verify that the service is running:

```bash
sudo systemctl status blulogshipper.service
```

<figure><img src="https://2078222076-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MMRHZBPHlLDUc8519fX%2Fuploads%2F17au8I619VaEqEohOC91%2Fimage.png?alt=media&amp;token=2345737d-0209-4671-8d2a-78c059ec2a30" alt=""><figcaption></figcaption></figure>

If the service is not active, you may start it using:

```bash
sudo systemctl start blulogshipper.service
```

{% embed url="<https://youtu.be/h9qbEhrZQts>" %}


# MACOS Package Installation

Installation of MACOS

### Installation Steps

Follow these steps to install the MACOS package:

1. **Download the Package**
   * Visit the portal <https://console.blusapphire.com> and download the **MACOS** package.

<figure><img src="https://2078222076-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MMRHZBPHlLDUc8519fX%2Fuploads%2FtQd1M50tSIX9VSusjKCw%2Fimage.png?alt=media&amp;token=fe9a88b7-3d76-44a6-aa19-5a1e9876b19f" alt=""><figcaption></figcaption></figure>

2. **Extract the Package**

* Locate the downloaded file and move it to the C:/ Folder.
* Right click on the Folder and click on "New Terminal Tab at Folder".
* It will navigate to the Terminal.

<figure><img src="https://2078222076-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MMRHZBPHlLDUc8519fX%2Fuploads%2FJj1x7VhEoAp10Bz5c1I3%2Fimage.png?alt=media&amp;token=3927b15e-e484-470f-908d-8e734b1c60e3" alt="" width="375"><figcaption><p>Package Folder</p></figcaption></figure>

<figure><img src="https://2078222076-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MMRHZBPHlLDUc8519fX%2Fuploads%2F7bTYaTSlXmyvfvYhrAVl%2Fimage.png?alt=media&amp;token=a7ae7adc-791e-4b4c-82d0-fd77dd8fcf60" alt="" width="563"><figcaption><p>Terminal login page</p></figcaption></figure>

3. **Execute the Command**

* In the terminal, run the following command:

  ```
  chmod +x ./install.sh
  ```

<figure><img src="https://2078222076-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MMRHZBPHlLDUc8519fX%2Fuploads%2FdSy0mm0W1Mr7BpytmiHT%2Fimage.png?alt=media&amp;token=4e9fb142-ca2e-4029-98a6-01b013a2a3a0" alt="" width="563"><figcaption><p>User Add</p></figcaption></figure>

4. **Execute the Installation Command**

* In the terminal, run the following command:

  ```
  sudo ./install.sh
  ```

&#x20;     Enter the System Password (password will not visible, just type in and press enter)

* **Note**: You will need `sudo` access to execute this command. Make sure you have the necessary permissions.

<figure><img src="https://2078222076-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MMRHZBPHlLDUc8519fX%2Fuploads%2FVLbYQw05ZvhkvZNhgBh1%2Fimage.png?alt=media&amp;token=6fdeab26-4e2e-4579-952e-192a0ced9ef9" alt="" width="375"><figcaption><p>Package Installation </p></figcaption></figure>

5. **Verify the Installation**

* After installation is complete, verify that the installation was successful by running the following command:

  ```
  $ sudo launchctl list | grep com.blusapphire
  ```

<figure><img src="https://2078222076-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MMRHZBPHlLDUc8519fX%2Fuploads%2FK5P9CxqOuOWPEwALqo0v%2Fimage.png?alt=media&amp;token=f9519170-ba43-4cff-86b8-52f456609417" alt="" width="375"><figcaption><p>Services Runing Status</p></figcaption></figure>


# OneAgent Windows Package Installation

Installing on Windows

## Installation Steps

Follow these steps to install the OneAgent package on Windows systems:

1. **Download the Package**

   * Visit the portal <https://console.blusapphire.com> and download the OneAgent Windows Installation package.

   <figure><img src="https://2078222076-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MMRHZBPHlLDUc8519fX%2Fuploads%2FXprzsLTdsSn6edUiDsdS%2Fimage.png?alt=media&amp;token=9a12d544-f9ad-4229-a3ab-0533d9d7e0c3" alt=""><figcaption></figcaption></figure>
2. **Extract the Package**

* Locate the downloaded file(oneagent\_installer.zip) and extract its contents to the desired location on your system.

<figure><img src="https://2078222076-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MMRHZBPHlLDUc8519fX%2Fuploads%2FZG1u07vgtX3cEFNAg0GT%2FScreenshot%20(54).png?alt=media&amp;token=2bd78a05-ff9e-4559-9bb2-1621a768320f" alt="" width="563"><figcaption></figcaption></figure>

<figure><img src="https://2078222076-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MMRHZBPHlLDUc8519fX%2Fuploads%2FdAhk7Govth7hEwcXg9PO%2FScreenshot%20(55).png?alt=media&amp;token=d3e63000-a303-4f27-bfc8-ae6ef51c9058" alt="" width="563"><figcaption></figcaption></figure>

* Open the extracted folder.

<figure><img src="https://2078222076-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MMRHZBPHlLDUc8519fX%2Fuploads%2FjCksNpS711KJlwF7NQ36%2Fimage.png?alt=media&amp;token=29185fcb-a58c-49e0-80f1-2bc7a8aa3a89" alt="" width="563"><figcaption></figcaption></figure>

3. **Run the Installer**

* Double-click OneAgent\_Installer.exe to start the installation process.
* Microsoft Defender SmartScreen may prompt below window. Click on **More info**.

<figure><img src="https://2078222076-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MMRHZBPHlLDUc8519fX%2Fuploads%2F2pGLDU42ugIU27AmX9TB%2FScreenshot%20(56).png?alt=media&amp;token=46613be2-0ed8-4222-a94a-4aaa0505d7cd" alt="" width="563"><figcaption></figcaption></figure>

* Click on **Run anyway** button.

<figure><img src="https://2078222076-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MMRHZBPHlLDUc8519fX%2Fuploads%2F5YnIgYZtmJUd1tU9ylzH%2FScreenshot%20(57).png?alt=media&amp;token=de38864c-39cf-4c69-aa21-bce72a0d8b4f" alt="" width="563"><figcaption></figcaption></figure>

* When the installation window appears, click **Install**.

<figure><img src="https://2078222076-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MMRHZBPHlLDUc8519fX%2Fuploads%2FFGymNnfdQLaYXnw7a70U%2Fimage.png?alt=media&amp;token=585c75d6-ce51-4ceb-a248-67a72aaa91bb" alt="" width="563"><figcaption></figcaption></figure>

* If any issues occur, an error dialog box will appear at this stage.

<div align="center"><figure><img src="https://2078222076-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MMRHZBPHlLDUc8519fX%2Fuploads%2FuvSWK6O7PtFLAFi4V6js%2FScreenshot%20(42).png?alt=media&amp;token=aa08b3af-342a-4323-9e09-ce46bf6d6fda" alt="" width="563"><figcaption></figcaption></figure></div>

* Once the installation is complete, click Finish to exit the installer.

<div align="center"><figure><img src="https://2078222076-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MMRHZBPHlLDUc8519fX%2Fuploads%2Fxxr2oMfDx5JYAtxWPfFM%2FScreenshot%20(43).png?alt=media&amp;token=5d7090b1-628f-44a5-97a6-341b4767aaf6" alt="" width="563"><figcaption></figcaption></figure></div>

4. &#x20;**Verify the Installation**

* Open Services Manager by pressing  `Win + R`, typing **services.msc**, and pressing Enter.

<div align="center"><figure><img src="https://2078222076-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MMRHZBPHlLDUc8519fX%2Fuploads%2FydnE5ufRpGhGt7RXuTZ5%2FScreenshot%20(46).png?alt=media&amp;token=35afddc3-dd6f-4375-9030-eb93fc0d5d85" alt="" width="560"><figcaption></figcaption></figure></div>

* In the Services list, confirm that the following services are running:
  * OneAgent Service
  * OneAgent Support Service

<div align="center"><figure><img src="https://2078222076-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MMRHZBPHlLDUc8519fX%2Fuploads%2FplKszgYudxZS0ctXP7WJ%2FScreenshot%20(47).png?alt=media&amp;token=4e7ac05f-b865-4ba2-9808-e6080951218a" alt="" width="563"><figcaption></figcaption></figure></div>

## Uninstallation Steps

* Press  `Win + R` , type **control**, and press **Enter** to open the **Control Panel.**

<div align="center"><figure><img src="https://2078222076-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MMRHZBPHlLDUc8519fX%2Fuploads%2FnOwCdKKdBY6XQOLJ8uJX%2FScreenshot%20(48).png?alt=media&amp;token=9430baf3-4260-489d-a332-3422440daa76" alt="" width="563"><figcaption></figcaption></figure></div>

* Under **Programs** category, click on **uninstall a program**

<div align="center"><figure><img src="https://2078222076-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MMRHZBPHlLDUc8519fX%2Fuploads%2F52ZDBNhzAKAcfharH7Bq%2FScreenshot%20(49).png?alt=media&amp;token=83425379-bdae-42a2-8a96-5e63f3d53988" alt="" width="563"><figcaption></figcaption></figure></div>

* Locate OneAgent in the list of installed programs.
* Select it and click Uninstall.

<div align="center"><figure><img src="https://2078222076-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MMRHZBPHlLDUc8519fX%2Fuploads%2FzZFgHxQu1FRwAMBkPSW0%2FScreenshot%20(50).png?alt=media&amp;token=6853d8b9-a2d8-47b9-b2f4-3e17aad1d63e" alt="" width="563"><figcaption></figcaption></figure></div>


# RPM Package Installation

Installing on RPM-based Linux Systems (e.g., CentOS, RHEL, Fedora)

### Supported Systems

The deployment package supports **RPM-based Linux distributions** with the following requirements:

**System Requirements:**&#x20;

* **GLIBC Version:** Must be **2.28 or greater**

#### How to Check GLIBC Version

Run the following command in your terminal to verify the GLIBC version:

```bash
ldd --version
```

If the output shows a version below 2.28, you will need to update GLIBC or upgrade your system.

### Installation Steps

#### Follow these steps to install the BluLogShipper package on RPM-based systems:

1\. Log in to the portal and download the BluLogShipper RPM package (`blulogshipper_rpm.zip`)

<figure><img src="https://2078222076-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MMRHZBPHlLDUc8519fX%2Fuploads%2FmdNSL1Bo1Ytk92eodLrh%2Fimage.png?alt=media&amp;token=4bfc500a-7448-42fa-817c-1d736c8aa4aa" alt=""><figcaption></figcaption></figure>

2. **Launch a Terminal** and navigate to the directory where the package was downloaded. Example:

```bash
cd /path/to/downloads
```

<figure><img src="https://2078222076-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MMRHZBPHlLDUc8519fX%2Fuploads%2FfQka4sEzWC1t8ZCOBBpl%2Fimage.png?alt=media&amp;token=defbe499-5294-42a6-9a13-53599fedb3c8" alt=""><figcaption></figcaption></figure>

3. Extract the contents of the downloaded `.zip` file using the `unzip` command:

```bash
unzip *_linux_rpm.zip
```

<figure><img src="https://2078222076-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MMRHZBPHlLDUc8519fX%2Fuploads%2Fox0ytuDaSUL2Bi8Uf8mx%2Fimage.png?alt=media&amp;token=6a218837-65e0-4000-891d-4f8a887febd1" alt=""><figcaption></figcaption></figure>

If `unzip` command is not available, install using the command `sudo yum install unzip`

4\. Navigate to the extracted directory, use `chmod +x` command to make a file executable&#x20;

```bash
chmod +x install.sh
```

<figure><img src="https://2078222076-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MMRHZBPHlLDUc8519fX%2Fuploads%2F058j8WOMNc4a6GacrLlo%2Fimage.png?alt=media&amp;token=25869391-9518-4d88-9cfa-6e740269269a" alt=""><figcaption></figcaption></figure>

5. Execute the installation script with superuser privileges to install the package:

```bash
sudo ./install.sh
```

<figure><img src="https://2078222076-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MMRHZBPHlLDUc8519fX%2Fuploads%2FBEM82r9PXeC7m3FYpt9W%2Fimage.png?alt=media&amp;token=68fe7e19-8ebb-4f84-8a77-6e7d4c933b61" alt=""><figcaption></figcaption></figure>

6. Verify the Installation

To ensure the package is installed correctly, verify that the service is running:

```bash
sudo systemctl status blulogshipper.service
```

<figure><img src="https://2078222076-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MMRHZBPHlLDUc8519fX%2Fuploads%2FGJCjj9ILnEe0jGfj4yGO%2Fimage.png?alt=media&amp;token=11fac4fa-bcd8-4424-b09b-41107eb7cfa8" alt=""><figcaption></figcaption></figure>

If the service is not active, you may start it using:

```bash
sudo systemctl start blulogshipper.service
```

{% embed url="<https://youtu.be/LUxyBf0oPV8>" %}


# Windows Package Installation

Installing on Windows

### Installation Steps

Follow these steps to install the BluLogShipper package on Windows systems:

1. **Download the Package**

   * Visit the portal <https://console.blusapphire.com> and download the BluLogShipper Windows package.
   *

   ```
   <figure><img src="/files/Xs10jT2n5ObowxNbYL6L" alt=""><figcaption></figcaption></figure>
   ```
2. **Extract the Package**

   * Locate the downloaded file and extract its contents to the desired location on your system.
   * Copy the Folder path.

   <figure><img src="https://2078222076-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MMRHZBPHlLDUc8519fX%2Fuploads%2FUDyTbOyh3ZE9qE6eIsuy%2Fimage.png?alt=media&amp;token=f91ccd73-391f-49b8-af90-1da0905091ac" alt=""><figcaption></figcaption></figure>

   <figure><img src="https://2078222076-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MMRHZBPHlLDUc8519fX%2Fuploads%2F6b9yH8Uiwsn3URRkhZvx%2Fimage.png?alt=media&amp;token=20632474-7161-4328-97d6-cc752a9c137d" alt=""><figcaption></figcaption></figure>
3. **Open Command Prompt**
   * Open **Command Prompt** with administrative privileges:

     * Click the **Start** menu, type `cmd`, and right-click **Command Prompt**.
     * Select **Run as Administrator**.

     <figure><img src="https://2078222076-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MMRHZBPHlLDUc8519fX%2Fuploads%2FR1iBBMHAN666UrNKPDuM%2Fimage.png?alt=media&amp;token=0b906bd5-54a2-4f3d-99f8-b22a6fa86a57" alt=""><figcaption></figcaption></figure>
4. **Navigate to the Package Directory**

   * Use the `cd` command in Command Prompt to navigate to the directory where the package was extracted, and press enter. &#x20;
   * Example:  cd C:\path\to\extracted\package (paste the folder path we have copied earlier)

   <figure><img src="https://2078222076-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MMRHZBPHlLDUc8519fX%2Fuploads%2FeMhfooHT1LlV7uiFVvxH%2Fimage.png?alt=media&amp;token=d0283b04-de68-4bb5-925f-284194c38579" alt=""><figcaption></figcaption></figure>
5. **Run the Installer Script**

* Execute the batch script with administrative privileges and press enter
* <pre><code><strong>install.bat
  </strong></code></pre>

<figure><img src="https://2078222076-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MMRHZBPHlLDUc8519fX%2Fuploads%2FFkHnZC6bDsfjbxqPDi9z%2Fimage.png?alt=media&amp;token=4fc97322-e72a-48fe-92a5-9acb044b734e" alt=""><figcaption></figcaption></figure>

6. **Agent Setup:**&#x20;

* Read the BluSapphire Log Shipping Agent License Agreement, Tick the Checkbox and click on Install.
*

```
<figure><img src="/files/qdj9PYuYXid3D6LJfPac" alt=""><figcaption></figcaption></figure>
```

* Click on Finish to complete the BluSapphire Log Shipping Agent Setup Wizard.
*

```
<figure><img src="/files/bF8cmwxLoWsG41UTvtEz" alt=""><figcaption></figcaption></figure>
```

* Press any Key to continue
*

```
<figure><img src="/files/1Zgi4eIaCbL0MgczVmqh" alt=""><figcaption></figcaption></figure>
```

6. **Verify the Installation**

* To confirm the package is installed correctly, verify that the `blulogshipper` service is running by checking its status in **services.msc**

<figure><img src="https://2078222076-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MMRHZBPHlLDUc8519fX%2Fuploads%2FgoC8RlKXtDVEUEK1cg0I%2Fimage.png?alt=media&amp;token=04d8990a-e74d-433e-a26d-857b2a36bac5" alt="" width="375"><figcaption></figcaption></figure>

{% embed url="<https://youtu.be/jopk3-BuVGw>" %}

### Uninstallation Steps

1. Press `Win + R`, type `control`, press Enter, then go to **"Programs and Features"**.
2. Select "BluLogShipper", click **"Uninstall"**, and follow the prompts.


# Troubleshooting Installs

Easy Troubleshooting Page for Agent Install Failures.

BluLogShipper Install Errors

\#1. **Error: TLS Verification Error (Resolved)**

If you encounter the above "TLS Verification Error", it is often associated with the below causes:

***Cause*****:** The System is not up-to-date on patches OR it hasn't been patched in a very long time. This results in the system not having updated TLS root certificates in its certificate authority store.&#x20;

*<mark style="color:green;">**Resolution 1**</mark>*: Please update your system to the latest updates available.

*<mark style="color:green;">**Resolution 2**</mark>*: If TLS issue is not resolved. Here are the steps to fix it:

1. Open the following link in a browser:\
   <https://www.amazontrust.com/repository/AmazonRootCA1.pem>
2. Copy the key.
3. Save it as a `.pem` file on your system.
4. Move the `.pem` file to the conf folder.
5. Edit the `fluent-bit` configuration.
6. Add the following script to the output section:\
   \
   **tls: on**\
   **tls.verify: true**\
   **tls.ca\_file: \<path of the .pem file>/.pem**
7. Ensure that the path uses forward slashes (`/`).
8. Then restart the service now&#x20;

***Cause***: Your systems is out of support and is no longer supported by the vendor.

*<mark style="color:green;">**Resolution**</mark>*: Please upgrade to the latest version of the Operating System (OS) at the earliest. This is considered a severe risk by CSCRF. When your operating system is out of support, security patches are no longer provided by the vendor. Hence, this qualifies as a severe risk and shall be represented as such to the exchange.

***Cause***: Your system Date and time are not synchronised to a radio clock / time server on the internet and/or is not up to date.

*<mark style="color:green;">**Resolution**</mark>*: Good security practices require that your system should always be in sync with network time servers. There are many reliable time servers on the internet. Please ensure your system is synced.

***Cause***: TLS version mismatch.

*<mark style="color:green;">**Resolution**</mark>*: This again happens if you system is out of support by the vendor and/or not updated in a long time. TLS 1.3 has been a standard for over at least 3yrs now. Please upgrade.

***

#### #2. **Error: Windows Event and Message Fields Are Missing (Resolved)**

**Cause:**\
This issue typically arises on older versions of Windows (2016 or older). The root cause is a character set mismatch in Fluent Bit, which defaults to Unicode, while older versions of Windows use ANSI.

<mark style="color:green;">**Resolution**</mark>**:**

* Update the `Use_ANSI` flag in every input section to `True`.
* Restart the service.

***

#### #3. **Error: Input Channel for Windows Defender Operational Is Not Present on Windows Server 2012 R2, Leading to Unexpected Service Termination**

**Cause:**\
Fluent Bit is unable to find the log locations for Windows Defender Operational logs.

<mark style="color:green;">**Resolution**</mark>**:**

* Remove the input log source for Windows Defender Operational logs.
* This is a temporary solution that allows the service to work with limited input.

***

#### #4. **Error: Unable to Install BluLogShipper Due to GLIBC Version Being Lower Than Required**

**Cause:**\
This issue is caused by an unsupported version of the GNU C Library (GLIBC) for C library-based applications.

<mark style="color:green;">**Resolution**</mark>**:**

* BluLogShipper supports systems with GLIBC version 2.27 or higher.
* If the customer needs an older version, refer to the BluLogShipper build documentation and build it in an environment with the required or older GLIBC version.

***

#### #5. **Error: Unable to Install BluLogShipper from Non-C:\ Drives**

**Cause:**\
This error occurs when the installer is launched from a file path other than the "C:" drive on Windows. The installer is unable to copy configuration and credential files from another drive to `C:\Program Files\BluLogShipper\conf`, causing the installation to terminate.

<mark style="color:green;">**Resolution**</mark>**:**

* Install BluLogShipper from a child directory of the `C:\` drive.

***

#### #6. **Error: Timeout While Performing a DNS Call**

**Cause:**\
For some clients, the DNS server is set by the service provider, which can lead to errors. Please check your local DNS resolution.&#x20;

<mark style="color:green;">**Resolution**</mark>**:**

* If you do not receive any support from your local DNS provider (usually your ISP), then try changing  the DNS server address to a public secure DNS server like below:

| Google     | 8.8.8.8        | 8.8.4.4         | Fast, globally distributed, minimal logging |
| ---------- | -------------- | --------------- | ------------------------------------------- |
| Cloudflare | 1.1.1.1        | 1.0.0.1         | Privacy-focused, no logging, fast           |
| Quad9      | 9.9.9.9        | 149.112.112.112 | Security-first: blocks malicious domains    |
| OpenDNS    | 208.67.222.222 | 208.67.220.220  | Offers filtering and parental control       |

.

* Carefully verify the DNS configuration to resolve these issues.


# M-SOC | Frequently Asked Questions (FAQ)

This page attempts to capture all the FAQs related to MSOC, but may be applicable for other customers also.

**SEBI released an CSCRF FAQ circular on June 11th 2025 to answer most frequently asked questions from REs (Regulated Entities) / members.**&#x20;

**Further to the SEBI FAQ circular, on 20th June 2025, DSCI released thier explanatory note on these FAQs and more facts on CSCRF. Please refer to them in the URLs mentioned below:**

**SEBI:** [**https://www.sebi.gov.in/sebi\_data/faqfiles/jun-2025/1749647139924.pdf**](https://www.sebi.gov.in/sebi_data/faqfiles/jun-2025/1749647139924.pdf)

**DSCI:** [**https://www.dsci.in/resource/content/explanatory-note-released-faqs-cscrf-and-cloud-adoption-framework-regulated-entities-sebi**](https://www.dsci.in/resource/content/explanatory-note-released-faqs-cscrf-and-cloud-adoption-framework-regulated-entities-sebi)

**1. Is log data stored on my local network?**&#x20;

* Log data is stored with the M-SOC provider. Regulator requires that M-SOC provides 6months online and 18 months offline. That is a total of 24 months worth of data storage. M-SOC is responsible and accountable for storing this data and provisioning it on demand to the exchange and/or auditors. REs may also access this data easily using their own logins created using the [self-service portal](/m-soc/m-soc-or-self-service-portal/manage-users-and-roles).

**2. Will I have access to the logs OR only M-SOC has access?**&#x20;

* Yes, REs will have direct read-only access to the logs themselves. Infact, REs will have access to everything that an M-SOC analyst has access to including Logs, Dashboards, Tickets, Alerts, Incidents and reports.

**3. How will you collect data from my environment?**&#x20;

* We only collect logs from your environment. These could be operating system logs, application logs, webserver logs, firewall logs, etc. The types of logs we collect depend on your organization's infrastructure and the security measures in place.&#x20;

**4. I want to only include some of my critical machines only. Is that possible?**&#x20;

* Yes, we can tailor the deployment to focus on critical machines based on your requirements. According to SEBI guidelines, this must be done in consultation with your SPOC or someone familiar with your infrastructure. If your critical machines are not on a separate zone or VLAN with strict access controls, it's generally not advisable to just include critical machines. all systems have to be included.

**5. What is EDR and why is it needed?**&#x20;

* EDR (Endpoint Detection and Response) is similar to an antivirus system. It helps detect and respond to potential threats at the endpoint level, enhancing security on devices like computers and servers. Most Windows operating systems come with Windows Defender by default.  In large complex infrastructures dedicated EDR tools that operate across windows and linux systems may be needed.

**6. What is the onboarding process? and how long does it take?**

* Step 1: [Register on the portal](/m-soc/m-soc-or-self-service-portal/registering-as-a-customer-regulated-entity) with all the required details.&#x20;
* Step 2: Upon login, you will be directed to a [landing page](/m-soc/m-soc-or-log-collection-and-forwarding-guide/windows-package-installation) with links to download the required lightweight agents that will forward the logs.&#x20;
* Step 3: Follow the standard [installation instructions](/m-soc/m-soc-or-log-collection-and-forwarding-guide/windows-package-installation) provided on the portal page.&#x20;
* Alternatively, you may watch this [playlist of videos](https://www.youtube.com/playlist?list=PLyWdzMZRpDRW1Z6bAv-EH9AMcjQtCUXWe) to guide you through the process OR refer to the step-by-step [documentation on this site](/m-soc/m-soc-or-self-service-portal).

The entire onboarding process takes less than **10 minutes** to complete. Installing log forwarding agents could take upto 5 minutes with required administrator privileges needed for install.

**7. Can you send me the onboarding process and company details?**&#x20;

* The onboarding process includes:&#x20;
* [Registering](/m-soc/m-soc-or-self-service-portal/registering-as-a-customer-regulated-entity) on the portal.&#x20;
* Downloading the [necessary agents](/m-soc/m-soc-or-log-collection-and-forwarding-guide/windows-package-installation).&#x20;
* Installing the agents as per the provided instructions.&#x20;

**8. In the case of an attack at BluSapphire, what will happen to my environment?**&#x20;

* BluSapphire ensures robust security measures to protect both our platform and your environment. We are an ISO27001 company and our data center is SOC2 type2 certified. \
  Additionally, there is no inbound connectivity to your environment from BluSapphire, ensuring your environment remains safe at all times. In the unlikely event of an attack, our multi-layered security architecture minimizes risks to your data and operations.&#x20;

**9. What data/logs will be pushed from BluSapphire to my environment? Is it safe?**&#x20;

* For a list of the logs we collect, please refer to the "[Logs Collected](/m-soc/m-soc-or-log-collection-and-forwarding-guide/default-log-collection)" section. All data in-transit and at-rest are encrypted and comply with industry standards to ensure your safety.&#x20;

**10. What kind of reports can I expect from BluSapphire?**&#x20;

* BluSapphire provides standard Monthly and Quarterly reports, which include high-level overviews of security posture, threat intelligence, and incident analysis.&#x20;

**11. What support can I expect if I struggle to download or deploy the solution?**&#x20;

* Our support team (<support@blusapphire.com>) provides end-to-end assistance during the download and deployment process. We offer 24x7 product services to help resolve any challenges.&#x20;

**12. What components will BluSapphire deploy for me? How can I opt for SOAR capabilities?**&#x20;

* For smaller infrastructures, we only install the log forwarding agents. BluSapphire will deploy a log-collector to in case of complex/mature infrastructure.&#x20;
* If you are interested in SOAR (Security Orchestration, Automation, and Response) capabilities, please contact our sales team at <sales@blusapphire.com> to discuss customized options and pricing.&#x20;

13. I**s EDR (Endpoint Detection and Response) mandatory for the endpoints?**

* EDR is not mandatory, but highly recommended for proactive cybersecurity.

14. **Is Remediation part of the stakeholder responsibilities, or do they fall under BluSapphire?**

* Remediation is the responsibility of the stakeholders. There will be a detailed RACI chart that will describe these responsibilities in greated detail. However, Remediation asisstance is available at an additional fee.

15. **The Announcement says this is the Pilot and the actual go-live will be the 1st of April, will we be charged from now or from April**

* The billing starts immediately. Invoicing and payment are upfront.

16. **There is a mention of Pilot in the announcement**

* Pilot is more to fine tune the engagement process between the MSOC and the exchange. For REs the compliance is due.

17. **SEBI circular says the effective date is 1st April; we will get back to you in March**

* Compliance to CSCRF is mandatory. April 1st is to finalize the notification requirements between SEBI, Exchange and MSOC. The On-Boarding should start as early as possible as we have a priority Onboarding Queue, and the system and processes will need a few weeks to stabilize on your environment.

18. **If we have a VM and have multiple apps on it will it be counted as one device or multiple devices?**

* Our Response – VM will count as one endpoint along with its operating system logs. Each cover compliance app is counted as one endpoint.&#x20;
  * Eg 1: if you have an email-server on a VM, the VM will be counted as one endpoint and email-server shall be counted as another endpoint.
  * Eg 2: consider an environment with the below infrastructure:

    * 20 laptops
    * 5 servers
    * Two web applications (hosted on two of the 5 servers listed above)
    * Two AWS instances

    In this case, the total number of endpoints counted are:

    * 20 laptops + 5 servers + 2 web applications + 2 AWS instances = **29 endpoints**.

19. **What is the log retention policy?**

* All logs are retained for 6 months online and 18 months offline as per SEBI requirements. RE are not required to pay anything additional. The fee covers everything.

20. **Will I have unlimited access to my logs?**

* Yes, RE themselves will also have unlimited access to their logs. REs will also have access to all the published Dashboards always. However, RE will only have access to thier own data. The Dashboards will also only reflect thier own data only.

21. **Who will be monitoring my logs for security alerts and incidents "Exchange" or "M-SOC"?**

* M-SOC will be responsible for monitoring RE logs for security alerts and incidents. Once an incident has been identified, M-SOC and RE have to follow the [incident management workflow](/m-soc/m-soc-or-self-service-portal/incident-management-workflow-m-soc-only) and perform thier requisite duties to close the incident.

22. **Who else will be aware of cyber security incidents on my environment?**

* M-SOC will notify the RE of the security incident. Critical incidents are notified to CERT-IN as per SEBI requirements.

23. **What is EPS? I hear other vendors offering based on EPS?**

* EPS stands for Events Per Second. This is very dynamic and confusing for REs with little infrastructure. If you are an RE with less than 100 endpoints, then you are usually better served using per endpoint pricing model.\
  REs with large scale complex infrastructure clearly understand EPS and may opt for it instead. Please reach out to <msoc@blusapphire.com> for pricing.

24. **Will M-SOC provide VAPT and audit services also?**

* Yes, M-SOC will provide VAPT and audit services at an additional pricing. Please refer to the document section of the portal and you will see a laundry list of all additonal services offered by M-SOC.

&#x20;25\. **Do I have to declare assets in my infrastructure? Why is this needed?**

* Yes, There is an "AssetInventory.xls" template file under documents in your onboarding portal. Please fill out the details of your assets that you are onboarding in the same format. List provided in any other format shall not be accepted.
* M-SOC will monitor these assets and notify non-availability of an asset OR if M-SOC stops receiving logs from an asset.
* Yes, REs can upload multiple versions of the asset list with updated assets any time they wish.

26. **How can we identify we fall under which category?**

* Kindly refer to the [SEBI CSCRF notification](https://www.sebi.gov.in/legal/circulars/aug-2024/cybersecurity-and-cyber-resilience-framework-cscrf-for-sebi-regulated-entities-res-_85964.html) Section 2, page39+ for details.

27. **How you guys will define the level of alert (Critical, high, med /low)??**

* Kindly refer to the [SEBI CSCRF notification](https://www.sebi.gov.in/legal/circulars/aug-2024/cybersecurity-and-cyber-resilience-framework-cscrf-for-sebi-regulated-entities-res-_85964.html) Annexure -O for details.

28. **Is M-SOC is mandatory for Stock broker doing only proprietary and institution trading ?**

* Kindly refer to the [SEBI CSCRF notification](https://www.sebi.gov.in/legal/circulars/aug-2024/cybersecurity-and-cyber-resilience-framework-cscrf-for-sebi-regulated-entities-res-_85964.html) Section 2, Page 39+ for details.

29. **What all will be done in User Entity Behaviour Analytics?**

* User and Entity Behavior Analytics (UEBA) analyzes user and device activity to detect suspicious behavior. UEBA uses machine learning and statistical analysis to identify normal patterns of behavior. It can then alert security teams when it detects deviations from those patterns.
* UEBA monitors user and device activity in real time. It builds behavioral profiles for users, devices, and other entities. It detects anomalies in behavior, such as unusual data transfers or unusual activity times. It alerts security teams when it detects anomalies that may indicate a threat.

30. **We want to know that we are a member of BSE and Also Have CDSL DP and Research Analyst then we are lying in Mid REs or Small RE's?**

* Kindly refer to the [SEBI CSCRF notification](https://www.sebi.gov.in/legal/circulars/aug-2024/cybersecurity-and-cyber-resilience-framework-cscrf-for-sebi-regulated-entities-res-_85964.html) Section 2, Page 39+ for details.

31. **Can we have one SOC for all the exchanges and depository?**

* SEBI has mandated BSE and NSE to provide M-SOC services. Other exchanges and depositories have the option of starting or just using the ones provided by BSE & NSE. You may choose one M-SOC for your compliance. There is no need to subscribe to multiple M-SOCs.

32. **How logs will be collected? A syslog server is provided by MSOC or REs need to implement on their own?**

* Depending on the architecture, logs are collected directly OR a Log Collector (syslog) will be provided by M-SOC. This has to get installed on hardware provided by RE.

33. **We are an NSE registered entity. Can we use the M-SOC provided by BSE?**

* Absolutely. There are no restrictions. You can onboard with BSE M-SOC and you will still be compliant.

34. **If we are self-certified RE if we have SOC is it required to subscribe to M-SOC?**

* If you already have a SOC and complies with all the requirements of CSCRF including SOC efficacy requirements, then there is no need to subscribe to M-SOC.

35. **Log retention is mandatory as per regulatory req. then why is it under Optional service?**

* Log retention of 6 months is mandatory as per regulator. BSE M-SOC provides this service as part of the proposed cost. No need for any additional cost. As per SEBI framework for M-SOCs, they may optionally provide the service.

36. **For small sized REs who are part of global large banks who have access to group SOC , can they be exempted from Market SOC?**

* Please work with SEBI for clarification. Kindly refer to the [SEBI CSCRF notification](https://www.sebi.gov.in/legal/circulars/aug-2024/cybersecurity-and-cyber-resilience-framework-cscrf-for-sebi-regulated-entities-res-_85964.html) Section 2, page39+ for details.

37. **Is there any exemption provided to 100% proprietary trading broker?**

* Please work with SEBI for clarifications. Kindly refer to the [SEBI CSCRF notification](https://www.sebi.gov.in/legal/circulars/aug-2024/cybersecurity-and-cyber-resilience-framework-cscrf-for-sebi-regulated-entities-res-_85964.html) Section 2, page39+ for details.

38. **How is incident management run?**&#x20;

* The incident management workflow linked here is the agreed upon Incident WorkFlow for all M-SOCs. Any assistance needed outside of this may be availed at an additional cost.

39. **Can you elaborate a bit more on SOAR?**

* SOAR refers to Security Orchestration Automation and Reponse. Please review on OneFlow documentation. This describes our SOAR in detail.

40. **What are the privacy / data protection policies for the logs?**

* Logs are governed by the Data Protection, Localization requirement laid down by the regulator. M-SOC adheres to the regulatory requirements laid down in Cloud Security Framework and CSCRF.

41. **Are optional services also mandated sebi for all or midsized small sized?**

* No. Optional services are not mandated by SEBI. The exception is log retention. The regulator requires 180 days logs online and 18 months logs offline.

42. **Do we have access to Centralized Dashboard? Read only?**

* All logs once generated and consumed are immutable (strictly read-only) by definition. They cannot be edited by anyone. Yes, you will have access to centralized dashboards that pertain to your data only.

43. **How to enrol and participate in test environment?**

* You may enrol using the self-service portal and go live with no further assistance from M-SOC. If you need support, please reach out to <msoc@blusapphire.com> OR for existing customers (<msoc_support@blusapphire.com>).
* For customers with less than 200 systems, test environment is not available. For customers with larger than 200 systems please reach out to your sales representative or <msoc@blusapphire.com> and a testbed may be arranged for you. All testbeds are for a period of 10 working days.

44. **Which SIEM tool , you will use and what will be the cost?**

* For M-SOC we use BluSapphire next-gen AI SIEM tool. All licenses and their associated costs are included in the service.

45. **Does threat intelligence include Dark Web Monitoring too?**

* Threat Intelligence does not include Dark Web Monitoring. That is a separate service that M-SOC does not provide and will have to be sourced from a different vendor if needed.

46. **How secure is this M-SOC ,technically it will collect logs of critical servers databases having clients Information , might be required to installs M-SOC log forwarder Agents for better visibility, does it follow or admit any NDA and Data will be maintained within India?**

* Logs are governed by the Data Protection, Localization requirement laid down by the regulator. M-SOC adheres to the regulatory requirements laid down in Cloud Security Framework and CSCRF. Additionally, Logs are encrypted in-transit and at-rest. Encryption Keys used for encrypting logs at-rest are stored outside of the service provider. This is in compliance with Cloud Security Framework provided by SEBI.
* M-SOC is ISO 27001 certified and the data centre is SOC2 Type2 certified.
* Geographically, all logs are stored in Mumbai, India.

47. **Is it possible to integrate application logs for monitoring purposes via MSOC?**

* M-SOC is for security monitoring. Yes, it is possible for monitoring application logs for security violations/incidents using M-SOC.

48. **If there is a need to integrate an additional system, such as a server or network device, what criteria and procedures should be followed?**

* M-SOC can accommodate specific integration requirements outside of the default logs collected at an economical cost. Logs have to adhere to some guidelines viz., logs have to be text, each log line has to be on a different line and not mixed with one another, and the vendor/customer should be aware of the contents of the logs and be able to provide assistance for integration.

49. **What about VMWare logs ?**

* Yes, VMWare logs can also be ingested. Logs that are supported by default are [here](/log-forwarding/03_log-forwarding-guide/log-forward) and [here](/m-soc/m-soc-or-log-collection-and-forwarding-guide/default-log-collection).

50. **Can we register with only one M-Soc empanelled with either NSE/BSE?**

* Yes. You have to register with only one M-SOC.

51. **What is the contract period?**

* Contract term will be 3 years. Either party may terminate the contract with 90 days notice period.

52. **Are all logs stored for 180 days or only actionable events?**&#x20;

* All security logs are stored for 180 days online and 18 months offline.

53. **In future, how we will be able to access the old logs if we start our own SOC ?**

* Yes. Data Exfiltration costs apply.

54. **We have multiple lines of business and membership under same entity for example Stock Broking, Depository Participant, PMS and also acting as Investment manager for an AIF. Do we need to register separately as per different licenses for the same entity?**

* Licensing is based on per endpoint. So you may choose to license as one entity or multiple entities. It does not matter to M-SOC. In many cases, it also depends on how your internal billing works.

55. **Is this only for Security Information and Event Management or does it also provide overall environment security?**

* This applies to all compliance systems as identified by the regulator. Typically your IT environment at this point and not IOTs or ICT systems. Please check with your regulator for clarity.

56. **Will SOC generate alerts in case on down time taken for critical systems?**

* M-SOC will generate alerts for missing log sources (endpoints) within a given threshold. These thresholds are configurable as per each client requirements.&#x20;

57. **If web server is connected to internet through firewall ,how many end points will be there in this case?**

* One for the operating system hosting the web server + one for the web server logs + one for firewall. So in this example, this will be 3 endpoints. Another example is given as response for Question 18.

58. **Are netflow logs from firewall also collected in M-SOC?**

* Yes. M-SOC has the capability to collect [these logs](/m-soc/m-soc-or-log-collection-and-forwarding-guide/default-log-collection) by default. Others are listed [here](/log-forwarding/03_log-forwarding-guide/log-forward).

59. **What is the bandwidth used for transferring logs to M-SOC?**

* Logs are compressed and encrypted during transit. Compressing is usually at 9:1 on average.  So if you consider a windows log event to be around 1.3KB, then the amount of data that will pass through the internet pipe will be around 113bytes after compression. Average log sizes of various logsources can be reviewed [here](/log-forwarding/02_average-logsize-by-logsource).

60. **What logs are collected for the standard log categories?**

<table data-header-hidden><thead><tr><th width="79.1875"></th><th width="215.25"></th><th></th></tr></thead><tbody><tr><td>Sr. No.</td><td>Log Category</td><td>Logs  Collected</td></tr><tr><td>1</td><td>Windows 11/10 (server and desktop)</td><td>- OS / System &#x26; Security Event<br>- AV / XDR / EDR / Windows Defender Logs<br>- Network Connection<br>- User Access Audit</td></tr><tr><td>2</td><td>Unix (Linux, RHEL, Fedora, Ubuntu<br>etc.,)</td><td>- OS / System &#x26; Security Event<br>- AV / XDR / EDR / Windows Defender Logs<br>- Network Connection<br>- User Access Audit</td></tr><tr><td>3</td><td>Web server</td><td>- Access logs<br>- Traffic logs where applicable<br>- IIS / Apache</td></tr><tr><td>4</td><td>Database Server (As applicable)</td><td>- DB Audit logs<br>- DB Access logs</td></tr><tr><td>5</td><td>Firewall(s)</td><td>- Audit Logs<br>- Access Logs<br>- NetFlow<br>- Traffic Logs</td></tr><tr><td>6</td><td>Proxy (web/email)</td><td>- Audit Logs<br>- Access Logs<br>- Traffic Logs</td></tr><tr><td>7</td><td>DHCP</td><td>- DHCP logs where applicable</td></tr><tr><td>8</td><td>DNS</td><td>- DNS logs where applicable</td></tr><tr><td>9</td><td>Active Directory</td><td>- AD logs</td></tr><tr><td>10</td><td>Auth</td><td>- Authentication logs</td></tr><tr><td>11</td><td>Cloud</td><td><p>-CloudWatch, CloudTrail, GuardDuty</p><p>-M365, Azure, EntraID, Defender</p></td></tr></tbody></table>


# 01\_List of Supported LogSources

<table data-header-hidden><thead><tr><th width="79.46484375"></th><th width="220.8515625"></th><th></th><th></th></tr></thead><tbody><tr><td><strong>S.NO</strong></td><td><strong>Log Source</strong></td><td><strong>Log Category</strong></td><td><strong>Log Format</strong></td></tr><tr><td>1</td><td>Apache WebServer</td><td>webserver</td><td>clf</td></tr><tr><td>2</td><td>Apache Tomcat</td><td>webserver</td><td>clf</td></tr><tr><td>3</td><td>AWS Cloudtrail</td><td>aws</td><td>json</td></tr><tr><td>4</td><td>AWS Cloudwatch</td><td>aws</td><td>json</td></tr><tr><td>5</td><td>AWS ELB</td><td>aws</td><td>json</td></tr><tr><td>6</td><td>AWS Guardduty</td><td>aws</td><td>json</td></tr><tr><td>7</td><td>AWS Security Hub</td><td>aws</td><td>json</td></tr><tr><td>8</td><td>AWS VPCflow</td><td>aws</td><td>json</td></tr><tr><td>9</td><td>AWS WAF</td><td>aws</td><td>json</td></tr><tr><td>10</td><td>AZURE AD logs</td><td>azure</td><td>json</td></tr><tr><td>11</td><td>Azure Application Gateway</td><td>azure</td><td>json</td></tr><tr><td>12</td><td>Azure Firewall</td><td>azure</td><td>json</td></tr><tr><td>13</td><td>Azure Graph Activity</td><td>azure</td><td>json</td></tr><tr><td>14</td><td>Azure Identity Protection</td><td>azure</td><td>json</td></tr><tr><td>15</td><td>Barracuda Web Application Firewall</td><td>proxy-web</td><td>syslog</td></tr><tr><td>16</td><td>Brocade Switch</td><td>network</td><td>syslog</td></tr><tr><td>17</td><td>Check Point Harmony Endpoint</td><td>epp</td><td>syslog-kv</td></tr><tr><td>18</td><td>Check Point NGAV</td><td>epp</td><td>cef</td></tr><tr><td>19</td><td>Checkpoint Firewall</td><td>ngfw</td><td>syslog</td></tr><tr><td>20</td><td>Cisco ASA Firewall</td><td>ngfw</td><td>syslog</td></tr><tr><td>21</td><td>Cisco DNAC</td><td>wireless</td><td>syslog-json</td></tr><tr><td>22</td><td>Cisco Duo</td><td>auth</td><td>json</td></tr><tr><td>23</td><td>Cisco Fabric Controller (NX-OS)</td><td>network</td><td>syslog</td></tr><tr><td>24</td><td>Cisco Firepower Threat Defense</td><td>ngfw</td><td>syslog</td></tr><tr><td>25</td><td>Cisco Firewall Management Center</td><td>ngfw</td><td>syslog</td></tr><tr><td>26</td><td>Cisco Identity Services Engine</td><td>nac</td><td>syslog-kv</td></tr><tr><td>27</td><td>Cisco IOS Devices (Router, Switch)</td><td>network</td><td>syslog</td></tr><tr><td>28</td><td>Cisco Meraki Firewall</td><td>ngfw</td><td>syslog -kv</td></tr><tr><td>29</td><td>Cisco Meraki Switch</td><td>network</td><td>syslog</td></tr><tr><td>30</td><td>Cisco Remote Management Service (RMS)</td><td>linux</td><td>syslog</td></tr><tr><td>31</td><td>Cisco Secure Endpoint (AMP)</td><td>epp</td><td>json</td></tr><tr><td>32</td><td>Cisco Umbrella</td><td>dns</td><td>csv</td></tr><tr><td>33</td><td>Cisco Wireless Access Point</td><td>wireless</td><td>syslog-kv</td></tr><tr><td>34</td><td>Cloudflare Events</td><td>proxy-web</td><td>json</td></tr><tr><td>35</td><td>Crowdstrike Falcon</td><td>epp</td><td>json</td></tr><tr><td>36</td><td>Cyber20-IT</td><td>epp</td><td>json</td></tr><tr><td>37</td><td>CyberArk Pas</td><td>auth</td><td>syslog-json/cef</td></tr><tr><td>38</td><td>Dell CloudIQ</td><td>nas</td><td>syslog-kv</td></tr><tr><td>39</td><td>Dell Remote Management Service (RMS)</td><td>linux</td><td>syslog</td></tr><tr><td>40</td><td>Dellemc Switch</td><td>network</td><td>syslog</td></tr><tr><td>41</td><td>ERP SAP</td><td>erp</td><td>json</td></tr><tr><td>42</td><td>Escan Antivirus</td><td>epp</td><td>syslog</td></tr><tr><td>43</td><td>Forcepoint Web Security</td><td>proxy-web</td><td>json or cef</td></tr><tr><td>44</td><td>Fortinet FortiAnalyzer</td><td>ngfw</td><td>syslog</td></tr><tr><td>45</td><td>Fortinet FortiClient EMS</td><td>epp</td><td>syslog-kv</td></tr><tr><td>46</td><td>Fortinet FortiGate Firewall</td><td>ngfw</td><td>syslog</td></tr><tr><td>47</td><td>Fortinet FortiManager</td><td>ngfw</td><td>syslog</td></tr><tr><td>48</td><td>Fortinet Fortinac</td><td>nac</td><td>cef</td></tr><tr><td>49</td><td>FreeIPA</td><td>auth</td><td>syslog-kv</td></tr><tr><td>50</td><td>Gajshield Firewall</td><td>ngfw</td><td>syslog-kv</td></tr><tr><td>51</td><td>GCP CloudSQL MySQL</td><td>gcp</td><td>json</td></tr><tr><td>52</td><td>GCP Firewall</td><td>gcp</td><td>json</td></tr><tr><td>53</td><td>GCP Loadbalancer</td><td>gcp</td><td>json</td></tr><tr><td>54</td><td>HPE Aruba Switch</td><td>network</td><td>syslog</td></tr><tr><td>55</td><td>HPE Aruba Wireless</td><td>wireless</td><td>syslog</td></tr><tr><td>56</td><td>HPE Remote Management Service (RMS)</td><td>linux</td><td>syslog</td></tr><tr><td>57</td><td>IBM Remote Management Service (RMS)</td><td>linux</td><td>syslog</td></tr><tr><td>58</td><td>IBM Storwize</td><td>nas</td><td>syslog -kv</td></tr><tr><td>59</td><td>Imperva WAF</td><td>proxy-web</td><td>cef</td></tr><tr><td>60</td><td>JumpCloud Directory Events</td><td>auth</td><td>json</td></tr><tr><td>61</td><td>Juniper Firewall</td><td>ngfw</td><td>syslog</td></tr><tr><td>62</td><td>Juniper Router</td><td>network</td><td>syslog</td></tr><tr><td>63</td><td>Kaspersky Antivirus</td><td>epp</td><td>cef</td></tr><tr><td>64</td><td>Lenovo NAS</td><td>nas</td><td>syslog-json</td></tr><tr><td>65</td><td>Lenovo Remote Management Service (RMS)</td><td>linux</td><td>syslog</td></tr><tr><td>66</td><td>Lenovo Switch</td><td>network</td><td>syslog</td></tr><tr><td>67</td><td>Liferay CMS</td><td>webserver</td><td>syslog</td></tr><tr><td>68</td><td>Linux</td><td>linux</td><td>syslog</td></tr><tr><td>69</td><td>ManageEngine ADAudit Plus</td><td>auth</td><td>syslog</td></tr><tr><td>70</td><td>ManageEngine Endpoint Central</td><td>epp</td><td>syslog-kv</td></tr><tr><td>71</td><td>ManageEngine OpManager</td><td>webserver</td><td>syslog</td></tr><tr><td>72</td><td>Mcafee Epolicy Orchestrator</td><td>epp</td><td>syslog-xml</td></tr><tr><td>73</td><td>Microsoft DHCP</td><td>microsoft dhcp</td><td>csv</td></tr><tr><td>74</td><td>Microsoft DNS Server</td><td>microsoft dns</td><td>json</td></tr><tr><td>75</td><td>Microsoft IIS</td><td>webserver</td><td>clf</td></tr><tr><td>76</td><td>Microsoft Intune</td><td>mdm</td><td>json</td></tr><tr><td>77</td><td>Microsoft Office-365</td><td>azure</td><td>json</td></tr><tr><td>78</td><td>Microsoft SQL Server</td><td>db</td><td>kv</td></tr><tr><td>79</td><td>Mimecast Email Security</td><td>proxy-mail</td><td>json</td></tr><tr><td>80</td><td>MySQL Enterprise</td><td>db</td><td>json</td></tr><tr><td>81</td><td>Netgate PfSense Firewall</td><td>ngfw</td><td>syslog-kv</td></tr><tr><td>82</td><td>Netgear Switch</td><td>network</td><td>syslog</td></tr><tr><td>83</td><td>Netskope Security</td><td>proxy-web</td><td>json or syslog-cef</td></tr><tr><td>84</td><td>NetXGate Firewall</td><td>ngfw</td><td>syslog-kv</td></tr><tr><td>85</td><td>Nginx WebServer</td><td>webserver</td><td>clf</td></tr><tr><td>86</td><td>Nutanix HCI</td><td>virtual</td><td>syslog-kv</td></tr><tr><td>87</td><td>Okta</td><td>auth</td><td>json</td></tr><tr><td>88</td><td>OneLogin</td><td>auth</td><td>json</td></tr><tr><td>89</td><td>OpenVPN</td><td>ra</td><td>json</td></tr><tr><td>90</td><td>Oracle Database</td><td>db</td><td>json</td></tr><tr><td>91</td><td>PaloAlto Firewall</td><td>ngfw</td><td>csv</td></tr><tr><td>92</td><td>Perception Point Email Security</td><td>proxy-mail</td><td>json</td></tr><tr><td>93</td><td>PostgreSQL Database</td><td>db</td><td>json</td></tr><tr><td>94</td><td>Proofpoint On Demand Email Security</td><td>proxy-mail</td><td>json</td></tr><tr><td>95</td><td>Proofpoint Target Attack Protection</td><td>proxy-mail</td><td>json</td></tr><tr><td>96</td><td>Pulse Secure Connect</td><td>ra</td><td>syslog</td></tr><tr><td>97</td><td>Quality Network Appliance Provider (QNAP)</td><td>nas</td><td>syslog</td></tr><tr><td>98</td><td>Ruckus Switch</td><td>network</td><td>syslog</td></tr><tr><td>99</td><td>Ruckus Wireless Controller</td><td>wireless</td><td>syslog</td></tr><tr><td>100</td><td>Sectona PAM</td><td>auth</td><td>csv</td></tr><tr><td>101</td><td>SentinelOne Endpoint Protection</td><td>epp</td><td>json</td></tr><tr><td>102</td><td>Seqrite Antivirus</td><td>epp</td><td>syslog-cef-kv</td></tr><tr><td>103</td><td>SonicWall Firewall</td><td>ngfw</td><td>syslog</td></tr><tr><td>104</td><td>Sophos Central</td><td>epp</td><td>json</td></tr><tr><td>105</td><td>Sophos InterceptX</td><td>epp</td><td>json</td></tr><tr><td>106</td><td>Sophos XG Firewall</td><td>ngfw</td><td>syslog</td></tr><tr><td>107</td><td>Symantec Endpoint Protection</td><td>epp</td><td>syslog-kv</td></tr><tr><td>108</td><td>Tacitine EN6200</td><td>ngfw</td><td>syslog-kv</td></tr><tr><td>109</td><td>Trend Micro Apex Central</td><td>epp</td><td>syslog-cef</td></tr><tr><td>110</td><td>Trend Micro Deep Security</td><td>epp</td><td>syslog-cef</td></tr><tr><td>111</td><td>TrendMicro Vision one XDR</td><td>epp</td><td>json</td></tr><tr><td>112</td><td>Vcenter</td><td>virtual</td><td>syslog</td></tr><tr><td>113</td><td>Veeam Backup &#x26; Replication</td><td>nas</td><td>syslog-kv</td></tr><tr><td>114</td><td>Vicarius Vulnerability Management</td><td>vuln</td><td>json</td></tr><tr><td>115</td><td>Vmware ESXI</td><td>virtual</td><td>syslog</td></tr><tr><td>116</td><td>Vmware HCI</td><td>virtual</td><td>syslog</td></tr><tr><td>117</td><td>WatchGuard Firebox Firewall</td><td>ngfw</td><td>syslog</td></tr><tr><td>118</td><td>Windows</td><td>windows</td><td>json</td></tr><tr><td>119</td><td>Zoho Analytics</td><td>erp</td><td>json</td></tr><tr><td>120</td><td>Zoho Vault</td><td>erp</td><td>json</td></tr><tr><td>121</td><td>Zscaler Audit Events</td><td>proxy-web</td><td>json</td></tr><tr><td>122</td><td>Zscaler Deception</td><td>deception</td><td>syslog-json</td></tr><tr><td>123</td><td>Zscaler Web Events</td><td>proxy-web</td><td>syslog-cef-kv</td></tr></tbody></table>


# 02\_Average LogSize by LogSource

Logsize by Logsource

The below tables makes an attempt to capture the average size of a log by logsource.&#x20;

**Please note:** *There could be variations depending on the organizaiton type, asset type, logging options chosen, deployment type and architecture. This table is for a basic reference - more like a rule of thumb.*

| Log Source                            | LogSize (in bytes) |
| ------------------------------------- | ------------------ |
| azure                                 | 710.09             |
| cylance                               | 363.51             |
| dhcp                                  | 102.67             |
| dns                                   | 151.83             |
| entrust                               | 2182.78            |
| epo                                   | 1102.28            |
| fireeye                               | 827.82             |
| fsctcenter                            | 360.29             |
| msad                                  | 1638.15            |
| msexchange                            | 186.49             |
| nessus                                | 2586.53            |
| net\_infrastructure                   | 392.78             |
| net\_lan                              | 193.71             |
| net\_security                         | 161.16             |
| websense                              | 680.60             |
| wineventlog                           | 1251.04            |
| ActiveDirectory                       | 2318.07            |
| DhcpSrvLog                            | 102.17             |
| MSAD:NT6:DNS                          | 150.57             |
| MSAD:NT6:DNS-Health                   | 1240.72            |
| MSAD:NT6:DNS-Zone-Information         | 564.93             |
| MSAD:NT6:Health                       | 650.1              |
| MSAD:NT6:Netlogon                     | 66.83              |
| MSAD:NT6:Replication                  | 233.05             |
| MSAD:NT6:SiteInfo                     | 139.33             |
| MSExchange:2013:Audit                 | 820.23             |
| MSExchange:2013:Database-Stats        | 766.54             |
| MSExchange:2013:DistributionLists     | 2781.24            |
| MSExchange:2013:Folder-Usage          | 116.24             |
| MSExchange:2013:InboxRules            | 2234.74            |
| MSExchange:2013:Mailbox-Usage         | 247.15             |
| MSExchange:2013:MailboxAudit          | 1481.75            |
| MSExchange:2013:MessageTracking       | 764.75             |
| MSWindows:2012:IIS                    | 276.38             |
| Powershell:ScriptExecutionErrorRecord | 3513.35            |
| Powershell:ScriptExecutionSummary     | 249.04             |
| WinEventLog:DFS-Replication           | 509.5              |
| WinEventLog:Directory-Service         | 689.77             |
| cisco:acs                             | 880.61             |
| cisco:asa                             | 161.55             |
| cisco:ios                             | 197.93             |
| citrix:netscaler:syslog               | 286.06             |
| mcafee:epo                            | 1128.8             |
| ms:o365:management                    | 1269.09            |
| ms:o365:reporting:messagetrace        | 484.13             |
| syslog                                | 165.61             |
| syslog\_protect                       | 366.75             |
| websense                              | 678.49             |


# 03\_Log Forwarding Guide


# On-Prem Log Forwarding Guide

This page contains instructions on how to forward logs from various log sources to BluSapphire. There may be minor differences on the data collected on various sources. Beware.


# Aruba


# Aruba-3810M-L3 Switch

L3 Switch

Aruba 3810M:

[To configure the IP address of a syslog server to which the managed device can direct the logs of Aruba 3810M, you can follow these steps](https://www.arubanetworks.com/techdocs/ArubaOS_87_Web_Help/Content/arubaos-solutions/manage-utilities/conf-logg.htm):

* In the Managed Network node hierarchy, navigate to the Configuration > System > Logging > Syslog Servers page.
* To add a logging server, click + in the Syslog Servers section.
* Enter the IP address and the Port number of the syslog server.
* Add the logging server to the list of logging servers.
* Ensure that the syslog server is enabled and configured on this host.


# Aruba-6200F-48-Access Switch

Access Switch

6200F-48 switch:

To configure the IP address of a syslog server to which the Aruba 6200F-48 switch can direct the logs, you can follow these steps:

* Connect to the switch using a console cable or a Telnet/SSH session.
* Enter the privileged EXEC mode by typing \`enable\` and providing the password if prompted.
* Enter the global configuration mode by typing \`configure terminal\`.
* Enter the logging configuration mode by typing \`logging\`.
* Specify the IP address of the syslog server by typing \`host \<ip-address>\`. You can also specify the UDP port number and the facility level by adding \`port \<port-number>\` and \`facility \<facility-level>\` respectively. For example, \`host 192.168.1.100 port 514 facility local7\`.
* Exit the logging configuration mode by typing \`exit\`.
* Save the configuration by typing \`write memory\`.

You can verify the syslog configuration by typing show logging in the privileged EXEC mode. You can also view the syslog messages on the switch by typing show logging bu


# Aruba switch log integration

**Aruba Switch Log Integration Guide**

**Log Integration procedure:**

To forward logs, make the following configuration.

1. **Login to the CLI Terminal**
2. **Switch to Global Configuration mode.**

Enter the following command:

**config t**

`device# config t`

3. **Configure Syslog Forwarding**

Enter the following command:

**logging X.X.X.X udp 12311**

`device(config)# logging 10.10.2.73 udp 12311`

Replace X.X.X.X with Log Collector IP of specific branch with the Port Number same as above.

4. **Configure Severity level**

Enter the following command:

**logging severity debug**

`device(config)# logging severity debug`

5. **Exit the Configuration mode.**

Type **end**

`device(config)# end`

6. **Save the configuration.**

Type **write memory**

`device# write memory`


# aruba switch log integration

**Aruba Switch Log Integration Guide**

**Log Integration procedure:**

To forward logs, make the following configuration.

1. **Login to the CLI Terminal**
2. **Switch to Global Configuration mode.**

Enter the following command:

**config t**

`device# config t`

3. **Configure Syslog Forwarding**

Enter the following command:

**logging X.X.X.X udp 12311**

`device(config)# logging 10.10.2.73 udp 12311`

Replace X.X.X.X with Log Collector IP of specific branch with the Port Number same as above.

4. **Configure Severity level**

Enter the following command:

**logging severity debug**

`device(config)# logging severity debug`

5. **Exit the Configuration mode.**

Type **end**

`device(config)# end`

6. **Save the configuration.**

Type **write memory**

`device# write memory`


# Big-IP Load Balancer 17.x

This guide outlines two methods to forward logs from your BIG-IP Load Balancer to a Log collector:

**Method 1 :** Using the configuration utility.

**Method 2 :** Using TMOS Shell

**Prerequisites**

You must meet the following prerequisites to use these procedures:

* System is running BIG-IP 11.x and later.
* The remote **syslog** server(Log Collector) is accessible from your BIG-IP system on the default route domain (Domain 0) or management network, and conversely, your BIG-IP system is accessible from the remote **syslog** server.
* If you want to use a fully qualified domain name (FQDN) for the **syslog** servers, configuration of DNS servers is required.

**Method 1 : Using the configuration utility.**<br>

The Configuration utility provides a basic means of configuring the **syslog** configurations.

1. Log in to the Configuration utility.
2. Go to **System** > **Logs** > **Configuration** > **Remote Logging**.

   <img src="https://2078222076-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MMRHZBPHlLDUc8519fX%2Fuploads%2FM1QUhGTXZIydeWnw42DW%2Fe7784bde%207e95%2043f9%20b6ca%2068f5dd567c58.png?alt=media" alt="" height="305" width="680">
3. For **Remote IP**, enter the Log Collector IP address, or FQDN. (DNS server configuration required)
4. For **Remote Port**, enter the UDP port (default is 514, however please use the port provided by the team).
5. (Optional) For **Local IP**, enter the local IP address of the BIG-IP system.

   ***Note**: For BIG-IP systems in a high availability (HA) configuration, the non-floating self IP address is recommended if using a Traffic Management Microkernel (TMM) based IP address.*
6. Select **Add**.
7. Select **Update**.
8. For BIG-IP systems in a high availability (HA) configuration, perform a ConfigSync to synchronize the changes to the other devices in the device group.

**Method 2 : Using TMOS Shell.**

To configure extensive **syslog-ng** customizations, you must use the command line

1. Log in to the TMOS Shell (**tmsh**) by entering the following command:

   `tmsh`
2. To add a single remote **syslog** server, use the following command syntax:

   `modify /sys syslog remote-servers add { <name> { host <IP addr or FQDN> remote-port <port> }}`

   For example, to add Log Collector IP **10.154.210.201** with port **514** and name **mysyslog**, enter the following command:

   modify /sys syslog remote-servers add { mysyslog { host 10.154.210.201 remote-port 514 }}

   ***Note**: If you do not enter a port number, the system configures the default port number, **514**.*
3. To save the configuration, enter the following command:

   `save /sys config`

<img src="https://2078222076-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MMRHZBPHlLDUc8519fX%2Fuploads%2FL5c6i81MwfUNffPKi9G9%2F5cc19c18%20c6be%2040ea%208da7%20710eb189ecf1.png?alt=media" alt="" height="177.5" width="641">

1. For BIG-IP systems in a high availability (HA) configuration, perform a ConfigSync to synchronize the changes to the other devices in the device group.

**Reference**: <https://my.f5.com/manage/s/article/K13080>

**Video link**:

[YouTube](https://www.youtube.com/watch?v=2RQ7p-JdsD0)


# Blue Coat Proxy Logs


# To Forward Blue Coat Logs Using Web Interface

### TO FORWARD BLUE COAT LOGS USING WEB INTERFACE&#x20;

1. Log in to the GUI on Blue Coat appliance.&#x20;
2. Select Configuration > Access Logging > Logs > Upload Client.&#x20;
3. From the Log list, select the log that contains your custom format.&#x20;
4. From the Client type list, select Custom Client.&#x20;
5. Click Settings.&#x20;
6. From the Settings For list, select Primary Custom Server.&#x20;
7. In the Host field, type the IP address of your Log Collector.&#x20;
8. In the Port field, type \<port number> (Check Appendix A for default port list).&#x20;
9. Click OK.&#x20;
10. Select the Upload Schedule tab.&#x20;
11. From the Upload the access log list, select Continuously.&#x20;
12. Click Apply.&#x20;

###


# To Forward Blue Coat Proxy Logs Using CLI

### TO FORWARD BLUE COAT PROXY LOGS USING CLI&#x20;

1. At the root configure mode, Enter the command&#x20;

`syslog view`&#x20;

To view the default configuration.&#x20;

1. To change the facility, enter the command&#x20;

`syslog facility <facility>`&#x20;

1. where facility is the category which should be sent to Log Collector.&#x20;
2. To start logging to the specified facility, enter the command&#x20;

`syslog add <Log Collector IP Address>`&#x20;

1. To verify that the host and facility are correct, enter the command&#x20;

`syslog view`&#x20;

1. Confirm the changes.&#x20;


# Broadcom


# Brocade & Ruckus Switch Log Integration

**Brocade/Ruckus**

**L2 & L3 Switch**

**Log Integration Guide**

**Log Integration procedure:**

To forward logs, make the following configuration.

1. **Login to the CLI Terminal**
2. **Switch to Global Configuration mode.**

Enter the following command:

**config t**

`device# config t`

1. **Configure Syslog Forwarding**

Enter the following command:

**logging host X.X.X.X udp-port 12520**

`device(config)# logging host 10.20.100.161 udp-port 12520`

Replace X.X.X.X with Log Collector IP of specific branch with the Port Number same as above.

1. **Exit the Configuration mode.**

Type Exit


# Cavera L2 Switch

**Cavera L2 Switch**

**Log Integration Guide**

**Log Integration procedure:**

To forward logs, make the following configuration.

1. **Login to the CLI Terminal**
2. **Switch to Global Configuration mode.**

Enter the following command:

**config t**

`device# config t`

1. **Configure Syslog Forwarding**

Enter the following command:

**logging server X.X.X.X**

`device(config)# logging server 10.20.100.161`

Replace X.X.X.X with Log Collector IP of specific branch same as above.

Logging level will be automatically set by the above command.

1. **Exit the Configuration mode.**

Type Exit

`device(config)# exit`

1. **Save the configuration.**

Type write memory

`device# write memory`


# Checkpoint

Log Exporter - Check Point Log Export

Log Collector supports Log Exporter for R77.30, R80.10, R80.20 and later versions.

Installation


# R80.20

### R80.20&#x20;

Log Exporter is already integrated in version R80.20. There is no need to install dedicated package.&#x20;

| Note:​ | <ol><li>In order to preserve the Log Exporter configuration before upgrading to R80.20, please follow <a href="https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&#x26;solutionid=sk127653">sk127653 - How to backup and restore Log Exporter configuration on upgrade to R80.20</a> </li><li>In order to support exporting logs in CEF format, please install <a href="https://supportcenter.us.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&#x26;solutionid=sk137592">R80.20 Jumbo Hotfix</a> Take 5 and above. </li></ol> |
| ------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |

###


# R80.10

### R80.10&#x20;

Install this release on a R80.10 Multi-Domain Server, Multi-Domain Log Server, Security Management Server, Log Server or SmartEvent Server.&#x20;

| Note:​ | <ol><li>Log Exporter can be installed on top of R80.10 Jumbo Hotfix Take 56 and above. </li><li>This hotfix must be installed after the Jumbo, and will need to be uninstalled to upgrade to a higher Jumbo take, and then reinstalled after the newer Jumbo is in place. </li><li>Take care to install the latest Log Exporter take available for download below, in order to avoid a conflict with the Jumbo HF. </li></ol> |
| ------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |

###


# R77.30

### R77.30&#x20;

Install this release on a R77.30 Multi-Domain Server, Multi-Domain Log Server, Security Management Server, Log Server or SmartEvent Server.&#x20;

| Note:​ | Log Exporter can be installed on top of R77.30 Jumbo Hotfix Take 292 and above. |
| ------ | ------------------------------------------------------------------------------- |

\*\*This hotfix must be installed after the Jumbo, and will need to be uninstalled to upgrade to a higher Jumbo take, and then reinstalled after the newer Jumbo is in place.&#x20;

| Version | Date             | CPUSE Online Identifier                                      | CPUSE offline package |
| ------- | ---------------- | ------------------------------------------------------------ | --------------------- |
| R80.10  | 20 January 2019  | Check\_Point\_R80.10\_Log\_Exporter\_T43\_sk122323\_FULL.tgz | (TGZ)                 |
| R77.30  | 06 November 2018 | Check\_Point\_R77.30\_Log\_Exporter\_T30\_sk122323\_FULL.tgz | (TGZ)                 |

Install the hotfix using CPUSE, see [sk92449](https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=\&solutionid=sk92449\&partition=General\&product=All%22).&#x20;

Configure Log Exporter to forward Syslogs using CLI&#x20;

After applying the hot fix, the firewall will restart automatically, you have to restart the Check Point firewall, once again.&#x20;

1. Telnet/SSH the Check Point firewall and enter the below command.&#x20;

`cp_log_export add name <name> target-server <Log Collector IP Address> target-port 1514 protocol udp format cef`&#x20;

1. The new log exporter does not start automatically. To start it run:&#x20;

`cp_log_export restart name <name>`&#x20;

##


# Checkpoint Harmony Endpoint

Checkpoint Harmony Logs integration&#x20;

**To export logs from Harmony Endpoint:**&#x20;

1. Go to Endpoint Settings > Export Events.&#x20;
2. Click Add.&#x20;

&#x20;     The New Logging Service window opens.&#x20;

3. Fill in the export details:&#x20;
   1. Name - Enter a name for the exported information.&#x20;
   2. IP Address - Enter the IP Address of the target to which the logs are exported.&#x20;
   3. Protocol - Select the protocol over which to export the logs: TCP or UDP.&#x20;
   4. Format - Select the export format.&#x20;
   5. Port - Select the port 6514 to export the logs.


# Cisco


# Cisco ASA with FirePOWER services

## Cisco ASA with FirePOWER services&#x20;

Creating a Syslog Alert Response&#x20;

1.  Choose ASA Firepower Configuration > Policies > Actions > Alerts.&#x20;
2.  From the Create Alert drop-down menu, choose Create Syslog Alert.&#x20;
3.  Enter a Name for the alert.&#x20;
4.  In the Host field, enter the hostname or IP address of “Log Collector”.&#x20;
5.  In the Port field, enter the port the server uses for syslog messages. Please check Appendix A for default port list.&#x20;
6.  From the Facility list, choose a facility LOCAL7.&#x20;
7.  From the Severity list, choose a severity INFO.&#x20;
8.  Click Save.&#x20;

!\[Graphical user interface, website

Description automatically generated]\(<https://firebasestorage.googleapis.com/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MMRHZBPHlLDUc8519fX%2Fuploads%2FWZuXLuuON7wzpuhdNPoM%2Ffile.png?alt=media>)

Configuration for sending the Traffic Events&#x20;

1. Navigate to ASA Firepower Configuration > Policies > Access Control Policy&#x20;
2. Edit the access rule and navigate to logging option.&#x20;
3. Select log at Beginning and End of Connection options.&#x20;
4. Navigate to Send Connection Events to option , select Syslog, and then select a Syslog alert response.&#x20;
5. Click Save.&#x20;

!\[Graphical user interface, text, application

Description automatically generated]\(<https://firebasestorage.googleapis.com/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MMRHZBPHlLDUc8519fX%2Fuploads%2FOC5d7ECeBkIMldtAtuyw%2Ffile.jpeg?alt=media>)

 <https://www.cisco.com/c/en/us/support/docs/security/firepower-ngfw/200479-Configure-Logging-on-FTD-via-FMC.html>


# Cisco ASA

## Cisco ASA&#x20;

Cisco ASA using Command Line Interface&#x20;

1. Telnet to the ASA firewall and enter the enable mode&#x20;
2. Type the following:&#x20;

`configure terminal` \
&#x20;\
`logging enable` \
&#x20;\
`logging timestamp` \
&#x20;\
`logging trap informational` \
&#x20;\
`logging device-id {context-name | hostname | ipaddress interface_name | string text}` \
&#x20;\
`logging host interface_name syslog_ip [udp/<syslog_port>]`&#x20;

| interface\_name           | is the interface on the ASA Firewall whose logs need to be analyzed (for example: "inside" or "outside").                                                                                                                                                                                                           |
| ------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| syslog\_ip                | is the IP address of the Log Collector to which the Firewall should send the Syslogs.                                                                                                                                                                                                                               |
| udp/\<syslog\_port>       | indicates that logs will be sent using the UDP protocol, to the [configured syslog port](https://www.manageengine.com/products/firewall/help/firewall-analyzer-prerequisites.html#port) on the syslog server. If left blank, logs will be sent to the default UDP port 514. Check Appendix A for default port list. |
| hostname                  | firewall's host name (defined with the hostname configuration command)                                                                                                                                                                                                                                              |
| ipaddress interface\_name | the IP address of a specific firewall interface named interface\_name (for example: "inside" or "outside")                                                                                                                                                                                                          |
| string text               | an arbitrary text string (up to 16 characters)                                                                                                                                                                                                                                                                      |
| context-name              | in PIX 7.x or FWSM 2.x operating in multiple-context mode, the name of the firewall context can also be sent.                                                                                                                                                                                                       |

##


# Cisco VPN 3000 Concentrator

## Cisco VPN 3000 Concentrator&#x20;

Follow the below steps to configure the VPN Concentrator:&#x20;

1. Configuring Syslog Server &#x20;
2. Login to the Cisco VPN 3000 Concentrator Management console.&#x20;
3. Go to Configuration > System> Events >Syslog Servers&#x20;
4. Click the Add button&#x20;
5. In the Syslog Server text box enter the IP Address of the machine Log Collector is running.&#x20;
6. Enter the Port value. Check Appendix A for default port.&#x20;
7. Facility is Local 7&#x20;
8. Configuring Syslog Events &#x20;
9. Go to Configuration > System> Events >General&#x20;
10. For Syslog Format you can either select Original or Cisco IOS Compatible format.&#x20;
11. For Events to Syslog select Severities 1-5&#x20;
12. All other configurations are default for this page.&#x20;
13. Click Apply button&#x20;

For more information, refer the Cisco VPN Concentrator documentation.&#x20;


# Cisco IOS Switch

## Cisco IOS Switch&#x20;

Follow the below steps to configure the Cisco IOS Switch:&#x20;

1. Login to the Cisco IOS console or Telnet to the device.&#x20;
2. Change the configuration mode of the device. &#x20;

Use the following command:&#x20;

configure terminal&#x20;

1. Enable logging by using the following commands:&#x20;

`logging on`&#x20;

`logging trap informational`&#x20;

`logging <IP Address of Log Collector>`&#x20;

1. If there is a Firewall module in the IOS device, use the following command to enable audit trail. This will generate traffic information.&#x20;

`ip inspect audit-trail`&#x20;

For more information, refer the Cisco IOS Switch documentation.&#x20;

##


# Cisco ASA using ASDM

## Cisco ASA using ASDM&#x20;

* Load the ASDM.&#x20;
* Select Configuration > Device Management > Logging > Logging Setup.&#x20;

!\[Graphical user interface, text, application, email

Description automatically generated]\(<https://firebasestorage.googleapis.com/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MMRHZBPHlLDUc8519fX%2Fuploads%2FHMpW7UbL4MBDrVIhsiWa%2Ffile.jpeg?alt=media>)

* Select Enable Logging.&#x20;
* Select Logging > Logging Filters.&#x20;
* Choose the syslog-servers as Informational.&#x20;
* Select Logging > Syslog servers.&#x20;
* Click Add.&#x20;

!\[Graphical user interface, application

Description automatically generated]\(<https://firebasestorage.googleapis.com/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MMRHZBPHlLDUc8519fX%2Fuploads%2FhBT4iecWqLCN6UR4cXSE%2Ffile.jpeg?alt=media>)

* Enter the IP address of Log Collector and choose the appropriate interface. Also, ensure that you choose UDP and enter the port number 514 or 1514. Check Appendix A for default log ports.&#x20;
* Select Logging > Syslog Setup.&#x20;
* Select Include time stamp in syslogs option and scroll down to ensure the syslog IDs 302013, 302014, 302015 & 302016 are in enabled state and the logging level is set to Informational.&#x20;

### Disable Logging&#x20;

You can disable specific syslog IDs based on your requirement. &#x20;

| Note: | By selecting the check mark for the Include timestamp in syslogs option, you can add the date and time that they were generated as a field to the syslogs. |
| ----- | ---------------------------------------------------------------------------------------------------------------------------------------------------------- |

*  Select the syslogs to disable and click Edit.&#x20;
* From the Edit Syslog ID Settings window, select the Disable messages option and click OK.&#x20;
* The disabled syslogs can be viewed in a separate tab by selecting Disabled syslog IDs from the Syslog ID Setup drop-down menu.&#x20;


# Cisco Router

## CISCO ROUTER &#x20;

To configure Cisco Router to send syslog messages&#x20;

Enter the command:&#x20;

`enable`&#x20;

To enter privileged EXEC mode.&#x20;

Enter the command:&#x20;

`configure terminal`&#x20;

This will allow you to enter global configuration mode.&#x20;

Enter the command:&#x20;

`logging host`&#x20;

Replace host with Log Collector IP Address.&#x20;

Enter the command:&#x20;

`logging trap level`&#x20;

Specify the level as per requirement.&#x20;

Where:&#x20;

Emergency: 0&#x20;

Alert: 1&#x20;

Critical: 2&#x20;

Error: 3&#x20;

Warning: 4&#x20;

Notice: 5&#x20;

Informational: 6&#x20;

Debug: 7&#x20;

Enter the command:&#x20;

`logging facility local7`&#x20;

`Default facility-type value is local7.` &#x20;

Enter the command:&#x20;

`end`&#x20;

To save changes and exit global configuration mode.&#x20;

To display changes made enter command:&#x20;

`show logging`&#x20;

This displays logging configuration. Verify configuration.&#x20;

## nd Severity from the listbox.&#x20;

Near the top-left of the page, click Policy Information.&#x20;

Click Commit Changes.&#x20;


# Cisco Sourcefire

## CISCO SOURCEFIRE&#x20;

To Forward Cisco Sourcefire Ids Intrusion Alerts&#x20;

Log in to the SourceFire IDS using web interface.&#x20;

Go to Policies > Intrusion > Intrusion Policy.&#x20;

Locate the policy you want to apply and select Edit.&#x20;

Click Advanced Settings.&#x20;

In the list, locate Syslog Alerting and set it to Enabled.&#x20;

In the Logging Hosts field, type the IP address of Log Collector.&#x20;

Choose an appropriate Facility a


# Cisco Ironport

## CISCO IRONPORT&#x20;

To configure IronPort device to send syslog events, please follow the following steps:&#x20;

* Log in to Cisco IronPort user interface.&#x20;
* Select System Administration \ Log Subscriptions.&#x20;
* Click Add Log Subscription.&#x20;
* Configure the following values:&#x20;
* Log Type - Define a log subscription for both Ironport Text Mail Logs and System Logs.&#x20;
* Log Name - Type a log name.&#x20;
* File Name - Use the default configuration value.&#x20;
* Maximum File Size - Use the default configuration value.&#x20;
* Log Level - Select Information (Default).&#x20;
* Retrieval Method - Select Syslog Push.&#x20;
* Hostname - Type the IP address of Log Collector.&#x20;
* Protocol - Select UDP.&#x20;
* Facility - Use the default configuration value. This value depends on the configured Log Type.&#x20;
* Save the subscription.&#x20;


# Cisco Nexus Switch

## CISCO NEXUS SWITCH&#x20;

To forward Cisco Nexus Switch logs, make the following configuration&#x20;

Type the following command to switch to configuration mode:&#x20;

`config t`&#x20;

Type the following commands:&#x20;

`logging server <IP ADDRESS OF LOG COLLECTOR> <SEVERITY>`&#x20;

Type the following to configure the interface for sending syslog events:&#x20;

`logging source-interface loopback`&#x20;

Type the following command to save your current configuration as the start-up configuration:&#x20;

`copy running-config startup-config`&#x20;


# Cisco VPN Concentrator

## CISCO VPN CONCENTRATOR&#x20;

To configure Cisco VPN concentrator and send syslog messages&#x20;

Log in to the VPN concentrator using web interface.&#x20;

Go to Configuration > System > Events > Syslog Servers&#x20;

Select `Add`&#x20;

Enter the IP address of the “Local Collector” and choose facility level from the facility drop down menu.&#x20;

Next, return to the Syslog Server page by clicking `Add` again.&#x20;

![Cisco VPN Syslog GUI](https://firebasestorage.googleapis.com/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MMRHZBPHlLDUc8519fX%2Fuploads%2FwQUWxi2bHwu5Bms3ZNIl%2Ffile.png?alt=media)

### CONFIGURE EVENTS&#x20;

Go to Configuration > Events > System > General.&#x20;

Select the event options based on the severity to the syslog drop down menus and click Apply.&#x20;

![Cisco VPN configure event handling](https://firebasestorage.googleapis.com/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MMRHZBPHlLDUc8519fX%2Fuploads%2FZrTgU7JT67rlVwDbXSm4%2Ffile.png?alt=media)

To save changes click on the Save button.&#x20;


# Cisco Meraki Firewall

1. Open your Meraki dashboard as an administrator
2. Select the device you’d like to use
3. Select **Network-Wide**
4. Under the *Configure* Header – Select **General**
5. Scroll down to the **Reporting** Section
6. Select **“Add New Syslog Server”**
   1. Type the **IP address** of your Blumira Sensor
   2. Type port number **(Check with Deployment Support team)**.
   3. Add in **Event Log, Flows, URL**
7. Scroll to the bottom of the page and **Save Changes**


# Cisco HX220C-M5SX Log Integration

**Cisco HX220C-M5SX**\
**(Physical Server)**

**Log Integration Guide**

**Log Integration procedure:**

Cisco Hyperflex allows you to send Logs using Cisco Integrated Management Controller to a Syslog Server or Log Collector.

1. Login to the Cisco Integrated Management Controller Console and go to Chassis->Faults and Logs.

<figure><img src="https://2078222076-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MMRHZBPHlLDUc8519fX%2Fuploads%2F5mJXeHTJwexhX7u447ej%2Fimage.png?alt=media&amp;token=29e4e36e-94e0-43e0-94bf-92f34ccb82a4" alt=""><figcaption></figcaption></figure>

1. Under Faults and Logs, click on **Logging Controls**.

<figure><img src="https://2078222076-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MMRHZBPHlLDUc8519fX%2Fuploads%2FBzRh7VHbZd9IZkS6iDEt%2Fimage.png?alt=media&amp;token=daa1b92b-9f6d-4ef2-a2cf-1e3d97bf4bdb" alt=""><figcaption></figcaption></figure>

1. Under Logging Controls, **Enable Remote Syslog Server 1 or 2**.

If Remote Syslog Server 1 is already used, Enable Remote Syslog Server 2

<figure><img src="https://2078222076-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MMRHZBPHlLDUc8519fX%2Fuploads%2FgoMtgqFC1SgOOUIYxhno%2Fimage.png?alt=media&amp;token=2be48bbc-30ef-42e2-9942-12300f8ecf01" alt=""><figcaption></figcaption></figure>

Fill in the details as below.

* Hostname/IP Address : \[Log Collector IP of specific branch]
* Port : 12443
* Protocol : UDP.
* Minimum Severity to Report : Debug

<figure><img src="https://2078222076-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MMRHZBPHlLDUc8519fX%2Fuploads%2FJssFKt2ZjbU7PRpPFHld%2Fimage.png?alt=media&amp;token=93cc0ed7-506f-4807-af69-8bf20b71bf5f" alt=""><figcaption></figcaption></figure>

We have now configured Cisco Hyperflex to send logs to Log Collector.

1. To Verify the configuration, Click on Send Test Syslog to generate Test Event.

<figure><img src="https://2078222076-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MMRHZBPHlLDUc8519fX%2Fuploads%2FLLoEo85AH6TQ2dE4A8Q3%2Fimage.png?alt=media&amp;token=a6bf6c20-bb6a-4b63-8c85-db52a632fcca" alt=""><figcaption></figcaption></figure>


# Cisco L3 Switch Log Integration

**Log Integration Guide**

**Log Integration procedure:**

To forward logs, make the following configuration.

1. **Login to the CLI Terminal**
2. **Switch to Global Configuration mode.**

Enter the following command:

**config t**

`device# config t`

1. **Enable logging if it Is not enabled.**

Enter the following command:

**logging on**

`device(config)# logging on`

1. **Configure Syslog Forwarding**

Enter the following command:

**logging host X.X.X.X transport udp port 12515**

`device(config)# logging host 10.20.100.161 transport udp port 12515`

Replace X.X.X.X with Log Collector IP of specific branch with the Port Number same as above.

1. **Configure Severity level.**

Enter the following command:

**Logging trap debugging**

`device(config)# logging trap debugging`

1. **Select the Source Interface**

Enter the following command:

**Logging source-interface xxx**

`device(config)# logging source-interface vlan10`

Replace xxx with the source interface switch uses to send syslog packets.

This sets the source IP address for syslog packets that originate from the Switch. By default, packets originate from the interface closest to the destination.

1. **Exit the Configuration mode.**

Type **end**

`device(config)# end`

1. **Save the configuration.**

Type **write memory**

`device# write memory`


# Cisco L2 Switch Log Integration

**Log Integration Guide**

**Log Integration procedure:**

To forward logs, make the following configuration.

1. **Login to the CLI Terminal**
2. **Switch to Global Configuration mode.**

Enter the following command:

**config t**

`device# config t`

1. **Configure Syslog Forwarding**

Enter the following command:

**logging host X.X.X.X port 12515 severity debugging**

`device(config)# logging host 10.20.100.161 port 12515 severity debugging`

Replace X.X.X.X with Log Collector IP of specific branch with the Port Number same as above.

1. **Exit the Configuration mode.**

Type Exit

`device(config)# exit`

1. **Save the configuration**

Type write memory


# HCI\_CISCO\_HX 240C\_M5SX\_CIMS(Intersight)

**HCI CISCO HX 240C M5SX CIMS (Intersight) :**

1. Log in to Cisco Intersight with your Cisco ID and select admin role.
2. From the **Service Selector** drop-down list, select **Infrastructure Service**.

<figure><img src="https://2078222076-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MMRHZBPHlLDUc8519fX%2Fuploads%2FGjSDmnQ2Nz1xQ2INJcy4%2Fimage.png?alt=media&amp;token=e4126b70-633d-44c2-b06a-4735e896800d" alt=""><figcaption></figcaption></figure>

3. Navigate to **Configure** > **Policies**, and then click **Create Policy**.

<figure><img src="https://2078222076-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MMRHZBPHlLDUc8519fX%2Fuploads%2F76YIDnwOwuE4zgUVYCOO%2Fimage.png?alt=media&amp;token=bbd683fc-c877-4808-8b13-42f7165c2515" alt=""><figcaption></figcaption></figure>

4. Under Platform Type, Select the Platform as per the existing one.

<figure><img src="https://2078222076-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MMRHZBPHlLDUc8519fX%2Fuploads%2FShYeqGARtqVVzhgG48iR%2Fimage.png?alt=media&amp;token=28ed95e4-73ed-423c-9412-42ba30aa2cb3" alt=""><figcaption></figcaption></figure>

5. Select **Syslog**, and then click **Start**.
6. On the **General** page, configure the following parameters:

|                            |                                                                         |
| -------------------------- | ----------------------------------------------------------------------- |
| **Property**               | **Essential Information**                                               |
| **Organization**           | Select the Organization.                                                |
| **Name**                   | Enter a name for your policy.                                           |
| **Description (Optional)** | Provide a short description                                             |
| **Add Tag (Optional)**     | Enter a tag in the key:value format. For example, Org: IT or Site: APJ. |

7. On the **Policy Details** page, configure the following parameter

|                                                          |                                                                                                                                                                        |   |
| -------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------- | - |
| **Property**                                             | **Essential Information**                                                                                                                                              |   |
| **Local Logging**                                        |                                                                                                                                                                        |   |
| **Minimum Severity to Report**                           | Select the lowest severity level to report in the remote log. The severity levels are:                                                                                 |   |
| 0 Emergency                                              |                                                                                                                                                                        |   |
| 1 Alert                                                  |                                                                                                                                                                        |   |
| 2 Critical                                               |                                                                                                                                                                        |   |
| 3 Error                                                  |                                                                                                                                                                        |   |
| 4 Warning                                                |                                                                                                                                                                        |   |
| 5 Notice                                                 |                                                                                                                                                                        |   |
| 6 Informational                                          |                                                                                                                                                                        |   |
| 7 Debug                                                  |                                                                                                                                                                        |   |
| **Remote Logging - Syslog Server 1 and Syslog Server 2** |                                                                                                                                                                        |   |
| **Enable**                                               | Select this option to enable or disable the Syslog policy.                                                                                                             |   |
| **Hostname/IP Address**                                  | Enter the hostname or IP address of the Syslog server to store the Cisco IMC log. You can set an IPv4 or IPv6 address or a domain name as the remote system address.   |   |
| **Note**                                                 | If you have both IPv4 and IPv6 as the remote logging addresses, ensure to configure IPv4 and IPv6 in the Fabric Interconnect through the command-line interface (CLI). |   |
|                                                          |                                                                                                                                                                        |   |
| **Minimum Severity To Report**                           | Select the lowest severity level to report in the remote log. The severity levels are:                                                                                 |   |
| 0 Emergency                                              |                                                                                                                                                                        |   |
| 1 Alert                                                  |                                                                                                                                                                        |   |
| 2 Critical                                               |                                                                                                                                                                        |   |
| 3 Error                                                  |                                                                                                                                                                        |   |
| 4 Warning                                                |                                                                                                                                                                        |   |
| 5 Notice                                                 |                                                                                                                                                                        |   |
| 6 Informational                                          |                                                                                                                                                                        |   |
| 7 Debug                                                  |                                                                                                                                                                        |   |

8. Click **Create**.


# Cisco SF/SG 200 & 300 Series Switches

This guide outlines the steps for enabling system logs on your Cisco SF/SG 200 & 300 Series Managed Switches and forwarding them to Log Collector.

### **1. System Log Setup**

1. Log in to the web configuration utility and choose **Administration > System Log > Log Settings**. The *System Logs Settings* page opens:

![](https://2078222076-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MMRHZBPHlLDUc8519fX%2Fuploads%2FJB8RPU07d5HCWyvz4vrF%2F780cc8fb%20e5c4%204f57%20b1d6%200025c2cf15cc.avif?alt=media)

2. In the Logging field, check the **Enable** check box to enable system logs.
3. (Optional) In the Syslog Aggregator field, check the **Enable** check box to enable syslog aggregator. A Syslog Aggregator adds identical and contiguous syslog messages and traps according to the specific Max Aggregation Time value and sends it in a single message.
4. If syslog aggregator is enabled, in the Max Aggregation Time field, enter the time in seconds the syslog aggregator will accumulate syslog messages to be sent as a single message.
5. The switch keeps information about its events in two places: in RAM memory, and in Flash memory. Under RAM Memory Logging and Flash Memory Logging, check the appropriate check boxes respectively:

   • Emergency — The system is not usable.

   • Alert — Action is needed.

   • Critical — System is in critical condition.

   • Error — A system error has occurred.

   • Warning — A current or potential system condition has generated a warning.

   • Notice — The system is functioning properly, but a system notice has been generated.

   • Informational — General system and functional information.

   • Debug — Provides extremely detailed information about system events.
6. Click **Apply**.

### **2. Remote Log Servers Setup**

\
1\. Log in to the web configuration utility and choose **Administration > system log > Remote Log Servers**. The *Remote Log Server* page opens:

![](https://2078222076-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MMRHZBPHlLDUc8519fX%2Fuploads%2FiGIP6UnIpR83HDzbSzKh%2F6f27246a%209eb4%204ef6%20a05e%204414032c208a.avif?alt=media)

2. Click **Add** to set up a remote log server. The *Add Remote Log Server* window appears.

![](https://2078222076-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MMRHZBPHlLDUc8519fX%2Fuploads%2FzacQiyxl4Vvwvy63MnjN%2F93e25601%20afcc%204288%209b6a%20e474a4df3967.avif?alt=media)

3. In the Server Definition field, click one of the following radio buttons:

• By Name — The log server is defined with a name.

• By IP Address — The log server is defined with an IP address.

4. In the IP Version field, click Version 6 or Version 4 as the type of IP address of the Log server.
5. If Version 6 is chosen as the IP address in Step 4, in the IPv6 address type, click one of the following radio buttons:

   • Link Local — An IPv6 address that only identifies hosts on a single network link.

   • Global — an IPv6 address that is reachable from other networks.
6. If Link Local is chosen as the IPv6 address type in Step 5, in the Link Local Interface drop-down list, choose the appropriate interface.
7. In the Log Server IP address/Name field, enter the appropriate IP address or name that identifies the Log Collector.
8. In the Facility drop-down list, choose the facility value from which the log messages are sent to the remote server. The facility value indicates where the system log message originated from.
9. (Optional) In the Description field, enter a description of the log server.
10. n the Minimum Severity drop-down list, choose the minimum severity level of the system log messages that are sent to the server. The severity level indicates the type of log message.
11. Click **Apply**.

    ![](https://2078222076-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MMRHZBPHlLDUc8519fX%2Fuploads%2Fua6GCe9rhth9CzW4c1YG%2F71148734%20f944%2047ad%20a0e1%20fcf53c243cc5.avif?alt=media)

**Reference:** [**https://www.cisco.com/c/en/us/support/docs/smb/switches/cisco-small-business-200-series-managed-switches/smb104-manage-system-logs-on-the-200-300-series-managed-switches.html**](https://www.cisco.com/c/en/us/support/docs/smb/switches/cisco-small-business-200-series-managed-switches/smb104-manage-system-logs-on-the-200-300-series-managed-switches.html)


# Cisco SF/SG 200 & 300 Series Switches

This guide outlines the steps for enabling system logs on your Cisco SF/SG 200 & 300 Series Managed Switches and forwarding them to Log Collector.

### **1. System Log Setup**

1. Log in to the web configuration utility and choose **Administration > System Log > Log Settings**. The *System Logs Settings* page opens:

![](https://2078222076-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MMRHZBPHlLDUc8519fX%2Fuploads%2Feeyz9CqjVil12roCzzdN%2F780cc8fb%20e5c4%204f57%20b1d6%200025c2cf15cc.avif?alt=media)

2. In the Logging field, check the **Enable** check box to enable system logs.
3. (Optional) In the Syslog Aggregator field, check the **Enable** check box to enable syslog aggregator. A Syslog Aggregator adds identical and contiguous syslog messages and traps according to the specific Max Aggregation Time value and sends it in a single message.
4. If syslog aggregator is enabled, in the Max Aggregation Time field, enter the time in seconds the syslog aggregator will accumulate syslog messages to be sent as a single message.
5. The switch keeps information about its events in two places: in RAM memory, and in Flash memory. Under RAM Memory Logging and Flash Memory Logging, check the appropriate check boxes respectively:

   • Emergency — The system is not usable.

   • Alert — Action is needed.

   • Critical — System is in critical condition.

   • Error — A system error has occurred.

   • Warning — A current or potential system condition has generated a warning.

   • Notice — The system is functioning properly, but a system notice has been generated.

   • Informational — General system and functional information.

   • Debug — Provides extremely detailed information about system events.
6. Click **Apply**.

### **2. Remote Log Servers Setup**

\
1\. Log in to the web configuration utility and choose **Administration > system log > Remote Log Servers**. The *Remote Log Server* page opens:

![](https://2078222076-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MMRHZBPHlLDUc8519fX%2Fuploads%2F95RSIh1gA4heAAcutGxd%2F6f27246a%209eb4%204ef6%20a05e%204414032c208a.avif?alt=media)

2. Click **Add** to set up a remote log server. The *Add Remote Log Server* window appears.

![](https://2078222076-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MMRHZBPHlLDUc8519fX%2Fuploads%2FdypC5p9Uug4mDLOlOqqn%2F93e25601%20afcc%204288%209b6a%20e474a4df3967.avif?alt=media)

3. In the Server Definition field, click one of the following radio buttons:

• By Name — The log server is defined with a name.

• By IP Address — The log server is defined with an IP address.

4. In the IP Version field, click Version 6 or Version 4 as the type of IP address of the Log server.
5. If Version 6 is chosen as the IP address in Step 4, in the IPv6 address type, click one of the following radio buttons:

   • Link Local — An IPv6 address that only identifies hosts on a single network link.

   • Global — an IPv6 address that is reachable from other networks.
6. If Link Local is chosen as the IPv6 address type in Step 5, in the Link Local Interface drop-down list, choose the appropriate interface.
7. In the Log Server IP address/Name field, enter the appropriate IP address or name that identifies the Log Collector.
8. In the Facility drop-down list, choose the facility value from which the log messages are sent to the remote server. The facility value indicates where the system log message originated from.
9. (Optional) In the Description field, enter a description of the log server.
10. n the Minimum Severity drop-down list, choose the minimum severity level of the system log messages that are sent to the server. The severity level indicates the type of log message.
11. Click **Apply**.

    ![](https://2078222076-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MMRHZBPHlLDUc8519fX%2Fuploads%2FPJO59UlCvwZk9jaIkRh7%2F71148734%20f944%2047ad%20a0e1%20fcf53c243cc5.avif?alt=media)

**Reference:** [**https://www.cisco.com/c/en/us/support/docs/smb/switches/cisco-small-business-200-series-managed-switches/smb104-manage-system-logs-on-the-200-300-series-managed-switches.html**](https://www.cisco.com/c/en/us/support/docs/smb/switches/cisco-small-business-200-series-managed-switches/smb104-manage-system-logs-on-the-200-300-series-managed-switches.html)


# Citrix


# Citrix Access Gateway

## CITRIX ACCESS GATEWAY&#x20;

Log in to your Citrix Access Gateway web interface&#x20;

Click the Access Gateway Clustertab&#x20;

Select Logging/Settings&#x20;

In the Server field, type the IP address of Log Collector.&#x20;

From the Facility list, select a syslog facility level.&#x20;

In the Broadcast interval (mins), type 0 to continuously forward syslog events.&#x20;

Click Submit to save changes.&#x20;

##


# DarkTrace

## Configuring DarkTrace IDS Syslog &#x20;

To configure Darktrace to send Syslog to the BluSapphire Log Collector, you must be a Darktrace administrator with access to the user interface. &#x20;

1\. Log in to the Darktrace interface. &#x20;

2\. Expand the top left menu and select Admin, a second menu appears. &#x20;

3\. Select the System Config page.&#x20;

![](https://firebasestorage.googleapis.com/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MMRHZBPHlLDUc8519fX%2Fuploads%2F0OczJyPyhbzxsvNptnzl%2Ffile.jpeg?alt=media)

4\. In the “Alerting” section, click the Verify Alert Settings button. &#x20;

5\. In “JSON Syslog Alerts,” set the field to True. &#x20;

6\. Set the JSON Syslog server to the IP address of the “Log Collector”. &#x20;

7\. Set the JSON Syslog server port \<port>. Check Appendix A for default port.&#x20;

8\. Set “JSON Syslog TCP Alerts” to True.&#x20;

![](https://firebasestorage.googleapis.com/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MMRHZBPHlLDUc8519fX%2Fuploads%2FhGO1SsGWaxM7gUiFCK5s%2Ffile.jpeg?alt=media)


# Dell


# Dell EMC Switch

**Log Integration Guide**

**Log Integration procedure:**

To forward logs, make the following configuration.

1. **Login to the CLI Terminal**
2. **Switch to Global Configuration mode.**

Enter the following command:

**config t**

`device# config t`

1. **Enable Logging**

Enter the following command:

**logging enable**

`device# logging enable`

1. **Configure Syslog Forwarding**

Enter the following command:

logging server X.X.X.X udp 12312 severity log-debug

`device(config)# logging server 10.20.100.161 udp 12312 severity log-debug`

Replace X.X.X.X with Log Collector IP of specific branch with the Port Number same as above.

1. **Exit the Configuration mode.**

Type **exit**

`device(config)# exit`

1. **Save configuration changes**

Type **copy running-config startup-config**


# Dell Powervault ME4 & ME5 Series

**Log Integration Guide**

**Log Integration procedure:**

To forward logs, make the following configuration.

1. **Login to the CLI Terminal**
2. **Configure Syslog Forwarding**

Enter the following command:

`# set syslog-parameters notification-level info host 10.23.100.161 host-port 12422`

Replace 10.23.100.161 with Log Collector IP of specific branch with the Port Number same as above.

<figure><img src="https://2078222076-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MMRHZBPHlLDUc8519fX%2Fuploads%2F5YnhXfRxNipCKd36yI4M%2Fimage.png?alt=media&amp;token=91d3ddc8-ce1e-4a81-9a3a-ab851de1eb45" alt=""><figcaption></figcaption></figure>

1. **Verify the configuration.**

Enter the following command:

`# show syslog-parameters`

<figure><img src="https://2078222076-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MMRHZBPHlLDUc8519fX%2Fuploads%2FjJyN9WYNrb4BMjo20fws%2Fimage.png?alt=media&amp;token=1c1be7cd-ba1c-4704-accd-1f58737e5532" alt=""><figcaption></figcaption></figure>




---

[Next Page](/llms-full.txt/1)