用搜索引擎查了一下，发现在简体中文中似乎找不到介绍检测工程的文章，非常惊讶这么重要的东西在国内没有受到重视。因此就聊聊这个话题，希望能让更多人注意到“检测工程”——一个对于安全行业来说极端重要的技术方法（或者说学科？）， 即使当前“AI驱动安全”更炙手可热，但在个人看来也是需要检测工程作为基础才能发挥真正价值的。
一、未知攻，焉知防
“安全是攻防之间人的对抗”、“未知攻、焉知防”，这些话在行业内被反复提起，无疑也有其道理。但还需要进一步思考，知道如何进攻是否就可以知道如何防守？ 答案无疑是明确的：不能。了解企业面临的威胁和风险固然是做好防御的必要条件，但却不是充分条件，无论是架构层面的访问控制、身份认证，或者是更直接的检测和响应，都还需要更专业的领域知识。这种专业知识的创造和积累相较攻击技术有很大的不同，攻击很多时候可以依赖个体能力，而防御更是一个系统化工程。这种系统化体现在整体的防御水平，是由整个纵深防御系统中最薄弱的环节决定的；它也体现在诸如构建一套IDPS规则时，需要考虑巧妙利用不同的检技术（协议异常、网络异常、攻击特征、漏洞特征、启发式特征、AI模型等）以同时兼具精准性和适应性；它还体现在除了具体的引擎&规则技术，同时还要考虑使用安全产品和执行安全策略的人。好的防御不但要考虑到攻击者会如何做，还考虑到业务环境中的普通用户和不同的安全运营者，也包括如何去保障业务的开展而不是成为业务发展的桎梏。防御系统的建立复杂程度远远高于单纯的攻击。
较早之前，专业的防御关键知识是以个人经验的方式存在，在小范围内交流传播，很少能从公开材料中获取，也缺乏体系化的建设。而当前通过借鉴系统工程和软件工程的思想，防御技术和理念在继承和发展上出现了较大的进展，其中就包括“检测工程”。
二、检测工程简介
检测工程是构建、完善和管理检测内容（Rules、Content、Code、logic ）以抵御当前威胁的过程，是一门网络安全新的学科。随着威胁形式变得越来越复杂同时针对性、目的性越来越强，安全厂商及企业的安全运营团队都需要不断更新防御措施以提供检测潜在安全事件的能力，进而也必须弥合各种来源的数据（日志、元数据、遥测数据、威胁情报、漏洞情报等）和可指导响应活动的安全报警之间的差距。因此不同的厂商不约而同的借鉴了软件工程、敏捷开发中的思想来优化检测能力的构建过程，逐步形成了已经相对完善的检测工程概念、框架、方法等。
基于当前企业安全运营的需要，检测工程的目标也更加多元：检测工程希望尽可能在早期阶段来识别恶意活动，以便有更多时间来处置；检测工程中虽然借鉴了很多开发特征规则形成的最佳实践，但其价值输出并不局限在规则签名上，而是覆盖更多的新的检测技术，也包括AI模型的方法；同时检测工程并不是局限与检测，而是把如何优化事件响应也放到了重要的位置，希望可以优化事件分析过程、缩短事件响应时间，从而在最大程度上减少潜在损失。
检测工程作为一种能力建设的过程和方法，与其它一些近年流行的网络安全新概念有所不同，不是由某一个厂商或者咨询机构构建或推动的，而是由行业内多家公司从不同角度提供相关理念、方法，不断丰富、演进、完善而来的。这其中个人了解贡献比较多的就包括：Splunk、Google、Palantir、SpecterOps等。 当前有大量的信息和材料，每个人学习思考之后得到的东西可能都不尽相同，下面从自己的感受出发介绍几个比较有价值的点。
三、检测工程的关键价值点
1. 最佳实践总结
当前检测工程的材料中，沉淀了大量检测、分析工程师的实践总结，对处理具体工作难点非常有帮助，以传统检测中如何平衡检出率和误报率的问题而言，就基于专家经验给出了非常好的总结。很多检测方向没有系统学习和训练的人，往往认为检出率和误报率不可能同时达到优化，而有经验的检测工程师却知道很多的方法和技巧，可以同时保障这两方面的表现都非常好。SepcterOps就很好的把这些经验总结成了一套系统性的方法：
TTP抽象： 一种攻击技战术的检测，可以从多个层面上去抽象、理解，从最简单的具体攻击工具层面、或者系统调用、网络协议、应用协议等，从不同抽象层面都可以让我们更容易理解具体的攻击，同时也知道不同层面的检测方法可能的抗逃逸能力是如何的，下图就用一个实例表明了不同层面抽象形成的检测能力差异；
来源：https://posts.specterops.io/capability-abstraction-fbeaeeb26384
平衡检测： 有了上一步的分析和抽象工作后，可以建立起多种不同的检测逻辑思路，需要对不同的检测逻辑做进一步分析，以平衡检出和漏报性能。首先需要理解每个检测思路的特点（高误报&低漏报、低误报&高漏报）；需要考量自身（或者客户）的运营力量，能接受的误报水平如何，不要一味追求精准性，而需要在可运营的前提下，接受一定的误报换取更低的漏报性能。
参考：https://posts.specterops.io/detection-spectrum-198a0bfb9302
深度检测： 通过TTP抽象得出攻击中必须经过的多个防御点，对于一个攻击的技战术需要实现多个检测点——通过分层检测来缓解可能的盲点，从而提供更全面的检测；同时分层的方法，可以快速对报警进行关联分析，缩短响应时间；需要在攻击前期的检测中尽可能精准，同时配合SOAR的自动机制及早遏制攻击，在攻击中期可以考虑容忍一定的误报，以覆盖检测的盲点，最后在攻击后期，可以采用更泛化的检测思路，来防止可能出现的遗漏。
参考：https://posts.specterops.io/detection-in-depth-a2392b3a7e94
2. 完整的闭环过程
一些公司的检测能力运营方式，更多的偏重于检测规则的测试和部署，但对早期的需求收集和后续的持续检测都缺少必要的投入，因此时常在客户现场或者竞争性测试中发现重大的检测问题。而检测工程中建立的是一个相对更完整的闭环过程，具体可以参见下面的框架图。通过更有效的需求管理，可以让我们及早把必要的能力构建出来，同时通过持续优化来防止出现无效检测机制积压、低质量报警持续存留等问题。
3. 文档化&规范化
早期的检测能力的创建、开发和实施缺乏严格的规范，普遍存在没有文档和评审的情况下进行生产，因此即使是知名的Top安全企业，也存在部分报警质量极低，导致特定事故、报警疲劳或者额外的运营时间和资源。文档化&规范化不但可以解决上述问题，还可以促进安全能力团队间（情报、检测、响应&运营）更多的共享和协作，激发整体团队的能力来增强检测和防御，最终增加攻击者的成本。
当前比较被业内认可的规范文档框架来源于Palantir（https://github.com/palantir/alerting-detection-strategy-framework），其Github上不但提供了框架的文档，也提供了多个实例。下面是其框架的关键组成部分：
目标：报警的预期用途
分类：和MITRE ATT&CK的映射，工程师可以据此了解杀链阶段，并了解整体最强、最弱的地方，进一步优化威胁建模
技术摘要：提供利用何种数据，如何进行检测并发出警报；
技术背景：提供响应者需要了解的报警相关组件技术背景信息；
盲点和假设：何种情况下报警无法形成或者被绕过；
误报：由于配置错误、环境特殊性以及其它非恶意行为导致的误报及实例；
验证：如何验证报警可以正确触发的步骤，包括脚本和工具；
优先级：在不同环境、配置条件下，可能被标记的报警级别；
响应：触发此报警后的常规响应步骤；
参考资源：有助于理解报警的任何其它技术参考。
这套框架应该是在早期一流IDPS的报警框架进行的改进和完善，更适合当前的现状，还是具备较高的学习和参考价值的。
五、小结
检测工程中的内容太丰富，很难用一篇文章把它讲清楚。这里也只能基于个人的一点粗浅认识给一个大致的介绍，希望可以让多一点人知道检测工程，愿意去进一步了解，学习和应用。
声明：本文来自ZenMind，版权归作者所有。文章内容仅代表作者独立观点，不代表安全内参立场，转载目的在于传递更多信息。如有侵权，请联系 anquanneican@163.com。
