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:
Click the "+ New Key" button.
Drata suggests adding the following name for the Key:
Drata API Key
Click the "Create Key" button.
Click the "Copy Key" button. The Key's value will not be shown again.
Paste the Key into API Key input. Do not copy or paste the Key ID.
Create a Role:
Select + New Role.
Drata suggests using the following for the Name: Drata Monitoring Role
Select the following permissions:
Security Notification Rules Read
Required for Drata's Logs Monitored for Suspicious Activity test to verify that security notifications are enabled.
Usage Read
Required for Drata's Capacity and Usage Monitoring test to verify that hosts are being monitored.
Logs Read Archives
Required for Drata's Logs are Retained for 365 Days test to verify the archive destination.
Logs Configuration Read
There are 8 permissions granted to all roles by default. These permissions cannot be disabled. With the four additional permissions, the role should now have 12 permissions in total.
(Optional) Add other permissions as needed. For more information, refer to the Adding additional permissions section.
Select 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:
Click the "+ New Service Account" button.
Fill in a name and email address for the Service Account.
Drata suggests adding the following name for the Service Account:
Drata Service Account
(Optional) To further customize the scopes available to the service account, skip to "Adding Specific Permissions".
Assign the "Drata Monitoring Role".
Click "Create Service Account".
Create an Application Key:
Click on the Service Account you just created.
Click the "+ New Key" button.
Drata suggests adding the following name for the Key:
Drata Application Key
Click the "Create Key" button.
Click the "Copy Key" button. The Key's value will not be shown again.
Paste the Key into Application Key input. Do not copy or paste the Key ID.
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 |
Database Free Storage Space Monitored | aws.rds.free_storage_space |
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 |
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:
Select an AWS Bucket in the AWS S3 Web Console
Select the Management Tab
Within the LifeCycle rules section, click the "Create lifecycle rule" button.
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.
Select the checkbox for "Expire current versions of objects"
The section "Expire current versions of objects" will appear.
Set the "Days after object creation" value to 365 or a greater value.
Scroll to the bottom and click the "Create Rule" button.
To set up Datadog to Archive data to an S3 bucket:
Only Datadog users with logs_write_archive permission can complete this and the following steps.
Navigate to the Logs Archiving configuration page in the Datadog console.
Click the "+ New Archive" button.
Set your Archive Name and define which data you want archived.
Select Amazon S3 as the Archive Type
Select the appropriate AWS account and role combination for your S3 bucket
(Optional) Input a prefix directory in the Path input.
Click the "Save" button to create the Archive.
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 Note: 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.
For more information, go to Logs Are Monitored For Suspicious Activity
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.