平均110万个漏洞被积压,企业漏洞管理状况堪忧

平均,万个,漏洞,积压,企业,管理状况,堪忧 · 浏览次数 : 76

小编点评

**漏洞管理现状报告** **漏洞积压问题** * 12个月内,平均有 110 万个漏洞被积压。 * 仅不到一半的漏洞(46%)得到修复。 * 43% 的受访者认为这些工具和方法未能有效地起到作用。 * 47% 的受访者表示,由于他们无法确定需要修复的漏洞相应的优先级因此导致漏洞积压未被修复。 **漏洞管理挑战** * 确定漏洞的优先级和修复时间很长。 * 只有 29% 的受访者表示所在企业在此方面非常有效。 * 1到 10 的等级评价漏洞修复的及时性时,只有 30% 的受访者表示能有效地进行。 **自动化和 DevSecOps** * 自动化漏洞检测、优先级和修复过程可以显著减少确定哪些漏洞是最大风险所需的时间。 * 使用自动化可以显着减少修复漏洞所需的时间。 * 拥有成熟的 DevSecOps 程序是漏洞管理策略的重要组成部分。 **结论** * 企业需要从动化漏洞检测、优先级和修复过程中减少漏洞积压。 * 自动化和 DevSecOps 可以在漏洞管理中提供帮助。 * 减少漏洞积压可以显著降低企业对软件开发安全风险。

正文

在软件安全的世界中,企业在软件开发生命周期中都面临着漏洞带来的巨大挑战。开发人员每天都需要确保交付没有漏洞的代码,因此他们需要花费大量的时间来解决首要处理的漏洞问题以确保企业软件安全。然而确保产品没有漏洞缺陷的需求扼杀了创新的步伐,延迟软件产品的上市时间并导致收入和时间上的巨大损失。

业内权威咨询研究机构 Ponemon Institute 对634位 IT 和安全领导者进行采访,就企业 DevSecOps 在管理漏洞和攻击面方面进行研究和调查,并发布企业 DevSecOps 漏洞管理状态报告。该报告阐明了企业漏洞管理的一系列现状以及所面临的挑战。

漏洞积压

Ponemon 表示企业在管理漏洞时的另一项巨大挑战就是要处理大量积压的漏洞。根据报告结果显示,在过去的12个月里,平均有110万个漏洞被积压,然而其中不到一半(46%)得到修复

虽然企业拥有大量的漏洞和扫描工具,不论是网络还是应用程序,再到云端及移动端,涵盖技术基础设施的各个方面,但 Ponemon 报告研究发现,43%的受访者认为这些工具和方法未能有效地起到作用,还有47%的受访者表示,由于他们无法确定需要修复的漏洞相应的优先级因此导致漏洞积压未被修复。

随着企业积压的漏洞数量逐渐增加,消除这些漏洞积压往往给其软件应用程序开发方面的资金和生产力造成损失。调查发现,77% 的受访者表示,检测、优先排序和修复生产中的一个漏洞每个步骤需要超过 21 分钟,这样意味着生产端的一个漏洞需要花费一个多小时的时间。

在开发方面,漏洞管理变得更加有挑战性。据报告结果显示,确定优先级和修复时间也很长,有82% 的受访者表示修复开发中的一个漏洞需要超过 21 分钟,85% 的受访者表示确定开发中的一个漏洞的优先级需要超过 16 分钟。 当被问及在环境中检测到严重或高风险漏洞平均需要多长时间才能修复时,14%的受访者表示需要6周,需要7周的占16%,需要8周的占15%,还有13%的受访者表示需要9周来完成修复!修复漏洞的时间越长,漏洞被利用的风险就越大,企业攻击面也会随之增加。

Seal 软件供应链防火墙 可以为用户匹配漏洞修复的优先级,并自动提供修复建议,大大节省漏洞修复时间,极大程度降低企业被攻击的风险。

漫长的漏洞检测和修复过程导致了漏洞的积压。报告结果显示,有66%的受访者表示其所在的企业积压的漏洞至少有100,000个,其中54%的人表示他们能够修补不到一半的积压漏洞。手动检测、确定优先级再到修复漏洞,这意味着企业团队每年需要花费数千小时进行漏洞积压管理。

漏洞管理能力不足

在受访者被问到以1到10的等级来评价其所在的企业在优先处理关键漏洞的有效性,只有29%的人表示他们所在的企业在此方面非常有效。同样1到10的范围评价漏洞修补的及时性时,只有30%的受访者表示其所在企业能够有效且及时地修补漏洞。 这也说明企业并未能拥有足够的能力来管理漏洞。

而在尝试解决漏洞积压问题时,有几个因素正在给企业带来挑战。即无法确定需要修复的优先级,没有足够的关于可能利用漏洞的风险的信息,和缺乏有效的工具和资源。如之前所述,许多企业正在花费大量时间来解决大量漏洞积压问题,而安全团队无法确定漏洞的优先级以快速解决最关键的漏洞。超过一半的受访者 (53%) 表示其所在的企业只关注那些构成最大风险的漏洞,而不是专注于修复所有漏洞。然而,还有接近一半的受访者表示,因为不确定哪些漏洞带来的风险和危害最大,他们所在的企业修复了所有漏洞。

因此 Ponemon 表明,企业需要正确的工具和策略来自动化漏洞的检测、优先级和修复过程。否则他们无法实际管理漏洞积压。

自动化和 DevSecOps 是关键

当今漏洞管理的缺点之一是无法确定漏洞的优先级,而成功确定优先级的关键是使流程自动化。安全团队需要自动确定优先级,以使他们的补救工作更加及时和高效。自动化此过程可以显着减少确定哪些漏洞是最大风险所需的时间。除了自动化之外,拥有成熟的 DevSecOps 程序应该是漏洞管理策略的重要组成部分。企业必须采取必要的步骤来推进他们的 DevSecOps 计划。

使用自动化进行漏洞管理的企业正在看到成果。例如,超过一半的受访者表示他们的企业使用自动化来修复漏洞,其中大多数人表示此举已经产生了显着的收益。当被问及自动化如何影响修复漏洞所需的时间时,43% 的人表示响应时间明显缩短。当问及企业将哪些步骤自动化,结果是漏洞修复(59%),漏洞优先级排序(47%)以及漏洞报告(41%)。

此外,企业也应当接受并实施“安全左移”,并将 DevSecOps 放在首位,因为 DevSecOps 框架从构建过程开始就为软件生命周期的所有阶段添加了自动化安全测试和协调,而不是为最终的软件审查阶段保留漏洞测试环节。

许多企业都在努力充分利用 DevSecOps,虽然他们在优化模型使用方面面临障碍,包括缺乏正确的安全工具、缺乏工作流集成、不断增加的漏洞积压以及应用程序安全漏洞的增长,但这仍是确保软件开发安全的关键组成部分。DevSecOps 可以通过识别在企业环境中不可利用的漏洞来减少高达 85% 的漏洞积压以及修补工作。根据调查结果显示,45%的受访者表示采用 DevSecOps 的主要原因是减少修复漏洞所需的时间,还有33%的人表示 DevSecOps 能够帮助确定风险的优先级顺序和补救措施。

与平均110万个漏洞被积压,企业漏洞管理状况堪忧相似的内容:

平均110万个漏洞被积压,企业漏洞管理状况堪忧

在软件安全的世界中,企业在软件开发生命周期中都面临着漏洞带来的巨大挑战。开发人员每天都需要确保交付没有漏洞的代码,因此他们需要花费大量的时间来解决首要处理的漏洞问题以确保企业软件安全。然而确保产品没有漏洞缺陷的需求扼杀了创新的步伐,延迟软件产品的上市时间并导致收入和时间上的巨大损失。 业内权威咨询研

每个后端都应该了解的OpenResty入门以及网关安全实战

简介 在官网上对 OpenResty 是这样介绍的(http://openresty.org): “OpenResty 是一个基于 Nginx 与 Lua 的高性能 Web 平台,其内部集成了大量精良的 Lua 库、第三方模块以及大多数的依赖项。用于方便地搭建能够处理超高并发、扩展性极高的动态 We

聚焦“教-学-评-测-练-管一体化”,推动新型人才培养

摘要:华为云联合青软创新科技集团股份有限公司(以下简称“青软集团”)共同推出了联营解决方案——U+新工科智慧云平台。 本文分享自华为云社区《聚焦“教-学-评-测-练-管一体化”,推动新型人才培养!》,作者: 灰灰哒 。 新一代信息技术的发展使得产业对人才的能力要求持续提高,加强校企间的连接与合作,通

iOS中容易用错的常用知识点

坐标系转换 ios中的坐标系有三种 视图坐标系:原点(0,0)视图的左上角 窗口坐标系:原点(0,0)窗口的左上角 世界坐标系:原点(0,0)游戏中世界的原点 平时开发中经常会遇到转UIWindow坐标问题,如:已知一个UI控件的坐标,把它转换到UIWindow时,它对应的UIWindow坐标是什么

记录freeswitch的一个2833问题

概述 freeswitch是一款简单好用的VOIP开源软交换平台。 运营商内部新老系统混用,互联互通的问题较多,其中以DTMF码的问题最多,花样也多。 环境 CentOS 7.9 freeswitch 1.10.7 问题描述 问题现象 正常的fs业务服务器,呼叫正常,部分呼叫报错DTMF收码失败。

记录一次fs通话无声的问题

概述 freeswitch是一款简单好用的VOIP开源软交换平台。 fs的实际应用中,由于网络、配置等问题,经常会产生通话无声的问题。 环境 CentOS 7.9 freeswitch 1.10.7 问题描述 部署一台新服务器,作为SBC,对接B路,部署简图如下。 A -- fs1 -- fs2(f

[转帖]理解平均负载

https://www.jianshu.com/p/beb0b9f590d4 uptime命令 [test@localhost bin]$ uptime 22:02:14 up 3:34, 2 users, load average: 0.00, 0.01, 0.05 #22:02:14 //当前时

[转帖]Linux性能分析:理解系统平均负载

Linux系统中,平均负载是指单位时间内,处于可运行状态和不可中断状态的进程数。它不仅包括了正在使用CPU的进程,也包括处于不可打断的睡眠状态的进程—它们是在等待其它系统资源如磁盘 I/O 等的进程。而CPU使用率,是单位时间内CPU繁忙情况的统计,跟平均负载并不一定完全对应。 有诸多方式监测系统平

[转帖]iostat相关参数说明——await:平均每次设备I/O操作的等待时间 (毫秒),如果%util接近 100%,说明产生的I/O请求太多

https://www.cnblogs.com/bonelee/p/6323587.html iostat是I/O statistics(输入/输出统计)的缩写,iostat工具将对系统的磁盘操作活动进行监视。它的特点是汇报磁盘活动统计情况,同时也会汇报出 CPU使用情况。同vmstat一样,ios

[转帖]《Linux性能优化实战》笔记(一)—— 平均负载

最近在看极客时间的《Linux性能优化实战》课程,记录下学习内容。 一、 平均负载(Load Average) 1. 概念 我们都知道uptime命令的最后三列分别是过去 1 分钟、5 分钟、15 分钟系统的平均负载,到底平均负载是什么? 简单来说,平均负载是指单位时间内,系统处于可运行状态和不可中