Confidentiality Notice
The ideas and designs set forth in this document are the property of DryvIQ and may not be disseminated, distributed, or otherwise conveyed to third persons without the express written permission of DryvIQ.

Company and Solution Information

DryvIQ, Inc.
PO Box 546 A2 Ann Arbor, MI 48106

Hosting Information

Customer data is never stored, accessed, or processed on DryvIQ, Inc. owned or managed servers.

Contact

For more information regarding DryvIQ Security, please contact:
Steve Woodward
Chief Innovation Officer
swoodward@dryviq.com

Solution Architecture

The DryvIQ platform is built upon a pluggable, content–streaming architecture that enables highly–automated file/data transfer and synchronization capabilities for up to billions of files. File bytes stream in from one connection endpoint (defined by the administrator), across a customer owned and operated network and/or cloud service, then streamed out to a second connection endpoint. Content can also flow bidirectionally across two endpoints, rather than solely from an "origin" to a "destination".

DryvIQ is a "security–neutral" model, fully utilizing your existing infrastructure and security schema. Content and data bytes only exist in DryvIQ memory in chunks, which are immediately streamed from one endpoint (through DryvIQ), and out to another endpoint. Both incoming and outgoing bytes are transferred using the most secure protocol available for each connector. For example, DryvIQ will use SSL or TLS encryption along with OAuth, token–based authorization for most cloud service connectors.

Database Server

DryvIQ  utilizes a built–in PostgreSQL database as part of its standard installation process. You can also use pre–installed Microsoft SQL Server. DryvIQ requires network connectivity with the database to function properly, in all cases.

DryvIQ Remote Agents

DryvIQ remote agents are designed to serve two distinct use cases deployed on:

• Local, on–premises server(s)
• Remote server(s), such as a remote office NFS ‐ eliminating the need for a VPN solution

DryvIQ Connectors

DryvIQ's Platform Connectors provide storage endpoint integration. Each storage connector has been carefully developed to implement all of the available security features via its native API. The connectors themselves can be deployed to execute in the context of the primary DryvIQ Server or in the context of one or more DryvIQ Remote Sites depending on the deployment model selected.

DryvIQ stores connection information such as the authenticated security token, URL, UNC, and in some cases such as network file–shares, the user name and password are encrypted within the database. DryvIQ Connectors utilize all the default ports based upon the platform's required communication protocol.

General Security Concepts

DryvIQ's deployment model is incredibly flexible (identified within this section). Regardless of the deployment model, the following concepts always apply to DryvIQ :

• DryvIQ is a security–neutral model; it has no impact on existing security
• DryvIQ rides "on top" of existing endpoint security models
• DryvIQ operates behind a customer–owned/managed firewall
• DryvIQ  is fully managed by and under the control of the customer administrator
• DryvIQ never saves or caches files "at rest" during transfer processing
• DryvIQ is client–downloadable software
• Data to be included in within a transfer process is 100% controlled by customer administrators and users
• DryvIQ does not control, edit, move, or modify existing connection identities
• DryvIQ acts as an external user to storage systems, interacting with them via their public API's or via the credentials utilized for Network‐based ( NFS/SAN/NAS) file systems.

DryvIQ Access

The connection identity and credentials used during the "Add New Connection" process directly controls how and what content DryvIQ can access and the related data it can update. DryvIQ wholly respects the permissions set with any platform and will receive Access Denied or other related permissions errors if requested to perform operations where underlying credentials do not have access.

As such, the connection identity determines what content/data DryvIQ can access on each underlying platform and has several implications:

• DryvIQ cannot access folders, drives, or any content areas where its connection identity does not have access
• DryvIQ is most efficiently configured when the connection identity has appropriate permissions to all desired synchronization locations
• Content ownership information (i.e. created–by, last–modified–by, etc.) may be tagged with the connection identity when DryvIQ operates on content if the platform does not explicitly support preservation 
• Optionally, DryvIQ can be configured on a "user–by–user" basis to solve content ownership issues, however this will require additional administrator maintenance and a significant number of connections

On–Premises to Cloud (Multiple On–Premises Data centers and Cloud Centralized)

In on–premises to cloud scenarios, content/data is transferred across multiple on–premises data centers (local and/or remote site storage) to one or more cloud storage providers. With multiple customer data center locations, the ideal deployment configuration is to install the DryvIQ Service Platform (DryvIQ Manager Admin Console) in a cloud–based IaaS virtual machine infrastructure; in conjunction with DryvIQ Remote Site services (DryvIQ Remote Sites) on one or more virtual machines within each customer data center.

This deployment model provides a single, central point of configuration and reporting in the cloud while also facilitating fully functional "distributed" transfer engine services (DryvIQ Remote Sites) within each customer data center without the need to deploy a VPN or WAN.

On–Premises to Cloud Security Implications

In on–premises to cloud scenarios, the customer deploys a cloud–hosted virtual machine infrastructure for the centralized DryvIQ Service Platform (DryvIQ Manager Admin Console) and manages all intra–server service account level access, as well as user–level access to all cloud–based virtual machine resources. The customer also deploys and maintains full intra–server service account level access, as well as user–level access to all on–premises DryvIQ Remote Site virtual machine resources.

Transfer processing occurs within the DryvIQ Remote Sites on–premises. However, centralized control and reporting is processed within the IaaS environment at the DryvIQ Admin console. For initial deployment and configuration of the DryvIQ Service Platform (DryvIQ Manager Admin Console), remote site access must be granted.

A single configurable TCP port must be forwarded from the public IP address to the DryvIQ Manager server. This will allow Remote Site servers on–premises to communicate with the DryvIQ Manager Console in the IaaS cloud infrastructure. Typically, this port would be secured through the implementation of an SSL certificate. DryvIQ Support can provide guidance for enabling and configuring SSL on this port.

Related: Enable and Configure SSL

Desktop to Cloud (Cloud or WAN Centralized)

In desktop to cloud scenarios, content/data is being transferred from individual user desktops to one or more cloud storage providers. The deployment configuration installs the DryvIQ Service Platform (DryvIQ Manager Admin Console) within a centralized environment; on‐premises or on cloud IaaS resources. Centralized control and reporting occurs within the DryvIQ Manager Admin Console, which may be on‐premises or within an IaaS environment.

When the DryvIQ Manager Console is deployed on cloud IaaS resources, a single configurable TCP port must be forwarded from the public IP address to the DryvIQ Manager server. Typically, this port would be secured through the implementation of an SSL certificate. DryvIQ Support can provide guidance for enabling and configuring SSL on this port.

Related: Enable and Configure SSL

Desktop to Cloud Security Implications

Centralized control and reporting occurs within the DryvIQ Manager Admin Console on–premises data center or within the IaaS environment. For initial deployment and configuration of the DryvIQ Manager Service, remote desktop access must be granted.

When the DryvIQ Manager Service is deployed within an IaaS infrastructure, a single configurable TCP port must be forwarded from the public IP address to the DryvIQ Manager server. Typically, this port would be secured through the implementation of an SSL certificate. DryvIQ Support can provide guidance for enabling and configuring SSL on this port.

Related: Enable and Configure SSL

DryvIQ User Model / Role Based Access

The DryvIQ Management application is a fully–responsive web–based interface (PC, tablet, mobile) that allows for configuration and management of various aspects of the DryvIQ Platform console that can be controlled and accessed by various roles or "personas". DryvIQ is highly configurable in that specific user rights can be granted or revoked at a granular level.

The following roles are examples of the logical entities that might comprise the DryvIQ access personas:

IT Administrator (Alice)

During initial installation, DryvIQ facilitates the creation of a single administrative user. This user retains all rights and permissions to administer the DryvIQ Platform. This pre–configured user is an "Alice" type user.

The Alice persona could have the following responsibilities and appropriate access:

• Has primary, day–to–day responsibility for configuring and managing DryvIQ has full access to DryvIQ Manager
• Creates Jobs and Job Profiles
• Authorize and coordinates distribution of DryvIQ Agents / Remote Sites 
• Alice may also be an "Eddie" on her personal laptop

Sub Administrator (Sam)

When Alice the IT Administrator wants to delegate responsibility to one or more additional administrators, they will often be modeled after the "Sam" persona:

• Has occasional responsibility for configuring and managing some aspects of DryvIQ  
• Has restricted access to DryvIQ Manager
• May create jobs, profiles, or utilize other functionality unlocked for his profile by Alice
• May monitor, diagnose, or report on jobs unlocked for his profile by Alice
• Sam may also be an Eddie on his personal laptop

Power User (Paula )

The "Paula" power user persona will have more rights than a typical end user:

• User "in the field," on a laptop, desktop, supported device
• Accesses some level of functionality unlocked by Alice or Sam
• Provides necessary input to convert Job Profiles to Jobs so they can be run on their local machine
• May monitor, create, or modify connections or connection information (ex. creates connections)
• May monitor, create, or modify jobs
• Relies on Alice or Sam to be DryvIQ expert

End User (Eddie)

The "Eddie" persona is the typical end user:

• User "in the field," on a laptop or a Desktop PC user
• Cannot access DryvIQ Manager
• Provides necessary credential input to convert Job Profiles to Jobs so they can be run on their local machine
• Relies on Alice to be DryvIQ expert

Automated User (Otto)

The "Otto" persona is a special persona that may be implemented to execute jobs automatically. This persona shares similarities with "Eddie" however, "Otto" corresponds to a person who will not be prompted to enter credentials before a job can be executed.

• May be utilized to automatically execute remote site jobs
• An alternate method of implementing cluster processing
• Eddie that is not prompted for credentials such as:
  • IT driven operations (shared folders)
  • Legal Hold
  • Backup

Developer (Doug)

The "Doug" persona is also a specialized persona that is uniquely authorized to perform functions related to the consumption of the DryvIQ API's.

• Consumes DryvIQ API's to automate operations or create custom solutions
• DryvIQ  Gateway scenarios 
• Job Automation
• Reports/data extracts
• Creates DryvIQ custom connectors using .Net code
• Uses development tools such as Postman, PowerShell, etc.
• Relies on Alice or Sam to be DryvIQ expert

 
Each personas are just examples; designed to provide the various options of logical separation and delegation of user rights which can be implemented and enforced within DryvIQ.

Additional Security Concepts

Single Sign–On (SSO)
Most SSO solutions are properly managed by DryvIQ Connectors out–of–the–box. However, a best–practice is that end–to–end authentication and connectivity should be tested to ensure the specific environment configuration is supported.

Multi–Factor Authentication (MFA)

In most cases, MFA still results in the creation of an authentication token, which is all that DryvIQ connectors need to communicate with any given endpoint. It is this token that is stored in the DryvIQ database to be used in future operations. The ability to establish authentication with MFA enabled solutions will often "just work" in most cases. However, there are scenarios where certain MFA solutions do not properly allow for token refresh. This can cause credentials to have to be manually re‐authenticated periodically. Depending upon the size an scope of the synchronization or migration project, this may impact project duration unless another authentication mechanism is identified.

Service Accounts

Public/private key–based security accounts are often the best approach to ensure secure authentication with a given endpoint, without having to resort to credentials that include passwords or MFA credentials that time–out. DryvIQ supports Service Account–based authentication in most cases where it is also supported by the specific endpoint platform.

Session Management

Session management generally varies by platform. The most common session paradigm relates to EFSS systems and related platforms secured by OAuth/OAuth2. The access tokens and refresh tokens related to these platforms sessions are stored encrypted in the DryvIQ database for fault/restart tolerance. DryvIQ can impersonate a user's login to a connected platform by the administrator for platforms with API's that provide that capability. This is performed automatically, and only in response to affirmative administrator configuration. An example would be a user‐drive mapping scenario attempting to move a file server folder for the user 'John Doe' named 'jdoe' to his cloud account under the email 'jdoe@company.com' using a connection for an admin account. The admin account would (on behalf of' 'jdoe') transfer the data to the cloud service while preserving jdoe's file ownership.

In general, the management of any platform connection session is part of the API specification for the platform and DryvIQ automatically manages the resulting session as guided by the platform. Any sensitive data that must be stored within the DryvIQ database would be encrypted via native database encryption. When DryvIQ is required to store credentials, it uses the same encryption method noted above. The encrypted/hashed credentials are stored within DryvIQ's tracking database. Typically, DryvIQ uses proxy accounts, service accounts, tokens, integrated authentication, impersonation and other tactics whenever possible to avoid requiring/storing credentials.

Communication

DryvIQ may communicate with the database via Shared Memory, TCP/IP or Named Pipes. Depending on the connection endpoint platforms involved, HTTPS to cloud storage Providers, NFS, CIFS, or SMB to local storage are the protocols typically implemented. Remote Sites, the DryvIQ Command Line Interface (CLI), and any other API–driven custom integration communicates with the DryvIQ Management service via a single, customizable TCP port (9090 by default). DryvIQ can be configured to enable SSL on this port.

Related: Enable and Configure SSL

DryvIQ Manager and the "My Computer" Connection

When DryvIQ is initially installed, a default connection to "My Computer" on the DryvIQ Manager Console server is created. This connection is necessary for several scenarios including local file share transfer jobs as well as facilitating permission map import during general job creation. However, DryvIQ does expose the file and folder information for this connection through the DryvIQ Manager. In some scenarios, this could facilitate knowledge of other attack surfaces. If necessary, and if the "My Computer" connection is not needed, we strongly recommend that this connection is disabled.

Document Level Interaction

DryvIQ synchronizes files at the binary level from platform to platform, usually in chunks. It does not modify or analyze the internal contents of files in any way. DryvIQ does analyze metadata and properties of the content to make rules–based decisions, track content etc., however it does not validate file content beyond integrity check sums. A few common examples are comparing SHA1 codes for files between platforms for equality, or checking the SHA1 result after upload to ensure upload integrity.
DryvIQ performs validations on data input such as paths, regular expressions, typical data entry boundary checks, and others when appropriate in the configuration application.

Audit Trails and Logging

All DryvIQ audit information is stored within the database and is surfaced as configurable reports within the DryvIQ Reporting Console. DryvIQ also has robust diagnostic tools that can be configured for various levels of logging, including a verbose control setting. These logs are for application diagnostics and do not include password information. However, it is possible that URLs, URIs, and even user information (such as user name and/or login ID) may be present within the diagnostic logs as some platforms embed this information in returned exceptions which are subsequently added to the log. Note that DryvIQ Support does not have access to these logs unless explicitly shared with them by the customer's DryvIQ system administrator.

Application and Data Integrity

Data Integrity

File transfers are verified via checksum, byte counts, and stream lengths. They are compared for consistency, and audit records of all DryvIQ transfer operations are logged in our database and are available via report.

Application Functional and Performance Tests

DryvIQ  core load tests are utilized to profile baseline engine performance between versions. DryvIQ also performs difference testing across APIs when moving to a new version of a platform API. DryvIQ has a quarterly release cadence and in general, for every other release cycle, load test results are refreshed. Additionally, each DryvIQ software build has automated tests that validate lower level unit performance at every code check–in and/or modification.

Protecting Customer Data

DryvIQ does not host customer data. DryvIQ streams data from the origin platform(s) through the server where DryvIQ is installed, directly to the destination platform(s).

Secure Development Practices

This section identifies the security implemented around DryvIQ software development practices and related environments.

Audit

DryvIQ has an internal SDLC. Our product development teams generally follow a scrum–related agile development process on two–week sprints with quarterly release cycles.

Development Process

Each code check–in is reviewed by a peer process and checklist to explore potential security vulnerabilities. Specific security facing modules of code would get specific code reviews and in–depth review from the Chief Architect. DryvIQ Engineering executes regular scans of JavaScript and .NET dependencies to ensure it is not using libraries with known vulnerabilities.

Each release where new functionality is added, DryvIQ will perform an internal security review with gates before release.

Prior to general availability (GA) for major software releases, DryvIQ engages with a 3^rd party security consulting company to test for security vulnerability which includes:

• • Review and analysis token management and security
  • Review and analysis credential management and security
  • Penetration testing

Data Integrity

Both automated and manual mechanisms exist to ensure data integrity. Our suite of automated tests, with our preference to write tests for all significant units of code, allow us to note certain classes of code immediately after any application change . Our manual test scripts have several steps and test cases around verifying data and data transfer tests of known outcome to validate the end–to–end process. As a typical function of use our audit trails, DryvIQ verifies data vs. the reality and audit in formation on origin and destination platforms.

Source Code Security

DryvIQ  leverages Github–based repositories for source–code. Only team members within active development on a product line have access to select repositories. Team members work on feature branches of code, which is merged back into the master branch after clearing the process (code reviews, etc.) by the build master.

Environment

DryvIQ software has various internal test and deployment environments however as a best–practice for any software deployment, we recommend a test or stage environment for maximum risk avoidance. This is more critical for long–term hybrid or synchronization solutions and less so for migration environments, which are often tested as a Proof–of–Concept (POC) then utilized with the current version through the file migration process.

Data Security and Risk Management

This section pertains to the data classification, data security controls, and risk management.

Data Encryption

All DryvIQ software is installed on premises with customer encryption key control. Encryption details are outlined below in Encryption Key Management under the Security Practices section.

Environment Segregation

All DryvIQ software is installed on–premises or within a customer–managed cloud service (IaaS), under the full control of the customer.

Asset Management

All DryvIQ software is installed on–premises, under full control of the customer. DryvIQ will be used for asset management by the customer, but does not manage any customer data offsite. DryvIQ's primary electronic assets are data stored within cloud repositories as well as server, and desktop hardware. Hardware is tracked via asset tag, assigned to employees, and returned upon request.

Unauthorized transfer of Confidential Information

All DryvIQ software is installed on–premises or within a customer–managed cloud service (IaaS), under the full control of the customer. DryvIQ resources do not access or interact with client data. The control of confidential information is accomplished by NDAs, access controls, role–based access to systems, and auditing of access logs. In general, as a software–focused team and company, the developers work on code and associated design documents as electronic artifacts .

Device Security Controls

DryvIQ employee devices require passwords and have similar control polices set up by our internal IT and driven by our Active Directory in Microsoft Office 365. Devices require a pin/password to connect to our Office 365 email or repository. Our internal testing servers (ECM systems, SharePoint servers, etc.) are protected behind a firewall and Cisco VPN appliance. Servers and systems are generally set up to automatic Windows updates to remain current. Each employee device is pre-configured with virus and malware scanning tools.

Security Threat Protection

All DryvIQ software is installed on‐premises or within a customer–managed cloud service (IaaS), under the full control of the customer. Our internal IT maintains our SaaS/cloud infrastructure and our collocated data center for testing servers. Normal automated monitoring of our internal servers sends email alerts for triggers like DOS attacks, intrusion detection , CPU spikes , IP monitoring and related issues. The servers are monitored with a combination of automated notifications via software and manual checking of servers, logs, and access logs. DryvIQ typically rely on Windows, Active Directory, and associated policies to secure our environments as well as assuring that the latest patches and known exploits are addressed. Typically, our infrastructure review is performed in cadence with release cycles, approximately every 3‐6 months.

Automated software tests exercise the entire software stack continuously, identifying any problems for intervention on an ongoing basis.

Security Practices

This section pertains to the security controls in place for network and web security, patch management, and security monitoring.

Network Security Devices

Our internal IT staff maintains our SaaS/cloud infrastructure and our collocated data center for testing servers. Normal automated monitoring of our internal servers sends email alerts for triggers like DOS attacks, intrusion detection, CPU spikes, IP monitoring and related issues. The servers are monitored with a combination of automated notifications via software and manual checking of servers, logs, and access logs. DryvIQ typically rely on Windows, Active Directory, and associated policies to secure our environment as well as up–to–date patches and known exploits. Typically, this infrastructure review is performed in cadence with release cycles, approximately every 3–6 months.

Automated software tests exercise the entire software stack continuously, identifying any problems for intervention on an ongoing basis.

Malware Protection

Antivirus/malware software is standard on employee issued devices. Procedures as outlined above.

Data Transmission

DryvIQ rides on top of platform/environment security. Where appropriate, DryvIQ will utilize transport layer security like HTTPS. Internally, DryvIQ resources use HTTPS to most resources, and a private VPN to our testing infrastructure.

Encryption Key Management

Database columns containing sensitive information are encrypted, for example, columns that store connection authentication parameters. The encryption method varies depending on the database platform. In all cases, the encrypted values are salted with the row ID.

SQL Server: encryption keys with certificates, native to SQL Server

PostgreSQL: native pgcrypto module using a password from the DryvIQ configuration

Public Site Defacement

Public web hosting company provides this to our corporate .com site as a service.

Security Alerts Subscriptions

DryvIQ uses general industry announcements and news from major vendors that DryvIQ partners with including Box, Dropbox, Google, Microsoft, and others.

Patch Management

As previously mentioned, most of our internal infrastructure is cloud–hosted. For servers that maintain our test platforms, Windows Update is often used to simulate best–practice recommendations for customers to desire remain up–to–date without impacting to their existing deployment. Our internal IT team monitors our test infrastructure and periodically schedules downtime for maintenance and upgrades.

Security Breach Monitoring

DryvIQ does not retain customer data that could be compromised during a breach.

PO Box 546 A2  | Ann  Arbor, MI  48106 | 888.550.3721  | dryviq.com