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.
Oscar: Good morning, Jimmy. How’s everything been? I know everyone’s been busy these last few weeks.
Jimmy: Morning, Oscar. 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.
Oscar: I completely understand. That timeline is a bit aggressive, especially at the start. Maybe we can extend the critical remediation window to one week as a compromise, reserving the 48-hour deadline for truly severe zero-day vulnerabilities.
Jimmy: That sounds reasonable. We appreciate the flexibility. Would it also be possible to have some leeway in the beginning as we adjust to the new remediation and patching process? Maybe just for the first few months?
Oscar: Absolutely. Once the policy is finalized, we’ll officially launch the program, but we’re planning to give all departments about six months to adjust to the new process. Does that sound fair?
Jimmy: Thanks, Oscar. We’ll do our best. I really appreciate you including us in the decision-making process—it helps us feel like we’re part of the solution.
Oscar: Of course! We’re all in this together. Thanks for working with us.
Jimmy: No problem. And thanks for keeping this meeting short!
Oscar: My favorite kind. See you later!
Jimmy: See you!
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.
Oscar: Morning, Jimmy. Ready to conduct some scans?
Jimmy: Yep! Now that our vulnerability management policy is in place, I wanted to start running scheduled credential scans of your environment.
Oscar: Sounds good to me. What’s involved, and how can we help?
Jimmy: We’re planning to schedule weekly scans of the server infrastructure. We estimate it’ll take about 4 to 6 hours to scan all 2,200 assets. We’ll need administrative credentials to allow the scan engine to remotely log into the targets for a more thorough assessment.
Oscar: Whoa, hold on. What exactly does the scanning entail? I’m a bit concerned about resource utilization. Also, you’re asking for admin credentials to all 200 machines? That doesn’t sound safe.
Jimmy: Those are valid concerns. The scan engine sends different types of traffic to the servers to check for vulnerabilities. It looks at things like registry settings, outdated software, and insecure protocols or cipher suites. That’s why credentials are required—to get a deeper, more accurate assessment.
Oscar: I see. As long as it doesn’t take the servers offline, we should be okay.
Jimmy: Absolutely. Let’s start by scanning a single server first and monitor resource utilization.
Oscar: Not a bad idea.
Jimmy: Great. Regarding credentials, could you set up something in Active Directory for us? Maybe create a dedicated account that remains disabled until we’re ready to scan—then we enable it for the scan and disable it afterward. A just-in-time access setup.
Oscar: That sounds reasonable. I’ll ask Susan to start automating the account provisioning process.
Jimmy: Awesome. Talk soon!
Oscar: Sounds good. I’ll get back to you once the credentials are set up.
Jimmy: See you later!
Oscar: See you!
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).
Oscar: Morning, Jimmy. How are you?
Jimmy: Not bad for a Monday. You?
Oscar: Still alive, so I can’t complain! Before we get into the vulnerabilities, how did the scan go? Any outages or resource overutilization?
Jimmy: The scan went well. We monitored everything, and aside from all the open connections, we wouldn’t have even noticed it was running.
Oscar: That’s great news. I expected as much, but we’ll keep monitoring to be safe. I don’t anticipate any resource utilization issues. Mind if I jump into the vulnerability findings?
Jimmy: Go ahead.
Oscar: Cool. Let me share my screen.
The majority of the vulnerabilities come from Wireshark being outdated—it's installed on multiple systems.
One interesting find: the local guest account on some servers is part of the local administrators group. I’m not sure why that is, but it’s definitely a security risk.
Some issues may resolve automatically with Windows updates, like the Microsoft Edge Chromium vulnerability. However, I’ll need to confirm if others will be addressed that way.
We can ignore the self-signed certificate warning, as it’s just a system-generated certificate.
The bigger concerns are:
- Medium-strength cipher suites
- Deprecated TLS 1.0 and 1.1 protocols
We should prioritize remediating these. So, in summary, we need to:
- Update or remove Wireshark
- Disable insecure cipher suites and protocols
- Remove the guest account from admin privileges
Jimmy: Interesting. The good news is most of our servers likely have the same vulnerabilities, which should make remediation easier.
Oscar: Exactly—a uniform environment helps. Do you foresee any challenges fixing the cipher suites or insecure protocols?
Jimmy: I doubt it. We’ll run it through the next Change Control Board. Removing Wireshark and fixing the guest account won’t be an issue—those shouldn’t be on the servers anyway. I’ll check with our sysadmins.
Oscar: Sounds good. I’ll start building remediation packages to make fixes easier.
Jimmy: That’d be great. Quick question—do you have a process in place for Windows update-related vulnerabilities?
Oscar: Yes, we have patch management in place. Windows updates should apply automatically by next week.
Oscar: Perfect. I’ll research the best remediation methods and get back to you before the next Change Control Board meeting.
Jimmy: Sounds good. Talk soon!
Oscar: Cool, talk soon!
✨ This document is part of my cybersecurity portfolio. For more projects and insights, check out my GitHub! 🚀
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: Next up, we have a couple of vulnerability remediations for the server team. These include:
- Removal of insecure protocols
- Removal of insecure Cipher Suites
Oscar from the risk department is working with Jimmy from infrastructure on this. Jimmy, would you like to walk us through the technical aspects of the changes being implemented?
Jimmy: Normally, I would, but do you mind if I hand this over to Oscar? He built the solution, and we’re still getting used to the process.
Oscar: Sure, I can explain these.
Insecure cipher suites and protocols are deprecated algorithms or protocols that the system might use if it connects to a server that only supports them. These are controlled by the Windows registry, and allowing them to exist poses a security risk. The fix is straightforward—we wrote a PowerShell script that disables all insecure protocols and ciphers and enables only the current, secure standards. It's a simple and effective solution.
Facilitator: Sounds good. But what if something goes wrong? Do we have a rollback plan in place?
Oscar: Absolutely.
First, we’ll conduct a tiered deployment:
- Pilot Group – A small set of computers.
- Pre-production – A wider group for testing.
- Production – Full rollout to all systems.
Additionally, we’ve developed a fully automated rollback script. This will restore the original protocols and ciphers in case any issues arise during deployment.
Facilitator: That sounds reassuring. I assume the fixes are simple registry updates, so I’m not too concerned.
Oscar: Exactly.
Facilitator: Any more questions from anyone?
Alright, that wraps things up for this week's CAP meeting. See you all next week!
All: See you later!
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
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.