loader

Security

CALENDAR CREDENTIALS AND ACCESS AUTHORIZATION

When you Sign In With Your Calendar you authorize FreeBusy to access one or more online calendars that you own, whenever someone checks your availability. Depending on your calendar provider this authorization uses OAUTH or a password. If your calendar allows only password-based authorization, FreeBusy needs to save your password.

Calendar ProviderRequires saving your password
Google CalendarNo
Google WorkspaceNo
Microsoft Office 365No
Outlook.comNo
Apple iCloudNo
FruuxNo
Microsoft ExchangeNo if signing up entire organization, Yes if signing up individual accounts
Amazon WorkMailNo if signing up entire organization, Yes if signing up individual accounts
ZimbraNo if signing up entire organization, Yes if signing up individual accounts
Yahoo! MailYes
KerioYes
ZohoYes
NextCloudYes
OwnCloudYes
SabreDavYes

Rest assured that for calendars where we need to save the password we take extra precautions to encrypt your password and not make it directly accessible to FreeBusy staff. All data is encrypted both in transit and at rest using high-grade industry-standard security with the utmost care for your privacy.

FREEBUSY IS COMMITTED TO ENTERPRISE SECURITY

We take security very seriously and we invest in a complex set of safeguards to protect your calendar credentials and calendar data. FreeBusy staff does not have access to your calendar data. In addition to data encryption in transit and at rest, when you purchase Enterprise or Dedicated plan you can request compliance audits for a variety of assurance programs, including:

compliance-CSAcompliance-SOC-2compliance-SOC-3compliance-privacy-shieldcompliance-EU-clauses


PROTECTING CREDENTIALS WITH ENCRYPTION, KEY WRAPPING, AND SEPARATION OF DUTIES

Access controls and encryption keys are segregated such that no one person or machine has direct access to all the pieces necessary to access or utilize your credentials. Your data is protected against malicious attackers, whether external (who might have gained control over one of the machines) or part of our staff (on the development or operations teams). Multiple coordinated breaches or individuals working together are necessary to compromise the data.

We encrypt all calendar access credentials whether they are passwords or OAuth refresh tokens. Data is encrypted with a AES 256-bit key. At all times, whether in storage or when loaded in memory by the production machines, this AES key is itself encrypted with another RSA 4096-bit key (aka key wrapping). The only moment the AES key is in the clear (unwrapped) is inside the function call that performs the decryption.

FreeBusy is built on Windows Azure cloud services. The wrapped AES key is stored in Azure Storage together with the rest of the user account details. The service runs on machines utilizing the latest Windows Server OS. The wrapping RSA key-pair is packaged as a X.509 certificate and stored in the local machine certificate store provided by the Windows Server OS. The key generation ceremony is local to the production machines and happened on the first deployment such that the wrapping RSA key-pair only exists in the certificate store of the production machines and nowhere else. Access to the RSA key-pair on the production machine is restricted to the application Windows OS service account.

Why this choice for keys and key wrapping?

  • We chose AES to encrypt the actual data because decrypting with symmetric keys (AES) is much faster than with asymmetric keys (RSA)
  • We chose to wrap the AES key with an RSA key (rather than another AES key) because in order to implement separation of duties we need to persist the keys in distinct stores with distinct access control mechanisms. Windows OS already has a store that can persist RSA key-pairs and uses distinct access controls (the certificate store). It's easier and more secure to use the OS' existing infrastructure.
  • We didn't want to have both keys loaded in memory at the same time in case the web server gets hacked from a zero-day vulnerability that enables it to access its memory directly (like Heartbleed). The OS certificate store provides a natural separation. The RSA private key is loaded into the web server process' memory only during decryption and it's securely flushed afterwards.

DevOps staff does not have access to the Windows OS service account and cannot read the RSA key-pair from the local certificate store. DevOps staff also does not have access to the Administrator account on the production machine. The password for the Administrator account is generated randomly at deployment time and then thrown away. If we have problems with a production machine that would necessitate Administrator access to fix, we throw it away and rebuild new one.

For your protection we do NOT backup the RSA or AES keys so as to not create further copies that would have to be secured. This is perhaps they only case known to us where not creating a backup leads to more protection. If a catastrophic event were to happen the consequence of losing the keys is small: all users would have to reauthorize FreeBusy (for calendar providers who support OAuth) or re-enter their password. It's a small price to pay for the extra security.

KEY MANAGEMENT FOR ENTERPRISES

Companies who purchase FreeBusy Enterprise can request dedicated encryption keys, generated and managed with Azure Key Vault, in place of the multi-tenant keys described above. The algorithm for protecting credentials remains the same however, dedicated keys are generated and stored in hardware security modules (HSMs) rather than in Azure Storage. Key operations are done inside the HSMs, which are certified FIPS 140-2 Level 2, allowing the enterprise to audit key usage.


GDPR COMPLIANCE


FreeBusy is GDPR compliant

FreeBusy operates according to the standards and directives of the GDPR. You can review our Privacy Policy for additional details. You can also read more about our Cookies Policy to learn what cookies we use and how.


Am I still GDPR compliant if I add FreeBusy to my website?

Yes. FreeBusy offers a Data Processing Addendum so we can be a "data processor" in the relationship between you and your data subjects with respect to processing their personal information.


Can I unsubscribe from all communication from you?

Yes, the link is included in every email we sent. If you unsubscribe, you may still receive occasional emails from us about administrative matters (Maintenance, changes to our Terms and Conditions etc.).


Can I download my data?

Yes. Simply contact us at [email protected] and we'll help you with that.


Can I delete my data?

Yes. Please see How do I close my account instructions for how to close your account which also deletes your FreeBusy data. Note that FreeBusy data does not refer to your calendar data which resides with your calendar provider not with FreeBusy and which is not affected by closing your FreeBusy account. FreeBusy data refers to your Calendar Credential, meeting scheduling preferences and analytics about meetings scheduled with FreeBusy.