Encryption
Data at Rest
All data stored by CaseBender is encrypted at rest:- Database: PostgreSQL Transparent Data Encryption (TDE) or filesystem-level encryption (dm-crypt/LUKS)
- Field-Level Encryption: Sensitive fields (API keys, integration credentials, PII) are encrypted at the application level using AES-256-GCM before storage
- Key Versioning: Encryption keys are versioned, allowing rotation without re-encrypting all data immediately
- Backup Encryption: Database backups inherit encryption from the underlying storage
Data in Transit
All network communication is encrypted:- External Traffic: TLS 1.3 required (TLS 1.2 minimum with AEAD cipher suites only)
- Inter-Service: Mutual TLS or HMAC-authenticated channels
- Database Connections: SSL/TLS with certificate verification
- Redis Connections: TLS with AUTH
- Elasticsearch: API key authentication over TLS
Encryption Key Rotation
CaseBender supports automated encryption key rotation without downtime:- New key versions are created and activated automatically on schedule
- Existing data continues to decrypt with the previous key version
- Background re-encryption progressively migrates data to the new key
- Progress tracking shows re-encryption status across all encrypted fields
- Old key versions are retained until all data is migrated, then securely destroyed
Data Classification
CaseBender includes an automatic data classification engine that categorizes data based on sensitivity:Classification Levels
| Level | Description | Handling Requirements |
|---|---|---|
| Restricted | Highly sensitive data (credentials, PII, threat actor attribution) | Field-level encryption, strict access control, audit logging on every access |
| Confidential | Internal security data (case details, investigation notes) | Encrypted storage, role-based access, audit logging |
| Internal | Operational data (metrics, team assignments, workflow configs) | Standard access controls, periodic review |
| Public | Non-sensitive data (published CVEs, public advisories) | No special handling required |
Automatic Classification
- Rule Engine: Configurable rules that classify entities based on content patterns, source, severity, and TLP level
- Pattern Detection: Scans for PII patterns (SSN, credit card numbers, email addresses) and auto-classifies accordingly
- TLP Mapping: TLP classifications automatically map to data classification levels
- Propagation: Classification levels propagate from parent to child entities (case to alerts, alerts to observables)
- Review Workflow: Classification changes above a threshold require human review and approval
Secrets Management
CaseBender provides a centralized secrets management system with provider abstraction, so your deployment can use whichever secrets backend your organization standardizes on.Supported Providers
| Provider | Use Case | Features |
|---|---|---|
| Environment Variables | Development, simple deployments | Zero dependencies, easy setup |
| HashiCorp Vault | Enterprise on-premise | Dynamic secrets, lease management, audit logging |
| AWS Secrets Manager | AWS deployments | Automatic rotation, cross-region replication |
| Azure Key Vault | Azure deployments | HSM-backed keys, managed identity integration |
| GCP Secret Manager | Google Cloud deployments | IAM integration, automatic replication |
| Kubernetes Secrets | Kubernetes deployments | Native K8s integration, RBAC-controlled |
Secrets Security Features
- Audit Logging: Every secret access, creation, update, and deletion is logged with actor identity and timestamp
- Rotation Scheduling: Automated rotation policies with configurable intervals per secret
- Circuit Breaker: If a secrets provider becomes unavailable, the system gracefully degrades with cached values and alerts operators
- Retry with Backoff: Transient failures are retried with exponential backoff before triggering the circuit breaker
- Health Monitoring: Continuous health checks on secrets providers with alerting on degradation
Data Retention
CaseBender supports configurable data retention policies that comply with multiple regulatory frameworks:Jurisdiction-Aware Retention
Retention policies are configurable per jurisdiction to meet local regulatory requirements:| Framework | Minimum Retention | Right to Erasure | Legal Basis Required |
|---|---|---|---|
| GDPR | No minimum (purpose limitation) | Yes (Article 17) | Yes |
| SOC2 | 1 year | No | No |
| HIPAA | 6 years | No | No |
| PCI DSS | 1 year | No | No |
| SEC Rule 17a-4 | 3-7 years | No | No |
| CMMC | 3 years | No | No |
Retention Features
- Policy Engine: Define retention periods by entity type, classification level, and jurisdiction
- Legal Hold Integration: Entities under legal hold are exempt from automated deletion regardless of retention policy
- Erasure Requests: GDPR-compliant right to erasure with verification and audit trail
- Impact Preview: Before executing retention, preview exactly which entities will be affected
- Automated Execution: Scheduled retention jobs with full audit logging of every deletion
Related Documentation
- Security Architecture — Zero Trust design and service isolation
- Authentication — How access to data is controlled
- Compliance: GDPR — GDPR-specific data protection features
- Audit Logging — How data access is tracked