Security Statement

The purpose of this document is to help our customers evaluate the security, risk, and compliance of opensentinel. If you have any questions beyond what is covered here, please email us at [email protected].

All traffic to and inside of opensentinel is secured and encrypted with SSL/TLS. As with other evolving architectures, we reserve the right to change the underlying infrastructure of opensentinel at any time.

Analytics, Performance Monitoring, & Error Reporting

We use the following hosted services for client side performance monitoring and website analytics:

  • Cloudflare Web Analytics to track customer activity on the website.

  • Stripe to track website analytics for proactive fraud detection.

    Stripe collects identifying information about the devices that connect to its services, and uses this information to operate and improve the services it provides to opensentinel, including fraud detection.

  • New Relic for performance monitoring & error reporting, to proactively diagnose and fix issues as they come up.

On the backend we utilize AWS CloudWatch and New Relic to monitor and track operational metrics.

The Cloudflare, Stripe, New Relic, and AWS privacy policies are available here:

Customer Authentication

We use Google Cloud Identity Platform to manage customer signups and authentication.

This essentially means that after a customer is authenticated by Google — using either a username/password or a social login provider — opensentinel receives a token attesting that this customer is who they claim to be. We (opensentinel) do not get access to passwords or any other login credentials.

The Google privacy policy is available here:

Payments & Credit Card Data

All billing and credit card payments are handled by our PCI Level 1 certified payments provider, Stripe. We do not receive or store any credit card data on our systems.

The Stripe security policy is available here:

Runtime Infrastructure

All incoming website traffic, as well as traffic to the API & Automations endpoints, is proxied to our backend servers in AWS through Cloudflare.

We use the following Amazon Web Services to drive the opensentinel backend, running primarily out of Oregon, USA (us-west-2).

All customer data is encrypted in transit as well as at rest, and runtime secrets are managed using a combination of AWS Secrets Manager & AWS Systems Manager Parameter Store.

  • API Gateway, SQS, EventBridge, & Lambda to serve and run the API & automations endpoints.
  • DynamoDB as the primary datastore (for customer data).
  • CloudWatch to store logs for all components of opensentinel (to investigate operational issues) — details below.
  • ECR & ECS to run the Keybase sentinelbot service.
  • S3 to store business metrics for analytics (data warehouse), stripped of PII — details below.
  • SES to send outbound customer email notifications.

The Cloudflare, and AWS security policies are available here:

Development & Build Infrastructure

Development of opensentinel is carried out in a separate AWS account from staging & production — live customer data is never copied between AWS accounts.

We use GitHub to host our source code, and GitHub Actions to manage our infrastructure and deploy the app to our staging and production environments.

The GitHub security policy is available here:

Logging Policies

The backend system that powers opensentinel is hosted on AWS. We use a combination of CloudWatch for ephemeral logs, and S3 for longer term storage. These are the three primary logging sub-systems that affect our customers:

User Audit Logs

These are the the account-level access logs you can view from your your dashboard — essentially information such as where you accessed the service from, which devices you used, and also any relevant account-level actions you took (e.g. changed your password).

We store these logs for 30 days in our primary database (for you to access), and 1 year in our long term system (for compliance). Each log entry is automatically purged after it expires.

Automation Logs

The automation logs document how your automations are processed in the backend which is a useful tool for troubleshooting issues. With debug mode — which you explicitly have to enable & disable (in your settings) — we also log raw payloads + other ephemeral information

Similar to user audit logs, we store these entries for 7 days in our primary database (for you to access), and 1 year in our long term system (for compliance). Each log entry is automatically purged after it expires.

Note that we do not persist debug log entries to our long term system.

Backend Operational Logs

The backend logs are what each of our components logs as part of their day-to-day activity, divided into two distinct objectives: operational issues & analytics.

Operational Issues

These CloudWatch logs are used to investigate + mitigate any day-to-day operational issues that pop up. Each of these log entries are automatically purged after 5 days, unless manual intervention is required (in exigent circumstances).

Business Analytics

A small subset of the above operational logs are processed & analyzed for business metrics. These log entries are automatically stripped/obfuscated of all personally identifiable information (PII) and persisted to our long-term/permanent storage system in S3.

We use user/account/team specific salt values to hash PII information such as IP addresses, user IDs, email addresses, and so forth before persisting this data.

Account Deletion

Customers have the ability to close & delete their opensentinel account at anytime through their Account Profile. When this process is triggered, the following occurs:

  • If the customer is on a paid plan, their subscription is immediately cancelled and they are charged for any outstanding usage.

  • The user account, including automation recipes & other data, is immediately deleted from our primary datastores.

  • The customer profile on our payment partner (Stripe) will be automatically deleted after 12 months. Payment history data (e.g. transactions, invoices) will be retained indefinitely.

  • Account data on our secondary systems will automatically purge itself after a set period of time — 40 days for backups, 1 year for compliance logs.

Inbound & Outbound Email

All inbound email is handled and processed by Fastmail.

We use a variety of hosted providers to send outbound email on behalf of, namely:

  • Google Cloud Identity Platform for account authentication related emails.
  • Stripe for billing & subscription related emails.
  • AWS Simple Email Service for account related notifications.

We have SPF or DKIM enabled for each of these providers, and we have also DMARC strict mode enabled in order to prevent spam.

The Fastmail, AWS, Google Cloud, and Stripe security policies are available here: