In this project, we simulate the implementation of a comprehensive vulnerability management program, from inception to completion.
Inception State: the organization has no existing policy or vulnerability management practices in place.
Completion State: a formal policy is enacted, stakeholder buy-in is secured, and a full cycle of organization-wide vulnerability remediation is successfully completed.
- Tenable (enterprise vulnerability management platform)
- Azure Virtual Machines (Nessus scan engine + scan targets)
- PowerShell & BASH (remediation scripts)
- Vulnerability Management Policy Draft Creation
- Mock Meeting: Policy Buy-In (Stakeholders)
- Policy Finalization and Senior Leadership Sign-Off
- Mock Meeting: Initial Scan Permission (Server Team)
- Initial Scan of Server Team Assets
- Vulnerability Assessment and Prioritization
- Distributing Remediations to Remediation Teams
- Mock Meeting: Post-Initial Discovery Scan (Server Team)
- Mock CAB Meeting: Implementing Remediations
- Remediation Round 1: Windows OS Updates
- Remediation Round 2: Guest Account Group Membership
- Remediation Round 3: Outdated Wireshark (Insecure Software)
- Remediation Round 4: Disable SMB Signing
- Remediation Round 5: RDP Without Network Level Authentication (NLA)
- Remediation Round 6: Weak LAN Manager Authentication Level
- First Cycle Remediation Effort Summary
This phase focuses on drafting a Vulnerability Management Policy as a starting point for stakeholder engagement. The initial draft outlines scope, responsibilities, and remediation timelines, and may be adjusted based on feedback from relevant departments to ensure practical implementation before final approval by upper management.
Draft Policy
In this phase, a meeting with the server team introduces the draft Vulnerability Management Policy and assesses their capability to meet remediation timelines. Feedback leads to adjustments, like extending the critical remediation window from 48 hours to 5 buisiness days, ensuring collaborative implementation.
Attendees: Phil Zangara (Vulnerability Analyst), Marcus Webb (Server Manager)
Marcus: Phil, the 48-hour window for Critical findings is going to be a problem. Half our production servers need a maintenance window and stakeholder sign-off before we can even touch them. 48 hours isn't realistic for that group.
Phil: That's fair. What if we split it: Critical findings on internet-facing or high-impact assets stay at 48 hours, but production servers behind change control get 48 hours to mitigate (compensating control, isolation) and 5 business days to fully patch?
Marcus: I can work with that, as long as "mitigate" counts as meeting the SLA on paper. I don't want us flagged as non-compliant every time we buy time with a firewall rule.
Phil: Agreed. I'll add mitigation as an accepted interim response in the policy, logged and tracked until the real patch lands. I'll also add your team's servers as their own maintenance group so the timeline reflects reality instead of one-size-fits-all.
Marcus: That works. Send me the updated draft and I'll sign off.
After gathering feedback from the server team, the policy is revised, addressing aggressive remediation timelines. With final approval from upper management, the policy now guides the program, ensuring compliance and reference for pushback resolution.
Finalized Policy
The team collaborates with the server team to initiate scheduled credential scans. A compromise is reached to scan a single server first, monitoring resource impact, and using just-in-time Active Directory credentials for secure, controlled access.
Attendees: Phil Zangara (Vulnerability Analyst), Marcus Webb (Server Manager)
Marcus: Phil, before we go further, why does the scanner need admin credentials on every server? That's a lot of access to hand out.
Phil: Fair question. Without local admin, Tenable can only do an unauthenticated scan, it pokes at open ports and banners from the outside. That misses most of what actually matters: missing patches, outdated packages, weak configs. Authenticated scans log in locally and check the actual installed software and settings, which is where most real vulnerabilities show up.
Marcus: So it's basically the difference between checking a lock from the sidewalk versus checking it from inside the house.
Phil: Exactly. And it cuts down false positives too, the scanner doesn't have to guess based on what's exposed externally.
Marcus: What about the credentials themselves, are they going to sit in some spreadsheet somewhere?
Phil: No. They'd live in Tenable's credential vault, scoped to a dedicated service account, read-only where possible, and used only during scan windows. Not a standing admin account someone could grab.
Marcus: Okay, that's reasonable. Set up the service account and I'll approve access for the server group.
Phil: Sounds good. I'll send the account request today.
In this phase, an insecure Windows Server is provisioned to simulate the server team's environment. After creating vulnerabilities, an authenticated scan is performed, and the results are exported for future remediation steps.
We assessed vulnerabilities and established a remediation prioritization strategy based on ease of remediation and impact. The following priorities were set:
- Windows OS Updates (Re-enable and apply updates)
- Guest Account Group Membership (Remove from Administrators)
- Third-Party Software Removal (Outdated Wireshark)
- Disable SMB Signing
- RDP Without Network Level Authentication (NLA)
- Weak LAN Manager Authentication Level
The server team received remediation scripts and scan reports to address key vulnerabilities. This streamlined their efforts and prepared them for a follow-up review.
The server team reviewed vulnerability scan results, identifying outdated software, insecure accounts, and deprecated protocols. The remediation packages were prepared for submission to the Change Control Board (CAB).
Attendees: Phil Zangara (Vulnerability Analyst), Marcus Webb (Server Manager)
Marcus: Phil, a few servers spiked in CPU and disk I/O during last week's scan window. Nothing crashed, but it was noticeable.
Phil: Yeah, I saw that too. Mostly on the older database servers. I can throttle scan concurrency and shift that group to a later window with lower load, off-peak hours instead of business hours.
Marcus: That'd help. As long as it doesn't push the monthly scan past our reporting deadline.
Phil: It won't, I'll stagger it across two nights instead of one. Now, on results: we had 12 Critical and 34 High findings from this cycle. All 12 Criticals are remediated or mitigated within SLA: 9 patched, 3 mitigated on your production servers and queued for full patch this week.
Marcus: And the Highs?
Phil: 28 of 34 closed so far, within the 7-day window. The remaining 6 are in progress, still inside SLA.
Marcus: Good. That's real progress. Let's revisit the scan schedule next month and see if the throttling holds up.
Phil: Agreed, I'll bring updated numbers then.
The Change Control Board (CAB) reviewed and approved the plan to remove insecure protocols and cipher suites. The plan included a rollback script and a tiered deployment approach.
Attendees: Phil Zangara (Vulnerability Analyst), Marcus Webb (Server Manager), Elena Ruiz (Lead Systems Engineer), David Okafor (CAB Facilitator)
David: Next item: CR-1042, removal of insecure protocols and cipher suites. Phil, walk us through it.
Phil: This closes out several Medium and High findings from recent scans. TLS 1.0/1.1 and weak ciphers still enabled on a subset of servers. The change disables them and enforces TLS 1.2+ with approved cipher suites only.
David: Elena, from an engineering standpoint?
Elena: We tested in staging, no application breakage, but a couple of legacy internal tools still negotiate TLS 1.0. Those are flagged separately for remediation, not covered by this change.
Marcus: What's the rollback if something breaks in production?
Phil: Rollback script re-enables the previous protocol/cipher config and restarts the affected services, under 5 minutes per server. We're also doing a tiered rollout: dev, then staging, then a 10% production canary group before full deployment.
David: Any objections? ... None noted. CAB approves CR-1042, tiered deployment, rollback script in place, production canary before full rollout.
Phil: Understood, I'll schedule the first tier for this weekend's maintenance window.
Windows updates were re-enabled and applied until the system was fully up to date. A follow-up scan verified the changes.
The server team removed the guest account from the administrator group. A new scan confirmed remediation, and the results were exported for comparison.
Scan 3 - Guest Account Group Removal
The server team used a PowerShell script to remove outdated Wireshark. A follow-up scan confirmed successful remediation.
Scan 4 - Third Party Software Removal
SMB Signing was enabled on the server to enforce message authentication and prevent man-in-the-middle attacks. A follow-up scan confirmed successful remediation.
Scan 5 - SMB Signing Remediation
Network Level Authentication (NLA) was enabled for Remote Desktop connections to require authentication before a session is established. A follow-up scan confirmed successful remediation.
The LAN Manager authentication level was configured to only allow NTLMv2 responses and refuse LM and NTLM. A follow-up scan confirmed successful remediation.
Scan 7 - LAN Manager Authentication Remediation
Remediation Status: Pending Vendor Patch (Windows-Managed Component)
Findings: libcurl 7.64.1 < 8.22.0 Negotiate Ambient User Connection Reuse (CVE-2026-19931) and libcurl 7.64.0 < 8.22.0 HTTP/2 Server Push Use-After-Free (CVE-2026-18924), found on Windows Server 2025 hosts running curl/libcurl 8.16.0.
Reason not remediated: On Windows Server 2025, curl and libcurl are OS components serviced through Windows Component-Based Servicing (WinSxS), not standalone applications. Verification confirmed all instances (System32, SysWOW64, and the WinSxS store) are the OS-managed build, with no third-party bundled copies present. This component can only be updated via a Microsoft cumulative update that bumps curl to 8.22.0 or later; no such update has been released for the affected build as of this report. Manual binary replacement is not viable, as Windows servicing will revert it.
Compensating factors: Both CVEs require non-default conditions to exploit (shared ambient credentials with connection reuse; HTTP/2 server-push connection sharing between handles), neither of which is known to be present in current usage.
Planned action: Hosts will be patched via standard Windows Update/WSUS once Microsoft releases a cumulative update incorporating curl 8.22.0+. Tracked as vendor-pending until then; will be re-verified and closed on the next scan cycle.
The remediation process reduced total vulnerabilities by 80%, from 25 to 5. Critical vulnerabilities were reduced by half (50%), and high vulnerabilities we fully resolved (100%). Medium vulnerabilities were reduced from 12 to 2 (83% reduction). The remaining vulnerabilities (SSL certificates, ICMP Timestamp, and libcurl) will be addressed in the next remediation cycle.
After completing the initial remediation cycle, the vulnerability management program transitions into Maintenance Mode. This phase ensures that vulnerabilities continue to be managed proactively, keeping systems secure over time. Regular scans, continuous monitoring, and timely remediation are crucial components of this phase. (See Finalized Policy for scanning and remediation cadence requirements.)
Key activities in Maintenance Mode include:
- Scheduled Vulnerability Scans: Perform regular scans (e.g., weekly or monthly) to detect new vulnerabilities as systems evolve.
- Patch Management: Continuously apply security patches and updates, ensuring no critical vulnerabilities remain unpatched.
- Remediation Follow-ups: Address newly identified vulnerabilities promptly, prioritizing based on risk and impact.
- Policy Review and Updates: Periodically review the Vulnerability Management Policy to ensure it aligns with the latest security best practices and organizational needs.
- Audit and Compliance: Conduct internal audits to ensure compliance with the vulnerability management policy and external regulations.
- Ongoing Communication with Stakeholders: Maintain open communication with teams responsible for remediation, ensuring efficient coordination.
By maintaining an active vulnerability management process, organizations can stay ahead of emerging threats and ensure long-term security resilience.