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.
- 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.
JA Vulnerability Management Policy – Draft
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.
The Vulnerability Management team meets with the Server Team to review a new VM policy draft and agree on realistic remediation timelines.
- James — Vulnerability Management / Risk Lead
- William — Server Team Lead
James: Morning, William. How have things been lately? I know the last few weeks have been busy.
William: Morning, James. Yeah, it’s been hectic, but we’re hanging in there. Thanks for asking.
William: I read through the policy draft. Overall it makes sense—but with our current staffing, the remediation timelines feel aggressive.
James: I hear you. Which part is the biggest concern?
William: The 48-hour window for critical vulnerabilities. We can’t consistently hit that right now.
James: That’s fair. What if we compromise: critical vulnerabilities move to one week as the standard expectation…
James: …and we reserve 48 hours only for truly urgent cases—like high-impact, active exploitation / zero-days?
William: That sounds reasonable. We appreciate the flexibility.
William: Can we also have some leeway early on while we get used to the new patching and remediation workflow?
James: Absolutely. After the policy is finalized, we’ll start the program officially—but we’ll give departments about six months to ramp up and adjust to the process.
William: That feels fair. Thanks for including us in the decision-making—it helps us feel like part of the solution.
James: Of course. We’re all in this together. Thanks for partnering with us.
William: Appreciate it. Short meetings are my favorite.
James: Same here. 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.
JA Vulnerability Management Policy – Production
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.
The Vulnerability Management team coordinates with the Server Team to start credentialed scanning. The Server Team raises concerns about performance impact and credential safety, leading to a controlled pilot approach.
- James — Vulnerability Management Lead
- William — Server Team Lead
- Susan — Identity/AD Administrator (supporting JIT credentials)
William: Morning, James. I heard you’re ready to start scanning.
James: Morning. Yep—now that the vulnerability management policy is in place, I want to begin scheduled credentialed scans of your environment.
William: Sounds good. What’s involved—and how can we help?
James: We’re planning weekly scans of the server infrastructure. We estimate 4–6 hours to scan roughly 200 assets.
James: To get accurate results, we’ll need administrative credentials so the scan engine can authenticate and assess configs—like registry settings, installed software versions, and insecure protocols/cipher suites.
William: Hold on—what exactly does scanning entail? I’m worried about resource utilization.
William: And admin credentials to 200 machines doesn’t sound safe.
James: Those are valid concerns. The scanner sends controlled traffic to check for known vulnerabilities, and credentialed checks reduce guesswork and false positives.
James: But we can take this safely: let’s pilot on one server first, closely monitor CPU/memory/network, and confirm there’s no disruption.
William: I like that. If it doesn’t impact production, we can expand from there.
James: Great. On the credential side, can we do just-in-time Active Directory credentials?
James: Create a dedicated account, keep it disabled by default, enable it only during the scan window, and disable/deprovision immediately after.
William: That’s much better. We can automate that.
James: Perfect—can Susan help with the provisioning workflow?
William: Yes, I’ll ask Susan to get started on the automation.
James: Awesome. Once the credentials are ready, we’ll schedule the single-server pilot.
William: Sounds good—talk soon.
James: Talk soon.
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.
[Scan 1 - Initial Scan]
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.
[Remediation Email]
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).
After the initial pilot scan, the teams review results, confirm there was no performance impact, and agree on remediation priorities and change-control steps.
- James — Vulnerability Management Lead
- William — Server Team Lead
James: Morning, William. How are you doing?
William: Not bad for a Monday—how about you?
James: Still alive, so I can’t complain.
James: Before we dive into findings—how did the scan go on your end? Any outages or resource issues?
William: The scan went well. We monitored closely, and aside from a lot of open connections, we wouldn’t have known it was running.
James: That’s great news. I expected it to be light, but we’ll keep monitoring going forward.
James: Mind if I share my screen and walk through the findings?
William: Go for it.
James: Most of these findings appear tied to Wireshark being installed—it’s significantly out of date.
William: That should not be on servers. We can remove it.
James: One item that stood out: the local Guest account is mapped into a group—and it looks like it’s in Local Administrators.
William: That’s definitely not expected. I’ll pull in our CIS admins to investigate how that happened.
James: On the configuration side, we also have deprecated cipher suites and TLS 1.0 / 1.1 still enabled.
William: Do you foresee any issues remediating those?
James: I highly doubt it—but we’ll run it through the Change Control Board.
James: Removing Wireshark and fixing the Guest account should be straightforward.
James: Some findings may resolve via regular patching (like browser components), but the cipher/protocol items need a deliberate configuration change.
William: Patch management is already in place—Windows updates should handle the patch-related items by next week.
James: Perfect. I’ll start building remediation packages and guidance to make execution easier on your side.
William: Sounds good. Let’s align before the next Change Control Board.
James: Will do—talk soon.
William: 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.
In a Change Advisory Board (CAB) meeting, the team proposes remediations to remove insecure protocols and cipher suites using a controlled rollout and automated rollback plan.
- CAB Chair — Facilitates agenda
- James — Risk/Vulnerability Management Lead (solution owner)
- William — Infrastructure/Server Team Representative
CAB Chair: Next up: vulnerability remediations for the Server Team.
CAB Chair: Item one: removal of insecure protocols. Item two: removal of insecure cipher suites.
CAB Chair: James from Risk is partnering with William from Infrastructure. William—want to walk through the technical change?
William: Normally I would, but could we have James cover it? He built the solution and we’re still getting used to the process.
James: Sure—I can explain.
James: Insecure protocols and cipher suites mean systems can still negotiate deprecated crypto.
James: If a legacy endpoint forces weak protocols, the server may accept them—so we need to disable them.
James: On Windows, these settings are controlled via the registry.
James: We wrote a PowerShell script to disable insecure protocols/ciphers and enable the secure, standardized set.
CAB Member: What if something goes wrong—do we have a rollback plan?
James: Yes. We’re doing a tiered deployment:
- Pilot group (small scope)
- Pre-production
- Production (full rollout)
James: We also built an automated rollback script that restores the original protocol/cipher settings if any unexpected issues appear.
CAB Member: That sounds reasonable.
CAB Member: These fixes look like registry updates—so risk seems manageable.
James: Exactly. Straightforward change, controlled rollout, and a tested rollback path.
CAB Chair: Any other questions?
CAB Chair: Great—approved to proceed through the staged rollout. That wraps this week’s CAB. See you next week.
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
[Scan 5 - Post Windows Updates]
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.
[Remediation Data]
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.