Application Security Management (ASM) Protect enables you to slow down attacks and attackers by blocking them. Suspicious requests are blocked in real-time by the Datadog tracing libraries. Blocks are saved in the Datadog platform, automatically and securely fetched by the Datadog Agent, deployed in your infrastructure, and applied to your services.
To leveraging protection capabilities for your service:
Update your Datadog Agent to at least version 7.41.1.
Update your tracing library to the appropriate minimum version needed to turn on protection and the supported capabilities:
| Java | .NET | NodeJS | Go | Python | |
|---|---|---|---|---|---|
| Minumum tracer version | 1.9.0 | 2.23.0 | 3.11.0 | 1.48.0 | 1.9.0 |
| IP blocking support | |||||
| User blocking support | |||||
| Suspicious requests blocking (in-app WAF) |
If you plan to use authenticated user blocking, add user information to traces.
You can block attackers that are flagged in ASM Security Signals temporarily or permanently. In the Signals Explorer, click into a signal to see what users and IP addresses are generating the signal, and optionally block them.
From there, all ASM-protected services block incoming requests performed by the blocked IP or user, for the specified duration. All blocked traces are tagged with security_response.block_ip or security_response.block_user and displayed in the Trace Explorer. Services where ASM is disabled aren’t protected.
Attackers’ IP addresses and authenticated users that are permanently or temporarily blocked are added to the Denylist. Manage the list on the Denylist page.
You can use the Passlist to permanently allow an IP address, or range of addresses, access to your application. For example, you may wish to add internal IP addresses to your passlist, or IP addresses that regularly run security audits on your application. You can also add specific paths to ensure uninterrupted access. Manage the list from the Passlist page.
ASM In-App WAF (web application firewall) combines the detection techniques of perimeter-based WAFs with the rich context provided by Datadog, helping your teams protect their systems with confidence.
Because ASM is aware of an application’s routes, protection can be applied granularly to specific services, and not necessarily across all applications and traffic. This contextual efficiency reduces your inspection effort, and it reduces the false positive rate compared to a perimeter WAF. There is no learning period, because most web frameworks provide a structured map of routes. ASM can help your team roll out protections against zero-day vulnerabilities automatically soon after the vulnerability is disclosed, while targeting vulnerable applications, limiting the risk of false positives.
In addition to the monitoring and disabled modes offered for each of the 130+ In-App WAF rules, rules also have blocking mode. Each rule specifies conditions on the incoming request to define what the library considers suspicious. When a given rule pattern matches an ongoing HTTP request, the request is blocked by the library.
Managed policies define the mode in which each of the In-App WAF rules behave on match: monitoring, blocking, or disabled. Because it has the full context of your applications, ASM knows which rules to apply to protect your applications while limiting the number of false positives.
For fine-grained control, you can clone a Datadog managed policy or create a custom policy and set the mode to meet your needs. If you set the policy to auto-updating, your applications are protected by the latest detections rolled out by Datadog. You also have the option to pin a policy to a specific version of the ruleset.
As In-App WAF rules are toggled between modes, the changes are reflected in near real-time for services with Remote Configuration enabled. For other services, you can update the policy on the In-App WAF page and then define In-App WAF rules for the change in behavior to be applied.
Manage In-App WAF by navigating to Security –> Application Security –> Configuration –> In-App WAF.
View blocked suspicious requests in the Trace Explorer by filtering on the facet Blocked:true.
The blocked requests feature JSON or HTML content. If the Accept HTTP header is pointing to HTML, like text/html, the HTML content is used. Otherwise, the JSON one is used.
Both sets of content is embedded in the Datadog Tracer library package and loaded locally. See examples of the templates for HTML and JSON in the Datadog Java tracer source code on GitHub.
The HTML and JSON content can both be changed using the DD_APPSEC_HTTP_BLOCKED_TEMPLATE_HTML and DD_APPSEC_HTTP_BLOCKED_TEMPLATE_JSON environment variables. Alternatively, you can use the dd.appsec.http.blocked.template.html or dd.appsec.http.blocked.template.json configuration entries.
By default, the page shown in response to a blocked action looks like this:
Additional helpful documentation, links, and articles:
