Skip to content

Latest commit

 

History

History
148 lines (112 loc) · 10.6 KB

mitigations.md

File metadata and controls

148 lines (112 loc) · 10.6 KB

Mitigation Strategies Analysis for elastic/elasticsearch

Mitigation Strategy: Enable and Configure Security Features

Mitigation Strategy: Enable and fully configure Elasticsearch's built-in security features (authentication, authorization, TLS).

Description:

  1. Enable Security: Modify the elasticsearch.yml file on every node in the cluster. Set xpack.security.enabled: true. Restart each node.
  2. Initial Setup: Use the elasticsearch-setup-passwords utility (or manual API calls) to set passwords for built-in users (elastic, kibana, logstash_system, etc.). Immediately change the default elastic password.
  3. Create Application User: Create a dedicated user for your application with the minimum necessary privileges. Never use the elastic user for application access. Use the Elasticsearch API or Kibana to manage users.
  4. Define Roles: Create roles that map to specific application functions (e.g., "data_reader," "data_writer," "index_admin"). Assign granular permissions to each role using the Elasticsearch API or Kibana. Permissions include cluster-level, index-level, and potentially field/document-level access control.
  5. Assign Roles to Users: Assign the appropriate roles to the application user and any other users who need access to Elasticsearch via the API or Kibana.
  6. Enable TLS: Configure TLS for both the transport layer (node-to-node communication) and the HTTP layer (client-to-node communication). Generate certificates, configure elasticsearch.yml with the certificate paths (xpack.security.transport.ssl.* and xpack.security.http.ssl.* settings).
  7. Regular Audits: Regularly (e.g., monthly) review user accounts, roles, and permissions using the Elasticsearch API or Kibana. Remove inactive users and refine permissions.

Threats Mitigated:

  • Unauthorized Access (Severity: Critical): Prevents access without valid credentials managed within Elasticsearch.
  • Data Breaches (Severity: Critical): Limits data access based on roles defined within Elasticsearch.
  • Privilege Escalation (Severity: High): Prevents users from gaining more privileges than assigned through Elasticsearch's role management.
  • Data Tampering (Severity: High): Limits data modification based on roles defined within Elasticsearch.
  • Man-in-the-Middle Attacks (Severity: High): TLS encryption, configured within Elasticsearch, prevents eavesdropping.

Impact:

  • Unauthorized Access: Risk reduced from Critical to Low (with proper role configuration).
  • Data Breaches: Risk reduced from Critical to Low (with proper role and FLS/DLS configuration).
  • Privilege Escalation: Risk reduced from High to Low.
  • Data Tampering: Risk reduced from High to Low.
  • Man-in-the-Middle Attacks: Risk reduced from High to Negligible.

Currently Implemented:

  • Security is enabled in elasticsearch.yml on all nodes.
  • Basic roles ("reader," "writer") are defined.
  • TLS is enabled for the HTTP layer.

Missing Implementation:

  • TLS is not enabled for the transport layer (inter-node communication).
  • Roles are not granular enough; "writer" role has too many permissions.
  • No regular audit process for user accounts and roles.
  • Application still uses a user with excessive privileges.

Mitigation Strategy: Resource Limits (Circuit Breakers & Query Settings)

Mitigation Strategy: Configure Elasticsearch's built-in resource limits to prevent denial-of-service.

Description:

  1. Circuit Breakers: Modify elasticsearch.yml to set appropriate limits for circuit breakers. Key settings include:
    • indices.breaker.total.limit: Overall memory limit.
    • indices.breaker.request.limit: Per-request memory limit.
    • indices.breaker.fielddata.limit: Field data memory limit.
    • Start with conservative values and adjust based on monitoring data from Elasticsearch itself.
  2. Query Complexity: Limit the complexity of boolean queries using indices.query.bool.max_clause_count in elasticsearch.yml.
  3. Concurrent Searches: Control concurrent searches and shards per search using settings like search.max_concurrent_shard_requests in elasticsearch.yml.
  4. Dynamic Updates: Use the Cluster Update Settings API to adjust these limits dynamically without restarting, based on real-time monitoring data from Elasticsearch.

Threats Mitigated:

  • Denial of Service (DoS) Attacks (Severity: High): Prevents resource-intensive queries from overwhelming the Elasticsearch cluster itself.
  • Resource Exhaustion (Severity: High): Prevents legitimate users from accidentally consuming all resources within Elasticsearch.

Impact:

  • Denial of Service (DoS) Attacks: Risk reduced from High to Medium.
  • Resource Exhaustion: Risk reduced from High to Low.

Currently Implemented:

  • Default circuit breaker settings are in place.

Missing Implementation:

  • Circuit breaker settings have not been tuned.
  • indices.query.bool.max_clause_count is not explicitly set.
  • No dynamic adjustment of limits based on monitoring.

Mitigation Strategy: Scripting Controls (Disable Dynamic or Use Painless Securely)

Mitigation Strategy: Disable dynamic scripting if possible; if required, use only Painless and sanitize all inputs within the context of Elasticsearch.

Description:

  1. Disable Dynamic Scripting (Preferred): In elasticsearch.yml, set script.allowed_types: none. This is the most secure option.
  2. Use Painless (If Necessary): If scripting is required, use only Painless.
  3. Parameterized Scripts: Use the params object to pass values to Painless scripts, rather than embedding them directly in the script code. This is handled within the Elasticsearch query/script context.
  4. Contextual Input Validation: While general input validation is important, focus on validating inputs within the context of the Painless script to ensure they are safe for use within Elasticsearch's scripting engine. This might involve checking data types or lengths before they are used in script logic.

Threats Mitigated:

  • Remote Code Execution (RCE) (Severity: Critical): Prevents arbitrary code execution on the Elasticsearch nodes.
  • Script Injection (Severity: High): Prevents malicious code injection into Elasticsearch scripts.
  • Data Exfiltration/Tampering (Severity: High): Limits the ability to use scripts for unauthorized data access or modification within Elasticsearch.

Impact:

  • Remote Code Execution (RCE): Risk reduced from Critical to Negligible (disabled) or Low (Painless, secure use).
  • Script Injection: Risk reduced from High to Low.
  • Data Exfiltration/Tampering: Risk reduced from High to Low.

Currently Implemented:

  • The application does not use dynamic scripting.

Missing Implementation:

  • script.allowed_types is not explicitly set to none.

Mitigation Strategy: Field and Document Level Security (FLS/DLS)

Mitigation Strategy: Implement Field Level Security (FLS) and Document Level Security (DLS) to restrict access to specific data within indices.

Description:

  1. Field Level Security (FLS): Define roles (using the Elasticsearch API or Kibana) that restrict access to specific fields within documents. For example, hide sensitive fields like PII from certain roles. This is configured entirely within Elasticsearch.
  2. Document Level Security (DLS): Define roles that restrict access to entire documents based on queries. For example, only allow users to see documents related to their department. This is also configured entirely within Elasticsearch.
  3. Role-Based Access Control (RBAC): FLS and DLS are implemented as part of Elasticsearch's RBAC system. Carefully design your roles and permissions to enforce the principle of least privilege.
  4. Data Modeling: Consider how your data is structured and indexed to best support FLS and DLS.

Threats Mitigated:

  • Data Breaches (Severity: Critical): Even if an attacker gains access to an index, FLS/DLS limits the data they can see within that index.
  • Unauthorized Data Access (Severity: High): Prevents users from accessing sensitive fields or documents they shouldn't see, even if they have access to the index.
  • Data Tampering (Severity: High): While FLS/DLS primarily control read access, they indirectly limit tampering by restricting what data is visible for modification.

Impact:

  • Data Breaches: Risk reduced from Critical to Low (in conjunction with other security measures).
  • Unauthorized Data Access: Risk reduced from High to Low.
  • Data Tampering: Risk reduced from High to Medium (requires additional write access controls).

Currently Implemented:

  • None.

Missing Implementation:

  • FLS and DLS are not implemented. All users with read access to an index can see all fields and documents.

Mitigation Strategy: Audit Logging

Mitigation Strategy: Enable and configure Elasticsearch's built-in audit logging.

Description:

  1. Enable Audit Logging: In elasticsearch.yml, set xpack.security.audit.enabled: true.
  2. Configure Output: Choose where audit logs are stored (e.g., file, index). Configure settings like xpack.security.audit.outputs.
  3. Log Retention: Configure audit log retention policies to meet compliance requirements and manage storage space.
  4. Index Audit Logs (Optional): If storing audit logs in an index, use Index Lifecycle Management (ILM) to manage the lifecycle of the audit log indices (rollover, deletion, etc.).

Threats Mitigated:

  • Non-Repudiation (Severity: Medium): Provides a record of actions performed on the cluster, making it difficult to deny actions.
  • Intrusion Detection (Severity: Medium): Audit logs can be used to detect suspicious activity and potential security breaches.
  • Compliance (Severity: Varies): Helps meet compliance requirements that mandate audit logging.

Impact:

  • Non-Repudiation: Risk reduced from Medium to Low.
  • Intrusion Detection: Risk reduced from Medium to Low (when combined with active monitoring of logs).
  • Compliance: Risk reduced to meet specific compliance requirements.

Currently Implemented:

  • None.

Missing Implementation:

  • Audit logging is not enabled. There is no record of actions performed on the cluster.