当它成为一项管理任务时
当公司已经拥有扫描仪、报告、关键 CVE 和定期会议，但不清楚资产所有者应首先修复什么、实际的时间框架以及业务仍存在哪些风险时，漏洞管理就成为一项管理任务。
本页面适用于网络安全总监、CIO、基础设施主管、SOC、DevSecOps、关键系统所有者、项目办公室和采购。对于银行、工业、公共部门、零售、电信以及拥有大量服务器、工作站、网络服务、云资源、承包商和受监管环境的公司特别有用。
什么是漏洞管理
VM 代表Vulnerability Management，即漏洞管理。在成熟的企业级架构中，这是一个持续的过程：了解您的资产，定期发现漏洞，了解真正的危险，分配所有者，控制消除，仔细检查结果并向管理层展示风险的动态。
扫描仪提供技术发现。漏洞管理回答了其他问题：哪些发现真正威胁到重要的业务流程，哪些内容已经被攻击者利用，哪些地方有补偿措施，哪些地方无法立即应用补丁，以及责任所有者需要做出什么决定。
关键术语说明
| 学期 | 解码 | 在项目中是什么意思 |
|---|---|---|
| VM | 漏洞管理——漏洞管理。 | 链接扫描、资产、优先级、任务、截止日期、例外情况和报告的流程。 |
| CVE | 常见漏洞和暴露 - 已知漏洞的公共标识符。 | 网络安全、IT、供应商和承包商在讨论特定漏洞时的通用语言。 |
| CVSS | 通用漏洞评分系统 - 用于评估漏洞的技术严重性的系统。 | 需要补充资产、威胁和操作环境的基本严重性评估。 |
| EPSS | 漏洞利用预测评分系统 - 预测 CVE 漏洞利用的可能性。 | 帮助了解哪些漏洞在短期内最有可能被利用。 |
| KEV | 已知被利用的漏洞 - 已被利用的漏洞目录。 | 这是加速解决问题的强烈信号，特别是对于公共和关键系统。 |
| ASM / EASM | 攻击面管理/外部攻击面管理 - 攻击面的管理，包括外部攻击面。 | 帮助您查看域、子域、IP、公共服务、测试台和云接入点。 |
| SLA | 服务水平协议 - 商定完成日期。 | 在VM中，指定不同资产类别和漏洞的风险消除或处理的时间表。 |
| SIEM / SOAR | 网络安全事件/响应自动化的收集和关联。 | 用于链接漏洞、事件、事故、行动手册和 SOC 报告。 |
| EDR / XDR | 端点检测和响应/高级关联。 | 显示易受攻击的主机实际暴露于活动的位置以及采取了哪些缓解措施。 |
| SCA / SBOM | 软件构成分析/软件物料清单 - 依赖性分析和软件组件列表。 | DevSecOps 需要查看易受攻击的库、容器和应用程序组件。 |
| ITSM / CMDB | IT服务管理/配置项数据库。 | 他们帮助分配所有者、创建任务、将漏洞与服务关联起来并监控状态。 |
该流程在大型组织中如何运作
资产
我们收集服务器、工作站、应用程序、数据库、网络设备、云资源、外部服务、容器和所有者。
扫描
我们配置数据源：内部和外部扫描仪、AppSec、SCA、端点、SIEM、CMDB、云和手动检查。
丰富
我们添加了业务关键性、互联网暴露、利用可用性、CVSS、EPSS、KEV、补偿措施和依赖性。
优先事项
将真正紧急的风险与噪音分开：并非所有的关键因素都同样重要，也不是所有的媒介都可以安全地放在一边。
任务
我们在 ITSM 或团队任务队列中创建任务，确定所有者、截止日期、更正选项、排除风险和目标日期。
考试
我们重新扫描、验证实际消除情况、关闭误报并更新报告。
报告
我们向管理层展示动态：哪些已修复、哪些已逾期、哪些风险已被接受、哪些系统需要单独的解决方案。
优先级：首先关闭什么
VM 流程的一个典型错误是尝试根据技术评分来关闭所有漏洞。事实上，IT 的更新窗口有限，存在遗留系统、关键业务服务、承包商和监管环境。因此，优先级必须考虑技术严重性、被利用的可能性以及资产的价值。
| 信号 | 如何使用 |
|---|---|
| 资产重要性 | 支付系统、个人账户、GIS、CII、ERP、包含个人数据的数据库或公共 API 比孤立的测试平台更重要。 |
| 可通过互联网访问 | 具有漏洞的外部服务需要比没有来自用户或攻击者的路由的内部节点更严格的响应。 |
| KEV 和操作 | 如果某个漏洞已经被用于实际攻击，则不能将其留在一般等待名单上。 |
| EPSS | 帮助从大量技术发现中区分出更有可能被利用的漏洞。 |
| 补偿措施 | WAF、分段、EDR、禁用的组件或受限的访问可能会改变紧迫性，但并不能消除对解决方案的需求。 |
| 纠正费用 | 有时，快速配置修复比复杂补丁上的长期项目更能降低风险。 |
国际实践与俄罗斯监管语境
在国际实践中，漏洞管理与更新管理密切相关。 NIST SP 800-40 Rev. 4 将更新管理视为主动维护：在整个组织内识别、确定优先级、接收、安装和验证更新。这是与 IT 人员交谈的一个很好的指导原则：补丁不是其他人的网络安全任务，而是可靠操作的一部分。
FIRST CVSS 作为技术严重性的一般标准很有用，但不能单独使用。 FIRST EPSS 增加了被利用的可能性，并且 CISA KEV 有助于突出攻击中已经发现的漏洞。 CIS Controls 提供基本网络卫生的实用语言：资产清单、配置控制、访问控制、日志记录和漏洞修复。
在俄罗斯赛道中，VM 必须与 FSTEC、KII、GIS、ISPDn、内部政策和检查证据基础的要求相关联。对于已知漏洞有用 俄罗斯 FSTEC 网络安全威胁数据库。在受监管的项目中，重要的是不仅要关闭CVE，还要显示流程的可控性：谁负责、采取什么措施、采取什么风险以及如何通过文件和日志确认这一点。
AI如何帮助VM处理
人工智能不应自行决定企业可接受的风险。但如果将其构建到包含源、角色和日志的受控循环中，它可以显着加快团队的工作速度。
结果去重复
人工智能有助于将重复的扫描结果、同一问题的不同名称以及来自多个来源的噪音结合起来。
给楼主的解释
系统所有者不会收到干燥的 CVE，而是收到清晰的描述：什么是脆弱的、它威胁什么、有哪些纠正选项可用以及为什么截止日期很重要。
草稿任务
AI 可以为 ITSM、Jira 或问题队列准备问题描述：受影响的资产、版本、补救步骤、审查和关闭标准。
链接到文档
该模块将漏洞与策略、威胁模型、CII/GIS/ISPD 要求以及合规性证据包进行比较。
报告
人工智能有助于为 CISO、CIO 和委员会编写一份简短的摘要：趋势、延迟、接受的风险、问题所有者和快速行动。
约束控制
专家仍处于决策循环中：人工智能准备选项，负责的专家确认风险、例外、截止日期和最终状态。
RESTART 的价值所在
当漏洞管理不需要作为单独的控制台，而是作为网络安全、IT、开发、运营、采购和系统所有者之间的工作流程时，RESTART 非常有用。我们连接审计、外部边界、端点、DevSecOps、SIEM/SOAR/SGRC、ITSM、CMDB、供应商解决方案和监管要求。
我们的方法：首先了解资产和流程，然后选择工具和规则。否则，很容易最终得到一个昂贵的平台，该平台会产生数千次点击，但无法帮助企业更快地降低风险。
外部边界、端点和 DevSecOps
交付成果
| 人工制品 | 它是做什么用的？ |
|---|---|
| 资产和来源图 | 显示流程中包含哪些系统、主机、应用程序、云、外部服务和扫描仪。 |
| 优先级模型 | 修复规则：CVSS、EPSS、KEV、资产重要性、互联网可访问性、补偿措施和监管画像。 |
| SLA矩阵 | 为不同类型的资产、漏洞、异常和关键系统设置处理和补救期限。 |
| RACI 和所有者 | 确定谁负责资产、补救、风险承担、审计和管理报告。 |
| 消除任务队列 | 将调查结果转化为 IT、DevSecOps、系统所有者和承包商可以理解的任务。 |
| 异常寄存器 | 记录无法立即纠正的情况：原因、补偿措施、所有者、审查期限和剩余风险。 |
| 整合方案 | 显示 VM 平台与扫描仪、SIEM/SOAR/SGRC、ITSM、CMDB、端点、AppSec 和报告的组合。 |
| 管理报告 | 显示风险、延误、关键系统、速效、问题领域和开发计划的动态。 |
VM工具的交付和实施
漏洞管理工具、扫描仪、EASM、配置管理、SCA 和 SGRC 平台应与资产、优先级、运营、DevSecOps 和报告相关联。 RESTART 有助于选择和交付此类解决方案作为托管流程的一部分，而不是作为单独的许可证购买。
常见问题
漏洞管理与渗透测试有何不同？
渗透测试验证商定边界内的实际攻击场景。 VM 是一个持续的过程，定期查找漏洞、确定漏洞的优先级并监控漏洞的修复。这些方法相辅相成：渗透测试显示攻击路径，虚拟机保留修复和重新测试的过程。
为什么不能只修复关键漏洞？
因为没有背景的技术分数可能具有欺骗性。公共服务上的中级漏洞在现实世界中的利用可能比孤立测试节点上的关键漏洞更危险。我们需要一个优先级模型。
补丁无法安装怎么办？
记录异常情况：原因、责任人、审查期限、补偿措施、剩余风险和责任人的决定。这比默默地忽略这个发现要好。
是否可以在不引入新平台的情况下开始？
是的。通常，第一步是诊断流程：资产、数据源、当前扫描仪、优先级规则、所有者、SLA、报告和快速改进。此后，是否需要新产品就变得更加清楚。
如何将VM与SOC和DevSecOps连接起来？
SOC 获取资产和漏洞的背景信息以进行事件调查。 DevSecOps 在发布前关闭易受攻击的依赖项、容器和代码。 VM 将这些线程组合到风险和任务的公共注册表中。
AI能自动修复漏洞吗？
大多数企业级架构没有。人工智能可以产生分析、任务草案、解释和报告，但纠正、冒险和生产系统的改变必须经过负责人和改变过程。
让我们讨论一下您的环境
描述任务、当前系统、约束和预期结果。我们将提供实用的第一步：诊断、试点、审计、路线图或项目团队。
