安全路透社
当前位置:安全路透社 > 网络转载 > 正文

浅谈企业内部安全漏洞的运营(一):规范化

一提到漏洞,不少安全工程师又爱又恨。爱在,挖掘和复现漏洞本身,就是特别有意思的事情,能登上国内各大SRC排行榜,进入谷歌名人堂、被微软致谢也是充满成就感的事情。恨在,如果企业真的发现的漏洞多了,就有“野火烧不尽 春风吹又生”之感,仿佛自己的时间被不断的发现漏洞、确认和分发漏洞、推动修复漏洞给淹没了。不修漏洞吧,风险在那儿好像也不踏实;修吧,总是在找业务方,业务方还不一定立即找得到、乐意修。一段时间下来,觉得仿佛漏洞怎么修也修不完,自己不像做技术的,反而很多时间花在技术之外,不少开发还谈安全漏洞色变,没啥成就感。等到汇报的时候,好像不出事是应该的,出了事就是安全没做到位。

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

既然说是漏洞运营,肯定不是说如何挖掘和复现漏洞,而是针对漏洞的整个生命周期进行优化。期望后续再遇到一些麻烦的时候,能有一点点小小参考。优化主要可以从4个方面进行:1.规范化 2.产品化 3.数据化 4.人。这4点有的时候可以同时进行,有的时候需要先完成规范化再去进行产品化,因为有的产品在流程规范都没有跑通的情况下就动手,后续的硬伤会非常多;而很多产品是安全强需求,等不及万事俱备是必须先上了再说,然后一点点优化规则;而人,就是这个过程中最不可控,也运营里最困难的地方。接下来会就规范化进行详细的分解,里面会涉及到一部分产品和数据化的东西,由于篇幅有限,其他维度后续会专门出文章详细说明。

浅谈企业内部安全漏洞的运营(一):规范化

规范化讲从以下5个方面进行解读,即:

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

一、漏洞类型

漏洞类型,是漏洞管理的一个基础。国内常见的各大SRC区分方式,都是漏洞大类、漏洞小类,或者是一级分类、二级分类。内部处理时候,可能会针对不同的二级分类进行细分。一般一级分类是依照不同的介质,如Web、移动、PC、系统网络等。这些都是从技术层面的漏洞分类,同时业务安全、数据安全和权限安全相关的漏洞,和技术漏洞平行,有时也会一起加进来。当然这个就不是大类,而是安全方向了。在此处仅说明技术漏洞。

二级分类,有按照原因细分的,也有按照结果细分的,也有两者相结合的情况。

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

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

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

二、漏洞等级

1.等级分类

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

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

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

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

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

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

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

2.等级的判定

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

2.1 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安全》给出了如下例子:

在一个web网站中,存在用户账号被盗威胁,根据DREAD进行评分如下:

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.2 根据漏洞风险结合业务核心程度判断影响力

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

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

1)漏洞类型和等级

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

浅谈企业内部安全漏洞的运营(一):规范化

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

等级梳理好后备用。 

2)核心业务

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

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

浅谈企业内部安全漏洞的运营(一):规范化

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

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

三、漏洞时效性

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

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

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

israbye FreeBuf.COM

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

PC端和移动端类似。

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

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

四、处理流程

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

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

1)常规修复流程

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

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

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

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

C.如果做好去重,可以将漏洞归并;

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

2)忽略流程

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

3)不修复流程

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

浅谈企业内部安全漏洞的运营(一):规范化

五、复盘流程

所谓“温故而知新”。

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

1)数据分析,主要关注量,如漏洞修复情况、归属事业部产品线情况、类型情况。

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

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

上次发文没配图,被P来着,这次配了图,发现好像篇幅有些长,也来不及写产品、数据化和人的运营。这些会在接下来的文章中进行详细说明,欢迎感兴趣的小伙伴一起交流。

参考资料和特别鸣谢:

1.道哥《白帽子讲web安全》

2. ASRC漏洞定级规范,特别特别感谢ASRC少丰指导

3.特别特别感谢滴滴出行信息安全部王友帮指导

*本文作者:安惞,转载请注明 FreeBuf.COM

未经允许不得转载:安全路透社 » 浅谈企业内部安全漏洞的运营(一):规范化

赞 (0)
分享到:更多 ()

评论 0

评论前必须登录!

登陆 注册