How Application Security Management Works in Datadog
Cette page n'est pas encore disponible en français, sa traduction est en cours.
Si vous avez des questions ou des retours sur notre projet de traduction actuel, n'hésitez pas à nous contacter
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.
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 threat monitoring is in private beta. Request to join the early preview with this form
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.
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.
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.
One-click IP blocking is in private beta. Access early preview through this form
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.
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.
Documentation, liens et articles supplémentaires utiles: