Skip to content

Latest commit

 

History

History
192 lines (149 loc) · 12 KB

mitigations.md

File metadata and controls

192 lines (149 loc) · 12 KB

Mitigation Strategies Analysis for apache/spark

Mitigation Strategy: Authentication and Authorization (Fine-Grained Access Control)

  • Mitigation Strategy: Fine-Grained Access Control with Spark's Security Manager and Kerberos.

  • Description:

    1. Enable Authentication: Set spark.authenticate=true in spark-defaults.conf. This forces Spark components to authenticate with each other.
    2. Configure Kerberos:
      • Install and configure a Kerberos Key Distribution Center (KDC).
      • Create Kerberos principals for Spark users and services (driver, executors, history server).
      • Distribute keytabs to the appropriate nodes.
      • Set spark.kerberos.principal and spark.kerberos.keytab in spark-defaults.conf or in the application's configuration.
    3. Enable ACLs: Set spark.acls.enable=true in spark-defaults.conf.
    4. Define View ACLs: Use spark.ui.view.acls to specify users/groups allowed to view the Spark UI. Example: spark.ui.view.acls=data_scientists,admins.
    5. Define Modify ACLs: Use spark.modify.acls to specify users/groups allowed to modify running applications (e.g., kill jobs). Example: spark.modify.acls=admins.
    6. Define Admin ACLs: Use spark.admin.acls for administrative actions. Example: spark.admin.acls=super_admins.
    7. Test: Thoroughly test the configuration to ensure that only authorized users can perform the intended actions.

  • Threats Mitigated:

    • Unauthorized Job Submission (High Severity): Prevents attackers from submitting malicious Spark jobs.
    • Unauthorized Job Modification (High Severity): Prevents attackers from killing or altering running jobs.
    • Unauthorized Access to Spark UI (Medium Severity): Prevents attackers from viewing sensitive information in the Spark UI.
    • Data Exfiltration via Malicious Jobs (High Severity): Limits who can submit jobs, reducing exfiltration risk.

  • Impact:

    • Unauthorized Job Submission: Risk reduced significantly (e.g., 90%).
    • Unauthorized Job Modification: Risk reduced significantly (e.g., 95%).
    • Unauthorized Access to Spark UI: Risk reduced significantly (e.g., 85%).
    • Data Exfiltration via Malicious Jobs: Risk reduced significantly (e.g., 80%).

  • Currently Implemented:

    • Authentication (spark.authenticate) is enabled.
    • Kerberos integration is implemented for the production cluster.
    • Basic view ACLs (spark.ui.view.acls) are configured.

  • Missing Implementation:

    • Modify ACLs (spark.modify.acls) are not implemented.
    • Admin ACLs (spark.admin.acls) are not implemented.
    • Staging and development clusters lack consistent Kerberos/ACL configuration.

Mitigation Strategy: Network Encryption (Internal Communication)

  • Mitigation Strategy: Enable Spark's Internal Communication Encryption.

  • Description:

    1. Enable Crypto: Set spark.network.crypto.enabled=true in spark-defaults.conf.
    2. Configure Key Length: Set spark.network.crypto.keyLength to a secure value (e.g., 256).
    3. Configure Key Factory Algorithm: Set spark.network.crypto.keyFactoryAlgorithm (e.g., PBKDF2WithHmacSHA256).
    4. Configure SASL: Ensure SASL is properly configured (often automatic with Kerberos).
    5. Test: Verify encrypted communication between Spark components.

  • Threats Mitigated:

    • Man-in-the-Middle (MITM) Attacks (High Severity): Prevents interception of data between Spark components.
    • Data Snooping on the Network (Medium Severity): Protects sensitive data during shuffle operations.
    • Credential Sniffing (High Severity): Protects credentials if transmitted (though secret management should prevent this).

  • Impact:

    • MITM Attacks: Risk reduced significantly (e.g., 95%).
    • Data Snooping: Risk reduced significantly (e.g., 90%).
    • Credential Sniffing: Risk reduced significantly (e.g., 95%).

  • Currently Implemented:

    • spark.network.crypto.enabled is set to true in production.
    • Default key length and algorithm settings are used.

  • Missing Implementation:

    • Staging and development clusters lack consistent encryption.
    • Regular review of encryption settings is not formalized.

Mitigation Strategy: Data Serialization Security

  • Mitigation Strategy: Avoid Java Serialization; Use Safer Alternatives and Validate Kryo Classes.

  • Description:

    1. Prefer Safer Formats: Use JSON, Avro, Parquet, or ORC.
    2. Avoid Java Serialization: If possible, avoid it entirely.
    3. Kryo (If Necessary):
      • Register only needed classes: spark.kryo.registrationRequired=true and spark.kryo.classesToRegister.
      • Do not use spark.kryo.unsafe=true unless absolutely necessary.
      • Keep Kryo updated.
      • Consider a custom serializer with input validation.
    4. Input Validation: Validate all input data.

  • Threats Mitigated:

    • Remote Code Execution (RCE) via Deserialization (Critical Severity):
    • Data Corruption (Medium Severity):
    • Denial of Service (DoS) (Medium Severity):

  • Impact:

    • RCE via Deserialization: Risk significantly reduced (e.g., 80-95%).
    • Data Corruption: Risk reduced (e.g., 70%).
    • DoS: Risk reduced (e.g., 60%).

  • Currently Implemented:

    • The project primarily uses Parquet.
    • Kryo is used in some cases, but spark.kryo.registrationRequired is not enabled.

  • Missing Implementation:

    • spark.kryo.registrationRequired=true needs to be enabled, with a maintained list of allowed classes.
    • Formal review process for Kryo configuration is missing.
    • Input validation is inconsistent.

Mitigation Strategy: Event Log Encryption and Authentication

  • Mitigation Strategy: Encrypt and Authenticate Access to Spark Event Logs

  • Description:

    1. Enable Encryption: Set spark.eventLog.encrypt=true in spark-defaults.conf.
    2. Configure Encryption Keys: Configure appropriate encryption keys for event log encryption. The specifics depend on the chosen encryption method.
    3. Secure Storage: Ensure the event log directory (specified by spark.eventLog.dir) is secure.
      • Use appropriate file system permissions.
      • If stored remotely (e.g., HDFS), use the storage system's access controls.
      • Consider using encryption at rest for the storage location.
    4. Authenticated Access: Control access to the event logs using the storage system's authentication and authorization mechanisms (e.g., Kerberos for HDFS).

  • Threats Mitigated:

    • Unauthorized Access to Historical Job Data (Medium Severity): Event logs can contain sensitive information about past jobs, including configuration details and potentially data samples.
    • Data Leakage (Medium Severity): Attackers could gain insights into the application's data and logic by analyzing event logs.
    • Tampering with Event Logs (Low Severity): Encryption and access controls help prevent unauthorized modification of event logs, which could be used to cover up malicious activity.

  • Impact:

    • Unauthorized Access: Risk reduced significantly (e.g., 90%).
    • Data Leakage: Risk reduced significantly (e.g., 85%).
    • Tampering: Risk reduced (e.g., 75%).

  • Currently Implemented:

    • Event logging is enabled (spark.eventLog.enabled=true).
    • The event logs are stored on HDFS with basic HDFS permissions.

  • Missing Implementation:

    • spark.eventLog.encrypt=true is not set. Event logs are stored in plain text. This is a major vulnerability.
    • Strong authentication and authorization for accessing the event logs on HDFS are not fully enforced.
    • Encryption at rest for the HDFS directory is not configured.

Mitigation Strategy: Dynamic Allocation Security

  • Mitigation Strategy: Configure Limits for Dynamic Allocation

  • Description:

    1. Set Maximum Executors: Use spark.dynamicAllocation.maxExecutors to limit the maximum number of executors that can be allocated to an application.
    2. Configure Idle Timeout: Use spark.dynamicAllocation.executorIdleTimeout to specify how long an executor can be idle before it's released.
    3. Initial Executors (Optional): Use spark.dynamicAllocation.initialExecutors to set a reasonable starting number of executors.
    4. Scheduler Backend: Ensure your scheduler backend (YARN, Kubernetes, Mesos) is also configured with appropriate resource limits.
    5. Monitor: Actively monitor resource usage to detect anomalies.

  • Threats Mitigated:

    • Resource Exhaustion (Denial of Service) (Medium Severity): Prevents a single application from consuming all cluster resources, potentially impacting other applications.
    • Cost Overruns (Low Severity): In cloud environments, uncontrolled resource allocation can lead to unexpected costs.

  • Impact:

    • Resource Exhaustion: Risk reduced significantly (e.g., 80%) by setting appropriate limits.
    • Cost Overruns: Risk reduced (e.g., 70%) by controlling resource usage.

  • Currently Implemented:

    • Dynamic allocation is enabled (spark.dynamicAllocation.enabled=true).
    • spark.dynamicAllocation.executorIdleTimeout is set.

  • Missing Implementation:

    • spark.dynamicAllocation.maxExecutors is not set, or is set to a very high value. This allows for potential resource exhaustion.
    • spark.dynamicAllocation.initialExecutors is not configured.
    • Regular monitoring of resource usage specifically for dynamic allocation is not formalized.

Mitigation Strategy: Secure Temporary File Handling

  • Mitigation Strategy: Secure Spark's Temporary File Directories

  • Description:

    1. Configure spark.local.dir: Set spark.local.dir in spark-defaults.conf to point to a secure directory.
    2. Permissions: Ensure this directory has restrictive file system permissions, allowing access only to the user running the Spark application.
    3. Encryption: Consider using an encrypted file system or volume for spark.local.dir.
    4. Ephemeral Storage: If possible, use a dedicated, ephemeral storage volume that is automatically wiped after the job completes.
    5. Avoid shared directories: Do not use shared directories like /tmp for spark.local.dir.

  • Threats Mitigated:

    • Data Leakage (Medium Severity): Temporary files can contain intermediate data that could be sensitive.
    • Unauthorized Access to Intermediate Data (Medium Severity): Attackers could potentially access or modify temporary files.
    • Disk Space Exhaustion (Low Severity): Uncontrolled temporary file creation could fill up the disk.

  • Impact:

    • Data Leakage: Risk reduced (e.g., 75%) by using secure directories and encryption.
    • Unauthorized Access: Risk reduced significantly (e.g., 85%) with proper permissions.
    • Disk Space Exhaustion: Risk reduced (e.g., 60%) by using dedicated, potentially ephemeral, storage.

  • Currently Implemented:

    • spark.local.dir is set to a specific directory.

  • Missing Implementation:

    • The directory specified by spark.local.dir does not have sufficiently restrictive permissions. Other users on the system might be able to access it.
    • Encryption is not used for the spark.local.dir directory.
    • Ephemeral storage is not used.