How Application Security Management Works in Datadog

Overview

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.

APM records information about each application request, referred to as traces. Datadog ASM uses the same library as APM to monitor your traffic, and flags attack attempts based on suspicious requests that match known attack patterns. Security signals are automatically created when Datadog detects application attacks impacting your services. The signals identify meaningful threats for you review instead of assessing each individual attack attempt. Depending on your security signal settings, you can receive notifications from Slack, email, or PagerDuty.

Traditional Web Application Firewalls (WAFs) are usually deployed at the perimeter and have no context of the application behavior. For ASM to be effective, it must be embedded in the application to get access to the data. Datadog ASM leverages known attack patterns, similar to a Web Application Firewall (WAF) but with additional application context to increase the signal to noise ratio, lowering false positives.

Datadog ASM identifies bad actors by collecting client IP addresses and manually-added user tags on all requests.

Identify services exposed to application attacks

Datadog ASM uses the information APM is already collecting, and flags traces containing attack attempts. Services exposed to application attacks are highlighted directly in the security views embedded in APM (Service Catalog, Service Page, Traces).

Because APM collects a sample of your application traffic, enabling ASM in the tracing library is necessary to effectively monitor and protect your services.

Compatibility

For Datadog ASM to be compatible with your Datadog configuration, you must have APM enabled, and send traces to Datadog. ASM uses the same libraries used by APM, so you don’t need to deploy and maintain another library. Steps to enable Datadog ASM are specific to runtime language. Check to see if your language is supported in the ASM prerequisites.

Serverless monitoring

Datadog ASM supports functions deployed on AWS Lambda. Detection is done by using the Lambda extension.

Full threat monitoring capabilities are available for Lambda functions. You can detect attackers targeting your functions, trace their attack path with deep code-level insights, and then remediate the threat.

Performance

Datadog ASM uses processes already contained in the Agent and APM, so there are negligible performance implications when using it. When APM is enabled, the Datadog Library generates distributed traces. Datadog ASM flags security activity in traces by using known attack patterns. Correlation between the attack patterns and the execution context provided by the distributed trace triggers security signals based on detection rules.

Data Sampling and Retention

In the tracing library, Datadog ASM collects all traces that include security data. A default retention filter ensures the retention of all security-related traces in the Datadog platform.

Data for suspicious requests is kept for 90 days. The underlying trace data is kept for 15 days.

Data privacy

There are multiple methods used to avoid your sensitive information being indexed. To take further action, you can set up custom and static scrubbers, and use exclusion filters.

Note: Datadog ASM does not automatically obfuscate sensitive information or PII. To keep this sensitive data from being sent to Datadog, configure the Datadog Agent or Tracer for data security.

Contact Support to delete sensitive data that may have been indexed.

Threat detection methods

Datadog uses multiple pattern sources, including the OWASP ModSecurity Core Rule Set to detect known threats and vulnerabilities in HTTP requests. When an HTTP request matches one of the OOTB detection rules, a security signal is generated in Datadog.

Security Signals are automatically created when Datadog detects meaningful attacks targeting your production services. It provides you with visibility on the attackers and the targeted services. You can set custom detection rules with thresholds to determine which attacks you want to be notified about.

Built-in protection

Datadog ASM offers built-in protection capabilities to slow down attacks and attackers.

IP blocking actions are implemented through the tracing libraries, not introducing any new dependencies in your stack. IP blocks are saved in the Datadog platform, automatically and securely fetched by the Datadog Agent, deployed in your infrastructure, and applied to your application.

You can block attackers’ IPs that are flagged in ASM Security Signals temporarily or permanently with a single click in the Datadog UI.

From there, all services already protected by ASM block incoming requests performed by the blocked IP, for the specified duration. All blocked traces are tagged with security_response.block_ip and displayed in the Trace Explorer. Services where ASM is disabled aren’t protected.

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.

Coverage

Datadog ASM categorizes attack attempts into different threat types:

• Unqualified attacks match inbound HTTP requests with known attack patterns. For example, no correlation with the service’s business-logic is found after correlating with the execution context provided by the trace.
• Contextualized attacks correlate the attack attempts performed on the service with a matching business-logic. For example, SQL injection patterns on a service performing SQL statements.
• A Vulnerability is triggered when an attack attempt gives evidence that a vulnerability has been successfully exploited, after matching known attack patterns.

Datadog ASM includes over 100 attack patterns that help protect against many different kinds of attacks, including the following vulnerabilities:

• SQL injections
• Code injections
• Shell injections
• NoSQL injections
• Cross-Site Scripting (XSS)
• Sever-side Request Forgery (SSRF)

How Datadog ASM protects against Log4Shell

Datadog ASM identifies Log4j Log4Shell attack payloads and provides visibility into vulnerable apps that attempt to remotely load malicious code. When used in tandem with the rest of Datadog’s Cloud SIEM, you can investigate to identify common post-exploitation activity, and proactively remediate potentially vulnerable Java web services acting as an attack vector.

Further Reading

お役に立つドキュメント、リンクや記事:

Learn more about language and framework compatibilityDOCUMENTATION Introducing Datadog Application SecurityBLOG Get started with Application Security ManagementDOCUMENTATION