Vulnerability Management Program

Design and run a complete vulnerability management program end to end for an organization with no existing practice: policy drafting, stakeholder buy-in, scanning, prioritization, remediation, and validation. Built as a self-directed simulation using a fictional organization (AllSafe) to practice the full lifecycle, not just the scanning half of it.

A simulated corporate environment built on Azure Windows Server 2019 Datacenter targets, scanned with Tenable's Nessus engine. Stakeholder negotiations (the server team, systems engineering, and the Change Advisory Board) were run as structured mock meetings to mirror how a real rollout actually gets negotiated, not just how the scanning gets done.

The program was built in order: draft a vulnerability management policy, negotiate realistic remediation timelines with the server team, get sign-off from leadership, negotiate scan access starting with a single pilot workstation before expanding, run the first authenticated scan, prioritize findings by ease of remediation and impact, hand remediation scripts to the server team, and walk the fix through Change Advisory Board approval before running four remediation rounds and a validation scan after each one.

1. Step 01

   Drafted a vulnerability management policy defining scope, responsibilities, and remediation timelines.

2. Step 02

   Negotiated the policy with the server team; the 48-hour critical remediation window became a 48-hour mitigation plus 7-day remediation window, with an expedited change path added.

3. Step 03

   Finalized the policy and secured senior leadership sign-off.

4. Step 04

   Negotiated scan access: started with one pilot workstation to validate performance impact before expanding, using just-in-time credentials instead of static scan accounts.

5. Step 05

   Ran the first authenticated scan against the server team's environment.

6. Step 06

   Prioritized findings by ease of remediation and impact: third-party software removal, insecure protocols and ciphers, guest account privilege, then OS updates.

7. Step 07

   Handed remediation scripts and scan reports to the server team ahead of a follow-up review.

8. Step 08

   Walked the server team through the scan results and confirmed scanning caused no performance impact.

9. Step 09

   Presented the protocol and cipher-suite remediation to the Change Advisory Board with a tiered rollout and a rollback script.

10. Step 10

    Ran four remediation rounds: removed outdated Wireshark, disabled insecure protocols and cipher suites, removed the Guest account from Administrators, and applied pending OS updates.

11. Step 11

    Validated each round with a follow-up scan before moving to the next.

Each remediation round is backed by its own PowerShell script and a before/after scan. The Wireshark removal script checks for the installer path before running a silent uninstall; the protocol and cipher-suite scripts toggle the Schannel and TLS registry keys (and can flip back to the insecure state for testing); the Guest-account script checks local group membership before adding or removing it from Administrators. All four are written to be idempotent, so re-running one against an already-remediated host is a no-op instead of an error.

Prioritizing by ease of remediation and impact meant the first fixes (removing an unauthorized packet-capture tool, and pulling the Guest account out of Administrators) were also the fastest wins, which built stakeholder trust before the Change Advisory Board had to sign off on something riskier like disabling legacy TLS protocols. The full cycle took total findings from 30 to 6: critical vulnerabilities were eliminated entirely by the second scan, high-severity findings dropped 90%, and medium-severity findings dropped 76%.

Protocol and cipher-suite changes went through Change Advisory Board approval with a tiered rollout (pilot group, then pre-production, then full production) and a rollback script that restores the original registry values if a legacy system breaks. Each of the four remediation rounds was validated with its own follow-up scan before the next round started, instead of batching all four changes and re-scanning once at the end.

The technical fixes were the easy part. The real constraint was throughput on the human side: getting the server team comfortable with authenticated scanning meant starting with one pilot workstation and showing the actual performance impact, not just asserting it would be fine. And the policy's original 48-hour critical remediation window turned out to be unrealistic the moment it met a real change-approval process; renegotiating it to 48-hour mitigation plus a 7-day remediation window, with an expedited path for critical items, is exactly the kind of adjustment a policy needs before it's worth enforcing.