ShareFile Enterprise

Security White Paper

Providing security is essential when implementing
an Enterprise class file sync and sharing solution
Learn how ShareFile Enterprise provides industry-leading security
measures to protect both ShareFile.com and our customers data

citrix.com/sharefle
 White Paper

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

citrix.com/sharefle | White Paper | ShareFile Enterprise Security White Paper 2

 White Paper

Table of Contents
22 Which DLP systems are supported?
22 How ShareFile works to prevent data loss
24 Information Rights Management
29 Customer Managed Encryption Keys
32 NetScaler integration
32 Overview
33 Requests for ShareFile data from on-premise data storage
33 Securing ShareFile data upload/download requests with NetScaler
34 Requests for data from StorageZones Connectors
35 Securing ShareFile Connector upload/download requests with NetScaler
36 SAML integration
36 Overview
36 Workflow
37 Security and benefits
37 Additional resources
38 OAuth
38 Overview
38 Workflows
38 Web authentication ShareFile credentials
41 Parameter definitions
42 Web authentication SAML
42 Desktop apps
44 Security and benefits
45 Conclusion
46 Appendix A.
46 Mobile device security
49 Appendix B.
49 ShareFile web application security features

citrix.com/sharefle | White Paper | ShareFile Enterprise Security White Paper 3

 White Paper

Introduction
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 ShareFile Enterprise customers.

Figure 1. ShareFile components overview with applicable ports

citrix.com/sharefle | White Paper | ShareFile Enterprise Security White Paper 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 Citrix-
managed 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

citrix.com/sharefle | White Paper | ShareFile Enterprise Security White Paper 5

 White Paper

SaaS Application Tier

ShareFile servers: web, API, and database overview

The ShareFile SaaS Application Tier is hosted in Citrixs 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 TLS 1.2 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 users 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.

citrix.com/sharefle | White Paper | ShareFile Enterprise Security White Paper 6

 White Paper

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 tiers 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

citrix.com/sharefle | White Paper | ShareFile Enterprise Security White Paper 7

 White Paper

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

citrix.com/sharefle | White Paper | ShareFile Enterprise Security White Paper 8

 Securing File Upload/Download Requests
When a user uploads or downloads a file, ShareFiles architecture prevents forged requests by
using hash-based message authentication codes or HMACs.

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.

citrix.com/sharefle | White Paper | ShareFile Enterprise Security White Paper 9

 Security

Encryption in transit
Client files are protected in transit between the web application and storage tier using TLS with
no less than 128 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 providers 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 ShareFiles 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
worlds 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.

citrix.com/sharefle | White Paper | ShareFile Enterprise Security White Paper 10

 White Paper

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 organizations 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 organizations 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

citrix.com/sharefle | White Paper | ShareFile Enterprise Security White Paper 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-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 (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.

citrix.com/sharefle | White Paper | ShareFile Enterprise Security White Paper 12

 Security
Trust and encryption: on-premise StorageZone

Shared Zone Secret

Key created when
StorageZone is created. Storage Encryption Encryption Key is en-
Key created when crypted by Passphrase
StorageZone Controller 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 TLS 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 Sites 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 customers ShareFile account and on the
StorageZones Controller server stored encrypted in the registry.
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.

citrix.com/sharefle | White Paper | ShareFile Enterprise Security White Paper 13

 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 TLS 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 TLS protocols as above.

If a NetScaler is used in the architecture, the TLS 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 TLS. 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 customer- managed
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 TLS.

citrix.com/sharefle | White Paper | ShareFile Enterprise Security White Paper 14

 White Paper

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 Controllers proxy service with a request for
metadata.

citrix.com/sharefle | White Paper | ShareFile Enterprise Security White Paper 15

 White Paper

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 StorageZones 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

citrix.com/sharefle | White Paper | ShareFile Enterprise Security White Paper 16

 White Paper

Customer-managed StorageZones
with Windows Azure storage
Overview
The Microsoft Azure customer-managed solution (Figure 8) integrates ShareFile with Microsoft
Azures 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

citrix.com/sharefle | White Paper | ShareFile Enterprise Security White Paper 17

 Securing file upload/download requests
Overview
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.

citrix.com/sharefle | White Paper | ShareFile Enterprise Security White Paper 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 customers 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.

citrix.com/sharefle | White Paper | ShareFile Enterprise Security White Paper 19

 White Paper

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 customer-
managed implementation of a StorageZones Controller server, network shares and
SharePoint document libraries.

Figure 11. StorageZone Connectors component architecture

citrix.com/sharefle | White Paper | ShareFile Enterprise Security White Paper 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

citrix.com/sharefle | White Paper | ShareFile Enterprise Security White Paper 21

 White Paper

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 Forcepoint

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

Figure 13. Graphical overview of DLP integration solution.

citrix.com/sharefle | White Paper | ShareFile Enterprise Security White Paper 22

 Weve 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.

citrix.com/sharefle | White Paper | ShareFile Enterprise Security White Paper 23

 White Paper

Information Rights Management

Overview
When you are working with an application or service like ShareFile, control over access to
content can be easily maintained as long as the end-users interact and share content with
other users of the same service. This works great as long as the interaction is contained
within the application.

However, in the world where mobility is becoming the norm and users have the ability to
download applications, the control can disappear once the document leaves the application.

With the ever growing mobilization of the workforce, data has a tendency to develop legs.
Once the recipient has downloaded a file, the authentication and authorization controls no
longer apply. They are free to re-distribute that file to anyone using any means (USB drive,
email attachment, Personal cloud account, etc.).
A file you intended to only be seen by one recipient, suddenly has found its way to an
unauthorized user that you never intended.

How can I ensure that content I sent to a recipient is only viewed by that person? This is
where Information Rights Management or IRM can help. Its a follow-me security model that
allows for security protections to continue being enforced no matter where the data goes.

Securing documents likely means different things to different people. If you are familiar with
the on-premises world, its defined as securing at the share level and then maybe the file and
folder level. But in the mobile-first, cloud enabled world this means something different and
you need a security model that allows defined security settings to follow documents.

citrix.com/sharefle | White Paper | ShareFile Enterprise Security White Paper 24

 White Paper

Information Rights Management applies file-level encryption, authentication and

authorization controls to downloaded documents. You set some very simple and
straightforward sharing permissions to a file you intend to send to a collaborator.
Controls like:

Whether the document can only be viewed

Whether it can view and printed
Or whether it can be view, printed or edited

Those permission controls will be packaged with the file. This results in securing the file no
matter where it lives or ends up. The great thing is, at any point in time if you no longer desire
the recipients to have access, you can revoke the share and thus removing their access.

What can I control using Rights Management for ShareFile?

The following are the actions that you can control when using Rights Management for
ShareFile:
Limit access to browser view only
Require Authentication to open downloaded file
Revoke access to downloaded file
Apply watermark
Block printing and the clipboard
Expire access after a set number of days
Amount of time offline file access is allowed
Allow Editing
Screen sharing or screenshots

How it works
To explain how this works we will use an example where Bob is working on a project with
Alice an outside consultant. Bob needs to collaborate with Alice and needs to share a
document with her regarding the project. Bob wants to control how the file is used after he
shares it with Alice,

citrix.com/sharefle | White Paper | ShareFile Enterprise Security White Paper 25

 White Paper

1. Bob selects a file he has stored in ShareFile that he wants to share with Alice. This file is
stored in a StorageZone that is associated with an on-premises storagezone controller.
2. Bob defines Rights Management Security settings to be applied to the file he intends
to share. The ShareFile StorageZone Controller will obtain an encryption key from the
Rights Management policy server located within the ShareFile control plane and wraps
the file using this encryption key.
3. Bob sends the file to Alice, who subsequently downloads the file. Alice then attempts
to open the downloaded file. At this time she will need to authenticate to ShareFile and
the Rights Management policy server will be consulted for the allowed permissions. This
check is done in real time and the permissions are also enforced in real time.

Up to this point all of the interaction between Bob, Alice and the file have been with
ShareFile. During her interaction with the file Alice decides that she needs to consult
Charlie for guidance. However, Charlie is not authorized to view content associated with the
project. Alice isnt aware of this and shares the file with Charlie anyway.

4. Alice constructs an email to Charlie and attaches her downloaded copy of file to the
email.
5. Charlies receives the email and attempts to open the attached file. At this point the file
open will initiate a process where ShareFile and the Rights Management Policy server
will be consulted. This is similar to the earlier process where Alices permissions are
checked in real time.
6. The open request will be disallowed as Charlie will not be able to authenticate to
ShareFile. This will result in the Rights Management policy server being unable to
validate the actions attempted on the file. Even though Charlie has a physical copy of
the file, it is still wrapped with the initial security settings defined by Bob back in step
#2. Just because a copy of the file was downloaded by Alice the Rights Management
setting were not removed.

To provide this level of security, Citrix ShareFile has partnered with Seclore to provide
this follow-me security model. Securing files within ShareFile is easy and is extended to
sharing via the web UI, Outlook Plug-in, iOS and Android devices and the ShareFile Desktop.
In order to utilize Rights Management with a share, the sender will select from a list of
straightforward sharing options:

citrix.com/sharefle | White Paper | ShareFile Enterprise Security White Paper 26

 White Paper

View and Print This allows a recipient to only be capable of printing or viewing the
file. They will be unable to edit the file
View, Print and Edit This will allow essentially full control on a shared file.
View (online and offline) Recipient will be allowed view only. No printing or editing
abilities will be provided to the recipient.

Should a user download the file and later go offline, they will still be allowed access to
the file for a period of time while offline. As the above example shows, there is a direct
interaction between the recipient and the ShareFile environment. In order to allow a user
to download a file and work offline, that interaction has to be suspended in order to allow
continued access. This is important when somebody is in an environment where they do
not have internet access available to them (travelling, in a customer site with no available
access, etc).

When a file is downloaded and offline use is allowed, the user will be granted access offline
for a defined period of time. A timer will begin. As long as the user is offline and the period
of offline access is not exceeded, they will be allowed to work with the file. Once the offline
access period expires, the user will be required to restore online access in order to continue
working with the file. This is done to ensure there is a periodic check available to validate
the recipients access rights and usage ability has not been revoked or changed.

What is required for this to work

In order for a recipient to work with protected files there is additional software they will
need to install. This software is available for Mac OS, iOS / Android and Windows operating
systems. When a recipient receives a rights management protected share and they do not
have the software installed, the recipient is presented with a page that provides further
guidance on how to interact with the file.

Should a recipient not download the necessary software and attempt to open the file, they
will be presented with an additional message advising them hey have received a protected
document. The document will display a user friendly unencrypted message that references
similar details as above.

citrix.com/sharefle | White Paper | ShareFile Enterprise Security White Paper 27

 White Paper

This level of protection is available across a wide range of file types. Information Rights
Management settings can be applied to traditional office types, PDF, TXT/RTF files, Open
Office, image files (bmp, jpg, png, tif), AutoCAD / AutoDesk and Visio.

As of the last published date of this document the solution is supported for the on-premises
deployment of ShareFile storagezone data. In addition to the above the environment will
need a ShareFile Storagezone controller deployed and configured to store customer data
on-premises. You will need to ensure that your storagezone controller is running the latest
revision of the ShareFile storagezone controller software.

There is no additional software to deploy beyond those requirements. The Information

Rights Management server software and infrastructure itself is deployed and managed by
Citrix within the ShareFile application tier or control plane.

citrix.com/sharefle | White Paper | ShareFile Enterprise Security White Paper 28

 White Paper

Customer Managed Encryption Keys

Overview
ShareFile provides customers with flexibility in storing content through our StorageZones
architecture. Customers can choose between hosting content entirely in the cloud in a
ShareFile Managed zone, on-premises via our StorageZone Controller software, in your own
cloud storage container and finally a hybrid approach that uses a combination of the previous
options. Some primary factors considered when deciding which option to use are: performance
(proximity to primary user base), compliance / regulatory or geographic specific needs.

Beyond the above, security becomes the next concern for customers how is my data secured
if I select to store my data entirely in the ShareFile cloud? Data stored within the ShareFile
cloud is always encrypted utilizing encryption keys generated by the ShareFile service. Even
with this level of assurance by Citrix, this still can present some hesitancy by customers to
adopt the service due to a lack of provider trust. Customers desire the ability to control the
encryption of content in the cloud using their own encryption keys and subsequently be
capable of revoking access should they have the need to for security reasons. This is where
customer managed encryption keys offered by ShareFile can assist.

What are Customer Managed Encryption Keys

ShareFile Customer Managed Encryption Keys is a feature leveraging Amazons Key
Management Solution to assist customers in providing the data security control they desire.
Customer files will still reside within the ShareFile application, but the generation (and control)
of the encryption keys will occur within Amazon KMS.

What is Amazon KMS? Its a service offered by Amazon utilizing two kinds of keys to secure
content: Master and Data Keys. An Amazon KMS customer will have a single master key that
can be used to encrypt or decrypt up to 4KB of data but more importantly its used to generate
/ protect data keys. As a feature available to ShareFile the KMS master key is only used to
generate and protect data keys. The actual encryption of data will occur within ShareFile.

A master key is stored securely within a customers Amazon KMS account and never exported
outside of that environment. In contrast, a data key can be generated and exported outside of
the KMS environment.

So how does Amazon KMS work when generating data keys and securing data:

1. A request is initiated to encrypt data using a Customers Amazon KMS account by a service
or application
2. The Request is sent to Amazon KMS
3. Within an Amazon KMS Customer account their Master Key will generate (2) data keys: one
plain text and one encrypted copy of the plain text key
4. Both of these keys are returned to the requesting service.
5. The requesting service will utilize the plain text key to encrypt the data to be stored in the
service
6. Once the data has been encrypted by the service, the plain text copy of the key is
discarded.
7. The service will write the encrypted file to disk and alongside it the encrypted copy of the
data key used to secure the file. The encrypted copy of the data key will be used later for
decrypting the stored data.

citrix.com/sharefle | White Paper | ShareFile Enterprise Security White Paper 29

 White Paper

The benefit of this solution is that it simplifies the management of encrypted data and at the
same time it allows for a level of trust to be established between the cloud service provider
and the customer. After the data has been stored within the service in encrypted format,
should someone gain access to the data they would be unable to open the file without having
the ability to decrypt the secured file. This moves the control over encryption closer to the
customer. If a file encrypted with KMS need to be accessed the following steps are followed to
decrypt the file:

1. A client or application makes a request to access a KMS encrypted file to the service storing
the file.
2. The service initiates a conversation with Amazon KMS, sending the encrypted data key
associated with the saved file over to be decrypted
3. Amazon KMS will utilize the associated customer master key to decrypt the encrypted data key
4. Amazon KMS will return the plaintext copy to the requesting service that initiated the
conversation
5. The service will use the plaintext key to decrypt the file requested by the client /
application
6. The service will discard the plaintext copy of the key and return the now unencrypted file to
the requesting client or application

So how does all of this fit into the context of ShareFile. Below are brief walk-throughs of
uploading and downloading files from ShareFile when using Customer Managed Encryption
Keys.

Upload a file to ShareFile

1. Customer initiates a request to upload a file to their ShareFile cloud StorageZone

2. ShareFile initiates a conversation with Amazon KMS associated with the Customers KMS
Account. Requesting a data key that can be used to encrypt the file
3. Amazon KMS generates the plain text data key and the encrypted copy, returning both to
ShareFile
4. ShareFile encrypts the customers file using the plain text key and discards the plaintext key.
The encrypted copy of the key and the encrypted customer file are then stored in ShareFile

citrix.com/sharefle | White Paper | ShareFile Enterprise Security White Paper 30

 White Paper

Download a file from ShareFile

1. Client initiates a download of a file secured via a KMS encryption key. ShareFile retrieves the
encrypted file and the associated secure data key (ie: encrypted data key).
2. ShareFile initiates a conversation with Amazon KMS and sends the encrypted data key to
KMS
3. Amazon KMS locates the master key associated with the KMS customer, decrypts the data
key and returns the plain text data key back to ShareFile
4. ShareFile now decrypts the file using the plain text copy of the key. The plain text copy of the
key is discarded and the requested file is returned to the client initiating the download request.

As you can see the reliance on securing data is heavily dependent on the customers Amazon
KMS Master key. At any point the customer can revoke ShareFiles access to their Master Key.
Once access has been revoked it would it would make all the data secured using data keys tied to
that master key inaccessible.

Currently this security feature is supported for cloud storage zones only. If an environment is
using theon-premises storage model having deployed a Citrix ShareFile StorageZone controller,
the control over encryption keys is already within the customers domain. When using on-
premises storagezone a customer has option of using encryption through StorageZone controller
itself or take advantage of the encryption services available on the destination CIFS repository
where the on-premises data is stored. Once the feature is enabled and configured for a ShareFile
account only new data will use the customer managed keys. Data stored prior to enabling the
feature will use ShareFile encryption keys for storage. The feature is designed to work in parallel
to existing ShareFile encrypted files.

citrix.com/sharefle | White Paper | ShareFile Enterprise Security White Paper 31

 White Paper

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 TLS from StorageZone Controllers
Ensure requests for files on SharePoint or network drives are authenticated before
passing through the DMZ

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 TLS protocol on port 443 to establish this connection.
To support this connectivity, you must open port 443 on the firewall and install a public TLS
certificate on the NetScaler appliances (if they terminate the user connection).

citrix.com/sharefle | White Paper | ShareFile Enterprise Security White Paper 32

 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 TLS, 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).

citrix.com/sharefle | White Paper | ShareFile Enterprise Security White Paper 33

 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.

citrix.com/sharefle | White Paper | ShareFile Enterprise Security White Paper 34

 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 TLS 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)

citrix.com/sharefle | White Paper | ShareFile Enterprise Security White Paper 35

 White Paper

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

citrix.com/sharefle | White Paper | ShareFile Enterprise Security White Paper 36

 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

citrix.com/sharefle | White Paper | ShareFile Enterprise Security White Paper 37

 White Paper

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-users 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 users
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.

citrix.com/sharefle | White Paper | ShareFile Enterprise Security White Paper 38

 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 users subdomain from account discovery
appcp the web application control plane (ShareFile.com etc)
apicp the API control plane for the user
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

citrix.com/sharefle | White Paper | ShareFile Enterprise Security White Paper 39

 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 users ShareFile API control plane, i.e. sharefile.com for the above
example.
appcp The users ShareFile account control plane, i.e. for the above example.
subdomain The users 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.

citrix.com/sharefle | White Paper | ShareFile Enterprise Security White Paper 40

 Youll 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 users credentials.
Anytime a user opens the ShareFile application the application checks to see whether the
access_token has expired. If it hasnt 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 hasnt 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 doesnt know this is happening and authentication
happens instantaneously bringing the user to his or her files and folders.

Parameter definitions

Field Description

access_token Short lived token presented to ShareFile to obtain an authid.

refresh_token Long lived token used to acquire new access token.

token_type Token type typically will be bearer.

apicp API Control Plane for the user.

appcp Control Plane for the web app (sharefile.com, securevdr.com, etc.).

subdomain Subdomain for the users account.

expires_in Lifetime of the access_token in seconds.

citrix.com/sharefle | White Paper | ShareFile Enterprise Security White Paper 41

 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,
auto- advancing 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

citrix.com/sharefle | White Paper | ShareFile Enterprise Security White Paper 42

 If your account doesnt 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

citrix.com/sharefle | White Paper | ShareFile Enterprise Security White Paper 43

 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 TLS (Transport
Layer Secuity) 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 APIs to link into
Enterprise Content Management systems.

citrix.com/sharefle | White Paper | ShareFile Enterprise Security White Paper 44

 White Paper

Conclusion
This paper details how ShareFile is secure by design, and enumerates the complete set of
security and compliance controls available to ShareFile Enterprise 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 customers own datacenter; or in both. This flexibility helps IT address the
organizations 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
customer- managed 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 organizations 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 industrys most
comprehensive feature set. By making follow-me data a seamless and intuitive part of
every users day, ShareFile enables optimal productivity for todays highly mobile, anywhere,
any device workforce.

citrix.com/sharefle | White Paper | ShareFile Enterprise Security White Paper 45

 White Paper

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
Allow or deny download of documents to the mobile device for offline viewing or editing.
Disable offline access
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
Require password
authenticate each time the app is launched.
Documents downloaded to the device are automatically removed after a fixed amount of
File self-destruct
time.
Device-specific file encryption within the ShareFile app - requires passcode lock setting to
Encrypt files at rest
be enabled.

Passcode 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
Device lock
administrator unlocks the device.

Jail-break detection Prevent use of the ShareFile app if the device is jail-broken.

Removes all ShareFile account information and data from the device. Status of the wipe
operation is communicated to the control plane.
Wipe
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
Wipe status and auditing complete. After wipe completion, any actions performed by the client after the wipe was
requested are reported to the administrator.
Disable external
Prevents opening of downloaded ShareFile documents in third- party apps (open in).
applications

Secure Sharing Require recipients of shared files and folders to log on prior to download.

Session inactivity timeout Automatically log out inactive users after a configured amount of time.

citrix.com/sharefle | White Paper | ShareFile Enterprise Security White Paper 46

Security Control Description iOS Android

Provided by XenMobile
Allow/disallow cut and copy of data from the ShareFile app to be pasted into
Constrain clipboard cut and copy
other applications.

Constrain clipboard paste Allow/disallow data from other applications to be pasted into the ShareFile app.

Allow/disallow only approved (MDX wrapped) external applications to be used

Constrain external applications
for opening ShareFile documents (open in).
Filter the URL schemes that are passed into the ShareFile application for
Constrain URL Schemes
handling.
Prevent ShareFile from using the device camera to upload photos or videos
Block camera
taken with the device.
Prevent ShareFile from using the device microphone to capture and upload
Block microphone
videos taken with the device.

Block screen capture Prevent a user-initiated screen capture operation while ShareFile is running.

Block email compose Prevent ShareFile from sending e-mails via the native mail application.

Enable or disable printing of ShareFile documents from the mobile device to a

Disable print
network printer.
Require Citrix Worx Home The user must have a valid session with Worx Home in order to use ShareFile. A

Authentication separate password can be required for offline access.

Define maximum offline period Defines the maximum period ShareFile can run offline without a network logon.

Challenge an authenticated user to re-authenticate at regular intervals in order

Require regular re-authentication
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
Wipe data after security event 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 appno
Online access only
offline access.
Require the device be connected to one of a white list of named Wi-Fi
Constrain Wi-Fi networks
networks in order to launch the app.
Require the device to be connected to an internal company network
Require internal network
(determined by connectivity to an internal beacon).
Require the ShareFile app to route all of its traffic through the company
Constrain network access
network.
Defines the grace period during which users may use ShareFile after the
App update grace period 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.

Require device encryption 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
Require device pattern screen lock
configured.

citrix.com/sharefle | White Paper | ShareFile Enterprise Security White Paper 47

Security Control Description iOS Android

Provided by XenMobile MDM

Allow or deny use of the ShareFile app on the device. If the application is
Application white list/ black list
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
Application provisioning
XenMobile
Remove the ShareFile application by administrator action or if the device is un-
Application removal
enrolled from XenMobile by the end user.

Figure 28. Mobile Device Security table

citrix.com/sharefle | White Paper | ShareFile Enterprise Security White Paper 48

 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
Administrators have the option of configuring password policies including password history, expiration, and
Password policy 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
Custom SMTP (mail) settings e-mails sent through ShareFile will be routed through the clients mail sever, instead of ShareFile mail servers.
Administrators may optionally configure the connection to support TLS.
ShareFile supports SAML 2.0 for single sign-on and integrates with most SAML-compatible identity
SAML 2.0 enabled single sign-on 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
Multi-factor authentication 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
File retention
preferences and policies.
Users can view different versions of a file uploaded with the same name to ensure that no changes are lost
File versioning
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
Terms and conditions
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 TLS (FTPS connection over port 990), an inherently more secure protocol than FTP. Users can connect
FTP/FTPS
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.

OAuth 2.0 support 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 lockout 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
Customized folder permissions
specific folders. These permissions may be set to propagate to subfolders or apply only to specific subfolders.

Require login 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
Account activity reporting
permissions. Reports can be run on demand or emailed daily, weekly or monthly.

citrix.com/sharefle | White Paper | ShareFile Enterprise Security White Paper 49

Features Description

Email notifications Users can choose to have customized notifications sent in real time or in a consolidated daily message.

Email domain whitelist/

ShareFile administrators can restrict file sharing based on email
blacklist
Access log retention Detailed file-access logs are retained for at least one year.

File Archiving
When enabled, ShareFiles archiving feature supports your compliance with federal regulations regarding data
Archiving for financial services 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

ShareFile provides multiple technical safeguards to support client compliance obligations under HIPAA.
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
Audit controls
and access to files and folders, to track disclosures.
Unique users and ShareFile provides administrators the capability to assign individual user accounts based on unique email
authentication 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
Encryption
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
Integrity controls
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
Physical safeguards 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 Citrixs behalf.
To maintain compliance with the HIPAA Security Rule, Citrix engages an independent third party to perform
Testing and evaluation
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.

Enterprise Sales
North America | 800-424-8749
Worldwide | +1 408-790-8000

Locations
Corporate Headquarters | 851 Cypress Creek Road Fort Lauderdale, FL 33309 United States
Silicon Valley | 4988 Great America Parkway Santa Clara, CA 95054 United States

Copyright 2016 Inc. All rights reserved. Citrix, the Citrix logo, and other marks appearing herein are property of
Citrix Systems, Inc. and/or one or more of its subsidiaries, and may be registered with the U.S. Patent and Trademark
Office and in other countries. All other marks are the property of their respective owner/s.

citrix.com/sharefle | White Paper | ShareFile Enterprise Security White Paper 50