读红蓝攻防：技术与策略31漏洞管理

方子楠 · 2025-6-24 05:15:17

1. 漏洞管理

1.1. 漏洞的利用可能会导致灾难恢复的场景，因此，必须首先建立一个能够防止漏洞被利用的系统
1.2. 建立一个漏洞管理流程，该流程可用于识别漏洞并帮助缓解这些漏洞威胁
1.3. 一个系统不可能百分之百安全，但是可以采取一些措施使黑客难以完成他们的任务
1.4. 漏洞管理阶段的最大挑战是缺乏可用信息

1.4.1. 一些组织没有记录其政策、程序、策略、流程和安全资产，因此可能很难获得完成这一阶段所需的信息
1.4.2. 大公司有多个业务部门，缺乏足够的资源和严谨的文档，而且职责交叉重叠
1.4.3. 唯一解决方案是，定期进行内务管理活动以确保所有重要的事情都记录在案，且每名员工都清楚地理解自身的职责

2. 创建漏洞管理策略

2.1. 为确保拥有健康的安全项目并降低组织风险，组织必须有效地识别、评估和补救弱点
2.2. 漏洞管理旨在减少组织暴露，强化攻击表面区域，提高组织弹性
2.3. 最佳方法是使用漏洞管理生命周期

2.3.1. 以有序的方式规划所有漏洞缓解过程
2.3.2. 使网络安全事件的目标和受害者能够减轻已经造成或可能造成的损害
2.3.3. 在正确的时间执行正确的应对措施，以便在攻击者滥用漏洞之前发现并解决这些漏洞

3. 阶段

3.1. 资产盘点

3.1.1. 编制资产目录
3.1.1.1. 资产目录被描述为该策略的关键，因为它列出了有关主机的所有详细信息以帮助用户彻底清理所有可能存在漏洞的计算机
3.1.2. 资产目录是一个网络中所有主机和所含软件的登记册
3.1.3. 至少应该显示一个组织所拥有的硬件和软件资产，以及它们的相关许可细节
3.1.4. 还应该显示这些资产中存在的漏洞
3.1.5. 许多组织缺乏有效的资产登记，因此在保护其设备时很困难
3.1.6. 让一名员工负责管理资产目录以确保记录所有设备，并确保目录保持最新
3.1.7. 资产目录也是网络和系统管理员用来快速查找和修补设备和系统的强大工具
3.1.7.1. 如果没有目录，在修补或安装新的安全软件时，可能会遗漏一些设备，它们将会成为攻击者攻击的目标设备和系统
3.1.8. 缺乏资产目录还可能导致组织在安全方面的支出不足或超支
3.1.8.1. 无法正确确定需要为其购买保护服务的设备和系统
3.1.8.2. 组织也缺乏有效确保一致性的资产目录维护工具

3.2. 信息管理

3.2.1. 控制信息如何流入组织
3.2.2. 最关键的信息流是来自组织网络的互联网流量
3.2.2.1. 组织需要防范的蠕虫、病毒和其他恶意软件威胁数量不断增加
3.2.2.2. 本地网络内部和外部的流量也有所增加
3.2.2.3. 不断增加的流量可能会给组织带来更多恶意软件
3.2.2.4. 应该注意这种信息流以防止威胁进入或离开网络
3.2.3. 目标应该是建立一种有效的方式，在尽可能短的时间内向相关人员提供有关漏洞和网络安全事件的信息
3.2.4. 在这个阶段结束时，如果系统遭遇破坏，事件响应者和其他用户之间应该有一个精心设计的沟通渠道
3.2.5. 存在竞争关系的组织可以通过获得对方的秘密配方、原型和商业秘密，从而胜过对方
3.2.5.1. 信息管理在漏洞管理策略中至关重要
3.2.6. 为了实现有效的信息管理，组织可以部署计算机安全事件响应小组(Computer Security Incident Response Team，CSIRT)来处理其信息存储和传输面临的威胁
3.2.7. 在访问信息时，组织可以采用最低权限的策略
3.2.7.1. 此策略确保拒绝用户访问除履行职责所必需的信息之外的所有信息
3.2.7.2. 减少访问敏感信息的人数是减少攻击途径的有力措施
3.2.8. 建立检测和阻止恶意人员访问文件的机制
3.2.8.1. 可以确保拒绝恶意流量进入，并在发现诸如监听之类的可疑活动时进行报告
3.2.8.2. 还可以安装在最终用户设备上，以防止非法复制或读取数据
3.2.9. 所有这些挑战共同影响组织在面对潜在的或已验证的黑客企图的情况下可以采取的行为和拥有的响应时间
3.2.9.1. 将合法告警视为误报而不予理睬并不令人意外
3.2.9.2. 进出组织网络的流量也变得复杂起来

3.3. 风险评估

3.3.1. 在降低风险之前，安全小组应该对其面临的威胁和漏洞进行深入分析
3.3.2. 在理想的IT环境中，安全小组应该能够应对所有漏洞，因为他们有足够的资源和时间
3.3.3. 组织必须优先考虑某些漏洞，并分配资源来缓解这些漏洞
3.3.4. 国际标准化组织(ISO)建议选择和确定一种与组织管理相一致的风险评估方法，并采用适合组织的方法
3.3.5. 子阶段
3.3.5.1. 范围识别

> 3.3.5.1.1. 风险评估始于范围识别> 3.3.5.1.2. 组织的安全小组只有有限的预算，因此，风险评估必须确定将覆盖的领域和不会覆盖的领域，确定要保护的内容、其敏感性以及需要保护的级别等> 3.3.5.1.3. 范围需要仔细定义，因为这决定将从何处开始进行内部和外部的漏洞分析

复制代码

3.3.5.2. 收集数据

> 3.3.5.2.1. 收集有关保护组织免受网络威胁的现有政策和程序的数据> 3.3.5.2.2. 通过对用户和网络管理员等人员进行访谈、问卷和调查来实现> 3.3.5.2.3. 应收集范围内的所有网络、应用程序和系统的相关数据 > 3.3.5.2.3.1. 服务包、操作系统版本、运行的应用程序、位置、访问控制权限、入侵检测测试、防火墙测试、网络调查和端口扫描

复制代码

3.3.5.3. 政策和程序分析

> 3.3.5.3.1. 组织设立政策和程序来管理其资源的使用方式，以确保它们被正确和安全地使用> 3.3.5.3.2. 审查和分析现有的政策和程序是很重要的> 3.3.5.3.3. 制定并宣传了政策和程序，并不意味着它们得到了遵守> 3.3.5.3.4. 对不遵守规定的行为的处罚也应该进行分析> 3.3.5.3.5. 知道组织是否有足够的政策和程序来解决漏洞

复制代码

3.3.5.4. 漏洞分析

> 3.3.5.4.1. 必须进行漏洞分析以确定组织的暴露面并找出是否有足够的应对措施来保护自己> 3.3.5.4.2. 会召集渗透测试人员来执行此过程> 3.3.5.4.3. 最大的困难是排除误报 > 3.3.5.4.3.1. 必须将各种工具一起使用，才能得出组织中现有漏洞的可靠列表> 3.3.5.4.4. 根据所发现的漏洞对组织构成的风险进行分级 > 3.3.5.4.4.1. 严重程度和暴露程度较低的漏洞通常评级较低 > 3.3.5.4.4.2. 轻微级是针对需要大量资源才能利用，但对组织影响很小的漏洞 > 3.3.5.4.4.3. 中等级是针对那些具有中等破坏性、可利用性和暴露可能性的漏洞 > 3.3.5.4.4.4. 高严重性级指那些需要较少资源即可利用，但会对组织造成很大损害的漏洞

复制代码

3.3.5.5. 威胁分析

> 3.3.5.5.1. 对一个组织的威胁是指可能导致一个组织的数据和服务被篡改、破坏或中断的操作、代码或软件> 3.3.5.5.2. 威胁分析是为了查看组织中可能发生的风险，且必须分析发现的威胁以确定其对组织的影响> 3.3.5.5.3. 该分级系统可能与漏洞分析中使用的分级系统有所不同> 3.3.5.5.4. 对识别出的威胁进行量化和分级

复制代码

3.3.5.6. 可接受风险分析

> 3.3.5.6.1. 首先评估现有的政策、程序和安全机制，以确定它们是否足够完善> 3.3.5.6.2. 假定组织中存在漏洞，并采取纠正措施以确保不断升级，直到足够充分> 3.3.5.6.3. 没有涵盖的任何风险都被视为可接受的风险> 3.3.5.6.4. 随着时间的推移，风险可能会变得更具危害性，因此必须定期进行分析 > 3.3.5.6.4.1. 只有在确定它们不会构成威胁之后，风险评估才会结束 > 3.3.5.6.4.2. 如果它们可能构成威胁，就应该更新防护标准以应对它们> 3.3.5.6.5. 该子阶段标志着漏洞管理战略的风险评估阶段结束

复制代码

3.4. 漏洞评估

3.4.1. 漏洞评估紧随风险评估之后，因为这两个阶段密切相关
3.4.2. 通过若干道德黑客攻击尝试和渗透测试来进行，组织网络上的服务器、打印机、工作站、防火墙、路由器和交换机都是这些攻击的目标
3.4.3. 目的在于使用潜在攻击者可能使用的相同工具和技术来模拟真实的黑客场景
3.4.4. 目标不仅是识别漏洞，而且要以快速、准确的方式进行识别
3.4.5. 该步骤应生成关于组织面临的所有漏洞的综合报告
3.4.6. 要考虑的是组织应该评估什么
3.4.6.1. 机可能是潜在攻击的关键目标
3.4.7. 漏洞扫描器
3.4.7.1. 一些扫描器可能提供错误的评估报告，并将组织引向错误的道路
3.4.8. 随着所有道德黑客和渗透测试活动的进行，网络、服务器和工作站都会受到影响，防火墙等网络设备也会变得迟缓，在进行拒绝服务攻击时更是如此
3.4.9. Metasploit等工具要求你对Linux有深入的了解，并具有使用命令行界面的经验
3.4.10. 漏洞评估方式
3.4.10.1. 外部评估：从外部发现漏洞
3.4.10.2. 内部评估：在网络内部发现漏洞
3.4.10.3. 社会工程：查找人力和培训差距方面的漏洞
3.4.10.4. 无线评估：发现无线网络内的漏洞
3.4.10.5. 物理安全评估：查找与人和设施相关的漏洞
3.4.10.6. 应用程序与数据库：发现软件漏洞

3.5. 报告和补救跟踪

3.5.1. 进行漏洞评估后将进入报告和补救阶段
3.5.2. 报告的任务是帮助系统管理员了解组织的当前安全状态以及组织中仍然存在的不安全领域，并向负责人指出这些情况
3.5.2.1. 所有确定的风险和漏洞都必须报告给组织的利益相关者
3.5.2.2. 涉及属于组织的所有硬件和软件资产
3.5.2.3. 还应对报告进行微调，以满足不同受众的需求
3.5.2.4. 为管理层提供了一些关键内容，这样他们就可以将其与组织的未来发展方向联系起来
3.5.2.5. 报告通常在补救之前进行，因此，在漏洞管理阶段编译的所有信息都可以无缝地融入本阶段
3.5.3. 补救启动了结束漏洞管理周期的实际过程
3.5.3.1. 漏洞评估阶段在分析威胁和漏洞并概述了可接受的风险之后提早结束了
3.5.3.2. 补救阶段通过提出针对已发现威胁和漏洞的解决方案来补充这一点
3.5.3.3. 应公布负责补救这些风险和漏洞的合适人员
3.5.4. 应跟踪所有易受攻击的主机、服务器和网络设备，并制定必要的步骤以消除漏洞并保护它们免受未来的攻击
3.5.5. 是漏洞管理策略中最重要的任务，如果执行得好，漏洞管理就是成功的
3.5.5.1. 同时还针对扫描工具发现的错误确定解决方案
3.5.5.2. 如果在这个阶段做得不到位，则会使整个漏洞管理过程变得毫无意义
3.5.6. 一份写得不好的报告可能会导致补救措施不力，从而使组织仍然面临威胁
3.5.6.1. 没有文档的话，可能很难更新定制的软件
3.5.6.2. 软件供应商之间沟通不畅，当需要为系统打补丁时，组织也可能面临挑战
3.5.6.3. 补救措施可能会因最终用户缺乏合作而受到影响
3.5.6.4. 补救可能导致最终用户停机，这是用户永远不想经历的事情

3.6. 响应计划

3.6.1. 响应计划可以认为是漏洞管理战略中最简单但却非常重要的一步
3.6.2. 在响应计划中，组织应该想出一个办法来修补、更新或升级那些被确认为具有某些风险或漏洞的系统
3.6.3. 在这一阶段最重要的是执行速度
3.6.3.1. 由于响应计划不完善，大多数公司在攻击开始时还没有做到这一点
3.6.3.2. 如果攻击没有被及时阻止，甚至会有更多的计算机成为受害者
3.6.3.3. 在响应计划方面，速度是多么重要

> 3.6.3.3.1. 补丁程序应在可用时立即安装

复制代码

3.6.4. 及时与合适的人进行适当的沟通
3.6.4.1. 当一个补丁发布时，黑客就会毫不迟疑地想方设法危害那些没有安装补丁的组织
3.6.5. 问责
3.6.5.1. 组织需要知道谁应该为未安装补丁程序负责
3.6.5.2. 用户可能需要对取消安装负责
3.6.5.3. 在其他情况下，可能是IT部门没有及时启动修补过程
3.6.5.4. 总应该有人为没有安装补丁程序负责
3.6.6. 重复努力
3.6.6.1. 通常发生在IT安全人员众多的大型组织中
3.6.6.2. 可能使用相同的响应计划，但由于沟通不畅，可能最终会重复对方的操作，但收效甚微

来源：程序园用户自行投稿发布，如果侵权，请联系站长删除
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！

账号		自动登录	找回密码
密码			立即注册