Datadog Application Security Management (ASM) provides observability into application-level attacks that aim to exploit code-level vulnerabilities, and into any bad actors targeting your systems. ASM helps you quickly respond to threats and remediate vulnerabilities on your web applications and APIs.
This guide walks you through best practices for getting your team up and running with ASM.
In your first three days with Datadog ASM:
Identify the most exposed services. Go to the Service Catalog Security view and sort the data by the Suspicious Requests column.
This data is collected from APM traces (through Datadog libraries). It provides you with visibility on the services that are exposed to the most suspicious traffic.
Enable ASM on the most exposed services. Click Enable ASM in the ASM Status column to see the instructions or share them with the service’s owner.
Because ASM relies on the same library as APM, configuring a single environment variable is all that is needed to get ASM enabled on a service that is already sending traces. Read more in the Enabling ASM documentation.
Explore your first suspicious requests. Go to Security –> Application Security to see suspicious requests listed in ASM.
If the client IP is not well-resolved (for example, if it’s showing an internal or proxy IP), configure the client IP header.
Open the Traces page and click one of the traces for a suspicious request. The Attack Flow diagram helps you understand all the services hit by the attack. Scroll down to the Security section to read about why this request was flagged as suspicious. Read more in How Application Security Management Works.
You don’t need to examine every suspicious request individually. ASM generates signals when your attention is required, which you can learn about in Phase 2.
Now that ASM is set up detecting suspicious requests on your service in real-time, let the product run for a couple days.
Note: ASM also enables you to track user activity, identifying authenticated users making suspicious requests. Setting up authenticated user tracking is not required to use ASM, but it does help you get visibility on authenticated attacks and attackers.
After a few days of usage, you typically get your first security signals. If you have not received your first security signal, you can simulate an attack and trigger a signal by running the following script from a terminal:
for ((i=1;i<=200;i++)); do
# Target existing service’s routes
curl https://your-application-url/<EXISTING ROUTE> -A
'dd-test-scanner-log';
# Target non existing service’s routes
curl https://your-application-url/<NON-EXISTING ROUTE> -A
'dd-test-scanner-log';
doneOver the next few days:
Review security signals at Security –> Application Security –> Signals. Security signals are generated by ASM when your attention is required. The signal severity provides you with insights on how quickly you need to react.
Aim to review INFO and LOW signals once a week, MEDIUM and HIGH once a day, and CRITICAL signals immediately.
Click a signal to see its details. The signal details tell you what happened, who the attackers are, and what you should do next. On the Traces tab, you can investigate the traces that generated the signals.
Archive the signal after it’s been investigated. If the signal is a false positive, set up a passlist entry to eliminate noisy signal patterns.
Subscribe to the weekly digest to receive weekly updates on your detected security activity.
Set up a notification rule to alert you in real-time when attacks require your attention, over email, Slack, or other communication integrations. Datadog recommends setting a notification rule for Medium and higher severity signals.
Additional helpful documentation, links, and articles:
