转载请标明来源：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/
简而言之，简化规则编写的流程
规则的编写人员和漏洞的运营人员是分开的。
正式上线的规则产出的漏洞可以转交给运营人员，这部分应该是误报率极低、可人工运营的漏洞；
而测试状态的规则，比如新漏洞曝光、编写规则扫描全内网看看误报率漏报率如何，这是是测试状态，漏洞不直接运营。
而测试规则转为正式规则，则需要清空测试库的漏洞结果、或者将测试漏洞表的结果转移到正式漏洞表。
新增一个规则，后续会不断的随着运营遇到的问题（业务用其他方式修复了但仍检出的误报、poc不全导致的漏报、漏洞结果体验不够友好等）而不断优化规则，会在同一个规则上迭代不同版本。
不同版本的对比，应能逐行对比不同的部分，其实用gitlab等管理是挺好的，更新修改的部分展示明确、各方面的记录都很齐全，免去很多不必要的开发量。
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.1 运行时长/请求量指标
在性能篇中提过，计算规则每个任务的运行时长、http/socket的请求发送量，设置一个阈值，平均值超过则报出
主要针对有的规则比如nmap 扫描全端口指纹、sqlmap拉满、socket没有设置timeout会运行很长一段时间；有的弱口令设置检测列表设置太过复杂(账密使用频率极低)，会有很多没必要的请求，占用时间且可能对被扫描方造成压力。
- 3.2.2 运行报错指标
规则报错在n小时内处理。
引擎端需要把报错给出并通知(微信/内部通信软件/短信等)，处理时间可以按照报错首次和最后一次出现的时差计算。
没有明确指标情况下， 规则报错但不处理的情况会有一些，影响产出，或者引擎性能。
为什么有了流量去重，还要进行漏洞去重？
流量去重并不能替代漏洞去重，漏洞去重与漏洞状态相关联。
对于同一条流量或者同一个IP/端口资产，会进行不止一次的扫描。可能第一次扫描没有漏洞，但之后这个接口因为某次上线多了一个注入，或者某个redis端口密码改成了弱口令等。所以流量不能只扫描一次，url流量需要有去重缓存窗口，资产漏洞扫描也需要有定时周期任务。
未修复状态的漏洞(还没确认/已确认未流转到业务线/业务线收到但还没修复)，重复时不产生新漏洞，只有已经修复了(漏洞又产生了)/已经忽略了(规则没优化完全)才会产出重复漏洞。
漏洞重复的标准：
主机资产类漏洞， 去重根据 IP+端口+规则类型(规则类型可以是这个规则的唯一key、不管多少个迭代版本但唯一的key或token，也可以是这种漏洞的CWE类型)
url类型，去重根据 url去重归一key+规则类型
有部分规则产出的漏洞，误报率极低，人工运营状态下也不需要进行多少验证操作，可以直接设置成漏洞自动确认状态：漏洞产出后直接确认。
可以在规则列表页里加一列滑动单选按钮。
运营人员处理某类漏洞时，确定误报率极低、人工验证操作极少，点开就好了
漏洞自动发送到业务线：需要注意两个细节
1 漏洞对接到集群与处理人
有一套找集群的程序，url可以根据nginx找到最后转发的集群，IP可以根据cmdb配置找到集群；再根据集群确定需要对接的漏洞处理人。
2 漏洞聚合发送
一个集群下可能存在多个机器，或者有一些重复流量对应到同一个接口。有时候漏洞往往是成复数出现，比如同一个redis集群下，每十分钟扫描出一个redis弱口令，弱口令还都一样。
面对这种情况，作为业务线其实并不希望漏洞一个一个发、消息一个一个弹。
所以需要根据 集群+规则 作聚合，把这些漏洞都放到一个工单里。又因为一个集群的漏洞并不是一下子都出来，需要设置聚合时间窗口，比如每4小时/6小时/12小时/24小时聚合一次，时间长了漏洞利用时间可能延长，时间短了会有多个工单，窗口时长需自己衡量。
漏洞推送到业务线，需要让业务知道漏洞有什么危害、可以怎么利用、怎么验证，最重要是怎么修复。
poc的信息有有一些是面对业务线的，有一些是给运营人员看的。比如侧信道方式的漏洞，可能需要添加扫描子任务唯一标识uuid信息，用于有问题需要详细验证的时候找找具体的流量。比如xss，可能需要添加xss的payload是针对那种html类型的编号，这种业务看不懂也不想看。而可利用的xss链接这种才是业务想直接看到的。
所以poc字段可以设置两种类型，一种会展示到业务可见的工单，一种业务不可见仅安全运营人员可见。
每一个规则都得有对应的漏洞类型，多对一的关系。每种漏洞类型，得有漏洞描述/漏洞利用场景/漏洞复现方式/漏洞修复方案，也就是需要一个漏洞文库，用于与规则关联，与工单关联，沉淀团队内的漏洞信息，给业务线做漏洞展示。
SRC的漏洞复测可能需要人工参与，而DAST的漏洞都可以做自动复测，业务提交复测需求后，由扫描器重放流量，测试漏洞是否存在，不存在就直接关闭工单。
至此规则产出的漏洞可自动确认、自动发送工单、自动关闭工单，运营人员可专注于规则的编写，后续的流程都自动实现。
5.1 个人漏洞平均处理时长漏洞需要流转到业务线，并且修复，才能算作有用的产出
有部分误报率已经尽可能优化但还无法确保无误报的规则，产出的漏洞需要人工验证。所以需要计算分配到个人的漏洞从发现到处理的平均时间，设置个人指标 小于n小时。
大量堆积的待处理漏洞，超过半个月一个月，会有部分漏洞不存在了(比如机器关了、端口换了、接口下了)，发送给业务线就需要再确认一遍，而且没发送给业务线的漏洞也就是单纯自娱自乐用的。
漏洞发送到业务才计算处理时间，但不确认或者确认了不发工单不就好了， 所以需要处理率限制，以一个季度为准，季度结束时个人所分派的漏洞，需要100%确认/忽略，并且确认的漏洞需要通过工单的形式发送/流转到业务。
0X06 系列终篇至此自动化漏洞扫描器系列短暂结束了，陆陆续续写了一个月，算了算大概一万八千字。很早就想总结，终于写完了。
从流量、规则，到引擎以及项目成熟稳定后的持续化运营，这3/4年涉及到的或多或少都有讲述，算是对产品经验的总结。
而完整做完一套产品，转移到另一套产品，其实并没有太大难度，有很多都是思考方式与设计方式都是相似的，比如流量+规则+引擎+结果运营的核心模式。
当然还有一部分没有写到，比如生态级互联网企业中，把扫描器封装成只提供服务的产品、给业务BP使用的相关功能(一般是SAAS模式)；把扫描器封装成独立部署的硬件产品相关功能。
不过核心思考都是这些方面，不变的是核心功能与流程，变化的是用户交互界面功能。针对不同场景可以有不同的web控制平台，对接到同一套引擎 (引擎兼容设计变化较大的可能是任务调度、无害处理这方面)。