从Log4j2看漏洞管理需要考虑的问题

新钛云服已为您服务1348天

最近Log4j2漏洞把甲乙方都折腾了一遍，让大家体会了一把“夜太美，尽管再危险总有人黑着眼眶熬着夜”。修复的方法和防护方式在朋友圈刷了一圈又一圈。这边就不再赘述，主要聊聊漏洞修复方面的思考。

漏洞管理是企业安全建设需要考虑的一个关键过程，许多安全和风险管理者或多或少对于漏洞管理存在很多顾虑，如何优化流程以达到预期的安全目标，如何持续进行漏洞管理以降低企业面临的风险。

挑战1

随着IT基础设施范围和规模的增加，当发现最新漏洞时，如何快速定位受影响的业务范围，多少系统、多少组件涉及修复，大概的工作量是多少?需要协调哪些人来应急？

资产发现和分类：

大多数企业都有服务器、云资源、台式机、笔记本电脑、移动设备、物联网 (IoT) 等。这些资产是动态的，并且不断移动和增长。随着增长组织的威胁暴露也在增加，维护资产清单是任何漏洞管理计划的基础。

有效的漏洞管理程序应与资产发现和管理程序紧密结合，企业应保持最新的资产清单。高质量的配置管理数据库CMDB是基础，内容至少包括：资产标识数据、资产所有者、资产位置、资产的潜在业务影响。

通过与基础架构、运营、应用所有者、以及其他团队的合作，说明资产梳理的价值。当发现最新漏洞时，以最快的速度筛选统计资产是内网的、还是暴露在互联网的，涉及系统和组件版本、涉及的服务器范围、涉及的应用影响范围，需要协调通知的人员，给予决策者、应用负责人、技术智囊团判断漏洞修复的紧急程度，是暂时接受风险还是需要马上开展行动。

突发漏洞时，各层级的反应。

领导层:这个漏洞的影响范围？需要多少资源协助修复？不修复的影响......

业务层：漏洞涉及多少应用？修复需要停机多久？需要全量验证吗？可以暂时不修排期修复吗......

针对以上疑问，应急团队应快速的给到以下答复：

我们以评估此次漏洞的利用方法存在PoC还是EXP，公司XX系统涉及风险、XX系统是内网的暂时可能不受影响，大概需要排期多久修复。XX系统是外网暴露的需要修复XX台，涉及XX业务停机XX分钟进行修复和验证，此外在WAF上已启用虚拟补丁，并监控受攻击情况。我想这样的答复才是领导、业务相对比较满意的答复吧。

定期扫描：

定期运行大范围的计划发现扫描，以识别系统更改和未知情况下部署的系统。企业还可以将漏洞管理程序连接到现有的变更管理流程和ITSM工具。

扫描频率：

每天、每周、每月、每季度，基于Agent、非登录扫描、登录式扫描，这个频率应该是基于企业风险承受能力、合规性、资产数量来确定的合理频率，并与修复同步循环。

应用层漏洞：

最好使用 DevSecOps 模型，将漏洞工具与持续集成/持续交付 (CI/CD) 周期相结合，以便在构建或运行期间修复代码漏洞。

工具：

CMDB、漏扫软件、CWPP主机层资产信息收集、漏洞管理平台等。

挑战2

即使有最好的漏洞管理、基础设施运营团队、应用团队、开发团队的配合，也无法按时完成修复任务，被内审或者相关利益方认为效率低下。

漏洞修复方案的合理性考量和评估，如果处理不当，可能直接造成业务风险。以合理且最佳的修复周期频度进行修复，这个频率源自于企业的风险承受能力、合规性要求、资产修复数量（关键基础设施）。

例如修复周期是每季度一次，并在日常运营过程中与领导层、业务层达成一致意见。哪些漏洞修复是例行任务，哪些是需要专项小组突击修复的，界定好范围，并作为固定要求写入企业漏洞修复制度中，持续宣教。

Tips：

漏洞管理中沟通协调表达能力有时比技术更重要。让对方明白你的意图是什么，多换位思考（智者告诉我们：“若欲长久利己者,暂时利他乃窍诀”）。业务和安全一定是一条战线的，安全不是用来刁难业务让业务难以开展的。安全建设初期需要制定一些红线规则，但后期一定是考虑业务安全的维度出发，过程中需要磨合平衡。

挑战3

漏洞修复优先级已成为大多数漏洞评估解决方案首先需要考虑的问题。

企业需要执行基于风险的漏洞管理。为团队的工作制定战略，使他们能够处理相关的、可利用的和具有重大业务风险的漏洞。由于各种原因，企业将无法修复所有漏洞，例如资源有限，修补并不总是可行的。 因此，辨别关键漏洞变得势在必行。

企业应混合使用内部和外部情报来源以确定漏洞的优先级。例如业务关键性、安全状况、风险登记情况、变更管理系统、CMDB、渗透测试数据、网络可访问性和网络控制情况，需要考虑多种因素。

许多企业仅限于通用漏洞评分系统 (CVSS) 分数，并开始修补高于截止分数的所有内容。此外，可能会只修补关键和高危漏洞，忽略大量看似不太重要的漏洞，例如中危漏洞。但攻击者可能会寻找不那么重要、易于利用、在流行产品中可用并且在贵司环境中具有良好利用的漏洞。

务实的优先排序将帮助企业用最小的努力实现最大的回报。此外，一些企业正在使用供应商提供的预测建模模块，以提高识别真正存在风险的漏洞。这涉及处理大量数据以产生准确的可利用性。

这些解决方案使用机器学习来预测哪些漏洞更有可能被武器化并应优先修复。无论企业采用何种方法，请确保使用多个来源，增加覆盖指标并优化工作。可考虑搜索了解漏洞优先级VPT相关技术。

挑战4

除了打补丁是否有其他漏洞修复方案。

不要认为系统打补丁是唯一的方法，也可以尝试利用补偿控制、缓解控制和风险接受。可能不是最有效的但绝对是一个替代方案。

补偿控制：

Web 应用程序防火墙 (WAF)，因为许多供应商提供虚拟补丁功能，可以作为对威胁的第一级响应。

缓解控制：

缓解方法可以是工具、网络分段隔离可避免被利用系统的横向传播。配置调整以及禁用或更换组件，但需要持续跟进确认其有效性。

风险接受：

如果企业既不补救或减轻源自漏洞的风险，在这种情况下，安全团队需要确保系统和应用程序所有者知道这最终是他们的决定。该决定必须正确记录并由最终受影响的人员和管理层人员的签署。

写在最后：根据标题进来的小伙伴们，最后回到Log4j2 的解决：

有实力的企业:

后续可以考虑IAST和RASP的解决方案。

平民版方案：

鉴于漏洞性质，需要callback，其中目标/受害者连接回发送原始请求的主机，如果发生callback，则主机易受攻击。可以考虑业务服务器外访白名单，防止回连。虽然梳理白名单比较麻烦，但是白名单机制可以以不变应万变，应对类似漏洞的风险。

了解新钛云服

往期技术干货