Skip to content

Latest commit

 

History

History
77 lines (68 loc) · 8.47 KB

mitigations.md

File metadata and controls

77 lines (68 loc) · 8.47 KB

Mitigation Strategies Analysis for apache/cassandra

Mitigation Strategy: Enable Cassandra Authentication

  • Description:
    1. Edit cassandra.yaml: Locate the authenticator property in your cassandra.yaml configuration file.
    2. Set Authenticator: Change the value of authenticator from AllowAllAuthenticator (default, insecure) to a secure authenticator like PasswordAuthenticator.
    3. Restart Cassandra Nodes: Restart all Cassandra nodes in your cluster for the configuration change to take effect.
    4. Create Users: Use cqlsh or a Cassandra client to create administrative users with strong passwords using CQL commands like CREATE USER 'admin' WITH PASSWORD 'StrongPassword' SUPERUSER;.
    5. Grant Permissions: Grant appropriate permissions to users based on their roles using GRANT statements. For example, GRANT ALL PERMISSIONS ON KEYSPACE keyspace_name TO 'user';.
  • Threats Mitigated:
    • Unauthorized Access (High Severity): Prevents anyone without credentials from directly accessing and manipulating Cassandra data through Cassandra interfaces (CQL, Thrift if enabled).
    • Data Breaches (High Severity): Reduces the risk of data leaks due to unauthorized direct access to Cassandra.
    • Data Manipulation (High Severity): Prevents unauthorized modification or deletion of data directly through Cassandra.
  • Impact:
    • Unauthorized Access: High Risk Reduction
    • Data Breaches: High Risk Reduction
    • Data Manipulation: High Risk Reduction
  • Currently Implemented: Yes, enabled in the production and staging Cassandra clusters. Configured using PasswordAuthenticator and user roles are managed via scripts during infrastructure provisioning.
  • Missing Implementation: Authentication is not enforced in the development environment Cassandra instances for ease of local development. This should be addressed by providing secure default credentials for development or using containerized instances with authentication enabled.

Mitigation Strategy: Implement Role-Based Access Control (RBAC)

  • Description:
    1. Define Roles: Identify different user roles within your application's interaction with Cassandra (e.g., admin, read-only, application user).
    2. Create Cassandra Roles: Use CQL commands in cqlsh to create roles corresponding to your application roles. For example, CREATE ROLE 'app_read_role' WITH LOGIN = false;. Set LOGIN = false for roles not intended for direct user login.
    3. Grant Permissions to Roles: Grant specific permissions to each role based on the principle of least privilege within Cassandra. For example, GRANT SELECT ON KEYSPACE keyspace_name TO ROLE 'app_read_role';.
    4. Assign Roles to Users: Assign roles to Cassandra users. For example, GRANT ROLE 'app_read_role' TO 'application_user';.
    5. Application Integration: Ensure your application authenticates as a specific Cassandra user with assigned roles, rather than using a generic superuser account when connecting to Cassandra.
  • Threats Mitigated:
    • Privilege Escalation within Cassandra (Medium Severity): Limits the impact of compromised Cassandra accounts by restricting their permissions within Cassandra.
    • Accidental Data Modification/Deletion (Medium Severity): Reduces the risk of unintended data changes by users with overly broad Cassandra permissions.
    • Insider Threats (Medium Severity): Limits potential damage from malicious insiders with direct Cassandra access by enforcing least privilege within Cassandra.
  • Impact:
    • Privilege Escalation within Cassandra: Medium Risk Reduction
    • Accidental Data Modification/Deletion: Medium Risk Reduction
    • Insider Threats: Medium Risk Reduction
  • Currently Implemented: Partially implemented. Basic roles like admin and read-only are defined and used in production.
  • Missing Implementation: Granular roles for specific application functionalities are not fully defined and implemented within Cassandra's RBAC. Need to expand RBAC to cover more fine-grained permissions based on application features and user workflows interacting with Cassandra. Also, role management is currently manual; consider automating role assignment and revocation within Cassandra.

Mitigation Strategy: Enable Encryption in Transit (TLS/SSL) for Client-to-Node Communication

  • Description:
    1. Generate Keystore and Truststore: Create Java keystore and truststore files containing certificates for TLS/SSL. You can use keytool utility.
    2. Configure cassandra.yaml:
      • Set client_encryption_options.enabled: true.
      • Specify paths to your keystore and truststore files using client_encryption_options.keystore and client_encryption_options.truststore.
      • Set keystore and truststore passwords using client_encryption_options.keystore_password and client_encryption_options.truststore_password.
      • Configure cipher suites and protocols as needed in client_encryption_options.
    3. Restart Cassandra Nodes: Restart all Cassandra nodes for the changes to take effect.
    4. Configure Client Applications: Update your application's Cassandra driver configuration to enable TLS/SSL and point to the truststore containing the Cassandra server certificate to establish secure connections to Cassandra.
  • Threats Mitigated:
    • Eavesdropping on Cassandra Client Traffic (High Severity): Prevents attackers from intercepting and reading data transmitted between applications and Cassandra nodes.
    • Man-in-the-Middle (MITM) Attacks on Cassandra Client Connections (High Severity): Protects against attackers intercepting and manipulating communication between applications and Cassandra.
  • Impact:
    • Eavesdropping on Cassandra Client Traffic: High Risk Reduction
    • Man-in-the-Middle (MITM) Attacks on Cassandra Client Connections: High Risk Reduction
  • Currently Implemented: Yes, TLS/SSL is enabled for client-to-node communication in production and staging environments. Certificates are managed by our internal certificate authority.
  • Missing Implementation: Need to automate certificate rotation for TLS/SSL to ensure ongoing security and reduce manual maintenance for Cassandra client connections.

Mitigation Strategy: Enable Encryption in Transit (TLS/SSL) for Internode Communication

  • Description:
    1. Configure cassandra.yaml:
      • Set internode_encryption: all to encrypt all internode traffic within the Cassandra cluster. Alternatively, use dc or rack for more granular control if needed.
      • Configure keystore and truststore paths and passwords under server_encryption_options in cassandra.yaml, similar to client encryption.
    2. Restart Cassandra Nodes: Restart all Cassandra nodes in a rolling fashion to apply the configuration changes without downtime.
    3. Verify Configuration: After restart, check Cassandra logs to confirm that internode encryption is enabled and functioning correctly within the Cassandra cluster.
  • Threats Mitigated:
    • Eavesdropping on Cassandra Internode Traffic (Medium Severity): Prevents attackers who have compromised the internal network from eavesdropping on data exchanged between Cassandra nodes within the cluster.
    • Data Breaches within the Cassandra Cluster Network (Medium Severity): Reduces the risk of data leaks if internal network traffic between Cassandra nodes is compromised.
  • Impact:
    • Eavesdropping on Cassandra Internode Traffic: Medium Risk Reduction
    • Data Breaches within the Cassandra Cluster Network: Medium Risk Reduction
  • Currently Implemented: No, internode encryption is currently not implemented in any environment.
  • Missing Implementation: Internode encryption needs to be implemented in production and staging environments. This is a critical missing Cassandra-specific security measure, especially in environments where network security within the Cassandra cluster is not fully trusted or in cloud environments. Implementation should be prioritized.