Skip to main content

ARCHITECTURE OVERVIEW

Sandworm Platform Architecture

How eleven security tools, 22 microservices, one event bus, and one identity model compose into a platform that detects, investigates, and responds without manual intervention.

Platform Overview

Sandworm is eleven purpose-built security tools backed by 22 microservices. The products cover every attack surface — cloud posture (CloudGuard), SIEM and UEBA (Sandworm SIEM), NGFW / WAF / IPS / DDoS (Stillsuit), EDR (Sandworm EDR), SASE (Sandworm SASE), breach-and-attack simulation (Sandworm BAS), supply-chain security (Sandworm SCA), AI and LLM security (Sandworm AI Security), SOAR (Elm), threat intelligence (Sight), and anti-social-engineering (Truthsayer). A unified portal and the Mendicant AI run across all of them.

The architectural property that makes this a platform rather than a portfolio is that every service reads and writes one canonical event envelope, every token is issued by one auth-service under RS256, and every cross-product action travels one event bus. There are no per-integration data translators, no per-integration RBAC models, and no per-integration alert pipelines. Capabilities compose by design.

The Eleven Products

Truthsayer (anti-social-engineering). Real-time detection of phishing, pretexting, and manipulation attempts across email, messaging, and voice channels. Delivers verdict + evidence citations directly to the operator console.

CloudGuard (CNAPP). Continuous cloud-native application protection across AWS, Azure, and GCP — misconfiguration detection, workload protection, and compliance benchmarking (SOC 2, HIPAA, PCI DSS, ISO 27001) with auto-remediation. The 3D attack-graph visualization shows blast-radius paths in real time.

Sandworm SIEM (SIEM + UEBA). Ingests security events from all 300 connectors, applies MITRE ATT&CK-mapped detection rules (Sigma-compatible), and runs behavioral baselines that detect anomalies signature rules cannot see. UEBA materialized views in ClickHouse give sub-second baseline lookups at scale.

Stillsuit (NGFW / WAF / IPS / DDoS). Five enforcement modes — packet filter, stateful inspection, NGFW with App-ID and deep-packet inspection, Layer 7 WAF, and signature-based IPS — driven by one rule engine. Policies are defined as code and deployed through CI/CD.

Sandworm EDR (EDR). Continuous process monitoring, YARA rule evaluation, and behavioral analysis across Windows, macOS, and Linux. Network isolation executes in seconds when a compromise is confirmed.

Sandworm SASE (SASE). ZTNA, SWG, CASB, and DLP in one identity-aware edge. Every connection verifies device health, user identity, and posture before granting access — no VPN-style implicit trust.

Sandworm BAS (breach-and-attack simulation). Continuous adversary simulation against your live environment, mapped to MITRE ATT&CK, so gaps are found before attackers find them.

Sandworm SCA (supply-chain security). Dependency graph analysis, SCA, and SBOM generation with continuous monitoring for new CVEs against pinned versions. Signs artifacts with the platform's Ed25519 attestation chain.

Sandworm AI Security (AI / LLM security). Prompt-injection detection, jailbreak monitoring, model-output scanning, and access-control enforcement for AI workloads. Covers both first-party deployments and third-party API integrations.

Sight (threat intelligence). Federated threat-intel feeds aggregated under epsilon-differential-privacy guarantees, searchable via Vespa across all products. IOC types: file hashes, IPs, domains, JA3 fingerprints, YARA rules.

Elm (SOAR). Orchestrates automated response playbooks across all other products. Full investigation lifecycle with human-override at every decision gate, case outcomes tracked for analyst feedback loops.

Event Bus and OCSF Data Plane

Every service in the platform produces and consumes events on NATS JetStream. JetStream provides durable, at-least-once delivery with consumer group semantics, so no event is dropped during traffic spikes and independent services can replay any window of history without coordination. The bus is the single coupling point between products — services do not call each other directly.

All events are normalized to the Open Cybersecurity Schema Framework (OCSF) 1.3 before they enter the bus. This is a hard contract, not a best-effort suggestion. An authentication event from Okta and an authentication event from Entra ID arrive at every downstream consumer with the same field names, the same enum values, and the same timestamp precision. Detection rules, response playbooks, and the triage agent are written once and work against every data source.

Persistence uses three complementary stores: PostgreSQL per-product schemas for relational state (configuration, RBAC, investigation records), ClickHouse for high-throughput time-series event analytics (UEBA projections, search indexes, materialized aggregations), and Vespa for universal cross-product full-text and semantic search. Redis handles session state, rate limiting, and real-time pub/sub for WebSocket delivery.

Identity Model

A single auth-service issues all tokens. It holds the RS256 private signing key exclusively; every other service verifies tokens against the public key. A compromised product service cannot forge tokens for other services — the cryptographic boundary is architectural, not policy.

JWT claims encode both standard RBAC roles (admin / analyst / viewer) and a capability vocabulary that maps to fine-grained product permissions. Trust tier (Platform / Sovereign) is encoded in the token and enforced at every service boundary, enabling the same binary to serve a fully cloud-managed tenant and an air-gapped sovereign deployment without configuration branching.

The sandworm_staff role gates internal platform operations through a dedicated audit trail, replacing environment-variable hacks with a real privilege model. All role grants and revocations are hash-chained in the same audit log used for triage attestations.

Autonomous SOC Layer

The triage agent runs a bounded tool-loop against every incoming alert: a hard ceiling of ten tool calls, sixty seconds of wall time, and thirty thousand tokens per invocation. Every conclusion the agent reaches must be supported by evidence already present in the retrieved artifacts — if the evidence does not support the conclusion, the agent cannot produce it. Hallucinated verdicts are structurally prevented, not filtered after the fact.

Each auto-close decision is hash-chained into an audit record and bundled into a monthly Ed25519-signed triage attestation. The signing scheme is on a migration path to hybrid Ed25519 + ML-DSA-65 (NIST FIPS 204) for post-quantum durability. Tenants can verify any attestation offline using the sandworm CLI against the public key served by the trust portal — no round-trip to Sandworm required.

Autonomous response actions (session revocation, IP block, endpoint isolation, user quarantine) run under per-tenant policy gates. Each action supports dry-run mode and per-action rollback. Default-on actions (notify, revoke session, quarantine user) activate after a confidence threshold the operator configures; destructive actions (block IP, isolate host) are default-off and require explicit opt-in.

Mendicant AI

Mendicant is Sandworm's in-house AI engine — in active development, written in C++ without PyTorch or TensorFlow as runtime dependencies, designed to operate in sovereign and air-gapped environments. GPU acceleration is hardware-agnostic and runs across all major GPUs (AMD, NVIDIA, and Apple Silicon), so Mendicant is built to operate where dependency audits and export controls make PyTorch-family runtimes impractical or prohibited. Competing AI-native security products built on Python ML stacks cannot reach these environments.

Mendicant powers the per-product AI panels visible in every product UI. The advanced capabilities currently listed on the roadmap are in active development; we do not claim frontier-scale model performance today. What ships is a self-contained inference runtime that runs entirely within the customer's trust boundary — no training data, telemetry, or model weights leave the deployment.

Federated Learning with Formally Verified Privacy

Tenants share UEBA behavioral baselines and threat-intel IOCs through a federated learning protocol. No raw event data crosses tenant boundaries. Contributions are noised under an epsilon-differential-privacy guarantee before aggregation, providing a mathematically provable upper bound on what an adversary can infer about any individual tenant's data from the shared model.

The DP correctness guarantee is validated by an automated test suite that runs Kolmogorov-Smirnov tests against the noise distribution (p = 0.63 on baseline), a membership-inference adversary simulation (advantage 0.51 vs. theoretical maximum 0.68), gradient inversion resistance, and bounded-influence model-poisoning checks. To our knowledge, Sandworm is the first commercial security product to ship federated learning with formally verified privacy properties validated by statistical tests on every build.

Scale and Observability

ClickHouse handles the OCSF event analytics workload. UEBA materialized views with projections reduce query time by an estimated 100–1000x compared to row-scan approaches on the same data. The ingest pipeline is designed for millions of events per second per node; horizontal scaling adds capacity without architectural changes.

All services emit OpenTelemetry traces using W3C trace-context propagation. A trace that starts at the API gateway carries the same trace-id through every microservice it touches, so a slow triage decision can be decomposed into the exact tool calls, database queries, and network hops that contributed to the latency. Prometheus metrics and Alertmanager routing cover operational alerting; Grafana dashboards for each service are provisioned automatically on deploy.

The platform is multi-region today (us-east-1 and eu-west-1), architected for N regions. Sight and Platform trust tiers run a global control plane with regional data planes. Sovereign tier runs fully regional — no data transits region boundaries under any circumstances.

Deployment

The 22 backend services deploy via Docker Compose (development) or Helm (production Kubernetes). All eleven product UIs ship as native desktop applications for Windows, Linux, and macOS via Electron, so operators work from a signed, locally-installed binary rather than a browser tab that requires a stable internet connection to the control plane.

An nginx API gateway handles TLS termination, rate limiting, and path-based routing to each service. The trust portal SPA serves a public, unauthenticated view of connector counts, signing keys, and recent attestations — cryptographic proof of platform state that any customer or auditor can verify without a Sandworm account.

See the platform in action.

Get Started