Protecting your self-hosted Foundry installation

Palantir Foundry is designed to provide secure collaboration in almost any environment, from the cloud to the edge. If you are running Foundry outside of Palantir’s managed SaaS platform, such as in your own datacenter or on your own cloud, observe the following guidance for protecting your installation.

Physical access

If your Foundry installation is deployed on bare-metal hardware, such as in a datacenter, it is crucial you implement strong physical security controls. Access to servers running Foundry should be restricted to authorized personnel, have time-bound and documented access, and follow industry best practices.

As physical security is foundational to information security, unauthorized access to the hardware running Foundry could allow an adversary the opportunity to perform various attacks and subvert security controls.

Data encryption

To maintain information security, your data must be encrypted both at rest and in transit.

Data at rest

While all data in Foundry is encrypted at-rest using application-level encryption, you should encrypt all underlying servers and storage devices used in your Foundry installation.

  • You should use an industry-standard encryption solution for full-disk encryption. This could include open source projects (such as LUKS ↗), commercially available software, hardware implementations like self-encrypting drives, or solutions offered by cloud service providers.
  • You should store cryptographic key material in hardware, such as a hardware security module (HSM).
  • You should use strong cryptographic standards for disk encryption, such as AES-256 or AES-128.

Data in transit

All data transmitted between your clients and Foundry should be protected using strong encryption protocols and ciphers.

  • You should use a valid certificate issued by a trusted certificate authority with a lifespan of 90 days, up to a maximum lifespan of one year.
  • You should only support connections using transport layer security (TLS) versions 1.2 or higher.
  • You should only support strong TLS cipher suites. You should adjust this based upon compatibility and security needs.
  • We recommend using elliptical curve Diffie-Hellman exchange (ECDHE) with CHACHA-POLY1305 or AES-{128-256} in GCM mode. CBC-mode cipher suites should be avoided where possible.

Identity security

Single sign-on

You should centrally manage identities in your single sign-on provider.

  • All users should be required to use named accounts. Accounts should not be shared.
  • You should require strong multi-factor authentication for all users. Where possible, modern technologies like FIDO2 should be used. SMS- or email-based multi-factor authentication should not be used.

Credential hygiene

You should require your users to have strong credential hygiene. Passwordless authentication is strongly recommended.

  • You should require your users to have a sufficiently strong, long, and unique password for access.
  • You should not let your users reuse their password with other services outside your environment.
  • You should require your users to rotate passwords if they are accidentally entered on an unauthorized domain.

Zero trust

You should use modern zero trust technologies to protect your Foundry installation.

  • You should use zero trust technologies to only allow access to authorized users on the basis of identity and device health and verification.
  • You should deny access to your Foundry installation from untrusted, unhealthy, or unknown devices.

Network security

Network segmentation

Your Foundry installation should be highly segmented from the rest of your environment.

  • Network isolation should be implemented using firewalls or other technology. An allowlist of approved protocols, ports, and subnets should be used to gate access to services.
  • You should deny all inbound traffic by default to your Foundry installation.
  • You should only expose your Foundry installation to the minimum set of networks where possible. It is not recommended to expose your Foundry installation to the public internet without additional controls in place, such as intrusion detection systems and web application firewalls.
  • You should silo off your Foundry installation in a dedicated private network (VLAN/subnet).

Egress controls

Network traffic originating from your Foundry installation should be strictly controlled.

  • You should require all network connections from Foundry to be gated by a proxy or other network security device.
  • You should maintain an allowlist of permitted destinations by IP or domain to which your Foundry installation can connect.
  • You should deny all other network access by your Foundry installation.

Network security

You should use network security controls to protect your Palantir Foundry installation.

  • You should use network security controls, such as intrusion detection systems, to identify anomalous activity.
  • You should use firewalls to identify and block network exploitation or attack attempts.
  • You should use data-loss prevention (DLP) technologies to look for unauthorized data transfers.
  • You should collect network security logs from your networks to identify anomalous activity.

Infrastructure security

Server hardening

The servers used for your Foundry installation should be hardened using industry-standard configuration guidance such as CIS or NIST controls.

  • You should only use a modern, supported operating system.
  • You should perform aggressive vulnerability management and patching on the hosts used for your Foundry installation. Critical security vulnerabilities should be patched in 30 days or less.

Host security

You should use host security controls to protect your Foundry installation.

  • You should collect audit and security logs from your hosts to identify anomalous activity.
  • You should use host-based security controls, such as intrusion detection systems, to identify anomalous activity.
  • You should use data-loss prevention (DLP) technologies to look for unauthorized data transfers.

Privileged access

You should strictly control privileged access to your Foundry installation.

  • The backend infrastructure hosting your Foundry installation should be restricted to be accessible exclusively via dedicated bastion servers or jump hosts.
  • Multi-factor authentication should be required for all infrastructure or cloud-level access to your Foundry installation.

Backups

You should take periodic full-disk backups of your Foundry installation for organizational continuity purposes.

  • Foundry has a service (“Rescue”) that is designed to perform application backups and restoration.
  • You should minimally perform full-disk backups of Rescue service data. It is highly recommended to perform full-disk backups of all Foundry hosts.
  • You should encrypt your backups and ensure they are stored in a durable and/or offline location. Ransomware and other malicious actors typically try to destroy backups before performing other malicious actions.
  • You should test your backup and restoration process at least annually.

Application patching

You should apply security patches to your Foundry installation as soon as possible.

  • If your Foundry installation is Apollo-connected, your Foundry installation will automatically receive security updates. These updates generally do not require action from you.
  • If you do not use Apollo, you should apply security updates as soon as they are made available. Critical security vulnerabilities should be patched in 30 days or less.