高效漏洞管理的六个锦囊

安全 应用安全 漏洞
只有准确地对漏洞进行风险评估,才能真正地改善漏洞管理。对此,建议从以下六个方面,提高漏洞响应优先级排序的效率。

对于资产拥有者而言,漏洞是让人厌恶的东西。但对于黑客而言,漏洞则是他们最喜欢的“高价值资产”,它们可以为黑客带去源源不断的收益价值。举个简单例子,黑客通过系统漏洞进入服务器内部,一方面可以通过非法盗取数据信息在黑市上变现来获得经济收益,另一方面也可以将那些被控制的“肉鸡”作为攻击其它网络平台“滩头阵地”的武器。

[[317852]]

层出不穷的漏洞让安全人员的工作不堪重负。但是,想要将所有漏洞一次性消除又几乎不可能。如果安全人员将注意力放在一些“无伤大雅”的小漏洞而长时间忽略严重的漏洞,这就犹如在粉刷一个随时会坍塌的屋顶一样滑稽。由于各个企业都有其自身的特点,因此需要对漏洞响应顺序进行优先级排序,需要了解每个漏洞对企业关键资产或业务造成威胁的严重程度。

正所谓,千里之堤,溃于蚁穴。一个小小的漏洞,也可能引发致命的危害。因此如何快速确定漏洞修复优先级,并以最快的速度修复关键漏洞成为了所有安全人员的头等大事。为此,根据我在网络安全服务领域多年来的从业经验,总结出了一个漏洞管理的关键策略:知己知彼,百战不殆。

一、知己:资产管理是风险评估的前提

当运行良好、风平浪静的时候,资产管理往往显得不那么重要,但是当遇到攻击时,就会让安全运营人员明白谁才是安全防护的先决条件。例如,爆发高危漏洞时,如果安全人员无法确定有哪些资产受到该漏洞的影响,想要确定漏洞修复优先级就犹如盲人摸象,无从下手。

因此,安全人员一定需要拥有一个完整的资产视图,并且能够做到实时了解其动态变化,此为“知己”,亦是漏洞管理的前提。毕竟任何人都无法对未知的资产进行风险评估,而它们也会成为黑客手中可以随时引爆的“隐形炸弹”。

资产管理的重要性不言而喻,但是99%企业IT人员都不知道自己拥有哪些IT资产。据全球权威IT咨询机构Gartner调查分析,在数据中心内有近28%的物理服务器是幽灵服务器或者是僵尸服务器。对于这些处于休眠状态的服务器,日常没有任何补丁更新。在这种情况下,如果需要启动服务器,比如查看网站的旧版本时,该服务器将会成为企业IT环境中风险最高且最易受攻击的服务器。攻击者完全可以利用这些老旧系统的漏洞为跳板,通过横向渗透攻击技术进入内网来访问其它主机,获取包括邮箱、共享文件或凭证信息在内的敏感资源。在此基础上,进一步控制其它系统、提升权限或窃取更多有价值的数据。这对于企业的安全人员来说,简直就是一场噩梦。

因此,我认为,资产管理是安全的前提,但良好资产管理方案需具备以下二个方面的能力,包括资产清点的能力和资产关联的能力。

1. 理得清:资产的全面清点

企业必须清楚自己的所有资产(包括硬件和软件),比如自己企业中有哪些服务器,分别运行什么软件,它们是如何打补丁的?如果你不知道自己拥有什么,就很难回答上述这些基本问题。

之前,一位甲方企业安全人员就跟我抱怨每天都过得“提心吊胆”。每当网上爆出一个0Day漏洞,安全团队想要尽快确认受该漏洞影响的服务器范围,以便在最短时间内做出应对。但是,公司业务复杂,安全管理人员甚至不知道企业有多少服务器,在服务器上运行的应用更是数不胜数。因此,只能通过公司发文,要求各业务线提交自身业务系统的部署情况。接下来就是漫长的等待,等待厂商漏洞通告,编写检测脚本查找存在漏洞的主机,等待厂商的漏洞修复方法,编写修复脚本,最后一台一台修复问题主机。

在整个事件响应过程中,安全人员不知道业务部门上报的资产全不全,也不知道检测脚本是否扫描到所有包含漏洞的主机,更不知道在此期间是否有黑客已经入侵到企业内部。这个漫长的等待过程,那些脆弱的主机资产就犹如砧板上的“鱼肉”任黑客宰割,安全人员却如同局外人一般,束手无策。

2. 看得透:资产的深度关联

资产的全面清点是资产管理的第一步,有助于企业生成完整的、不断更新的资产视图。但是如果针对资产收集的每条数据都很浅显,那么即使拥有完整的资产列表所能发挥的价值也是非常有限的。以主机资产为例,信息安全团队除了需要深入了解主机资产包括硬件规格、已安装的软件、已批准的账户、root权限和安装包等各方面信息,还需要了解这些资产之间的关联程度以及每类资产的重要性。

此时,如果拥有良好的资产管理,能够将资产数据通过API方式导入风险发现或入侵检测等其它系统并进行深度关联,这将会为安全人员采取安全防范措施提供极大帮助。例如,漏洞风险关联对应的软件应用状态,账号风险关联到对应的系统账号,反弹Shell关联对应的端口、进程等。只有这样,一旦现有资产存在对应风险或者被黑客入侵了,才能进行实时报警和提醒。

二、知彼:持续监控是漏洞响应的关键

除了对企业IT资产要有清晰而深入的了解,企业安全负责人还需要对外部漏洞风险情况有所了解才行,此为“知彼”。这包括行业协会、政府机构、学术研究人员、技术分析师和安全供应商等机构最新的漏洞披露情况。尤其是对那些可被利用的“零日”漏洞、可“横向移动”漏洞等外部风险状况需要格外注意。一旦发现新爆发的漏洞,应该立刻将漏洞规则包导入扫描系统,以便尽快对该漏洞进行检测。

虽然,黑客不会针对已发布的所有漏洞展开攻击,但他们会不断地扫描系统、软件中的关键漏洞。密歇根大学的一项研究表明,一台有开放端口或漏洞的服务器连网后,在23分钟内就会被攻击者扫描到,在56分钟内开始被漏洞探测,第一次被彻底入侵平均时间是19小时。

当然,扫描的频率决定了持续监控的可行性。如果每月扫描一次,甚至每个季度扫描一次,就很难为实时监控提供最新的数据信息。鉴于漏洞不断变化,因此,建议每天持续地扫描重要的、优先级高的核心资产。

基于Agent的持续监控扫描

新的漏洞每天都会出现、系统配置每分钟都在变化。同时,黑客通过对新技术的利用,攻击速度和能力都得到大幅提升。这些变化决定企业安全状态一直处于动态变化过程中,因此持续安全监控显得尤为重要。因此,安全人员需要通过专业的风险评估工具,对漏洞进行持续检测、移除和控制,来缩小攻击面。

当下漏洞扫描工具类型包括主动和被动两种,即基于Agent和Agentless。尽管Agentless监控解决方案和几年前相比,功能更加强大,但与基于Agent的解决方案相比,Agentless解决方案的应用往往极为有限。基于Agent监控的解决方案是通过监控操作系统内部运行的进程实现的,与Agentless解决方案相比,基于Agent的监控通常可以更深入地了解操作系统的运行状况。

基于Agent监控的解决方案如此强大的原因之一是因为它们可以监控终端多个层面的内容。当然,并非所有产品都会检查各个方面,但通常情况下,与Agentless产品相比,基于Agent解决方案的产品能够提供更细粒度的主机运行状况。

漏洞

基于Agent的监控

虽然很难否认Agentless监控的便利性,但是Agentless解决方案依赖于通过网络段“嗅探”或查询从网络端点获取的数据,这些方法获得的监控数据类型有限。基于Agent的解决方案可以直接访问受监控的端点,因此能够获取非常细粒度的监控数据。

据研究表明,Agentless和基于Agent的IT系统管理解决方案的性能下降基本相同。但是,基于Agent的解决方案提供了固有的可用性和安全性优势,包括在网络中断期间管理系统的能力以及无需额外配置即可管理防火墙周围系统的能力。

由于基于Agent的解决方案和Agentless解决方案各有优缺点,因此一些供应商使用混合监控的解决方案,使用多种监控技术而不是依赖于单一方法。目的是为了既可以使用Agentless监控,又可以基于Agent实现更细粒度的监控。因此,建议尽可能采用Agent监控方式,尤其是对于那些需要深入监控的、复杂的关键环境,基于Agent的方法更为合适。

三、百战不殆:自动化为漏洞修复“减压”

漏洞修复是漏洞管理最重要的步骤之一,一旦出错将会对企业产生重要影响。因此,尽快根据漏洞优先级进行修复,并将系统风险降到最低,这一点尤为重要。但是传统人工排查漏洞、提供修复建议以及打补丁的过程费时费力,而且出错率高。众所周知,复杂的修复过程会导致企业组织选择延迟修复,这些积累的“技术债务”对于企业而言就是一个定时炸弹。

为简化补丁处理过程以及将成本降到最低,建议采用自动化的补丁管理解决方案。毕竟,安全专家作为稀缺资源,不应该被束缚在那些可以通过自动化解决的简单重复工作任务中。他们应该去解决那些自动化工具解决不了的问题,例如,确定补丁的优先级并对这些补丁的应用提供指导建议等。

在漏洞修复时,自动化的漏洞管理解决方案能够以可视化方式全面展示风险状况并输出对应安全报告,让安全人员对于风险概况、整体趋势等有一个详细的了解。当然,对于一线操作人员而言,最有用的报告功能是了解需要修复哪些漏洞,以及如何完成该任务。因此,报告应该介绍风险的严重性、漏洞的检测细节和修复步骤,帮助安全人员尽快完成漏洞修复任务。同时,为满足不同职位人员的需求,自动化的漏洞管理解决方案应该支持根据需求定制风险信息的类型和展现形式。

此外,扫描报告应该全面、具体、易于理解、无漏报和误报。误报会占用IT人员大量的精力和时间进行排查,而漏报则会导致因为存在未修补漏洞而被黑客利用的严重风险。通常情况下,漏洞报告至少包括以下4块内容:

漏洞报告主要内容:

  • 风险概览,提供一个“一目了然”的风险评级及各风险点概况和趋势。
  • 风险汇总,按优先级列出所有风险点。
  • 风险分析,详细描述资产面临的具体威胁,并允许对具体问题进行深入审查。
  • 补丁报告,显示补丁的状态以及负责人。

实践案例:Struts2漏洞爆发后,与黑客的一次正面交锋

下面通过我亲身经历的一个故事,跟大家分享下在Struts2爆发后,我们的响应过程。

某天半夜凌晨,接到公司打来的一个紧急求助电话。

我赶紧打开电脑查看报警邮件,提示存在一个反弹Shell的攻击行为。

深更半夜,服务器居然正在主动尝试连接外部其它服务器。在那个瞬间,我都能想象得出来,服务器另一端那个穿着“黑衣服”的人,面对“冒着新鲜热气儿”的Shell唾手可得的那种狂喜。显然,黑客正在疯狂攻击,情况甚是紧急,需要在黑客造成真正破坏之前阻止他们。

做技术的人都知道,反弹Shell一般是外网渗透的最后一步,也是内网渗透的第一步。反弹Shell对服务器安全乃至内网安全的危害不必多说。

多年的一线拼杀经验告诉我,黑客一般是利用远程命令执行、远程代码执行、Webshell、Redis未授权访问可执行系统命令等漏洞,执行反弹命令,使目标服务器发出主动连接请求,从而绕过防火墙的入站访问控制规则。

① 初试无果

虽然我们记录了展示每台服务器系统交互的Shell命令,包括操作者IP、操作终端、操作用户、操作详情等关键信息,但是出乎意料的是,在反弹Shell这十几分钟时间内,日志上居然没发现任何黑客执行反弹Shell操作等相关的异常操作行为。

② 改变思路

显然,黑客不是通过在服务器端执行命令的常规方式进行反弹,但一定是有其它资产存在漏洞,被黑客利用了。为了找到根本原因,我全面清点了一下该主机上运行的资产(如虚拟机、web站点、web服务、web框架等),发现该服务器上存在Struts 2的Web框架,凑巧的是该版本正好存在S2-045漏洞。

要说著名的RCE(远程代码执行)漏洞,Struts2框架漏洞最为“经典”,一经爆发就被各安全厂商作为高危紧急漏洞处理。S2-045漏洞是由报错信息包含OGNL表达式,并且被带入了buildErrorMessage这个方法运行,造成远程代码执行。S2-045只有一种触发形式,就是将OGNL表达式注入到HTTP头的Content-Type中。

③ 柳暗花明

为确认真正攻击源,通过查看Tomcat日志发现存在反弹Shell行为的恶意IP,正在通过post请求方式访问客户服务器上一个Struts2页面。至此,基本可以判断攻击者正是通过Struts2的反序列化漏洞进行攻击,从而完成反弹Shell的操作。值得庆幸,因为及时发现和快速响应,黑客的攻击行为未对服务器造成任何伤害。

④ 进行反击

首先通过防火墙立即封堵该IP,同时在WAF上设置规则,拦截该请求,进一步对Struts2漏洞立马打补丁。

攻防的较量从未停止,黑客与白帽子间的斗争也越演越烈。在Struts2框架漏洞这个战场上,需要持续深入地研究,才能占有主动权。虽然从过去出现的Struts漏洞看,恶意OGNL表达式的注入点无处不在,但随着Struts2框架版本不停迭代,很多漏洞都被修补。

在这里,也提醒各位安全人员,一定要及时打补丁并使用最新版的Struts框架,避免被不法分子利用而造成损失。同时,对request请求的参数名、参数值、cookie参数名、action的名称、Content-Type内容、filename内容、请求体内容(反序列化漏洞)进行验证,降低后期被黑客利用的可能性。

安全锦囊

大多数企业的安全部门并不具备充足的人力对所有漏洞进行实时响应。因此,为了最有效地利用有限的人力、物力资源,需要对漏洞响应进行优先级排序。当然只有准确地对漏洞进行风险评估,才能真正地改善漏洞管理。对此,建议从以下六个方面,提高漏洞响应优先级排序的效率。

  • 对关键资产清单进行及时更新。精确掌握哪些资产有风险以及攻击者最有可能对哪里进行攻击。
  • 引入威胁情报,为漏洞修复提供支持。情报能让用户及时了解新发生的重大漏洞,继而对漏洞修复给出更有效的建议。
  • 建立相关的安全合规基线。包括操作系统补丁更新、相关配置需要满足安全规范的要求,杜绝新设备“带病”入网。
  • 使用持续的安全评估。可以通过基于Agent持续监控、安全日志、流量分析、CMDB等多种方式全面掌握资产变化带来的风险。
  • 建立漏洞修复优先级排序。综合资产的暴露位置、资产重要性、是否有防护手段、漏洞有无POC、漏洞利用热度等指标,对资产漏洞修复工作进行排序。
  • 自动化漏洞修复方案。尽量采用自动化补丁修复方案,减少安全运维人员工作量。

【本文是51CTO专栏作者“安全牛”的原创文章,转载请通过安全牛(微信公众号id:gooann-sectv)获取授权】

戳这里,看该作者更多好文   

 

责任编辑:赵宁宁 来源: 51CTO专栏
相关推荐

2023-01-29 07:45:06

DevOps

2021-07-16 10:27:07

ITIT领导IT管理

2018-03-23 08:48:51

程序员技能沟通

2024-01-05 18:04:59

人工智能Tabnine插件

2022-05-15 00:20:43

特权访问管理PAM

2021-11-02 22:40:03

云存储私有云混合云

2024-05-13 12:56:19

2010-08-11 15:05:39

2022-07-27 08:34:13

Vim插件

2022-11-15 16:54:54

2019-08-15 10:20:43

前端组件工具

2023-05-16 16:03:10

2022-03-21 16:40:27

数据管理数据

2022-06-20 14:57:50

漏洞安全威胁

2012-09-19 16:09:43

2016-07-25 18:10:55

2024-03-11 14:34:04

JavaScript开发

2022-04-07 12:03:28

云安全CSPM云计算

2016-12-15 09:53:07

自学编程技巧

2024-03-06 10:50:30

云计算云实例云提供商
点赞
收藏

51CTO技术栈公众号