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.
Finnis: Good morning, Chase. How’s everything been? I know everyone’s been busy these past few weeks.
Chase: Good morning, Finnis. Yeah, it's been a bit hectic, but we're hanging in there. Thanks for asking. I had a chance to review the policy draft, and overall, it makes sense. However, with our current staffing, we can't meet the aggressive remediation timelines, especially the 48-hour window for critical vulnerabilities.
Finnis: I understand. That timeline is a bit aggressive, especially at the start. As a compromise, we could extend the critical remediation window to one week for now while keeping the 48-hour requirement for severe, zero-day vulnerabilities.
Chase: That sounds reasonable. We appreciate the flexibility. Would it be possible to allow some leeway in the first few months as we adjust to the remediation and patching process?
Finnis: Absolutely. Once the policy is finalized, we’ll officially start the program. But we’re planning to give all departments about six months to adjust and familiarize themselves with the new process. Does that sound fair?
Chase: Thanks, Finnis. We’ll do our best. I appreciate you including us in the decision-making process—it really makes us feel like part of the solution.
Finnis: Of course! We’re all in this together. Thanks for working with us.
Chase: No problem. And thanks for keeping the meeting short.
Finnis: Yeah, those are my favorite kinds. Bye for now.
Chase: See
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.
Finnis: Good morning, Chase. How’s everything been? I know everyone’s been busy these past few weeks.
Chase: Good morning, Finnis. Yeah, it's been a bit hectic, but we're hanging in there. Thanks for asking. I had a chance to review the policy draft, and overall, it makes sense. However, with our current staffing, we can't meet the aggressive remediation timelines, especially the 48-hour window for critical vulnerabilities.
Finnis: I understand. That timeline is a bit aggressive, especially at the start. As a compromise, we could extend the critical remediation window to one week for now while keeping the 48-hour requirement for severe, zero-day vulnerabilities.
Chase: That sounds reasonable. We appreciate the flexibility. Would it be possible to allow some leeway in the first few months as we adjust to the remediation and patching process?
Finnis: Absolutely. Once the policy is finalized, we’ll officially start the program. But we’re planning to give all departments about six months to adjust and familiarize themselves with the new process. Does that sound fair?
Chase: Thanks, Finnis. We’ll do our best. I appreciate you including us in the decision-making process—it really makes us feel like part of the solution.
Finnis: Of course! We’re all in this together. Thanks for working with us.
Chase: No problem. And thanks for keeping the meeting short.
Finnis: Yeah, those are my favorite kinds. Bye for now.
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).
Morning, Jimmy! How are you doing?
Not bad for a Monday. How about you?
I'm still alive, so I can't complain.
Before we dive into the vulnerabilities, how did the actual scan go on your end? Did you have any outages or overutilization?
The scan went well. We were monitoring it, and aside from the open connections, we wouldn't have known the scan was taking place.
That's good news. I kind of expected that. We can keep monitoring moving forward, but I don't expect we'll have any issues with resource utilization.
Do you mind if I dive into the vulnerability findings?
Absolutely, go ahead.
Great, I'm going to share my screen really quick.
So, the majority of these vulnerabilities are related to Wireshark being installed. As you can see, all of these vulnerabilities are due to it being super outdated. One interesting thing I found is that the local guest account on the servers actually belongs to a group. I looked deeper, and it turns out it belongs to the local administrators group. I'm not sure why that is.
Some of these might be automatically resolved by Windows updates, like the Microsoft Edge Chromium vulnerability. I’m not entirely sure about this one though. It could also be fixed by Windows updates.
We don’t need to worry about the self-signed certificate one, since it's just the computer’s self-signed cert.
Now, these medium-strength Cipher Suites and TLS 1.1 and 1.0 are deprecated cipher suites and protocols. I think we should prioritize remediating these.
So, basically, we need to handle Wireshark, the protocols, the cipher suites, and removing the guest account.
Very interesting. The good news is, I suspect most of our servers will have the same vulnerabilities, so hopefully that makes remediation easier.
Yeah, a uniform load-out should help.
Do you foresee any issues with remediating any of these, specifically the cipher suites and insecure protocols?
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 shouldn't be an issue, since those aren’t supposed to be on the servers anyway. I'll talk to our CIS admins about that.
Sounds good. I'll go ahead and start building out some remediation packages to make your life easier when it's time to fix them.
That sounds great!
I wanted to ask: Do you have anything in place to fix the Windows update-related vulnerabilities? Do you have patch management already?
Yes, we have patch management in place. I'm not worried about that. Windows updates should be handled automatically by next week.
Excellent! Alright, 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.
Sounds good. Talk to you soon.
Cool, talk to you 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.
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 Josh from the Risk department is working in conjunction with Jimmy from Infrastructure on this.
Jimmy, do you want to walk us through the technical aspects of the change being implemented?
Normally, I would, but do you mind giving this one to Josh? He actually built a solution for us, and we're still getting used to the process.
Josh:
Yeah, I can explain these.
So, basically, insecure Cipher Suites and protocols mean that the system is capable of negotiating and using some kind of algorithm or protocol that has been deprecated. If it connects to a server that only wants to use those protocols, it's possible that the computer will use them. These protocols are controlled by the Windows registry.
It's a really simple fix. We wrote a PowerShell script that goes through, disables all the insecure protocols and ciphers, and then enables the ones that are standardized and secure. It's a straightforward fix.
That sounds good. But what if something goes wrong? Do we have a rollback plan in place? Did you even think about that?
Yes, absolutely.
First of all, we are going to do a tiered deployment. This means we’ll start with a pilot group, which is a really small set of computers, then move to pre-production, and finally production where it will go everywhere. On top of this, we have a fully built-in, automated rollback script for each remediation. The script will restore the original protocols and ciphers should any unknown issues arise.
That sounds good. I guess since the fixes are simple registry updates, I'm not too concerned.
Yep, exactly.
Any more questions from anyone?
Great, that wraps things up for this week's CAP meeting. See you all next week.
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.