漏洞管理项目实施

使用 Tenable 实施企业级漏洞管理生命周期。

概述 • 技术 • 结果 • 维护

图 – 本项目中使用的漏洞管理架构。

### 项目信息 | 项目 | 详情 | |------|--------| | **项目类型** | 漏洞管理项目实施 | | **环境** | Azure Virtual Machines (Windows Server Lab) | | **主要工具** | Tenable Vulnerability Management | | **框架对齐** | NIST CSF, MITRE ATT&CK, CIS Controls | | **作者** | Sun Dimitri NFANDA | | **最后更新** | 2026 | ## 项目概述 本项目演示了使用 Tenable Vulnerability Management 和模拟的企业 Windows 环境，**端到端实施漏洞管理项目**的全过程。 本项目涵盖了漏洞管理的完整生命周期： 1. 漏洞管理策略制定 2. 利益相关者协调与变更管理审批 3. 基线漏洞发现 4. 风险优先级排序 5. 修复部署 6. 通过后续扫描进行验证 7. 过渡到持续漏洞监控 在实验室环境中部署了一台故意配置不安全的 Windows Server，并使用 Tenable 进行扫描。 随后通过配置加固、补丁更新和自定义 PowerShell 修复脚本，修复了多个漏洞。 _**初始状态：**_ 组织没有现有的策略或漏洞管理实践。 _**完成状态：**_ 制定了正式策略，获得了利益相关者的支持，并成功完成了整个组织范围的漏洞修复全周期。 ## 使用的技术 - **Tenable Vulnerability Management** – 企业级漏洞扫描平台 - **Azure Virtual Machines** – 托管扫描目标和扫描引擎的实验室基础设施 - **Windows Server / Windows 10** – 易受攻击的目标系统 - **PowerShell & Bash** – 修复自动化和配置加固 - **Nessus Plugins** – 漏洞检测和验证 ## 展示的技能 - 使用 **Tenable Vulnerability Management** 进行漏洞扫描 - 漏洞分类与 **风险优先级排序** - Windows **安全配置加固** - **PowerShell 修复脚本编写** - **TLS 协议和密码套件**的安全配置 - 强制执行 **SMB 签名** - 缓解 **ICMP 时间戳侦察暴露** - 通过 **经过身份验证的漏洞扫描** 验证修复效果 - 通过 **CAB 审批流程** 协调变更管理 - 实施 **持续漏洞管理生命周期** ## 安全框架对齐 本项目展示了与常见安全框架对齐的实践： | 框架 | 相关控制措施 | |----------|------------------| | **NIST Cybersecurity Framework** | ID.RA-1, PR.IP-12, DE.CM-8 | | **MITRE ATT&CK** | T1595 (Active Scanning), T1562.001 (Impair Defenses) | | **CIS Critical Security Controls** | Control 7 – Continuous Vulnerability Management | 使用下方的目录快速浏览本项目实施的漏洞管理生命周期的每个阶段。 ## 目录 - [步骤 1：漏洞管理策略草案制定](#step-1-vulnerability-management-policy-draft-creation) - [步骤 2：模拟会议 – 策略认可 (利益相关者)](#step-2-mock-meeting-policy-buy-in-stakeholders) - [步骤 3：策略定稿与高层领导签署](#step-3-policy-finalization-and-senior-leadership-sign-off) - [步骤 4：模拟会议 – 初始扫描许可 (服务器团队)](#step-4-mock-meeting-initial-scan-permission-server-team) - [步骤 5：服务器团队资产初始扫描](#step-5-initial-scan-of-server-team-assets) - [步骤 6：漏洞评估与优先级排序](#step-6-vulnerability-assessment-and-prioritization) - [步骤 7：向修复团队分发修复方案](#step-7-distributing-remediations-to-remediation-teams) - [步骤 8：模拟会议 – 初始发现扫描后 (服务器团队)](#step-8-mock-meeting-post-initial-discovery-scan-server-team) - [步骤 9：模拟 CAB 会议 – 实施修复](#step-9-mock-cab-meeting-implementing-remediations) - [步骤 10：修复工作](#step-10-remediation-effort) - [修复轮次 1：移除过时的 Wireshark](#remediation-round-1-outdated-wireshark-removal) - [修复轮次 2：不安全的协议与密码套件](#remediation-round-2-insecure-protocols--cipher-suites) - [修复轮次 3：来宾账户组成员身份](#remediation-round-3-guest-account-group-membership) - [修复轮次 4：Windows OS 更新](#remediation-round-4-windows-os-updates) - [修复轮次 5：WinVerifyTrust CVE-2013-3900 缓解措施](#remediation-round-5-winverifytrust-cve-2013-3900-mitigation) - [修复轮次 6：强制 SMB 签名](#remediation-round-6-smb-signing-enforcement) - [修复轮次 7：ICMP 时间戳泄露缓解](#remediation-round-7-icmp-timestamp-disclosure-mitigation) - [漏洞减少时间线](#vulnerability-reduction-timeline) - [首轮修复工作总结](#first-cycle-remediation-effort-summary) - [项目成果](#program-outcome) - [步骤 11：持续的漏洞管理 (维护模式)](#step-11-ongoing-vulnerability-management-maintenance-mode) - [经验教训](#lessons-learned) ## 仓库结构 仓库的组织结构将扫描证据、修复脚本以及漏洞管理过程中使用的可视化数据进行了分离。 ``` vulnerability-management-program/ │ ├── images/ │ ├── scans/ # Nessus scan screenshots │ ├── charts/ # vulnerability reduction charts │ └── diagrams/ # architecture diagrams │ ├── evidence/ │ ├── scans/ # exported Nessus scan reports (PDF) │ └── data/ # vulnerability scan data (CSV/XLSX) │ ├── scripts/ │ └── generate-vulnerability-chart.py │ ├── LICENSE └── README.md ``` ### 步骤 1) 漏洞管理策略草案制定 此阶段的重点是起草一份初步的漏洞管理策略，作为利益相关者参与和项目实施的基础。 [策略草案](https://docs.google.com/document/d/1CLSWm1_9JL1oUqgyNNwtPXW6FzXJ7ddVnSAUQTyqC8I/edit?usp=drive_link) ### 步骤 2) 模拟会议：策略认可 (利益相关者) 在此阶段，与服务器团队举行会议，介绍漏洞管理策略草案，并评估其满足修复时间表的能力。反馈导致了调整，例如将关键修复窗口从 48 小时延长至一周，确保了协作式实施。 #### 主要收获 在与服务器团队进行策略审查讨论期间，各方对最初的修复时间表提出了担忧。 提议的策略要求在 **48 小时内** 修复关键漏洞，团队表示由于当前的人员配置水平，这很难满足。 为了平衡安全要求与运营现状，达成了以下调整： - 将 **关键漏洞修复窗口延长至一周**。 - **48 小时修复窗口** 仅用于严重的零日漏洞。 - 为各部门提供策略推行后的 **6 个月调整期**。

查看完整会议记录

## 策略讨论：漏洞修复时间线 **Sun:** 早上好，Dimitri。我知道过去几周大家都很忙。情况怎么样？ **Dimitri:** 早上好，Sun。确实有点忙乱，但我们还能应付。我审查了策略草案，总体上是合理的。然而，鉴于我们目前的人员配置水平，要满足那些紧迫的修复时间表——特别是 **48 小时的关键漏洞修复窗口**——会非常困难。 **Sun:** 我理解。那个时间表确实相当紧迫，尤其是在启动新项目时。或许我们可以折衷一下，将关键漏洞的修复窗口延长至 **一周**。然后我们可以将 **48 小时窗口** 保留给真正严重的问题，例如 **零日漏洞**。 **Dimitri:** 听起来很合理。我们感谢这种灵活性。在开始阶段，当团队适应修复和补丁流程时，是否可以允许一些灵活性？ **Sun:** 当然。策略定稿后，我们将正式启动该项目。不过，我们计划给所有部门 **大约六个月的时间来适应** 新的漏洞管理流程。 **Dimitri:** 这听起来很公平。我们会尽力而为，我也很感激能被纳入决策过程。这让我们感觉自己是解决方案的一部分。 **Sun:** 没问题。我们都朝着同一个目标努力。谢谢与我们的合作。 **Dimitri:** 谢谢这次简短的会议。 **Sun:** 这是我最喜欢的会议类型。再聊。

### 步骤 3) 策略定稿与高层领导签署 在收集了服务器团队的反馈后，对策略进行了修订，解决了修复时间表过于紧迫的问题。在获得上层管理的最终批准后，该策略现在指导着该项目，确保合规性并作为解决阻力的参考。 [最终定稿的策略](https://docs.google.com/document/d/1rvueLX_71pOR8ldN9zVW9r_zLzDQxVsnSUtNar8ftdg/edit?usp=drive_link) ### 步骤 4) 模拟会议：初始扫描许可 (服务器团队) 安全团队与服务器团队协调，开始计划中的凭证漏洞扫描，同时解决了运营和安全方面的担忧。 ### 扫描授权讨论 在启动漏洞扫描之前，团队审查了扫描过程并讨论了潜在的操作影响。 关键议题包括： - 安排 **每周的凭证漏洞扫描** - 预计扫描持续时间：**约 200 个资产需 4–6 小时** - 潜在的 **资源利用率影响** - 使用 **管理员凭据** 时的安全考虑 为了降低风险并确保安全推出，两个团队同意： - 先对 **单个服务器进行初始扫描** - 监控系统 **性能和资源利用率** - 使用 **临时的 Active Directory 凭据** - 实施 **即时 (JIT) 访问模型**，仅在扫描窗口期间启用凭据，之后将其禁用 这种协作方式确保了扫描过程既 **安全又在操作上可控**。

查看完整模拟会议记录

## 扫描计划讨论：凭证漏洞扫描 **Sun:** 早上好，Dimitri。 **Dimitri:** 早上好，Sun。我听说你们准备好开始进行一些漏洞扫描了。 **Sun:** 是的。既然我们的漏洞管理策略已经到位，我们计划开始对服务器环境进行定期的凭证扫描。 **Dimitri:** 听起来不错。这具体涉及什么，我们需要如何配合？ **Sun:** 我们计划安排每周对服务器基础设施进行扫描。根据我们的估计，扫描大约 200 个资产的完整环境大约需要 4-6 小时。 为了执行更深入的评估，我们需要管理员凭据，允许扫描引擎远程登录到目标系统。 **Dimitri:** 稍等一下。扫描具体包含什么？我担心资源利用率问题，而且向所有服务器提供管理员凭据也会引发一些安全担忧。 **Sun:** 这些都是合理的担忧。扫描引擎向服务器发送各种类型的流量，以检查已知漏洞。这包括检查系统配置、检查注册表、检测过时的软件以及识别不安全的协议或密码套件。凭据允许扫描程序执行更深入的检查，并发现原本会隐藏的漏洞。 **Dimitri:** 我明白了。只要扫描不会对服务器性能或可用性产生负面影响，我们就没问题。 **Sun:** 绝对没问题。为了安全起见，我们可以先从扫描单个服务器开始，并监控系统的资源利用率。 **Dimitri:** 听起来是个不错的方法。 **Sun:** 很好。关于凭据，您的团队可以创建一个临时的 Active Directory 账户用于扫描吗？理想情况下，该账户默认保持禁用状态，仅在扫描窗口期间启用，然后在之后禁用或删除。这将提供一种即时访问模型。 **Dimitri:** 这行得通。我会让 Susan 开始着手自动化账户配置过程。 **Sun:** 完美。凭据准备好后请告诉我。 **Dimitri:** 我会的。再聊。 **Sun:** 好的。回头见。

### 步骤 5) 服务器团队资产初始扫描 在此阶段，配置了一台故意不安全的 Windows Server 来模拟服务器团队的环境。引入了几个漏洞以代表企业环境中常见的安全弱点。 随后使用 Tenable Vulnerability Management 进行了 **经过身份验证的漏洞扫描**，以建立 **基线漏洞配置文件**。该基线提供了一个参考点，用于指导项目后期进行的修复工作。 **扫描结果**

**基线发现** | 严重性 | 数量 | |--------|------| | 严重 | 2 | | 高危 | 8 | | 中危 | 13 | | 低危 | 1 | | **总计** | **24** | **识别出的关键漏洞** - 由过时软件引起的多个 **Wireshark 漏洞** - **WinVerifyTrust CVE-2013-3900 配置错误** - **SMB 签名未强制要求** - **中等强度密码套件 (SWEET32)** - **已弃用的 TLS 协议** - **ICMP 时间戳泄露** [完整扫描报告](evidence/scans/scan-1-baseline-vulnerability-assessment.pdf) ### 步骤 6) 漏洞评估与优先级排序 我们评估了漏洞，并根据修复难度和影响制定了修复优先级策略。设定了以下优先级： 1. 第三方软件移除 (Wireshark) 2. Windows OS 安全配置 (协议与密码) 3. Windows OS 安全配置 (来宾账户组成员身份) 4. Windows OS 更新 ### 步骤 7) 向修复团队分发修复方案 服务器团队收到了修复脚本和扫描报告，以解决关键漏洞。这简化了他们的工作并为他们进行了后续审查做好了准备。 [修复邮件](https://github.com/joshmadakor1/lognpacific-public/blob/main/misc/remediation-email.md) ### 步骤 8) 模拟会议：初始发现扫描后 (服务器团队) 在初始发现扫描之后，安全团队和服务器团队审查了漏洞发现并讨论了修复计划。 ### 漏洞发现审查 主要发现包括： - **过时的软件** (服务器上安装了 Wireshark) - **不安全的账户配置 (来宾账户被添加到本地管理员组) - **已弃用的加密配置** - TLS 1.0 - TLS 1.1 - 中等强度密码套件 预计与 **Microsoft Edge 和其他 Windows 组件** 相关的某些漏洞将通过组织的 **补丁管理流程** 自动解决。 为了简化修复，安全团队开始准备 **修复包**，这些修复包将在部署前通过 **变更控制委员会 (CAB)** 审查和批准。

查看完整模拟会议记录

## 扫描后审查：漏洞发现 **Sun:** 早上好，Dimitri。今天怎么样？ **Dimitri:** 周一还算不错。你呢？ **Sun:** 还活着，所以没什么可抱怨的。在我们深入讨论漏洞之前，你们的扫描进行得怎么样？有没有注意到任何中断或资源利用率问题？ **Dimitri:** 扫描进行得很顺利。我们密切监控了服务器，除了开放连接的增加外，我们根本不知道有扫描在运行。 **Sun:** 听到这个消息很好。这对于配置正确的扫描来说通常是预期的结果。我们将继续监控，但我预计不会出现任何性能问题。 你介意我过一遍漏洞发现吗？ **Dimitri:** 请讲。 **Sun:** 我们检测到的大部分漏洞都与安装了 Wireshark 且版本严重过时有关。 另一个有趣的发现是，几台服务器上的本地来宾账户是本地管理员组的成员，这构成了安全风险。 其他一些发现可能会通过 Windows 更新自动解决，例如 Microsoft Edge Chromium 漏洞。 此外，我们识别出了几个已弃用的加密配置，包括： - 中等强度密码套件 - TLS 1.0 和 TLS 1.1 协议 这些协议已过时，应将其禁用以提高安全性。 我们还检测到了一个自签名证书，但这对于某些内部系统来说是预期行为，目前不需要修复。 总体而言，关键修复领域包括： - 从服务器中移除 Wireshark - 从本地管理员组中移除来宾账户 - 禁用已弃用的 TLS 协议和密码套件 **Dimitri:** 这非常有帮助。好消息是我们的大多数服务器可能都有类似的配置，因此修复应该在环境中相当一致。 **Sun:** 这其实是有益的。统一的配置使修复更容易自动化。 您预见在修复密码套件或已弃用协议时会有任何问题吗？ **Dimitri:** 我不预计会有任何重大问题。我们将通过变更控制委员会 (CAB) 运行修复，以确保在部署前一切得到批准。 卸载 Wireshark 和修复来宾账户成员身份也应该很简单，因为这些配置不应存在于生产服务器上。 **Sun:** 这是个好消息。我将开始构建修复包，以便在实施修复时让您的团队更轻松。 另外，你们已经有针对 Windows 更新相关漏洞的补丁管理了吗？ **Dimitri:** 是的，我们有。Windows 更新是自动处理的，这些漏洞应在下一个计划的补丁周期内解决。 **Sun:** 完美。我将开始研究剩余发现的最佳修复方法，并在下次变更控制委员会会议之前提供这些包。 **Dimitri:** 听起来不错。再聊。 **Sun:** 再聊。

### 步骤 9) 模拟 CAB 会议：实施修复 变更控制委员会 (CAB) 审查了在初始漏洞扫描期间发现的漏洞的修复计划。 ### CAB 修复审批 提议的修复侧重于通过以下方式提高加密安全性： - 禁用 **已弃用的 TLS 协议** (TLS 1.0 和 TLS 1.1) - 移除 **不安全的密码套件** 为了确保在整个环境中安全实施，部署计划包括： - **分层推出策略** - 试点组 - 预生产系统 - 全面生产部署 - **自动回滚脚本**，能够在发生意外问题时恢复原始注册表设置 在审查了修复方法和回滚程序后，CAB 批准了这些变更以进行部署。

查看完整 CAB 会议记录

## CAB 会议：修复实施 **Soren:** 议程上的下一项是服务器团队请求的两项修复措施： 1. 移除不安全的协议 2. 移除不安全的密码套件 看起来风险部门的 Sun 一直与基础设施部门的 Dimitri 合作进行此变更。Dimitri，您能向我们介绍一下技术细节吗？ **Dimitri:** 通常我会介绍，但 Sun 实际上开发了这个修复方案，我们还在适应这个流程。Sun，你介意解释一下吗？ **Sun:** 当然。不安全协议和密码套件的问题在于，系统能够协商已弃用的加密算法或通信协议。 如果系统连接到另一个仅支持那些过时选项的系统，机器可能会使用它们。这些设置通过 Windows 注册表控制。 为了修复这个问题，我们开发了一个 PowerShell 脚本，该脚本： - 禁用已弃用的协议，如 TLS 1.0 和 TLS 1.1 - 禁用不安全的密码套件 - 仅启用现代、安全的加密标准 实施本身很简单。 **Sami:** 听起来不错，但如果出现问题怎么办？我们有回滚计划吗？ **Sun:** 是的，当然。 首先，部署将遵循分层推出流程，包括： 1. 试点组 – 一小部分系统 2. 预生产环境 3. 全面生产部署 此外，我们开发了一个全自动回滚脚本。如果发生任何意外问题，回滚脚本将恢复原始注册表值，重新启用以前的协议和密码配置。 **Sami:** 这很合理。由于修复涉及注册表更新，我不太担心。 **Sun:** 正是。变更是受控且可逆的。 还有其他问题吗？ _(无其他问题。)_ **Soren:** 好了，本周的 CAB 会议到此结束。下周见。

### 步骤 10) 修复工作 在基线评估期间识别出的漏洞分多个阶段进行了修复。 每个修复步骤之后都进行了经过身份验证的验证扫描，以确认漏洞已成功解决。 #### 修复轮次 1：移除过时的 Wireshark 过时版本的 Wireshark 引入了多个严重和高危漏洞。 服务器团队使用 PowerShell 修复脚本移除了 Wireshark。 移除后，后续扫描确认所有与 Wireshark 相关的漏洞已被消除。 脚本参考： [Wireshark 移除脚本](https://github.com/joshmadakor1/lognpacific-public/blob/main/automation/remediation-wireshark-uninstall.ps1) **扫描结果**

[完整扫描报告](evidence/scans/scan-2-remediation-wireshark-removal.pdf) #### 修复轮次 2：不安全的协议与密码套件 检测到了遗留协议和弱密码套件，包括易受 SWEET32 攻击的配置。 使用 PowerShell 脚本禁用了不安全的协议和密码套件，并强制执行现代加密标准。 使用的脚本： - [PowerShell：不安全协议修复](https://github.com/joshmadakor1/lognpacific-public/blob/main/automation/toggle-protocols.ps1) - [PowerShell：不安全密码套件修复](https://github.com/joshmadakor1/lognpacific-public/blob/main/automation/toggle-cipher-suites.ps1) **扫描结果**

[完整扫描报告](evidence/scans/scan-3-remediation-protocols-cipher-suites.pdf) #### 修复轮次 3：来宾账户组成员身份 为了模拟权限提升风险，来宾账户被手动添加到了本地管理员组。 尽管此配置错误是故意引入的，但 **漏洞扫描器并未检测到它**，这突显了自动化漏洞评估的局限性。 因此，该问题 **使用 PowerShell 脚本手动修复**，以从管理员组中移除客户账户。 脚本参考： [来宾账户组成员身份修复](https://github.com/joshmadakor1/lognpacific-public/blob/main/automation/toggle-guest-local-administrators.ps1) **扫描结果**

[完整扫描报告](evidence/scans/scan-4-remediation-guest-account-group-membership.pdf) #### 修复轮次 4：Windows OS 更新 重新启用并安装了 Windows 更新，直到系统达到最新的补丁级别。 尽管打补丁并未消除所有漏洞，但它确保系统安装了最新的 Microsoft 安全补丁。 **扫描结果**

[完整扫描报告](evidence/scans/scan-5-remediation-windows-updates.pdf) #### 修复轮次 5：WinVerifyTrust CVE-2013-3900 缓解措施 扫描识别出系统易受 **CVE-2013-3900** 攻击，该漏洞与不安全的 WinVerifyTrust 签名验证行为有关。 开发了一个 PowerShell 修复脚本来强制执行所需的注册表配置： `EnableCertPaddingCheck = 1` 此缓解措施应用于两个必需的注册表路径，以满足扫描器验证。 修复仓库： [CVE-2013-3900 WinVerifyTrust 缓解脚本](https://github.com/SDimitri05/cve-2013-3900-winverifytrust-mitigation) **扫描结果**

[完整扫描报告](evidence/scans/scan-6-remediation-enablecertpaddingcheck.pdf) #### 修复轮次 6：强制 SMB 签名 扫描检测到 **SMB 消息签名未被要求**，这可能允许对 SMB 会话进行中间人攻击。 使用 PowerShell 在客户端和服务器配置上强制执行了 SMB 签名。 修复仓库： [SMB 签名强制脚本 (Nessus Plugin 57608)](https://github.com/SDimitri05/nessus-57608-smb-signing-required) **扫描结果**

[完整扫描报告](evidence/scans/scan-7-remediation-smb-signing-enforced.pdf) #### 修复轮次 7：ICMP 时间戳泄露缓解 系统响应 **ICMP 时间戳请求**，这可能暴露对侦察有用的系统时间信息。 实施了 PowerShell 修复脚本以禁用 ICMP 时间戳响应。 修复仓库： [ICMP 时间戳缓解脚本 (Nessus Plugin 10114)](https://github.com/SDimitri05/nessus-10114-icmp-timestamp-mitigation) **扫描结果**

[完整扫描报告](evidence/scans/scan-8-remediation-icmp-timestamp-disabled.pdf) ### 漏洞减少时间线 | 扫描 | 阶段 | 漏洞数量 | |-----|------|------| | 扫描 1 | 基线 | 24 | | 扫描 2 | 移除 Wireshark | 6 | | 扫描 3 | 协议加固 | 5 | | 扫描 4 | 修复来宾账户 | 5 | | 扫描 5 | Windows 更新 | 5 | | 扫描 6 | 修复 WinVerifyTrust | 4 | | 扫描 7 | 强制 SMB 签名 | 3 | | 扫描 8 | ICMP 缓解 | 2 | ### 首轮修复工作总结 修复过程显著减少了环境中的漏洞数量。 - 初始基线：**24 个漏洞** - 修复后的最终结果：**2 个漏洞** - **100% 的严重漏洞已解决** - **高危漏洞已消除** - 中危漏洞通过配置加固和打补丁得以减少。 **总体减少：** 修复周期内 **漏洞减少了 91.7% (24 → 2)**。 #### 漏洞减少可视化

图表生成工具： generate-vulnerability-chart.py

**支持数据** - [修复数据 (CSV)](evidence/data/vulnerability_scan_data.csv) - [下载修复数据](evidence/data/vulnerability_scan_data.xlsx) ### 项目成果 通过实施此漏洞管理项目，组织建立了一个与行业安全实践对齐的 **持续漏洞管理生命周期**。 该项目为在整个环境中识别、确定优先级和修复漏洞建立了一个结构化的流程： 1. **漏洞发现** – 经过身份验证的扫描识别系统弱点与配置问题。 2. **风险评估与优先级排序** – 根据严重性、可利用性和潜在业务影响对漏洞进行评估。 3. **修复计划** – 安全团队与基础设施团队协调，确定适当的修复策略。 4. **变更管理审批** – 修复行动通过变更咨询委员会 (CAB) 进行审查和批准。 5. **修复部署** – 实施配置加固、打补丁和系统变更。 6. **验证与核实** – 后续漏洞扫描确认修复行动成功解决了已识别的问题。 7. **持续监控** – 持续的扫描和安全审查确保快速识别并解决新引入的漏洞。 通过实施此生命周期，组织改善了其 **整体安全态势**，减少了对已知漏洞的暴露，并建立了一个 **可重复的流程来管理安全风险**。 ### 步骤 11) 持续的漏洞管理 (维护模式) 完成初始修复周期后，漏洞管理项目将过渡到 **维护模式**。 此阶段确保随着系统的演变和新威胁的出现，漏洞继续被识别、评估和修复。 漏洞管理不再是一次性的工作，而是成为 **集成到正常 IT 工作流程中的持续安全操作**。 维护模式期间的关键活动包括： #### 定期漏洞扫描 定期（例如每周或每月）执行经过身份验证的漏洞扫描，以识别由软件更新、配置变更或新披露的 CVE 引起的新漏洞。 #### 补丁与更新管理 持续应用安全补丁和更新，以保持系统完整性并最大限度地减少对已知漏洞的暴露。 #### 基于风险的修复 对新漏洞进行分类和优先级排序，依据是严重性、可利用性和潜在业务影响，确保关键问题优先得到修复。 #### 策略执行 漏洞管理策略定义了修复时间表、上报路径以及各技术团队的责任，以确保一致的漏洞处理。 #### 合规与审计 定期审查确保漏洞管理项目保持与安全框架和合规要求一致。 #### 利益相关者协调 安全团队与基础设施、系统管理和应用程序团队保持持续合作，以协调修复工作并最大限度地减少运营影响。 ### 经验教训 在此漏洞管理周期中出现了一些关键见解： - **自动化扫描器存在局限性。** 扫描未检测到一个故意引入的权限提升配置错误（管理员组中的来宾账户）。 - **仅靠打补丁无法解决所有漏洞。** 配置弱点和不安全的协议需要手动修复。 - **配置加固是漏洞管理的关键组成部分。** - **验证扫描至关重要**，用于确认修复成功并衡量风险降低情况。 这些观察结果强调了在企业漏洞管理项目中结合 **自动化扫描、配置管理和手动安全审查** 的重要性。

标签：AI合规, Azure 虚拟机, BlazeGraph, CISA项目, CIS Controls, GPT, IPv6, NIST CSF, PowerShell, Tenable, Windows Server, 人工智能安全, 企业安全, 合规性, 安全实验室, 安全架构, 安全运营, 扫描框架, 智能体, 漏洞优先级, 漏洞管理, 端点安全, 网络安全, 网络安全审计, 网络资产管理, 补丁管理, 隐私保护