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

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

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

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

背景

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

方案调研 

一、SOAR 

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

二、手撸脚本

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

三、飞书多维表格

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

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

流程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]]    

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

总结

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

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