Energy SOAR stores your most sensitive security data — alerts, cases, observables, and incident timelines — all the time, on disk. Here is how encryption at rest works inside the platform, and how to make sure it is enabled in your deployment.
Security operations platforms handle some of the most sensitive data in an organization: threat intelligence, incident records, attacker observables, analyst notes. Protecting that data while it is stored on disk is not optional — it is a baseline expectation for any production deployment.
Energy SOAR can use Apache Cassandra as its primary data store. Cassandra provides transparent, storage-layer encryption that protects everything written to disk — without requiring any changes to how you query data or run workflows. This post explains how that works, and how to configure it correctly for your SOAR environment.
How data flows from SOAR to encrypted storage
Every time Energy SOAR writes data — a new alert ingested from your SIEM, a case created by an analyst, an observable enriched by a playbook — that data follows Cassandra’s write path before it ever touches a disk. Encryption happens at the final step, automatically.
The important detail here is step 4. By the time data leaves the Cassandra node’s memory and is flushed to an SSTable file, it has already been encrypted. Neither an analyst querying the database nor a playbook running a workflow is aware this is happening — the encryption and decryption steps are invisible to the application layer.
The transparent encryption layer
Energy SOAR’s Cassandra nodes have a clean separation between what the application sees and what is stored on disk. Analysts, workflows, and integrations all interact with the storage layer via standard queries. What they get back is plaintext — because decryption happens at the node, in memory, before the data is returned. What lives on disk is always ciphertext.
The key management separation shown above is what makes this model resilient. Even if an attacker obtains a disk image or a cold backup, they cannot read the data without access to the keys. And because the keys live in a separate KeyStore or external KMS, that access path is independently controlled and auditable.
What an encrypted node looks like from outside
The third concept worth making concrete is the physical boundary. From outside the node, you see encrypted bytes. From inside — from any query running against the node — you see plaintext records. The decryption step happens at the node boundary, in memory, and only for data you are authorized to read.
This is the threat model encryption at rest is designed for: a stolen disk, a rogue backup, a datacenter access incident. The attacker gets ciphertext and nothing else. Your analysts, playbooks, and integrations are never impacted.
Enabling encryption in your Energy SOAR deployment
Cassandra encryption at rest is configured in cassandra.yaml on each node. Below is the relevant section to add or enable. This needs to be applied to every Cassandra node in your cluster and requires a rolling restart.
# cassandra.yaml — transparent data encryption
transparent_data_encryption_options:
enabled: true
chunk_length_kb: 64
cipher: AES/CBC/PKCS5Padding
key_alias: testing:1
key_provider:
- class_name: org.apache.cassandra.security.JKSKeyProvider
parameters:
- keystore: /etc/cassandra/conf/.keystore
keystore_password: cassandra
store_type: JCEKS
key_password: cassandra
# Apply to commit log as well
commitlog_compression:
class_name: LZ4Compressor
# Hint: replace keystore_password and key_password with secrets
# managed by your KMS or Vault in production deployments.
What gets encrypted
When encryption at rest is enabled on an Energy SOAR node, the following persistent structures are protected:
SSTables — the primary on-disk representation of all data: alerts, cases, tasks, observables, analyst notes, workflow logs, and configuration. This is the main target for at-rest encryption.
Commit logs — write-ahead logs used for durability and crash recovery. Encrypting these ensures that even incomplete writes that have not yet flushed to SSTables are protected.
Snapshots and backups — Cassandra snapshot files are copies of SSTable files. Because the SSTables are already encrypted, all snapshots produced from an encrypted node are also encrypted. Backups shipped offsite or to object storage remain ciphertext throughout.
Performance impact
Cassandra’s encryption operates at the chunk level (chunk_length_kb: 64 by default) rather than encrypting files in full on every operation. This keeps the per-operation overhead low — typically under 5% on modern hardware with AES-NI CPU support, which is standard on any virtualized or bare-metal environment Energy SOAR would run on.
Encryption does not change Cassandra’s internal write or read path in any way that affects throughput or latency at SOC-relevant workloads. Alert ingestion, case creation, and observable enrichment all perform identically.
Compliance context
Encryption at rest is a control requirement in multiple frameworks relevant to security operations teams: ISO 27001 (A.10.1), SOC 2 Type II (CC6.1), NIS2 for critical infrastructure operators, and GDPR Article 32. Enabling Cassandra encryption at rest in Energy SOAR directly satisfies the “data at rest” clause in each of these, and can be evidenced with a configuration export and a node audit log showing the cipher algorithm in use.
Enable encryption in your deployment
The Energy SOAR knowledge base includes a full step-by-step guide for enabling Cassandra encryption at rest, including key generation, rolling restarts, and KMS integration for cloud deployments. Contact our team
