Data Privacy And Security

For any questions or concerns please contact security@cdata.com.

• Company Policies
• Pure Software - No Intermediary
• Transport Protocol and Authentication Mechanism
• Diagnostics and Troubleshooting
• Licensing Telemetry
• OAuth Flow Using CData Servers
• EU Data Protection
• Responsible Vulnerability Disclosure
• HIPAA Compliance

Company Policies

CData maintains an internal security policy that all employees are required to follow. Our policies are reviewed at least annually and include coverage for the following topics:

• Secure Application Development - All developers undergo official training programs in order to verify compliance with our secure coding requirements. This policy defines programs such as peer review, static code analysis, adherence to industry-standard best practices such as the Microsoft Secure Coding guidelines and consideration of the OWASP top 10 vulnerabilities.
• Physical Security - Access to the offices is restricted and access to production systems is further restricted to authorized personnel only.
• Remote Access - Remote access to systems maintained by CData Software require the use of multi-factor authentication and follows strict requirements for session management and logging.

Pure Software - No Intermediary

CData drivers are pure software libraries that do not interact with our servers in any way for normal data transfer. Our drivers establish a direct connection with the data source server and the data traffic flows over your network, the Internet, and the data source service in a secure manner as established by APIs and SLAs of the data source.

Our drivers do support configuring firewalls, proxies, etc. and we expect our customers to use these settings in a manner that is consistent with their security policies.

Transport Protocol and Authentication Mechanism

Most services offer multiple forms of authentication and support multiple protocols for communication. When these protocols are negotiated (TLS cipher suite negotiation) we always pick the most secure protocol allowed by the service. For example, we support TLS 1.1 and TLS 1.2 to ensure that the connection is made using the most recent, secure protocol, with the most secure cipher suite possible.

We usually support all forms of authentication to allow our drivers to be used more broadly. It is up to our customers to pick the preferred authentication mechanism that is in line with their security policy.

Diagnostics and Troubleshooting

Our drivers DO NOT send any diagnostics information to our servers. In some situations, it is useful to see the exchange between the client and the service to troubleshoot the functioning of the driver. We do this through configurable log files.

• Log files can be written at configurable levels of verbosity to only include the amount of information that is needed.
• Our support team ALWAYS asks permission to see the log file if that is necessary. And we ALWAYS ask for the least amount of information.
• We strive to ensure that no sensitive information, such as credentials or security tokens, is written by the drivers to log files.
• The log files are in plain text and the customer is encouraged to look at these files before passing these on. Most organizations have internal checks on what data is sent and we comply with those policies.

Licensing Telemetry

CData drivers do communicate the usage (version, anonymized machine ID, core count, and license key) to our servers for license compliance. Core components of telemetry include:

• NodeID
• Serial number / SKU
• Driver Version information
• Java Runtime Information (i.e. JRE version) or .NET version as applicable
• Number of queries & affected rows
• CPU Core count

This does not affect the functioning of the drivers in any way. If for instance, the request is blocked, the driver will continue to function. If we detect the usage of our drivers exceeds the licensed servers and cores, the drivers will continue standard operation.

Sometimes customers inadvertently install drivers on more servers than licensed. Licensing telemetry is simply used as a means to start a conversation to bring usage in compliance (i.e uninstalling unnecessary deployments or licensing additional machines).

OAuth Flow Using CData Servers

Some CData drivers that rely on OAuth authentication may use oauth.cdata.com to relay the OAuth Token back to the driver. Relayed tokens are encrypted via TLS, encoded so they are never visible as plaintext, and requests are never logged or stored on CData servers.

This is also fully configurable by the customer and only applies when using the embedded CData OAuth Application credentials.

EU Data Protection

CData drivers are installed on the customer's premises and network environment and as such we do not have any access to customer data. Therefore, we are not considered a 'processor' under the European Union's General Data Protection Regulation (EU/2016/679) (GDPR) or like privacy laws.

Responsible Vulnerability Disclosure

In spite of all our efforts, there might be a vulnerability unknown to us. If you find a security vulnerability, please report it to security@cdata.com. Please detail the following:

• The name and the version of the product.
• A detailed description of the steps required to reproduce the vulnerability.

We will respond to your report within 2 business days of receipt and will attempt to keep you regularly informed of our progress toward resolving the vulnerability.

HIPAA Compliance

CDATA is not a covered entity under HIPAA rules, and therefore cannot be "HIPAA compliant", since HIPAA itself applies to covered entities (that is, those entities that are subject to regulation by the HHS). CDATA provides software that runs on customer's environment but does not communicate with any CDATA servers, which means that PHI traversing is never seen by CDATA. All transmissions undertaken by CDATA software are encrypted using industry best practices (at present, TLS 1.2+). The customer is responsible for their own assessment in how they use CDATA software to honor HIPAA.