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 黑盒漏洞扫描器 第六篇:运营篇(终)的更多相关文章
- DAST 黑盒漏洞扫描器 第二篇:规则篇
0X01 前言 怎么衡量一个扫描器的好坏,扫描覆盖率高.扫描快.扫描过程安全 而最直接的效果就是扫描覆盖率高(扫的全) 怎么扫描全面,1 流量全面 2 规则漏报低 流量方面上篇已经讲过,这篇主要讲扫描 ...
- DAST 黑盒漏洞扫描器 第四篇:扫描性能
0X01 前言 大多数安全产品的大致框架 提高性能的目的是消费跟得上生产,不至于堆积,留有余力应对突增的流量,可以从以下几个方面考虑 流量:减少无效流量 规则:减少规则冗余请求 生产者:减少无效扫描任 ...
- DAST 黑盒漏洞扫描器 第五篇:漏洞扫描引擎与服务能力
0X01 前言 转载请标明来源:https://www.cnblogs.com/huim/ 本身需要对外有良好的服务能力,对内流程透明,有日志.问题排查简便. 这里的服务能力指的是系统层面的服务,将扫 ...
- DAST 黑盒漏洞扫描器 第三篇:无害化
0X01 前言 甲方扫描器其中一个很重要的功能重点,就是无害化,目的是尽量降低业务影响到可接受程度. 做过甲方扫描器,基本上对于反馈都有所熟悉. "我们的服务有大量报错,请问和你们有关么&q ...
- web网络漏洞扫描器编写
这两天看了很多web漏洞扫描器编写的文章,比如W12scan以及其前身W8scan,还有猪猪侠的自动化攻击背景下的过去.现在与未来,以及网上很多优秀的扫描器和博客,除了之前写了一部分的静湖ABC段扫描 ...
- qqzoneQQ空间漏洞扫描器的设计attilax总结
qqzoneQQ空间漏洞扫描器的设计attilax总结 1.1. 获取对方qq(第三方,以及其他机制)1 1.2. QQ空间的html流程1 1.3. 判断是否有权限1 1.4. 2015年度Web服 ...
- [C# 基础知识梳理系列]专题六:泛型基础篇——为什么引入泛型
引言: 前面专题主要介绍了C#1中的2个核心特性——委托和事件,然而在C# 2.0中又引入一个很重要的特性,它就是泛型,大家在平常的操作中肯定会经常碰到并使用它,如果你对于它的一些相关特性还不是很了解 ...
- 仿百度壁纸客户端(六)——完结篇之Gallery画廊实现壁纸预览已经项目细节优化
仿百度壁纸客户端(六)--完结篇之Gallery画廊实现壁纸预览已经项目细节优化 百度壁纸系列 仿百度壁纸客户端(一)--主框架搭建,自定义Tab + ViewPager + Fragment 仿百度 ...
- 6. Vulnerability scanners (漏洞扫描器 11个)
Nessus是最流行和最有能力的漏洞扫描程序之一,特别为UNIX系统. 它最初是免费的和开源的,但是他们在2005年关闭了源代码,并在2008年删除了免费的“注册Feed”版本.现在要每年花费2,19 ...
随机推荐
- uniapp-uni.setNavigationBarColor 动态修改顶部背景颜色
uni.setNavigationBarColor({ frontColor: '#ffffff', backgroundColor: "#3583ff" })
- 微信小程序 因文件大小不能使用本地背景图片解决方法
因微信文件只允许2m,所以不能给图片太多空间.所以出现背景图片的坑 解决方案1: 把背景图片放到服务器文件件下,直接将路径给url. 得是https开头的路径才可以 解决方案2:将图片转换成base6 ...
- JS_进阶-遍历对象属性、数组输出、Math、正则表达式匹配
1 <!DOCTYPE html> 2 <html lang="en"> 3 <head> 4 <meta charset="U ...
- 『现学现忘』Git基础 — 19、在Git中进行忽略文件操作
目录 1.忽略文件说明 2.忽略文件的原则 3..gitignore忽略规则 4.忽略文件的三种方式 (1)忽略单个仓库中的文件(远程共用) (2)忽略单个仓库中的文件(本地使用) (3)全局忽略 1 ...
- ChCore Lab1 机器启动 实验笔记
本文为上海交大 ipads 研究所陈海波老师等人所著的<现代操作系统:原理与实现>的课程实验(LAB)的学习笔记的第一篇. 书籍官网:现代操作系统:原理与实现,里面有实验的参考指南和代码仓 ...
- Prometheus监控实战应用
目录 1.Prometheus的主要特征及概述 2.普罗米修斯原理架构图 3.下载安装启动Prometheus 4.web客户端操作 5.默认图像 6.目录解释 7.配置文件 8.监控指标 8.1.监 ...
- DOM0级同DOM2级
DOM0级分为两个:一是写在标签内的onclick事件: <button id="btn" onclick="alert('happy')">按钮& ...
- PHP反序列化链分析
前言 基本的魔术方法和反序列化漏洞原理这里就不展开了. 给出一些魔术方法的触发条件: __construct()当一个对象创建(new)时被调用,但在unserialize()时是不会自动调用的 __ ...
- Ubuntu中安装redis
第一种方式在线安装首要前提安装c语言编译环境,命令如下:$sudo apt-get install gcc 安装完成后可以输入$gcc --version查看版本 1.获取源码:$wget https ...
- ASCII&Base64
ASCII https://zh.wikipedia.org/wiki/ASCII American Standard Code for Information Interchange,美国信息交换标 ...