66 lines
4.1 KiB
Markdown
66 lines
4.1 KiB
Markdown
---
|
||
title: "Threat Detection Engineer Agent Personality"
|
||
type: source
|
||
tags: ["agent-personality", "security", "detection-engineering", "siem", "threat-hunting"]
|
||
date: 2026-05-01
|
||
---
|
||
|
||
## Source File
|
||
- [[Agent/agency-agents/engineering/engineering-threat-detection-engineer.md]]
|
||
|
||
## Summary（用中文描述）
|
||
- 核心主题：威胁检测工程师 Agent 个性定义——专注于构建检测层，在攻击者绕过预防控制后捕获威胁
|
||
- 问题域：SIEM 规则开发、MITRE ATT&CK 覆盖度映射、威胁狩猎、告警调优、Detection-as-Code 流水线
|
||
- 方法/机制：用 Sigma（厂商无关）编写检测规则，编译为 Splunk SPL / Sentinel KQL / Elastic EQL / Chronicle YARA-L；通过 Git + CI/CD 实现检测即代码；原子红队验证检测有效性
|
||
- 结论/价值：检测质量远比数量重要；未检测到的入侵损失是已检测到的 10 倍；嘈杂的 SIEM 比没有 SIEM 更糟糕
|
||
|
||
## Key Claims（用中文描述）
|
||
- 检测质量 > 检测数量：未在真实日志数据上测试的规则要么触发一切，要么什么都不触发
|
||
- 行为检测优于 IOC 匹配：IP地址/哈希攻击者每天轮换，行为模式更难伪造
|
||
- 检测即代码：规则版本控制、peer review、测试、CI/CD 部署——绝不在 SIEM 控制台直接编辑
|
||
- MITRE ATT&CK 映射必须：每个检测必须映射到至少一个 ATT&CK 技术，否则无法理解自己在检测什么
|
||
- 覆盖完整杀伤链：仅检测初始访问意味着错失横向移动、持久化和数据外泄
|
||
|
||
## Key Quotes
|
||
> "An undetected breach costs 10x more than a detected one, and a noisy SIEM is worse than no SIEM at all — because it trains analysts to ignore alerts."
|
||
> — Threat Detection Engineer Agent 身份定义
|
||
|
||
> "Detection rules are code: version-controlled, peer-reviewed, tested, and deployed through CI/CD — never edited live in the SIEM console."
|
||
> — 关键规则：运营纪律
|
||
|
||
> "For every detection you write, ask 'how would I evade this?' — then write the detection for the evasion too."
|
||
> — 关键规则：对手思维设计
|
||
|
||
> "A rule that passed testing 12 months ago may not catch today's variant."
|
||
> — 关键规则：季度验证
|
||
|
||
## Key Concepts
|
||
- [[Detection Engineering]]：构建和维护高保真检测规则的学科，强调检测质量优于数量
|
||
- [[Threat Hunting]]：基于情报、异常分析和 ATT&CK 差距评估，主动搜寻检测规则遗漏的威胁
|
||
- [[Alert Tuning]]：通过允许列表、阈值调优和上下文富化降低误报率，提升信噪比
|
||
- [[Detection-as-Code]]：检测规则作为代码管理，Git 版本控制 + CI/CD 测试和部署
|
||
- [[Purple Team]]：红蓝结合的验证方法，通过原子红队测试或紫队练习确认检测有效性
|
||
- [[MITRE ATT&CK Mapping]]：将检测规则映射到 ATT&CK 矩阵，评估覆盖度并识别关键差距
|
||
|
||
## Key Entities
|
||
- [[Sigma]]：厂商无关的检测规则格式，是 Detection-as-Code 的核心语言
|
||
- [[MITRE ATT&CK]]：威胁战术和技术知识库，所有检测规则必须映射到此矩阵
|
||
- [[Splunk]]：企业 SIEM 平台，Sigma 规则编译为 SPL 部署目标之一
|
||
- [[Microsoft Sentinel]]：Azure 云 SIEM，Sigma 规则编译为 KQL 部署目标之一
|
||
- [[Elastic]]：SIEM/可观测性平台，Sigma 规则编译为 EQL 部署目标之一
|
||
- [[Sysmon]]：Windows 系统监视工具，提供进程创建、进程访问等关键事件日志
|
||
|
||
## Connections
|
||
- [[Sigma]] ← writes_detection_rules ← [[Detection Engineering]]
|
||
- [[MITRE ATT&CK]] ← maps_coverage ← [[Detection Engineering]]
|
||
- [[Splunk]] ← deploys ← [[Detection-as-Code]]
|
||
- [[Microsoft Sentinel]] ← deploys ← [[Detection-as-Code]]
|
||
- [[Threat Hunting]] ← converts_findings_to ← [[Detection Engineering]]
|
||
- [[Alert Tuning]] ← improves ← [[Detection Engineering]]
|
||
|
||
## Contradictions
|
||
- 与 [[Alert Tuning]] 存在张力：
|
||
- 冲突点：过度调优可能削弱检测灵敏度，将真正的攻击者行为加入允许列表
|
||
- 当前观点：允许列表和阈值调优是降低误报的必要手段
|
||
- 对方观点：频繁调优会侵蚀 SOC 信任，且可能让真正的 APT 行为通过
|