Security | Datadog

Security & Compliance

We care about security. If you have any questions, or
encounter any issues, please contact us.

At Datadog, we manage security in a hybrid model, with a layered approach that reflects our Software as a Service (SaaS) framework. We have created a shared responsibility model that outlines the controls we’ve inherited from our cloud service providers (CSPs) and the security responsibility Datadog has to our customers.

Platform and Network Security

The foundation of security at Datadog is infrastructure security. Datadog relies on our Virtual Private Cloud (VPC) to logically isolate our internal networks. We maintain configured security groups to control and restrict network access through configured inbound and outbound rules.

Availability

We build highly available products that service our customers through scalability inherited from our CSPs and multiple availability zones (AZ). We adhere to our service level agreement (SLA), which can be found within our Master Services Agreement under Availability.

Personnel Security

At Datadog, all employees have a responsibility to help secure our customer data and company assets. Where applicable by law, Datadog performs background screenings on personnel prior to joining the organization. All Datadog personnel undergo regular security and privacy awareness training, during onboarding and annually thereafter. Our security training materials are based on individual roles to ensure employees have the tools to handle the specific security-oriented challenges they may encounter in their jobs.

Product Security

Product security is of paramount importance at Datadog. We incorporate security into all stages of our software development lifecycle. We develop products in line with general Agile methodologies and integrate security throughout the Agile release cycle. This allows us to discover vulnerabilities sooner, so we can address them more rapidly than we would if we used longer release cycles. Well-defined change management policies and procedures determine when and how changes occur. This philosophy is central to DevOps security and the development methodologies that have driven Datadog adoption. You can find more information through our Trust Center.

Patch Management

Datadog releases software patches as part of our continuous integration process. We strive to ensure patches that can impact end users are applied as soon as possible and within our established service level agreements (SLA) by sending end user notifications and scheduling service windows.

Physical Security

As a SaaS provider, Datadog production infrastructure is hosted in industry standard cloud service provider (CSP) environments. These CSPs manage the physical and environmental security controls for Datadog production servers, including buildings, locks, and door keys.

Physical security practices at Datadog offices include enforcement of badge access to enter the building,Datadog floors, and secure work areas. All visitors are pre-registered and required to provide identification to receive a visitor’s badge and must be escorted by a Datadog employee at all times. All entries and exits are monitored by security cameras.

Access Management

Datadog grants access on a need-to-know basis based on role. Access is controlled based on the principle of least privilege. Additionally, we require multi-factor authentication. Datadog third parties do not have direct access to production systems.

Datadog has implemented multiple layers of access controls for administrative roles and privileges. As with regular user accounts, we also enforce the principles of least privilege and need-to-know for access to customer data for administrative accounts. User access reviews are regularly performed for appropriateness.

We monitor and log access to all production environments for security purposes. Additionally, access is audited and baselined to meet our security and compliance requirements

Protection of Customer Data

All data submitted to the Datadog service by authorized users is considered confidential. This data is protected in transit across public networks and encrypted at rest. Customer data is not authorized to exit the Datadog production service environment except in limited circumstances such as to support a customer request. Datadog also provides a Sensitive Data Scanner that Customers can use to sanitize data sent to the Datadog application.

All data transmitted between Datadog and our users is protected using up to date Transport Layer Security (TLS) and HTTP Strict Transport Security (HSTS). If encrypted communication is interrupted, the Datadog application is inaccessible.

Datadog has implemented controls to ensure the integrity and confidentiality of administrative credentials and access mechanisms, and we enforce full-disk encryption and unique credentials for workstations

Data Transfers

Datadog leverages third-party data centers globally. For more information on how Datadog ensures compliance with international privacy laws when transferring data across borders, visit https://www.datadoghq.com/privacy/.

Monitoring

Datadog monitors critical infrastructure for security-related events by using a custom implementation of open source and commercial technologies. Activity data such as API calls and operating system-level calls are logged to a central point, where the information is passed through a series of custom rules designed to identify malicious or unapproved behavior. The results of these rules are fed into an orchestration platform that triggers automated actions, which may include directly alerting the security team or prompting additional authentication requirements.

Certifications, Attestations and Frameworks

Datadog maintains a comprehensive set of security and compliance certifications to meet industry standards and regulatory requirements. We are compliant with SOC 2 Type 2, ISO 27001, ISO 27017, ISO 27018, ISO 27701, PCI DSS, HIPAA, and TISAX frameworks. We publish our security controls in the Cloud Security Alliance’s (CSA) Security, Trust & Assurance Registry (STAR). These accreditations help our customers meet their own compliance obligations while leveraging Datadog’s platform with confidence.

For customers operating in regulated U.S. government environments, Datadog maintains a FedRAMP Moderate Authority to Operate (ATO) in US1-Fed and supports ITAR compliance obligations. The FedRAMP High ATO and GovRAMP are both designated “In Process”. These attestations enable federal, state, and local agencies and contractors to securely adopt Datadog’s services while meeting strict security and regulatory requirements. Our continued investment in compliance ensures that we remain aligned with the evolving needs of government and highly regulated customers.

Laws and Regulations

Datadog is committed to maintaining compliance with applicable laws and regulations governing security, privacy, and data protection. Our compliance programs are designed to meet evolving legal requirements and industry standards. To learn more about our approach to privacy, visit https://www.datadoghq.com/privacy/.

Vendor Management

Datadog leverages a number of third party applications and services (“subprocessors”) in support of the delivery of our products to our customers. As such, Datadog maintains a vendor management program that sets forth the requirements to be established and agreed upon when Datadog engages with third parties or external vendors. For a complete list of Datadog’s subprocessors, please visit https://www.datadoghq.com/legal/subprocessors/.

Safety and Security

To ensure a safe and trustworthy user experience, Datadog builds security into our platform through safe design and proactive monitoring.

Safety Center

Datadog provides security alerts and best practices dynamically in your organization in the Safety Center. Admins of an organization can visit this page to review recommendations and take action on high priority security warnings and alerts. The Safety Center can be found in Organization Settings.

Security Contacts

You can set primary and secondary email addresses to receive security notifications for your Datadog organization, keeping you informed about important account safety events and notifying the appropriate individuals promptly. Upon detecting security issues, like publicly exposed Datadog keys needing rotation (see Token Safety below), your assigned Security Contact will be notified. This proactive approach lets you quickly address and mitigate potential security risks. To configure Security Contacts for your organization you must have organization management permissions.

Token Safety

Datadog proactively and automatically detects if one of your private Datadog API or application keys is accidentally uploaded to a public GitHub repository. If a valid key is detected, you’ll receive an email notification with instructions on how to secure your account.

In the event of a confirmed key leak, Datadog immediately sends an email notification to the key creator/owner.

By default, the key creator/owner receives the email notification. If the key creator is no longer part of your organization, then the administrators of your organization will be notified.

To notify additional contacts about a key leak, configure Security Contacts.

If you receive a leaked key notification, follow these the remediation steps outlined in the email as soon as possible to ensure the security of your account.

Password Safety

To protect your account from brute force and password-spraying attacks, Datadog automatically restricts the use of unsafe passwords, e.g. passwords that appear in third-party, non-Datadog data breaches.

Datadog maintains a database of hashed passwords obtained from third-party, non-Datadog data breaches. When you sign in, a hashed version of your password is checked against this list. This check follows guidelines established by the National Institute of Standards and Technology.

Content Safety

Many of Datadog’s products combine live data, rich Markdown text, and collaborative features that enable users to create meaningful content. As a proactive safety measure, Datadog protects you against potentially harmful links that may be found in user-generated content.

If you try to access a potentially unsafe link, Datadog displays a warning that shows the full URL and gives you the option of continuing to that site or returning to the previous page.

Disclosure

If you believe you’ve have potentially discovered a security bug in Datadog’s products bug in Datadog’s security, please get in touch at security@datadoghq.com and we will promptly get back to you within 24 hours, and usually earlier. Our PGP key is available for download in case you need to encrypt communications with us. We request that you not publicly disclose the issue until we have had a chance to review and address it as necessary.

For inquiries related to known vulnerabilities on our products, please use the vulnerability inquiry request on a datadog product on the Datadog support site - https://help.datadoghq.com/hc/en-us/requests/new.

Program

Datadog hosts its private Bug Bounty Program with HackerOne. If you’re an independent security expert or researcher and believe you’ve discovered a security-related issue on our platform, we appreciate you disclosing the issue to us responsibly and thank you for your time and expertise.

If you are eligible and want to participate in our private Bug Bounty Program, send us an email at bugbounty@datadoghq.com with your HackerOne username or the email you want an invitation for.

You will report the vulnerability directly in the HackerOne platform and all communication after submission will be conducted there. Before submitting an issue, please read our guidelines and scope of the program.

Eligibility

Datadog employees or contractors—current or former—are not eligible to participate in this program. Please read the complete eligibility requirements before joining the program.

Scope

The scope of the Bug Bounty Program includes Datadog’s products, services, and systems. Vulnerabilities found in vendor systems fall outside of this policy’s scope and should be reported directly to the vendor via their own disclosure programs.

The following describes what systems and types of research are covered under this program. Always be careful to verify whose assets you are testing while performing research.

Rules of Engagement

The following is intended to give security researchers clear guidelines for conducting vulnerability discovery activities to limit the potential for company and/or customer data to be at risk:

  • Do add a prefix Bugbounty- to your Datadog org name.
  • Do report a potential security issue immediately.
  • Do NOT attack other users. If you are testing the ability to access another customer’s data, do not iterate randomly. Create another test account or ask for assistance at bugbounty@datadoghq.com.
  • Do NOT attempt Denial of Service (DoS) attacks. If you notice performance interruption or degradation, immediately suspend all testing.
  • Do NOT perform any phishing, spamming, social engineering, or other form of fraud on our employees or customers.
  • Do NOT perform any physical attacks against Datadog’s property (including workstations, office spaces, servers, or networks) or otherwise try to discover risk beyond digital means against Datadog.
  • Do NOT exploit a security issue you discover for any reason other than to validate your finding.
  • Do NOT deface any Datadog-associated publicly available resource for a proof of concept (PoC) which explicitly states the vulnerability. For example, for a subdomain takeover PoC, upload a file with hello world in it.

Out-of-Scope Vulnerabilities

Any of the following (or related) activities will be automatically considered out of scope for the Bug Bounty Program:

Application Vulnerabilities:

  • Clickjacking or UI redressing (on pages with no sensitive actions)
  • Content injection or “HTML injection” unless you can clearly show risk (other than social engineering)
  • Cross-Site Request Forgery (CSRF) on features which are available to anonymous users
  • Low-impact CSRF including, but not limited to, login, logout, and unauthenticated
  • User session duration
  • Username/email enumeration
  • Same-site scripting and Self-XSS
  • Self-exploitation (i.e., password reset links or cookie reuse)
  • Missing flags on non-essential session cookies
  • Missing security-related HTTP headers which do not lead directly to a vulnerability
  • Open redirects on ad/analytics subdomains
  • Presence of autocomplete attribute on web forms
  • Reflected File Download (RFD) attacks

Data Exposure:

  • Banner or version disclosure of server or software
  • Information disclosure that has no practical use for exploitation
  • Descriptive/verbose/unique error pages (without proof of exploitability)
  • Default configuration files which do not disclose sensitive information

Denial of Service:

  • Denial of Service (DoS) attacks
  • Distributed Denial of Service (DDoS) attacks

End of Life (EoL)/ Outdated Software:

  • Any Datadog-developed software that is EoL or no longer supported
  • Client side bugs which do not affect (and/or are exploitable on) the latest version of modern browsers
  • Outdated dependencies without a working PoC

Physical Security:

  • Man-in-the-middle (MITM) attacks or those requiring physical access to the victim’s device
  • Physical or social engineering attacks

Security Best Practices:

  • Missing SSL/TLS best practices
  • Mixed content warnings
  • Missing best practices in Content Security Policy
  • Missing email security best practices (such as incomplete or missing SPF/DKIM/ DMARC) without a proof of exploitability
  • Issues related to networking protocols or industry standards

Miscellaneous:

  • Bugs Datadog is already aware of (or ones previously submitted by another researcher)
  • Pivoting, scanning, exploiting, or exfiltrating data from internal Datadog systems
  • Pervasive issues or vulnerabilities such as heartbleed, meltdown, spectre, or others without a PoC
  • Results of automated tools or scanners without a PoC
  • Theoretical subdomain takeover claims with no supporting evidence
  • Using unreported vulnerabilities to find other bugs
  • Vulnerabilities in community-contributed API and DogStatsD client libraries
  • Public zero-day vulnerabilities that have had an official patch for less than one month will be awarded on a case by case basis.

Disclosure Policy

The Disclosure Policy of Datadog’s private Bug Bounty Program follows HackerOne’s private program disclosure policy and Datadog’s HackerOne program policy. This program is subject to strict confidentiality requirements. You will need consent from Datadog for any disclosure outside of the program. Prior to accepting an invitation to Datadog’s private program, you should carefully review the program policies and the non-disclosure agreements required for participation.