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 黑盒漏洞扫描器 第六篇:运营篇(终)的更多相关文章

  1. DAST 黑盒漏洞扫描器 第二篇:规则篇

    0X01 前言 怎么衡量一个扫描器的好坏,扫描覆盖率高.扫描快.扫描过程安全 而最直接的效果就是扫描覆盖率高(扫的全) 怎么扫描全面,1 流量全面 2 规则漏报低 流量方面上篇已经讲过,这篇主要讲扫描 ...

  2. DAST 黑盒漏洞扫描器 第四篇:扫描性能

    0X01 前言 大多数安全产品的大致框架 提高性能的目的是消费跟得上生产,不至于堆积,留有余力应对突增的流量,可以从以下几个方面考虑 流量:减少无效流量 规则:减少规则冗余请求 生产者:减少无效扫描任 ...

  3. DAST 黑盒漏洞扫描器 第五篇:漏洞扫描引擎与服务能力

    0X01 前言 转载请标明来源:https://www.cnblogs.com/huim/ 本身需要对外有良好的服务能力,对内流程透明,有日志.问题排查简便. 这里的服务能力指的是系统层面的服务,将扫 ...

  4. DAST 黑盒漏洞扫描器 第三篇:无害化

    0X01 前言 甲方扫描器其中一个很重要的功能重点,就是无害化,目的是尽量降低业务影响到可接受程度. 做过甲方扫描器,基本上对于反馈都有所熟悉. "我们的服务有大量报错,请问和你们有关么&q ...

  5. web网络漏洞扫描器编写

    这两天看了很多web漏洞扫描器编写的文章,比如W12scan以及其前身W8scan,还有猪猪侠的自动化攻击背景下的过去.现在与未来,以及网上很多优秀的扫描器和博客,除了之前写了一部分的静湖ABC段扫描 ...

  6. qqzoneQQ空间漏洞扫描器的设计attilax总结

    qqzoneQQ空间漏洞扫描器的设计attilax总结 1.1. 获取对方qq(第三方,以及其他机制)1 1.2. QQ空间的html流程1 1.3. 判断是否有权限1 1.4. 2015年度Web服 ...

  7. [C# 基础知识梳理系列]专题六:泛型基础篇——为什么引入泛型

    引言: 前面专题主要介绍了C#1中的2个核心特性——委托和事件,然而在C# 2.0中又引入一个很重要的特性,它就是泛型,大家在平常的操作中肯定会经常碰到并使用它,如果你对于它的一些相关特性还不是很了解 ...

  8. 仿百度壁纸客户端(六)——完结篇之Gallery画廊实现壁纸预览已经项目细节优化

    仿百度壁纸客户端(六)--完结篇之Gallery画廊实现壁纸预览已经项目细节优化 百度壁纸系列 仿百度壁纸客户端(一)--主框架搭建,自定义Tab + ViewPager + Fragment 仿百度 ...

  9. 6. Vulnerability scanners (漏洞扫描器 11个)

    Nessus是最流行和最有能力的漏洞扫描程序之一,特别为UNIX系统. 它最初是免费的和开源的,但是他们在2005年关闭了源代码,并在2008年删除了免费的“注册Feed”版本.现在要每年花费2,19 ...

随机推荐

  1. 夯实基础上篇-图解 JavaScript 执行机制

    讲基础不易,本文通过 9 个 demo.18 张 图.2.4k 文字串讲声明提升.JavaScript 编译和执行.执行上下文.调用栈的基础知识.

  2. 『现学现忘』Git基础 — 5、Git的协作模式

    目录 1.分布式工作流程 2.集中式工作流 3.分支工作流 4.GitFlow 工作流(最流行) 5.Forking 工作流(偶尔使用) 6.总结 1.分布式工作流程 与传统的集中式版本控制系统(CV ...

  3. java class 文件格式解析

    前言 大约5年前,想研究javaassistant,cglib等字节码操作的相关类库,来对class进行增强,当要到要操作字节码的时候,发现无法继续下去了,只能放弃. 学习jvm字码,需要理解clas ...

  4. 百度AI人脸检测——解析JSON 数据格式

    1.了解一下 通常情况下,每个需要访问网络的应用程序都会有一个自己的服务器,我们可以向服务器提交数据,也可以从服务器上获取数据.不过这个时候就出现了一个问题,这些数据到底要以什么样的格式在网络上传输呢 ...

  5. Ubuntu 下 firebird 数据库的安装和配置

    Ubuntu 下 firebird 数据库的安装和配置 1.简介 本文主要是 Ubuntu 下 firebird 数据库的安装和目录迁移,同样适用于 Debian 系统:Ubuntu 20.0.4 f ...

  6. WinUI使用LiteDB做个女演员图鉴

    为什么选择LiteDB 之前做uwp的时候有做过一个植物图鉴,当时图片使用的是在线图片,所以图片很多也并没有什么体验上的差别,但是直到有一天别人的网站挂掉了,图片访问不到了,当时想访问不到也没啥,反正 ...

  7. CSS一个较为完整的页面布局_可以根据页面屏幕大小调整布局

    1 <!DOCTYPE html> 2 <html lang="en"> 3 <head> 4 <meta charset="U ...

  8. oauth协议原理

    oauth协议关系图(如获取微信用户信息): oauth一般授权步骤:

  9. 【图解】面试题:ConcurrentHashMap是如何保证线程安全的

    注意:JDK1.7与JDK1.8中的ConcurrentHashMap主要延续HashMap的设计与思想,是在其基础上进行的相应优化 1.JDK1.7中的底层实现原理 (1)JDK1.7Concurr ...

  10. Mybatis执行多条SQL

    1:在数据库连接配置文件处,增加如下参数即可:allowMultiQueries=true spring: datasource: url: jdbc:mysql://IP:PORT/数据库名?其他参 ...