How to Configure Log Storage

How we approach logging and audit:

Logging and audit are critical to StrongDM’s operational and design principles. StrongDM is designed to protect user logs in transit and at rest and allows you to configure logging according to your business and operational requirements. The StrongDM proxy is also designed to “fail closed” in the case that it is unable to produce logs as configured; this design decision ensures that all access is auditable by default.

Log destination options:

You can choose to log with the StrongDM Platform, log local to your infrastructure, or both. Logs stored with the StrongDM Platform are written to an immutable, write-once S3 bucket. When you choose to log locally, logs are written to the StrongDM proxy’s local storage. This allows you to configure how and where to ship logs.

Log encryption options:

Logs with StrongDM are always encrypted at some level. We support three different methods of encryption within the StrongDM Platform.

1. Platform Encryption: Logs generated by the StrongDM Platform are encrypted with a Customer-unique key by the StrongDM application before being written to AWS S3, on top of the default at rest encryption enabled on the S3 bucket. Using the StrongDM Platform encryption provides two key functions: logs are able to be displayed in the Admin UI in plaintext, and logs cannot be viewed in plaintext from the raw storage (AWS S3). By encrypting all logs with a unique application key, StrongDM is able to provide another layer of assurance that Customer information is not inadvertently disclosed.
2. Public Key Encryption: Log data from the StrongDM gateway is encrypted at the StrongDM Gateway using the public component of a public/private key pair before being sent to the StrongDM Platform. In this case, log metadata is still sent to StrongDM for plaintext display within the Admin UI. When using public key encryption to protect log data, log contents will be returned in encrypted form in the AdminUI and as query results from an sdm CLI command. Metadata will be present in the AdminUI in plain text, and Customer administrators must use the private component of the key pair to decrypt the log contents for review. StrongDM will never be able to see the plain text log contents.
3. Non-shared Symmetric Key Encryption (Combined with local logging): In this situation, only session metadata will be sent to StrongDM for display in the Admin UI. StrongDM does not have access to the key used to encrypt the data. The logs will be sent, encrypted, to your Gateway/Relay servers, where you will be able to decrypt it locally.

Log retention in StrongDM Platform:

If you store logs with the StrongDM Platform, they will be retained for a period of 13 months, and then permanently deleted.

StrongDM log types:

There are four types of logs that StrongDM generates:

1. Activity logs capture the actions that occur within the StrongDM product; these are primarily administrative actions (for example, users changing each others’ permission levels, adding or editing infrastructure, changing settings, and so forth)
2. Query logs record access to resources and the commands run on them
3. Sessions/Replay logs are captured whenever an SSH, Kubernetes, or RDP session is completed
4. Error logs are the logs that record state and errors within StrongDM, and are output to a file called sdm.log on clients and on gateway/relay servers

Questions to frame StrongDM log configuration:

1. What types of logs does your organization collect?
2. What systems, software, and tooling does your organization use to aggregate, visualize, and exploit the logs it collects?
3. What teams or business units are the consumers of your organization’s logs?
4. What business processes and outcomes depend on your organization’s logs?
5. What are the regulations and policies that govern logging in your organization?

General recommendations and operational notes:

1. If your organization has invested time, money and resources establishing a logging system, use it… and use the native tooling to work with the logs that StrongDM creates.
2. The administrative web interface at app.StrongDM.com can search and filter activity logs as well as presenting a limited amount of query and session/replay logs, but it is primarily useful for viewing recent events.
3. Activity, query, and error logs are small in size. By contrast session/replay logs can grow quite large.  Although ingesting session/replay logs into a SIEM or log aggregation system is technically possible, it is not recommended. Memorialize the session/replay event in your SIEM or log aggregator and access the session/replay from storage using the uuid string associated with the event.
4. Activity logs reside in the StrongDM Platform. A public-facing audit API endpoint is in development; in the interim you will need to retrieve activity logs periodically using one of the StrongDM SDKs or the StrongDM command line tool with a cron job or scheduled task.
5. The StrongDM Code Garden team maintains the Log Export Container (LEC), which can be useful for sending logs to multiple destinations, particularly if you have not invested time and resources in a SIEM or log aggregation system.

Log disposition and encryption decision tree:

Relevant StrongDM Documentation:

• StrongDM log destination overview 
• Pervasive auditing in StrongDM 
• StrongDM logging overview
• What types of activity do StrongDM activity logs contain?
• Viewing StrongDM query logs
• Viewing and replaying StrongDM ssh sessions
• Viewing StrongDM RDP replays
• Viewing StrongDM Kubernetes logs and sessions
• Viewing website logs
• Getting started with log encryption and storage
• Setting up log encryption on the StrongDM proxy
• Setting up logging local to the StrongDM proxy
• Setting up remote encryption for StrongDM logs
• Reference: StrongDM command line audit functions
• GitHub repo: StrongDM Log Export Container