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.
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.
Alexis (VM SecAnalyst):
Thanks for making the time today John. I wanted to walk through the draft Vulnerability Management Policy and get your feedback before it goes to leadership. The aim is to set clear, achievable expectations around how quickly we remediate vulnerabilities.
John (SrvTMgr):
Sure. We’ve heard about new requirements coming, but we need to make sure they’re realistic for our workload.
Alexis (VM SecAnalyst):
Exactly. Right now, the draft policy sets remediation timelines based on severity:
- Critical vulnerabilities: 48 hours
- High vulnerabilities: 7 days
- Medium vulnerabilities: 30 days
- Low vulnerabilities: 90 days
The idea is to reduce exposure while balancing operational needs.
John (SrvTMgr):
48 hours for criticals is going to be tough. We manage hundreds of servers, many with legacy applications. Coordinating patches, testing, and CAB approvals in 48 hours is often impossible.
Alexis (VM SecAnalyst):
That’s a fair concern. Our priority is reducing risk, but we need your team’s input to make the policy practical. What would be achievable without sacrificing stability?
John (SrvTMgr):
If we had one week for criticals, we could plan emergency maintenance windows, run tests, and still get CAB approval. That would keep us from rushing into production changes.
Alexis (VM SecAnalyst):
That makes sense. So, if we extend the critical remediation window from 48 hours to 7 days, your team could realistically comply without major disruptions?
John (SrvTMgr):
Yes. One week is doable. For highs, seven days is fine—we already align patching to weekly cycles.
Alexis (VM SecAnalyst):
Great. We can adjust the draft to:
- Critical: 7 days
- High: 14 days (to give more buffer alongside criticals)
- Medium: 30 days
- Low: 90 days
This still addresses the risk but gives your team the breathing room it needs.
John (SrvTMgr):
That feels much more achievable. My team will be more willing to support this if they know the policy is designed with their realities in mind.
Alexis (VM SecAnalyst):
Exactly what we want—collaboration. I’ll revise the draft to reflect this input before it goes to leadership. We’ll also build in reporting so both your team and leadership can track progress transparently.
John (SrvTMgr):
Sounds good. If the policy is flexible but structured, we can make it work.
Alexis (VM SecAnalyst):
Perfect. Thanks for the input—this helps ensure the policy is something we can all stand behind and actually implement. Bye!
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.
Alexis (VM SecAnalyst):
{Good Morning/Good Afternoon} and thanks for meeting with me, John. As part of strengthening our security posture, we’d like to initiate scheduled credentialed vulnerability scans across the server environment. I wanted to talk through this with you before we move forward.
John (SrvTMgr):
I’ll be honest—scans have me concerned. They can be resource-heavy, and the last thing we need is something that impacts performance or availability.
Alexis (VM SecAnalyst):
I completely understand. System stability is critical, and that’s why I’m here to align before taking any steps. Credentialed scans give us much more accurate results than agentless checks or network-only scans, but we want to roll this out in a way that’s safe and transparent.
John (SrvTMgr):
What exactly are you asking from my team?
Alexis (VM SecAnalyst):
To start, we’d like to run a pilot scan on just one non-production server that your team selects. We’ll monitor CPU, memory, and network impact during and after the scan. If we see any issues, we’ll stop immediately and re-evaluate.
John (SrvTMgr):
That sounds safer. But what about credentials? Granting permanent service accounts is a big risk.
Alexis (VM SecAnalyst):
Agreed. We don’t want standing credentials either. The plan is to use just-in-time Active Directory credentials. These accounts will only be created temporarily during the scan window, and then they’ll be revoked automatically. That way, access is controlled and auditable.
John (SrvTMgr):
Okay, so we’re not leaving any permanent accounts hanging around?
Alexis (VM SecAnalyst):
Exactly. No standing privileges, no unmanaged passwords. Everything is logged, and you’ll have visibility.
John (SrvTMgr):
If we do this on one server first and it doesn’t cause problems, then we can look at expanding?
Alexis (VM SecAnalyst):
That’s the idea. Start with a controlled pilot, validate the impact together, and then scale in phases. You’ll stay fully in the loop, and your team can help decide the pace.
John (SrvTMgr):
Alright, I’m willing to let you test on one server, as long as my team is involved in monitoring the results.
Alexis (VM SecAnalyst):
Perfect—that collaboration is exactly what we want. I’ll draft a pilot plan, including the server you nominate, the scan schedule, and how we’ll monitor impact. Then we’ll review it with you before running anything.
John (SrvTMgr):
Sounds like a plan. Let’s move forward that way.
Alexis (VM SecAnalyst):
Understood and we will get back to you with the rest of the scan. Bye!
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).
Alexis (VM SecAnalyst):
Thanks for sitting down with me, John. We’ve got the results from our initial vulnerability discovery scan, and I’d like to review them with you so we can align on next steps.
John (SrvTMgr):
Okay, let’s see what we’re dealing with.
Alexis (VM SecAnalyst):
The scan flagged three main categories:
- Outdated software versions – several servers are still running [example: OpenSSL 1.0.x] which is no longer supported.
- Insecure accounts – we found some local admin accounts with weak or non-expiring passwords.
- Deprecated protocols – a handful of servers are still using SMBv1, which is vulnerable to known exploits.
John (SrvTMgr):
That’s not surprising—we’ve had some legacy systems hanging around. My main concern is how much work this will create for my team and what risk it introduces to production stability.
Alexis (VM SecAnalyst):
Totally understood. To manage that, we’ve grouped the findings into remediation packages—essentially action bundles—for submission to the Change Advisory Board (CAB). Each package is designed to be handled during normal maintenance windows to reduce impact.
John (SrvTMgr):
What do those packages look like?
Alexis (VM SecAnalyst):
For example:
- Package 1: Update OpenSSL to the supported version on 12 affected servers.
- Package 2: Audit and disable insecure local accounts, enforce password policies.
- Package 3: Disable SMBv1 and validate application compatibility.
Each package includes rollback steps in case something breaks, and we’ll provide CAB with risk justification and impact analysis.
John (SrvTMgr):
That’s helpful. But SMBv1 worries me—some of our older apps may depend on it.
Alexis (VM SecAnalyst):
That’s a valid concern. For SMBv1, we’ll propose a staged approach:
- Test disabling on one non-critical server.
- Validate app functionality.
- If issues arise, request a temporary exception and escalate to the application owners.
John (SrvTMgr):
Okay, I like that phased approach. What’s the timeline you’re thinking?
Alexis (VM SecAnalyst):
We’ll align with your existing change calendar. If CAB approves, the first package could go into the next maintenance cycle. The critical ones—like insecure accounts—we should prioritize sooner, since they’re low-effort and high-risk.
John (SrvTMgr):
Makes sense. If you prepare the CAB submissions, my team can review them before they go up. That way, we’re confident in what we’re committing to.
Alexis (VM SecAnalyst):
Perfect. I’ll finalize the remediation packages, share them with your team for review, and then submit to CAB. Once approved, we’ll track remediation progress together and update leadership.
John (SrvTMgr):
Sounds good. Thanks for framing this in a manageable way.
Alexis (VM SecAnalyst):
Thanks for your partnership. The goal here is to reduce risk while respecting your team’s capacity and change processes. Bye!
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.
James (CAB Facilitator):
Next on the agenda is the proposal to remove insecure protocols and cipher suites identified during the vulnerability scan. Alexis, please walk us through it.
Alexis (VM SecAnalyst):
Thank you. The scans flagged several servers still supporting deprecated protocols like TLS 1.0 and weak cipher suites such as RC4. These represent exploitable security risks.
Our remediation plan is structured to minimize disruption and includes three key elements:
- Tiered deployment – starting with non-production servers, then lower-risk production, and finally high-criticality systems.
- Rollback script – developed by the system engineering team, allowing us to re-enable prior configurations quickly if issues are detected.
- Validation checkpoints – after each phase, server and application owners will confirm system stability before moving forward.
James (CAB Facilitator):
Thank you. John, does this align with your team’s operational capacity?
John (SrvTMgr):
Yes. We’ve reviewed the approach with the system engineering team. The tiered rollout respects our maintenance windows and avoids overwhelming the team with changes across all environments at once.
James (CAB Facilitator):
Sara, can you expand on the technical safeguards?
Sara (Lead SysEngr.):
Of course. The rollback script has been tested in our staging environment. If a legacy application fails due to the removal of older protocols, we can restore the prior configuration in under ten minutes. During the tiered rollout, we’ll monitor logs, CPU usage, and service connectivity. Any anomalies will trigger immediate rollback and escalation.
James (CAB Facilitator):
That’s reassuring. What’s the proposed timeline?
Alexis (VM SecAnalyst):
- Phase 1: Non-production servers in the upcoming maintenance window.
- Phase 2: Lower-risk production within two weeks.
- Phase 3: High-criticality systems within 30 days, contingent on successful prior phases.
James (CAB Facilitator):
Understood. What risks remain?
Sara (Lead SysEngr.):
The primary risk is legacy applications that may still depend on deprecated protocols. That’s why we’re validating after each phase. If we find dependencies, exceptions will be documented and escalated for risk acceptance.
John (SrvTMgr):
And my team will coordinate with application owners after each change. We’re confident this approach balances security urgency with operational stability.
James (CAB Facilitator):
Excellent. With the phased approach, rollback safety net, and monitoring controls, the CAB approves this remediation plan. Please provide progress updates after each deployment phase.
Alexis (VM SecAnalyst):
Will do. We’ll track completion in the vulnerability dashboard and report back after each stage.
John (SrvTMgr):
My team will handle scheduling and execution, keeping both security and CAB updated.
Sara (Lead SysEngr.):
And I’ll oversee the technical implementation and validation.
James (CAB Facilitator):
Perfect. Approval granted—proceed as planned.
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.