USAF Veteran with a Summa Cum Laude BS in Cyber Operations from DSU, exploring the vast landscape of information technology one day at a time. ἀρετή
Vulnerability Management Program Implementation
Tenable - Cyber Range Project
July 27, 2025 · 2868 words · 14 min read
Official Cyber Range Project
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.
Technology Utilized
- Tenable (enterprise vulnerability management platform)
- Azure Virtual Machines (Nessus scan engine + scan targets)
- PowerShell (remediation scripts)
Table of Contents
- 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
Vulnerability Management Policy Draft Creation
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
Step 2) Mock Meeting: Policy Buy-In (Stakeholders)
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.
Vulnerability Management Policy Review Meeting
Attendees: Skelly (Cyber/VM Analyst), George (Server Team Manager)
Skelly: Hey, what’s up George? How’s everything been recently? I know everyone’s been running around crazy these last few weeks.
George: Good morning Skelly! Yes, it’s been very hectic but we’re hanging in there, thanks for asking. I had a chance to read through the policy draft and overall it makes sense, however…
Skelly: Uh oh, I sense a “but” coming. Let me guess - the timelines are tighter than we thought?
George: chuckles Exactly! With our current staffing, we can’t meet the aggressive remediation timelines, especially the 48-hour window for critical vulnerabilities. These patches take time to properly test and deploy!
Skelly: Yeah, I totally understand. That timeline is pretty aggressive. Perhaps we can extend the critical close to one week? It might be a good compromise for now, and then we can reserve the 48-hour window for those truly critical zero-day vulnerabilities - you know, the ones that keep everyone up at night.
George: That sounds very reasonable! We appreciate the flexibility. Can we have a bit of leeway in the beginning as we work through getting used to the remediation and patching process? Just for the first few months or so? I don’t want my team feeling overwhelmed!
Skelly: Absolutely, George! After the policy is finalized, we’ll officially start the program, but we’re planning to give all departments about 6 months to adjust and get comfortable with the new process. No need to go from zero to full speed overnight!
George: relieved sigh Thanks Skelly, we’ll do our best! I appreciate you including us in the decision-making process. It really helps feel like we’re part of the solution instead of just being told what to do!
Skelly: grins Of course! We’re all in this together. Thanks for working with us, George.
George: No problem! Thanks for the short meeting - those are my favorite types. Much more productive than hour-long sessions!
Skelly: smiles Same here, buddy. Now if you’ll excuse me, I’ve got to go work on some more security improvements. See ya later!
George: Bye now! And Skelly… thanks for being so flexible with the timelines.
Skelly: off camera Anytime, George!
End of meeting
- Courtesy of claude.ai
Step 3) Policy Finalization and Senior Leadership Sign-Off
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
Step 4) Mock Meeting: Initial Scan Permission (Server Team)
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.
Attendees: Skelly (Cyber/VM Analyst), George (Server Team Manager)
Skelly: Morning, George! What’s up, buddy?
George: Good morning! I heard you ready to conduct some scans?
Skelly: Yep! Now that our vulnerability management policy is in place, I wanted to get started on conducting some scheduled credential scans of your environment, friend.
George: Sounds good to me! What’s involved? How can we help?
Skelly: We’re planning to schedule some 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 us with some administrative credentials which will allow the scan engine to remotely log into the targets to better assess them.
George: Whoa, whoa, hold on there, buddy! What does scanning actually entail? I’m a bit worried about resource utilization! Also, you want admin credentials to all 200 machines? That doesn’t sound safe! That’s very, very dangerous!
Skelly: Those are valid concerns, George. The scan engine basically sends different traffic to the servers that will check for the existence of certain vulnerabilities, which include looking into the registry and looking if certain out-of-date software is installed, or if there’s any insecure protocols or cipher suites - that kind of thing. So that’s why credentials are required.
George: I see… well, as long as it doesn’t bring the servers offline, I guess we should be okay. But I’m still very worried about this whole affair!
Skelly: Absolutely, George! Let’s just scan a single server for now and keep an eye on the resource utilization.
George: Not a bad idea! Great! Also, for the credentials, can you set up something in Active Directory for us? Like some Active Directory credentials you can just leave disabled until we’re ready to do the scan, and then enable them during the scan, and then when it’s finished we can deprovision or at least disable that account? Kind of like a just-in-time access situation?
Skelly: That sounds good, George! I’ll ask Susan to get started on the automation for the account provisioning.
George: Awesome! Okay, talk soon!
Skelly: Yeah, that sounds good! I’ll get back to you once the credentials are set up. Time to go hunting for vulnerabilities!
George: See you later! And remember - be very, very careful with those credentials!
Skelly: Perfect! See ya, George!
End of meeting
- Courtesy of claude.ai
Step 5) Initial Scan of Server Team Assets
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.
Step 6) Vulnerability Assessment and Prioritization
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
Step 7) Distributing Remediations to Remediation Teams
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.
Step 8) Mock Meeting: Post-Initial Discovery Scan (Server Team)
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 Advisory Board (CAB).
Attendees: Skelly (Cyber/VM Analyst), George (Server Team Manager)
Skelly: Morning, George! How are you doing, buddy?
George: Not bad for a Monday, and yourself?
Skelly: I’m still alive so I can’t complain! But before we get into the vulnerabilities, how did the actual scan go on your end? Did you have any outages or over-utilization or anything?
George: The scan went well! We were monitoring them and aside from all the open connections, we would have never known a scan was taking place.
Skelly: Yeah, that’s good news, friend! I kind of expected that much. We can keep monitoring going forward, but I don’t expect we’ll have any issues with resource utilization. Do you mind if I dive into the vulnerability findings?
George: Yeah, absolutely!
Skelly: Cool! I’m going to share my screen really quick. So basically, the majority of these vulnerabilities come from Wireshark being installed. You can see all these Wireshark issues because it’s just super out of date, that’s all. One interesting thing I did find is the local guest account on the servers actually belongs to a group, and I looked deeper - it belongs to the local administrators group! I’m not sure why that is, buddy. Also, some of these might be automatically resolved by Windows updates, like this Microsoft Edge Chromium one, and I’m not sure about this one as well - could be resolved by Windows updates, I’m not really sure. But we don’t have to worry about the self-signed certificate one because it’s just, you know, the computer self-signed cert. But these medium strength cipher suites and TLS 1.1 and 1.0 - these are deprecated cipher suites and deprecated protocols. So I think we should take some time to remediate these. So basically just Wireshark, the protocols, cipher suites, and removing the guest account is what we’re looking at.
George: Very interesting! The good news is I suspect most of our servers are going to have the same vulnerabilities. Hopefully that makes things easier during remediation!
Skelly: Yeah, that’s actually good news, George! Like a uniform rollout. Do you foresee any issues with remediating any specifically, like the cipher suites and the insecure protocols?
George: I highly doubt there will be any issues. We’ll run it through the next Change Control Board. Uninstalling Wireshark and fixing the guest account - those shouldn’t be an issue. Those aren’t supposed to be on the servers anyway! I’ll have to talk to our sys admins about that.
Skelly: Yeah, that’s good news! I’ll go ahead and get started on building out some remediation packages for you to kind of make your life easier when it comes time to fix them.
George: Yeah, that sounds great!
Skelly: Oh, I wanted to ask - do you have anything in place to actually fix the Windows update related vulnerabilities? Like, you have patch management already?
George: Oh, oh yes! I’m not actually worried about that. Windows update should be handled automatically by next week - we have patch management in place.
Skelly: Okay, excellent! All right, I’ll get started on researching the best way to remediate these findings and I’ll get back to you before the next Change Control Board. Time to get to work on those vulnerabilities!
George: Sounds good! Talk to you soon!
Skelly: Perfect! Cool, cool, talk to you soon, George!
End of meeting
- Courtesy of claude.ai
Step 9) Mock CAB Meeting: Implementing Remediations
The Change Advisory 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.
Attendees: Johnny (CAB facilitator), Jack (Lead Sys Engineer), Skelly (Cyber/VM Analyst), George (Server Team Manager)
Johnny: Alright folks, next up on our thrilling agenda - and I use “thrilling” very loosely - we’ve got a couple of vulnerability fixes for the server team. We’re talking removal of insecure protocols and cipher suites. Sounds fancy, right? Skelly from risk and George from infrastructure are tag-teaming this one. George, want to dazzle us with the technical wizardry?
George: chuckles Normally I’d love to bore you all to tears with technical details, but I’m gonna pass the mic to Skelly here. He’s the one who actually figured out how to make our servers stop talking to sketchy websites like they’re at a bad party.
Skelly: laughs Thanks George! Okay, so picture this - our servers are like that friend who’s way too trusting. They’ll chat with anyone using old, terrible security protocols that went out of style faster than flip phones. These cipher suites and protocols are basically the digital equivalent of leaving your house key under a fake rock that says “TOTALLY NOT A KEY HIDING SPOT.”
Jack: smirking Okay, that’s actually a pretty good analogy. But what happens when your fancy script breaks everything and we’re all sitting in the dark crying into our coffee?
Skelly: grins Ah, Jack, always the optimist! Don’t worry, we’ve got this covered better than a helicopter parent. We’re doing a staged rollout - pilot group, pre-production, then full production. It’s like testing the water before jumping in the pool, except the pool is our entire infrastructure. Plus, we built an “oops button” - a rollback script that’ll put everything back the way it was faster than you can say “I probably should’ve read the documentation first.”
Jack: laughs An “oops button”? I like that. And since it’s just registry tweaks, I’m guessing the worst case scenario is someone has to reboot a server and pretend they knew what they were doing all along?
Skelly: Exactly! It’s basically digital housekeeping - out with the old, sketchy stuff, in with the shiny, secure protocols that won’t make our security auditors cry.
Johnny: chuckling Well, this has been surprisingly entertaining for a discussion about cipher suites. Anyone else have questions, or can we all go back to pretending we understand what Skelly just explained?
George: laughing I vote we approve it before Jack thinks of more worst-case scenarios!
Jack: Hey, I’m just keeping you honest! But yeah, sounds good to me.
Johnny: Perfect! That’s a wrap on this week’s CAB meeting. Try not to break the internet before next week, people!
All: various laughs and goodbyes See ya! Don’t break anything! No promises!
End of meeting
- Courtesy of claude.ai
Step 10 ) Remediation Effort
Remediation Round 1: Outdated Wireshark Removal
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
Remediation Round 2: Insecure Protocols & Ciphers
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
Remediation Round 3: Guest Account Group Membership
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
Remediation Round 4: Windows OS Updates
Windows updates were re-enabled and applied until the system was fully up to date. A final scan verified the changes
First Cycle Remediation Effort Summary
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.
On-going Vulnerability Management (Maintenance Mode)
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.