告警运营逻辑

01

—

    个人原因：笔者虽美名其曰的在做安全运营，但是其实安全运营里面可以细分多个领域的运营，如数据安全运营、研发安全运营、基础安全运营、告警运营等，这个可能也跟每个公司的组织架构有关，而笔者其他领域只是略知一二，告警运营才是组织给我的定位，而我想要总结的也是这方面的内容；

    前辈原因：读了很多偶像的安全运营文章觉得和自己所作所理解的大差不差，而我最喜欢的一篇《小步快跑，快速迭代：安全运营的器术法道》是3-4年前我从一个挖洞小子到阅读后义无反顾的闯入了安全运营这个领域；到如今前段时间我有点迷茫的时候我又拿出来阅读了一遍仍有共鸣与收获！

    上面这篇文章讲到的一个点我个人觉得安全运营人员其实大概率都会遇到，那么我就也建议大家去看看这篇文章，咱们站在巨人的肩膀，去更好的做好安全运营~当然这篇文章可能更适合技术人员去激励自己提升自己。！

    字面理解：其实很多人会把应急响应也归纳到这个领域，但是笔者经过多年工作以及理解并不认为是一个领域。笔者认为告警运营的目标是快速识别真正的威胁，并确保对这些告警进行适当的响应，从而防止潜在的安全事件升级；而应急响应是在告警被升级为事件或者被入侵、造成数据泄露等，通常涉及到更深入的调查和分析，可能需要动员更多的资源和专业知识，包括取证分析、攻击溯源和法律合规性考虑。——应急响应需要的能力、资源不同等于告警运营。

    规划原因：笔者写的过程中也边思考我对告警小组的目标到底定的是什么？现在怎么样？接下来我需要去做到才能达到我预期的目标？为了达成这个目标，我需要去怎么做？

    所以看到这里可以大概了解到本文我想要讲的是哪一方面了，如果非你感兴趣的其实看到这也差不多了，我就是讲下安全运营中的一个小小的领域，大佬们就不用花太多时间往下看了。

MTTR、MTTD 愿景OR目标？

    想必大家都会张嘴就来MTTR达到XX小时内，MTTD达到XX小时内，高危及以上的告警工单关单率达到100%。但最近笔者读书中依稀记得别人做公司的规划时是分为愿景、目标...，愿景可以有前瞻性点、可以高大上点、有所追求的，所以其实上面大家张嘴就来的，往往有时我更愿意把他当作为我目前小组的愿景，目标还是现实点有阶段性点的目标干起来或许更有所期望点，例如笔者这里的MTTR是24小时内，而MTTD这块发现准APT事件？具体怎么定，定为多少貌似目前也没有看到很好的度量方式，除非对一些特定的事件进行复盘分析。

    而往往指标严格计算的话，想要达标除非资源、人力、能力、流程、自动化等跟得上，要不我更倾向于这是每个企业刚开始做规划时的愿景而不是目标了。想做好，想达标还是有难度的，有时候不亲身下一线又怎知一线的苦呢？要求多，告警多，给一线资源直接干满，又谈何优化提升呢？

    所以一开始定目标的时候一定要掂量掂量，然后最重要的一点就是目标要大家一致认可，并定期回顾复盘，分析差距，才能一致为其而努力，同时目标需要可度量且有了度量方式后要尽可能的去做到自动化而非人为统计，因为人为统计难免出错或者存在其他各种统计口径不同的问题。

    我们这里主要更多关注的还是MTTR，MTTR我们的计算方式是当告警工单被创建时的时间视为开始，告警工单经过二线复核后关闭视为结束，当然还会有部分告警虽然二线关闭了但是在告警晨会或复盘会仍有可能对告警重新驳回重新处理则按最终关闭时间计算为处置时间。

MTTR度量

MTTR（Mean Time To Respond）通常指的是从检测到安全事件或威胁到开始响应所需的平均时间;

    MTTR 更常见的含义是 Mean Time To Repair 或 Mean Time To Recovery 或 Mean Time To remediation （“缓解”）而我们这边告警运营更多还是度量到缓解，至于修复后恢复则是进入到了应急响应的流程后去度量，例如有个系统被漏洞攻击了，告警运营的MTTR度量的区域是从发现被告警，到阻止了攻击，找到对应的攻击点，做好阻断和相对应的缓解措施后，告警运营则闭环，至于后续的漏洞修复和其他的溯源分析等则是进入相对应的应急响应流程中去度量。

度量方式：

总工单处置时间=所有工单各自结束时间-所有工单各自开始时间，MTTR=总工单处置时间/总工单数。

收益：

有了这个数值，我能明确的去观察到每个月的变化，并去分析其中相对异常处置时间的工单的异常原因；同时就算指标正常同样会对所有工单的处置时长做个排序，去分析最快和最慢处置的个别工单，分析是否有需要去持续提升或者优化的点。

MTTD度量

"MTTD" 通常指的是 "Mean Time To Detection"，即平均检测时间。这个可能在不同地方不同公司不同的人会有不同的用法。而我能想到的几个场景度量这些指标的话有几个：

1、特定的事件：在最后因为随着规则更新或者其他方式发现的告警，去复盘分析现有安全设备检测为何检测不到，为何检测慢了，分析差距去提升MTTD；

2、培训和意识提升：提高员工的安全意识，使他们能够更快地识别和报告可疑行为，这也是缩短 MTTD 的重要因素；

3、有效性验证：设备验证失效了，到你恢复你设备检测能力的时间。

其他的我暂时没有很多想法，可能如果有缘人有读到这个文章，再一起交流分享下你们的经验。

4、业务OR外部：业务自行上报的异常钓鱼事件，但却没被监控告警出来的与整体自行发现的风险做计算来统计出对应的MTTD；外部通报过来的异常外联或漏洞风险，如监管通报你有漏洞或木马外联行为，再与内部告警处置和渗透测试的结果做对比。

5、情报运营：这个是笔者近期突然想到的，但有没有用还待论证；例子就是日常我们情报运营小组会给我们收集来很多漏洞、病毒、IOC等情报，那么当我们接收到这个情报的时候，如果我们的设备本来不能去监测和发现这些特征，那我们从获取情报到设备完成更新相关情报以达到防护策略的这个区间的时间来作为MTTD。

    这是我拍脑袋简单整理的告警运营相关的简易版小房子，有些细节可能会遗漏，大家有空可以给我提提建议和补充补充，来帮我装修下我的房子，同时房子看着貌似五脏俱全，但是由于摸着石头过河的运营者（笔者）还是存在豆腐渣工程需要持续去加固的；

    笔者接触安全运营的时候的初心如lake2的一句话所说：把安全系统真正用起来，发现安全系统的问题，不断去优化安全系统，提升系统能力最终解决安全风险，就是安全运营的核心思想所在。

运营中常见问题&痛点

    下面就是日常在告警运营中常见的一些痛点，都是笔者在这几年运营所经历的。

1、覆盖率&设备健康度：

    告警的输入大部分来源于公司买的或者自研的安全设备去检测，那么只有你的系统能持续健康且覆盖全面才可以去检测到风险，你才有办法去做后面的运营工作，否则当你遇到一个告警时，当你要去关联性分析，去流量设备、去HIDS等设备，结果发现这没覆盖那没覆盖，要个日志都费劲的时候，这个告警基本处置下去就十分困难了，所以最基础最重要的也是这点，而我这确实很感谢我们基础安全组的同事帮我们承包且保障了这方面的工作，不过这项工作确实是十分耗时耗精力的，例如安全代理或流量等都有可能因为网络管理员或者系统管理员的变更而导致失效。

2、告警处置疲劳：

    当一线处于海量告警处置疲劳的时候，可能会对告警产生时的敏感度持续下降，而且日常可能处理更多的是内部业务的正常操作行为，或者确实有相关的业务需求需要临时用到一些工具、代理转发、命令执行等操作；一线的同学们处理多了后容易把大部分告警都往这个角度去猜测，降低了一些告警的处置优先级，这样总有一天如果有个真实的攻击事件可能就会被忽视而未能及时阻止危害的扩散。

3、人员能力：

    告警处置往往会处理到很多攻击类的告警，而对于这些攻击类的告警如果设备能明显的给你标识出具体命中的策略，那告警处置人员还是相对容易去发现并处置的，但有时部分设备没法给你标识出来，那就要依赖告警人员自身能力和学习能力了，否则有可能就会把一些真实存在攻击特征但是又涉及了运营人员的知识盲区时，可能就会被误判为误报了，我就真实复核过一次这样的事情。

4、告警误报率高：

    每个安全设备都有误报，规则误报和IOC误报等等，而当这些误报多了后，告警运营基本就运营不下去了，海量误报淹没了真实攻击、海量误报让一线同学直接麻木到想放弃处理，更别说去优化策略了，直接陷入死循环；而此时可能重点就是要去做降噪了。

5、难以持续的热情：

    不管是安全运营还是告警运营，一直埋头苦干而不偶尔抬头看看路确实容易迷茫并质疑自己之前做制定的目标，同时在工作上可能也会有很多的事情影响着你，所以如何去形成一个互相学习提升，互相背靠背的小组也是值得深思的！

    有了上面提到告警运营简单的一个逻辑架构，那么如何去高效的运转起来呢？其还是围绕着资产、风险、人、工具、流程；

知己知彼，才能百战不殆

资产：这里的资产指的就是一家公司他所拥有的所有资产，当然我们也没办法去做到非常细因为资源有限，需要利用有限的资源去创造更大的价值，那么我们就需要去关注核心资产、核心业务所关联的"资产"，只有明确了我们需要保护的核心业务及资产，才能更好的去把识别其可能面临的风险、挖掘出潜在的风险提前去做好应对，这个叫做"知己"；

风险： 风险其实就是"知彼"，除了对于已知的历史风险漏洞、供应链问题、木马特征等，还是需要持续性的获取到最新的风险，且快速的去匹配公司可能受影响的资产，赶在风险被利用的前面修复它，避免核心资产、业务受到影响，故拥有一支优秀的情报小组也是十分重要的，并且能做到持续学习，持续提升，毕竟每天都在产生大量的漏洞和其他潜在的风险；

人尽其才，物尽其用

    对于所有设备，作为告警运营的负责人，对于前面提到的资产和风险，那么这里的物就是需要你去思考，每个设备到底有啥能力，它所覆盖的范围是什么，在哪些场景下你能去充分的使用它。如：有些HIDS产品或者监控agent能去监控系统的补丁，对于熟悉产品能力的人能结合这个去把派发下去的漏洞工单做自动化关联，如果显示补丁打了就自动关单；不熟悉产品能力的人却需要等系统负责人截图证明，那要是系统负责人处理了后忘记提交工单复核，你还需要一个个去问。故对于一个设备，尽管你不需要去深入了解它的检测原理，但是它具备什么能力，它的定位是什么都值得去深思并做好相对应的规划，才能做到物尽其用！

    而想对于lake2前辈的一个补充就是人，因为我也是一个从一线逐步成长到二线的人，所以这点有所感触吧，其实对于把安全系统真正用起来，不断去优化，大多还是要靠人，现在很火的AI其实也还有很长一段路才能去成熟的辅助；

    所以想要做好这点，人暂时还是前提，那么除了对于整个小组成员的共同提升（定期分享、组织复盘）以及个别较为自觉的主动提升外；我更喜欢的是去倾听一线的声音，辅助一线分析他们所遇到的问题，并站在更广的视角去给他们寻求资源和解决方案来共同提升整个小组的能效；

流程高效，持续提升

    前面大概的介绍了资产、风险、人、物，那么把这些东西串起来并高效运转、持续的提升就是流程或会议了；

这里简单分享下我们认为相对有比较多辅助于我们告警小组提升的流程或会议。

自动化需求收集会议：定期对现有或者近期新增的安全设备（能力）、告警响应流程等做分析，看看是否可通过自动化来对现有的流程做优化或能力关联运用，做到提质增效；

告警分类分级： 对从设备产出的告警，通过告警的攻击来源、受害范围、攻击类型、资产等级几个做对应的权重，在每个设备告警吐出来后通过SOAR去做计算给出对应告警的权重值，越高的值越需要重点去及时响应，避免被其他低中危风险影响到真实存在且严重的风险对业务造成影响，而权重低的可以放后确认，做好抓大放小；

白名单（例外）流程： 前面提到告警可能会有大量误报或者已知风险但已经过领导层认可表示风险可接受的告警重复出现、又或者是临时需要使用且能接受风险的中低风险的持续告警，这都会影响整个告警组处置告警的效率，毕竟单单都需要反馈和复核，那么白名单流程就是临时或永久对规则做 白名单（例外），并定期组织复盘对原定的白名单在现在是否仍需执行，是否要对该策略做优化，策略优化是否解决了这块告警噪音，如果是则取消原定的白名单策略，避免相关被误用而导致风险行为未能被监测，持续做好降噪增效；

告警复盘： 告警可能可以分为个别告警复盘或者对全局告警回顾，至于这个时间多久一次可能就见仁见智了，而复盘我建议是当天如果出现较为重大的告警响应，应在当天告警处理的差不多的时候，及时把整个小组拉齐做复盘，一方面互相分享排查思路，一方面就是分享下排查过程中流程、相互配合、思路、工具等是否存在问题，是否可以优化提升，同时也能分析出是否有遗漏的风险需要去做进一步确认，注意最好是当天，笔者就尝试过这样做，上午发生的告警，在下午忙的差不多的时候组织大家共同复盘，复盘后大家都认为收获满满同时经验较少的人也能通过此次复盘汲取到经验较为丰富的人的排查思路，做到人的能力共同提升，同时流程、工具也有可能会在这个环节做到持续提升；

拥抱变革技术，解放双手，激发创造力

    AI大模型，是这段时间很火，也是很多个乙方厂商开始推广的新产品了，但是可以看到有些人对于把AI应用到安全的场景并不清晰且做出来的效果并不理想，只能说有但不好用或者没人用，这就是行业内经常看到的PPT功夫了（甲乙双方都有这个问题，披着狼皮的羊罢了），所以对于AI的应用也是需要思考清楚做出来的功能的定位、解决的问题、投入产出比，毕竟算力那些资源又不是一笔小数目。

应急响应能力提升，从告警迈向应急

    当需要应急的时候往往都是影响较大且是你面临真正的对手时的实战了，而上面讲的告警相关的内容并没法保证当你遇到实战时就能从容的去应对应急响应，所以在应急方面也同样需要有完善的预案涵盖组织、流程、工具，并且能在日常中找机会组织红蓝对抗或外部厂商资源来做实战演练并及时复盘，才能在真实的对抗来临时就算做不到从容也不至于那么慌张。

    在自己工作的这几年中，从懵懂到了解安全运营到接触安全运营学会了很多，分享给大家几句偶尔当自己在安全运营中迷茫的时候能勉励自己的几句话。

    1、“关注未知”是尽责的运营和优秀的运营的重要区别 ——而我就是认为优秀的运营符合我的价值观，我才选择了运营；

    2、"埋头苦干久了，适当抬头看看路"，这句话原话我忘了，但是我想再根据自己理解再补充多一句话，"并选择正确的路，尝试坚持的走下去"，毕竟看到了十字路口你也不能乱拐；

    3、"以实干、创一流"，切莫搞表面功夫，虽然往往PPT做的好比你做实事更重要，但是骗别人可以，别把自己也给骗了