ShareFile Enterprise: security white paper

Security White Paper : security white paper Providing security is essential when implementing an Enterprise class file sync and sharing solution Learn how provides industry-leading security measures to protect both ShareFile.com and our customer s data

Table of Contents Introduction 4 SaaS application tier 6 ShareFile servers: web, API, and database overview 6 SaaS application tier security 6 Encryption 6 Hash-based message authentication code 6 Metadata 7 Citrix-managed StorageZones 8 Overview 8 Securing file upload/download requests 9 Security 10 Encryption in transit 10 Encryption at rest 10 Data backup 10 Anti-virus 10 Amazon Web Services security 10 Microsoft Azure Security 10 Customer-managed StorageZones with on-prem storage 11 Overview 11 Securing file upload/download requests 12 Security 13 Trust and encryption: on-premise StorageZone 13 ShareFile StorageZones Controller server 13 Encryption in transit 14 Encryption at rest 14 Customer-managed Restricted StorageZones 15 Overview 15 Encrypting file upload/download data and metadata 15 Adding a document 15 Enumerating files from the Restricted StorageZone 15 External Access to encrypted file and metadata 16 Email notifications 16 Sharing/sending files 16 Receiving a shared file 16 Customer-managed StorageZones with Windows Azure storage 17 Overview 17 Securing file upload/download requests 18 Security 19 StorageZone Connectors 20 Overview 20 Securing File Upload/Download Requests 21 Security 21 2

Data Loss Prevention (DLP) integration 22 Overview 22 Which DLP systems are supported? 22 How ShareFile works to prevent data loss 22 NetScaler integration 24 Overview 24 Requests for ShareFile data from on-premise data storage 25 Securing ShareFile data upload/download requests with NetScaler 25 Requests for data from StorageZones Connectors 26 Securing ShareFile Connector upload/download requests with NetScaler 27 SAML integration 28 Overview 28 Workflow 28 Security and benefits 29 Additional resources 29 OAuth 30 Overview 30 Workflows 30 Web authentication ShareFile credentials 30 Parameter definitions 33 Web authentication SAML 34 Desktop apps 34 Security and benefits 36 Conclusion 37 Appendix A. 38 Mobile device security 38 Appendix B. 40 ShareFile web application security features 40 3

ShareFile is an enterprise follow-me data solution that enables IT to deliver a robust data sharing and sync service that meets the mobility and collaboration needs of users and the data security requirements of the enterprise. Securing data is critical to every enterprise and is a responsibility taken seriously by ShareFile. Savvy IT executives understand that with the plethora of free or low-cost data sharing applications available to end users, it has become critical to provide users with a more secure alternative that still empowers them to sync files across their devices and securely share files with co-workers. This paper explores the details of how ShareFile is secure by design, and highlights the set of security controls available to customers. Figure 1. ShareFile components overview with applicable ports 4

ShareFile consists of 3 primary components: the SaaS Application Tier, StorageZones, and the client. 1. SaaS Application Tier sometimes referred to the as the Control Plane, this is a Citrixmanaged component that consists of web, database, and API servers 2. StorageZones this is where customer data is stored. Customers have four options when deciding where to store their data. This paper will discuss the workflow and security processes of each option Citrix-managed cloud storage on Amazon Web Services Citrix-managed cloud storage on Microsoft Azure Customer-managed cloud storage on Microsoft Azure Customer-managed storage in corporate datacenters 3. Clients ShareFile supports a broad device list, which includes but is not limited to Windows and Mac OSX, Android and ios, Windows phone and Windows Metro 5

SaaS application tier ShareFile servers: web, API, and database overview The ShareFile SaaS Application Tier is hosted in Citrix s datacenter. The components include (see figure 2.): NetScaler used to load balance client requests to the ShareFile.com/eu webs and API webservers ShareFile.com/eu webservers designed to deliver the Web UI API webservers used for client devices and tools using the HTTPS and REST API, including the Outlook plug-in, mobile and sync applications Database SQL database instances which contain things such as account data, file and folder metadata, including access rights, user account data, logs etc. The database in the SaaS Application tier does not process or store any customer data files The NetScalers and web servers are installed in the DMZ with the SQL databases installed in the private network behind an additional firewall. The SQL database instances are securely replicated to a second datacenter for backup and disaster recovery purposes. Figure 2. SaaS Application Tier components overview SaaS application tier security Encryption To protect customer data in transit ShareFile supports SSL 3.0/TLS 1.0 with up to 256 bit AES encryption and no less than 128 bit encryption with the negotiation to TLS/AES-256 dependent on whether the end user s device or proxy supports TLS/AES-256. Hash-based message authentication code Hashing is defined as producing hash values for accessing data or for security purposes. A hash value (or simply hash) is a number generated from a string of text. The hash is substantially smaller than the text itself, and is generated by a formula in such a way that it is extremely unlikely that some other text will produce the same hash value. 6

In security systems, hashes are used to ensure that transmitted messages have not been tampered with. The sender generates a hash of the message, encrypts it, and sends it with the message itself. The recipient then decrypts both the message and the hash, produces another hash from the received message, and compares the two hashes. If the hashes are the same, it indicates that the message was transmitted intact. Metadata Customer files are never processed, stored or transferred to the ShareFile SaaS application tier. Instead we store metadata which when defined means data about data or data that describes other data. The metadata attributes that ShareFile stores in the SaaS application tier s database servers are as follows: User Info: First Name Last Name User Login (Email Address) Company Name (Optional) Password Hash Security Question Security Answer Access Control Lists (ACL) File Info: File Name File Description File Location File Size File Hash File Creation Date Email Notification Access Control Lists (ACL) IP Address from which file was uploaded Other: Account Subdomains on ShareFile.com/eu Audit & Reporting 7

Citrix-managed StorageZones Overview ShareFile operates a hybrid cloud infrastructure, with separate application and storage tiers managed by separate entities. Citrix manages the SaaS application tier (no file content) while an enterprise class cloud services provider (either Amazon Web Services or Microsoft Azure, depending on customer contract) hosts the StorageZone servers, along with application servers running the FTP/FTPS, Antivirus, Indexing, and Thumbnail services. The Citrix-managed StorageZones architecture consists of the SaaS Application tier, StorageZone Controller server(s) and cloud storage (see Figure 3). Figure 3. Citrix-managed StorageZones architectural overview 8

Securing file upload/download requests When a user uploads or downloads a file, ShareFile s architecture prevents forged requests by using hash-based message authentication codes or HMAC s. Figure 4. Preventing forged requests workflow diagram 1. Client requests a file. 2. A prepare message is sent by the ShareFile web application or API servers in the SaaS application tier to the StorageZone hosting the file. The location of the file is stored in the SaaS application tier database, accessed by the ShareFile web application and API servers. 3. A hash-based message authentication code (HMAC) based on the Shared Key used to establish a trust relationship between the SaaS application tier and StorageZone, is sent as part of the prepare message and is validated by the StorageZone Controller. 4. Once validated, the StorageZone confirms the validity and generates a unique one-time-use download token. 5. The ShareFile web application or API server provides the download link containing the fully qualified domain name (FQDN) of the StorageZones controller to the client with the unique download token. 6. To start the actual download, the client connects directly to the StorageZone. 7. The download token (part of the download request from the client), is validated. 8. If validation is successful, the file will be retrieved from storage, and the StorageZone will provide the file to the client. 9

Security Encryption in transit Client files are protected in transit between the web application and storage tier using SSL with no less than128 bit encryption depending on end-user browser configuration. Encryption at rest All client files are encrypted using AES 256-bit symmetric key encryption, a FIPS approved encryption algorithm. Data backup Customer files are stored redundantly within the cloud storage provider s region and ShareFile backs up all files daily. We store and back up customer files according to the data retention and version settings your dedicated ShareFile admin configures via the ShareFile administrative web interface. Anti-virus We employ dedicated antivirus servers that, based on customer preference, can scan all client files for malware. Any infected file is marked with a Red exclamation mark to warn end users of the risk associated with downloading an infected file. Amazon Web Services security The ShareFile infrastructure is segmented logically from other vendors using a concept Amazon Web Services refers to as Security Groups. Think of security groups as a firewall-like implementation that segregates ShareFile s infrastructure from other vendors. Amazon EC2 provides a firewall solution to enable security groups; this mandatory inbound firewall is configured in a default deny mode and we must explicitly open any ports to allow inbound traffic. The traffic may be restricted by protocol, by service port, as well as by source IP address (individual IP or CIDR block). Amazon Web Services runs in geographically dispersed datacenters that comply with key industry standards for security, reliability and confidentiality, such as ISO/IEC 27001:2005, SOC 1 and SOC 2. Microsoft Azure security Like Amazon Web Services, Windows Azure runs in geographically dispersed datacenters that comply ISO/IEC 27001:2005, SOC 1 and SOC 2. Datacenters are managed, monitored, and administered by Microsoft operations staff that have years of experience in delivering the world s largest online services with 24 x 7 continuity. In addition to datacenter, network, and personnel security practices, Windows Azure incorporates security practices at the application and platform layers to enhance security for application developers and service administrators. 10

Customer-managed StorageZones with on-prem storage Overview Customer-managed StorageZones allow IT administrators to choose where corporate data will be processed and stored. IT can store data in the organization s datacenter to help meet unique data sovereignty and compliance requirements, or an organization can choose to host ShareFile data natively in a Microsoft Azure account, helping IT build the most cost-effective and customized solution for their organization. The on-premise customer-managed data can be easily integrated with an organization s existing infrastructure as it is designed to support any Common Internet File System (CIFS)- based network share. In both options the SaaS application tier is a required component. The customer-managed on-premise architecture consists of the SaaS Application tier, StorageZone Controller server(s) and customer datacenter hosted backend storage (see Figure 5). Figure 5. Customer-managed on-premise StorageZones components diagram 11

Securing file upload/download requests The workflow is the same as Citrix-managed StorageZones. The ShareFile architecture in customer-managed StorageZones prevents forged upload and download requests by using hash-based message authentication codes (HMAC) as well. Figure 6. Preventing forged requests workflow diagram 1. Client requests a file. 2. A prepare message is sent by the ShareFile web application or API servers in the SaaS application tier to the StorageZone hosting the file. The location of the file is stored in the SaaS application tier database, accessed by the ShareFile web application and API servers. 3. A hash-based message authentication code (HMAC) based on the Shared Key used to establish a trust relation between the SaaS application tier and StorageZone, is sent as part of the prepare message and is validated by the StorageZone Controller. 4. Once validated, the StorageZone confirms the validity and generates a unique one-timeuse download token. 5. The ShareFile web application or API server provides the download link to the Client with the unique download token. 6. To start the actual download, the Client connects to the StorageZone. 7. The download token (part of the download request from the Client), is validated. 8. If validation is successful, the file will be retrieved from storage. 9. The StorageZones controller server will send the file to the Client. 12

Security Trust and encryption: on-premise StorageZone Shared Zone Secret Key created when StorageZone is created. Storage Encryption Key created when StorageZone Controller Encryption Key is encrypted by Passphrase when StorageZone Controller is configured. Figure 7. Security related SZ Controller configurations ShareFile StorageZones Controller server Once the pre-requisites for installation are met, installing the StorageZones Controller server software is simple and consists of launching an.msi file and clicking through until finished. Pre-requisites: Use a publicly-resolvable Internet hostname (not an IP address) Install a commercially trusted SSL certificate in IIS Allow inbound TCP requests on port 443 through the Windows firewall The installation file installs the following server components: A virtual directory and files into the IIS Default Web site. The physical location of the folder and files is c:\intetpub\wwwroot\citrix\storagecenter. An IIS application pool named StorageCenterAppPool. The installer also points the IIS Default Web Site s application pool to the newly created StorageCenterAppPool application pool. 4 windows services: --ShareFile Cloud Storage Uploader Service --ShareFile File Cleanup Service --ShareFile File Copy Service --ShareFile Management Service After installing the StorageZones Controller server software, configuration is required. Instructions on configuring the StorageZones Controller software can be found here. The configuration utility accomplishes the following tasks (see Figure 7): Creates a shared zone secret key in the customer s ShareFile account and on the StorageZones Controller server stored encrypted in the registry. 13

Creates a storage encryption key (SCKeys.txt) and encrypts that key using 128 bit encryption when a passphrase is entered in the last step of the configuration. This encryption key is only used if the Enable Encryption box is checked during configuration which instructs the StorageZone Controller server to encrypt the files stored in your shared ShareFile data repository. Creates a proprietary folder structure and the SCKeys.txt file in the ShareFile Storage Location network share location defined during the configuration. Enables StorageZone Connectors if Enable StorageZone Connector for Network File Shares and Enable StorageZone Connector for SharePoint are checked. Enabling the Connectors creates the IIS apps cifs (Connector for Network File Shares) and sp (Connector for SharePoint). Encryption in transit If a NetScaler is not used in the architecture, customer files are protected in transit between the web application and the customer-managed on-premise storage location using SSL with a minimum 128 bit encryption depending on end-user browser or proxy configuration. If customers are using Windows Azure, files are protected in transit between the web application and the customer-managed on-premise storage location and to the Windows Azure storage container using the same SSL protocols as above. If a NetScaler is used in the architecture, the SSL connection will be terminated at the NetScaler in the DMZ and files will be sent to the storage location either over http or https, depending on your configuration. If HTTP is used, files will traverse the internal network to the storage location un-encrypted. If HTTPS is used, files will traverse the internal network to the storage location using SSL. The storage server will then decrypt the files and store them. Encryption at rest The StorageZones Controller software has the ability to encrypt the files located in the Storage Location defined during configuration. If data encryption is enabled, all zone files are encrypted with 128 bit encryption using the same key stored in SCKeys.txt. It is therefore critical that the SCKeys.txt file and passphrase be backed up to a secondary secure location. If the SCKeys.txt file is lost, all zone files become inaccessible. Because this directory resides in a customermanaged datacenter it is a Citrix best practice to not have the StorageZones Controller software encrypt the data and leverage encryption options from your storage subsystem instead. If encrypted by the StorageZone Controller software, processes like anti-virus scanning and file indexing will not work. If customers are using Windows Azure, the StorageZones Controller software has the ability to encrypt the files located in the temporary storage location defined during configuration. If the files are encrypted they will be transferred to the Windows Azure storage container encrypted. Decryption happens when a file is requested for download. The file gets copied from the Azure storage container to the temporary storage location in the customer datacenter where it is decrypted and sent from the StorageZones controller server to the client. All communications from the StorageZones servers and Windows Azure storage containers happen over SSL. 14

Customer-managed Restricted StorageZones Overview In some highly regulated industries and organizations, having ShareFile data stored in customer-managed on-premises StorageZones still presents some privacy concerns. The first is that metadata, specifically file and folder names are still visible to Citrix, and secondly, as the authentication provider, Citrix must be trusted to authorize access to files. Customer-managed Restricted StorageZones is the solution to this problem. The on-premises StorageZones Controller encrypts the metadata with a customer-owned encryption key before writing that data to the Citrix SaaS application tier (sharefile.com/sharefile.eu). Access to decrypted files and metadata only happens via the StorageZones Controller server, which acts as an authenticating encryption/decryption proxy. Figure 8. Customer-managed Restricted StorageZone Encrypting file upload/download data and metadata During the configuration of a Restricted StorageZone, customer-owned private encryption keys are created and used for the encryption and decryption of file data and metadata. An HTTPS binding occurs to a new proxy service used to authenticate all requests to the Restricted StorageZone and serves as the only communication path to that Restricted StorageZone. Adding a document 1. Unencrypted file and metadata is uploaded from a client to the StorageZones Controller via the proxy service 2. Both the file and metadata are encrypted with the customer-owned encryption key 3. Encrypted file metadata is uploaded to ShareFile with a sample file name of!zk!@ OwYB92ryh-m9MvrQ6ejLQ$$!ZK! 4. Encrypted file is written to the Restricted StorageZones repository Enumerating files from the Restricted StorageZone 1. User logs in to ShareFile using either ShareFile credentials or via SAML and Active Directory. 2. The user is redirected to the StorageZone Controller s proxy service with a request for metadata. 15

3. The StorageZone Controller initiates an authentication to Active Directory prompting the user for domain credentials with appropriate permissions to view encrypted metadata. As part of the authentication process, the StorageZones Controller server also verifies that the e-mail address in Active Directory matches the e-mail address used to authenticate to ShareFile. 4. The StorageZone Controller server fetches the encrypted metadata from ShareFile and decrypts it for the user. 5. The unencrypted metadata is returned to the client. External access to encrypted file and metadata Encrypted file and metadata are being delivered from the customer-managed StorageZones Controller server. For this reason, to enable access for users not on the internal network or VPN, a NetScaler Gateway is used to server as the Restricted StorageZone s external domain address. The architecture is similar to how we architect authentication to SharePoint and Network Share connectors (section 8). The traffic headed to those connectors is stopped at the NetScaler in the DMZ, authenticated and then those credentials are passed to the appropriate location using SSO. With Restricted StorageZones all traffic destined for the StorageZone Controller server can be stopped at the NetScaler, authenticated and credentials passed back to the StorageZone Controller using SSO. Email notifications The ShareFile SaaS application tier cannot see the folder and file names, therefore sharing and upload/download notification emails cannot be sent by Shar efile. Using Restricted Zones, customers will need to point to an SMTP server that is reachable by the on-premises StorageZones Controller server. Notification e-mail content with encrypted info is downloaded by the StorageZones Controller via the use of an Azure service bus, decrypted, and then sent via SMTP. Sharing/sending files 1. Client initiates the request to share an encrypted document 2. The share object is requested and digitally signed by the StorageZones Controller 3. In ShareFile a share e-mail message object is created with encrypted file names 4. The StorageZones Controller downloads the encrypted message using the Azure service bus 5. The message is decrypted by the StorageZones Controller server and sent to the SMTP server where it is sent to all recipients Receiving a shared file 1. User clicks the Share URL from ShareFile.com 2. ShareFile.com redirects the user to the StorageZones Controller server where they are required to authenticate with Active Directory credentials 3. After successful authentication the StorageZones Controller fetches the signed shared object, validates the signature and enforces security policies 4. The file is obtained from the StorageZone data storage repository and delivered to the client from the StorageZones Controller server 16

Customer-managed StorageZones with Windows Azure storage Overview The Microsoft Azure customer-managed solution (Figure 8) integrates ShareFile with Microsoft Azure s Binary Large Object (Blob) storage, a cloud service for storing large amounts of unstructured data that can be accessed from anywhere in the world via HTTP or HTTPS. The Azure Storage architecture is similar to the customer-managed on-premise StorageZones architecture with one minor difference. Azure storage is customer-managed storage hosted in the Azure cloud. File uploads are initially deposited into a temporary storage area shared by all StorageZone controllers. Then, a background service copies those files to the Windows Azure storage container and deletes the local cached copy of the file(s). Figure 9. Customer-managed StorageZones with Windows Azure components diagram 17

Securing file upload/download requests Because the architecture is very similar to the customer-managed on premise StorageZones architecture, the workflow is the same with one small difference highlighted in bold below. Figure 10. Preventing forged requests workflow diagram 1. Client requests a file. 2. A prepare message is sent by the ShareFile web application or API servers in the SaaS application tier to the StorageZone hosting the file. The location of the file is stored in the SaaS application tier database, accessed by the ShareFile web application and API servers. 3. A hash-based message authentication code (HMAC) based on the Shared Key used to establish a trust relation between the SaaS application tier and StorageZone, is sent as part of the prepare message and is validated by the StorageZone Controller. 4. Once validated, the StorageZone confirms the validity and generates a unique one-time-use download token. 5. The ShareFile web application or API server provides the download link to the Client with the unique download token. 6. To start the actual download, the Client connects to the StorageZone. 7. The download token (which is part of the download request from the Client), is validated. 8. If validation is successful, the file will be retrieved from Windows Azure storage and placed in the shared storage location in the customer datacenter. 9. The StorageZones controller server will send the file to the Client. 18

Security The installation of the StorageZones controller software is identical to the customer-managed on premise installation instructions, but the configuration of the software requires some additional steps. Instructions on configuring the StorageZones Controller software with Windows Azure support can be found here and there is a video of the configuration located here. The configuration utility accomplishes the following tasks (see Figure 7 above) with the difference in configuration in bold below: Creates a shared zone secret key in the customer s ShareFile account and on the StorageZones Controller server stored encrypted in the registry. Creates a storage encryption key (SCKeys.txt) and encrypts that key when a passphrase is entered in the last step of the configuration. This encryption key is only used if the Enable Encryption box is checked during configuration which instructs the StorageZone. Controller server to encrypt the files stored in your shared ShareFile data repository Creates a proprietary folder structure and the SCKeys.txt file in the ShareFile Storage Location network share location defined during the configuration. Enables StorageZone Connectors if Enable StorageZone Connector for Network File Shares and Enable StorageZone Connector for SharePoint are checked. Enabling the Connectors creates the IIS apps cifs (Connector for Network File Shares) and sp (Connector for SharePoint). Connects the StorageZones controller server to the Windows Azure account using the account name and 512-bit authentication key generated in Azure when the Azure storage container is created. Once the StorageZones controller authenticates to Azure the administrator is presented with a list of available storage containers to choose from for the ShareFile data storage location. 19

StorageZone Connectors Overview ShareFile StorageZone Connectors, enabled by a customer-managed implementation of a StorageZones controller server, help organizations leverage and mobilize existing enterprise data platforms. This feature, available in the ShareFile mobile app for iphone, ipad and Android devices, allows mobile users to create a secure connection to existing CIFS network shares and SharePoint document libraries. The StorageZone Connectors architecture consists of the SaaS application tier, a customermanaged implementation of a StorageZones Controller server, network shares and SharePoint document libraries. Figure 11. StorageZone Connectors component architecture 20

Securing file upload/download requests Figure 12. StorageZone Connectors workflow diagram without NetScaler 1. User login request sent to subdomain.sharefile.com 2. Top-level StorageZone connectors are displayed 3. User login request sent to organizations Active Directory 4. User authenticated to Active Directory 5. Network shares enumeration 6. SharePoint document libraries enumeration 7. Files are uploaded/downloaded Security When using StorageZone Connectors, an additional authentication step (Step 3 in Figure 10) is introduced when users access a Connector, and the file upload/download authorization step from sharefile.com is removed. Additional StorageZone Connectors security information: Clients always use HTTPS when initiating connections to the StorageZones Controller HTTPS Basic authentication is required to support all mobile applications Passwords are never sent in clear text by ShareFile clients ShareFile administrators can control through user permissions which users have the ability to create connectors Administrators can also whitelist/blacklist connectors to specific file shares and SharePoint libraries 21

Data Loss Prevention (DLP) integration Overview ShareFile integrates with several market-leading Data Loss Prevention (DLP) products enabling content-aware sharing restrictions. Documents stored in your on-premises StorageZone can be examined by any third-party DLP security suite that supports ICAP, a standard network protocol for inline content scanning. Sharing and access privileges can then be adjusted based on the results of the DLP scan and your preferences for how strictly you want to control access. Which DLP systems are supported? Because we rely on the ICAP standard for interaction with your DLP server the ShareFile DLP integration will work with any ICAP-compliant solution and requires no changes to policies or servers in your existing security suite. ICAP-compliant solutions include: Symantec Data Loss Prevention McAfee DLP Prevent Websense TRITON AP-DATA RSA Data Loss Prevention Tying ShareFile security policies to your existing DLP security suite means you can maintain a single point of policy management for data inspection and security alerts. If you already use one of the solutions mentioned above for scanning outgoing e-mail attachments or web traffic, you can point the ShareFile StorageZones Controller to the same server. How ShareFile works to prevent data loss How ShareFile works to prevent data loss Figure 13. Graphical overview of DLP integration solution. 22

We ve developed a flexible policy-based system that offers granular access and sharing controls based on a new classification attribute that will be associated with each file. The system uses the DLP scan results to classify every version of every file in your StorageZone. There are three data classifications: 1. Scanned: OK Files that were scanned by a DLP system and passed OK 2. Scanned: Blocked Files that were scanned by a DLP system and were found to contain sensitive data 3. Unscanned Files that have not yet been scanned (in cases where files exist before DLP is configured, or when the external DLP system is unavailable or slow to respond) Next, the ShareFile platform enforces different access and sharing restrictions for each data classification. For each of the three categories, the ShareFile administrator chooses which actions to allow: Whether employees can download or share the file Whether 3rd-party users can download share the file Whether anonymous users can download the file These settings constrain the normal permissions and sharing controls available to users as they interact with their ShareFile data and collaborate with others. For instance, when sending someone a file, users could choose to block anonymous access even if DLP settings would allow them to share it anonymously. But if they attempt to share a file in a way that the DLP settings prohibit, the platform prevents them from doing so. This flexibility allows you to control the trade-offs between security and usability as best fits your organization. If a document is flagged as sensitive, you could still allow sharing between employees but block sending to anyone outside your organization. Or you could take a stricter approach and block all users (even the owner of the file) from downloading or sharing the file with anyone. If you block downloads, an employee would not be able to access ShareFile from an unmanaged device, get the file and share it by other means. For any files that are not yet scanned, you can configure the same sets of constraints. This means ShareFile could take an innocent until proven guilty or guilty until proven innocent approach according to your approach for impeding the flow of information. When the StorageZones Controller sends files to the DLP system for scanning, it includes metadata indicating the owner of the file and the folder path where the file resides in ShareFile. This allows the DLP server to log incidents and create notifications with enough detail to be actionable. 23

NetScaler integration Overview A demilitarized zone (DMZ) provides an extra layer of security for the internal network. A DMZ proxy, such as Citrix NetScaler VPX, is an optional component used to: Ensure all requests to a StorageZones originate from sharefile.com or sharefile.eu, so that only approved traffic reaches the StorageZone Controllers Validates URI signatures before forwarding messages to StorageZone controllers reducing load on the StorageZone controllers Load balance requests to StorageZone Controllers using real-time status indicators Offload SSL from StorageZone Controllers Ensure requests for files on SharePoint or network drives are authenticated before passing through the DMZ r files on SharePoint or network drives are authenticated before passing through the DMZ. Figure 14. NetScaler components architecture for on-premise StorageZones Controllers In this scenario, two firewalls stand between the Internet and the secure network. StorageZone Controllers reside in the internal network. User connections to ShareFile must traverse the first firewall and use the SSL protocol on port 443 to establish this connection. To support this connectivity, you must open port 443 on the firewall and install a public SSL certificate on the NetScaler appliances (if they terminate the user connection). 24

Figure 15. NetScaler configuration architectural diagram NetScaler content switching virtual server sends user requests for data from ShareFile and from StorageZones Connectors to the appropriate NetScaler load balancing virtual server NetScaler load balancing virtual server Load balances the traffic for your StorageZones Controllers and also handles requests for data from your on-premise data storage and from StorageZone Connectors Requests for ShareFile data from on-premise data storage A load balancing virtual server performs hash validation, to ensure valid URI signatures are present on incoming requests. Figure 16. NetScaler configuration architectural diagram for ShareFile data Securing ShareFile data upload/download requests with NetScaler The following diagram and table describe the network connections that occur when a user logs onto ShareFile and then downloads a document from an on-premise storage zone deployed behind NetScaler. File activity is accessed via NetScaler in the DMZ, which terminates SSL, authenticates user requests and then accesses the StorageZone Controller in the trusted network on behalf of authenticated users. The NetScaler external address for ShareFile is accessed using the Internet FQDN szc.company.com (See Figure 17). 25

Figure 17. Securing requests for on-premise ShareFile data with NetScaler 1. The client makes a user logon request to company.sharefile.com over HTTPS 2. The client makes a file/folder enumeration and download request to company.sharefile.com over HTTPS 3. A file download authorization comes from sharefile.com to the szc.company.com (external address) over HTTP(S) 4. A file download authorization is sent from the NetScaler NSIP to the StorageZones Controller over HTTPS 5. A file download request comes from the Client to the szc.company.com (external address) over HTTPS 6. A file download request is sent from the NetScaler NSIP to the StorageZones Controller server over HTTP(S) 7. The file is downloaded In between steps 4 and 5 the NetScaler strips the HMAC from the URI and sends the URI & HMAC to the StorageZones Controller server. The HMAC is validated by the StorageZones Controller server which then sends confirmation to NetScaler. The process completes and file is uploaded or downloaded. Requests for data from StorageZones Connectors A load balancing virtual server performs user authentication. It stops a user request at the NetScaler, authenticates the user, and then performs single sign-on of the user to the StorageZones Controller. Although authentication to NetScaler is optional, it is a recommended best practice. 26

Figure 18. NetScaler configuration architectural diagram for StorageZone Connectors Securing ShareFile Connector upload/download requests with NetScaler The following diagram and table extend the previous scenario (see Figure 17) to show the network connections for StorageZone Connectors. This scenario includes the use of NetScaler in the DMZ to terminate SSL and perform user authentication for Connectors access. Figure 19. Securing requests for ShareFile Connector data with NetScaler 1. The client makes a user logon request to company.sharefile.com over HTTPS 2. The client requests top-level connector enumeration from company.sharefile.com over HTTPS 3. The client then sends a user logon to the StorageZones Controller server via the szc. company.com (external address) over HTTPS 4. The user is authenticated from the NetScaler SNIP to the AD domain controller over LDAP(S) 5. The NetScaler SNIP sends file/folder enumeration and upload/download requests to the StorageZones Controller over HTTP(S) 6. The StorageZones Controller server sends network share enumeration and upload/ download requests to the customer file server over CIFS or DFS 7. The StorageZones Controller server sends SharePoint enumeration and upload/download requests to the internal customer SharePoint server over HTTP(S) 27

SAML integration Overview Security Assertion Markup Language (SAML) is a standard for exchanging authentication and authorization data between security domains. SAML is an XML-based protocol that uses security tokens to pass information about a principal (usually an end user) between a SAML authority, (an identity provider), and a SAML consumer, (a service provider). SAML enables web-based authentication and authorization scenarios including cross-domain single sign-on (SSO), which helps reduce the administrative overhead of distributing multiple authentication tokens to an end user. ShareFile supports single sign-on via SAML 2.0 and integrates with a number of federated identity management solutions. ShareFile requires SAML assertions to include a NameID in the format emailaddress. Workflow Figure 20. ShareFile SAML 2.0 Workflow 1. Client requests https://subdomain.sharefile.com/saml/login from sharefile.com 2. Client discovers identity provider 3. Client is redirected via an HTTPS 302 redirect to identity provider @ https://mydomain.com/ idroot with SAML request 4. Client requests identity provider @ https://mydomain.com/idroot 5. Identity provider authenticates the user and redirects client to Assertion Consumer Service @ https://subdomain.sharefile.com/saml/acs with SAML response 6. Client posts SAML response to the Assertion Consumer Service @ https://subdomain. sharefile.com/saml/acs 7. Assertion Consumer Service validates SAML response and authenticates the user if successful ShareFile sets a session cookie and redirects Client to https://subdomain.sharefile.com 8. Client requests https://subdomain.sharefile.com 9. Access to https://subdomain.sharefile.com/default granted. End user defaults to personal folder 28

Security and benefits User passwords never cross the firewall, since user authentication occurs inside of the firewall and multiple web application passwords are no longer required. Web applications with no passwords are virtually impossible to hack, as the user must authenticate against an enterprise-class Identity Provider first, which can include strong authentication mechanisms. Service Provider (SP)-initiated SAML SSO provides access to web apps for users outside of the firewall. If an outside user requests access to a web application, the SP can automatically redirect the user to an authentication portal located at the Identity Provider. After authenticating, the user is granted access to the application, while their login and password remains locked safely inside the firewall. Centralized federation provides a single point of web application access, control and auditing, which has security, risk and compliance benefits. The ability to offer secure, scalable, standards-based Internet SSO to customers, either as a value-added service, a competitive differentiator, or to satisfy customer demands. Ability to federate with other service providers, sharing user identity in order to deliver seamless, transparent, value-added services without requiring an additional login. Additional resources These additional resources can be used to get more information on ShareFile SAML configuration. 1. Configure Single Sign-on for SAML-Based Federation using ADFS 2. Configure Single Sign-on for SAML-Based Federation using Ping Federate 3. Configure Single Sign-on for SAML-Based Federation using CA SiteMinder 4. Configure Single Sign-on for SAML-Based Federation using OKTA 29

OAuth Overview OAuth is an open protocol to allow secure authorization in a simple and standard method from web, mobile and desktop applications. ShareFile supports the OAuth 2.0 framework which enables applications like the ShareFile mobile, sync, and Outlook Plug-In to obtain limited access to an HTTP service like ShareFile.com. The great thing about OAuth is that it uses access tokens to provide authentication protecting the end-user s account credentials. The following ShareFile clients support OAuth: iphone and ipad --With the exception of the MDX-wrapped versions of this client. Those will ask Worx Home for a SAML token during every login attempt Android --With the exception of the MDX-wrapped versions of this client. Those will ask Worx Home for a SAML token during every login attempt Windows Phone 8 Windows 8 Modern App ShareFile Sync for Windows and ShareFile Sync for MAC Outlook Plug-In Workflows Web authentication ShareFile credentials Below is a graphical representation of how the ios mobile client exchanges a user s credentials with an OAuth token. Please refer to section 9.2.2 for the definitions of specific terms used in the following workflow. In most scenarios our latest mobile apps will use the Web authentication flow for authenticating the exception for mobile is the MDX builds of ios and Android get a SAML token directly from Worx Home and authenticates without OAuth. 30

Figure 21. IOS mobile client web authentication flow using ShareFile credentials 1. The first step in the request of an OAuth token will be either a GET or POST request with the following parameters: response_type Needed to determine whether the endpoint returns an authorization code. For web applications (like ShareFile.com) the value of code is used. client_id This is hard coded in the code of the mobile client. redirect_uri An HTTPS URI or custom URL scheme where the response will be redirected. This is also hardcoded into the mobile client and gets set when the mobile client is initially installed on the mobile device. 2. Next in the sequence will be calls for account discovery. This is when a user enters their ShareFile credentials and subdomain. 3. Once the client has finished account discovery an HTTP 302 is sent to the client with the redirecturi and the following parameters: code authorization code returned from ShareFile expires_in the amount of time the authorization code is valid for subdomain the user s subdomain from account discovery appcp the web application control plane (ShareFile.com etc) apicp the API control plane for the user 31

4. Next in the sequence will be the POST request sent to subdomain.appcp/oauth/token with the following parameters found in our API documentation: Header: Content-Type: application/x-www-form-urlencoded Content: grant_type authorization_code (this has to be authorization_code.) code the authorization code received in the previous step client_id comes from the mobile client code client_secret this is a client specific secret hardcoded into the software An example request in curl looks like: curl https://subdomain.sharefile.com/oauth/token \ -d grant_type=authorization_ code&code={your_code}&client_id={your_client_id}&client_secret={your_client_ secret} \ -X POST 5. If successful the client will receive an HTTP 200 response with a JSON encoded object with the following data: access_token The access token. refresh_token The refresh token. token_type The token type. apicp The user s ShareFile API control plane, i.e. sharefile.com for the above example. appcp The user s ShareFile account control plane, i.e. for the above example. subdomain The user s ShareFile subdomain, i.e. if they access their ShareFile account through https://mycompany.sharefile.com, this value would return mycompany. Some username / password combinations may be active on multiple accounts. The user would need to choose an account in this case. expires_in The expiration time in seconds. A sample OAuth token would look like this: Figure 22. A sample OAuth token. 32

You ll notice that the response includes an access_token and a refresh_token. Access_tokens are designed to expire in 8 hours and can be revoked at any time by the ShareFile administrator. Refresh_tokens are designed to have a lifetime assigned to them after which they expire and force re-authentication. The default lifetime for the refresh_token is set to never expire but can be changed by the ShareFile administrator to 1, 7 or 30 days, this OAuth Lifetime setting is located in your ShareFile account on the Admin Advanced Preferences Password, Login and Security Policy page and ShareFile support can set a custom timeframe if one is needed. These tokens can also be revoked at any time by the ShareFile administrator and if an employee leaves the company, disabling or deleting their account in ShareFile will automatically revoke all of their tokens and break their access to ShareFile. The way that the tokens work is as follows. When you configure your ShareFile account on a mobile client the client checks the Device Security configuration and if Automatic Login is enabled the client will store the access and refresh tokens on the device. This makes opening and using the ShareFile client much easier. If Automatic Login is disabled the user will be prompted with their E-mail address and password every time they use the ShareFile client. What needs to be stressed here is that we are not storing user credentials in the client we are storing access and refresh tokens that are linked to the user s credentials. Anytime a user opens the ShareFile application the application checks to see whether the access_token has expired. If it hasn t expired the access_token is used to authenticate the user to ShareFile and the user is presented with his or her files and folders. If the access_token has expired, an example of this would be the user hasn t opened the application in less than 8 hours, the refresh_token is used to refresh the access_token and restarts the 8 hour expiration clock. The user doesn t know this is happening and authentication happens instantaneously bringing the user to his or her files and folders. Parameter definitions Field access_token refresh_token token_type apicp appcp subdomain expires_in Description Short lived token presented to ShareFile to obtain an authid. Long lived token used to acquire new access token. Token type typically will be bearer. API Control Plane for the user. Control Plane for the web app (sharefile.com, securevdr.com, etc.). Subdomain for the user s account. Lifetime of the access_token in seconds. Figure 23. Parameter Definitions. 33

Web authentication SAML The workflow for the IOS and Android mobile client using SAML is very similar to the above workflow with the exception of the redirection and authentication with the SAML IdP. Figure 24. Mobile client web authentication flow using SAML. Desktop apps Our desktop apps that support OAuth (Desktop Sync and Outlook Plug-in) will only do the account discovery part of the web authentication natively. If the user can login using their ShareFile e-mail address/password the desktop app will use the Password Authentication flow in Figure 23 below. If the customer uses an IdP that can do some sort of integrated authentication the desktop app will natively capture the SAML token and use the SAML Authentication Native flow in Figure 24 for exchanging the SAML token for OAuth token. And finally, if the customer uses forms authentication the application will switch to the Web authentication SAML flow in Figure 25 and provide the username and subdomain, autoadvancing the flow to the IdP and bypassing all calls for account discovery. Password authentication ShareFile credentials Figure 25. Password Authentication flow for desktop apps using ShareFile credentials 34

If your account doesn t use SAML, the ShareFile Sync for Windows, ShareFile Sync for MAC and the Outlook Plug-in will use this Password Authentication ShareFile Credentials flow. SAML authentication native Figure 26. SAML Authentication Native flow for desktop apps using SAML integrated windows authentication If your account is using SAML with integrated windows authentication the ShareFile Sync for Windows, ShareFile Sync for MAC and the Outlook Plug-in will use this SAML Authentication Native flow. Web authentication SAML Figure 27. Web authentication flow for desktop apps using forms-based SAML authentication 35

If your account has Web Authentication enabled, is using the ShareFile Sync for Windows, ShareFile Sync for MAC or the Outlook Plug-in and your SAML IDP is configured for web-based (forms) authentication this Web authentication SAML flow will be used. To Enable Web Authentication in your ShareFile account navigate to the Admin Configure Single Sign-On page and under Optional Settings check the Enable Web Authentication box. Security and benefits Since the advent of OAuth 2.0 all OAuth data transfers must take place on SSL (Secure Sockets Layer) to ensure the most trusted cryptography industry protocols are being used to keep data as safe as possible. By using Oauth 2.0, ShareFile provides users access to their data while protecting their account credentials. Access and refresh tokens are stored in the client software allowing users to easily log in and connect to their files and folders while the administrator has complete control in revoking those tokens on demand, forcing re-authentication into the application. ShareFile supports OAuth for 3rd party applications like RightSignature and SalesForce, as well as companies like point.io and CloudFuze who use OAuth and our API s to link into Enterprise Content Management systems. 36

Conclusion This paper details how ShareFile is secure by design, and enumerates the complete set of security and compliance controls available to customers. Flexible data storage Organizations can selectively store ShareFile data in Citrix-managed StorageZones, which provide highly secure cloud storage without the need for on-premise infrastructure or maintenance; in StorageZones managed directly within the customer s own datacenter; or in both. This flexibility helps IT address the organization s unique data sovereignty and compliance requirements while building the most cost- effective and customized solution. Seamless integration with existing data platforms Working in conjunction with customermanaged StorageZones, StorageZone Connectors let IT create a secure connection between the ShareFile service and user data stored in existing network shares without the need for data migration. Enterprise-grade security ShareFile is an enterprise solution that provides extensive data protection features. Files are encrypted both at rest and in transit. Remote wipe allows secure destruction of all ShareFile-stored data and passwords on a device that has been compromised. IT can also remove a device from the list of devices that can access ShareFile accounts, or lock a device to restrict its use for a defined period of time. A poison pill capability lets IT prescribe data expiration policies for mobile devices. Auditing and reporting IT can track and log all user activity, including both data access and data sharing, to support compliance requirements and provide visibility into data usage. Users and IT can also create custom reports on account usage and access. ShareFile makes it possible for IT to provide the anywhere, any device data access and collaboration people need while meeting the organization s requirements for security, manageability and compliance. With more than two decades of experience serving enterprise IT, Citrix designed ShareFile as a true enterprise-class solution that eliminates the threat posed by consumer file sharing services while providing the industry s most comprehensive feature set. By making follow-me data a seamless and intuitive part of every user s day, ShareFile enables optimal productivity for todays highly mobile, anywhere, any device workforce. 37

Appendix A. Mobile device security This section summarizes the ShareFile security controls available for mobile devices. Many controls are provided as a native part of ShareFile. When ShareFile is used in conjunction with the XenMobile enterprise solution, more controls become available. The table below indicates which security controls are provided by ShareFile and XenMobile enterprise, and which are applicable to ios or Android devices. Security Control Description ios Android Provided by ShareFile Disable offline access Require password File self-destruct Allow or deny download of documents to the mobile device for offline viewing or editing. When enabled, the user must be on the network to view or edit documents. Whether end users can save their password on the device. When disabled, users must authenticate each time the app is launched. Documents downloaded to the device are automatically removed after a fixed amount of time. Encrypt files at rest Device-specific file encryption within the ShareFile app - requires passcode lock setting to be enabled. Passcode lock Device lock Prompts user for a ShareFile-specific passcode whenever the ShareFile app is launched. Prevents user from logging onto the current account with the ShareFile app until the administrator unlocks the device. Jail-break detection Prevent use of the ShareFile app if the device is jail-broken. Wipe Wipe status and auditing Disable external applications Secure Sharing Session inactivity timeout Provided by XenMobile Constrain clipboard cut and copy Constrain clipboard paste Constrain external applications Constrain URL Schemes Block camera Removes all ShareFile account information and data from the device. Status of the wipe operation is communicated to the control plane. Applies only to ShareFile account data; see XenMobile and AppController sections for more comprehensive wipe options. Status of the wipe request is communicated to the ShareFile administrator as pending or complete. After wipe completion, any actions performed by the client after the wipe was requested are reported to the administrator. Prevents opening of downloaded ShareFile documents in thirdparty apps ( open in ). Require recipients of shared files and folders to log on prior to download. Automatically log out inactive users after a configured amount of time. Allow/disallow cut and copy of data from the ShareFile app to be pasted into other applications. Allow/disallow data from other applications to be pasted into the ShareFile app. Allow/disallow only approved (MDX wrapped) external applications to be used for opening ShareFile documents (open in). Filter the URL schemes that are passed into the ShareFile application for handling. Prevent ShareFile from using the device camera to upload photos or videos taken with the device. 38

Security control Description ios Android Block microphone Block screen capture Block email compose Disable print Require Citrix Worx Home Authentication Define maximum offline period Require regular re-authentication Wipe data after security event Online access only Constrain Wi-Fi networks Require internal network Constrain network access App update grace period Require device encryption Require device pattern screen lock Provided by XenMobile MDM Prevent ShareFile from using the device microphone to capture and upload videos taken with the device. Prevent a user-initiated screen capture operation while ShareFile is running. Prevent ShareFile from sending e-mails via the native mail application. Enable or disable printing of ShareFile documents from the mobile device to a network printer. The user must have a valid session with Worx Home in order to use ShareFile. A separate password can be required for offline access. Defines the maximum period ShareFile can run offline without a network logon. Challenge an authenticated user to re-authenticate at regular intervals in order to continue using ShareFile. Any persistent data maintained by the ShareFile app can be erased, effectively resetting the app to its just installed state, if any of the following events occur: Loss of app entitlement for the user App subscription removed Receiver account removed Receiver uninstalled Too many app authentication failures Jail-broken or rooted device detected Device placed in lock state by administrative action. The user must log on to Worx Home in order to use the ShareFile app no offline access. Require the device be connected to one of a white list of named Wi-Fi networks in order to launch the app. Require the device to be connected to an internal company network (determined by connectivity to an internal beacon). Require the ShareFile app to route all of its traffic through the company network. Defines the grace period during which users may use ShareFile after the system has discovered that a ShareFile app update is available. If set to 0, the update must be applied as soon as it becomes available. Locks the ShareFile app if the device does not have encryption configured. Locks the ShareFile app if the device does not have a pattern screen lock configured. Application white list / black list Application provisioning Application removal Allow or deny use of the ShareFile app on the device. If the application is installed before a black list policy is applied to the device, the app is removed. Install the ShareFile application automatically when the device is enrolled by XenMobile Remove the ShareFile application by administrator action or if the device is un-enrolled from XenMobile by the end user. Figure 28. Mobile Device Security table 39

Appendix B. ShareFile web application security features The following ShareFile web application security and compliance features provides ShareFile the necessary tools to safeguard your data. Features Description Configurable settings Password policy Custom SMTP (mail) settings SAML 2.0 enabled single sign-on Multi-factor authentication File retention File versioning Terms and conditions FTP/FTPS OAuth 2.0 support Account lockout Customized folder permissions Require login Account activity reporting Email notifications Email domain whitelist / blacklist Access log retention Administrators have the option of configuring password policies including password history, expiration, and complexity controls such as length, uppercase and lowercase letters, at least one number, and at least one special character. ShareFile enables accounts to route email messages through their own mail servers. When enabled, all e-mails sent through ShareFile will be routed through the client s mail sever, instead of ShareFile mail servers. Administrators may optionally configure the connection to support SSL. ShareFile supports SAML 2.0 for single sign-on and integrates with most SAML-compatible identity management solutions. (See section 7.) Accounts can be configured to allow a mix of SAML authentication and password-based authentication, or set to require SAML authentication for all users. Administrators may set up a multi-factor (or strong) authentication process that requires submission of the account password and a secondary authentication, such as Google authentication or SMS/text message, in order to access the account. ShareFile supports various two-factor and two-step authentication methods including forms and token-based authentication as well as SMS, voice and backup codes. Users can choose to automatically delete files a certain number of days after upload to support retention preferences and policies. Users can view different versions of a file uploaded with the same name to ensure that no changes are lost between updates or edits. Terms and conditions can be displayed on the login page, with the option of including a check box on the login screen that must be marked to indicate compliance with the terms before logging in. By default, file transfers occur over HTTPS (Port 443). Optionally, users can connect to ShareFile using FTP or FTP over SSL (FTPS connection over port 990), an inherently more secure protocol than FTP. Users can connect to ShareFile directly from an FTP/FTPS program, providing a way for users to upload or download files to or from a secure location while using existing FTP/FTPS programs. ShareFile supports the OAuth authentication protocol with configurable OAuth token expiration time intervals. ShareFile can configure your account to lock for five minutes after five invalid logon attempts to prevent account tampering. This application control is an account preference that can be customized to meet individual compliance needs. Administrative users can set folder permissions to ensure that employee and client users may only access specific folders. These permissions may be set to propagate to subfolders or apply only to specific subfolders. ShareFile administrators can disable anonymous sharing requiring login for all file sharing. ShareFile allows administrative users to run and access various reports on activity, usage, storage and permissions. Reports can be run on demand or emailed daily, weekly or monthly. Users can choose to have customized notifications sent in real time or in a consolidated daily message. ShareFile administrators can restrict file sharing based on email domain. Detailed file-access logs are retained for at least one year. 40

Features Description File archiving Archiving for financial services When enabled, ShareFile s archiving feature supports your compliance with federal regulations regarding data retention by retaining all files, links, attachments and versions either uploaded or sent through the ShareFile SMTP email server for a customizable period of at least three years. ShareFile Cloud for Healthcare HIPAA Audit controls Unique users and authentication Encryption Integrity controls Physical safeguards Testing and evaluation ShareFile provides multiple technical safeguards to support client compliance obligations under HIPAA. ShareFile supports your HIPAA compliance and will provide and sign a HIPAA Business Associate Agreement upon request. Administrators can use the tools provided within ShareFile to review account activity, such as account usage and access to files and folders, to track disclosures. ShareFile provides administrators the capability to assign individual user accounts based on unique email addresses. Administrators are responsible for providing unique accounts and logins to each user. ShareFile handles the encryption and decryption of all files, including those presumed to contain PHI. Customers can, at their discretion, also encrypt files prior to uploading them to their ShareFile account. To help ensure that PHI has not been altered or destroyed in transit or at rest, ShareFile verifies file size and uses industry-accepted hashing algorithms to verify file integrity during file transfers. Measures are in place to prevent unauthorized persons from gaining physical access to datacenters and systems, where PHI may be processed or stored. Infrastructure-as-a-Service providers do not have access to unencrypted customer files and do not manage encryption on Citrix s behalf. To maintain compliance with the HIPAA Security Rule, Citrix engages an independent third party to perform periodic risk assessments and gap analyses. Figure 29. ShareFile web application security and compliance features table Additional HIPAA documents can be located via the hyperlinks below. What is the ShareFile Cloud for Healthcare? ShareFile Cloud for Healthcare Frequently Asked Questions. Corporate Headquarters Fort Lauderdale, FL, USA India Development Center Bangalore, India Latin America Headquarters Coral Gables, FL, USA Silicon Valley Headquarters Santa Clara, CA, USA Online Division Headquarters Santa Barbara, CA, USA UK Development Center Chalfont, United Kingdom EMEA Headquarters Schaffhausen, Switzerland Pacific Headquarters Hong Kong, China About Citrix Citrix (NASDAQ:CTXS) is leading the transition to software-defining the workplace, uniting virtualization, mobility management, networking and SaaS solutions to enable new ways for businesses and people to work better. Citrix solutions power business mobility through secure, mobile workspaces that provide people with instant access to apps, desktops, data and communications on any device, over any network and cloud. With annual revenue in 2014 of $3.14 billion, Citrix solutions are in use at more than 330,000 organizations and by over 100 million users globally. Learn more at www.. Copyright 2015 Citrix Systems, Inc. All rights reserved. Citrix, ShareFile, NetScaler, NetScaler Gateway, XenMobile, Worx Home and Citrix Receiver are trademarks of Citrix Systems, Inc. and/or one of its subsidiaries, and may be registered in the U.S. and other countries. Other product and company names mentioned herein may be trademarks of their respective companies 0615/PDF 41