> ## Documentation Index > Fetch the complete documentation index at: https://docs.casebender.com/llms.txt > Use this file to discover all available pages before exploring further. # Security Architecture > CaseBender's Zero Trust architecture, service isolation, network segmentation, and multi-tenant security design. ## Zero Trust Architecture CaseBender implements a Zero Trust security model aligned with NIST SP 800-207. No service, user, or device is implicitly trusted regardless of network location. ### Core Principles 1. **Verify Explicitly**: Every request is authenticated and authorized based on all available data points — identity, device health, location, service identity, and data classification 2. **Least Privilege Access**: Users and services receive the minimum permissions required for their function, with just-in-time elevation for privileged operations 3. **Assume Breach**: The architecture assumes any component can be compromised and limits blast radius through segmentation and isolation ### Device Trust Assessment Every client device connecting to CaseBender is assessed for trust level: | Trust Level | Criteria | Access Granted | | ------------- | ------------------------------------------------------------------ | -------------------------------------------------- | | **Full** | Managed device, up-to-date OS, EDR active, compliant configuration | All operations including sensitive data | | **Elevated** | Known device, recent OS, security software present | Standard operations, restricted sensitive data | | **Standard** | Authenticated user, basic device info available | Read operations, limited write access | | **Reduced** | Unknown device or outdated security posture | Read-only access, step-up required for any changes | | **Untrusted** | Failed device checks or suspicious indicators | Access denied, security alert generated | ### Mutual Service Authentication Microservices within CaseBender authenticate to each other using HMAC-based mutual authentication: * Each service has a unique identity and signing key * Every inter-service request includes a cryptographic signature * Receiving services verify the signature before processing * Replay attacks are prevented with timestamp-based nonce validation * Key rotation is automated and does not require service restarts ### Step-Up Authentication Sensitive operations require re-authentication regardless of existing session validity: * **Bulk operations**: Deleting or modifying more than 10 entities * **Configuration changes**: Security settings, integration credentials, RBAC policies * **Privileged access**: PAM elevation requests, role assignments * **Data export**: Bulk data exports, audit log downloads * **Administrative actions**: User management, organization settings ## Service Architecture CaseBender is composed of isolated microservices, each with a single responsibility: ### Service Inventory | Service | Purpose | Exposed Ports | External Access | | ---------------------- | --------------------------------------------------- | ------------- | ----------------------- | | **web** | Next.js application server, UI, and tRPC API | 3000 | Yes (via reverse proxy) | | **api** | RESTful API for external integrations | 4000 | Yes (via reverse proxy) | | **worker** | Background job processing (alerts, enrichment, SLA) | None | No | | **ingestion** | Alert ingestion from external sources | 4100 | Yes (via reverse proxy) | | **workflow-processor** | Playbook and workflow execution | None | No | | **misp-processor** | MISP threat intelligence processing | None | No | | **search-sync** | Elasticsearch synchronization | None | No | ### Service Isolation * Each service runs in its own container with a dedicated non-root user * Services that do not need external access have no exposed ports * Inter-service communication uses authenticated internal channels * Each service has its own resource limits (CPU, memory) * Container images use minimal Alpine Linux base images to reduce attack surface ## Network Security ### Segmentation CaseBender's network architecture separates concerns into distinct zones: * **Public Zone**: Reverse proxy / load balancer (the only externally accessible component) * **Application Zone**: Web, API, and ingestion services (accessible only from public zone) * **Processing Zone**: Worker, workflow-processor, misp-processor, search-sync (no external access) * **Data Zone**: PostgreSQL, Redis, Elasticsearch (accessible only from application and processing zones) ### Communication Security * All external traffic requires TLS 1.3 (TLS 1.2 minimum with strong cipher suites) * Inter-service communication uses mutual TLS or HMAC authentication * Database connections are encrypted with SSL certificates * Redis connections use AUTH and TLS * Elasticsearch connections use API key authentication over TLS ### Rate Limiting CaseBender implements multi-layer rate limiting: * **Global**: Protects the entire platform from volumetric attacks * **Per-API-Key**: Tier-based limits (Standard, Professional, Enterprise) * **Per-Endpoint**: Sensitive endpoints (login, password reset) have stricter limits * **Sliding Window**: Prevents burst attacks while allowing legitimate traffic patterns ## Multi-Tenant Security ### Tenant Isolation CaseBender supports multi-tenant deployments with strict data isolation: * **Database-Level**: Every query is scoped to the tenant's `organizationId` — there is no way to query across tenants * **Application-Level**: Middleware enforces tenant context on every request before it reaches business logic * **API-Level**: API keys are scoped to a specific tenant and cannot access other tenants' data * **Search-Level**: Elasticsearch indices are tenant-scoped with filtered aliases ### TLP Classification The Traffic Light Protocol (TLP) provides an additional layer of data access control: | TLP Level | Visibility | Use Case | | -------------------- | ------------------------------------- | --------------------------------------------------- | | **TLP:RED** | Named recipients only | Active incident details, threat actor attribution | | **TLP:AMBER+STRICT** | Organization only, restricted sharing | Vulnerability details, internal investigation notes | | **TLP:AMBER** | Organization and clients | Threat intelligence, remediation guidance | | **TLP:GREEN** | Community-wide | General security advisories, best practices | | **TLP:CLEAR** | Unrestricted | Public information, published CVEs | TLP classifications propagate automatically from cases to child entities (alerts, tasks, observables) and are enforced at the query level. ## Container Security ### Build-Time Hardening Every CaseBender container image follows security best practices: * **Multi-Stage Builds**: Build dependencies are not included in production images * **Non-Root Users**: All services run as dedicated non-root users * **Minimal Base Images**: Alpine Linux to minimize attack surface * **Pinned Dependencies**: All system packages and tools are version-pinned * **Frozen Lockfiles**: `pnpm install --frozen-lockfile` ensures reproducible builds * **No Secrets in Images**: All secrets are injected at runtime via environment variables or secrets providers ### Runtime Hardening * Read-only root filesystem (where supported) * Dropped Linux capabilities * Resource limits (CPU, memory, file descriptors) * Health check endpoints for orchestrator monitoring * Graceful shutdown handling for zero-downtime deployments ## Related Documentation * [Data Protection](/en/security/data-protection) — Encryption, classification, and secrets management * [Authentication](/en/security/authentication) — MFA, SSO, and session management * [Supply Chain Security](/en/security/supply-chain) — Container signing and build verification * [Hardening Guide](/en/security/hardening-guide) — Deployment hardening recommendations