First, we want to highlight that marbot works without read or write access to your AWS accounts. Instead, you configure your AWS infrastructure in a way to push alarms and notifications to our API. The Monitoring Setup Assistant helps you to configure your AWS accounts to send relevant events to marbot. The Monitoring Setup Assistant supports CloudFormation and Terraform templates. Some of those templates will create IAM roles and Lambda functions, for example, to filter or enrich data before sending it to our API. However, all of that happens in your account with the ability to review the code before deploying it. Optionally, you can connect your AWS accounts with marbot and provide us secure and limited access to your AWS account via an IAM role.
Second, we implement the following measures to operate marbot securely.
All data is encrypted when we move it over the wire.
- All data passed between marbot and Slack / Microsoft Teams is encrypted in transit using TLS (https).
- All data passed between your AWS accounts and marbot is encrypted in transit using TLS (https).
- When you use the optional email endpoint, data might not be encrypted in transit due to the nature of emails.
All data is encrypted when we persist it.
- We use Amazon DynamoDB as our main database. DynamoDB is fully encrypted by default using an AWS-owned key.
- We use Amazon Kinesis to enqueue asynchronous operations. Kinesis is fully encrypted using a customer-managed key.
We store as little information as possible and as short as possible.
- We store event payloads that endpoints receive for 14 days.
- We store alerts for 14 days with references to user IDs.
- We store escalations for 14 days with references to user IDs.
- We store information about the endpoints to map them to a channel (including the channel name).
- We store information about connected AWS accounts (including the account alias if the
AccountAliasfeature is turned on).
- We store log files for 30 days to debug issues in production.
- Subscriptions are handled by AWS Marketplace (or FastSpring for legacy subscriptions). We do not process or store your payment information.
- We store data about your Slack workspace needed to integrate with Slack’s API.
- Workspace ID and name.
- Bot user ID and access token, and scopes.
- The above data is deleted within 24 hours when you uninstall the bot.
- We store data about your Microsoft Teams tenant needed to integrate with Microsoft’s API.
- Tenant ID.
- Bot user ID and the service endpoint for your region.
- We keep track of the team IDs to which marbot is added.
- The above data is deleted within 24 hours when marbot is no longer added to any team.
marbot is implemented using a multi-tenancy architecture. We achieve tenant isolation by using the customer ID as a core component of primary keys used in our database.
Humans, as well as code, have only the needed permissions to get the job done.
We use a suite of tools to ensure that we follow best practices and industry standards. We use:
- AWS SecurityHub: We comply with AWS Foundational Security Best Practices and CIS AWS Foundations Benchmark (security score > 75%).
- AWS CloudTrail and AWS Config to record changes to our infrastructure.
We protect our API (https://api.marbot.io) against attacks using rate limiting and authorization. Our API is used by our partners (Slack and Microsoft Teams) and our customers.
Slack and Microsoft Teams sign their requests to us. We only accept requests adequately signed to ensure that we only receive valid events from our partners and not malicious actors.
Our https endpoint feature is the most common way for our customers to send events to us (usually using an Amazon SNS topic). Each endpoint is rate limited to 0.1 req/sec (5 req/sec burst) to avoid one customer overwhelming our system and slowing down all other customers. The endpoint is protected using a secret endpoint ID that must not be shared with others.