先说定义
证据中没有任何攻击事件
如果一条告警的证据中没有任何事件被标注为攻击，它就是误报。
误报 ÷ 全部告警
与行业常说的“40% 以上的告警是误报”采用同一口径：分析师不得不查看的告警。
没有触发任何告警的攻击
已标注的攻击，却没有产生任何告警。
相同检测器，但不做上下文和关联
每个信号一条告警，同一规则和主机在一分钟内去重。比较的是架构，而不是规则集。
先回放一段没有攻击的时期，让平台学习正常状态。这段时期内的告警对两种方法都不计入。
CICIDS2017：220 万条网络流
来自加拿大网络安全研究所的网络流数据，采用 KU Leuven 修正后的标注（Engelen、Rimmer、Joosen，IEEE CNS 2022）。数据和标注都不是我们的。每天约 55 万条网络流。
| 日期 | SENTINEL AI：告警 | SENTINEL AI：误报 | 传统方法：告警 | 传统方法：误报 |
|---|---|---|---|---|
| 周二 | 2 | 0% | 210 | 41.9% |
| 周三 | 1 | 0% | 63 | 38.1% |
| 周四 | 2 | 0% | 71 | 49.3% |
| 周五 | 4 | 0% | 85 | 48.2% |
| 四天合计 | 9 | 0% | 429 | 43.8% |
已发现
- FTP-Patator
- SSH-Patator
- PortScan
- DDoS
- Botnet
- DoS Slowloris
- DoS GoldenEye
- DoS Hulk
- DoS Slowhttptest
- Infiltration-PortScan
未发现
- Heartbleed
- Web 攻击：暴力破解、XSS、SQL 注入
- Infiltration
为什么漏掉
该数据集只有网络流统计：数据包和字节数、时间、TCP 标志位。没有 HTTP 请求行，没有 TLS 记录，也没有进程数据。SQL 注入和 XSS 位于请求正文中：平台能够识别它们，但需要 Web 服务器或 WAF 的日志。曾有一条规则根据网络流形态推测 Heartbleed，结果对每一次普通的 HTTPS 下载都会触发，因此被删除，而没有发布。
高难度的合法流量
一个模拟的政府机构：域控制器、文件和数据库服务器、门户网站、备份、漏洞扫描器、36 台工作站、35 个账户。一个工作日中穿插了八个已标注的攻击场景。
这不能证明什么
合法噪音来自一个约十种模式的固定目录，检测器和数据出自同一作者之手。这是底线检验：平台能扛住让传统工具失灵的噪音。正因如此，才有上面的独立数据。
一台服务器能承受多少
五分钟、16 个并发采集器、每批 200 个事件，遥测数据模拟真实的 Windows 环境，其中 2% 模拟入侵，让关联层和评分层真正运转起来。
AMD Ryzen 7 7435HS，8 核，16 GB，NVMe，SQLite（WAL 模式）。负载生成器运行在同一台机器上，与平台争用处理器，因此这些数字是下限。
结果没有说明什么
九条告警是很小的样本
只要出现一次错误，误报率就会变成 10%。结果表明架构不会产生日常噪音，但无法精确确定误报率。这需要在真实流量上长期运行。
在这批数据上召回率不完整
有些攻击没有被发现，而它们恰恰是证据不在网络流中的那些。应把误报率视为强项，把在该数据集上的召回率视为不完整。
平台只能看到发给它的数据
在已接入的遥测中不留痕迹的攻击，平台无法发现。所以试点首先要选择数据源。
模型和检测器出自同一作者
这就是每次运行结果相同的原因。这也说明了独立数据和在您自己的数据上试点的必要性。
我们修复的缺陷
每一个都是在真实数据上运行时发现的，而不是靠阅读代码。以下是最具代表性的三个。
同一个原因被算了四次
“这是一名技术支持人员”解释了四个观察结果，却被当作四个发现相加。这曾是日常 IT 工作中误报的最大来源。现在，共享同一解释的证据只计算一次。
攻击最猛烈时，核心反而变慢
一次端口扫描把成千上万个信号放进同一个案件，而案件在每个信号到来时都被重新评分。吞吐量从每秒 20,000 个事件降到 180 个。已修复。
规则被删除，而不是发布
对每一次 HTTPS 文件下载都触发的检测器起不到任何预警作用，只会让分析师学会不看告警。
复现每项测量的命令都随产品一同交付。