漏洞管理一直是安全团队工作中的老大难问题，漏洞来源多数量多，而且是层出不穷，占据网络安全团队大量的时间和精力来进行检测、排查、通报、整改和复测。稍不留神就会因为一个洞而被打穿，防不胜防，给人一种前功尽弃的绝望感。如何实现漏洞的检测、通报、修复和复测的全周期闭环管理，是我们一直在探索的答案。
下面简要介绍下我们在建设漏洞管理系统过程中积累的经验或是踩过的坑：
1、漏洞检测环节：常规的主机和Web漏洞的定期扫描必不可少。在此基础上，我们增加了如下几类检测工作：
·产进行端口和服务的细粒度扫描，同时还增加了Github、暗网等数据泄露的监测。
·互联网众测：自动化扫描的弊端就是对于深层次的或是逻辑性的漏洞检测能力较差，故需要引入人工检测能力，众测平台上有一大批漏洞检测能力一流的人才，借此可以弥补我们在漏洞发掘面人力短缺和技术水平不高的短板。
·内网渗透测试服务：上述是面向互联网侧的漏洞检测，在内网的漏洞检测方面，我们也增加了内网渗透测试服务，试图发现网络架构上的不合理之处，同时对日常应用系统脆弱性进行摸排。
·资产多扫描周期长：对于资产分散且数量庞大的情况下，就必须引入分布式扫描系统，为了加快扫描进度，需要先进行主机或应用存活检测，扫描的结果应该形成资产信息存入资产库，再依据资产库对主机和端口服务进行漏洞检测。
2、漏洞研判环节：之前经常碰到发现就通报但最后被怼的情况。一是漏洞的实际影响可能并不大，但修复起来较困难比较费时，导致耗费大量时间跟进但漏洞缺迟迟无法修复，反而造成那些易利用危害大的漏洞没有被及时处理；二是漏洞通报后研发也不清楚如何修复，没有知识库供参考，导致事情不了了之；三是某一类组件的漏洞总时频繁出现，研发升级组件疲于奔命。对此，我们的应对如下：
·漏洞优先级的评定：常见的是基于漏洞的网络位置，以及危害等级来定出优先修复的漏洞清单，例如我们优先处置互联网侧的漏洞，哪怕是低级别的也必须快速处理，从发现到通报要求一天内处理完成，期间还需要做好监测，以防漏洞被利用。另外，对于内网的漏洞，要求高危及以上且是RCE\EXP的漏洞需要优先修复。Gartner提出的基于风险的漏洞管理思想，Tenable产品中取代CVSS的预测优先级分析与漏洞优先级评级 (VPR) 以及漏洞情报(VIR)概念用于漏洞优先级的评定是一个不错的思路。
·漏洞知识库的补充：在通报漏洞之前，安全团队应补充必要的漏洞知识，包括但不限于漏洞原理、利用手段、加固方法、修复方法。我们定期梳理一段时间的漏洞清单，找出优先修复的列表，然后到互联网收集漏洞知识整理成文章，补充进漏洞管理系统和技术社区，并将链接一并给到研发。
3、漏洞定位环节：漏洞需要匹配到对应的管理员才能定位到由哪些人员负责。对于主机漏洞，主要通过IP等方式匹配。在有些单位，应用类漏洞和主机类漏洞需要通报给不同的人，Windows和Linux主机操作系统有基础设施组管理，而上面运行的WEB、应用程序则有应用组管理，而且有的更加细分可能会出现一台机器上跑了多个应用，而这些应用又由不同的应用管理员负责，当然这种情况极少，一般的情况是一台机器上跑的应用统一由某一位应用管理员负责。漏洞与资产关联需要解决几个问题：
·WEB、主机等漏洞归一化格式：WEB的格式可能是http://xxx.xxx.xxx.xxx:8080/path/to/vul，而IP是http://xxx.xxx.xxx.xxx，如何归一化，有些产品的做法是protocal://ip:port/uri的形式。例如Windows MS17-010漏洞，格式可能就是smb://http://xxx.xxx.xxx.xxx ，SQL注入漏洞，格式可能就是http://xxx.xxx.xxx.xxx:8080/showArticle。但是这样会存在如何判断前面的协议，一般的扫描器是没有的。所以有些厂商的做法是把web类资产、主机类资产分别管理。
·应用漏洞与应用资产的关联：漏洞与资产的关联，难点在应用漏洞与资产的关联。资产需要分为操作系统和应用两类，每一类都有多个管理员，应用类漏洞往往需IP再加上应用标签进行匹配，而且前提是有应用的资产信息（例如WEB漏洞的URL是http://IP:Port/path/to/vul，应用标签是B应用，IP对应的资产应该包含B应用信息方可进行关联）。
·资产遗漏：有些主机资产找不到人，有些应用资产无法齐全的检测到，是个老大难的问题。这里推荐基于Agent的资产检测产品，对于资产的识别和检测，比远程扫描要有效的多，例如一些HIDS产品已经具备非常丰富的资产识别功能。这一块其实涉及资产管理的内容，最基本的是需要具备主机和应用的资产信息，此文暂时不讨论，后续文章会分享。
4、漏洞通报环节：之前的做法是给一个excel表格然后配上漏洞知识库发给关联的管理员，但是你会发现在漏洞数量达到3位数的时候，发邮件就是个极费体力的活。当然电子化流程做的比较好的情况下，可以和OA工单集成。但是你有没有想过你会碰到如下情况：
·部分人员没有工单系统账号：当前较大企业组织的外包人员众多，有些人员并未被授权访问工单系统，没有工单系统账号，你如何甄别并通报。解决的办法是要么单独建立一个集中的工单系统专用于安全事件通报，要么运用邮件、短信、工单多种组合方式进行通报。
·漏洞多导致工单多：漏洞少的时候运维和研发还有心情配合你进行修复，当数量过多时容易造成待完成工单堆积，给他们造成极大的心理压力。解决的办法是一段时间一次只推送少量优先级高的漏洞。
5、漏洞修复环节：我们得有觉悟，并非我们推荐的修复方案，研发和运维会按照执行，总会出现这样或那样的问题导致无法进行正常的漏洞修复，例如系统较老而不敢碰，或是使用的开源组件目前尚无漏洞修复补丁或是无新版本，一时半会无法修复漏洞也不能放任自流：
·加固方案：如果无法正常修复漏洞则应该考虑进行加固，例如利用iptables限制端口访问。
·修复周期长：有些采购的第三方系统，出了漏洞厂商反应慢，反馈得等到2个月后的版本升级。除了进行加固，应该考虑到更深层次的问题，如何进行供应商管理，如何促进DevSecOps更高效等。
·修复方案：有的时候安全组提供的方案可能不符合实际环境，那么久要求运维或研发提供他们的具体方案，漏洞管理系统和漏洞管理流程则应该支持修复方案的提交等功能。
·漏洞暂时搁置：有些漏洞可能暂时无法处理或是需要延后处理的，则可建立漏洞review机制，管理需要修复但暂时无法处理的，形成定时任务，到期即提醒，并在此进行研判和通报。
6、漏洞复测环节：漏洞进行了处置之后就需要进行漏洞复测，以形成闭环。对于漏洞复测，其实这个回到了第一个环节即漏洞检测，如果你已经实现了自动调用扫描器或HIDS等API接口进行扫描，那么实现复扫只需要调用漏洞对应的API接口进行复扫，并同步检测结果即可。如果是手工录入的渗透测试漏洞，如果漏洞管理系统支持自定义漏洞检测插件，则可以考虑进行定制，且定制后可以重复使用。如果无法自定义，则只能进行手工复测。
当然，出了上述提到的一些重难点，其实有还有很多坑，给大家留个清单，可以自行思考得到答案。
本文内容不用于商业目的，如涉及知识产权问题，请权利人联系51Testing小编(021-64471599-8017)，我们将立即处理
