CTERA End-to-End Security. Whitepaper by CTERA Networks

Transcription

1 CTERA End-to-End Security Whitepaper by CTERA Networks

2 Copyright CTERA Networks Ltd. All rights reserved. No part of this document may be reproduced in any form or by any means without written permission from CTERA Networks Ltd. Information in this document is subject to change without notice and does not represent a commitment on part of CTERA Networks Ltd. CTERA, C200, C400, C800, CloudPlug, NEXT3, Cloud Attached Storage, and Virtual Cloud Drive are trademarks, service marks, or registered trademarks of CTERA Networks Ltd. All other product names mentioned herein are trademarks or registered trademarks of their respective owners. The products described in this document are protected by U.S. patents, foreign patents, or pending applications. Tip For legal information and for the end user license agreement, refer to Legal Information in the CTERA Portal User Guide.

3 The CTERA Cloud Attached Storage End-to-End Security Solution CTERA Networks was founded by seasoned veterans of the network security industry, who employed their extensive experience and knowledge of network security to develop and design the CTERA Cloud Attached Storage solution. Let's take a look at the solution's components and its various security features, in order to understand how CTERA provides end-to-end security. The Solution's Components The CTERA Cloud Attached Storage platform is comprised of the following key components: The CTERA Portal The CTERA Portal is a scalable cloud service delivery platform that enables the creation, delivery and management of cloud storage applications, including file sharing and sync, backup, and mobile collaboration. It serves as the middleware connecting the datacenter storage infrastructure to the CTERA clients/endpoints. We'll take a closer look at the CTERA Portal's components later on. CTERA Cloud Storage Gateways CTERA Cloud Storage Gateways are hardware appliances that can be deployed on-premises in remote branches or offices. They serve as local, cloud-integrated, NAS appliances that enable data aggregation for multiple users and optimized backup and restore to the CTERA Portal. CTERA Agents CTERA Agents are software clients installed on desktop and server stations. They can operate in Local Mode, enabling hybrid file-level and disk-level backup with a CTERA Cloud Storage Gateway, or they can operate in Cloud Mode, enabling file-sync & share and backup directly to the CTERA Portal. CTERA Mobile The CTERA Mobile is a smartphone application that enables secure access to the data stored on CTERA Portal, while providing collaboration capabilities.

4 The following diagram describes how these components fit into the Cloud Attached Storage architecture. The CTERA Portal's Components As the CTERA Portal is the "heart" of the Cloud Attached Storage solution, let's take a closer look at its components: Main Database The CTERA Portal leverages PostgreSQL as its primary database server for maintaining system-related information, including user accounts, CTERA clients, provisioning, and so on. The main database server stores sensitive metadata, such as user names and secret keys. Only the application servers need to connect to this high-security zone; therefore, when considering the security architecture, the main database should reside in a private network without direct Internet access. Catalog Node Catalog nodes are PostgreSQL server nodes that maintain object-related information on files and blocks that CTERA clients backed up to the CTERA Portal. By default, the main database is configured to operate as a catalog node. The catalog nodes store sensitive metadata such as file names. Only the application servers need to connect to this high-security zone; therefore, when considering the security architecture, the catalog nodes should reside in a private network without direct Internet access. Front-End Application Server

5 The CTERA Portal leverages the Apache Tomcat Web server to enable user access to the CTERA Portal Web interface and mobile application. The Apache Tomcat Web server also serves as the endpoint for CTERA clients connections. In its default and recommended configuration, the application server communicates only over HTTPS and TLS connections, which are encrypted using AES (Advanced Encryption Standard) and authenticated using 2048 bit RSA X.509 certificates. The application servers can be placed in a world-facing DMZ network and protected by standard Web Application Firewall (WAF) and IDS/IPS systems. Storage Infrastructure The CTERA Portal supports storing data in private and public storage systems from a wide variety of vendors, including EMC, IBM, DDN, Amazon, and Hitachi. All data at rest on the storage nodes is encrypted using AES-256 encryption, with keys that are stored in the main database only. Data-at-rest encryption applies to all storage (backup folders, home drives, and projects). No cleartext data is ever stored on the object storage system, so even if an attacker gains read access to the object storage system, they still cannot see any of the files' content. Furthermore, each file is protected by an HMAC-SHA-1 signature to prevent malicious tampering or corruption by people with access to the storage infrastructure, and each individual data block is protected against corruption by an MD5 hash. This is used as a secondary integrity check, (which can be validated with no need for the encryption key). CTERA Portal deployment is supported on either a standalone server or in a multi-instance environment. In a standalone environment, a single CTERA Portal server will serve as both the main database, catalog node, and the front-end Web server for user and CTERA client connections. In a multi-instance environment, a single node operates as the main database server, and the remaining nodes can be configured as the catalog node, front-end Web server, or both. All internal communications between CTERA Portal servers is authenticated to prevent unauthorized access. However, to implement the in-depth defense philosophy, it is good practice to place the CTERA application servers and database servers each in their own separate network, isolated from the corporate network by a firewall. This means that only the application servers need to face the Internet, shielding the sensitive catalog nodes and main database from the hazards of unsecured networks. The Solution's Security Features Now that we've learned about the CTERA Cloud Attached Storage solution's components, we're ready to explore the cornucopia of security features they provide.

6 The CTERA Portal X.509 Certificate The CTERA Portal uses a 2048-bit X.509 security certificate to do the following: Authenticate CTERA Portal servers for TLS connections from CTERA Cloud Storage Gateways and Cloud Agents to CTERA Portal servers Authenticate the Web server for HTTPS connections from Web browsers to the CTERA Portal

7 CTERA Portal Multi-Tenancy Multi-tenancy is when a single instance of software is used to serve multiple customers, called tenants. CTERA Portal multi-tenancy enables delegating aspects of service delivery to channel partners or departments, by using virtual portal instances (tenants) of the CTERA Portal, each of which acts as a software blade and shares the same underlying infrastructure settings as the other instances, but is completely isolated from the other instances. The CTERA Portal supports two types of virtual portal instances (tenants) team portals and reseller portals and enables creating as many of them as desired. (You can learn more about the differences between team and reseller portals, by referring to the CTERA Portal Administrator Guide Datacenter Edition.) User accounts created in different virtual portal instances are completely separated, as is their backed up data. In addition, CTERA Portal supports assigning a dedicated storage bucket to each virtual portal instance. This means that the stored data of user accounts in different instances will be stored on different storage buckets. This can be done for tiering purposes, regulatory reasons, or security purposes. CTERA Portal Access Control The CTERA Portal provides two ways of restricting access to its Web interface: IP-Based Access Control

8 It is possible to configure a list of specific IP address ranges, from which administrators can access the CTERA Portal's Web interface. This configuration is available for global administrators, as well as for instance-level administrators. Role-Based Access Control Every user account in CTERA Portal is assigned a role, which indicates the user account's authorization level in the system. Likewise, every administrator account, whether global or instance-level, is assigned a role indicating the administrator's authorization level in the system. In addition, it is possible to customize the permissions included in each administrator role. Regardless of their role, an administrator cannot mimic a user s login or perform actions that appear to have been performed by a user. Administrator activity is restricted using role-based access controls and fully logged as part of the audit log, along with the identity of the administrator that performed the action.

9 CTERA Active Directory Integration Full Active Directory integration is available on the CTERA Portal and CTERA Agent. When using a single password and Single Sign On (SSO) with Active Directory, each user need only remember a single organization-wide password that is securely stored and managed by Active Directory. It is not necessary to maintain any additional passwords. Furthermore, storing the password in a central location enables full control of the password strength and rotation policy by the organization's password lifecycle policies. CTERA Portal The CTERA Portal platform supports integrating each virtual portal instance, whether team or reseller, with Active Directory services or an LDAP server. CTERA Cloud Storage Gateways

10 The CTERA Cloud Storage Gateway supports integration with Active Directory, thereby enabling users to access the device via Web interface using supported protocols, and to access CTERA Agents using their domain accounts. In both cases, Active Directory integration can be established using LDAP or LDAP over SSL. Furthermore, integration with a cross-forest Active Directory setup is supported. The CTERA Portal periodically synchronizes user accounts that were modified on Active Directory, to promptly detect and adapt to any group membership changes. If desired, you can map a user's Active Directory groups, and the user s administrative roles on the CTERA Portal. Role mappings, allow controlling what the user can do on the CTERA Portal, based on their Active Directory groups.

11 It is also important to note that Active Directory user passwords are never persistently stored on CTERA Portal or CTERA Cloud Storage Gateway. Instead, authentication is performed using the Kerberos protocol. In addition to Active Directory integration, the CTERA Portal also supports LDAP-based authentication and authorization. As with Active Directory, when LDAP is used, user passwords are never persistently stored on the CTERA Portal. Instead all user authentications are performed directly using the LDAP protocol. CTERA Transport Protocol For maximum security of read and write procedures between CTERA clients and the CTERA Portal, CTERA Networks developed a highly efficient, WAN-optimized file-transfer protocol called CTERA Transport Protocol (CTTP). CTTP is a TCP-based protocol that is encrypted in transit by the industry-standard TLS protocol using a configurable cipher. (The default cipher is AES-256.) Backup, restore, and sync procedures are performed using CTTP over TCP port 995 as follows: 1 As mentioned in The CTERA Portal X.509 Certificate (page 6), the CTERA Portal uses a 2048-bit X.509 certificate for authenticating connections between CTERA clients and the CTERA Portal, as well as for connections between Web browsers and the CTERA Portal's Web interface. 2 For initial enrollment, the CTERA client establishes a connection with the CTERA Portal using user/password authentication, after which it receives a unique 256-bit authentication key. 3 The CTERA client stores all file fragments at rest and encrypts them with AES-256 CBC. 4 The data encryption keys (DEK) are never stored persistently on the client. The CTERA Portal acts as a key server and provides DEK keys to the client on a need-to-know basis. (That is, if the client is granted access to a cloud folder, the key is provided.) 5 The Cloud Backup service supports secret passphrase protection mode. From the passphrase, the client derives a key encrypting key (KEK) using the PBKDF2 key derivation algorithm. (If the client is a CTERA Cloud Storage Gateway, KEK is stored persistently in its flash memory.) 6 The CTERA Portal does not receive the KEK or DEK. Instead, KEK is used to encrypt DEK using the AES-256 key wrapping algorithm as defined in RFC-3394, and the result is stored on the CTERA Portal as an encrypted folder key (EFK). 7 To decode the files, the client first requests the EFK from the CTERA Portal for a specific folder. 8 The CTERA Portal checks whether the client has permission to access the folder, and if so, the CTERA Portal returns the EFK.

12 9 The client then decodes the EFK using the KEK, to obtain the DEK. Then it uses the DEK to successfully back up or restore files in the folder. CTERA Audit Log Both the CTERA Portal and the CTERA Cloud Storage Gateway Web maintain extensive logging of all configuration and data changes. One of the log types displayed are Audit logs, which document various configuration changes. Audit logs include information on the action type, account name, date, timestamp, target, and more. The CTERA Portal can also log all file changes and file accesses. In CTERA Portal, the Audit Log Viewer is available for both global administrators and virtual portal instance (team or reseller) administrators. CTERA audit logs can be automatically forwarded to an organizational Syslog server for log analysis, threat detection, protection against log tampering, and long-term storage.

13 CTERA Portal Built-in Defenses The CTERA Portal employs best practices to secure its data. It uses Oracle Java technology, which ensures buffer overruns are checked for automatically. The system also includes HTML validation technology that defeats Cross-Site Scripting (XSS) attacks and performs specific checks to defeat potential attacks such as Cross-Site Request Forgery (CSRF), XEE, ClickJacking, and more. The CTERA Portal is provided as a VMWare-based, hardened virtual appliance. Only minimal initialization settings (IP addresses and so on) are stored on the virtual appliance's file system, and access to those files is protected by an SSH password or certificates. The rest of the configuration is stored inside the PostgreSQL database and protected by PostgreSQL security mechanisms. Configuration changes are logged, along with the user name that executed them, to the CTERA Portal's audit log. These log messages can optionally be sent to external systems via the Syslog protocol. All successful and failed access attempts are logged. In addition, it is possible to configure the system to send alerts to the administrator, upon specific log events. If a client fails to log in due to entering an incorrect user name and/or password three times in a row, all logins from the same source are automatically banned for five minutes. This mechanism severely limits the rate of password guessing attacks, which makes them unfeasible.

14 CTERA Protection Against OWASP Top-Ten Attacks CTERA uses a variety of methods to protect against OWASP top-ten attacks: A1-Injection A2-Broken Authentication and Session Management A3-Cross-Site Scripting (XSS) A4-Insecure Direct Object References The CTERA Portal sanitizes user inputs and uses bind variables, to prevent SQL injection attacks. Furthermore, CTERA uses code reviews and third-party vulnerability scanning to detect the presence of potential injection attacks. For another layer of protection, it is possible to deploy the CTERA Portal behind a WAF. Widely used and established Active Directory protocols (LDAPS and Kerberos) are used for authentication and authorization. When used with a directory service (Active Directory or LDAP), the system does not store user passwords in its database; rather, it delegates all user authentications to Active Directory. Sessions automatically time out after a short interval of inactivity, and session IDs are rotated after every new successful login. Persistent cookies are never used for storing session IDs or other authentication data, and passwords, session IDs, and other credentials are never sent over unencrypted connections. Code reviews and third-party vulnerability scanning are used to detect the presence of potential session management vulnerabilities. The CTERA Portal automatically escapes all data sent to the browser, to prevent XSS attacks. CTERA has performed extensive black-box testing via third-party security experts to detect such potential attacks. Code reviews are also performed regularly to find XSS vulnerabilities. For another layer of protection, it is possible to deploy the CTERA Portal behind a WAF. The CTERA Portal's security engine is designed to perform an access-control check, to ensure that the user is authorized for the requested object, before using a direct object reference from an untrusted source. Code reviews and black-box testing are used regularly to prevent insecure direct object references.

15 A5-Security Misconfiguration A6-Sensitive Data Exposure A7-Missing Function Level Access Control A8-Cross-Site Request Forgery (CSRF) The CTERA Portal uses a strong application architecture, which separates components so as to allow for multiple layers of security between product modules. (For example, in recommended production environments, database servers and storage servers are separated from application servers.) The CTERA Portal also includes hardened OS installation that is specifically customized to remove all unnecessary services and open ports. All default passwords are changed as part of the product installation process. All sample applications, application server management consoles, and data are removed from production servers. CTERA's application servers disable directory listings. CTERA has in place a process to ensure that the OS, application servers, development frameworks, database, applications, and all third-party code libraries used by CTERA are regularly patched as needed, based on risk assessments. Multiple layers of security are used to protect sensitive data, including AES-256 data encryption at rest, SHA-1 fingerprinting of all data, and TLS encryption of all data in transit. No sensitive data is ever transmitted in cleartext, and the system is configured not to allow use of old, insecure ciphers. All access to the CTERA Portal OS console is secured by SSH public/private key pairs. Secure X.509 certificates with 2048-bit key length are used for server authentication. As another layer of protection against exposure of sensitive data, role-based access control is employed. In addition, the system is designed to be completely private with no shared components, and it is entirely self-hosted with no required SaaS components. The CTERA Portal's presentation (UI) layer is never used to enforce security rules. All security rules are enforced by the backend at the authorization module, which is located below the API level. The enforcement mechanism built into the CTERA Portal denies all access by default and requires an administrator account to be explicitly granted specific roles in order to access to each function. The system has been tested and confirmed by a third-party testing lab to be immune from CSRF attacks. All API PUT/POST requests require a special CSRF prevention token (x-ctera-token).

16 CTERA has in place a process to ensure that the OS, application servers, development frameworks, database, applications, and all third-party code libraries used by CTERA are regularly A9-Using Components with Known Vulnerabilities patched as needed, based on risk assessments. CTERA has in place security policies governing component use, including requiring source code access, requiring acceptable licenses, and assessment of security risks involved in using each third-party component. Forwards are not used. Redirects are always validated to contain safe destinations only. Code reviews and third-party A10-Unvalidated Redirects and Forwards vulnerability scanning are used to detect the presence of potential unvalidated forwarding attacks. For another layer of protection, it is possible to deploy the CTERA Portal behind a WAF. Session Management CTERA provides session security, by focusing on preventing session prediction, capture, and hijacking. Session prediction refers to guessing a valid session identifier. With the CTERA Portal, session identifiers cannot be predicted, because the session ID is an extremely long number, generated using a cryptographically secure random number generator. Session capture is prevented by using only encrypted communication mediums. (In its default configuration, the CTERA Portal never sends the session ID using clear protocols.) Session hijacking is prevented by using a special CSRF protector header, and by changing the session identifier on every login so as to prevent session fixation attacks. The system automatically logs out inactive users after 30 minutes of inactivity. CTERA Appliance Security The CTERA Cloud Storage Gateway is based on a minimal, security-hardened version of Linux, in which virtually all standard services are disabled, to minimize potential attack footprints. The CTERA Cloud Storage Gateway supports creating encrypted volumes. When the administrator chooses to encrypt the contents of a volume, they are prompted to input a passphrase. Password-Based Key Derivation Function 2 (PBKDF2) is used to harden the volume passphrase (that is, to make the passphrase more secure), and the passphrase is then used to encrypt the encryption key using AES-256. Volume encryption is based on Linux Unified Key Setup (LUKS). This method is an implementation of the TKS1 key setup scheme.

17 Two-Factor Authentication CTERA supports collaboration with guests by means of guest invitations. Guest invitations are special time-limited URLs containing a secret code that grants the recipient the ability to view a specific file or folder and to optionally collaborate on those items. The CTERA Portal allows the organization to define which users are allowed to collaborate with external guests at the per-user or per-group level. CTERA Portal supports two-factor authentication for guest invitations, based on random numeric passcodes (consisting of six numeric digits) or "challenges" which are sent to the user (by SMS or ), in response to an attempt to access a guest invitation. This feature offers protection against unintended recipients accessing the guest invitation URL. Two-factor authentication is protected against brute force attacks: Each user is given five tries to enter the code, after which the code is disabled. In addition, rate limits are employed to restrict the number of authentication requests, so as to protect against denial of service attacks. On private computers, after successfully authenticating using two-factor authentication, the user is given the option of setting their computer as "Trusted". When this option is selected, a 256-bit, unique random key is stored on the user's computer, allowing the user to bypass two-factor authentication challenges and avoid answering challenges from the same device for the next 30 days. All accesses to invitations, as well as successful or failed two-factor authentication attempts, are logged.

18 CTERA Mobile CTERA Mobile stores all data fully encrypted at rest, "sandboxed" from other applications, with a remote wipe feature for lost or de-authorized devices. Encryption keys are generated on the client side during the first service enrollment, using a secure random number generator. CTERA Mobile does not store the password for connecting to the CTERA Portal locally. Instead, upon first connecting to the CTERA Portal, the mobile app exchanges a secure 256-bit access key that does not depend on the password. Only the access key is stored on the mobile device. The access key is unique to each device and is stored in the Android/iOS secure keychain. Secure Development Lifecycle CTERA's development lifecycle for software and hardware is highly methodical and includes specific provisions for code reviews and inspections, as well as thorough automatic and manual testing procedures, to minimize security vulnerabilities and other defects. As part of CTERA's development methodology, CTERA has developed an extensive test automation system to validate the integrity of data processing and storage by the CTERA Portal. The test system is automatically run on each new version to ensure that the CTERA Portal operates optimally while under stress, and that even under extreme conditions, the stored data can always be read back correctly without corruption or data loss. In addition to quality assurance, code reviews are performed during the development stage to ensure that changes in the core data processing paths do not introduce a risk of data corruption or data loss. CTERA's core team is composed of the people who designed and developed Unified Threat Management (UTM) and VPN appliances of one of the world's top security firms. Therefore, security is CTERA's DNA, and we see it as one of our top priorities. CTERA has developed an internal security standard based on a combination of industry best practices and standards. CTERA conducts periodic secure coding training and issues reminders to all developers, covering generally recognized secure coding standards and industry practices such as the Open Web Application Security Project (OWASP) "Top Ten Projects", the CWE/SANS "Top 25 Programming Errors", and more. These courses are provided by third-party security experts. In addition, CTERA has performed black and gray-box penetration tests with multiple third-party labs. CTERA has a policy of performing at least two penetration tests per year, by well-known third-party security testing labs that are independent of CTERA. CTERA has an internal code review process in which every code change is reviewed for quality and security. In addition to internal code reviews, a well-known third-party certification lab retained by CTERA regularly performs independent code review for security-critical code segments.