基于飞书实现漏洞运营自动化

——漏洞的全生命周期管理，从提交到关闭

本文为作者Steven原创，转载请注明出处

文章仅用于学习目的，请勿用于非法目的

背景

前段时间，基于暴露面管理的需求采购了某家EASM（外部攻击面管理系统），在调用api的时候意外发现利用EASM的漏洞及功能接口可以实现我的漏洞运营自动化场景。于是开始调研我的实现场景。 

方案调研 

一、SOAR 

安全产品中SOAR目前属于是炙手可热的产品，目前有不少数量的金融政企落地了相关的产品及自动化场景。恰好在这个需求之前，雾帜智能开源了他们的社区版SOAR ——Octomation，加上之前个人有折腾过一些SOAR的场景，所以本次使用起来相对上手还是比较快的。
对于安全运营人员，SOAR的上手难度还是有的，APP开发和剧本编写有一定的门槛，且目前的调试机制比较复杂，影响运营人员编写的效率。不支持对自动化剧本的结果分析，没有数据产出，怎么看剧本的效率。此外，有什么想录入存放的数据也没地方放，似乎SOAR产品只是一个统一调用各种API的平台。当然了，我说的这些都是社区版的问题，商业版怎么样我就不清楚了。另外，虽然社区版免费，但是也是需要授权的，而且授权有效期为1年，这么搞我也很惶恐。

二、手撸脚本

既然上面没有存放临时数据或输出运营数据的地方，为什么不自己写个脚本呢？相比之下，脚本调试还快，至于数据，脚本开发起来也不是太难的需求。至少整一个简陋版的，不难还很耐用。但这样的缺点也很显而易见，虽然手撸一串代码实现简单的自动化不难（最少比起SOAR的自动化场景实现不难），但是缺少协作的平台，交互起来不是很方便。再有一个，没有一个集中管理自动化的地方。

三、飞书多维表格

实际上我们在漏洞运营1.0时就用的飞书多维表格了，1.0是在多维表格上集中管理漏洞数据，但是从整体的使用情况来看，在管理数据方面效果还是不错的，且支持手动编辑仪表盘，仪表盘的制作也非常便捷。效果图如下： 

但是在缺少一个自动化流程的情况下，我们运营人员在衔接漏洞发现到漏洞推送的过程中会有延时，漏洞修复时效和漏洞推进修复有延时，不管是漏洞运营人员还是漏洞修复人员都缺少一个提醒，使漏洞闭环。

那么我在探索自动化方案的时候，突然想到了飞书的自动化助手，就上去探索了一下，发现这个多维表格的定位竟然是一个0代码平台，那么根据我的漏洞运营自动化流，飞书能不能满足我的需求呢？ 

上面是一个简化版的流程，基于上面这个流程，我暂时利用飞书多维表格实现了一个自动化流程，后续还有很多值得完善的地方。 

流程1. 更新API接口漏洞 

根据EASM发现的漏洞数据，可以将数据以API的方式写入到多维表格中，效果图如下所示 

流程2. 运营人员漏洞审核确认

EASM扫描的漏洞数据也会有一定的误报率，所以我们对表格添加的结果新增一个自动化助手，当新增漏洞数据时，就给我们发一个确认提醒，效果如下所示： 

点击【确认漏洞存在】按钮时，表格中的【漏洞状态】字段也会从未处置改为处置中，【漏洞误报】按钮会将【漏洞状态】字段改为误报。

流程3. CMDB 调用资产owner 

按照我的理想化流程，这一步应该是要根据资产信息自动找到资产owner的，但实际上企业的资产管理还是有很大问题的。所以这一块如果在找不到资产owner的情况下就会进入【资产管理员查找资产owner】的动作，这个动作会给相应的IT发送一个打开飞书链接的动作（因为多维表格通知这块只有按钮和打开链接的动作，如果有能够在消息界面修改数据这个动作就完美了）

流程4. 资产Owner确认接收漏洞

一旦漏洞处于未修复以及资产Owner字段变更为相应人员时，就会给资产owner发送一个通知确认接收的消息，并告知修复建议及截至修复日期等

流程5.漏洞修复通知 

在漏洞截止修复日期前一天，会给资产owner发送一个通知，询问资产修复进度，并且如果已经修复完成，可以点击【已修复】按钮，这个时候，漏洞状态会变为待复核，同时会给漏洞运营人员发送复核的通知。![[Pasted image 20231116164205.png]] 当然了，在复核这块其实还有一个隐藏的流程，目前还没加进来，那就是多维表格支持发送http请求这个动作，以上的漏洞复核，可以调用EASM的漏洞扫描接口或者自己配置好的扫描器接口进行扫描，如果误报率比较高，可以加入人工干预的流程。![[Pasted image 20231116164314.png]]    

最后，漏洞闭环，输出报表

以上就是大概的漏洞运营自动化流程了，当然了，中间的很多地方都可以加上容错的机制使其更完善。根据上面的流程我们也可以将以下的几点数据输出成报表：
    1. EASM漏洞扫描的误报率
    2. 漏洞处置的忽略率
    3. 漏洞修复及时率
    4. 漏洞推送到确定接收的平均响应时间
    5. 严重、高、中、低的漏洞占比
    6. 各部门的漏洞产出占比
    7. MDDR、MTTR等等指标

第三种方案是基于飞书多维表格单独实现的，也是我目前采用的方案。那么他实现起来的难点在哪里呢？第一步数据导入的时候需要一定的开发工作量（不大）。其他的基本就是点点鼠标，整体算上是完美的解决方案了。倘若有一天，SOAR能够做到低代码，并且完美的剧本编写体验，那就舒服了。

四、飞书集成平台
严格意义上来说，飞书集成平台才算的上是实现编排自动化需求的平台。他的实现方式大体上和其他编排的概念是一样的，但是他的定位是围绕飞书的审批、消息、文档等服务实现编排，比起多维表格支持的功能更多，也更强大，且方便后期的维护。

总结

整体来说，飞书（不管是多维表格还是集成平台）实现漏洞运营自动化的成本确实低了很多，且依赖飞书实现，协作起来更舒服，推进的时候也很方便。需要的技术门槛低只是很小的一个原因，最重要的是他在技术门槛低的情况下，配置还简单，这就很nice了。但是在用飞书实现这个方案的时候，领导给出了这样的几个疑问：    
    1. 用飞书实现这个功能，功劳不归自己，是飞书的；
    2. 用别人管控的平台很难要权限，工作推进会比较慢；
    3. 要权限的时候容易与别人产生冲突；

这个过程中深有体会的是第二点，因为我最初的需求是用飞书集成平台来实现。但是因为飞书集成平台的权限问题和其它部门拉扯了近一周，最后做了，但是现在两周了还没有帮我实现。总之还是蛮无语的。
基于飞书实现一个漏洞运营自动化看起来是个不错的方式，那么如果未来运营堆得自动化场景多了，能实现那么多需求吗？能集中运营好吗？能保证数据安全和稳定性吗？SOAR能实现低代码吗？或许这一切或许值得我们思考。  

B端公司还得加油啊 /doge  

转载请注明出处。 

原文始发于微信公众号（东方隐侠安全实验室）：基于飞书实现漏洞运营自动化