How Application Security Management Works in Datadog

Application Security Management is not supported for your selected Datadog site ().

Overview

Datadog Application Security Management (ASM) provides observability into application-level attacks that aim to exploit code-level vulnerabilities or abuse the business logic of your application, and into any bad actors targeting your systems.

In addition, ASM detects the risks built into your applications, for example through vulnerable libraries and dependencies the application uses at runtime.

Datadog APM records information, called traces, about each application request. Datadog ASM uses the same tracing libraries as APM to monitor your traffic. ASM flags attack attempts based on security traces that match known attack patterns, or tags business logic information. Security signals are automatically created when Datadog detects application attacks or business logic abuse impacting your services. The signals identify meaningful threats for your 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. Because ASM is embedded in the application, it has access to trace data, making it more effective at pinpointing and classifying threats. 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.

Identify services exposed to application attacks

Datadog ASM Threat Management 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.

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

1-Click Enablement
If your service is running with an Agent with Remote Configuration enabled and a tracing library version that supports it, you can enable ASM from the Datadog UI without additional configuration of the Agent or tracing libraries.

Identify vulnerable services

Datadog Software Composition Analysis uses various known vulnerability data sources related to open source software libraries, plus information provided by the Datadog security research team, to match the libraries your application depends on at runtime with their potential vulnerabilities, and to make remediation recommendations.

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 for AWS Lambda provides deep visibility into attackers targeting your functions. With distributed tracing providing a context-rich picture of the attack, you can assess the impact and remediate the threat effectively.

Read Enabling ASM for Serverless for information on setting it up.

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.

A diagram illustrates that the Datadog tracer library operates at the application service level and sends traces to the Datadog backend. The Datadog backend flags actionable security signals and sends a notification to the relevant application, such as PagerDuty, Jira or Slack.

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 security traces is kept for 90 days. The underlying trace data is kept for 15 days.

Data privacy

By default, ASM collects information from security traces to help you understand why the request was flagged as suspicious. Before sending the data, ASM scans it for patterns and keywords that indicate that the data is sensitive. If the data is deemed sensitive, it is replaced with a <redacted> flag. This indicates that the request was suspicious, but that the request data could not be collected because of data security concerns.

Here are some examples of data that is flagged as sensitive by default:

  • pwd, password, ipassword, pass_phrase
  • secret
  • key, api_key, private_key, public_key
  • token
  • consumer_id, consumer_key, consumer_secret
  • sign, signed, signature
  • bearer
  • authorization
  • BEGIN PRIVATE KEY
  • ssh-rsa

To configure the information redacted by ASM, refer to the data security configuration

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.

Automatic Threat Patterns Updates: If your service is running with an Agent with Remote Configuration enabled and a tracing library version that supports it , the threat patterns being used to monitor your service are automatically updated whenever Datadog publishes updates.

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

If your service is running an Agent with Remote Configuration enabled and a tracing library version that supports it, you can block attacks and attackers from the Datadog UI without additional configuration of the Agent or tracing libraries.

ASM Protect goes beyond Threat Detection and enables you to take blocking action to slow down attacks and attackers. Unlike perimeter WAFs that apply a broad range of rules to inspect traffic, ASM uses the full context of your application—its databases, frameworks, and programming language—to narrowly apply the most efficient set of inspection rules.

ASM leverages the same tracing libraries as Application Performance Monitoring (APM) to protect your applications against:

  • Attacks: ASM’s In-App WAF inspects all incoming traffic and uses pattern-matching to detect and block malicious traffic (security traces).
  • Attackers: IP addresses and authenticated users that are launching attacks against your applications are detected from the insights collected by the libraries and flagged in Security Signals.

Security traces are blocked in real time by the Datadog tracing libraries. Blocks are saved in Datadog, automatically and securely fetched by the Datadog Agent, deployed in your infrastructure, and applied to your services. For details, read How Remote Configuration Works.

To start leveraging Protection capabilities—In-App WAF, IP blocking, User blocking and more—read Protection.

Attack attempt qualification

Leveraging distributed tracing information, attacks attempts are qualified as safe, unknown, or harmful.

  • Attack attempts qualified as safe cannot breach your application, for example, when a PHP injection attack targets a service written in Java.
  • An unknown qualification is decided when there is not enough information to make a definitive judgement about the attack’s probability of success.
  • A harmful qualification is highlighted when there is evidence that a code level vulnerability has been found by the attacker.

Threat monitoring coverage

Datadog ASM includes over 100 attack signatures that help protect against many different kinds of attacks, including, but not limited to, the following categories:

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

Built-in vulnerability detection

Datadog ASM offers built-in detection capabilities that warn you about the vulnerabilities detected in your open source dependencies. Details of that information are shown in the Vulnerability Explorer, identifying the severity, affected services, potentially vulnerable infrastructure, and remediation instructions to solve the surfaced risks.

For more information, read Software Composition Analysis.

API security

API security is in private beta.

Datadog Application Security Management (ASM) provides visibility into threats targeting your APIs. Use the API Catalog to monitor API health and performance metrics, where you can view attacks targeting your APIs. This view includes the attacker’s IP and authentication information, as well as request headers showing details about how the attack was formed. Using both ASM and API management, you can maintain a comprehensive view of your API attack surface, and respond to mitigate threats.

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