不修漏洞吧，风险在那儿好像也不踏实；修吧，总是在找业务方，业务方还不一定立即找得到、乐意修。一段时间下来，觉得仿佛漏洞怎么修也修不完，自己不像做技术的，反而很多时间花在技术之外，不少开发还谈安全漏洞色变，没啥成就感。等到汇报的时候，好像不出事是应该的，出了事就是安全没做到位。

上面这些情形，在过去的几年里，我见过，亲身经历过，也解决过的一些问题。在做的过程中，也走了不少弯路，踩了不少坑，同时也发现有不少的共性可以提炼。作为做过安全管理和运营，也做过SOC产品经理的菜鸟，在此和大家探讨交流下，如何做企业内部的安全漏洞运营。

既然说是运营，肯定不是说如何挖掘和复现漏洞，而是针对漏洞的整个生命周期进行优化。期望后续再遇到一些麻烦的时候，能有一点点小小参考。

优化主要可以从4个方面进行:

1. 规范化

2. 产品化 

3. 数据化 

4. 人

这4点有的时候可以同时进行，有的时候需要先完成规范化再去进行产品化，因为有的产品在流程规范都没有跑通的情况下就动手，后续的硬伤会非常多；而很多产品是安全强需求，等不及万事俱备是必须先上了再说，然后一点点优化规则；而人，就是这个过程中最不可控，也是运营里最困难的地方。接下来会就规范化进行详细的分解，里面会涉及到一部分产品和数据化的东西，受限于篇幅有限，其他维度后续会专门出文章详细说明。 

规范化将从以下5个方面进行解读，即：

漏洞类型、漏洞等级、漏洞实效性、漏洞处理和漏洞复盘。

漏洞类型，是漏洞管理的一个基础。国内常见的各大SRC区分方式，都是漏洞大类、漏洞小类，或者是一级分类、二级分类。内部处理时候，可能会针对不同的二级分类进行细分。

一般一级分类是依照不同的介质，如Web、移动、PC、系统网络等。这些都是从技术层面的漏洞分类，同时业务安全、数据安全和权限安全相关的漏洞，和技术漏洞平行，有时也会一起加进来。当然这个就不是大类，而是安全方向了。在此处仅说明技术漏洞。二级分类，有按照原因细分的，也有按照结果细分的，也有两者相结合的情况。

一个配置不当导致的信息泄漏，按照原因可以被归类到配置不当，按照结果可以被归类到信息泄漏，主要看进行漏洞分析时，更注重损失和危害还是产生原因，常规情况下还是选择原因。

XSS大部分SRC还是区分了是反射型还是存储型，一方面是风险等级不同，另一方面是大部分反射型的XSS能够被扫描器覆盖，而存储型则不然，在二级大类区分后，便于后续review扫描器漏报、优化规则。

通用软件漏洞，有时候单独划分到一个大类，有时放到系统网络大类下面，主要是因为部分通用软件漏洞是底层漏洞。

常见的区分方式有两种，一种是三级分类，一种是五级分类。三级分类就是高危、中危、低危；五级分类是严重、高危、中危、低危和告警。

三级分类，无论对于安全从业者，还是安全以外的管理者而言，都简单易懂。但是对具体场景，如已经产生了或极易产生安全事件的漏洞（一般5级时是“严重”），仅作高危不能体现其程度和对时效性的要求，对于风险极低也难以被利用的漏洞，在人力资源紧张的情况下要求尽快修复也不合适（一般5级时定为“告警”）。

五级分类，能够给以上两种情况一个区分的buffer。同时，由于可以选择的等级太多，对于模糊的时候，容易出现不同工程师对同一漏洞定级不一致的情况，这个出现差异的比例比三级分类时候大的多。对于后续漏洞分析、向管理者汇报时也多少有一定困扰。

等级的判定，一般内部发现和外部报告的等级会有1～2级的区分。

外部报告除了自家公司的SRC之外，还包括部分可能会公布漏洞细节的第三方平台、新媒体和传统媒体。漏洞被曝光后，信息被大范围传播，一旦遇到不及时修复漏洞就曝光的情况，有可能被多次利用、入侵和数据泄漏窃取，影响公司股价、声誉，高层下台的事件屡见不鲜，所以外部报告的最终评级一般会高一些。

内部发现的漏洞，除了常规漏洞扫描，还有可能是产品上线前，主动找安全工程师进行安全评估发现的漏洞，以及在安全氛围比较好的部门，开发测试运维等人员主动发现的漏洞。这类漏洞，理论上讲，发现的越多越好，由于未上线和风险可控等原因，最终定级可以比外部报告的低1～2级。

上面说的原始等级和最终评级，一个是根据漏洞技术风险评定的等级，一个是根据具体情况进行的调整，两个等级都很重要，都需要分别作记录。

作为菜鸟，已知的有两大类等级规范的方式，一类是根据DREAD模型，一类是根据漏洞风险结合业务核心程度判断影响力，下面会进行详细的说明。

DREAD模型

优点是这个是国际标准，基本上已经久经考验；缺点是实践的时候计算的维度多，每个维度都需要填写精确不然很难自动化，填写的时候需要填的项目也比较多，用户体验可能存在一定的损伤。

1) 什么是DREAD模型？

DREAD模型，包括5个方面:

a.危害性 （damage）：如果被攻击了，会造成怎样的危害

b.持续生产 （reproducibility）：攻击后恢复运营的简易度？

c.难度系数 （exploitability）： 实施此项攻击的难度是如何？

d.受影响用户数 （affected users）： 有多少用户会受到此项攻击影响？

e.发现系数 （discoverability）： 这项威胁是否容易被发现？

2) 如何评价？

3) 如何计算？

一个漏洞具体的等级，可以按照上面的标准，计算给定威胁的值 (1-3)。结果范围为 5-15。这样就可以将总分 12-15 的威胁评价为高度危险，8-11 的威胁评价为中度危险，5-7 的威胁评价为低度危险。

道哥的《白帽子讲web安全》给出了如下例子：

a. 网站登陆页面存在暴利破解：D(3)+ R(3) + E(3) + A(3) + D(3) = 15

b. 密码找回存在逻辑漏洞：D(3)+ R(3) + E(3) + A(3) + D(2) = 14

c. 密码可能被嗅探：D(3) + R(3) + E(3) + A(1) + D(3) = 13

d. 服务端脚本漏洞（如SQL等）: D(3) + R(3)+ E(2) + A(3) + D(1) = 12

e. 钓鱼网站：D(3) + R(1) + E(3) + A(2) + D(3) = 12

f. XSS或其他客户端威胁：D(3) + R(2) + E(2) + A(2) + D(2) = 11

g. 病毒或木马：D(3) + R(1) + E(2) + A(1) + D(1) = 8

根据计算结果，我们可以得出漏洞的具体等级。

根据漏洞风险结合业务核心程度判断影响力

这个实际上是源自一部分工作实践，利用既有数据可以快速计算出风险等级，而且便于自动化提示。优点是简单易懂，即使初入门也比较容易给出等级，缺点是衡量的维度确实有所欠缺，有时需要人工进行调整，计算出来的只能是提示的建议等级。

这个方法有2个核心要素，即漏洞类型和业务核心程度，两者取乘积，得出最终的等级。

1）漏洞类型和等级

上述的五级分类里，有风险的漏洞分为严重、高危、中危和低危，然后给每个漏洞设置基础分，例如严重的基础分是x，高危的基础分是y，中危是z，低危是w。

一般，根据某一种漏洞，可以判断出常规情况漏洞风险的，例如SQL注入一般是高危或严重；CSRF一般是中危，可能低危可能高危；如果是被getshell一般都是严重，存储型XSS比反射型XSS等级高一些。这样可以根据不同的漏洞类型，以及自己公司的业务形态，梳理出一版适合自己公司业务场景下，每个漏洞类型的默认风险等级，等级梳理好后备用。

2）核心业务

一般情况下，即使不完全清楚自己公司全部的资产信息，但是哪些部门是核心部门，哪些业务是核心业务，往往是可以区分得清楚的。举个例子，打开某个APP，如果这个APP有很多功能，你最常用，最先映入眼帘的功能，很有可能是核心；一提起某个公司，你就知道这个公司有哪些产品，一般也是核心；再或者，看某个公司的财报，基本上经常上榜的，就是核心没跑了。

如果一个核心业务就在一个事业部，这个就很容易知道谁是核心；如果一个事业部有多个业务，可以参考以下公式：

然后用漏洞危害的基础分x核心业务的权重，就能得出最终的漏洞风险，即：

漏洞风险=漏洞危害x业务核心权重

漏洞时效性，包括漏洞的确认、分发、止损、转移、修复和关闭的各个环节。不过，常规漏洞关注确认和关闭两个环节就够了。

漏洞的时效性，一般根据漏洞类型和最终等级共同确定。

一般Web漏洞，常规时效性是

移动端的漏洞，由于其特性，即漏洞不一定是企业内部都可以cover的，部分需要等待官方厂商给出升级版，即使是自己能够cover的部分，也不能像Web端频繁发版（考虑用户体验），IOS端发版还要看AppStore审核，故难以严格按照Web漏洞的时效性予以要求。对于高危（严重）的漏洞，一般先要求止损时间，即看能否通过其他方式暂时避免损失，上线时间要求在两周已经很紧了。中危漏洞，上线时间一个月，低危两个月。

PC端和移动端类似。

系统网络漏洞，根据漏洞性质，常规漏洞要求同Web端，通用型漏洞可以参考移动端也可以根据不同情况具体界定。

当然，以上各种时效性要求都是参考，实际执行的时候，需要给安全工程师和业务方，留有“延期”的权限，不同等级延期要求不同。高危（严重）可能需要总监审批，其他可以选择主管审批或者不审批。强烈推荐，延期的操作由业务方来进行，安全工程师来审核，而不是安全工程师自行延期。延期的时候要限制最多延期次数和最多延期周期，以免漏洞无限期推迟修复，造成较大风险。

高危（严重）漏洞，外部发现的，需要发起应急响应流程，重点强调时效性和复盘。

所有的漏洞都需要遵照的处理流程至少包括3个流程：

常规修复流程

漏洞发现后由安全工程师给出风险，定位受影响事业部修复人，和给出修复方案。如果是高危严重漏洞需要进行应急响应。

这里额外说下，如果SOC做好资产功能，可以极大的提升工作效率：

A. 可以根据url/app名称/ip/机器名自动匹配事业部和修复人；

B. 如果做好漏洞知识库，在选定某一类安全漏洞的时候，也可以自动弹出该类漏洞的的修复方案和风险;

C. 如果做好去重，可以将漏洞归并；

D. 一旦超期，做好不同超期情况逐级上报规则，可以有节奏的提醒开发修复漏洞，前提是必须做好提示，以及允许有延期功能。

如果是非安全漏洞，风险可以忽略，可以走忽略流程。

如果是安全漏洞，存在风险，不是可以忽略不计的情况，但是由于修复成本过高接受风险的情况，可以走不修复流程，但是需要修复人上级和安全工程师双重确认。

所谓“温故而知新”。

漏洞运营的最后一个流程不是修复完毕，而是针对历史的漏洞进行分析，包括量上的数据分析，原因上的归因分析。

数据分析

主要关注量，如漏洞修复情况、归属事业部产品线情况、类型情况。

主要关注高风险，不仅要分析产生原因，还需要分析漏报原因。同时一旦发现，注意排查日志判断是否被利用。

得出复盘结论后，需要出相应的复盘报告，联系相关团队开展复盘沟通，对于各团队都认可的风险，明确改进措施，负责人和排期。并在后续定期追踪完成进度。