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 various monitoring and observability needs for our customers through scalability inherited from our CSP. We adhere to our service level agreements (SLAs) of 99.8% availability. Additional information about our SLA can be found within our Master Services Agreement.

Personnel Security

At Datadog, we encourage all employees to participate in helping 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 that weaves security into technical and non-technical roles. Our security training materials are based on individual roles to ensure employees have the tools to handle the specific security-oriented challenges they encounter in their jobs.

Product Security

Product security is of paramount importance at Datadog. We incorporate security into the design of our products from the beginning 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 Platform.

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 cloud service provider (CSP) environments. These CSPs manage physical and environmental security controls for Datadog production servers, including buildings, locks, and door keys.

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

LEARN MORE

Access Management

Datadog grants access to assets and sensitive information on a need-to-know basis based on role. Access is controlled based on the principle of least privilege, meaning users have only the level of access required to perform their job functions. Additionally, we enforce multi-factor authentication, which includes strong passwords and a secondary factor. 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.

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

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 Customers can use to scrub PII and sensitive data sent to the Datadog application.

All data transmitted between Datadog and our users is protected using 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 maintains distinct data centers in the United States and the EU. Customer-submitted service data is not transferred or shared between distinct data centers. Datadog utilizes encryption at various points to protect customer data and Datadog secrets, including encryption at rest (e.g., AES-256), asymmetric encryption (e.g., PGP) for system backups, KMS-based protections for the protection of secrets (passwords, access tokens, API keys, etc.), and GPG encryption. Additional information about EU data transfers please visit EEA Transfers FAQ

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.

LEARN MORE

Certifications, Attestations and Frameworks

Datadog maintains active SOC 2 Type II compliance, provides HIPAA-compliant log management and security monitoring, has achieved certification to the International Organization for Standardization’s information security standard 27001, as well as compliance with standards 27017 and 27018, and documents security controls on the Cloud Security Alliance’s (CSA) Security, Trust & Assurance Registry (STAR).

Datadog also maintains a FedRAMP Moderate Impact for products in the US1-FED site and FedRAMP Low-Impact Authority to Operate (ATO) for the Infrastructure Metrics product in the US1 site.

Laws and Regulations

Datadog’s solution is compliant with various data protection laws and regulations applicable to the services we provide.

GDPR

Datadog is compliant with the General Data Protection Regulation (GDPR) which went into effect on May 25, 2018. Datadog has worked to enhance its products, processes, and procedures to meet its obligations as a data processor. For more information about our position on the GDPR, please visit https://www.datadoghq.com/gdpr/.

CCPA

Datadog is a monitoring service for infrastructure and applications and while we do not intend to transfer, process, use, or store personal information, Datadog can provide our CCPA Addendum so that our customers can fulfill their obligations under the CCPA in the event that personal data is in scope. For more information about how the CCPA impacts Datadog and its customers, please visit https://www.datadoghq.com/ccpa/.

Vendor Management

Datadog leverages a number of third party applications and services in support of the delivery of our products to our customers. The Datadog Security Team recognizes that the company’s information assets and vendor dependencies are critical to our continuing operations and delivery of services. As such, Datadog’s Security and Privacy teams have established a vendor management program that sets forth the requirements to be established and agreed upon when Datadog engages with third parties or external vendors. These engagements are designed to assess the technical, physical, and administrative controls in place and to ensure they are commensurate with the expectations of Datadog and its customers. 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.

Safety Center example

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), 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 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 immediately receive an email notification with instructions on how to secure your account.

How it works

Datadog proactively monitors your API and application keys as follows:

  1. We provide GitHub with regex patterns that could potentially match a Datadog API or application key.
  2. GitHub runs those regex patterns against commits and pushes to public repositories. If a match is found, GitHub automatically sends it to Datadog’s validation endpoint to be verified.
  3. If our validation endpoint determines that the candidate token is valid and active, we immediately take the following actions:
    • Automatically notify you via email
    • Display a banner in the Datadog UI on the API Keys and Application Keys pages within your Organization Settings

What is the impact of a leaked key?

A leaked API or application key can have the following consequences:

  • API keys are used to submit data to Datadog. Exposure may result in unintended data being submitted to your organization.
  • Application keys have the same permissions and capabilities as the key creator. Exposure results in a high risk of unauthorized access.

How will I be notified?

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

Leaked key email

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.

Additionally, Datadog displays the following warning banner under Organization Settings to alert you to the active leaked key:

Leaked key banner

What should I do if I receive a leaked key notification?

If you receive a leaked key notification, follow these steps 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 restricts the use of unsafe passwords. Passwords that appear in third-party, non-Datadog data breaches are considered unsafe.

What restrictions apply?

If you try to register a new account using an unsafe password or change your current password to one, Datadog will display the following warning:

Unsafe password warning

Existing accounts with unsafe passwords will be prompted to reset their password before logging in.

How does Datadog determine that a password is unsafe?

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:

Unsafe link warning

Datadog protects you from harmful links by following this protocol:

  1. Datadog monitors for clicks on external, user-defined links found in a dashboard, notebook, monitor, log, etc.
  2. When a user clicks an external link, the link is rewritten on the fly and checked against our URL Protection Endpoint to determine if it is potentially harmful.
  3. If the link is determined as potentially harmful, Datadog displays a warning with the option to either proceed to the destination or go back.

Disclosure

If you believe you’ve discovered a bug in Datadog’s security, please get in touch at security@datadoghq.com and we will 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 address it.

PGP DOWNLOAD

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.