In this project, I 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 (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: Outdated Wireshark Removal
- Remediation Round 2: Insecure Protocols & Ciphers
- Remediation Round 3: Guest Account Group Membership
- Remediation Round 4: Windows OS Updates
- 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.
I simulated a stakeholder meeting with the Server Team to validate whether the initial Vulnerability Management Policy draft was realistic.
- The original draft proposed very aggressive timelines (Critical = 48 hours for all systems).
- The server team pushed back, explaining that:
- 48 hours is not realistic for all Critical findings across all servers,
- change windows and testing requirements must still be respected,
- the team is small and needs to prioritize.
As a result of the discussion, the following compromise was agreed for the first implementation cycle:
- Critical remediation SLA is extended from 48 hours to 5 days, with a clear statement that internet-facing, high-criticality systems are prioritized within that window
- The initial rollout is treated as pilot on a limited set of Windows servers owned by the server team.
- The Security / Vulnerability Management function commits to providing tested remediation scripts (e.g. Wireshark removal, insecure protocol/cipher hardening, guest account fixes) to reduce operational friction.
- The policy explicitly confirms that all remediation activities must still follow existing change management and CAB processes.
This keeps the policy aligned with risk reduction goals while making the SLAs and expectations achievable for the server team.
After gathering feedback from the server team in Step 2, the Vulnerability Management Policy was updated to:
- extend the Critical remediation SLA from 48 hours to 5 days for the first implementation cycle,
- explicitly prioritize internet-facing, High-criticality systems within the Critical SLA window,
- clarify that remediation work which may affect stability must follow the existing change management and CAB process.
The revised policy was then presented to senior leadership (CISO/CIO equivalent) for approval. In this scenario, leadership accepts the updated SLAs and agrees that:
- the policy will initially be applied as a pilot to a limited set of Windows servers, and
- the signed-off policy becomes the baseline reference for future vulnerability management activities and for handling any pushback.
With this sign-off, the policy moves from draft to the governing document for the remainder of the vulnerability management implementation project.
With the policy approved, the next step was to agree on how to run authenticated vulnerability scans against the server team's assets.
During this mock meeting, the server team raised several practical concerns:
- the potential performance impact of full credential scans on production servers,
- the risk of scanning during business hours (CPU spikes, service degradation),
- how scan credentials would be created, stored and protected.
To address these concerns, we agreed on the following approach for the first implementation cycle:
- Start with a single pilot Windows server owned by the server team, instead of scanning all servers at once.
- Run the initial authenticated scan outside of business hours, with the server team monitoring resource usage during the scan window.
- Use a just-in-time Active Directory account with limited permissions, created before the scan and disabled/removed immediately afterward.
- Share the planned scan configuration and schedule in advance so the server team can prepare and rollback if needed.
This compromise allowed the vulnerability management function to collect real scan data while keeping operational risk low and building trust with the server team.
In this phase, an insecure Windows Server is provisioned to simulate the server team's environment. After creating vulnerabilities, an authenticated scan is performed against the pilot server. The goal is to establish a baseline of detected vulnerabilities before any remediation work is carried out, and to export the results for later comparison.
After the initial authenticated scan, we reviewed the Tenable findings and grouped them into logical remediation categories. The goal was to address the highest-risk and easiest-to-fix items first while aligning with the SLAs defined in the Vulnerability Management Policy.
Based on severity, exploitability and implementation effort, the following remediation priorities were set:
- Third-Party Software Removal (Wireshark) - outdated packet capture tool with Critical/High vulnerabilities installed on the server.
- Windows OS Secure Configuration (Protocols & Ciphers) - deprecated/insecure protocols and cipher suites exposed to the network.
- Windows OS Secure Configuration (Guest Account Group Membership) - misconfiguration allowing an unnecessary guest account to remain in a privileged group.
- Windows OS Updates - missing security updates required to reduce the remaining vulnerability backlog.
Based on the prioritized findings from the initial Tenable scan, a remediation package was prepared for the server team. The goal was to make it as easy as possible for them to act on the results by providing:
- the initial scan report for the pilot server,
- a short summary of the key vulnerabilities grouped by category,
- PowerShell-based remediation scripts for each category (Wireshark removal, protocol/cipher hardening, guest account fix, Windows Updates), and
- clear instructions on how and when to apply the changes.
The package was shared with the server team via email, and a follow-up meeting was scheduled to walk through the findings, answer questions and confirm the implementation plan.
Remediation Email (WIP)
After the remediation package had been shared, a follow-up meeting was held with the server team to review the initial scan and the proposed fixes.
During this meeting, the team:
- walked through the main vulnerability categories (outdated Wireshark, insecure protocols and ciphers, guest account misconfiguration, missing Windows Updates),
- confirmed that the provided PowerShell scripts were technically feasible to run on the pilot server,
- identified the appropriate maintenance window for applying the changes, and
- agreed which remediations would require a formal Change Advisory Board (CAB) request due to potential impact on availability (e.g. protocol/cipher hardening).
The outcome of the meeting was a shared remediation plan: the server team would implement the scripts during the next approved change window, and the vulnerability management function would schedule a follow-up authenticated scan to verify the results.
The Change Control Board (CAB) reviewed the proposed remediation plan for the pilot Windows server. The plan covered:
- removal of outdated third-party software (Wireshark),
- hardening of insecure protocols and cipher suites,
- correction of the guest account group membership, and
- application of pending Windows security updates.
During the meeting, CAB focused on the potential impact on availability and compatibility, especially for protocol and cipher changes. To reduce risk, the following safeguards were agreed:
- a rollback script would be prepared and tested in a lab VM for protocol/cipher changes,
- changes would be deployed in a tiered approach (pilot server first, then broader rollout if no issues are observed),
- all changes would be performed during an agreed maintenance window,
- follow-up authenticated scans would be run after each major change, and the results attached to the change ticket as evidence.
With these conditions in place, CAB approved the remediation plan for the pilot server.
Remediations were implemented in four rounds. After each round, a targeted authenticated Tenable scan was run to verify that the specific category of vulnerabilities had been reduced or fully remediated before moving to the next change.
The server team used a PowerShell script to remove outdated Wireshark. A follow-up scan confirmed successful remediation.
Scan 2 - Third Party Software Removal
The server team used PowerShell scripts to remediate insecure protocols and cipher suites. A follow-up scan verified successful remediation, and the results were saved for reference.
Scan 3 - Ciphersuites and Protocols
The server team removed the guest account from the administrator group. A new scan confirmed remediation, and the results were exported for comparison.
Scan 4 - Guest Account Group Removal
Windows updates were re-enabled and applied until the system was fully up to date. A final scan verified the changes.
Across the baseline scan (Scan #1) and subsequent remediation scans (Scan #2-#5), the pilot Windows server showed a significant reduction in vulnerability risk.
- **Baseline (Scan #1): 30 vulnerabilities in total
- 3 Critical, 9 High, 17 Medium, 1 Low
- After all four remediation rounds (Scan #5): 10 vulnerabilities in total
- 1 Critical, 1 High, 6 Medium, 2 Low
Key outcomes:
- Critical + High vulnerabilities were reduced from 12 to 2 (~83% reduction).
- Critical issues decreased from 3 -> 1; High from 9 -> 1.
- Medium vulnerabilities decreased from 17 -> 6 (~65% reduction) as configuration issues and missing updates were addressed.
- The remaining Critical/High/Medium/Low findings are either lower-risk items covered by compensating controls or scheduled for future hardening cycles.
The chart below visualizes the vulnerability trend by severity across the first remediation cycle:
The first cycle demonstrates that even on a single pilot server, applying a structured vulnerability management process - policy, stakeholder alignment, CAB-approved changes, scripted remediations and follow-up scans - can materially reduce risk while staying within agreed operational constraints.
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.
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.