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: 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
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.
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.
Date: October 7, 2025
Participants:
- Jay
- Alex
Jay: Good morning, Alex. How have things been? I know everyone’s been busy these past few weeks.
Alex: Good morning, Jay. It’s been a bit hectic, but we’re managing. Thanks for asking. I had a chance to review the policy draft. Overall, it makes sense. However, given our current staffing levels, we won’t be able to meet the aggressive remediation timelines—especially the 48-hour window for critical vulnerabilities.
Jay: I understand. That timeline may be too aggressive to start. Perhaps we can extend the remediation window for critical vulnerabilities to one week as a compromise. We can reserve the 48-hour requirement for truly severe zero-day vulnerabilities.
Alex: That sounds reasonable. We appreciate the flexibility. Would it also be possible to allow some leeway during the first few months while we adjust to the remediation and patching process?
Jay: Absolutely. Once the policy is finalized, we’ll officially launch the program, but we plan to give all departments about six months to adjust and become comfortable with the new process. Does that sound fair?
Alex: Yes, thank you. We’ll do our best. I appreciate being included in the decision-making process—it helps us feel like part of the solution.
Jay: Of course. We’re all working toward the same goal. Thanks for collaborating.
Alex: Thank you for keeping the meeting concise.
Jay: Those are my favorite kind. Talk soon.
Alex: Sounds good. Take care.
- Discussion centered on the new policy draft and remediation timelines.
- Agreement to extend the critical vulnerability window from 48 hours to one week.
- Departments will have a six-month adjustment period after policy finalization.
- Positive collaboration and mutual understanding emphasized.
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.
Here is the updated dialogue with Monica replaced by Jay and Jimmy replaced by Alex:
Alex: Morning, Jay. Good morning! I heard you’re ready to run some scans.
Jay: Yep. Now that our vulnerability management policy is in place, I want to get started on scheduled credentialed scans across your environment.
Alex: Sounds good to me. What’s involved? How can we help?
Jay: We’re planning weekly scans of the server infrastructure. It should take about four to six hours to cover all 200 servers. We’ll need administrative credentials so the scan engine can remotely log into each target for a deeper assessment.
Alex: Hold on, what exactly does scanning involve? I’m concerned about resource utilization. Also, you’re asking for admin credentials to 200 machines? That doesn’t sound safe.
Jay: Fair concern. The scan engine sends specific traffic to each server to check for vulnerabilities. It reviews registry settings, outdated software, insecure protocols, and weak cipher suites. Credentials are required so the scan can securely verify system configurations.
Alex: Alright. As long as it doesn’t take the servers offline, I’m fine with that.
Jay: It won’t. Let’s start with a single server and monitor resource usage before scaling up.
Alex: Not a bad idea.
Jay: Also, for credentials, could you create an Active Directory account specifically for scanning? Keep it disabled until we’re ready. We’ll enable it during the scan and then disable or deprovision it afterward—essentially using just-in-time access.
Alex: That works. I’ll ask Susan to handle the automation for account provisioning.
Jay: Perfect. Talk soon.
Alex: Sounds good. I’ll reach out once the credentials are ready. See you later.
Jay: See you.
- Scan Scope: Pilot scan on a single server, expanding to 200 servers after testing
- Frequency: Weekly scheduled scans
- Duration: 4–6 hours estimated for a full environment scan
- Access Method: Temporary Active Directory credentials
- Safeguard: Just-in-time access: enable during scan, disable afterward
Jay and Alex agreed to begin with a controlled scan on one server to observe performance impact. The approach balances security with operational stability. Once verified, full environment scans will proceed using temporary, securely managed credentials.
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).
Here is the updated version with the names replaced:
Jay: Morning, Alex. How are you doing?
Alex: Not bad for a Monday. And yourself?
Jay: I’m still alive, so I can’t complain. Before we dive into the vulnerabilities, how did the actual scan go on your end? Any outages or overutilization?
Alex: The scan went well. We monitored everything, and aside from some open connections, we wouldn’t have known a scan was running.
Jay: That’s good news. I expected as much. We’ll keep monitoring, but I don’t anticipate any resource utilization issues. Do you mind if I go over the vulnerability findings?
Alex: Go ahead.
Jay: Great. So, most of these vulnerabilities come from Wireshark being installed. You can see several versions here, all of them very outdated. That’s the main issue.
One interesting thing: the local guest account on some servers belongs to the local administrators group. I’m not sure why that’s the case.
Some of the other items might resolve automatically through Windows Updates, such as the Microsoft Edge Chromium update.
As for the self-signed certificate finding, we don’t need to worry about it, since it’s the machine’s own certificate.
What we should address are the medium-strength cipher suites and TLS 1.0 and 1.1. Those protocols are deprecated, so they need to go.
Basically, our remediation scope looks like this:
- Uninstall Wireshark
- Remove or disable the guest account from admin groups
- Disable TLS 1.0 and 1.1
- Update or remove weak cipher suites
Alex: Makes sense. The good news is most servers likely share the same vulnerabilities. That’ll make remediation easier.
Jay: Exactly. A uniform pattern makes the rollout more efficient. Do you foresee any issues addressing these, especially the cipher suites and protocols?
Alex: I doubt it. We’ll run them through the next Change Control Board. Uninstalling Wireshark and fixing the guest account shouldn’t be a problem. Those shouldn’t be on servers anyway. I’ll check with our CIS admins.
Jay: Sounds good. I’ll start building remediation packages to make your work easier once you’re ready to apply fixes.
Alex: Appreciate that. One question, though: do we have something in place for Windows Update–related vulnerabilities?
Jay: Yes, I’m not worried about those. Our patch management should handle them automatically by next week.
Alex: Excellent.
Jay: I’ll research the best approach to remediate the remaining issues and circle back before the next Change Control Board meeting.
Alex: Sounds good. Talk to you soon.
Jay: Talk soon.
- Key Vulnerabilities:
- Outdated Wireshark installations
- Guest account assigned to local administrators group
- Deprecated TLS 1.0 / 1.1 protocols
- Medium-strength cipher suites
- Low-Risk Findings:
- Self-signed certificates (no remediation needed)
- Edge Chromium and other update-related issues (auto-patched via Windows Update)
- Remove outdated software: Uninstall Wireshark from all servers.
- Account hardening: Ensure guest accounts are not part of the administrators group.
- Protocol deprecation: Disable TLS 1.0 and TLS 1.1 across all systems.
- Cipher upgrade: Replace medium-strength cipher suites with strong modern equivalents.
- Patch assurance: Verify Windows Update and Patch Management coverage.
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.
Facilitator: Karen
Manager: Fred
Infrastructure: Alex
Risk Department: Jay
- Removal of insecure protocols
- Removal of insecure cipher suites
Karen: Next up on the list are a couple of vulnerability remediations for the server team. Number one: removal of insecure protocols. Number two: removal of insecure cipher suites.
Karen: It looks like Jay from the Risk Department is working with Alex from Infrastructure on this. Alex, do you want to walk us through the technical aspects of the change being implemented?
Alex: Normally I would, but Jay actually built the solution for us. We’re still getting used to the process, so I’ll let him take it.
Jay: Sure. Insecure cipher suites and protocols mean the system can still negotiate outdated algorithms or communication methods. If a server or application only supports those older protocols, the system might use them, which creates a security risk. These settings are controlled through the Windows Registry.
We wrote a PowerShell script that disables all insecure protocols and cipher suites, then enables only the secure, current standards. It’s simple, repeatable, and ensures consistency across all servers.
Fred: That sounds good, but what if something goes wrong? Do we have a rollback plan in place?
Jay: Yes, absolutely. We’re using a tiered deployment approach. It starts with a small pilot group, moves to pre-production, and finally full production. Each remediation includes an automated rollback script. If anything unexpected happens, the script restores the original protocols and cipher suites.
Alex: That sounds solid. These are just registry updates, so I’m not too concerned.
Jay: Exactly. It’s straightforward and low-risk, and the tiered rollout adds extra safety.
Karen: Any more questions from anyone?
Alex: Nothing from me.
Jay: Same here.
Karen: Great. That wraps things up for this week’s CAP meeting. See you all next week.
- Objective: Disable deprecated SSL/TLS protocols and medium-strength cipher suites.
- Method: PowerShell script to update Windows Registry.
- Rollout Plan: Tiered deployment (pilot → pre-production → production).
- Rollback: Automated restoration script for original settings.
- Impact: Minimal, registry-only configuration change.
- Validation: Verify secure protocol negotiation post-remediation.
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.