竞品分析历程

Posted 2021-09-09 huim

一 历程

持续了一个季度的竞品分析。
扫描器的竞品分析，一开始觉得只是简单的上个靶场比较效果、补充插件就好了。
现在想想为什么能做一个季度？

1 简单版本

刚开始的一个月，在于上简单的靶场，挨个扫描器轮番测试一遍。

2 靶场切换语言与框架

由于靶场不止适用于扫描器，也得和代码审计一起，避免重复开发靶场，白盒召回也能给扫描器提供场景，又用公司的WF框架设计了靶场。

3 从靶场场景的丰富到靶场

首先从AWVS的插件代码、其他扫描器展示的能扫描的漏洞中，综合了一遍，挑选出了各扫描器能扫描的通用漏洞的交集。
但又出现了一个问题，同样是sql注入，有简单的get型回显注入，也有path型的盲注等等。
同一漏洞类型的场景丰富程度也不同。
以sql注入举例，数据来源有get参数、post参数、json形式的post数据、甚至header等位置；过滤拦截方式有过滤单引号、过滤双引号、过滤括号、过滤select/union等；sink点(触发)的方式有select/inject/update/order by/limit等不同的位置。
这几个维度都是想乘的关系。把这些场景都挨个写出来，会作大量的重复工作。
于是把靶场划分成了 来源/过滤方式/触发方式/输出方式，定了几个基于公司WF的靶场框架，尽量做到补充一个触发方式，搭配一下来源/过滤方式/输出方式，自动形成多个路由。
这一点又做了一个月。
​

4 功能上

第一个月把几个扫描器中我们没有的功能挑了出来，再看了一遍必要性和可行性，指定了这个Q的OKR。
到开始写报告的时候，发现功能对比这一项真是老大难问题，对比，当然不能只挑没有的功能(那是为了知道以后要做什么，但没法证明当前我们做的程度)
于是开始一个一个扫描器把全部功能捞出来，再根据开发和产品经验划分功能模块，把每个扫描器的功能分一分。
又重新挑选出来没做的功能。
零零散散总算到了现在快完结的时候了。
​

二 经验

以补充功能、证明我方产品效果的竞品分析，有两条线
功能、效果

1 功能

(1 捞出所有产品的功能

这里捞的功能，不仅仅只是前端交互层看到的功能，也要有深入交互层下的功能。
比如，从一个产品的功能上，大致地去猜测引擎的实现方式。比如awvs记录了有漏洞的请求包和响应包，这里说明了awvs可能也有一个统一的发包收包功能。而某扫描器复测时的时间能比正常扫描的时间快，说明复测时发包量少，扫描任务的最小单位可能是请求，这个是涉及到引擎底层架构的功能和需求(低代码化)。

(2 按照开发与产品经验来划分功能模块

用户管理模块、系统设置模块、日志模块、任务模块、规则模块等等。

(3 给每个模块划分二级功能

划分二级功能，划分的时候看看这些划分如果放在导航栏是否合理。按功能划分二级功能模块，而不是用心去感受。

(4 根据功能的有无描述

竞品分析的产品比较多，超过了2个。
那么，两个或两个以上的产品有的功能，是共有的功能，这些功能都填到表里。
表的第一列是一级功能模块，第二列是二级功能模块，三四五列则为产品是否有该功能。
对于特有的功能(只有一个产品有)，挑选出来单独讲。

(5 根据功能的实现方式描述

同样是控制QPS的功能，有的扫描器是同一域名设置了50，有的是根据服务器的响应时间来控制，而甲方的是结合了甲方内部的资源控制。同样的功能，不一样的实现方式有不一样的效果。个人认为，有亮点的实现方式也要挑出来讲。

(6 我方产品的补充

我方的产品，有缺失的功能，有共有的功能，有独有的功能以及共有功能中有亮点的。
缺失的功能，需要描述需不需要做、大概是个什么计划。
共有的功能描述是实现方法。
亮点功能和独有的功能挑出来重点描述。
​

文档正在补充中，等待编写完毕再来修改这里的内容
​

2 效果

(1 样本库

对于安全产品来说，就是靶场/样本库与检测
NIDS/HIDS/DAST/SAST/IAST的样本库建立。
样本库作为裁判，需要有维度，通过维度尽量去丰富靶场，尽量公平。

(2 精准率

(3 衡量与补充

在有相对公平的裁判的前提下，使用各个产品，得出精准率。
再补充自己的产品的规则。
最后得到效果表格。
​

靶场作为裁判，制定场景时要脱离产品，不能考虑大家都没有那就不做了、自家的没有也不做了。尽量避免裁判与运动员一体的情况。
​

三 其他

做的时候，试一下换位思考，转移到看报告人的角度，这样的报告是否可看(额外的，老板可能会看个三五分钟，有点高考作文阅卷的感觉。框架怎么设计才能简明扼要一些)
​

​

​