This is an automated email from the ASF dual-hosted git repository.
frankgh pushed a commit to branch trunk
in repository https://gitbox.apache.org/repos/asf/cassandra.git
The following commit(s) were added to refs/heads/trunk by this push:
new df6b4fb46c Establish the Security Model for Cassandra
df6b4fb46c is described below
commit df6b4fb46cc0b4f67696d4858be2d54e4acb0940
Author: Francisco Guerrero <[email protected]>
AuthorDate: Mon May 18 17:05:10 2026 -0700
Establish the Security Model for Cassandra
patch by Francisco Guerrero; reviewed by Stefan Miklosovic for
CASSANDRA-21392
---
doc/modules/cassandra/pages/reference/index.adoc | 3 +-
.../cassandra/pages/reference/security-model.adoc | 628 +++++++++++++++++++++
2 files changed, 630 insertions(+), 1 deletion(-)
diff --git a/doc/modules/cassandra/pages/reference/index.adoc
b/doc/modules/cassandra/pages/reference/index.adoc
index 642b9e0810..1879b8d463 100644
--- a/doc/modules/cassandra/pages/reference/index.adoc
+++ b/doc/modules/cassandra/pages/reference/index.adoc
@@ -6,4 +6,5 @@
* xref:reference/native-protocol.adoc[Native Protocol specification]
* xref:reference/sai-virtual-table-indexes.adoc[SAI virtual table]
* xref:reference/static.adoc[Static columns]
-* xref:reference/vector-data-type.adoc[Vector data type]
\ No newline at end of file
+* xref:reference/vector-data-type.adoc[Vector data type]
+* xref:reference/security-model.adoc[Security Model]
diff --git a/doc/modules/cassandra/pages/reference/security-model.adoc
b/doc/modules/cassandra/pages/reference/security-model.adoc
new file mode 100644
index 0000000000..c47cfad741
--- /dev/null
+++ b/doc/modules/cassandra/pages/reference/security-model.adoc
@@ -0,0 +1,628 @@
+= Apache Cassandra Security Model
+
+== Overview
+
+This document outlines the security model for Apache Cassandra, identifying
potential security threats,
+trust boundaries, and the security controls that protect against them. *This
threat model assumes
+that Apache Cassandra has been configured correctly from a security point of
view, with its strongest
+security settings applied*, including authentication (password-based or mutual
TLS-based),
+authorization (`CassandraAuthorizer`), TLS encryption for all communication
channels
+(client-to-node and node-to-node), and JMX bound to the local interface only
with Cassandra integrated
+authentication. Threats are evaluated against this hardened baseline -- not
against Cassandra's
+out-of-the-box defaults. Vulnerability reports that do not adhere to the
assumptions outlined in this
+document may not be accepted.
+
+This threat model is informed by
+https://cassandra.apache.org/doc/latest/cassandra/operating/security.html[Cassandra's
own security documentation].
+
+== System Architecture
+
+Apache Cassandra is a distributed NoSQL database system with the following key
components:
+
+* *Client Applications*: Applications that connect to Cassandra via the CQL
binary protocol to
+ read/write data
+* *Client Drivers*: Official Apache Cassandra drivers (e.g., Java driver,
Python driver) that
+ implement the CQL binary protocol on behalf of client applications
+* *Cassandra Nodes*: Individual database servers forming a peer-to-peer cluster
+* *Inter-node Communication*: Gossip protocol and data replication channels
between Cassandra nodes
+* *Storage Layer*: On-disk SSTables, commit logs, and hints
+* *JMX Interface*: Java Management Extensions interface for monitoring and
administration
+* *System Keyspaces*: Internal keyspaces (e.g., `system_auth`,
`system_schema`) that store cluster
+ metadata, authentication, and authorization data
+
+== Root of Trust
+
+The root of trust for a Cassandra deployment converges to:
+
+* *The infrastructure operator*: The party responsible for provisioning and
maintaining the underlying
+ hardware, operating system, JVM, and network infrastructure on which
Cassandra runs
+* *The Cassandra distribution*: The integrity of the Apache Cassandra software
itself, verified through
+ official Apache release signatures and checksums (signed with keys from the
+ https://downloads.apache.org/cassandra/KEYS[Apache Cassandra PMC KEYS file])
+* *The JVM*: Cassandra runs on the Java Virtual Machine; the security
properties of the JVM (including
+ its TLS implementation, cryptographic providers, and sandboxing) are assumed
to be correct
+
+Before deploying Cassandra in a security-sensitive environment, operators
should verify the authenticity
+of the distribution and ensure the underlying infrastructure meets their trust
requirements.
+
+== User Types
+
+Apache Cassandra distinguishes the following user types with different trust
levels:
+
+=== Trusted Users
+
+* *Infrastructure Operators / Administrators*: Users with OS-level access to
nodes running Cassandra.
+ They have access to configuration files (`cassandra.yaml`,
`cassandra-env.sh`), data directories, JMX
+ interfaces, and can start/stop nodes. These users are fully trusted. It is
the responsibility of the
+ organization to restrict who holds this role guided by the principle of
least privilege.
+* *Database Administrators (Superusers)*: Users with Cassandra superuser
roles. They can
+ create/alter/drop roles, keyspaces, and tables, and grant/revoke
permissions. They are trusted within
+ the CQL authorization model but should not require OS-level access.
+* *Application Developers*: Users who write applications that connect to
Cassandra. They are trusted
+ to use the CQL API correctly, construct safe queries, and manage credentials
securely within their
+ applications.
+
+=== Untrusted Users
+
+* *Database Users (Non-superuser Roles)*: Authenticated users with limited,
explicitly granted
+ permissions. They are not trusted beyond the permissions assigned to their
role. The authorization
+ subsystem (`CassandraAuthorizer`) enforces their access boundaries.
+* *Unauthenticated Network Actors*: Any party with network access to
Cassandra's client or
+ inter-node ports who has not authenticated. Under this threat model's
assumed configuration, all
+ communication channels require authentication and TLS, and JMX is bound to
localhost only, so
+ unauthenticated connection attempts are rejected. These actors remain a
threat only if they can
+ exploit vulnerabilities in the TLS handshake, authentication protocol, or
network stack itself.
+* *External Clients and End Users*: Users of applications that interact with
Cassandra indirectly.
+ Their input should never be trusted by the application layer and must be
validated before being
+ passed to CQL queries.
+
+== Data Sources
+
+=== Trusted Sources
+
+Cassandra trusts the following data sources. It is the responsibility of the
deployer to protect them:
+
+* *Configuration files* (`cassandra.yaml`, `cassandra-env.sh`,
`cassandra-rackdc.properties`,
+ `jmxremote.password`): These control all security-critical behavior
including encryption,
+ authentication, and authorization settings. Deployers must ensure that
untrusted parties do not
+ have write access to these files and that they are transmitted only over
confidential channels.
+* *System keyspaces* (`system_auth`, `system_schema`, `system`): These
internal tables store
+ authentication credentials, role definitions, permissions, and schema
metadata. Cassandra trusts their
+ contents. Deployers must ensure the `system_auth` keyspace has adequate
replication (recommended: RF
+ 3-5 per datacenter) and that direct manipulation via tools like
`sstableloader` is restricted to
+ trusted operators.
+* *JMX interface*: Operations performed through JMX are trusted to be
legitimate administrative actions.
+ JMX is bound to the local interface only, secured with Cassandra integrated
authentication and
+ authorization, and configured with fine-grained MBean permissions. Deployers
must maintain these
+ controls and audit JMX access.
+* *Environment variables and JVM system properties*: These configure
security-critical behaviors such
+ as SSL keystore paths, JMX settings, and JAAS configuration. Deployers must
protect the execution
+ environment.
+* *SSL/TLS key material*: Keystores, truststores, and PEM files used for
client-to-node, node-to-node,
+ and JMX encryption. Deployers must protect these files with appropriate
filesystem permissions and
+ manage certificate lifecycle (Cassandra supports hot reloading of SSL
certificates).
+* *Pluggable extension points, service provider interfaces (SPIs), and
operator-supplied JARs*:
+ Cassandra exposes numerous extension points that operators select via
`cassandra.yaml` or that are
+ discovered from the classpath at startup. Examples include authentication
and authorization plugins
+ (`IAuthenticator`, `IAuthorizer`, `INetworkAuthorizer`, `IRoleManager`,
`IInternodeAuthenticator`,
+ `ICIDRAuthorizer`), topology, partitioning, and seed selection
(`IEndpointSnitch`, `IPartitioner`,
+ `ISeedProvider`), TLS material providers (`ISslContextFactory`), storage and
data-path components
+ (`ICompressor`, `SSTableFormat.Factory`), audit and startup hooks
(`IAuditLogger`, `StartupCheck`),
+ per-table triggers (`ITrigger`), CQL constraint providers
(`ConstraintProvider`), and any other
+ interface or `java.util.ServiceLoader` SPI that Cassandra resolves at
runtime. User-defined functions
+ and aggregates loaded as Java code, and any other JAR placed on the
Cassandra classpath
+ (including the `triggers/` directory) fall in the same category. These
implementations run in-process
+ with the full privileges of the Cassandra JVM and can invoke any Cassandra
internal, read or modify
+ any data the process can access, and observe any in-memory state. The Apache
Cassandra project does
+ *not* control the security properties of third-party implementations and
cannot make guarantees about
+ them. Deployers are responsible for sourcing such components only from
trusted vendors, reviewing or
+ auditing their behavior, restricting who can publish JARs to a node's
classpath or trigger/UDF
+ directories, and treating them with the same care as the Cassandra
distribution itself.
+
+=== Untrusted Sources
+
+Cassandra does *not* trust the following, and its security controls are
designed to mediate access from
+them:
+
+* *CQL queries from client connections*: All client requests are subject to
authentication and
+ authorization checks. Either `PasswordAuthenticator`,
`MutualTlsWithPasswordFallbackAuthenticator`, or
+ `MutualTlsAuthenticator` is active alongside `CassandraAuthorizer`, and all
connections require TLS.
+ Applications should use parameterized queries and never interpolate
untrusted input directly into CQL
+ strings.
+* *Data content written by clients*: Cassandra does not validate or sanitize
the content of data written
+ to user tables. It is the application's responsibility to validate data
before writing.
+* *Inter-node messages from unauthorized sources*: With inter-node encryption
+ (`internode_encryption: all`) and mutual TLS active, unauthorized nodes
cannot join the cluster or inject
+ traffic. The residual threat is exploitation of vulnerabilities in the TLS
implementation or certificate
+ validation logic.
+
+== Client Driver Trust Model
+
+Apache Cassandra client drivers (Java driver, Python driver, and other
official drivers) operate under
+a trust model that mirrors the server-side assumptions in this document.
Drivers assume they are
+connecting to a properly configured, non-compromised Apache Cassandra server.
The trust relationship
+between a driver and a server is bidirectional:
+
+* The server authenticates and authorizes the client based on credentials or
mutual TLS certificates
+ presented by the driver.
+* The driver, in turn, trusts that the server it is connected to is
legitimate. With mutual TLS and
+ certificate validation against a configured truststore, the driver verifies
the server's identity
+ at the TLS layer before exchanging any CQL traffic.
+
+Once the TLS handshake succeeds and the driver is connected to an
authenticated server, the driver
+treats CQL protocol responses (result rows, schema metadata, server events) as
well-formed and within
+protocol bounds. Drivers do not, in general, perform exhaustive validation
that every length field,
+type code, or value in a server response conforms to the declared schema --
doing so would duplicate
+the server's own correctness guarantees and impose significant overhead on the
protocol fast path
+(including native/Cython-accelerated parsing paths).
+
+Consequently, scenarios that require a *malicious or compromised
Cassandra-compatible server*
+returning crafted protocol responses to attack a connected driver are outside
the trust boundary of
+this threat model. If an attacker controls the server endpoint the driver is
connected to, the
+attacker already has full access to every read and write the application
performs through that
+connection; a client-side process crash, memory corruption, or resource
exhaustion triggered by
+crafted response bytes is strictly less severe than the server compromise
itself.
+
+Bugs of this nature (for example, insufficient bounds checking when parsing
server responses,
+mishandling of malformed protocol frames, or driver crashes on out-of-spec
server replies) remain
+legitimate correctness and robustness issues and should be reported through
the project's normal bug
+tracker. They are not, however, treated as security vulnerabilities under this
threat model.
+
+== Threats
+
+=== 1. Unauthorized Data Access (CWE-284: Improper Access Control)
+
+*Threat*: Attackers gain unauthorized access to data stored in Cassandra
despite authentication and
+authorization being active.
+
+*Attack Vectors*:
+
+* Compromised or weak credentials allowing an attacker to authenticate as a
legitimate user
+* Exploiting overly permissive role grants that expose data beyond intended
scope
+* Direct access to SSTable files on disk, bypassing CQL-level access controls
+* Exploiting vulnerabilities in the authentication or authorization subsystem
to bypass access checks
+* Compromised JMX credentials exposing data through MBean operations
+
+*Active Controls*:
+
+* *Authentication*: `PasswordAuthenticator`,
`MutualTlsWithPasswordFallbackAuthenticator`, or
+ `MutualTlsAuthenticator` is active; the default `cassandra` superuser
account has been disabled and
+ replaced with a dedicated superuser. All client connections must
authenticate via credentials or
+ mutual TLS client certificates.
+* *Authorization*: `CassandraAuthorizer` enforces role-based access control
with keyspace and
+ table-level permissions via `GRANT`/`REVOKE`. Permissions follow an
allowlist model (no access
+ unless explicitly granted).
+* *File System Permissions*: OS-level access to data directories, commit logs,
and saved caches is
+ restricted to the Cassandra process user. Where the Apache Cassandra Sidecar
(control plane) is
+ deployed alongside a node, it shares filesystem access with the Cassandra
process for operations
+ such as bulk import/export (data directories), CDC consumption (commit log
directory), and live
+ data migration. The Sidecar process is treated as a co-located trusted
component subject to the
+ same operator-level protections as the Cassandra process itself.
+* *JMX Authentication*: JMX is bound to the local interface only
(`LOCAL_JMX=yes`), eliminating
+ remote JMX attack surface. Cassandra integrated auth (`CassandraLogin` JAAS
config) provides
+ authentication even for local access.
+* *Inter-node Encryption*: `server_encryption_options` with
`internode_encryption: all` and mutual
+ TLS prevents unauthorized cluster participants.
+
+*Residual Risks*:
+
+* Credential theft or brute-force attacks against authenticated accounts
+* Privilege creep through accumulated role grants over time
+* Compromise of an infrastructure operator who has OS-level access to data
files
+
+=== 2. Data in Transit Interception (CWE-319: Cleartext Transmission of
Sensitive Information)
+
+*Threat*: Attackers intercept data transmitted between clients and nodes, or
between nodes, despite
+TLS being active on all channels.
+
+*Attack Vectors*:
+
+* Exploiting vulnerabilities in the TLS implementation or cipher suite
negotiation
+* Compromised or weak certificates enabling man-in-the-middle attacks
+* Exploiting certificate validation flaws during SSL hot reloading
+* Attacks against the certificate authority or key material
+
+*Active Controls*:
+
+* *Client-to-Node Encryption*: `client_encryption_options` is configured with
`enabled: true` and
+ `optional: false`, requiring TLS for all client connections.
+* *Node-to-Node Encryption*: `server_encryption_options` is configured with
`internode_encryption: all`
+ and mutual TLS certificate validation.
+* *JMX Localhost Binding*: JMX is bound to the local interface only
(`LOCAL_JMX=yes`), so JMX traffic
+ does not traverse the network. This eliminates the risk of JMX
data-in-transit interception without
+ requiring JMX SSL.
+* *Certificate Management*: CA-signed certificates are used with properly
configured truststores for
+ mutual authentication. Cassandra's SSL certificate hot reloading (polling
every 10 minutes, or
+ triggered via `nodetool reloadssl`) supports certificate rotation without
downtime.
+* *FIPS Compliance*: Where required, FIPS-compliant settings are configured at
the JVM level.
+
+*Residual Risks*:
+
+* Compromise of private key material or certificate authority
+* Vulnerabilities in JVM TLS implementation (e.g., protocol downgrade attacks)
+* Brief window during certificate rotation where old/new certificates coexist
+
+=== 3. Data Tampering and Integrity (CWE-345: Insufficient Verification of
Data Authenticity)
+
+*Threat*: Attackers modify data without authorization or corrupt data
integrity despite active
+access controls.
+
+*Attack Vectors*:
+
+* Authenticated users exploiting overly broad `MODIFY` permissions to alter
data outside their
+ intended scope
+* Direct manipulation of SSTable files on disk by a compromised OS-level
account
+* Use of offline tools (`sstableloader`, `sstablescrub`) by a compromised
operator to overwrite
+ system or user tables
+* Exploiting vulnerabilities in the authorization subsystem to bypass write
restrictions
+
+*Active Controls*:
+
+* *Fine-grained Authorization*: `MODIFY` permissions are granted only to roles
that require write
+ access, scoped to specific keyspaces and tables.
+* *Audit Logging*: Audit logging is enabled for security-relevant categories
that strike a balance
+ between compliance and scalability on large systems. The recommended
categories to include are
+ AUTH, DCL, DDL, ERROR, OTHER, which captures authentication events, data
control
+ language (`GRANT`/`REVOKE`), data definition language (schema changes),
errors, and other
+ administrative operations. Capturing every `DML` (data modification)
statement is generally not
+ tenable at scale; deployers may opt in to `DML` auditing for specific
keyspaces or roles where
+ regulatory requirements demand it.
+* *File System Permissions*: SSTable files, commit logs, and hints are
protected with restrictive
+ OS-level permissions. Access to `sstableloader` and other offline tools is
restricted to trusted
+ operators or the control plane process (i.e. Cassandra Sidecar).
+* *Inter-node Authentication*: Mutual TLS on inter-node channels prevents
unauthorized nodes from
+ joining the cluster and injecting data.
+
+*Residual Risks*:
+
+* A compromised infrastructure operator can bypass all CQL-level access
controls via direct file
+ manipulation
+* Application-level logic errors that allow authenticated users to write
unintended data within
+ their granted permissions
+* *Application-level Integrity* _(developer responsibility)_: Implement
checksums or application-level
+ signatures where data integrity guarantees beyond Cassandra's internal
mechanisms are required
+
+=== 4. Denial of Service (CWE-400: Uncontrolled Resource Consumption)
+
+*Threat*: Attackers disrupt Cassandra availability despite authentication
requirements.
+
+*Attack Vectors*:
+
+* Authenticated users executing resource-exhaustive queries (full table scans,
unbounded reads,
+ excessive tombstone reads)
+* Authenticated users opening excessive connections to exhaust connection pools
+* Compromised JMX credentials used to trigger disruptive operations (e.g.,
compaction, repair on
+ overloaded nodes) -- requires local access to the node since JMX is
localhost-bound
+* TLS handshake abuse to exhaust CPU resources on client or inter-node ports
+* Network-level flooding against gossip or native transport ports
(infrastructure-layer attack)
+
+*Active Controls*:
+
+* *Authentication Barrier*: All client connections must authenticate,
preventing anonymous abuse.
+ TLS is required, raising the cost of connection flooding.
+* *Rate Limiting*: Client connection limits and native transport request
throttling are configured.
+* *Resource Limits*: Read/write request timeouts, query result size limits,
and tombstone thresholds
+ are set in `cassandra.yaml`.
+* *JMX Security*: JMX is bound to the local interface only, eliminating remote
JMX attack surface.
+ Local JMX access is secured with Cassandra integrated auth.
+* *Network Security*: Firewalls and network segmentation are in place. All
non-essential ports are
+ closed.
+* *Monitoring and Alerting*: Unusual traffic patterns, query latency spikes,
and resource exhaustion
+ conditions are monitored.
+
+*Residual Risks*:
+
+* Authenticated users with legitimate credentials can still craft expensive
queries within their
+ permissions
+* TLS handshake cost amplification from unauthenticated network actors
+* *Query Best Practices* _(developer responsibility)_: Use prepared
statements, avoid `ALLOW FILTERING`
+ in production, set appropriate page sizes, and ensure queries are
partition-aware
+
+=== 5. Privilege Escalation (CWE-269: Improper Privilege Management)
+
+*Threat*: Attackers elevate privileges beyond their authorized level despite
active RBAC and JMX
+authorization.
+
+*Attack Vectors*:
+
+* Exploiting overly permissive role grants that accumulate over time
(privilege creep)
+* Credential theft targeting superuser or DBA accounts
+* Exploiting vulnerabilities in the `CassandraAuthorizer`,
`PasswordAuthenticator`,
+ `MutualTlsWithPasswordFallbackAuthenticator` or `MutualTlsAuthenticator` to
bypass access checks
+* Exploiting inconsistencies between CQL authorization and JMX authorization
scopes
+* Exploiting role hierarchy (`GRANT role TO role`) to gain unintended
transitive permissions
+
+*Active Controls*:
+
+* *Default Superuser Disabled*: The default `cassandra` role has been removed
or disabled (`ALTER
+ ROLE cassandra WITH SUPERUSER = false AND LOGIN = false`) and replaced with
a dedicated superuser.
+ When `PasswordAuthenticator` (or the password fallback path of
+ `MutualTlsWithPasswordFallbackAuthenticator`) is in use, the dedicated
superuser is protected by a
+ strong password. When `MutualTlsAuthenticator` is in use, the dedicated
superuser is a passwordless
+ role bound to a specific administrative mTLS identity (client certificate)
via the configured
+ certificate-to-role mapping; password-based login is not required and is not
the only acceptable
+ hardening for the superuser role.
+* *Principle of Least Privilege*: Permissions are granted at the minimum
necessary scope using `GRANT`
+ statements scoped to specific keyspaces, tables, or MBeans.
+* *Role Separation*: Administrative (superuser), operational (JMX), and
application roles are separated.
+ Cassandra's role hierarchy (`GRANT role TO role`) is used to manage
permissions cleanly.
+* *Unified JMX Authorization*: Cassandra integrated JMX auth (`CassandraLogin`
JAAS config +
+ `AuthorizationProxy`) unifies CQL and JMX access control with fine-grained
MBean permissions.
+* *Inter-node Encryption*: Mutual TLS prevents unauthorized manipulation of
`system_auth` tables via
+ crafted inter-node messages.
+
+*Residual Risks*:
+
+* Privilege creep if role grants are not periodically audited (`LIST ALL
PERMISSIONS`)
+* Compromise of a superuser account grants full cluster control
+* Complex role hierarchies may create unintended transitive permission paths
+
+=== 6. Information Disclosure (CWE-200: Exposure of Sensitive Information)
+
+*Threat*: Attackers gain access to sensitive system information, metadata, or
credentials despite active
+access controls.
+
+*Attack Vectors*:
+
+* Authenticated users with overly broad permissions reading `system_auth`
tables (role definitions,
+ hashed credentials, permission grants) or other deployment-restricted
resources
+* Compromised JMX credentials exposing configuration details, memory state,
and operational metrics
+ beyond intended scope -- requires local access to the node since JMX is
localhost-bound
+* Log files containing sensitive information (credentials, query data, stack
traces) accessible to unauthorized parties
+* CQL error messages revealing internal system details to authenticated
non-superuser clients
+* Timing or error-based information leakage through CQL query responses
+
+*Active Controls*:
+
+* *System Table Permissions*: Access to `system_auth` (which stores role
definitions, hashed
+ credentials, and permission grants) is restricted -- non-superusers must be
explicitly granted
+ `SELECT` to read it. DDL against local and replicated system keyspaces is
blocked by the
+ authorization layer regardless of grants (only replication parameters of
replicated system
+ keyspaces may be altered by sufficiently privileged users).
+* *Schema and Topology Metadata (intentionally exposed)*: `system_schema`
(schema metadata) and the
+ topology-bearing tables in the `system` keyspace (`local`, `peers_v2`,
size/table estimates) are
+ readable by every authenticated user by design. Drivers and CQL tooling
depend on this -- for
+ example, `DESCRIBE schema;` and routine driver bootstrap require it. Schema
and cluster topology
+ are therefore not treated as confidential under this model; the deployment
relies on the trust
+ placed in authenticated clients (see the Client Driver Trust Model above).
+* *JMX Access Control*: JMX is bound to the local interface only, restricting
access to users with
+ local access to the node. Fine-grained MBean permissions limit what
authenticated JMX users can
+ observe. Monitoring roles are granted only `SELECT` and `DESCRIBE`.
+* *Log Management*: Access to log files is restricted at the OS level.
Production log levels are
+ configured to avoid logging sensitive data.
+
+*Residual Risks*:
+
+* Schema, keyspace/table/column names, and cluster topology are readable by
every authenticated user
+ by design; deployers must not encode sensitive information into schema
identifiers and should
+ treat that metadata as non-confidential
+* Authenticated users may infer data distribution through permitted query
patterns
+* Log files may inadvertently contain sensitive data if log levels are changed
during debugging
+* *Log Hygiene* _(developer responsibility)_: Do not log credentials,
authentication tokens, or
+ sensitive user data. Document which log levels may contain sensitive
information.
+* *Error Handling* _(framework responsibility)_: Cassandra should avoid
exposing internal stack
+ traces or system details in CQL error responses to non-superuser clients.
+
+=== 7. Supply Chain and Dependency Attacks (CWE-1357: Reliance on
Insufficiently Trustworthy Component)
+
+*Threat*: Attackers compromise Cassandra through malicious or vulnerable
dependencies or tampered
+distribution packages.
+
+*Attack Vectors*:
+
+* Compromised third-party libraries included in the Cassandra distribution
+* Tampered distribution packages obtained from unofficial sources
+* Vulnerable dependencies with known CVEs
+* Compromised build infrastructure or release process
+
+*Active Controls*:
+
+* *Verified Distribution*: Cassandra is obtained from official Apache
distribution channels with
+ release signatures verified against the
+ https://downloads.apache.org/cassandra/KEYS[Apache Cassandra PMC KEYS file].
Artifacts without
+ valid signatures are not used.
+* *Dependency Management* _(framework)_: The Apache Cassandra project checks
the quality of its
+ dependencies and monitors for known vulnerabilities.
+* *Security Patches*: Security updates are applied promptly. The
+ mailto:[email protected][Cassandra security mailing list] is
monitored for vulnerability
+ announcements.
+* *JVM Updates*: The underlying JVM is kept up-to-date with security patches,
as Cassandra inherits the
+ JVM's cryptographic and network security properties.
+
+*Residual Risks*:
+
+* Zero-day vulnerabilities in dependencies that have not yet been disclosed or
patched
+* Compromise of the Apache release infrastructure itself
+
+=== 8. Log Injection (CWE-117: Improper Output Neutralization for Logs)
+
+*Threat*: Attackers inject malicious content into log files through crafted
input, hiding malicious
+activity or corrupting log analysis. This threat applies even with all
security features enabled,
+as authenticated users can submit crafted data through legitimate CQL
operations.
+
+*Attack Vectors*:
+
+* Crafted CQL query strings or data values that inject log control characters
+* Manipulated client connection metadata (e.g., role names) appearing in log
output
+* Exploitation of structured log format parsing through specially crafted
values
+
+*Active Controls*:
+
+* *Authentication Barrier*: Only authenticated users can submit queries,
limiting the attack surface
+to known identities and providing an audit trail.
+
+*Residual Risks*:
+
+* Authenticated users can still inject log content through legitimate CQL
operations
+* *Structured Logging* _(framework responsibility)_: Where possible, use
structured log formats (JSON,
+ etc.) that properly escape special characters.
+* *Log Validation* _(deployer responsibility)_: Use log aggregation systems
that are resilient to
+ injection attacks.
+* *Input Awareness* _(developer responsibility)_: Be aware that
client-supplied values may appear in
+ Cassandra logs. Do not rely on unstructured log output for security-critical
decisions.
+
+=== 9. Improper Neutralization of Special Elements in CQL (CWE-138)
+
+*Threat*: Attackers exploit improperly constructed CQL queries to execute
unauthorized operations.
+This is an application-layer threat that persists regardless of Cassandra's
security configuration,
+as it targets how client applications construct queries.
+
+*Attack Vectors*:
+
+* CQL injection through string concatenation of untrusted input into queries
within client applications
+* Exploitation of application-level query construction flaws to escalate
operations within the
+ permissions of the application's database role
+
+*Active Controls*:
+
+* *Authorization Boundary*: Even if CQL injection succeeds, the injected
operations are limited to
+ the permissions of the authenticated application role. Fine-grained
authorization limits the blast
+ radius.
+* *Audit Logging*: Injected queries that fall within audited categories (e.g.,
authentication, DCL,
+ DDL, errors) are captured in audit logs, supporting detection and forensic
analysis. Detection of
+ injection within DML statements requires opting in to DML auditing for the
targeted scope.
+
+*Residual Risks*:
+
+* Within the application role's permissions, an attacker can read, modify, or
delete any data the role
+ has access to
+* *Parameterized Queries* _(developer responsibility)_: Always use prepared
statements with bound
+ parameters.
+ Never concatenate untrusted input into CQL query strings.
+* *Input Validation* _(developer responsibility)_: Validate and sanitize all
user input at the
+ application boundary before constructing CQL queries.
+
+== Responsibility Matrix
+
+[cols="4,^1,^1,^1",options="header"]
+|===
+| Responsibility | Deployer | Developer | Framework
+| Maintain authentication configuration and credential strength | X | |
+| Maintain authorization and role-based access control | X | |
+| Maintain TLS encryption on all channels | X | |
+| Protect configuration files, key material, and certificates | X | |
+| Manage firewall rules and network segmentation | X | |
+| Maintain appropriate replication for `system_auth` | X | |
+| Rotate credentials and certificates periodically | X | |
+| Audit role grants and permissions regularly | X | |
+| Maintain JMX security and access restrictions | X | |
+| Monitor and respond to security events | X | |
+| Use parameterized CQL queries | | X |
+| Validate user input before passing to CQL | | X |
+| Manage application credentials securely | | X |
+| Avoid logging sensitive data | | X |
+| Prevent log injection in structured log layouts | | | X
+| Verify integrity of dependencies | | | X
+| Provide secure defaults and security documentation | | | X
+|===
+
+== Security Configuration Baseline
+
+This threat model assumes the following security configuration is active. All
threats and residual
+risks are evaluated against this hardened baseline:
+
+. *Authentication*: `PasswordAuthenticator`,
`MutualTlsWithPasswordFallbackAuthenticator` or
+ `MutualTlsAuthenticator` is configured (not `AllowAllAuthenticator`). The
default `cassandra`
+ superuser account is removed or disabled. A dedicated superuser is in use.
When using
+ `PasswordAuthenticator` (or the password fallback path of
+ `MutualTlsWithPasswordFallbackAuthenticator`), strong passwords are
enforced. When using
+ `MutualTlsAuthenticator`, the dedicated superuser is a passwordless role
bound to a specific
+ administrative mTLS identity, and client certificate validation is enforced
through the TLS
+ truststore. Either form -- a strong password under password-based
authentication, or a passwordless
+ role bound to an administrative certificate identity under mutual TLS --
satisfies this baseline.
+. *Authorization*: `CassandraAuthorizer` is configured (not
`AllowAllAuthorizer`). Permissions
+ follow an allowlist model -- no access is granted unless explicitly assigned
via `GRANT`.
+. *Client-to-Node Encryption*: `client_encryption_options` is enabled with
`optional: false`,
+ requiring TLS for all client connections.
+. *Node-to-Node Encryption*: `server_encryption_options` is configured with
+ `internode_encryption: all` and mutual TLS with certificate validation.
+. *JMX Security*: JMX is bound to the local interface only (`LOCAL_JMX=yes` in
`cassandra-env.sh`),
+ restricting access to the localhost. JMX uses Cassandra integrated
authentication and authorization
+ (`CassandraLogin` JAAS config + `AuthorizationProxy`). If remote JMX access
is operationally required,
+ it must be enabled with SSL and Cassandra integrated auth; however,
localhost-only binding is the
+ recommended and assumed configuration.
+. *`system_auth` Replication*: The `system_auth` keyspace is configured with
`NetworkTopologyStrategy`
+ and a replication factor of 3-5 per datacenter.
+. *Audit Logging*: Audit logging is enabled with the
`AUTH,DCL,DDL,ERROR,OTHER` categories to
+ capture authentication, authorization changes, schema changes, errors, and
administrative operations.
+ This baseline balances compliance and scalability; auditing `DML` is opt-in
and should be scoped to
+ specific keyspaces or roles where required.
+. *Network Security*: Firewalls and network segmentation are in place. All
non-essential ports are closed.
+
+== Security Assumptions
+
+This threat model further assumes:
+
+. *Cassandra has been configured correctly from a security point of view*,
with all security features
+ enabled and properly configured as described in the Security Configuration
Baseline above
+. Cassandra is deployed on trusted infrastructure with proper OS-level
security hardening
+. Network infrastructure is secured with appropriate firewalls and segmentation
+. Infrastructure operators and administrators are trusted and follow security
best practices
+. The underlying JVM is kept up-to-date with security patches
+. Physical security of servers is maintained
+. The Cassandra distribution has been obtained from official Apache channels
and verified with release signatures
+. SSL/TLS key material is properly generated, stored, and rotated
+. Credentials are strong, unique, and managed through a secure credential
management process. For
+ password-based authentication this means strong, rotated passwords; for
mutual TLS authentication
+ this means properly issued, scoped, and rotated client certificates whose
subject identity is bound
+ to a specific Cassandra role (which may be passwordless)
+. Any pluggable implementation of a Cassandra interface or SPI
(authenticators, authorizers, snitches,
+ seed providers, partitioners, compressors, SSL context factories, audit
loggers, triggers, UDFs,
+ startup checks, etc.) and any JAR placed on the Cassandra classpath is
sourced from a trusted vendor
+ and treated as part of the trusted code base; third-party implementations
are outside the control of
+ the Apache Cassandra project
+
+== Vulnerability Reporting Scope
+
+Vulnerability reports against Apache Cassandra should adhere to the
assumptions and trust boundaries
+defined in this threat model. This model assumes a correctly configured, fully
hardened Cassandra
+deployment. Specifically:
+
+* Reports that assume a trusted user (administrator, infrastructure operator)
is the attacker are
+ *out of scope*, as these users are inherently trusted with full system
access.
+* Reports that require OS-level or physical access to Cassandra nodes are *out
of scope*, as
+ infrastructure security is a prerequisite assumption.
+* Reports that require security features to be disabled or misconfigured
(e.g., using
+ `AllowAllAuthenticator` or unencrypted connections) are *out of scope*, as
this threat model
+ assumes correct security configuration.
+* Reports demonstrating bypass of enabled authentication, authorization, or
encryption controls
+ are *in scope* and will be treated with appropriate severity.
+* Reports demonstrating vulnerabilities that persist despite correct security
configuration
+ (e.g., flaws in the `PasswordAuthenticator`,
`MutualTlsWithPasswordFallbackAuthenticator`,
+ `MutualTlsAuthenticator`, `CassandraAuthorizer`, or TLS implementation) are
*in scope*.
+* Reports against Apache Cassandra client drivers (Java, Python, etc.) that
require a malicious
+ or compromised Cassandra server returning crafted CQL protocol responses are
*out of scope*.
+ Drivers assume they are connected to a trusted, properly configured Apache
Cassandra server,
+ with TLS verifying server trust where applicable. Such reports should be
filed as correctness
+ or robustness bugs through the project's normal bug tracker.
+
+To report a vulnerability, follow the https://www.apache.org/security/[Apache
Security Team process].
+
+== Out of Scope
+
+The following are considered out of scope for this threat model:
+
+* Vulnerabilities in the underlying operating system, JVM, or hardware
+* Physical attacks on servers
+* Social engineering attacks targeting administrators
+* Application-level vulnerabilities in client code
+* Backup and disaster recovery security (covered separately)
+* Side-channel attacks: While we acknowledge that timing or
resource-usage-based side channels may exist,
+ they are out of scope for the current threat model. Where practical, we will
adopt software hardening to
+ mitigate known side-channel vectors.
+* Log masking: It is the developer's responsibility to ensure sensitive data
is properly masked before
+ passing it to CQL or logging. Third-party frameworks should be used for this
purpose.
+* Denial of service at the network/infrastructure layer (e.g., volumetric
DDoS) -- this is an infrastructure
+ concern, not a Cassandra application concern.
+* Driver-side bugs triggered by responses from a malicious or compromised
Cassandra-compatible server
+ (e.g., crashes, buffer overflows, or resource exhaustion in driver protocol
parsers when fed crafted server
+ replies). Drivers operate under the assumption that they are connected to a
trusted, properly configured
+ Apache Cassandra server; an attacker who controls the server endpoint is
already past the trust boundary
+ that drivers protect. These should be filed as correctness bugs rather than
security vulnerabilities.
+
+== References
+
+*
https://cassandra.apache.org/doc/latest/cassandra/operating/security.html[Apache
Cassandra Security Documentation]
+* https://cassandra.apache.org/doc/latest/cassandra/configuration/[Apache
Cassandra Configuration Reference]
+* https://cve.mitre.org/[CVE Database]
+* https://www.apache.org/security/[Apache Security Team]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
