标签：黑盒 运营 DAST 业务 流量 漏洞 需要 规则 第六篇
0X01 前言
转载请标明来源：https://www.cnblogs.com/huim/
当项目功能逐渐成熟，同时需要实现的是运营流程和指标体系建设。需要工程化的功能逐渐少了，剩下的主要工作转变成持续运营以及功能迭代优化。
个人认为，项目应该以运营为目的推动工程化。至少，安全和开发的需求五五开，分隔开，避免项目建设都投在了工程化上而忽略了产出、以及真正的确切需求。
有过一段时间，专注于各方面功能开发，但没有着重在运营上，等季度末结算的时候，功能都已完成，但是漏洞产出却要赶。有的功能虽然做了，但并不直接提升产出。
但也因此，大多数功能都已经趟过，产品功能也相对成熟。随着人数的补充，重心从工程化开发转移到运营，也不会因为过多不成熟的功能设计而造成阻拦。
扫描器涉及到运营的主要是规则和漏洞
0X02 规则运营工具类功能
提高运营效率
2.1 规则编写：规则SDK
各家产品规则格式不一致，但是开发规则的时候肯定不能拿着引擎做测试，引擎太重了。
需要精简引擎，抽取出能让规则运行的核心代码，如AWVS
http://www.acunetix.com/download/tools/WVSSDK.zip
又或者像xray 表达式类插件，有可视化的规则界面
https://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控制平台，对接到同一套引擎 (引擎兼容设计变化较大的可能是任务调度、无害处理这方面)。
标签：黑盒,运营,DAST,业务,流量,漏洞,需要,规则,第六篇 来源： https://www.cnblogs.com/huim/p/16414911.html
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。