一、前言
对于企业内部的安全工程师来说,对漏洞一直又爱又怕,爱在,漏洞的发现与验证实现的过程,充满满满的成就感;怕在,不断的新系统上线,老系统版本更新迭代,造就一批批的漏洞如雨后春笋般争相露头,一段时间下来,好像漏洞无穷无尽,怎么都修不完。甚至部分开发人员,谈漏洞色变,让人颇为无奈。等到汇报的时候,不出事就是应该的,出了事就是安全工作没做到位。但殊不知,在企业安全建设前期阶段,安全漏洞管理是复杂繁琐、让人头痛的事情,漏洞录入、跟进、处理、验证、修复完成整个循坏下来,需要好的方法与技巧,不然着实让人充满疲惫与无力感。
二、漏洞发现
随着企业安全建设的不断深入,漏洞发现的渠道变得越来越多,很多企业除了内部加强安全检测、渗透测试外,都有自己的SRC平台,这极大的促进了企业信息系统的完善跟优化。
2.1 漏洞来源
2.2漏洞类型
漏洞类型是漏洞管理的基础,一般都会分为一级大类,二级大类,一级大类主要根据技术层面划分,如主机安全、网络安全、应用安全、移动安全、终端安全等,当然还可以根据业务性质划分,如数据安全,业务安全等,本文主要对技术层面进行划分。
一般来说,漏洞产生的原因,以及漏洞造成的结果,都可以成为二级分类的细分方向,有时候会考虑两者结合,下图为对应用安全进行具体细分。
2.3 漏洞等级
1)漏洞分类
常见的漏洞分类区分方式有两种,一种是三级分类,一种是五级分类。三级分类就是高危、中危、低危;五级分类是严重、高危、中危、低危和信息。
企业内部一般会采用五级分类,相对来说比较合适,因为在实际操作过程中,有些已经产生了或极易产生安全事件的漏洞(一般5级时是“严重”),仅作高危不能体现其重要程度和对时效性的要求, 对于那些影响受限、风险极低且难以被利用的漏洞(一般5级时定为“信息”),在人员紧张的情况下,要求安全工程师与开发及时处理、修复,花费时间太多,也得不偿失,可能还会激起与开发同事的矛盾。
如漏洞来源中的SRC、外部检测中的外网渗透中提交的漏洞,因为是对外系统,一般会根据应用系统的重要程度,受影响的范围,酌情考虑提升1~2个等级进行处理,其中影响范围较大的,还需进入应急响应处置流程。
如安全事件导致的安全漏洞,一律按严重漏洞进行处理,并且进入应急响应处置流程。
2)漏洞风险计算
漏洞等级的最终划分,还是需根据漏洞分类、业务系统重要程度结合来定义,可以事先确定公司业务的分级,如核心业务系统(5)、重要业务系统(4)、业务支撑系统(3)、业务服务系统(2)、一般系统(1)等,可以采用漏洞分类x业务系统等级来判断最终的漏洞等级,因为安全最终也是为业务服务,减少业务的风险。
漏洞风险计算表
3)漏洞等级划分
为了方便安全工程师对漏洞风险的统一判断,以及后期漏洞管理自动化的开展,可以对漏洞风险制定一个参考表格,设定风险值等级,本文提供的仅供参考,大家可以根据企业内部的实际情况进行调整。
4)漏洞分级标准
对于漏洞分级标准,各大SRC平台都有明确的划分,各家都大同小异,企业内部做漏洞分级标准时都可以参考一下,根据企业内部的实际的情况稍作修改即可,本文所提供的是参考ASRC漏洞评分标准V3.0制定:
三、漏洞处置流程
当以上的流程与标准都规范化后,就可以进入漏洞的处置流程了,这是漏洞管理中必不可少且非常重要的环节,发现的所有漏洞,都需要人员进行处理,跟进,直至漏洞修复,已到达规避、减少及降低风险的作用,更好的为业务服务。
所有的漏洞处置都需遵循以下流程:
3.1 漏洞录入
在漏洞验证完成后,安全工程师需要根据企业内部的漏洞等级划分标准,将存在的漏洞录入漏洞管理系统或工单系统中,我们是将漏洞管理系统与工单系统相结合的方式。
当漏洞创建成功后,会自动邮件通知漏洞修复人员,当漏洞的状态或内容有变动时,会实时邮件通知漏洞创建者及漏洞修复人员,当然对改漏洞关注的人员也可收到漏洞变更邮件,这样极大的提高了漏洞修复进度的实时性,能极大的提高漏洞修复率。
注意:需要对漏洞管理系统进行权限控制,录入成功的漏洞,应除了漏洞管理系统管理员、漏洞创建者、漏洞修复人外,其他人无查看、修改权限,且只有管理员、漏洞创建者有删除权限,如其他人员想关注漏洞,需对应漏洞的修复人同意才可进程查看,关注。
3.2 漏洞分发
我们是采用漏洞管理系统与工单系统相结合的方式,可以参考以下几点,这有助于减少安全工程师的工作量,提高工作效率以及漏洞修复率,也可为以后漏洞管理自动化做好准备。
A、可以根据URL/app名称/ip/应用系统名称自动匹配部门和修复人; B、已有漏洞知识库,在选定某一类安全漏洞的时候,可以自动弹出该类漏洞的的修复方案和风险;
3.3 漏洞跟进
漏洞录入漏洞管理系统后,就需要有人员进行跟进、处理,不然漏洞迟迟不修复,也无法达到规避、减少或降低风险的目的,我们采用的是下面的方法:
1、录入时,自动邮件告知系统负责人; 2、根据漏洞等级设定的时效性,设置修复计划时间,修复计划时间到期,自动发送邮件至系统负责人邮箱提醒; 3、每周一,梳理修复计划已过期且未修改修复计划的漏洞,会在漏洞周报中重点标明; 4、超过两个修复周期的漏洞,邮件抄送部门领导。
3.4 漏洞修复周期
漏洞修复周期,包括漏洞的验证、评估、分发、复验、修复和关闭的各个环节。漏洞的修复周期,会根据漏洞等级确定。如人员紧张的时候,特别是内网系统,可只处理中危以上漏洞,一般web漏洞,漏洞修复周期为:
3.5 修复延期方法
当然,以上各种修复修复周期要求都是参考,实际执行的时候,需要给安全工程师和业务同事,拥有“延期”的权限,不同等级延期要求不同,但不能超过修复时间的2个周期,当然特殊情况按特殊处理,例如中危漏洞,最多延长2X724小时,意味着中危漏洞最长的修复时间为37*24小时。
1)严重漏洞需通过邮件、OA申请延期,经安全总监、业务总监双方审批 。 2)高危、中危漏洞需要邮件、OA申请,经安全部门负责人、业务部门负责人双方审批; 3)延期的操作建议业务方来进行,安全工程师负责修改延期时间,而不是安全工程师自行延期。 4)延期的时候要限制最多延期次数和最多延期周期,以免漏洞无限期推迟修复,造成较大风险。
四、漏洞数据分析与规则优化
对于漏洞管理整个流程来说,漏洞缓解或已解决后,关闭工单不是最终的目的,需要对漏洞数据进行分析,持续运营,可以从以下几个方面考虑:
1)统计一段时间内,外网系统出现的次数最多的Top10漏洞排名,分析漏洞出现的原因;
如外网系统中出现多次SQL注入漏洞,可以检查WAF的规则库是否及时更新?规则是否生效?此外网系统是否在WAF的防护之内?对外的系统为何不做严格的字符过滤机制等。
2)统计一段时间内,自主开发系统中漏洞数量最多的Top10系统排名,分析造成的原因;
如弱口令次数过多,是安全意识宣传不够?研发人员不重视?
3)哪些供应商的开发的系统漏洞数量最多?分析存在的原因;
是否需要约谈供应商沟通,是安全开发能力的问题,还是研发安全意识不够?
4)哪些框架被利用造成的漏洞过多?
是情报问题?还是应急响应机制的原因?是否可以替换为其他框架?
5)SDL安全开发的系统数量情况
本文列举的方面只是几个方面,漏洞管理运营是一个持续改进优化的过程,不能一蹴而就,更不可能一劳永逸,后期会继续发布运营方面的内容,各位小伙伴感兴趣的可以相互交流。
参考资料
1.安惞《浅谈企业内部安全漏洞的运营(一):规范化》 2. ASRC漏洞定级规范V3.0