银行业漏洞治理实践与展望--漏洞治理的道与术
第一部分 楔子
近几年，公司开展了多轮网络攻防演习，攻防演习的开展促进了基础安全架构升级和完善，随着WAF、IPS、蜜罐、全流量等安全设备和策略的逐步完善，网络安全工作走入深水区。如果说基础安全架构的完善是练外功，那么对资产漏洞的管理就是练内功，外功易得，内功难练。攻防演习对抗的就是对漏洞的感知、利用和防护，发现的是资产漏洞，在攻防对抗愈演愈烈的当下，管理漏洞就成了安全运营必须攻克的拦路虎。如何避免被打穿，从资产角度，最快速有效的防御方法就是干掉资产，系统下线就属于此类，但是，干掉所有资产是不现实的。于是，隐藏资产就成了缓解措施，但总有对外的业务没法隐藏，且并不是隐藏了就是安全的，隐藏资产只是对漏洞的掩耳盗铃，漏洞的存在和利用都是客观存在的。从漏洞角度，漏洞管理不是愚公移山的有无恒心问题，而是一个管子进水、一个管子出水的数学题，只有减少进水、加大出水，才能避免水溢出。漏洞，就像房贷一样，一直在那，是安全人员的债。是债，迟早要还。漏洞处置，是亡羊补牢，为时不晚。漏洞是企业网络安全保障体系的薄弱点，做好漏洞管理是堵住企业网络安全保障体系缺口、健全金融网络安全保证体系的关键举措，也是保障金融网络安全、HW行动和应对未来挑战的必由之路。
第二部分道与认知
一、漏洞管理成熟度
作为2B级的中小法人银行，随着渗透测试、攻防演习的常态化，网络安全建设进入深水区，漏洞管理已成为我行亟需解决的管理问题。
美国系统管理和网络安全审计委员会参照CMMI的做法，制定了漏洞管理成熟度模型，来衡量企业组织目前的漏洞管理水平。漏洞管理成熟度模型主要包括如下5个阶段：
|
级别 |
阶段 |
定义 |
自评 |
|
1 |
初始阶段 |
处在这一阶段的公司企业要么没有任何漏洞管理措施，要么只做临时性的测试。 |
时间：2012-2015 管理范围：监管、二三道防线、内部检查发现的合规问题由100余条增加至300余条。 |
|
2 |
已管理阶段 |
处于这个阶段的企业可以自发在内部开展漏洞扫描工作，每周或者每月固定开展，但是往往是为了应对外部监管。 |
时间：2015-2018 管理范围：监管、二三道防线、内部检查发现的问题+渗透问题，增至800余条。 形态：制定漏洞管理指引，收集漏洞的渠道增多，形成常态化督办、通报机制。 |
|
3 |
已定义阶段 |
该阶段的漏洞管理工作为公司所理解，也受到公司管理层的一定支持，漏洞扫描更为频繁，但是专业工具应用还比较有限。 |
时间：2019-至今 管理范围：监管、二三道防线、内部检查发现的问题+渗透+演习+检测+扫描问题，增至2000余条。 形态：制定漏洞管理、上线前安全检查制度，漏洞扫描常态化，安全检测手段进一步增多，收集漏洞的渠道进一步扩宽，进行人工漏洞优先级定级，形成每周督办、每月通报机制。 |
|
4 |
量化管理阶段 |
处在这一阶段的公司企业有可量化、可度量的指标，定义可接受的风险水平。 |
时间：*-2025年 管理范围：内外部检查合规问题、资产测绘+漏洞扫描漏洞、渗透+攻防漏洞、组件漏洞。 形态：漏洞管理制度进一步完善和落实，使用多样的漏洞检测工具，实现漏洞交叉校验，全面覆盖合规、主机、web、组件漏洞，实现漏洞发现渠道多样化、漏洞发现自动化、漏洞定级自动化、漏洞处置指标化、漏洞跟进可量化。 |
|
5 |
优化管理阶段 |
在这一阶段，使用第四阶段定义的度量指标用实现管理提升和优化，所有的优化指标都用于减少组织的受攻击面。 |
时间：未来 形态：漏洞情报联动化、漏洞处置自动化 |
表1：漏洞管理成熟度评估表
二、漏洞管理痛点与难点
随着信息化和数字化的建设，资产数量暴增的同时，外部漏洞披露逐年增多，安全检测深度也逐渐加大，漏洞数量随之暴增。而目前漏洞修复时间效率严重偏低、修复成本严重偏高，导致漏洞逐年积压，漏洞积弊长年累月，蕴含极大风险隐患。漏洞已成为国家级战略武器，漏洞研究和利用已产业化，银行需进一步提高漏洞响应时效。但漏洞数量庞杂，相同漏洞在不同资产上的修复优先顺序不一样，哪些先改，哪些后改，是安全管理人员亟需定义和评判的。这些，通通都是漏洞管理的痛点和难点。
图1：漏洞管理痛点与难点
既然漏洞是安全管理绕不开的结，那就尝试管住它吧。
三、漏洞认知
外部或二三道防线对于漏洞的认知就是“哇哦，系统有漏洞，好危险，肯定要改”。
为了应对这种情况，安全人员只能“掩耳盗铃”，在漏洞扫描器前加一堆安全策略或设备，然后扫出没有漏洞的扫描结果，你好我好大家好，只留下漏洞默默的潜伏，直至某天突然地爆发。
所以改变对漏洞的认知，很重要，而漏洞管理的认知误区又有不少：
1. 漏洞管理就是应急打补丁：漏洞管理应该包括事前预防、事中控制和事后处理，漏洞管理也不止打补丁一种方式，打补丁只是一种成本最高的事后补救措施；
2. 漏洞管理就是建流程：建漏洞整改流程，只是为了更高效地跟进漏洞的整改，形成整改闭环，它只是漏洞管理的一个抓手。
3. 漏洞管理只是安全的事：漏洞管理缺少了开发、运维的深度参与，漏洞管理只是救火运动，漏洞管理应该是开发、运维、安全全流程的管控。
4.漏洞管理最重要的是漏洞扫描：漏洞扫描只是一个发现漏洞的工具，而漏洞发现只是资产发现后的下一步，发现不是目的，整改才是。
5.只需要修复POC/EXP漏洞：POC漏洞只是市面上已知存在工具的漏洞，市面上没有POC，不代表没有利用工具。
6.是漏洞就需要修复：在漏洞整改时，眉毛胡子一把抓是大忌，大部分漏洞影响有限，漏洞修复也是要计算投入产出的，而且也不可能修复所有的漏洞，所以并不是所有的漏洞都需要修复。
四、漏洞管理目标与方针
漏洞管理，首先是漏洞，其次是管理。漏洞，是依附资产上的，是资产的一个安全属性，所以做好漏洞管理就应该先做好资产安全的管理，所以脱离资产的漏洞评级都是耍流氓。管理，是通过实施计划、组织、协调、控制等职能实现既定目标的活动过程，漏洞管理，即是确立漏洞管理目标、制定漏洞管理计划、建立漏洞管理组织、协调内外部资源、控制漏洞管理质量的一个工程。为做好漏洞管控指导工作，明确漏洞管理目标和方针是第一步。
漏洞管理的目标应该是“从根源上减少漏洞的产生，并能全面、自动、高效、精准地发现和处置关键漏洞，实现资产安全闭环管理：
1. 全面：通过多渠道、多场景全面发现资产和漏洞。
2. 自动：支持资产、漏洞数据的自动同步，任务的自动下发，数据的自动分析、入库。
3. 高效：实现漏洞的高效应急和高效整改。
4. 精准：通过多工具交叉验证资产及漏洞的状态，辅以全面的漏洞知识库，实现漏洞的精准分类分级。
5. 关键漏洞：即对漏洞进行优先级排序，结合资产重要程度、网络边界属性、漏洞利用情报等因素进行优先级算法排序，指导高效漏洞整改。
要实现漏洞管理的目标，需要制定工作方针，漏洞管理方针是“全面保障，预防为主，综合治理，分级管控”。
1. “全面保障”：漏洞管理应确保全面发现资产漏洞
2.“预防为主”；漏洞管理主要工作是预防漏洞产生
3. “综合治理”：漏洞管理应该是多方参与协同治理
4. “分级管控”：漏洞处置应做好分类分级科学处置。
通过对漏洞管理目标和方针的分析，做好漏洞管理的道就是节源开流。节源，是减少漏洞的产生来源；开流，则是加大漏洞的整改力度。预防漏洞是节源，是一场细雨，润无声，于无声处见真章；整改漏洞是开流，是一次排雷，动天地，于惊险中解风险。漏洞管理是企业网络安全管理中最基础的工作，重要性毋庸置疑。但如何节源？又如何开流？
第三部分 术与节源
打补丁能解决的只是一个或一批漏洞，不能解决所有漏洞，企业需要补的也不只是漏洞本身，而是安全管理存在的漏洞，包括组织职责分工、工作流程、工作规范等存在的不足都可能导致漏洞的产生。
一、制定漏洞管理规范
规范管理，制度先行，制度是一切管理的基石和保障。制定漏洞管理规范能为漏洞管理提供指导性意见、方法和统一标准，规范应明确漏洞管理原则、职责分工、等级评估、处置标准、修复风险评估和修复过程控制等。相同的漏洞在不同资产上的风险是不同的，所以漏洞管理规范应明确漏洞风险等级评估标准，明确漏洞二次定级规则。具体实践可根据资产网络属性、重要级别以及漏洞原始等级进行。如：漏洞风险等级积分（S）=漏洞初始风险等级基础因子（X）*系统级别权重因子（Y）*网络边界类别基础因子（Z）
表2：漏洞风险等级积分矩阵表
二、制定安全检查规范
提高漏洞发现能力，扩宽漏洞发现来源，是做好漏洞管理的技术前提，漏洞发现能力低下的漏洞管理注定只是自我欣赏的表演。建立安全检查规范，明确各类系统变更或上线前的安全检查要求，能提前发现和处置漏洞，也是预防漏洞产生的重要手段。
表3：系统变更前安全检查矩阵表
对于新建外包开发系统，安全人员可在设计评审前收集SBOM，对使用的开源组件合规和漏洞情况进行评估审查，明确需要整改的组件，提前发现和预防组件风险，做到安全左移。安全检查流程大体如下：
图2：安全检查流程图
三、组织落实
漏洞管理工程涉及人员较多，明确工作责任，确保工作落实是做好漏洞管理的管理前提。
可建立漏洞管理职责清单，明确各负责人在漏洞管理相关职责，除履行职责范围内的漏洞修复以外，还承担如下具体职责：
|
成员 |
漏洞管理工作职责 |
|
总经理 |
监督漏洞管理各项工作落实。 |
|
运维组 |
1、建立windows、linux等操作系统，tomcat、各类中间件，各类数据库，openssh等基础软件的基线版本库，每年迭代更新，并确保新系统不得使用低于基线版本的软件。 2、建立操作系统、数据库、中间件、基础软件等安全配置指南，并确保新设备、系统按要求配置。 |
|
网络组 |
建立网络设备及网络管理相关系统的基线版本，每年迭代更新，新系统不得使用低于基线版本的硬件和软件。 |
|
开发组 |
协同建立开发语言、互联网开发组件基线版本库，每年迭代更新，新系统不得使用低于基线版本的软件。 |
|
安全组 |
1、建立漏洞管理规范、安全检查规范，组织开展各类安全检查，进行漏洞管理工作。 2、组织、协助和督促基线版本库的建设和迭代更新，检查基线版本库建设情况，提供安全技术支持。 3、初始化搭建漏洞修复知识库，协助后续漏洞修复知识库的管理和维护。 |
表4：漏洞管理工作中职责表
四、建立基线版本库
基线版本库是预防漏洞产生的重要防线，是隔绝历史漏洞的防火墙，基线版本库包括开发语言、通用软件、开源组件等。产品基线库以外，还应该有技术基线库，包括开发安全知识库、开发安全最佳实践、编码安全规范等开发知识库，作为安全开发的过程指引。1、明确开发语言基线版本，建立开发组件基线库，明确行内使用开发语言版本、开发组件的类型、基线版本，严禁使用低于基线版本的组件，并根据威胁情报，每年评估、更新和发布开发组件库的种类和版本。2、建立通用软件库，明确操作系统、数据库、中间件、基础软件等通用软件的类型、基线版本，并根据威胁情报，每年评估、更新和发布通用软件库的种类和版本。3、每年1月底前OA邮件发布下一年年度基线版本库，并将基线版本纳入设计评审，将基线落实情况纳入上线评审，严禁新上线系统使用低于基线版本的通用软件，减少新上线系统使用低于基线版本的通用软件。4、对于必须使用低于基线版本软件的系统，上线前应发起OA签报流程经部门负责人审批后方可上线。5、各类软硬件产品基线版本库责任划分如下：
|
序号 |
大类 |
产品名称 |
责任人 |
|
1 |
应用软件 |
web、app |
开发组*** |
|
2 |
应用软件 |
SDK |
开发组*** |
|
3 |
开发语言 |
php |
开发组*** |
|
4 |
开发语言 |
java |
开发组*** |
|
5 |
开发语言 |
C++ |
开发组*** |
|
6 |
开发语言 |
C |
开发组*** |
|
7 |
开发语言 |
.net |
开发组*** |
|
8 |
开发语言 |
python |
开发组*** |
|
9 |
开发组件 |
dom4j |
开发组*** |
|
10 |
开发组件 |
fastjson |
开发组*** |
|
11 |
开发组件 |
mybatis |
开发组*** |
|
12 |
开发组件 |
Spring系列 |
开发组*** |
|
13 |
开发组件 |
poi |
开发组*** |
|
14 |
开发组件 |
hibernate |
开发组*** |
|
15 |
开发组件 |
netty |
开发组*** |
|
16 |
开发组件 |
log4j、slf4j |
开发组*** |
|
17 |
开发组件 |
quartz |
开发组*** |
|
18 |
开发组件 |
log4j2 |
开发组*** |
|
19 |
开发组件 |
c3p0 |
开发组*** |
|
20 |
开发组件 |
Jackson |
开发组*** |
|
21 |
开发组件 |
httpclient |
开发组*** |
|
22 |
开发组件 |
vue |
开发组*** |
|
23 |
开发组件 |
JDK |
开发组*** |
|
24 |
开发组件 |
ibatis |
开发组*** |
|
25 |
开发组件 |
FastFDS |
开发组*** |
|
26 |
开发组件 |
rxjava |
开发组*** |
|
27 |
开发组件 |
RocketMQ |
开发组*** |
|
28 |
开发组件 |
quartz |
开发组*** |
|
29 |
开发组件 |
PhotoView |
开发组*** |
|
30 |
开发组件 |
greendao |
开发组*** |
|
31 |
开发组件 |
Glide |
开发组*** |
|
32 |
开发组件 |
EventBus |
开发组*** |
|
33 |
操作系统 |
AIX |
运维组*** |
|
34 |
操作系统 |
Windows |
运维组*** |
|
35 |
操作系统 |
Linux |
运维组*** |
|
36 |
数据库 |
ORACLE |
运维组*** |
|
37 |
数据库 |
MYSQL |
运维组*** |
|
38 |
中间件 |
APACHE |
运维组*** |
|
39 |
中间件 |
IBM MQ |
运维组*** |
|
40 |
中间件 |
kafka |
运维组*** |
|
41 |
中间件 |
redis |
运维组*** |
|
42 |
中间件 |
tomcat |
运维组*** |
|
43 |
中间件 |
zookeeper |
运维组*** |
|
44 |
中间件 |
weblogic |
运维组*** |
|
45 |
中间件 |
nginx |
运维组*** |
|
46 |
基础软件 |
Vmware |
运维组*** |
|
47 |
基础软件 |
openssh |
运维组*** |
|
48 |
基础软件 |
NTP |
运维组*** |
|
49 |
基础软件 |
FTP |
运维组*** |
|
50 |
基础软件 |
samba |
运维组*** |
|
51 |
基础软件 |
smb |
运维组*** |
|
52 |
基础软件 |
WebSphere |
运维组*** |
|
53 |
基础软件 |
Allegro RomPager |
运维组*** |
|
54 |
基础软件 |
MS SQL SERVER |
运维组*** |
|
55 |
基础软件 |
Serv-U |
运维组*** |
|
56 |
基础软件 |
Windows RDP |
运维组*** |
|
57 |
基础硬件 |
网络设备 |
网络组*** |
|
58 |
基础硬件 |
安全设备 |
网络组*** |
表5：基础软硬件版本管理责任表
五、建立安全配置上线指南
1、建立应用系统、开发组件、操作系统、数据库、中间件、基础软件等安全配置指南，上线前指定专人按照指南配置，并经他人确认、复核后方可上线。2、实施运维标准化建设，实现日常流程标准化、操作系统标准化、中间件标准化、应用部署标准化、集成发布标准化、监控指标标准化、日志规范标准化。3、新系统正式上线前应对软硬件基线版本、安全配置情况进行检查，检查结果作为上线评审依据，确认无误后方可上线。
六、漏洞修复知识库
1．建立漏洞知识库，提供一个全面、权威和有效的漏洞修复指导方案库，能保证漏洞修复工作能更有效进行，减少漏洞修复的失败率。2．漏洞知识库内容包括：Web漏洞修复知识库、APP漏洞修复知识库、主机漏洞修复知识库、中间件漏洞修复知识库、其他通用软件漏洞修复知识库。3．漏洞知识库的组成部分应包括：漏洞类型、漏洞名称、产生原因、危害、修复建议、利用方式、案例、真实案例。其中“真实案例”由录入的漏洞修复后脱敏提取。4．漏洞修复知识库的建立来源主要如下:参考漏洞扫描设备的标准解决方案作为基础；利用多方威胁情报数据，录入更多的解决方案作为参考；人工定期整理已验证过的漏洞修复方案作为权威标准方案。5．开发、测试、运维人员可以自助学习漏洞知识库的内容，了解漏洞原理及修复方法，当开发在开发某功能时，可以查看会出现哪些漏洞。如：登录、注册、密码找回等。6．互联网系统大版本升级前进行一次开发安全技术培训，并定期从漏洞知识库中抽取内容组织开展开发安全开发技术培训、安全测试培训。
漏洞管理的理念应该是“管理前置，迭代更新；预防为主，修复为辅”。故本部分内容主要介绍为预防漏洞采取的一些举措，不同企业网络安全水平参差不齐，对网络安全投入不一样，可以适当裁剪或深化。
如有其他更行之有效的漏洞预防措施，欢迎交流和分享。
第四部分 术与开流
节源是未雨绸缪，目的是预防和减少漏洞的产生，但不能避免新漏洞的威胁。当存量资产命中新漏洞后，漏洞修复成了必然的选择。开流是亡羊补牢，目的是及时发现和处置漏洞，避免造成更大的隐患。为提升漏洞修复效率，抓住漏洞修复的重点工作，防患于未然，降低整体安全风险，公司启动了漏洞治理实践活动。本部分主要介绍漏洞管理平台建设的实践经验。本部分的理念是以全面的资产发现为基础，以数据存储和治理为核心，以多源采集为提升，以漏洞优先级为衡量基准，以管理体系为抓手，实现全网资产、漏洞的全面、闭环管理。
一、漏洞发现能力建设
（一）漏洞来源分析
做好漏洞管理工作的前提是能发现风险、检测出漏洞，本部分不探讨0day漏洞的发现和处置，仅分析常规漏洞。目前行业上常规的web扫描器、漏洞扫描器、开源组件分析工具、代码审计工具等均已较为成熟，开箱即用，使用技术门槛较低。而渗透测试、攻防演习等才是漏洞发现能力建设需要持续投入和保持技术迭代更新的。漏洞来源主要包括上线前检测、常规检测、外部威胁,具体如下：
图3：漏洞来源图
应采取技术和管理手段逐步扩大漏洞发现力度和深度，扩大自主主动发现漏洞比例，深化定期检测效果。如渗透测试服务，可采取多家供应商竞争比赛、交叉检验的方式，有条件、公司允许的的还可以采取SRC提高漏洞发现能力。如攻防演习服务，可采取按发现漏洞的效果付费模式，或引入多家同时比拼，运动式的一年多次开展。但这种运动式的演习并不能检验企业常态化网络防守能力，故可以采取无人防守干预的分批演习模式，固定演习目标，防守方无人值守，演习后攻防双方面对面复盘攻击和防守情况，检验企业日常安全防护的有效性。在建设漏洞发现能力时，如何做好漏洞发现自动化也是需要考虑的问题，包括：自动化扫描、自动化入库、自动化定级。
（二）漏洞检测左移
漏洞检测左移不同于预防漏洞，而是提前发现和处置漏洞，都知道漏洞修复成本在生产阶段的成本最大，那么与漏洞赛跑，提前发现并处置漏洞就尤为重要了。在项目设计阶段，将安全需求纳入需求管理，对系统的SBOM、安全需求对标结果进行评审，提前发现组件漏洞，并确保安全需求的执行；在项目开发阶段，对开发人员进行培训，使其学会使用源代码扫描工具，实时扫描代码漏洞，及时处置代码问题；在项目SIT阶段，部署IAST插桩节点，进行交互式漏洞检测，提前发现web和组件漏洞；在项目UAT阶段，进行上线前的漏洞扫描和渗透测试，经整改确认后，方可通过上线评审。
（三）漏洞检测常态化
制定资产测绘和漏洞扫描方案，针对互联网边界等重点区域的加大扫描密度，如每周、每月，非重点区域的以满足合规为目标，可以每季度扫描一次。
|
检测内容 |
频率 |
执行方式 |
|
互联网资产测绘 |
每周 |
定时任务 |
|
网银区内网资产测绘 |
每月 |
定时任务 |
|
内网资产测绘（全覆盖） |
每季度 |
定时任务 |
|
内网POC漏洞巡检 |
每月 |
定时任务 |
|
漏洞扫描 |
每季度 |
手工执行+现场值守 |
表6：漏洞检测工作表
二、漏洞分类
漏洞管理的范围包括通过手工或自动化工具发现的应用软件（web、app、SDK）、开发语言、开发组件、通用软件（操作系统、数据库、中间件、基础软件）等的漏洞。包括但不限于行内、行外安全评估、检测发现的漏洞以及第三方通报的漏洞。
基于目前行业态势及管理需要，漏洞分为四类：IP类、web类、组件类、合规类。
|
漏洞分类 |
支撑库 |
漏洞来源 |
关键工作 |
|
IP类 |
IP资产库 |
资产测绘、各类主机扫描产品 |
1、资产覆盖 2、漏洞精确度 3、优先级技术 4、交叉验证 |
|
Web类 |
Web资产库 |
资产测绘、攻防演习、渗透测试、web扫描、IAST等 |
1、实施频率 2、实施深度 3、覆盖范围 |
|
组件类 |
组件库 |
SBOM评审、SCA分析、IAST |
1、优先级技术 |
|
合规类 |
/ |
监管、三道防线检查发现的管理问题。 |
/ |
表7：漏洞分类表
三、漏洞分级
根据《网络安全漏洞分类分级指南》（GB/T 30279-2020），漏洞分技术分级和综合分级两个等级，均分为超危、高危、中危、低危。
|
漏洞级别 |
定义 |
|
超危 |
漏洞可以非常容易地对目标对象造成特别严重后果。 |
|
高危 |
漏洞可以容易地对目标对象造成严重后果。 |
|
中危 |
漏洞可以对目标对象造成一般后果,或者比较困难地对目标造成严重后果。 |
|
低危 |
漏洞可以对目标对象造成轻微后果,或者比较困难地对目标对象造成一般严重后果.或者非常困难地对目标对象造成严重后果。 |
表8：漏洞分级表
技术分级为漏洞原始等级，由漏洞本身被利用性（访问路径、触发要求、权限要求、交互条件）和影响程度（保密性、完整性、可用性）两个指标类决定。综合分级为以技术分级为基础，综合影响范围、被利用成本、修复难度等环境因素后得出的综合风险等级，更客观地为漏洞修复提供了参考依据。
表9：漏洞综合分级表
但综合分级仍旧仅仅能表明漏洞本身的安全属性，不能直观、明了的给出相同漏洞在不同网络环境、不同资产的整改排期。故开展漏洞治理工作势在必行。
三、漏洞管理目标
如果没有基于风险的漏洞管理方法，企业将无法面对不断增长的漏洞威胁。漏洞管理的目标是建立一套流程化、规范化、数据化的漏洞管理机制，实现漏洞全生命周期闭环管理，对web漏洞、主机漏洞、组件漏洞、合规漏洞进行系统化、流程化管理。
图4：漏洞管理目标图
基于以上工作目标，总体实施设计如下：
图5：漏洞管理设计方案图
四、平台架构设计
漏洞管理平台是资产、漏洞的统一管理平台，也是漏洞检测任务的统一扫描平台，通过其建立扫描任务，自动执行扫描，实现漏洞的集中化管理。漏洞管理平台架构设计如下：
图6：漏洞管理平台架构图
架构中重点需要运营的有3个资产库和3个漏洞库，资产库包括IP库、Web库、组件库，漏洞库则包括主机漏洞库、Web漏洞库和组件漏洞库。IP库应包括IP资产的操作系统版本、IP、端口、网络分区、所属环境、网络边界类型、中间件及版本、服务信息、数据库及版本等等。Web库应包括该站点所有URL、API清单、Request、Response，API、URL可依赖API安全产品集成收集。组件库应包括该应用系统使用的所有开源组件名称、版本、组件类型、开源协议类型、推荐版本、最新版本等等。资产来源越广、资产属性越全，越能提高资产和漏洞管理效率。五、资产管理设计资产管理架构从上至下分别为组织架构、应用系统、资产、漏洞四个层次，漏洞依附于资产，资产属于应用系统组成，而应用系统是归属不同组织下。组织架构：可设置为部门-中心-组架构，或者集团-分公司-部门-组架构。
应用系统：不同分组负责不同的应用系统，应用系统可以从公司CMDB或者管理平台同步，同步的要素包括但不限于：系统名称、系统分类、业务分类、系统状态、等级保护、重要程度、开发公司、技术团队、开发负责人、运维A角以及其他自定义属性及枚举值。
资产数量、漏洞数量则是应用系统下不同类型的资产数量和对应漏洞数量的整合展示，便于应用系统负责人和安全人员快速了解应用系统的整体安全态势，也方便安全人员快速排查无资产的应用系统。
资产：应用系统下分IP类资产、web类资产、组件类资产，资产来源包括CMDB、HIDS等各类资产管理工具以及资产测绘、RSAS等各类漏洞检测工具。目前资产属性包括：资产类型、应用系统名称、资产地址、资产名称、资产负责人、资产来源、网络环境、网络边界类型、资产状态、漏洞优先级以及其他自定义属性及枚举值。除此之外，平台还存储了同步来的其他资产属性，包括服务、端口、协议等开放的服务端口，软件名称、版本、厂商等使用的软件信息（由于本期重点为漏洞管理，故资产部分未进行精细化设计和整合处理）。
漏洞优先级为根据资产安全属性、漏洞原始级别以及威胁情报经过二次定级后的漏洞等级，展示的是该资产下现有漏洞情况。当发现新漏洞需要录入时可编辑该资产添加漏洞。
漏洞：经过梳理，不同类型漏洞的字段大体相同，故漏洞页面整合了IP类、web类、组件类、合规类四大类漏洞，可根据需要筛选各类型漏洞。目前漏洞属性包括：漏洞分类、应用系统名称（如有）、资产地址、漏洞名称、漏洞级别（原始等级）、漏洞优先级（二次定级）、漏洞来源、漏洞类型、漏洞描述、修复建议、修复期限、修复负责人、检测详情、发现状态以及检查名称等其他自定义属性及枚举值。
点击流程按钮，可以看到漏洞时间线：
图11：漏洞流程页面展示图
六、管理流程设计
漏洞状态共分为待派发、待确认、修复中、待复测、复测已通过、复测未通过、待审核、关闭。大致流程如下：
图12：漏洞管理流程图
待派发：同步、导入、录入的漏洞初始状态为待派发，需经过安全人员验证、审核后派发给整改责任人。待确认：可将不是自己的漏洞转办给其他负责人，在此过程中需确认漏洞负责人是否准确，漏洞是否误报，是否修复，以及确认出修复方案。
待审核：由所属主管对确认环节提交的申请不修复、申请误报、申请延期等的进行审核，审核后提交安全人员确认。修复中：确认完成后即进入修复中，待修复后即可反馈已修复，之后进入安全人员的待复测环节。待复测：复测结果如为复测通过的即进入上线环节或关闭，复测结果如为不通过则退回至修复中，直至复测通过。上线：漏洞洞负责人需点击上线，方可完成漏洞闭环（主要针对web漏洞和组件漏洞，因为该类型漏洞一般在测试环境修复后复测，需正式投产到生产环境才算漏洞修复，故需在上线阶段登记何时上线，确保漏洞整改已完成生产变更）。关闭：经确认为误报、不修复、已修复的漏洞会处于关闭状态。在漏洞流程管理上明确了以下要求：1．漏洞整改责任人收到漏洞信息后，应立即分析漏洞的情况，对漏洞进行接收和确认，做出漏洞修复方案和计划，对于计划整改的根据漏洞等级立即整改，对于无法整改或接受风险的漏洞反馈不整改的原因。2．整改责任人在漏洞整改完成后在漏洞管理平台中标注已整改，提请安全管理员进行复测，如果复测发现漏洞依然存在，则归为修复失败，对于修复失败的漏洞重新转换到漏洞发现状态。3．安全管理员复测确认已整改后，在漏洞管理平台中登记确认已整改，完成漏洞的整改闭环流程。
4．对于存在风险但修复成本过高或无法整改的漏洞，漏洞整改责任人应在接收到漏洞后，反馈不整改的意见，经安全管理员确认，安全管理员确认后必须整改的则进入整改流程。
七、漏洞管理流程
发现漏洞是漏洞管理的基石，有效管理并快速响应漏洞则是挑战。
（一）资产/漏洞入库
自动入库：漏洞管理平台对接了CMDB 、IAST、HIDS、RSAS等资产管理工具或漏洞发现工具，实现资产、漏洞的自动入库，提高漏洞管理自动化水平；手工导入：针对内外部检查检查发现的非标准化问题，安全人员应先对漏洞内容进行初步确认，明确漏洞修复优先级，并进行分工，再导入漏洞管理平台。下发扫描任务：定期的漏洞扫描可通过漏洞管理平台进行任务下发，扫描完成后漏洞自动解析入库。
（二）资产定级
在进行漏洞扫描或者资产同步时，可根据入库IP自动赋值网络分区、网络边界类型、主机环境等资产网络属性，同时继承应用系统的保护等级和重要程度。
图14：资产属性配置页面图
根据内外网关联清单，可快速查找互联网边界资产对应内网资产。
图15：内外网IP关联页面图
（三）漏洞优先级
权威报告显示传统的漏洞整改可能做了76%的无用功，仅有3%的漏洞应优先关注。76%的无用功：在每年新发现的漏洞中，即使安全团队修补了所有高危和严重漏洞，也不过修复了24%的可利用漏洞，有76%的时间消耗在短期内几乎无风险的漏洞上，有44%的短期可被利用的漏洞被评为中低风险，很可能被忽略掉。3%优先漏洞：Tenable通过对20万亿漏洞情报等数据进行人工分析和机器学习后认为安全团队应该优先关注的漏洞占所有漏洞的3%左右围绕漏洞可利用性和关键性对漏洞进行优先级排序是开展漏洞管理的首要目标。主机漏洞的发现能力容易建立，攒漏洞扫描设备即可，但主机扫描产品、SCA工具扫描出的漏洞都是海量的，但从海量漏洞里如何确定漏洞的整改优先级，这才是漏洞管理的核心，漏洞的优先级技术至关重要。漏洞的优先级不仅仅只考虑资产安全属性和漏洞本身属性，还应该考虑漏洞生命周期、漏洞情报以及漏洞标签等。
本方案中漏洞优先级根据配置的风险值自动自动赋值风险优先级，风险值范围和修复期限均可自定义，平台会根据漏洞优先级自动赋值修复期限。
图16：优先级设置页面图
风险值的计算根据资产安全属性、漏洞属性、漏洞生命周期、漏洞情报属性等综合计算而来：
图17：优先级权重配置页面图
资产安全属性可考虑的有：等级保护、重要等级、设备类型、资产状态、网络环境、网络边界类型等等。
图18：资产属性权重配置页面图
漏洞安全属性包括：漏洞的原始CVSS分值、录入时漏洞的原始等级、漏洞类型、公布时间长短、敏感端口服务等。
图19：漏洞属性权重配置页面图
生命周期属性包括漏洞发现方式、发现状态、修复是否超期等，情报则包括是否有POC/EXP、网关防御规则是否有效等。
图20：漏洞生命周期权重配置页面图
设置好各类安全属性的数值，再使用平台的风险计量工具校验和微调，直到不同类型的组合计算能满足预期结果。如：
1、在线预发布、直接接入互联网的资产命中超危漏洞，漏洞优先级为高危。
图21：漏洞风险计算页面图
2、在线、预发布、非直接接入互联网的资产命中超危漏洞，漏洞优先级为中危
（四）漏洞派发
漏洞优先级确定好后，可根据漏洞标签、漏洞优先级综合考虑后将漏洞派发出去或者直接置为不修复。对应不同优先级的漏洞可设置不同的修复期限、漏洞通知，根据漏洞优先级设定的整改时限，设置修复计划时间，修复计划时间到期，自动发送邮件至系统负责人邮箱提醒，参考如下：
|
漏洞优先级 |
漏洞修复期限 |
漏洞即将到期通知 |
漏洞响应期限 |
整改要求 |
|
超危 |
10 |
<5天 |
≤0.5天，人工通知 |
必改，紧急处置。 |
|
高危 |
30 |
<10天 |
≤1天，人工通知 |
必改，尽快处置。 |
|
中危 |
90 |
<20天 |
≤5天，邮件督办 |
必改，及时处置。 |
|
低危 |
360 |
<30天 |
≤5天，邮件督办 |
部分漏洞经评估后可接受风险，排期处置。 |
表10：漏洞修复规则表
漏洞派发前的关键工作包括：
1．如何实现漏洞管理自动化，如可以根据url/app名称/ip/机器名自动匹配整改责任人。
2．如何漏洞整改智能化，如在录入选定某一类安全漏洞的时候，可以自动弹出该类漏洞的的修复方案和风险。
3．如何实现漏洞分派的智能化，自动根据资产责任人、漏洞情况分发漏洞。做好这些，漏洞派发效率也能大大提升。
（五）漏洞督办
漏洞整改不是目的，应以漏洞整改督办促进开发、运维重视漏洞管理工作，指引做好漏洞的预防工作。分发后的漏洞需要及时通知漏洞修复负责人跟进，并及时通报超期未处理的流程和即将到期的漏洞，故可设置以下几类通知：(1)新增待办通知：每日早上自动邮件告知责任人有新增的漏洞，督促其处理漏洞流程。(2)漏洞确认超期通知：每周一早上统计超期未修复漏洞和超5天未确认漏洞，邮件通知责任人处理。(3)漏洞即将到期通知：每周二早上统计即将到期的漏洞，邮件通知修复负责人及时跟进。
针对邮件通知仍不处理的，可每月统计和通报至领导群。同时，可将漏洞通知推送至IT运维平台或科技管理平台展示，提高漏洞通知的触达率。在做漏洞督办管理时的关键点包括：1．漏洞修复数量化，需对修复漏洞数、修复漏洞耗时、修复漏洞成功率等漏洞修复成果进行统计和展示。2．漏洞督办自动化，对于超期未确认、临期的漏洞，漏洞管理平台可以有节奏的提醒责任人修复漏洞。
漏洞管理是一项精细化的运营工作，也是一项需要长期投入但又默默无名的工程。漏洞管理的成功运营离不开以下三点：
1、企业对漏洞治理工程的财务支持，以及相关单位对漏洞运营的技术支撑；
2、漏洞运营人员需要对企业网络资产有清晰的认识；
3、漏洞运营人员需要了解各类漏洞的原理和防范，对漏洞有一定的技术功底。经过半年的功能完善和漏洞运营，完成了2万余个漏洞的闭环管理，但仍有大量漏洞未能完成分析和闭环，漏洞管理工作任重而道远。
第五部分 展望
近两年，监管通报漏洞和漏洞情报日益增多，存在漏洞的软件是否有使用？版本是否命中，命中的资产是否需要立即处理？如何快速响应漏洞情报，快速定位受影响资产是亟需处理的技术问题，而这个问题的根源便是是否实现全面、深入的资产安全管理。只有全面的资产管理，才能在排查漏洞时快速定位漏洞影响的资产，开展漏洞的应急处理，只有有机整合了资产、漏洞和情报的平台才能发挥资产安全管理的价值。一、全面的资产安全管理截至目前，漏洞管理平台已接入大多数资产管理工具，但目前用的比较多的漏洞管理，未进行更深入的资产安全管理工作，未来，全面、深入的实现资产安全管理是下一阶段的重点。资产的全面管理就得考虑资产的覆盖面，包括：CMDB主机资产覆盖率、HIDS资产覆盖率、EDR资产覆盖率、漏扫覆盖率、重要资产堡垒机纳管率。资产的深入管理就得考虑资产属性的全面性，包括：端口、服务、版本······以及更多可丰富资产安全属性的内容。
二、联动的资产漏洞情报
HW期间，漏洞的应急处置离不开情报，而漏洞情报又是以标签化形式展示的，所以提供一套科学、合理的漏洞标签，能大大提高漏洞派发效率。基于目前行业对于漏洞标签暂未有更好的实践和分类，各家漏洞标签的做法各式各样，漏洞分类、关键漏洞目录、漏洞类型、POC/EXP、勒索、APT、重保、是否重启······都是漏洞标签。基于漏洞库数量较大，漏洞标签运营维护成本较高，各家仍存在标签体系混乱、标签内容不准的问题，希望未来能有更体系化、更具象化的漏洞标签，能够实现漏洞标签与优先级自动化关联定级。
三、更精准化的组件漏洞检测
截至目前，漏洞管理平台仅接入了IAST检测发现并经确认需要修复的组件漏洞，暂未进行更深入的组件漏洞管理和运营。组件漏洞的数量比IP类的会更多，海量组件漏洞里哪些需要先修复，做好VPT是关键。SCA产品有用，但扫出来的漏洞太多，基于目前的人力物力，依靠自身基本没法用起来，期望未来能有更完善的解决方案，不只是把漏洞扫出来，而是能漏洞整理出来，建议用户先处理哪些。
关于组件漏洞的二次定级个人认为可以综合考虑这些方面：
1、资产安全属性：是否互联网系统、重要等级等；
2、组件安全属性：web前端类、后台类、数据库类等，直接依赖、间接依赖等；
3、漏洞安全属性：利用难易、远程/本地、漏洞危害等；
4、漏洞修复属性：底层代码更新、组件升级、影响范围大小、修复难度（杠精：难道漏洞难修就排后面不修了么？非也！需要修的漏洞很多，考虑此属性，更多的是希望把钱和精力花到刀刃上，达到更高的投入产出比）；
5、漏洞情报属性：POC、EXP、利用可达性。
转载，侵权请告知删除！
