Skip to main content
All CollectionsConnectionsProvider
Datadog Connection
Datadog Connection

This article describes how to set up a Datadog Connection for the first time within Drata.

Updated over a month ago


​Note: Go to the end of this article if you would like to learn more about troubleshooting Datadog connection.

Initial Connection Instructions

Note: Many of the Datadog tests require an AWS <> Datadog integration. If you have not set this up in your Datadog account, you can follow Datadog's AWS guide.

First, log into your company's Datadog with administrator permissions (you will need these permissions to set up a service account).


Create an API Key:

  1. Navigate to https://app.datadoghq.com/organization-settings/api-keys

  2. Click the "+ New Key" button.

  3. Drata suggests adding the following name for the Key:

    Drata API Key

  4. Click the "Create Key" button.

  5. Click the "Copy Key" button. The Key's value will not be shown again.

  6. Paste the Key into API Key input. Do not copy or paste the Key ID.

Create a Role:

  1. Navigate to https://app.datadoghq.com/organization-settings/roles

  2. Click the “+ New Role” button.

  3. Drata suggests using the following for the Name:
    Drata Monitoring Role

  4. Check the box for the Security Notification Rules Read permission so Drata’s Logs Monitored for Suspicious Activity test is able to verify notifications are enabled.

  5. Check the box for the Usage Read permission so Drata’s Capacity and Usage Monitoring test is able to verify hosts are being monitored.

  6. Check the box for the Logs Read Archives permission so Drata’s Logs are Retained for 365 Days test is able to verify archives’ destination.

  7. There are 8 permissions granted to all roles by default. These permissions cannot be disabled. The role should now have a total of 11 permissions.

  8. (Optional) You may choose to add an additional permission - see the Adding Additional Permissions section below.

  9. Click "Save".

Adding Additional Permissions:

Datadog’s AWS integration (https://app.datadoghq.com/integrations/amazon-web-services) has the ability to tag metrics with specific tags for each AWS Account as shown here:

For the various infrastructure monitoring tests, some monitor setups make use of integration-level tagging that requires additional permissions. If your monitor chooses tags generated as part of your Datadog <> AWS Integration, Drata may not be able to use those tags to match the monitor to its related infrastructure and fail the test.

While Drata builds a workaround to this, you may be able to solve the problem with the addition of an additional permission, though it gives more permission to Drata than we'd like. If you see these failures and want to quickly resolve them, the Datadog Service Account could be granted the Integrations API Permission, but be aware of the write permissions it grants as well. Let our CS team know if this affects your tenant as well, and include a screenshot of the AWS integration accounts connected to Datadog as seen above.

Create a Service Account:

  1. Navigate to https://app.datadoghq.com/organization-settings/service-accounts

  2. Click the "+ New Service Account" button.

  3. Fill in a name and email address for the Service Account.

  4. Drata suggests adding the following name for the Service Account:

    Drata Service Account

  5. (Optional) To further customize the scopes available to the service account, skip to "Adding Specific Permissions".

  6. Assign the "Drata Monitoring Role".

  7. Click "Create Service Account".


Create an Application Key:

  1. Click on the Service Account you just created.

  2. Click the "+ New Key" button.

  3. Drata suggests adding the following name for the Key:

    Drata Application Key

  4. Click the "Create Key" button.

  5. Click the "Copy Key" button. The Key's value will not be shown again.

  6. Paste the Key into Application Key input. Do not copy or paste the Key ID.

  7. Click Save & Test Connection

Expected Datadog Setup and Troubleshooting


Infrastructure Monitoring Tests

⚠️ Note: For these tests, only customers with AWS Infrastructure and Datadog are supported. Support for Azure, GCP, and AWS Organizational Units will be addressed at a future date.

In the current Datadog implementation, these tests will only work in Datadog if there is an accompanying AWS connection that can inform Drata of the AWS infrastructure that needs monitoring.

The first set of tests require monitors to be created within Datadog that contain the following metrics in their monitoring queries. These monitors should be visible on your https://app.datadoghq.com/monitors/manage screen, or they will need to be created.
​
On the AWS side, you need to add Amazon Web Services to your installed Datadog Integrations, if you haven't already, to be able to use the default metrics provided for AWS. Once installed, include these metrics in the query when creating a new monitor. The Drata integration only cares about a monitor existing with the defined metrics listed below for each test.

If you had previously set up CloudWatch alarms to pass the Drata monitoring tests listed below, and you now want your alarms to be read from Datadog, you must delete the AWS CloudWatch alarms in order for Drata to read the Datadog settings. In addition, for the alarm-based monitoring tests to pass, you must set up active notifications against these alarms in Datadog. This is a similar concept to establishing an SNS topic and active subscription against a CloudWatch alarm in AWS.

Warning: The metric name must be explicit and match. For example - aws.rds.cpuutilization.max is not supported, even though the metric name is similar -- let us know if we should look at additional metrics you make use of today!

Monitoring Test

Datadog Metric Name

Database CPU Monitored

aws.rds.cpuutilization
aws.docdb.cpuutilization

Database Free Storage Space Monitored

aws.rds.free_storage_space
aws.rds.free_local_storage
aws.docdb.free_local_storage

Database Read I/O Monitored

aws.rds.read_iops

Messaging Queue Message Age Monitored

aws.sqs.approximate_age_of_oldest_message

Infrastructure Instance CPU Monitored

aws.ec2.cpuutilization.maximum
aws.ec2.cpuutilization
aws.ecs.cpuutilization
aws.ecs.cpuutilization.maximum


Logs are Centrally Stored

This test will generate an API response from Datadog listing all your active logging pipelines. If there is at least one, the test will pass. This test is not expected to fail very often, but is expected to give your auditor a good idea of all the data sources your company has that are piping logs into Datadog. Note that pipelines can be created in various ways, and if you are unfamiliar with them, we recommend reading through the Datadog documentation.

Additional details about how Drata executes this test can be found here.


​

Only Authorized Users can Access Log Sinks

This test checks for user permissions to read logs in Datadog. For now, the tests are using the standard Datadog Roles to check, though we have plans to limit this to the specific permissions Logs Read Index Data and Logs Read Data. As of now, we more simply check the user has access to one or all of the following Roles: Datadog Admin Role, Datadog Read Only Role, or Datadog Standard Role.
​
If that is true of a user, we fail the test unless the user has been specifically marked with the "Access Log Sinks" toggle in the Drata console under the Datadog Manage Accounts page. See the image below for an example. Note that out of scope accounts will not be included in this check.

Additional details about how Drata executes this test can be found here.
​

Logs are Retained for 365 Days

In its current state, this test requires an AWS S3 Bucket to exist and be configured in Datadog as an archive. Drata must have read access to this bucket's metadata under the AWS connection. The S3 bucket may have a Lifecycle Rule that expires items in the bucket after 365 days or longer, or have no lifecycle rule that prevents it from holding the data indefinitely. Note that the setting up of Lifecycle Rules below is optional.

(Optional) To find and set this period in AWS:

  1. Select an AWS Bucket in the AWS S3 Web Console

  2. Select the Management Tab

  3. Within the LifeCycle rules section, click the "Create lifecycle rule" button.

  4. Set up the Lifecycle rule with whatever name, prefix, and object tags you want, but for this test Drata looks at the "Lifecycle rule actions" section.

  5. Select the checkbox for "Expire current versions of objects"

  6. The section "Expire current versions of objects" will appear.

  7. Set the "Days after object creation" value to 365 or a greater value.

  8. Scroll to the bottom and click the "Create Rule" button.

To set up Datadog to Archive data to an S3 bucket:

  1. Only Datadog users with logs_write_archive permission can complete this and the following steps.

  2. Navigate to the Logs Archiving configuration page in the Datadog console.

  3. Click the "+ New Archive" button.

  4. Set your Archive Name and define which data you want archived.

  5. Select Amazon S3 as the Archive Type

  6. Select the appropriate AWS account and role combination for your S3 bucket

  7. (Optional) Input a prefix directory in the Path input.

  8. Click the "Save" button to create the Archive.

  9. For additional info please read the Datadog documentation on this setup

Additional details about how Drata executes this test can be found here.

Logs Are Monitored For Suspicious Activity

Warning: This test depends on the Datadog Cloud Security Platform product, which is a paid Datadog feature. You can check if you have this feature enabled by navigating to https://app.datadoghq.com/security/home and verifying that you see the "Cloud SIEM" dashboard. If this product is not enabled, you should disable this test.

This test checks that you're using all 5 supported Detection Rule types in your Datadog Security Notification Rules. The five rule types Drata will check for coverage across all notification rules are:

  1. Application Security

  2. Log Detection

  3. Cloud Configuration

  4. Infrastructure Configuration

  5. Workload Security

  • The simplest way to pass this test is to:

    1. Navigate to the Notification Rules page.

    2. Add a new Notification Rule with the "+ New Notification Rule" button.

    3. Add a name and recipient.

    4. By default, having one Notification Rule that has all 5 detection rule types selected will pass this test. But you could also split each rule type into a different notification rule.

    5. Click the "Save and Activate" button to create the rule.

Additional details about how Drata executes this test can be found here.

Capacity and Usage Monitoring

Reminder: The Datadog Service Account making the connection will need to have access to the Usage Read Permission. To add this, you will need to edit either the Read Only Role or make a new Role that also has this permission, and attach it to the Drata Service Account.
​

Datadog should be ingesting information from at least one infrastructure source (easily done after making an integration connection from the Datadog integration page).
​
You should ensure at least 1 infrastructure instance is active, running, and connected to Datadog. This can be verified by viewing the Datadog Infrastructure List.
​
The Drata test will check that within the last 24 hours, for at least a 1 hour period, Datadog detected usage from that infrastructure. This can be viewed on the Datadog Plan & Usage page.

Additional details about how Drata executes this test can be found here.

Did this answer your question?