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.
Phase 1: Enable ASM on your exposed services
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.
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.
If your services use recent versions of tracing libraries, ASM immediately detects security vulnerabilities in the upstream libraries that your services have as dependencies, and APM previews this information for you in its Security view. Optionally, explore ASM’s consolidated Vulnerabilities view to see how it helps you triage and prioritize vulnerabilities.
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.
Phase 2: Review your first security signals and vulnerabilities
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 routescurl https://your-application-url/<EXISTING ROUTE> -A
'dd-test-scanner-log';# Target non existing service's routescurl https://your-application-url/<NON-EXISTING ROUTE> -A
'dd-test-scanner-log';done
Over 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.
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.
Further reading
Additional helpful documentation, links, and articles:
