导语：
我最近与来自完全不同行业/领域的几个客户开展了研讨会，Sysmon + SIEM（安全信息和事件管理）检测规则 VS 商业EDR到底如何选择？这是一个反复出现的话题。
不选Sysmon的理由
Sysmon vs EDR
全球指标反映了过去30天内所有受监控端点上每个指标的发生情况。
| 设备时间 | 指标 | 全球趋势 | 全球端点数 | 评分 |
|---|---|---|---|---|
| 4月1日 04:54 | 观察到潜在未跟踪的RAT（远程访问工具）痕迹 | 3 | 10.00 | |
| 4月1日 04:52 | 潜在已知的RAT网络活动 | 7 | 7.00 | |
| 4月1日 04:50 | 从非浏览器访问非HTTP/S端口的稀有外部域名 <rustdesk.com> | 6 | 6.00 | |
| 4月1日 04:50 | 观察到潜在已知的RAT痕迹 | 5 | 5.50 | |
| 4月1日 04:48 | 从临时压缩文件运行的可执行文件或脚本 | 4 | 5.50 | |
| 4月1日 04:56 | 文件下载匹配显著扩展名 | 3 | 5.00 | |
| 4月1日 04:56 | 从Google Docs下载显著文件 | - | - | 5.00 |
| 4月1日 04:54 | 新进程执行外部连接至高UDP端口 | - | - | 4.50 |
| 4月1日 04:52 | 新进程执行外部连接至非常见TCP Web端口 | - | - | 4.00 |
| 4月1日 04:50 | LOLBin: <certutil.exe> 联系高频外部域名 <digicert.com> | 2 | 3.00 | |
| 4月1日 04:48 | 从临时位置执行的可执行文件 | 3 | 3.00 | |
| 4月1日 04:56 | 基线中未发现的新哈希 | 2 | 2.50 | |
| 4月1日 04:54 | 基线中未发现的Packer工具 | 1 | 2.00 | |
| 4月1日 04:52 | 管理员：通过consent.exe请求的管理权限 | 1 | 1.50 | |
| 4月1日 04:50 | 在命令行中找到URL | 1 | 1.00 | |
| 4月1日 04:48 | 压缩文件操作 | 1 | 0.50 |
**全球指标反映了过去30天内所有受监控端点上每个指标的发生情况。**| 设备时间 | 指标 | 全球趋势 | 全球端点数 | 评分 ||----------|------|----------|-----------|------|| 4月1日 04:54 | 观察到潜在未跟踪的RAT（远程访问工具）痕迹 |  | 3 | 10.00 || 4月1日 04:52 | 潜在已知的RAT网络活动 |  | 7 | 7.00 || 4月1日 04:50 | 从非浏览器访问非HTTP/S端口的稀有外部域名 <rustdesk.com> |  | 6 | 6.00 || 4月1日 04:50 | 观察到潜在已知的RAT痕迹 |  | 5 | 5.50 || 4月1日 04:48 | 从临时压缩文件运行的可执行文件或脚本 |  | 4 | 5.50 || 4月1日 04:56 | 文件下载匹配显著扩展名 |  | 3 | 5.00 || 4月1日 04:56 | 从Google Docs下载显著文件 | - | - | 5.00 || 4月1日 04:54 | 新进程执行外部连接至高UDP端口 | - | - | 4.50 || 4月1日 04:52 | 新进程执行外部连接至非常见TCP Web端口 | - | - | 4.00 || 4月1日 04:50 | LOLBin: <certutil.exe> 联系高频外部域名 <digicert.com> |  | 2 | 3.00 || 4月1日 04:48 | 从临时位置执行的可执行文件 |  | 3 | 3.00 || 4月1日 04:56 | 基线中未发现的新哈希 |  | 2 | 2.50 || 4月1日 04:54 | 基线中未发现的Packer工具 |  | 1 | 2.00 || 4月1日 04:52 | 管理员：通过consent.exe请求的管理权限 |  | 1 | 1.50 || 4月1日 04:50 | 在命令行中找到URL |  | 1 | 1.00 || 4月1日 04:48 | 压缩文件操作 |  | 1 | 0.50 |
然而，大多数组织没有工程能力或技能来走这条路。此外，如果一开始没有考虑可扩展性来设计框架，维护起来也不容易。
在SIEM中，我们大多数时候专注于构建检测，而实际的检测在别处完成（在EDR中?）。
这是你战略中的一个重大决定，从这里我开始阐述为什么你应该把这些检测外包给EDR。
“吞吐量”：EDR厂商的产品研发团队 VS 企业内部安全团队
"吞吐量"在这里指的是单位时间内可以开发和交付的安全检测功能的数量和质量。专门的EDR产品团队在这方面具有明显的优势。
主要原因包括：
1. EDR厂商拥有专业的研发团队，聚焦产品功能开发，可以投入更多的人力资源。相比之下，企业内部团队往往人手有限，还要兼顾其他工作。
2. 开发检测能力是EDR厂商的核心业务，他们有更强的动力快速迭代、完善产品。而对企业而言，这只是众多安全管理任务之一。
3. EDR团队可以通过产品化实现检测能力的快速复制和交付，使众多客户受益。而企业内部团队的成果很难在组织外部共享。
因此，在检测能力的开发效率和覆盖范围方面，企业内部团队很难与专业的EDR厂商竞争。对于大多数企业来说，从成本效益的角度考虑，购买成熟的EDR产品是更经济的选择。
当然，这并不意味着企业完全不需要内部团队参与检测能力的开发。对于EDR未覆盖的特定场景，以及快速响应特定安全事件的需求，专业的内部团队还是可以发挥重要作用的。
然而，你的（小）内部团队需要让Sysmon保持运行，同时还要设计、测试和部署利用Sysmon日志的SIEM检测规则。
EDR产品的检测（和功能）将很容易超过你的团队使用原始日志+SIEM规则所能完成的。
作为企业安全负责人者，我最好调配这些资源，因为大多数团队除了检测工程之外，还在执行其他任务，如威胁情报/建模、事件响应等。
作为从业者，如果你真的喜欢这样做，可以考虑加入供应商，甚至开发自己的产品。这方面有很多成功的故事!
我一直在说:
如今，在企业环境中显著提高检测覆盖面的最有效措施，就是安装新的EDR agent。
从它激活的那一刻起，就有数百个场景被监控，没有任何SIEM规则集可以与之相提并论。
大多数时候，从数据收集的角度来看，只需将EDR告警接入SIEM就足够了，而不需要同时引入原始日志。
然而，当涉及确保不遗漏任何告警信号，并在尽可能多的端点（服务器和笔记本电脑）上安装agent时，SIEM仍然是王者。这只是其用例的几个例子。
支持Sysmon的看法
Sysmon是互补的
这一点很容易达成一致，但我亲眼目睹了维持一个健康、大规模的Sysmon部署有多难。这需要时间，而这些时间本可以用于其他运维周期。
最重要的是，我不确定：
EDR未覆盖的用例是什么。迟早，供应商将能够覆盖这一点，考虑到他们今天的开发速度。
这种用例的价值是否值得在一个端点维护多个agent+维护Sysmon的投入。
EDR检测 = 黑盒
对大多数产品来说确实如此。你无法看到清晰的检测列表，更不用说背后的代码或逻辑了。
然而，现代EDR将覆盖大量检测，因此真正的挑战变成了确定团队应该关注哪些告警信号的优先级。这就是SIEM分析发挥作用的地方!
每当发现明显的差距，你的团队就应该能够在EDR的开箱即用功能之上进行构建。
例如，大多数EDR不会将TeamViewer和其他合法的远程协助软件标记为可疑。
在这种情况下，你的EDR应该提供一种方法来创建自定义检测，可以轻松地部署到多个终端。
专业提示：如果你可以像在SIEM中一样制作EDR检测规则，会怎样?
我的意思是，使用相同的开发工作流，甚至可能使用相同的查询语言?
是的，微软和CrowdStrike在这方面有明显优势!
这是通过有选择地启用正确的EDR原始日志，然后通过SIEM中的检测规则捕获它来实现的。
或者更好的方法是，在EDR之上构建自定义检测规则，然后在SIEM中汇总这个告警信号。
参考资料：
https://detect.fyi/sysmon-a-viable-alternative-to-edr-44d4fbe5735a
推荐阅读
闲谈
威胁情报
1.威胁情报 - 最危险的网络安全工作
2.威胁情报专栏 | 威胁情报这十年（前传）
3.网络威胁情报的未来
4.情报内生？| 利用威胁情报平台落地网空杀伤链的七种方法
5.威胁情报专栏 | 特别策划 - 网空杀伤链
APT
入侵分析与红队攻防
天御智库
如有侵权请联系:admin#unsafe.sh