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.
Zack:
Hey, good morning Thomas. How have things been going lately? I know it’s been a busy few weeks.
Thomas:
Good morning, Zack. Yeah, it’s been a bit hectic, but we’re hanging in there. Thanks for checking in. I had a chance to review the policy draft, and overall, it looks solid. The only concern I have is that with our current staffing, we won’t be able to meet some of the more aggressive remediation timelines—particularly the 48-hour window for critical vulnerabilities.
Zack:
That’s totally understandable. It is a bit aggressive, especially as a starting point. How about we extend the critical remediation window to one week for now? We can reserve the 48-hour timeline for truly severe cases, like zero-day vulnerabilities.
Thomas:
Yeah, that sounds like a reasonable compromise. We really appreciate the flexibility.
Zack:
Of course. And we’re also planning to give all departments about six months to adjust to the new process before fully enforcing the policy.
Thomas:
That’s great to hear. Would it be possible to have a bit of leeway during those first few months as we get used to the new remediation and patching workflows?
Zack:
Absolutely. The goal is to make this sustainable, not overwhelming. Once the policy is finalized, we’ll officially launch the program, but we want everyone to feel supported during the transition.
Thomas:
Thanks, Zack. We’ll do our best to get up to speed. I really appreciate you including us in the decision-making—it goes a long way in making us feel like part of the solution.
Zack:
Of course—we’re all in this together. Thanks for working with us on this.
Thomas:
No problem. And thanks for keeping the meeting short—my favorite kind!
Zack:
Same here. Take care, Thomas.
Thomas:
You too. Talk soon.
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.
Zack:
Morning Thomas.
Thomas:
Good morning. I heard you’re ready to conduct some scans?
Zack:
Yep. Now that our vulnerability management policy is in place, I wanted to get started on conducting some scheduled credentialed scans of your environment.
Thomas:
Sounds good to me. What’s involved? How can we help?
Zack:
We’re planning to schedule weekly scans of the server infrastructure. We estimate it’ll take about 4 to 6 hours to scan all 200 assets.
We’ll need you to provide some administrative credentials, which will allow the scan engine to remotely log into the targets for a more thorough assessment.
Thomas:
Whoa, whoa—hold on. What does scanning actually entail? I’m a bit worried about resource utilization.
And you want admin credentials for all 200 machines? That doesn’t sound safe.
Zack:
Those are valid concerns. The scan engine sends traffic to the servers to check for the presence of certain vulnerabilities—
things like outdated software, insecure protocols, or weak cipher suites. It might also check the registry, depending on configuration.
That’s why credentials are needed—to access deeper system info safely.
Thomas:
I see. As long as it doesn’t bring the servers offline, I guess we should be okay.
Zack:
Absolutely. Let’s start by scanning a single server and monitoring the resource utilization closely.
Thomas:
Not a bad idea.
Zack:
Also, for the credentials—could you set up an account in Active Directory for us? Something that stays disabled until we’re ready to scan.
We can enable it during the scan, then disable or deprovision it afterward. Like a just-in-time access model.
Thomas:
That sounds good. I’ll ask Susan to get started on automating the provisioning process.
Zack:
Awesome. Okay, talk soon.
Thomas:
Yeah, sounds good. I’ll get back to you once the credentials are set up.
Zack:
See you later.
Thomas:
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).
Zack:
Morning Thomas, how are you doing?
Thomas:
Not bad for a Monday. And yourself?
Zack:
I’m still alive, so I can’t complain. Before we dive into the vulnerabilities, how did the scan go on your end? Any outages, overutilization, or issues?
Thomas:
The scan went well. We were monitoring everything, and aside from all the open connections, we wouldn’t have even known a scan was taking place.
Zack:
That’s good news. I kind of expected that. We’ll continue to monitor going forward, but I don’t anticipate any resource utilization issues.
Do you mind if I jump into the vulnerability findings?
Thomas:
Yeah, absolutely.
Zack:
Cool, I’ll share my screen real quick.
So, the majority of the vulnerabilities are due to Wireshark being installed—it’s just very out of date.
One interesting thing I noticed: the local guest account on the servers actually belongs to a group, and that group is in the local administrators group. Not sure why that is.
Some of these issues—like the Microsoft Edge Chromium one—might be resolved automatically by Windows Updates. Same with a few others, but I’m not 100% sure.
The self-signed certificate warning isn’t a concern since it’s a local machine certificate.
But the medium-strength cipher suites, and TLS 1.0 and 1.1—those are deprecated protocols and need to be removed.
So basically, we’re looking at three key actions:
- Uninstall outdated Wireshark versions
- Disable or remove the guest account from administrative groups
- Deprecate insecure protocols and cipher suites
Thomas:
Very interesting. The good news is that I suspect most of our servers share the same vulnerabilities. Hopefully, that makes remediation easier.
Zack:
Exactly—it’s actually helpful to have a uniform loadout.
Do you foresee any issues with remediating the cipher suites or deprecated protocols?
Thomas:
I highly doubt it. We’ll run it all through the next Change Control Board.
Uninstalling Wireshark and fixing the guest account shouldn’t be a problem—they shouldn’t be there in the first place. I’ll talk to our CIS admins about that.
Zack:
Sounds good. I’ll go ahead and start building out some remediation packages to make the process smoother for you.
Thomas:
That sounds great. Quick question—do you already have something in place to handle the Windows update-related vulnerabilities? Patch management?
Zack:
Yes, actually. I’m not too worried about those. Windows Updates should take care of them by next week—we have patch management in place.
Thomas:
Okay, excellent.
Zack:
I’ll get started on researching the best way to remediate the rest of the findings and circle back before the next Change Control Board.
Thomas:
Sounds good. Talk to you soon.
Zack:
Cool cool. 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.
Johnny:
Okay, next up on the list are a couple of vulnerability remediations for the server team:
- Removal of insecure protocols
- Removal of insecure cipher suites
It looks like Zack from the Risk department is working in conjunction with Thomas from Infrastructure on this.
Thomas, do you want to walk us through the technical aspects of the change being implemented?
Thomas:
Normally I would, but do you mind if Zack takes this one? He actually built the solution for us—we’re still getting used to the process.
Zack:
Uh, yeah, I can explain these. So basically, the presence of insecure cipher suites and protocols on a system means it can negotiate and use algorithms or protocols that have been deprecated.
If the system connects to a server that only supports those outdated protocols, it might use them. These settings are controlled through the Windows registry.
The fix is simple—we wrote a PowerShell script that disables all insecure protocols and ciphers, and enables only the modern, secure standards.
It’s really straightforward.
Johnny:
That sounds good, but what if something goes wrong? Do we have a rollback plan in place?
Zack:
Yes, absolutely. We're doing a tiered deployment:
- Pilot group (small set of systems)
- Pre-production
- Then full production rollout
On top of that, we’ve built automated rollback scripts for each remediation.
If anything unexpected happens, the script can restore the original registry settings for protocols and ciphers.
Johnny:
Good to know. Since the fixes are just registry updates, I’m not too concerned.
Zack:
Exactly.
Johnny:
Any more questions from anyone?
(No response)
Great—that wraps things up for this week’s CAP meeting. See you all next week.
Everyone:
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.