一、前言
对于企业内部的安全工程师来说，对漏洞一直又爱又怕，爱在，漏洞的发现与验证实现的过程，充满满满的成就感；怕在，不断的新系统上线，老系统版本更新迭代，造就一批批的漏洞如雨后春笋般争相露头，一段时间下来，好像漏洞无穷无尽，怎么都修不完。甚至部分开发人员，谈漏洞色变，让人颇为无奈。等到汇报的时候，不出事就是应该的，出了事就是安全工作没做到位。但殊不知，在企业安全建设前期阶段，安全漏洞管理是复杂繁琐、让人头痛的事情，漏洞录入、跟进、处理、验证、修复完成整个循坏下来，需要好的方法与技巧，不然着实让人充满疲惫与无力感。
二、漏洞发现
随着企业安全建设的不断深入，漏洞发现的渠道变得越来越多，很多企业除了内部加强安全检测、渗透测试外，都有自己的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
*本文原创作者：jary123，本文属于FreeBuf原创奖励计划，未经许可禁止转载
