Audit logs from all Palantir platforms are first written to disk and then archived to a stack-specific storage bucket within 24 hours of being written (AWS S3, Azure Blob Storage, or on-premises storage). Access to these buckets is aggressively restricted. Palantir customers have the option to enable audit infrastructure that will export audit logs from the archive to a per-organization dataset for analysis within Foundry or a downstream SIEM. Refer to audit delivery for instructions on setting up an audit export dataset and the resulting dataset schema. Audit logs are engineered to be append-only throughout their lifecycle as to ensure their integrity for analysis.
Upon ingesting Foundry’s audit logs, customers generally have three priorities which represent the majority of audit log analysis efforts:
Reviewing audit logs in the context of security might involve searching for unsanctioned login activity, or deletion of sensitive data.
Foundry is a powerful tool, and provides immense visibility to the user. If a customer deals with sensitive, or regulated data, they often find it prudent to review audit logs to maintain oversight of their users’ behavior.
Certain organizations may want to glean visibility into how their users are operating the Foundry platform (number of users, frequency of certain actions, etc.). Foundry audit logs can provide the desired visibility into a given platform.
Audit logs are generally divided into audit categories, which are a means of categorizing an event type as reflecting a certain family of activity (for example, data creation, user login, etc.), and audit categories are shared between the core Foundry services (such as Multipass, Compass, and Blobster). Any auditable event should be describable through a union of audit categories.
Operating on the basis of categories will assist analysts in discerning which events & event types are relevant to their search. The following examples include a handful of the more commonly-searched categories in Foundry’s audit logging:
| Category | Description | Parameters | Examples |
|---|---|---|---|
| authenticationCheck | Checks authentication status via a programmatic or manual authentication event, such as token validation. | User ID, username, session ID (if known), realm (palantir, customer network, service user, etc.) | Multipass' token validity endpoint |
| dataCreate | Indicates the addition of some new entry of data into the platform. | spaceRid, organizationMarkingIds, organizationMarkingIds, etc | Foundry catalog's create dataset endpoint |
| dataDelete | Any action taken to purge data from the system. | Deleted resource IDs | Compass delete endpoint |
| dataExport | Any action taken to transfer data out of the system. | Resource ID, size | Blobster's export endpoint |
| dataImport | Any action taken to upload external data into the system. | File name, File type, resource ID, containing folder ID, size | Blobster's upload endpoints |
| tokenGeneration | An attempt to generate a new JSON Web Token (JWT) in the system. | Token ID, Token time-to-live, Token type | Multipass' various token creation endpoints |
| userLogin | A login attempt. | User ID, username, session ID, realm | Multipass' login endpoint |
| userLogout | A logout attempt. | User ID, username, session ID, realm | Multipass' logout endpoint |
For the complete list of available categories, refer to audit log categories.
As part of Foundry’s shared security model, Information Security Engineers at Palantir also ingest audit logs for each hosted customer’s Foundry platform. These logs are primarily infrastructure-level events, and do not contain customer data.
Palantir’s Computer Incident Response Team (CIRT) maintains internal alerting & detection strategies ↗ targeted towards activity on our hosted customer platforms. In the event that Palantir’s CIRT identifies an alert reflecting suspicious activity on a customer’s platform, the customer will be contacted to reconcile the activity.
We encourage our customers to author their own audit log security alerts in accordance with their understanding of a known-good activity baseline, in order to self-identify any anomalous actions.