Security Architecture

​

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:

​

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 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 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 — Encryption, classification, and secrets management
• Authentication — MFA, SSO, and session management
• Supply Chain Security — Container signing and build verification
• Hardening Guide — Deployment hardening recommendations