Security

Security Best Practices

The following best practices are followed to ensure your data remains private and secure:

• cloudHQ uses industry-standard OAuth password-less authorization protocol when connecting to Google, Box, Microsof, Engyte, and Dropbox. This means cloudHQ has no access to your passwords for these services.
• For certain services that do not support OAuth, cloudHQ requires users to specify their username and password. These credentials are securely stored on cloudHQ secure storage and encrypted with 256-bit AES encryption.
• cloudHQ does not permanently store your files. When cloudHQ accesses your data via API, it might temporarily cache part of the content, but cloudHQ never stores any of your files permanently on its servers.
• All 256-bit AES keys for encryption and decryption of users’ credentials are encrypted and stored in a special "wallet". This wallet is encrypted using a password that is not stored on any of our servers. The password to open this wallet is known only to the cloudHQ administrator who manages our production server.
• Communication between cloudHQ servers and Google, Microsoft, Box, and Dropbox servers is always done over a secure TLS v1.3 channel. Communication between cloudHQ servers and your browser is also always done over a secure TLS v1.3 channel.
• cloudHQ product software and infrastructure are updated regularly with the latest security patches. Our network is protected by an enterprise-class firewall.

Built-in data encryption

Every account cloudHQ protects receives a unique AES 256-bit encryption key. All meta-data saved on our servers for the account is encrypted with that key. The keys are encrypted and stored in a special "wallet". This wallet is encrypted using a password that is not stored on any of our servers. The password to open this wallet is known only to the cloudHQ administrator who manages our production server. stored in a special "wallet".

1. All authenticated user interaction (login, service configuration, settings changes, accessing logs, etc.) occurs over a 256-bit encrypted channel (SSL).
2. All data transmissions with third-party APIs (e.g. Google Apps, Salesforce) occur over a 256-bit encrypted channel (SSL).
3. All meta-data is encrypted using a randomly generated AES-256 bit key unique to each user.

How do we ensure security of your data?

cloudHQ Backup, Migration, and Sync: Data Flow Between Cloud Accounts

Here is a short overview of how cloudHQ replicates data:

1. cloudHQ process connects to source and target cloud services via API (for example, Google Drive API and Dropbox API). The connection is established via SSL, using OAuth 2.0 for authentication.
2. Data is read from source cloud service (e.g., Google Drive) and then uploaded to target cloud service (e.g., Dropbox).
3. No data being transferred is stored on our servers.

Authorization with Cloud Accounts

cloudHQ uses an OAuth mechanism to authorize cloud account access. This means cloudHQ has access only to an OAuth token and we never access the user’s password. OAuth tokens are encrypted.

The key to decrypt these tokens is stored in a special file called a “wallet.” This file is encrypted using a key that is not persistently stored. Ultimately, this means that the password to open the wallet needs to be entered each time a sync process or our Web application is started.

This “wallet” password is known only to the system operator maintaining cloudHQ servers. Furthermore, these “wallet” passwords are periodically refreshed.

Authentication of End-Users

By default, cloudHQ users are authenticated via Google OpenID Connect. Access to our service requires that the user be logged in to Google Apps and that Google has already verified the authenticity of the user. This is our default because Google’s authentication framework has many important security mechanisms, such as two-phase authentication and detection of login location (e.g., if login is coming from an unusual IP address). For users who choose to use a login and username to access our system (instead of Google OpenID Connect), we store a hashed password using BCrypt with a 32-byte salt.

Two-Factor Authentication

Two-factor authentication (also known as 2FA, 2-step verification, or 2-phase authentication) is a way of adding additional security to your account. Any cloudHQ account can enable 2FA to increase account security. 2FA prevents customer account takeovers when attackers gain unauthorized access to an account due to an exposed or easily guessed cloudHQ password (if you are using password authentication) or, in case of OpenID Connect, somebody gained access to your Google account. More detailed description is: here

Monitoring

cloudHQ monitors and logs all actions of any authenticated user to detect possible unusual activity. cloudHQ requires that a password be at least 8 characters long. In case of a password reset, we require that the user have access to his/her email. cloudHQ support will never reset or change a password via email or support request.

Vulnerability management

cloudHQ undergoes regular penetration testing and daily vulnerability scanning to maintain the security of our solution. We’re continually scanning and testing our services internally, as well as contracting with external firms.

Data control and monitoring

cloudHQ gives you advanced admin controls to manage and monitor your data, including:

• Ability to control who in your org can use other cloud apps (i.e., their private Evernote etc.)
• Ability to monitor data shared and stored in cloud accounts
• Audit log of account activity

Additional Security Protections

Protection against Denial of Service (DoS)

cloudHQ uses CloudFlare technology to protect our service against DoS attacks.

Protection against phishing and similar threats

cloudHQ uses CloudFlare technology to protect our service against the following possible problems:

• Only clients’ matching browsers are allowed – browser integrity check
• IP addresses blacklisted by CloudFlare’s network are blocked
• All known threats are detected and blocked even before they are sent to our servers

Regular technical vulnerability assessments and penetration tests

We regularly monitor and penetrate all ports on our servers. The script ensures that only ports 22 and 433 are open. Each new feature related to security is independently assessed for vulnerability by an external contractor (e.g., possible XSS bugs and similar) before being deployed on production.

Intrusion detection and monitoring

We use Unix tool Fail2ban to detect and subsequently ban any attempt to log in to or access our servers. The server has only two ports open: SSH port 22 and HTTPS port 443. All other ports are blocked using both CloudFlare firewall and external firewall and an internal Unix firewall program called IPTables. Login via SSH is possible only via RSA keys. So any attempt to log in using an invalid RSA key or login/password combination will cause a ban of the IP address using the internal Unix firewall. The HTTPS port is monitored for access, and IP addresses detected as malicious are banned using IPTables. On the application level, we log the history of IP addresses used to access accounts. If an IP address appears to be from a different country, the security response team is alerted. The account might be disabled and all OAuth2 tokens invalidated. All commands executed on the server are also logged.

Reliability

All cloudHQ applications include failover and backup instances and our infrastructure respects and maintains industry-standard security certifications, including ISO 27001, ISO 27017, ISO 27018, SOC 1, SOC 2, SOC 3, FedRAMP ATO and PCI DSS v3.2.

Physical protection of servers

Our system runs on dedicated and virtual servers provided by leading cloud providers with provide additional physical security for servers. For example, the racks which host our servers have their own physical key and access code, which are needed for physical access to these servers. Personnel of our hosting provider cannot access servers without our providing them with the access code (based on the RSA key). The servers are running chassis intrusion alarm.

Incident Response and Remediation

We monitor our systems 24/7/365 with a variety of performance measurement and error-checking tools. When problems are detected, our ops team is notified immediately, and the issues are investigated. We work closely with our hosting providers to ensure that underlying systems remain secure, and any security breaches are investigated, patched and remediated promptly. Our system operations are logged, and the logs are stored for at least a 7-day period in the cloud. If needed, these logs may be mined to investigate incidents or to reconstruct a chain of events. When a serious incident occurs, or a long interval of downtime is anticipated, we notify our users via our blog, Twitter and/or email. Should a security breach occur, we will promptly notify affected users of the nature and extent of the breach, and take steps to minimize any damage.

Reporting Security Issues

Privacy and Data Loss Prevention

Employees of cloudHQ are strictly forbidden from seeing users’ filenames or file content. If, in order to solve a support ticket, we need to have access to filenames or to file content, we are required to ask you for explicit permission to do so. All access will be logged, and you can request audit logs at your discretion. Data is NEVER shared with anybody outside cloudHQ.
cloudHQ may collect and store the following information when running the cloudHQ Service:

• When you register an account, we collect some personal information, such as your name and email address. Payment is handled by PayPal, so we are not storing credit card or other billing information.
• When you use the Service, we automatically record information from your Web browser. This may include the Device’s Internet Protocol (“IP”) address, browser type, the Web page visited before you came to our website, information you search for on our website, and locale preferences.
• cloudHQ also uses “cookies.” A cookie is a small data file that we transfer to your Device. cloudHQ uses “persistent cookies” to save your registration ID and authentication information for future logins to the Service. We also use “session ID cookies” to enable certain features of the Service, to better understand how the user interacts with the service and to monitor aggregate usage and Web traffic routing on the Service.

GDPR compliant

cloudHQ is in compliance with GDPR.

Protecting privacy is one key cloudHQ design issues: When we designed cloudHQ we had in protecting of your personal as the key design choices – not just review privacy implications after a product or process is developed. We conduct regular data protection impact assessments to meet the privacy by design principle.

User rights: The GDPR clearly defines set of user rights – and these right something we consider very natural and reasonable requirements.

Real time and detail breach notification rules: Under the GDPR, organizations are required to have a strong breach notification system in place and understand their specific reporting obligations. And cloudHQ already have these rules in place.

Accountability: cloudHQ has a clear internal privacy governance structure with necessary accountability.

Safe Harbor compliant

cloudHQ is self-certified in compliance with the US Department of Commerce Safe Harbor program. We maintain and enforce privacy practices that comply with the EU Privacy Directive on the protection of customer data. We have controls to give notice to customers when collecting personal data, allow customers to access and update their own information, and provide adequate security around all personally identifiable information.