Skip to content

Latest commit

 

History

History
96 lines (83 loc) · 10.1 KB

threat-modeling.md

File metadata and controls

96 lines (83 loc) · 10.1 KB

Threat Model Analysis for habitat-sh/habitat

Threat: Threat 1: Malicious Supervisor Impersonation

  • Description: An attacker crafts and runs a rogue Supervisor process that mimics a legitimate Supervisor. The attacker could use this to join the Habitat ring (gossip network) and inject false service status, configuration data, or even attempt to intercept or redirect traffic intended for legitimate services. The attacker might try to exploit vulnerabilities in the gossip protocol or bypass authentication mechanisms.
    • Impact:
      • Service disruption or complete outage.
      • Data corruption or loss due to incorrect configuration.
      • Potential for man-in-the-middle attacks if the rogue Supervisor can intercept traffic.
      • Compromise of other Supervisors if the rogue Supervisor can exploit vulnerabilities in them.
    • Affected Habitat Component: Supervisor (specifically, the hab-sup process and its gossip protocol implementation, including authentication and peer validation logic).
    • Risk Severity: Critical
    • Mitigation Strategies:
      • Strong Mutual Authentication: Enforce mTLS (mutual TLS) between all Supervisors. Each Supervisor should have a unique, verifiable certificate.
      • Gossip Protocol Hardening: Implement robust peer validation within the gossip protocol to detect and reject unauthorized Supervisors. This might include checking against a known list of allowed Supervisors or using a more sophisticated trust model.
      • Supervisor Configuration Auditing: Regularly audit the configuration of all Supervisors to ensure they are correctly configured and haven't been tampered with.
      • Network Segmentation: Isolate the Habitat ring's network traffic to limit the impact of a compromised Supervisor.

Threat: Threat 2: Origin Spoofing (Deceptive Origin Names)

  • Description: An attacker creates a Habitat origin with a name that is visually similar to a legitimate, trusted origin (e.g., my-company vs. my_company). They then publish malicious packages under this deceptive origin. Users or automated systems might be tricked into installing these packages, believing they are from the trusted source.
    • Impact:
      • Installation of malicious software, leading to system compromise.
      • Data theft or destruction.
      • Reputational damage to the legitimate origin owner.
    • Affected Habitat Component: Origin naming convention, Depot (package repository), hab pkg install command (and any tooling that uses it).
    • Risk Severity: High
    • Mitigation Strategies:
      • User Education: Train users and administrators to carefully verify origin names before installing packages.
      • Origin Key Verification: Enforce strict origin key signing and verification. The hab CLI should always verify the signature of a package against the origin's public key before installation.
      • Private Depot: Use a private, on-premise Habitat Depot with strict access controls to limit the risk of unauthorized origin creation.
      • Origin Name Restrictions: Implement policies or technical controls to prevent the creation of origins with deceptively similar names.

Threat: Threat 3: Package Tampering (Post-Build, Pre-Deployment)

  • Description: An attacker gains access to a .hart file after it has been built and signed by the Builder, but before it is deployed to a Supervisor. The attacker modifies the package contents, injecting malicious code or altering the application's configuration. This could happen in transit (e.g., during download from the Depot) or at rest (e.g., if the Depot itself is compromised).
    • Impact:
      • Execution of malicious code on the target system.
      • Data breaches or data corruption.
      • System instability or denial of service.
    • Affected Habitat Component: .hart file (package), Depot (storage), hab pkg install (installation process), Supervisor (package verification).
    • Risk Severity: Critical
    • Mitigation Strategies:
      • Enforce Signature Verification: The Supervisor must verify the digital signature of the .hart file against the origin's public key before running the package. This is Habitat's primary defense against tampering. Ensure this verification is never bypassed.
      • Secure Transport: Use HTTPS with strong TLS configurations for all communication between the Builder, Depot, and Supervisors.
      • Depot Integrity Monitoring: Implement file integrity monitoring on the Depot to detect any unauthorized modifications to .hart files.
      • Checksum Verification: Before installation, independently verify the checksum of the downloaded .hart file against a trusted source (if available).

Threat: Threat 4: Configuration Tampering via Gossip

  • Description: An attacker compromises a Supervisor (or successfully impersonates one) and uses it to inject malicious configuration changes into the Habitat ring. These changes are then propagated to other Supervisors via the gossip protocol, potentially affecting multiple services. The attacker might target specific configuration settings to disrupt services, steal data, or gain further access.
    • Impact:
      • Service misconfiguration, leading to outages or unexpected behavior.
      • Data breaches if sensitive configuration data is altered.
      • Potential for privilege escalation if the attacker can modify security-related settings.
    • Affected Habitat Component: Supervisor (gossip protocol implementation, configuration management system).
    • Risk Severity: High
    • Mitigation Strategies:
      • Signed Configuration Updates: Digitally sign all configuration updates using a trusted key. Supervisors should verify the signature before applying the update.
      • Quorum-Based Configuration: Implement a quorum-based approach for applying configuration changes. Require agreement from a majority (or a specific number) of Supervisors before a change is applied.
      • Configuration Change Auditing: Log all configuration changes, including the source, timestamp, and the Supervisors that applied the change.
      • Limit Gossip Scope: Restrict the types of configuration changes that can be propagated via gossip. Sensitive configuration should be handled through a more secure channel (e.g., a dedicated configuration management system).

Threat: Threat 6: Builder Compromise (Malicious Package Injection)

  • Description: An attacker gains control of the Habitat Builder infrastructure. This allows them to inject malicious code into packages before they are signed with the origin key. This is a very high-impact threat because the resulting packages will appear legitimate (they will have a valid signature), but they will contain the attacker's code.
    • Impact:
      • Widespread distribution of malicious software.
      • Complete compromise of all systems running the affected packages.
      • Severe reputational damage.
    • Affected Habitat Component: Builder (entire build pipeline), origin signing keys.
    • Risk Severity: Critical
    • Mitigation Strategies:
      • Secure Builder Infrastructure: Treat the Builder as a critical, high-security system. Implement strict access controls, network segmentation, and robust monitoring.
      • Multi-Factor Authentication: Require multi-factor authentication for all access to the Builder.
      • Build Process Auditing: Implement comprehensive auditing of the entire build process, including all code changes, build steps, and signing operations.
      • HSM for Origin Keys: Protect the origin signing keys using a Hardware Security Module (HSM) to prevent them from being stolen or misused.
      • Build Provenance: Implement build provenance tracking to ensure traceability of all build artifacts and dependencies. This helps to verify that the build process hasn't been tampered with.
      • Independent Verification: Implement a multi-stage build process with independent verification steps. For example, have a separate system that verifies the integrity of the built package before it is signed.

Threat: Threat 9: Depot Unavailability

  • Description: The Habitat Depot (either on-premise or SaaS) becomes unavailable due to a denial-of-service attack, network outage, hardware failure, or other issue. Supervisors are unable to download new packages, updates, or dependencies.
    • Impact:
      • Inability to deploy new applications or updates.
      • Existing applications may continue to run, but cannot be updated or scaled.
      • Potential for security vulnerabilities if updates cannot be applied.
    • Affected Habitat Component: Depot, Supervisor (hab pkg install, update mechanisms).
    • Risk Severity: High
    • Mitigation Strategies:
      • High Availability Depot: Use a highly available Depot infrastructure with redundancy and failover capabilities.
      • Caching: Implement caching mechanisms (e.g., a local proxy or caching within the Supervisor) to reduce reliance on the Depot for frequently accessed packages.
      • Offline Operation: Design applications and deployment processes to be as resilient as possible to Depot unavailability. This might involve pre-downloading necessary packages or having a fallback mechanism for obtaining updates.
      • Monitoring and Alerting: Implement robust monitoring and alerting for the Depot to detect and respond to availability issues quickly.
      • Backup and Recovery: Have a plan for backing up and restoring the Depot in case of a catastrophic failure.