2024年6月10日发(作者:)

Information Security

信息安全

对系统安全漏洞修复的认识及思考

中国光大银行信息科技部 邹秋波 刘凌志

说到安全,大家经常谈的可能是网络安全、纵深防

御、主动自适应防御等偏宏观的话题,也深知系统安全

漏洞的危害和及时修复的必要性。本文拟从微观角度,

从银行系统安全漏洞修复实践出发,阐明漏洞修复分

析评估及基本原则、经验总结思考及未来展望。抛砖

引玉,希望能和大家一起重新认识和理解系统安全漏

洞修复工作,共同改进和提升漏洞修复工作方式、技

术手段和效率。

出现,系统安全加固工作依然任重而道远。

二、对漏洞修复工作应有的基本认知

1.漏洞修复工作做不到一劳永逸

每月都会持续有新的漏洞出现,银行需经年累月持

续、连续地投入,扎实做好系统安全加固工作。根据

CVE公布的近几年系统环境中几个典型组件发现的漏洞

数量(见表1),可以看出,即使是同一个组件,几乎

每年都会出现新的漏洞。

一、系统安全漏洞现状

近年来,随着银行业务逐渐迁移到通用平台以及开

源组件在银行的大规模使用,银行面临的安全漏洞风险

也在扩大。安全公司WhiteSource发布了一份2019年开

源安全漏洞现状报告

The State of Open Source Security

2.组件之间关联依赖性导致修复成本大幅提升

开源软件之间存在大量关联依赖,存在安全风险放

大作用,只要一个开源软件出现漏洞,就会导致依赖它

的其他开源组件受到间接影响,组件之间这种层层关联

依赖,导致管理和修复开源软件漏洞极其复杂。此处以

与OpenSSL关联的组件为例说明(见表2)。

从表2中可以看出,一个简单的OpenSSL组件的

升级,同步需要进行升级或者是调整的其他组件数量在

Redhat7版本上达到了204个,而这么多组件的升级调

整,对应用可能产生的影响已经无法简单从技术原理层

面进行评估,最后只能通过系统性的测试来规避升级风

险,而系统性的测试无疑为漏洞修复带来很大的成本。

Vulnerabilities

。报告表明,2019年全球披露的开源安

全漏洞数量再创新高,比2018年增长近50%,开源软

件的安全漏洞很突出。

有效的安全漏洞补丁管理可以让管理员有机会在攻

击发生之前修复或规避漏洞风险。光大银行一向重视系

统安全漏洞的修复,出台了多项系统安全漏洞管理制度,

执行也比较到位,最近两年系统管理团队逐一排查外部

通报系统安全漏洞共计1000余个,排查集中漏扫漏洞

8000余个,通过集中组织漏洞修复和安全加固工作,现

有生产系统的漏洞大幅减少。然而,随着新的漏洞不断

三、漏洞影响及修复评估

银行业务系统可用性要求一向很高、很严格。不同

2021 . 04

中国金融电脑

65

INFORMATION

SECURITY

表1 2015-2019年系统环境中几个典型组件发现的漏洞数量

漏洞类型

Kernel

Glibc

OpenSSH

NTP

WebLogic

JDK

2015

107

10

5

25

5

Null

2016

125

7

10

28

20

Null

2017

176

12

1

10

14

3

2018

71

1

7

5

19

2

2019

216

10

1

2

27

2

表2 与OpenSSL关联的组件(

未统计间接依赖OpenSSL的组件数量

OS版本

SuSE11SP4

SuSE12SP3

Redhat 7.x

直接与OpenSSL依赖的组件数量

136个

97个

204个

的开源组件由社区不同的群体维护,而不是一家公司维

护,为了保证业务系统的连续性、稳定性和适配性,在

现有的技术条件下修复漏洞不仅需要简单安装或升级补

丁包,更需要进行全面评估和测试。如何确定评估的基

本原则,以银行使用最广的Linux开源操作系统为例,

从简单的层次结构(如图1所示)可以看出,最核心的

是Kernel层,中间是各种基础库和应用库接口,上层是

各类应用和工具等。

上层依赖下层,下层的变动会对上层造成影响,同

一层的组件也会有依赖影响。根据重要性和影响的范围,

确立如下四个基本修复原则。

2.批量修复

适用场景:对于依赖关系复杂,功能紧解耦、影响

较大的组件,特别是涉及应用与操作系统之间的API调

用接口,如Kernel、Glibc等组件漏洞,通过分析变动

情况评估影响,从复杂程度、时效及准确性看已不具备

可行性,需要经过功能及非功能测试。

3.综合修复

适用场景:漏洞除了涉及系统组件外,还涉及中间

件、数据库等组件,修复周期相对较长,进行合并修复

同样需要经过功能及非功能测试。

4.紧急修复

适用场景:对于危害等级极高的漏洞来说,因漏洞

威胁造成的风险可能会造成极为严重的影响,为了及时

修复漏洞,需要容忍试错,跳过各种影响评估,按照容

错的机制,简单验证之后分批分步直接在业务系统上进

行漏洞修复。

1.独立修复

适用场景:适用于依赖关系简单、功能相对独立

的组件,对其他组件特别是上层应用基本无影响。如

OpenSSH、NTP等组件漏洞,功能测试通过即可进行生

产修复。

66

FINANCIAL COMPUTER OF CHINA

监控等专用软件

管理系统调用议栈

……

调试工具

内核模

异常

……

Information Security

信息安全

应用层

库(Libraries)

内核(Kernel)

硬件或虚拟化层

图1 Linux开源操作系统层次结构

四、总结思考

通过上述思考、分析,笔者总结如下:

3.非标版本和非标使用的漏洞会带来高额的修复

成本,很可能无法及时修复

下面这几种典型场景会使得漏洞修复更复杂,影响

更难评估,修复成本更高。

(1)超出行内技术产品目录范围的组件。银行对

这类组件缺乏标准规范、安全基线以及足够的了解,修

复起来需要逐一分析,修复方案无法横向推广。

(2)采用的技术产品属于行内技术产品目录已引

入的产品,但使用的版本与行内当前主推版本不一致。

(3)随着时间的推移,以前的主推版本往往因为

厂商对此版本的功能受限、支持到期或者有严重的缺陷

无法维护而变成非主推版本。在非主推版本上执行漏洞

修复同样变得困难重重,甚至因为厂商无法提供非主推

版本的补丁而无法修复。采用了行内技术产品目录推荐

的主推版本,其使用方式与行内标准使用规范有差异,

若出现漏洞会带来高额的修复成本。

这几类使用场景因为安装使用配置的环境有差异,

无法采用按照标准使用规范制定的横向修复方案,需要

1.漏洞修复太快,补丁本身不稳定或有缺陷时,

易引入新问题

以2018年初的Intel CPU漏洞修复为例,按照超高

危进行修复,拿到漏洞补丁按分批分次原则修复,修复

完主机后在观察期内收到通知,此补丁有缺陷,存在服

务器重启的问题。备机暂停实施,导致在一段时间内出

现主备不一致的情形。

2.系统需要做好持续进行各类组件漏洞修复工作

的准备

漏洞库更新速度快、种类多、数量大,不同组件上

出现漏洞的时间是随机的,系统需要做好持续进行各类

组件的漏洞修复工作的准备。系统本身由多种系统软件

组成,包括OS、中间件、数据库、第三方软件等众多

领域和组件,漏洞发现时间不一,评估处置方案各不相

同,系统面临持续修复或升级各组件情况。需要从思想、

技术方法、自动化工具上以及资源上做好各项准备。

2021 . 04

中国金融电脑

67

INFORMATION

SECURITY

耗费大量的时间去逐一分析和制定修复方案。对已知漏洞或威胁作出处理。而现实中各类0day漏洞、

系统组件漏洞层出不穷,各种漏洞威胁被利用来攻击的

特征也在不断变化,传统的发现、防御、响应、修复的

理念在效率、效果和成本上越来越力不从心,难以为继,

这种被动的模式并不理想。

随着可信理念的普及和技术的逐步成熟,银行开始

试行和推广可信技术,未来可以建立起一套全新的理念,

即无论利用安全漏洞开展攻击的形式和方法如何变化,

只要监控了系统里面的操作行为,就能判断和预警哪些

行为动作是非法的,可以按照安全策略采取阻断、隔离

动作,不再完全依靠漏洞是否已知、漏洞是否已被修复、

漏洞行为是否可测等旧有标准。

可信技术通过集中和代理方式,在受保护的主机(物

理机或虚拟机甚至容器)上获取当前主机行为模型,包

括系统进程、数据处理和主机资源状态,根据业务系统

特点及资源使用模式建立合理的可信行为基线或建立白

名单,这些数据发送到可信平台进行集中分析、展示和

管理。以此为基础,可通过系统用户、进程、资源画像、

智能监控和审计回溯追踪等机制的联合作业,构筑主

机服务器新的安全框架体系。在此新安全体系下,即

便非法入侵者获得了该服务器的最高控制权,也无法

加载用于实施破坏的系统后门、病毒、渗透攻击等恶

意程序,从而极大程度地限制了入侵手段,降低了风

险损失。

五、未来展望

1.新技术架构的落地成熟有望带来新的系统漏洞

修复方案

在目前的系统基础架构下很难做到漏洞随时修复、

无影响修复,需要通过测试后,按照分批分次的方式进

行修复,如果修复出现了问题后回退步骤也同样耗时耗

力,难以实现自动化、智能化。可喜的是,随着云平台、

容器云平台等新技术的落地推广及功能逐渐完善,搭载

的系统有望借助云的弹性伸缩、灰度发布、AB部署等

新技术手段来开展漏洞修复工作,在模式成熟后可以优

化整个漏洞的评估、修复方式和要求,高效低成本完成

系统安全漏洞的修堵。

2.针对性加强和引入补丁管理工具

正因为开源组件之间存在大量关联依赖,必须依靠

系统化的工具来完成。通过SMDB平台等各类工具,

基本上能做出相关评估判断,但仍然需要投入大量的人

力和资源。通过引入更为针对性的开源操作系统管理

工具,实现对操作系统版本信息、补丁信息以及各组

件版本和配置的集中管控,进而实现效率提升和安全

漏洞管理,为业务快速发展和安全防护提供更为高效

的技术支撑。

3.开源操作系统组件定制化

开源组件越多,受漏洞影响的风险越大,需要操作

系统提供更为精准、高效的技术组件支持。通过深入研

究开源操作系统,可以对开源操作系统及其上层基础组

件进行裁剪、定制,对云技术、AI、5G、大数据、区块

链等各类新技术领域中必须的技术组件进行集成封装,

进而实现效率提升和应用的快速部署。同时在满足业务

的基础上,通过剔除部分高风险组件、加固必要技术组

件等方式提升系统安全性。

信息安全工作是动态发展、不断变化的。为了把好

系统安全大门,应对挑战,银行应不断主动地去优化流

程、工艺,引入新的技术手段和方法,加强风险防范,

在保证系统安全合规的同时,全力做到漏洞修复业务无

感知,不降低系统可用率,实现科技为业务保驾护航,

助力业务发展。

栏目编辑

:伍曼

*************.cn

4.可信技术

目前,漏洞修复工作还是基于发现或者知情的前提,

68

FINANCIAL COMPUTER OF CHINA