Product security is of paramount importance at Datadog. Datadog uses a software development lifecycle in line with general Agile principles. When security effort is applied throughout the Agile release cycle, security oriented software defects are able to be discovered and addressed more rapidly than in longer release cycle development methodologies. Software patches are released as part of our continuous integration process.
Datadog performs continuous integration. In this way we are able to respond rapidly to both functional and security issues. 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. In this way Datadog is able to achieve extremely short mean time to resolution for security vulnerabilities and functional issues alike. Datadog is continuously improving our DevOps practice in an iterative fashion.Physical Security
The Datadog production infrastructure is hosted in Amazon Web Services (AWS). Physical and environmental security related controls for Datadog production servers, which includes buildings, locks or keys used on doors are managed by AWS. “Physical access is strictly controlled both at the perimeter and at building ingress points by professional security staff. Authorized staff must pass two-factor authentication a minimum of two times to access data center floors.”Corporate Security
Datadog recognizes the diminishing utility of perimeter as concerns modern network security. Once that perimeter is breached services reliant on network security guarantees quickly fall. As such Datadog leverages internal services that require transport level security for network access and individually authenticate users, commonly by way of a central identity provider and leveraging two factor authentication wherever possible.
All data transmitted between Datadog and Datadog 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 does not “fail open.” Datadog is careful not to log sensitive values in clear text.Protection of Data at Rest
Customer data at Datadog is encrypted at rest using a secure symmetric cipher. AES with a key length of 256 bits is used for both storage of live service data and Datadog service backups.Customer Data Storage Location
Datadog service data currently resides in the United States of America and primarily in the state of Virginia.Data Retention
For Service users, we will retain your personally identifying information (PII) for as long as your account is active or as needed to provide you access and use rights with respect to the Service (which may include a limited 90-day tail period to, for example, allow for an orderly wind-down). Generally speaking, “full resolution” electronic information transmitted or received by you in relation to your use of the Service (which may include PII) will be retained for a rolling 15-month look-back period, after which such information may be aggregated on the basis of a one-minute resolution for the duration of the service period and any tail period. In addition, we may retain and use your information as necessary to comply with our legal obligations, resolve disputes and enforce our agreements.Gathering of Personally Identifiable Information (PII)
Certain visitors to the Website and Service choose to interact with Datadog in ways that require Datadog to gather personally identifiable information (PII). The amount and type of information that Datadog gathers depends on the nature of the interaction. For example, when signing up for a trial of the Service, we may ask a user to provide the user’s name and the name of the user’s company, as well as an email address and telephone number where we may contact the user and/or another representative of the user’s company. Each user is also expected to provide a username and password that, along with other information, we use to create and administer accounts. In each case, Datadog collects such information only insofar as is necessary or appropriate to fulfill the purpose of the visitor’s interaction with Datadog.
A limited number of Datadog employees have access to customer data via access controlled and logged mechanisms. Employees engaged in customer support access a support application similar in structure to the Datadog end user web application that allows them to access customer data. Access to this system requires authenticating to our central identity provider and using two factor authentication. Access to the customer support portal is strictly logged. Technical operations employees have access to the raw service data storage. This access requires using a management VPN, authentication via public key and two factor authentication. Access to the staging and production management infrastructure is strictly logged. All other employees are prohibited from accessing customer data.
While use of Datadog does not strictly require use of the Datadog agent, the vast majority of users will leverage the agent. The agent is composed of 4 major components, all written in Python. Each component runs in a separate process. The collector (agent.py) is responsible for gathering system and application metrics from the machine. The forwarder (ddagent.py) is responsible for buffering and communicating with Datadog HQ over SSL. Our dogstatsd (dogstatsd.py)is responsible for aggregating local metrics sent from your code. Our supervisord is responsible for keeping all previous processes up and running. The agent does not require root privileges in most circumstances.
Our supervisord runs a master process and forks all subprocesses as the user dd-agent. The agent configuration resides at /etc/dd-agent/datadog.conf and /etc/dd-agent/conf.d. All configuration must be readable by dd-agent. The recommended permissions are 0600 since configuration files contain your API key and other credentials needed to access metrics (e.g. mysql, postgresql metrics).
The Collector is where all standard metrics are gathered, every 15 seconds. It will temporarily execute standard utilities such as vmstat, mpstat, iostat, varnishstat and parsing their results returned over process pipes. The collector connects to applications' monitoring interfaces over tcp and http and parsing their results (e.g. Apache, MySQL, some JMX-based applications). It reads open files to extract metrics (e.g. nagios, jenkins). The collector also supports the execution of python-based, user-provided checks, stored in /opt/datadog-agent/agent/checks.d. User-provided checks must inherit from the AgentCheck abstract class defined in checks/init.py.
The forwarder listens over HTTP for incoming requests to buffer and forward over HTTPS to Datadog HQ. Buffering allows for network splits to not affect metric reporting. Metrics will be buffered in memory until a limit in size or number of outstanding requests to send is reached. Afterwards the oldest metrics will be discarded to keep the forwarder's memory footprint manageable. Dogstatsd is a python implementation of etsy's statsD metric aggregation daemon. It is used to receive and roll up arbitrary metrics over UDP, thus allowing custom code to be instrumented without adding latency to the mix. In the Agent, JMXFetch-based checks (e.g. cassandra, kafka, etc) and go-metro both send the metrics they collect through Dogstatsd.Agent Authentication
All requests to Datadog's API must be authenticated. Requests that write data require reporting access and require an API key. Requests that read data require full access and also require an application key. These keys act as a bearer tokens allowing access to Datadog service functionality.Agent Capabilities
The capabilities of the agent are dependent upon the integrations configured. Without any additional configuration an agent running as a non-privileged user will be able to gather some (platform dependent) operating system level information. Additional capabilities are dependent upon further integration configuration and can be reviewed in the related documentation.
Servers in the production environment receive software patches released through our continuous integration process. Patches that can impact end users will be applied as soon as possible but may necessitate end user notification and scheduling a service window.Single Sign On (SSO)
End users may log in to Datadog using an Identity Provider, leveraging Datadog’s Security Assertion Markup Language (SAML) support or via the “Sign-in with Google” Open ID service. These services will authenticate an individual’s identity and may provide the option to share certain personally identifying information with us such as your name and email address to pre-populate our sign up form. Datadog’s SAML support allow organizations to control authentication to Datadog and enforce specific password policies, account recovery strategies and multi-factor authentication technologies.Security Awareness Training
All Datadog personnel undergo an annual security awareness training that weaves security into technical and non-technical roles; all employees are encouraged to participate in helping secure our customer data and company assets. Security training materials are developed for individual roles to ensure employees are equipped to handle the specific security oriented challenges of their roles.
If you believe you’ve discovered a bug in Datadog’s security, please get in touch at firstname.lastname@example.org and we will get back to you within 24 hours, and usually earlier. You will find our PGP key 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.