Data Privacy And Security

For any questions or concerns please contact [email protected].

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

Company Policies

Arc 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 Arc require the use of multi-factor authentication and follows strict requirements for session management and logging.

Pure Software - No Intermediary

The Arc application does not interact with our servers in any way for normal data transfer. Our application establishes 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 application does 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 application 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 application DOES 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 application. 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

Arc does communicate usage statistics to Google Analytics for license compliance. This does not affect the functioning of the application in any way.

If for instance, the request is blocked, the application will continue to function. If we detect the usage of our application exceeds the licensed servers and cores, the application will continue to function.

Sometimes customers inadvertently install the application 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 Arc Servers

Some Arc connectors that rely on OAuth authentication may use oauth.arc.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 Arc servers.

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

EU Data Protection

Arc is 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 [email protected]. 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

Under the HIPAA Security Rule, Arc complies with HIPAA requirements for Protected Health Information (PHI) and will sign a Business Associate Agreement (BAA) with customers who are subject to HIPAA mandates (typically, HIPAA covered entities). Arc 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). Arc provides software that runs on the customer's environment but does not communicate with any Arc servers, which means that PHI traversing is never seen by Arc. All transmissions undertaken by Arc software are encrypted using industry best practices (at present, TLS 1.2+). The customer is responsible for their own assessment of how they use Arc software to honor HIPAA.