Security


We take the responsibility to protect your data seriously. Below, we detail how we handle customer data and what we do to secure it. This is not an exhaustive list of our security practices, but an overview of the key systems and policies.

If you have any questions about this document or something that’s not covered here, please email our team at moc.gniteemtahtetar@ytiruces.


Reporting a Vulnerability

If you need to report a vulnerability or have any concerns about the security of the Rate That Meeting platform, please email moc.gniteemtahtetar@ytiruces.

If you need to encrypt sensitive data as part of your report, you can use our PGP key, identified by the fingerprint:

82E3 D4D5 C7E5 E5FE 4B5F F158 FABF 9E99 A2F6 174A

Hosting Details

Rate That Meeting is hosted on the Amazon Web Services (AWS) platform. The physical hardware powering Rate That Meeting, and the data stored by our platform, is hosted in data centers controlled and secured by Amazon. You can read more about AWS’s security practices and compliance certifications here.

Rate That Meeting utilizes Amazon-managed services (for example, AWS Lambda and DynamoDB) to power our platform. We operate no EC2 instances or virtual machines of our own. This means that Amazon is responsible for securing the hardware and operating systems underlying our platform (Amazon articulates this as the "shared responsibility model"). Amazon has a reliable record of security and incident response. We trust them to secure key parts of our platform, letting us focus on the security of customer data and the application.

Multi-factor authentication and strong password policies are enforced for employee access to AWS, based on the standards recommended by the Center for Internet Security.

User Accounts, Authentication and Authorization

Rate That Meeting currently integrates with Google Calendar, and requires users sign up for our service using their associated Google account. Our web application authenticates you using the Google Identity Platform. Therefore, we do not operate our own login service, and store no passwords tied to user accounts.

Access to user data through our web application requires a Google OpenID Connect ID token (a JWT) specific to the authenticated user, which we validate with Google prior to every request for user data.

We recommend all users configure two-factor authentication on their Google accounts to further protect unauthorized access to their accounts on Google and Rate That Meeting.

OAuth and access to your calendar

Google utilizes the OAuth 2.0 protocol for authentication and authorization. When you sign up for Rate That Meeting, you explicitly authorize our application to read calendar events and settings. The permission you grant us does not give us access to modify these events or settings.

When you grant us authorization to your calendar, Google gives us both an access and refresh token so that we can access calendar data on your behalf. We encrypt this authorization information both in transit and at rest. The key we use to encrypt these tokens at rest is managed by Rate That Meeting. See the section on Encryption Keys below for more information about how we manage these keys.

Users can revoke Rate That Meeting’s access to calendar data at any time by managing the apps that have access to their Google accounts. When a user requests we delete their account, we revoke any tokens that authorized us access to that user’s calendar.

Other AWS security practices

Access to user data is controlled using IAM, an AWS service for controlling permissions to user data and services. We follow the principle of least privilege throughout the platform: a specific part of the application has only the access necessary to perform its designated function.

Additionally, we implement select controls recommended by the Center for Internet Security to tightly limit and audit the security of our AWS account.

Storage of user data

Everywhere user data is stored on our platform - whether in our databases, in application logs, or elsewhere - it is encrypted at rest using AES-GCM with 256-bit secret keys. See the Encryption Keys section for more about how we manage encryption using KMS.

User and calendar data is stored primarily in Amazon’s DynamoDB service. DynamoDB has achieved SOC 1, 2, 3, and ISO 9001, 27001, 27017, 27018 compliance. Copies of these certifications are available from Amazon on request.

We perform backups of DynamoDB data every 24 hours. These backups are encrypted using an Amazon-managed key. All backups are automatically deleted after 30 days.

Our application requests and stores only the data necessary to provide specific features to users. For each new feature we develop, we ask two primary questions:

  • What is the minimum set of data required to provide this feature to users?
  • Can we provide this feature without storing any user data on our platform?

All requests to the Google Calendar API are encrypted in transit. When making these requests, Google allows us to specify the fields returned in the API response (for instance, when fetching a list of events that occurred last week). We request only the fields necessary for the features we provide to customers.

Moreover, if we don’t have to store data to provide a specific feature, we don’t. For example: for many features, we store user data tied only to the unique identifier of a calendar event, along with the user’s email address. Then, in our web application, we use that data to request additional data about the event (for example, the meeting title, or participants) at runtime. In these cases, the additional data about the event isn’t stored in our database - we’re making a request for the data only when we need to display that data to users (for example, to identify a meeting by title so that they can provide a rating for a meeting).

When a user requests we delete their account, all data tied to that user in our database is deleted as soon as the deletion request is honored. Data for that user may exist in backups and application logs, both of which are automatically deleted after 30 days.

Our team uses Google’s GSuite service to manage email at ratethatmeeting.com. If you email our team, we secure those emails like other sensitive user data in our platform. Multi-factor authentication is enforced for every employee’s access to GSuite.

Please see the Application Logs section for more information about policies and security of log data.

Please see the Meeting Feedback Requests section for more information about how we utilize Mandrill and Slack as part of our feedback request feature.

The data tied to our staging environment, used for testing, is stored in a completely separate set of DynamoDB tables

Encryption of data in transit, SSL Certificates

All data sent between users' browsers and Rate That Meeting services is encrypted in transit using perfect forward secrecy, on browsers that support ECDHE cipher suites. See our SSL Labs Report for more information.

Within AWS, all data sent between services is encrypted in transit.

All Rate That Meeting-managed SSL certificates used to protect user data in transit are created using AWS Certificate Manager. This eliminates the need for our employees to manage certificate private keys: these keys are managed and secured by Amazon.

Security of the core web application

We secure our core web application (app.ratethatmeeting.com) using a number of industry best practices, including, but not limited to:

  • Performing vulnerability scans on the code and dependencies prior to production deploys using Snyk.
  • Enforcing TLS v1.2 on HTTPS requests to app.ratethatmeeting.com.
  • Enforcing HSTS (HTTP Strict Transport Security).
  • Enforcing a highly-restrictive content security policy (CSP).

See our Mozilla Observatory and SSL Labs reports for a third-party audit of our web application.

Encryption Keys

We follow industry best practices when encrypting user data and rely on Amazon’s Key Management Service (KMS) to manage our encryption keys. Access to administer these keys is limited to specific members of our team. Keys are automatically rotated once a year.

KMS has achieved SOC 1, 2, 3, and ISO 9001, 27001, 27017, 27018 compliance. Copies of these certifications are available from Amazon on request.

Application Logs

All application logs are stored in Cloudwatch Logs, an AWS-managed logging service. All application logs are encrypted at rest using a Rate That Meeting-managed key, and are accessible to select members of the Rate That Meeting technical team. All logs are automatically deleted after 30 days.

While we strictly limit the user data we log, in order for us to troubleshoot issues that arise with the platform, application logs may contain user email addresses, meeting titles, and other data attached to the calendar invite.

The Cloudwatch Logs service has achieved SOC 1, 2, 3, and ISO 9001, 27001, 27017, 27018 compliance. Copies of these certifications are available from Amazon on request.

Meeting Feedback Requests

If you elect to use the meeting feedback feature of Rate That Meeting, messages may be sent to you and participants of meetings you organize. These feedback requests may be sent over email, using Mandrill (a MailChimp-owned transactional email service), or via Slack, depending on the notification preferences of the user.

These feedback requests contain data specific to the meeting, including the meeting title, so we take the security of this feature seriously. All data transmitted to Mandrill and Slack is sent to their respective HTTP APIs, both of which require clients send data over SSL/TLS (HTTPS). Therefore, all data sent from Rate That Meeting to both Mandrill and Slack is encrypted in transit.

Mandrill requires customers configure SPF and DKIM records to validate the ownership of the sender’s domain.

When users grant us access to their Slack account, a bot is installed to their Slack workspace. Like access to Google accounts, this authorization grant is made using the OAuth 2.0 protocol. This authorization grants Rate That Meeting permissions to utilize the methods enumerated here. Based on our Privacy Policy, we will only send direct messages to the user who has specifically opted-in to receive feedback requests via Slack.

Source Code

Access to all source code is protected by multi-factor authentication.

Employee-level Security

Every employee runs macOS workstations. We use Fleetsmith to manage these workstations and enforce patches, Filevault, screen lock, and more.

Additionally,

  • We require employees use multi-factor authentication to access all services where user data is stored.
  • All employees use password managers to secure passwords to these services.
  • Employee access to all systems is immediately revoked upon termination of employment.

Incident Disclosure Policy

Our team handles incidents according to the methodology recommended by SANS. We communicate any incidents involving data breaches to customers as soon as possible, updating them as the incident response progresses.

Changelog

  • March 13th, 2018: First published
  • March 25th, 2018: added notes about employee termination, protection of source code, separation of stage and production data, Cloudfront / SSL, incident disclosure policy.
  • March 31st, 2018: added notes about Fleetsmith
  • April 5th, 2018: added additional encryption notes under Storage of User Data section, clarifying Encryption Keys section