- 필수 기능
- 시작하기
- Glossary
- 표준 속성
- Guides
- Agent
- 통합
- 개방형텔레메트리
- 개발자
- API
- Datadog Mobile App
- CoScreen
- Cloudcraft
- 앱 내
- 서비스 관리
- 인프라스트럭처
- 애플리케이션 성능
- APM
- Continuous Profiler
- 스팬 시각화
- 데이터 스트림 모니터링
- 데이터 작업 모니터링
- 디지털 경험
- 소프트웨어 제공
- 보안
- AI Observability
- 로그 관리
- 관리
This topic explains how Cloud Security Management Threats (CSM Threats) actively monitors system activity and evaluates it against a set of out-of-the-box (OOTB) rules to detect suspicious behavior.
By default, all OOTB Agent crypto mining threat detection rules are enabled and actively monitoring for threats.
Active Protection enables you to proactively block and terminate crypto mining threats identified by the Datadog Agent threat detection rules.
CSM Threats rules consist of two different components: Agent rules and threat detection rules.
Agent rules: Agent rules are evaluated on the Agent host. CSM Threats first evaluates activity within the Datadog Agent against Agent expressions to decide what activity to collect. Agent expressions use Datadog’s Security Language (SECL).
For example, here is the Agent rule expression cryptominer_args
:
exec.args_flags in ["cpu-priority", "donate-level", ~"randomx-1gb-pages"] ||
exec.args in [
~"*stratum+tcp*",
~"*stratum+ssl*",
~"*stratum1+tcp*",
~"*stratum1+ssl*",
~"*stratum2+tcp*",
~"*stratum2+ssl*",
~"*nicehash*",
~"*yespower*"
]
Threat detection rules: Threat detection rules are evaluated on the Datadog backend. Threat detection rules are composed of existing Agent rules and additional expression parameters.
Here is the threat detection rule Process arguments match cryptocurrency miner
. It uses the Agent rules, cryptominer_args
and windows_cryptominer_process
, identified by @agent.rule_id
, with additional expression parameters:
@agent.rule_id:(cryptominer_args || windows_cryptominer_process)
-@process.executable.path:"/usr/bin/grep"
CSM Threats uses the following pipeline when evaluating events:
The following diagram illustrates this pipeline:
CSM Threats detection rules are complex, correlating several datapoints, sometimes across different hosts, and including third party data. This complexity would result in considerable compute resource demands on the Agent host if all rules were evaluated there.
Datadog solves this problem by keeping the Agent lightweight with only a few rules, and processes most rules using the threat detection rules on the Datadog backend.
Only when the Agent observes an event that matches its rules does it send a detection to the Datadog backend. The Datadog backend then evaluates the detection to determine if it meets its threat detection rule expressions. Only if there is a match does the Datadog backend create a signal.
Understanding the dependency threat detection rules have on Agent rules is important when you want to use custom rules. Custom rules help to detect events Datadog is not detecting with its OOTB rules.
There are two use cases:
For a detailed explanation, see CSM Threats Detection Rules.
Agent rules contain Agent expressions that determine which activities the Agent collects. A full set of Agent rules is called a policy. Datadog provides you with several out-of-the-box Agent rules powered by the default Agent policy.
With Remote Configuration enabled, you automatically receive new and updated CSM Threats Agent rules when they’re released. These bundled Agent rules are used in the default detection rules.
Agent expressions use Datadog’s Security Language (SECL) to define behavior based on activity in your hosts and containers, as shown in the following examples:
passwd
command is executedTo detect when the passwd
command is executed, there are a few attributes to note.
On most Linux distributions, the passwd
utility is installed at /usr/bin/passwd
. Execution events include exec
, execve
, fork
, and other system calls. In the CSM Threats environment, all of these events are identified by the exec
symbol.
Putting it all together, the rule expression is exec.file.path == "/usr/bin/passwd"
.
The passwd
command rule is already present in the default CSM Threats Agent policy. However, Agent expressions can also be more advanced, and can define rules that match on process ancestors or use wildcards for broader detections.
To detect when a PHP or Nginx process launches Bash, there are a few attributes to note.
On most Linux distributions, Bash is installed at /usr/bin/bash
. As in the previous example, to detect execution, include exec.file.path == "/usr/bin/bash"
in your rule. This ensures the rule is accounting for the execution of Bash, and also Bash as a child process of PHP or Nginx.
A process ancestor’s filename in CSM Threats is an attribute with the symbol process.ancestors.file.name
. To check if the ancestor is Nginx, add process.ancestors.file.name == "nginx"
. Since PHP runs as multiple processes, use a wildcard to expand the rule to any process with the prefix php
. To check if the ancestor is a PHP process, add process.ancestors.file.name =~ "php*"
.
Putting it all together, the rule expression is exec.file.path == "/usr/bin/bash" && (process.ancestors.file.name == "nginx" || process.ancestors.file.name =~ "php*")
.
Detection rules run in the Datadog backend after events are sent over as logs. The logs are then evaluated based on patterns of events described in the detection rules. If the pattern matches a detection rule, a security signal is generated. Datadog continuously develops new detection rules, which are automatically imported into your account.