DAST 黑盒漏洞扫描器 第六篇:运营篇(终)
- 2022 年 6 月 27 日
- 筆記
- DAST 黑盒漏洞扫描器
0X01 前言
转载请标明来源://www.cnblogs.com/huim/
当项目功能逐渐成熟,同时需要实现的是运营流程和指标体系建设。需要工程化的功能逐渐少了,剩下的主要工作转变成持续运营以及功能迭代优化。
个人认为,项目应该以运营为目的推动工程化。至少,安全和开发的需求五五开,分隔开,避免项目建设都投在了工程化上而忽略了产出、以及真正的确切需求。
有过一段时间,专注于各方面功能开发,但没有着重在运营上,等季度末结算的时候,功能都已完成,但是漏洞产出却要赶。有的功能虽然做了,但并不直接提升产出。
但也因此,大多数功能都已经趟过,产品功能也相对成熟。随着人数的补充,重心从工程化开发转移到运营,也不会因为过多不成熟的功能设计而造成阻拦。
扫描器涉及到运营的主要是规则和漏洞
0X02 规则运营工具类功能
提高运营效率
2.1 规则编写:规则SDK
各家产品规则格式不一致,但是开发规则的时候肯定不能拿着引擎做测试,引擎太重了。
需要精简引擎,抽取出能让规则运行的核心代码,如AWVS
//www.acunetix.com/download/tools/WVSSDK.zip
又或者像xray 表达式类插件,有可视化的规则界面
//phith0n.github.io/xray-poc-generation/
简而言之,简化规则编写的流程
2.2 规则测试:测试流程
规则的编写人员和漏洞的运营人员是分开的。
正式上线的规则产出的漏洞可以转交给运营人员,这部分应该是误报率极低、可人工运营的漏洞;
而测试状态的规则,比如新漏洞曝光、编写规则扫描全内网看看误报率漏报率如何,这是是测试状态,漏洞不直接运营。
而测试规则转为正式规则,则需要清空测试库的漏洞结果、或者将测试漏洞表的结果转移到正式漏洞表。
2.3 规则迭代:历史版本记录与比对
新增一个规则,后续会不断的随着运营遇到的问题(业务用其他方式修复了但仍检出的误报、poc不全导致的漏报、漏洞结果体验不够友好等)而不断优化规则,会在同一个规则上迭代不同版本。
不同版本的对比,应能逐行对比不同的部分,其实用gitlab等管理是挺好的,更新修改的部分展示明确、各方面的记录都很齐全,免去很多不必要的开发量。
0X03 规则运营指标与规范
运营指标相关,在指标规范下,保证项目产出。项目本身已经有大指标了,落实到具体安全人员身上的是运营指标。
3.1 规则编写相关指标与规范
- 3.1.1 0day应急时间 <= n小时
保证0day应急时间,0day应急其实是扫描器的一大重要功能,从攻击者视角发现易受攻击面的漏洞,高ROI的收敛风险。缺乏指标,可能0day出现后过一周两周才有响应,已经过了应急的黄金时间。
0day来源参考规则篇中的漏洞预警,每一个事件/漏洞计算处理时间、标记处理状态,最后计算个人平均响应与处理时间,落实到个人指标上。 - 3.1.2 漏洞召回时间 <= n小时
漏洞召回主要是对外部第三方提交的漏洞进行召回,如SRC/补天等,排查扫描流程与规则中的漏报原因。
召回需要查看逐流程跟进流量走向,要么提供召回的标准,这点在实践时对安全人员要求比较高,需要稍微熟悉扫描引擎的流程,才能根据文档排查出原因;要么做自动化,自动查询流量在每个步骤中的状态,输出没有到规则这一步的原因。
因白名单与规则原因漏报的指定运营人员处理;因bug问题导致缺流量、过程漏掉流量的指定开发人员排查。
规定 n小时内响应排查出原因,n天内处理完毕可以扫描出该漏洞或者归档不可解决的漏报原因。 - 3.1.3 代码规范
对插件编写需要代码规范,代码风格诡异,沉淀下来的规则交接成本挺大。
在代码上传处,可设置简单的自动化代码检测功能,检测到不符合规范的代码,报错拒收。
3.2 规则维护相关指标与规范
- 3.2.1 运行时长/请求量指标
在性能篇中提过,计算规则每个任务的运行时长、http/socket的请求发送量,设置一个阈值,平均值超过则报出
主要针对有的规则比如nmap 扫描全端口指纹、sqlmap拉满、socket没有设置timeout会运行很长一段时间;有的弱口令设置检测列表设置太过复杂(账密使用频率极低),会有很多没必要的请求,占用时间且可能对被扫描方造成压力。
- 3.2.2 运行报错指标
规则报错在n小时内处理。
引擎端需要把报错给出并通知(微信/内部通信软件/短信等),处理时间可以按照报错首次和最后一次出现的时差计算。
没有明确指标情况下, 规则报错但不处理的情况会有一些,影响产出,或者引擎性能。
0X04 漏洞运营工具类功能
4.1 漏洞去重
为什么有了流量去重,还要进行漏洞去重?
流量去重并不能替代漏洞去重,漏洞去重与漏洞状态相关联。
对于同一条流量或者同一个IP/端口资产,会进行不止一次的扫描。可能第一次扫描没有漏洞,但之后这个接口因为某次上线多了一个注入,或者某个redis端口密码改成了弱口令等。所以流量不能只扫描一次,url流量需要有去重缓存窗口,资产漏洞扫描也需要有定时周期任务。
未修复状态的漏洞(还没确认/已确认未流转到业务线/业务线收到但还没修复),重复时不产生新漏洞,只有已经修复了(漏洞又产生了)/已经忽略了(规则没优化完全)才会产出重复漏洞。
漏洞重复的标准:
主机资产类漏洞, 去重根据 IP+端口+规则类型(规则类型可以是这个规则的唯一key、不管多少个迭代版本但唯一的key或token,也可以是这种漏洞的CWE类型)
url类型,去重根据 url去重归一key+规则类型
4.2 漏洞自动确认
有部分规则产出的漏洞,误报率极低,人工运营状态下也不需要进行多少验证操作,可以直接设置成漏洞自动确认状态:漏洞产出后直接确认。
可以在规则列表页里加一列滑动单选按钮。
运营人员处理某类漏洞时,确定误报率极低、人工验证操作极少,点开就好了
4.3 漏洞自动发送
漏洞自动发送到业务线:需要注意两个细节
1 漏洞对接到集群与处理人
有一套找集群的程序,url可以根据nginx找到最后转发的集群,IP可以根据cmdb配置找到集群;再根据集群确定需要对接的漏洞处理人。
2 漏洞聚合发送
一个集群下可能存在多个机器,或者有一些重复流量对应到同一个接口。有时候漏洞往往是成复数出现,比如同一个redis集群下,每十分钟扫描出一个redis弱口令,弱口令还都一样。
面对这种情况,作为业务线其实并不希望漏洞一个一个发、消息一个一个弹。
所以需要根据 集群+规则 作聚合,把这些漏洞都放到一个工单里。又因为一个集群的漏洞并不是一下子都出来,需要设置聚合时间窗口,比如每4小时/6小时/12小时/24小时聚合一次,时间长了漏洞利用时间可能延长,时间短了会有多个工单,窗口时长需自己衡量。
4.4 漏洞推修信息
漏洞推送到业务线,需要让业务知道漏洞有什么危害、可以怎么利用、怎么验证,最重要是怎么修复。
poc的信息有有一些是面对业务线的,有一些是给运营人员看的。比如侧信道方式的漏洞,可能需要添加扫描子任务唯一标识uuid信息,用于有问题需要详细验证的时候找找具体的流量。比如xss,可能需要添加xss的payload是针对那种html类型的编号,这种业务看不懂也不想看。而可利用的xss链接这种才是业务想直接看到的。
所以poc字段可以设置两种类型,一种会展示到业务可见的工单,一种业务不可见仅安全运营人员可见。
每一个规则都得有对应的漏洞类型,多对一的关系。每种漏洞类型,得有漏洞描述/漏洞利用场景/漏洞复现方式/漏洞修复方案,也就是需要一个漏洞文库,用于与规则关联,与工单关联,沉淀团队内的漏洞信息,给业务线做漏洞展示。
4.5 漏洞自动复测
SRC的漏洞复测可能需要人工参与,而DAST的漏洞都可以做自动复测,业务提交复测需求后,由扫描器重放流量,测试漏洞是否存在,不存在就直接关闭工单。
至此规则产出的漏洞可自动确认、自动发送工单、自动关闭工单,运营人员可专注于规则的编写,后续的流程都自动实现。
0X05 漏洞运营指标
漏洞需要流转到业务线,并且修复,才能算作有用的产出
5.1 个人漏洞平均处理时长
有部分误报率已经尽可能优化但还无法确保无误报的规则,产出的漏洞需要人工验证。所以需要计算分配到个人的漏洞从发现到处理的平均时间,设置个人指标 小于n小时。
大量堆积的待处理漏洞,超过半个月一个月,会有部分漏洞不存在了(比如机器关了、端口换了、接口下了),发送给业务线就需要再确认一遍,而且没发送给业务线的漏洞也就是单纯自娱自乐用的。
5.2 个人漏洞处理率
漏洞发送到业务才计算处理时间,但不确认或者确认了不发工单不就好了, 所以需要处理率限制,以一个季度为准,季度结束时个人所分派的漏洞,需要100%确认/忽略,并且确认的漏洞需要通过工单的形式发送/流转到业务。
0X06 系列终篇
至此自动化漏洞扫描器系列短暂结束了,陆陆续续写了一个月,算了算大概一万八千字。很早就想总结,终于写完了。
从流量、规则,到引擎以及项目成熟稳定后的持续化运营,这3/4年涉及到的或多或少都有讲述,算是对产品经验的总结。
而完整做完一套产品,转移到另一套产品,其实并没有太大难度,有很多都是思考方式与设计方式都是相似的,比如流量+规则+引擎+结果运营的核心模式。
当然还有一部分没有写到,比如生态级互联网企业中,把扫描器封装成只提供服务的产品、给业务BP使用的相关功能(一般是SAAS模式);把扫描器封装成独立部署的硬件产品相关功能。
不过核心思考都是这些方面,不变的是核心功能与流程,变化的是用户交互界面功能。针对不同场景可以有不同的web控制平台,对接到同一套引擎 (引擎兼容设计变化较大的可能是任务调度、无害处理这方面)。