渗透+风险模型+威胁情报（上）

【零】过去那篇文章

这篇文章的基础来自这里：http://www.51testing.com/html/49/n-225449.html；

文章是我2010年写的，原来的BLOG已经死在硬盘里，所以只能找一篇格式编辑还不错的转贴。

这篇文章整体比较杂乱，很多操作思路存在门槛或不成熟，方向和这次也有些差异，但其根基和这篇文章是一样的。

有兴趣就看看，如果嫌长懒得翻，直接看现在这篇也是一样的。

【壹】这次要写的

本想在题目里突显“可操作”三个字，后来我感觉这是个风险活。

毕竟，现实的骨感肯定装不下理想的丰满。

可操作的东西往往会因人力或物力所不及等问题，而不得不有所妥协，这样妥协出来的产物，这恐怕是很多人所不能接受的，所以为了避免开篇一文就被拍过狠，还是去掉这三个字，但从内容上去讲，我还是会更倾向于“可操作”，也会尽量给出我所尝试过的或我所能想象得到的操作思路。

【贰】现在的问题

因为渗透的本质是漏洞，所以我从漏洞入手来分析。

综合常见的一些漏洞评价指标或模型，大概可以总结一下，目前用于量化评价漏洞的维度大概有这么几个：

• 可用性

• 易用性

• 暴露性

• 本地/远程

• 认证情况（是否需认证）

• 影响范围（server端 或 client端）

• 可造成损失（直接 或 间接两个维度）

有些重合的我浓缩在了一起，可能大家理解的会不太一样，但总体应该不会偏离的太严重。

这里显而易见的问题是，这样的指标难以对漏洞所属的环境进行二次评价，从而评价结果往往会被扭曲。这也是为什么很多技术类评估最终以权限大小或影响范围来做简单粗暴评价的原因。

而且，由于缺乏漏洞所属环境的二次评价指标，这也会导致漏洞在业务环境中没有什么“流动性”，既然没有了流动性，其最终结果也必然是没有“持续性”，一个没有持续性的系统自然也无法让“实时性”在其内部施展拳脚。

所以，我觉得有必要选择一种新的交付模式来打破这些。

一是打破环境内的二次评价问题，二则是打破内外对接问题，三是对接的实时性 —— 其实本质上，这三个问题是相辅相成、不可分割的。

所以，这里引入两个解决方案：

• 内外评价的定义与对接转换

• 外部威胁情报（保证实时性）
  

【叁】以渗透为原型的改造

为什么要以渗透测试作为改造对象？

主要是因为渗透，现在渗透测试是被误读最深也是被利用最广的一种服务模式，很多厂商将渗透作为交付亮点，而很多用户则认为渗透是保障目标系统安全的一种校验手段。

但实际上，渗透本来只是用于校验系统整体安全性的一种手段，其本质是“点到为止”。虽然目前一些类似于众测的模式有一次性挖掘干净所有漏洞的野心，但从理论上来说，这种基于已知手段的挖掘方法仍然是不可能全面的，再如何论证，也是只是一种“点到为止”的手段。

基于这种误读和现状，所以这里索性就去改造这项服务，将其真的贴合这项服务被误读后的状态。

上面废话了这么多，最终，其实就拆了这么几个过程：

过程1：挖掘

• 标识与发现业务

• 基于业务或数据进行梳理，输出“测试流”

过程2：威胁情报（外部）

• 大而全的外部来源到内部的转换

• 打包推送（威胁情报 = 威胁 + 通用评价指标 ）

过程3：评估/渗透/验证

• 结合上面两种机制形成可评价的测试（验证）路径

• 对测试路径自身的影响、易用性、暴露性等方面进行评估

以上三个方面组合成为一种“渗透服务”或“威胁挖掘（发现）及跟踪服务”，其核心在于业务化、数据化、实时性以及持续性

整个的环节应该是这样的：

接下来需要拆分一下几个过程，并讨论一下3个过程中没有完成的那段闭环

不过，我已经几天没好好睡觉了，今天就先写这些吧

（待续）

本文始发于微信公众号（Piz0n）：渗透+风险模型+威胁情报（上）