What certifications does Druva adhere to?
What certifications does Druva adhere to?
Druva adheres to the same certifications as inSync.
As an IaaS provider, Amazon regularly updates their compliance certifications for all the standard certifications (See http://aws.amazon.com/compliance/ ). As a SaaS provider, Druva holds a number of certifications for controlling and managing our applications. This includes a SOC2 audit, certifications around Safe Harbor, and a review of our security and privacy controls for handling HIPAA-compliant protected health information (PHI).
You can get a copy of the certificates from the below link:
To know the certifications that inSync adheres to, contact Support.
What security standards do you employ?
What security standards do you employ?
To ensure that your data stays protected, Druva uses the 256-bit AES at rest and TLS in transit. Additionally, Druva also employs data scrambling techniques to obscure access to your data.
Does Druva support Safe Harbor?
Does Druva support Safe Harbor?
Yes, Druva does. While configuring a server, the server data can be scoped to administrative groups within a specific geography (known as “availability zone” within Amazon Web Services). This can provide complete assurance that data never leaves a specific geography.
Why does my vulnerability scanner report SSL/TLS certificate findings for internal Druva agent processes?
Why does my vulnerability scanner report SSL/TLS certificate findings for internal Druva agent processes?
Vulnerability scanners may occasionally flag local SSL/TLS certificate warnings for the Druva agent. These findings relate exclusively to internal Inter-Process Communication (IPC) between localized software components running on the host machine.
Communication between the Druva agent and the Druva Cloud remains fully secure, using industry-standard, publicly signed CA certificates to protect data in transit.
Below are the details on the common scanner findings for internal agent communication and why they do not pose a security risk:
1. SSL Certificate - Invalid Maximum Validity Date Detected
Why it occurs: The local certificate created for internal agent processes is set with an extended validity period (10 years).
Explanation: This certificate is used strictly for communication between internal background processes running locally on the same host machine. It is never exposed to external network traffic or public connections. The extended validity period is intentional to prevent service disruptions and unnecessary maintenance overhead caused by frequent local certificate rotations.
2. SSL Certificate - Signature Verification Failed Vulnerability
Why it occurs: The scanner cannot verify the certificate signature against a commercial third-party Certificate Authority (CA).
Explanation: The certificate used for internal IPC is self-signed and generated dynamically on the local machine during the Druva agent installation. Third-party CAs are intended for public-facing domain verification over open networks. For local host processes communicating internally, dynamically generated self-signed certificates provide robust, encrypted communication without external network dependencies.
3. SSL Certificate - Subject Common Name Does Not Match Server FQDN
Why it occurs: The scanner detects a mismatch between the host machine's actual FQDN and the Common Name (CN) listed on the certificate.
Explanation: The local certificate generated by the Druva agent is intentionally configured with localhost and 127.0.0.1 as its Common Name/Subject Alternative Names. It is intentionally not bound to the host machine's specific FQDN because internal agent processes interact strictly via the local loopback interface (127.0.0.1). Scanner reports flagging an FQDN mismatch are expected behavior and do not compromise system security.