Goal: Simulate standing up a full Vulnerability Management Program from “no policy / no process” to a completed remediation cycle with repeatable operations.
Technology used
- Tenable (enterprise vulnerability management platform)
- Microsoft Azure Virtual Machines (Nessus scan engine + scan targets)
- PowerShell and Bourne Again Shell (Bash) (remediation scripts)
Program workflow (high level)
- Draft vulnerability management policy and define roles/responsibilities.
- Obtain stakeholder buy-in and senior leadership approval.
- Perform initial authenticated vulnerability scanning.
- Triage and prioritize findings (severity + operational impact).
- Execute controlled remediation via Change Advisory Board (CAB) approvals.
- Re-scan to validate fixes and measure improvement.
- Transition into a steady maintenance cadence (repeatable cycle).
First cycle result (project simulation)
- Reduced total findings from 30 → 6 (80% reduction), documented through rescans and a remediation summary.
Repository artifacts
docs/→ policy, runbooks, and change-control templates (sanitized)scripts/→ remediation automation (PowerShell)evidence/→ screenshots and sanitized scan proofmetrics/→ tracking outputs (sanitized CSVs)diagrams/→ workflow + architecture diagrams
docs/— policy, runbooks, and change-control templates (sanitized)scripts/— remediation automation (PowerShell)evidence/— screenshots and sanitized proofmetrics/— tracking outputs (sanitized)diagrams/— workflow + architecture diagrams
- Policy:
docs/policy/vulnerability-management-policy.md - Runbook:
docs/runbooks/vulnerability-scan-triage-runbook.md - Change Control (CAB template):
docs/change-control/cab-change-template.md - Risk acceptance template:
docs/change-control/risk-acceptance-template.md - Workflow diagram (Mermaid):
diagrams/workflow.mmd - Cycle 1 evidence:
evidence/scan-cycle-1-evidence.md - Metrics:
metrics/severity-trend.csv+metrics/severity-trend.png
flowchart TD
A[Policy + Scope] --> B[Stakeholder Buy-In]
B --> C[Leadership Approval]
C --> D[Authenticated Scan]
D --> E[Triage + Prioritize]
E --> F[CAB / Change Control]
F --> G[Remediation]
G --> H[Rescan + Validation]
H --> I[Metrics + Reporting]
I --> J[Maintenance Cadence]
- Start with Quick Links (policy, runbook, CAB template, evidence, metrics).
- Review Cycle 1 evidence for before/after validation.
- Open scripts/ to see remediation automation used in the walkthrough.
- Check metrics/ to see the severity trend CSV + chart.
| Scan | Critical | High | Medium | Low | Total |
|---|---|---|---|---|---|
| baseline | 2 | 9 | 17 | 1 | 29 |
| rescan_1 | 0 | 1 | 4 | 1 | 6 |
Counts sourced from Tenable scan summaries — see evidence/scan-cycle-1-evidence.md.
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 & 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: 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.
Draft Policy
Sanitized Policy (this repo)
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 one week, ensuring collaborative implementation.
Context: A brief conversation about adjusting vulnerability remediation timelines to match current staffing capacity, while keeping a strict standard for truly urgent cases.
Aman: Morning, Bob. How’ve things been on your end?
Aman: I know the last few weeks have been nonstop for everyone.
Bob: Good morning, Aman. Yeah busy, but we’re managing.
Bob: I reviewed the vulnerability policy draft. Overall, it’s solid, but I’m concerned about the remediation timelines.
Bob: With our current staffing, hitting the critical deadline in 48 hours just isn’t realistic.
Aman: That’s fair. I can see how that would be tough, especially at the start.
Aman: What if we adjust the “Critical” target to five business days for now?
Aman: And we keep the 48-hour requirement only for exceptional situations—like an actively exploited zero-day or something with immediate impact?
Bob: I like that approach. It gives us something achievable without lowering the bar too much.
Bob: Would it also be possible to have a ramp-up period while teams get used to the new patching workflow?
Aman: Absolutely. After the policy is approved, we’ll launch the program, but we can build in a six-month transition period.
Aman: During that time, we’ll track progress, tune the process, and provide support so everyone can meet the cadence.
Bob: That sounds fair. Thanks for being flexible and involving us early.
Bob: It helps when it feels like we’re building the solution together.
Aman: Exactly. We’re on the same team. Appreciate you taking the time to review it.
Bob: No problem—thanks for keeping it quick.
Aman: Quick meetings are my favorite. Talk soon!
Bob: Sounds good. See you later.
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
Sanitized Policy (this repo)
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.
Context: A short discussion about starting scheduled credentialed vulnerability scans after the vulnerability management policy is approved, addressing concerns about performance impact and secure credential handling.
Aman: Morning, Bob.
Aman: I heard you’re ready to start conducting some scans.
Bob: Yep. Now that our vulnerability management policy is in place, I want to get started with scheduled credentialed scans of your environment.
Aman: Sounds good. What’s involved, and how can we help?
Bob: We’re planning weekly scans of the server infrastructure.
Bob: We estimate it’ll take about 4–6 hours to scan roughly 200 assets.
Bob: To run a credentialed scan, we’ll need administrative credentials so the scan engine can remotely authenticate and perform deeper checks.
Aman: Hold on, what does scanning actually entail?
Aman: I’m worried about resource utilization. Also, admin credentials across 200 machines doesn’t sound safe.
Bob: Those are valid concerns.
Bob: The scan engine sends controlled traffic to systems to check for known vulnerabilities. With credentials, it can do deeper inspection, like verifying patch levels, checking for outdated software, reviewing system configuration (for example, registry settings), and identifying insecure protocols and weak cipher suites.
Bob: That’s why credentials are required for a more accurate assessment.
Aman: Okay. As long as it doesn’t take servers offline, we should be fine.
Bob: Absolutely. Let’s start by scanning a single server first and monitor resource utilization during the scan.
Aman: Good idea.
Bob: For credentials, can you create a dedicated account in Active Directory for the scanner?
Bob: We can keep it disabled until we’re ready to scan, enable it during the scan window, then disable or deprovision it afterward. Kind of a just-in-time access approach.
Aman: That works. I’ll ask Susan to start the automation for provisioning the scan account.
Bob: Perfect, talk soon.
Aman: Sounds good. I’ll follow up once the credentials are ready. See you later.
Bob: See you later.
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:
- Third Party Software Removal (Wireshark)
- Windows OS Secure Configuration (Protocols & Ciphers)
- Windows OS Secure Configuration (Guest Account Group Membership)
- Windows OS Updates
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).
Context: A follow-up meeting after a credentialed vulnerability scan. They confirm scan impact was minimal, review key findings (outdated software, insecure protocols/cipher suites, and a risky local guest account configuration), and agree on a remediation approach aligned with change control and patch management.
Aman: Morning, Bob. How are you doing?
Bob: Not bad for a Monday. How about you?
Aman: Still alive, so I can’t complain. Before we get into the vulnerabilities, how did the scan go on your end? Any outages or resource overutilization?
Bob: The scan went well. We monitored things closely, and aside from a lot of open connections, we wouldn’t have even known a scan was happening.
Aman: That’s great news and, what I expected. We’ll keep monitoring going forward, but I don’t anticipate resource utilization being an issue.
Do you mind if I dive into the findings?
Bob: Yeah, absolutely.
Aman: Perfect. I’m going to share my screen real quick.
So, most of the findings are tied to Wireshark being installed and, it looks very out of date. That’s driving a large chunk of the vulnerability list.
Aman: One interesting issue: the local Guest account on the servers appears to be a member of a group,
and when I checked, it’s actually in the local Administrators group. I’m not sure why that’s set up that way.
Aman: A few other findings might be resolved automatically through Windows Updates,for example, some Microsoft Edge (Chromium) related items and a couple others that look patch related.
Also, the self-signed certificate item isn’t a major concern in this context since it’s the system’s own self-signed certificate.
Aman: But the medium-strength cipher suites and TLS 1.0 / 1.1 are worth addressing—those protocols and cipher suites are deprecated.
So the main remediation targets are:
- Removing or updating Wireshark
- Disabling deprecated TLS protocols and weak cipher suites
- Fixing/removing the risky Guest account configuration
Bob: Very interesting. The good news is I suspect most of our servers will have the same vulnerabilities, hopefully that makes remediation easier.
Aman: Yeah, that actually is good news, a uniform loadout usually makes things more predictable.
Do you foresee any issues remediating the cipher suites and insecure protocols specifically?
Bob: I highly doubt there will be issues. We’ll run it through the next Change Control Board.
Uninstalling Wireshark and fixing the Guest account shouldn’t be a problem—those shouldn’t be on the servers anyway. I’ll need to talk to our configuration / CIS administrators about how that happened.
Aman: Great. I’ll start building some remediation packages to make it easier when it’s time to implement changes.
Bob: That sounds great. Quick question, do you have anything in place to address the Windows Update, related vulnerabilities? Like patch management?
Aman: Yes, Windows Updates should be handled automatically by next week. We already have patch management in place.
Bob: Excellent.
Aman: Alright, I’ll research the best remediation approach for these findings and get back to you before the next Change Control Board.
Bob: Sounds good, talk to you soon.
Aman: Sounds good. Talk soon.
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.
Context: Weekly Corrective Action Plan (CAP) meeting. The team reviews two remediation items for the server team:
- removal of insecure protocols
- removal of insecure cipher suites
Participants:
- Dean (Change Advisory Board Facilitator)
- Aman (Vulnerability Management Security Analyst)
- Bob (Server Team Manager)
- Sam (Lead Systems Engineer)
Dean: Okay, next up on the list are a couple of vulnerability remediations for the server team:
- removal of insecure protocols, and
- removal of insecure cipher suites.
It looks like Aman from Vulnerability Management is working with Bob from the Server team on this.
Bob, do you want to walk us through the technical aspects of the change?
Bob: Normally I would, but do you mind giving this one to Aman? He actually built the solution for us, and we’re still getting used to the process.
Aman: Yeah, I can explain.
Insecure cipher suites and deprecated protocols mean the system is capable of negotiating older cryptographic options.
If it connects to another system that only supports those older options, there’s a chance it will fall back and use them, which increases risk.
Aman: On Windows, these settings are controlled through the Windows Registry.
The fix is straightforward: we wrote a PowerShell script that disables deprecated protocols and weak cipher suites, and enables modern, secure defaults aligned with today’s standards.
Sam: Makes sense. What’s the rollback plan if something breaks, especially with older applications?
Aman: Great question. We planned for that.
We’re doing a tiered deployment:
- Pilot group (small set of servers)
- Pre-production (wider validation)
- Production (full rollout)
Aman: We also built an automated rollback script. If we see unknown issues, it restores the original protocol and cipher suite configuration.
Bob: My main concern is compatibility. Some legacy integrations may still try to use Transport Layer Security (TLS) 1.0 or Transport Layer Security (TLS) 1.1. How are we confirming nothing critical breaks?
Aman: We’ll validate in the pilot and pre-production phases and confirm:
- services remain available
- application handshakes complete successfully
- no unexpected authentication or connectivity failures
Sam: Since it’s registry, based and we have staged rollout plus rollback, I’m comfortable. Any other controls?
Aman: Change window, monitoring, and clear “go/no-go” criteria before moving to each next phase.
Dean: Any more questions?
Bob: None from me.
Sam: All good here.
Dean: Great, this wraps up this item for this week’s Corrective Action Plan meeting. See you all next week.
Aman: Thanks everyone.
Bob: See you later.
The server team used a PowerShell script to remove outdated Wireshark. A follow-up scan confirmed successful remediation.
Wireshark Removal Script
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.
PowerShell: Insecure Protocols Remediation
PowerShell: Insecure Ciphers Remediation
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.
PowerShell: Guest Account Group Membership Remediation
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
The remediation process reduced total vulnerabilities by 80%, from 30 to 6. Critical vulnerabilities were resolved by the second scan (100%), and high vulnerabilities dropped by 90%. Mediums were reduced by 76%. In an actual production environment, asset criticality would further guide future remediation efforts.
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.