Your company's work day is valuable. Here's how Robin keeps it safe.
Need something more in-depth to share?Download Whitepaper
Network and App Architecture
The diagram below will give you the fastest overview of Robin's service architecture. Click the image to view a larger version.
Data Center Security
Robin is a cloud service, and hosted by data centers with the highest level of certifications including ISO 27001 and SOC. For more compliance information, you can visit AWS Security and AWS Compliance.
All application servers are based in the US, but may be accessed internationally via the internet. Robin’s CDN serves static assets (e.g. webpage stylesheets, avatar images) from servers across the world, but does not touch sensitive customer data.
Decommissioning and Data Removal
All customer data is stored on AWS services, which follows a strict decommissioning policy outlines on page 8 of their security whitepaper:
"AWS uses the techniques detailed in DoD 5220.22-M (“National Industrial Security Program Operating Manual “) or NIST 800-88 (“Guidelines for Media Sanitization”) to destroy data as part of the decommissioning process."
For customer-specific data, we will manually remove all identifying calendar data associated with your account from our database on request. Derivate anonymized data (i.e. "Total events booked on platform this month") will not be removed, as it cannot be linked back to source data. User accounts associated with your organization may also be removed on request. We retain backups for 30 days, after which time the data will be completely unobtainable.
Uptime & Reliability
We constantly monitor our service performance and have automatic notifications to ensure rapid response for service interruptions. All code is audited and peer reviewed before deploying to production servers. We also monitor updates from the security community and immediately update our systems when vulnerabilities are discovered. When we do have issues reported, we keep an updated system status here.
New features, performance improvements, and bugfixes are deployed multiple times per week. While agile, our development cycle relies heavily on a strict system for code quality and security. All code is peer reviewed, and requires multiple levels of acceptance on test/staging environments prior to deployment on production. Key highlights for common questions:
- Changes are checked for security and errors via extensive unit, integration, and static analysis tests.
- Production data is separated from development environments.
- We have completed rigorous reviews by internal security teams for multiple public companies
We maintain automatic access and security logs in multiple locations. All employees are required to use two-factor authentication and strong passwords that are unique from other services. Customer data access is limited, and is allowed only to a small set of employees as required for support and maintenance. Access is further limited to a small whitelist of IP addresses via VPN and require public key authentication.
Individual employee access follows a principle of least access, and access rights are reviewed quarterly.
Password authentication is available by default, and validated by entropy to restrict weak passwords. Robin also supports Single Sign-On through SAML 2.0, Google SSO, and ADFS (via SAML). Users registered through SSO use JIT provisioning. SCIM 2.0 support for automatic deprovisioning is in development and planned for 2017 release.
Through your existing SSO provider, Robin can enforce any existing password strength, expiration, and restrictions you already apply.
Customer data is encrypted when in-transit and at rest. All connections with Robin's services are encrypted and served through SSL/TLS 1.2+. You cannot access the service without using HTTPS. All certificates are verified on both sides with third party authorities. Data is encrypted every step of the way:
- Applications → Cloudflare
- Cloudflare → Amazon Web Services
- REST request → Robin application layer
- Robin application layer → Key Management Service → MySQL session
- API response → Applications
When at rest, customer data is encrypted using a key management system which logs all access automatically. Additionally, passwords are both hashed and salted using one-way encryption, which protect them even in the unlikely event of unauthorized database access. Application credentials are stored separate from the code base. Clients authenticate with Robin using a token system.
Each token has specific access scopes, which can be individually revoked without impacting others on the platform. We are also able to invalidate tokens across the entire platform instantly in the event of a security incident.
Servers are patched regularly to maintain a top security rating. Vulnerabilities are tracked via a combination of automated mailing lists and proactive internal audits completed on production machines weekly.
Our engineering team actively contributes to security libraries, including an open source library of Microsoft's NTLM encryption used for secure Exchange authentication.
Robin syncs all calendar data with your existing system (e.g. Exchange), and you can continue to use the audit logs generated there to monitor activity between Robin and your system. Additional activity logs are available for download in our admin portal or upon request from your account manager.
When you sign up for a paid subscription, we do not store your credit card information on our servers. We currently use Stripe, which is PCI-Compliant and dedicated to safely storing sensitive payment data. You can find a copy of their security practices here.
We do not store any data with regulatory requirements, such as HIPAA or PCI
IP addresses for whitelists
Robin's public-facing web service uses the following IP addresses for calendar connection and webhooks. If you host your calendar server on-premise (e.g. Exchange), add these addresses to your firewall's incoming connection whitelist. This will make sure Robin is able to connect.
For additional verification, you can also match user agents containing
RobinAPI, which will appear similar to
RobinAPI/123456 in the request headers
The majority of application traffic is via standard web traffic port
443. Rooms displays also use port
28989 specifically for logging device diagnostic information used in uptime analysis.
For networks that whitelist ongoing connections, you can verify against our DNS (e.g.
*.robinpowered.com) which is signed via DNSSEC. DNSSEC removes the need for specific IP address range since the DNS record itself is secured and can be validated with third party authorities similar to an SSL certificate. You can confirm using this tool from Verisign.
Once an external calendar account is connected to Robin, our cloud service will begin to synchronize data with the designated room calendars. In doing so, a subset of your calendar events and their details will be saved in Robin.
Robin will then keep this data in sync with your calendar system. Events booked through Robin will similarly synchronize the data back to your calendar service, so that Robin and connected calendars stay consistent. Synced event details include:
- Start and end times
- Location (e.g. "Acme Conference Room")
We do not store event attachments. You can learn more about our specific connection practices by service (e.g. Exchange) in our help center.
Application and customer data is stored redundantly at multiple availability zones within Amazon's data centers. Customer data and application source code are automatically backed up daily. Backups are retained for 30 days to recover in the event of a disaster.
In the event of a security breach, our team will promptly notify you of unauthorized access to your data. Service availability incidents are published to our status page with additional information. See an example incident report.
Should your security team need additional logs for their investigation of an incident determined to affect your organization, our security team will coordinate responsibly provide access as needed.
All employees are governed by documented strict security policies covering acceptable use, customer data, and encryption standards. If you would like to request a copy of these policies, please contact your account manager.
How to contact us
We know these issues are important to you too. If you have any additional questions that aren't answered above or by the help center, please email firstname.lastname@example.org and we'll reply as fast as we can.
If you believe you've found a security vulnerability while using Robin, we'd also like to hear from you. Fixing problems quickly and responsibly is incredibly important to us.
Need something more in-depth to share?Download Whitepaper
March 15, 2017: Security Whitepaper v1.4
September 6, 2016: Expanded details on encryption and policy docs
April 12, 2016: DNSSEC and application development section
November 24, 2015: Service IP addresses for whitelists
November 8, 2015: Network architecture diagram
Oct 16, 2015: Additional information about data collection
May 13, 2015: Initial draft published