# SpectraDetect Central SDM — Federated Manager Monitoring and YARA Policy Sync

> Deploy Central Spectra Detect Manager (CSDM) to aggregate dashboards and sync YARA policies across federated OVA and Kubernetes SDM instances via M2M token auth.

The Central Spectra Detect Manager (CSDM) is a management overlay that operates on top of deployed SDM instances. It provides a high-level, aggregated operational dashboard across all deployed SDM environments and ensures consistent security policies are maintained across the entire federated SDM deployment topology.

## Overview

The current Spectra Detect Manager (SDM) implementation supports both Open Virtual Appliance (OVA) and monolith microservice deployment models, but cannot manage both simultaneously within a single SDM instance. This limitation arises because the configuration switches that govern the instance's deployment behavior are implemented as global parameters.

The CSDM addresses this limitation by providing:

- **Centralized monitoring**: Aggregated operational dashboard across all deployed SDM environments
- **Policy synchronization**: Consistent YARA rule distribution across the entire federated SDM deployment topology
- **Multi-deployment support**: Ability to manage both OVA and Kubernetes deployments from a single interface, supporting migration from legacy deployment models

### What Central SDM does not do

The CSDM operates as a monitoring and YARA rule management plane. It does not replace the Spectra Detect Manager for day-to-day configuration tasks. The following operations remain on each local SDM:

- Connector configuration (ingress and egress)
- User management and access control
- Quota settings
- Classification change notifications
- Central Configuration settings

Local SDMs continue to serve as the only integration point for Worker and Spectra Analyze appliances. The CSDM is not a direct integration endpoint.

## Requirements

- All local SDMs registered with the Central SDM must run version 5.7.2 or later
- OpenID Connect (OIDC) authentication is strongly recommended for Single Sign-On (SSO) functionality

## Architecture

The CSDM uses a centralized approach where a single SDM instance manages all deployments, providing a unified view over the entire system while respecting the specifics of different deployment types. The CSDM transparently aggregates groups from different environments.

### Design approach

The CSDM architecture is based on an API-driven model where the CSDM acts as a lightweight orchestrator rather than a complete data repository. It relies on APIs to communicate with local SDMs, sending requests to relevant instances when information is needed or changes must be made. Each local SDM remains the true source of its own data.

All communication from the CSDM to local SDMs is initiated by the CSDM. This design simplifies network configuration and prevents the need for complex, direct connections between components.

### Local Spectra Detect Manager registration

Local Spectra Detect Manager (SDM) instances are registered with the Central SDM through configuration. This registration specifies the necessary parameters for the SDM's integration into the broader architecture.

### Data ingestion and M2M communication

The Central SDM collects operational data and telemetry from the registered local SDMs using the standard SDM API. Authentication for this Machine-to-Machine (M2M) communication is secured through a token-based mechanism. The CSDM operates solely as a centralized monitoring and management plane only.

### Communication patterns

#### API requests

The CSDM sends API requests to local SDMs when configuration changes or information retrieval is needed. For Kubernetes deployments, a Manager component serves as a proxy between the CSDM and individual appliances. The appliance ID is included as part of the request, and the Manager forwards the request to the specific hub or worker.

#### Appliance events

Events from appliances are collected by local SDMs and stored in persistent storage. The CSDM pulls events from local SDMs on a regular polling schedule, reversing the typical communication direction for event handling.

### YARA rule synchronization

#### Centralized rule authority

The CSDM maintains the master copy and serves as the single source of truth for all YARA rules. The CSDM is responsible for aggregating and resolving rule conflicts from all connected Detect and Analyze appliances.

#### Distribution mechanism

The CSDM pushes YARA rules to local SDMs. For Kubernetes deployments, local SDMs serve as repositories from which workers pull rules. This maintains the standard worker behavior while ensuring centralized rule management.

#### Upgrade path and initial data seeding

An existing cluster or set of clusters can be switched to the CSDM. During this transition, the existing single SDM is temporarily designated as the initial source, and its active YARA rules are imported into the CSDM repository. After import, all local SDMs are required to use the YARA rules managed by the CSDM.

#### Request forwarding

Spectra Analyze appliances continue to direct requests to their respective local SDMs. However, the local SDMs are configured to forward all YARA-related requests from both Spectra Analyze appliances and Workers to the CSDM for centralized processing. Sample-specific operations like egress configuration and retro hunting remain local.

Worker synchronization is also forwarded to CSDM. Synchronization status is resolved by local SDM by fetching the rules versions from CSDM and comparing them with Workers' statuses.

## Configuration

### Central SDM

The Central SDM (CSDM) pulls operational telemetry from local SDM instances. Local SDM discovery information is configured in the `multiRegion` section of the CSDM's ConfigMap. Local SDMs are enumerated here, and the overall multi-region polling feature is activated by setting the `enabled` flag to true.

```yaml
multiRegion:
  enabled: true
  initialYaraSyncPullId: vm-1
  sdmList:
    - id: vm-1
      name: "OVA First"
      url: https://10.200.1.1
      type: "ova"
    - id: vm-2
      name: "OVA Second"
      url: https://10.200.2.2/
      type: "ova"
    - id: k8s-2
      name: "AWS Kubernetes Third"
      url: "https://third.detect-dev.reversinglabs.com/"
      type: "kubernetes"
    - id: k8s-1
      name: "AWS Kubernetes Fourth"
      url: "https://fourth.detect-dev.reversinglabs.com/"
      type: "kubernetes"
```

#### Configuration parameters

- **enabled**: Activates or deactivates Central SDM multi-region polling
- **initialYaraSyncPullId**: Specifies which local SDM environment serves as the initial source of YARA rules. This must match one of the `id` values in the `sdmList`
- **sdmList**: Defines all local SDMs that the Central SDM monitors
  - **id**: Internal identifier for the SDM (used by APIs and UI routing)
  - **name**: Display name shown in the Central SDM UI
  - **url**: Base URL of the local SDM
  - **type**: Deployment type (`ova` or `kubernetes`)

#### Initial YARA rule synchronization

When configuring Central SDM, exactly one environment is designated as the initial YARA rule source via the `initialYaraSyncPullId` parameter. This environment's Spectra Analyze appliances should contain the YARA rulesets that will be distributed to all other environments.

All other Spectra Analyze appliances must start without existing rulesets. They will receive their initial rulesets through synchronization from the designated source environment. After the initial synchronization is complete, the Central SDM maintains a consistent ruleset across all environments.

### Local SDM

The local Spectra Detect Manager (SDM) generally operates independently of the CSDM. The exception to this independence is the YARA rule synchronization process. The local SDM assumes a simple consumer role, exclusively fetching the master YARA rule set from the central CSDM.

This behavior is configured exclusively on the CSDM side via an API operation. Refer to the Central SDM API documentation for endpoint details. This design decision ensures compatibility with deployment environments, such as OVA-based clusters, where configuration by a ConfigMap is not available.

Local SDMs are registered at the Central SDM. No separate configuration on each local SDM is required beyond standard YARA synchronization with Spectra Analyze and workers.

## Using Central SDM

### Authentication

Authentication for the Central SDM is configured to be consistent with the approach used for the local Spectra Detect Manager (SDM) instances. It is strongly recommended that OpenID Connect (OIDC) be deployed as the primary authentication mechanism. Using OIDC enables Single Sign-On (SSO), allowing users to seamlessly transition between the CSDM interface and local SDM management consoles without requiring re-authentication.

For machine-to-machine communication, local SDMs are authenticated with the CSDM using token-based authentication. Workers are authenticated with their local SDM instances as needed.

### Landing page

The UI of the CSDM is similar to the regular SDM UI, but with reduced functionality. Most of it is located on the single, initial screen. On the left side, it shows a list of the configured SDMs together with their type icon (VM/Kubernetes), name, and status.

![image](./images/CSDM.png)

SDM statuses are:

- **Unknown**: Before status is known
- **Online**: Everything is operating normally
- **Degraded**: Some hubs or workers are down
- **Error**: Some component reported an error
- **Offline**: Secondary unavailable
- **Maintenance**: Maintenance or restart in progress
- **Unauthorized**: Invalid primary authentication configuration

### Appliances tab

The Appliances tab on the SDM-CM interface largely mirrors the core status presentation found in a standalone local SDM. However, it incorporates CSDM specific controls which act as a centralized gateway to manage individual instances.

Added controls:

- **Manage button**: Launches the UI of the specific local SDM in a new browser tab. This is an authenticated launch (preferably via SSO) for direct configuration and troubleshooting.

### YARA synchronization

The overview screen provides a granular status display, detailing the current sync state for each appliance. Possible synchronization states include:

- **InSync**: The local SDM has successfully fetched and applied the latest rule set
- **OutOfSync**: The local SDM is using an older version of the rules
- **Error**: The last attempted synchronization failed
- **Unavailable**: The CSDM cannot establish communication with the local SDM endpoint
- **PendingNew**: A new rule set is available on the CSDM-CM, awaiting local SDM retrieval
- **Disabled**: Synchronization for this local SDM has been administratively deactivated
- **NoRules**: The local SDM has not yet received any rules from the CSDM

## Upgrading to Central SDM

Upgrading from a single existing local SDM to Central SDM is the supported migration path. The process involves designating an existing SDM as the initial YARA rule source and importing its active rules into the Central SDM.

### Migration considerations

- All SDMs in a Central SDM deployment share the same YARA rules
- The upgrade requires a maintenance window during which YARA synchronization is paused and rules are migrated
- Environments with multiple pre-existing SDMs that have independent rulesets require manual alignment before migration

### Migration procedure

1. Prepare the existing SDM that will serve as the initial rules source:
   - Place the SDM into maintenance mode
   - Stop YARA synchronization between Spectra Analyze and the SDM
   - Export active YARA rules from this SDM

2. Import rules into the Central SDM

3. Configure the local SDM to consume rules from the Central SDM

4. Re-enable synchronization (Central SDM to local SDM to workers)

5. Add additional SDMs to the Central SDM configuration. These will automatically adopt the centralized ruleset

## Limitations and considerations

### Functional scope

The Central SDM UI does not include the following features, which remain available only on each local Spectra Detect Manager instance:

- Central Configuration page
- Connector settings (ingress and egress configuration)
- Classification change notifications
- Local user and access management

### Operational considerations

- The Central SDM does not push configuration changes to local SDMs. It serves as a monitoring and YARA rule authority only
- If you need to decommission the Central SDM or remove an instance from it, coordinate this change with support to avoid interruptions in rule management
- All connected SDMs must share a single, unified YARA ruleset managed by the Central SDM
