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: Windows OS Updates
- Remediation Round 2: Guest Account Group Membership
- Remediation Round 3: Outdated Wireshark (Insecure Software)
- Remediation Round 4: Disable SMB Signing
- Remediation Round 5: RDP Without Network Level Authentication (NLA)
- Remediation Round 6: Weak LAN Manager Authentication Level
- 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.
Jimmy: Hey, good morning, Berm. How's everything been lately? I know everyone's been busy these past few weeks.
Berm: Good morning, Jimmy. Yeah, it's been a bit 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, with our current staffing levels, we won't be able to meet the aggressive remediation timelines—especially the 48-hour window for critical vulnerabilities.
Jimmy: Yeah, I completely understand. It is a bit aggressive, especially at the beginning. Maybe we can extend the remediation timeline for critical vulnerabilities to one week. That seems like a good compromise for now, and we can reserve the 48-hour requirement for truly critical issues, such as zero-day vulnerabilities.
Berm: Yeah, that sounds reasonable. We appreciate the flexibility. Would it be possible to have a little leeway during the first few months while we get accustomed to the remediation and patching process?
Jimmy: 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 and become comfortable with the new process. Does that sound fair?
Berm: Thanks, Jimmy. 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.
Jimmy: Of course. We're all in this together. Thanks for working with us.
Berm: No problem. Thanks for the short meeting.
Jimmy: Yeah, those are my favorite kinds. Take care!
Berm: You too. See you later.
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.
Berm: Good morning, Jimmy.
Jimmy: Good morning. I heard you're ready to start conducting some scans.
Berm: Yep. Now that our vulnerability management policy is in place, I'd like to begin scheduling credentialed vulnerability scans of your environment.
Jimmy: Sounds good to me. What's involved, and how can we help?
Berm: We're planning to run weekly credentialed scans across your server infrastructure. We estimate it will take about four to six hours to scan all 200 servers.
To perform the scans accurately, we'll need a set of administrative credentials that allow the scan engine to remotely authenticate to the systems. This enables us to perform a much deeper assessment than an unauthenticated scan.
Jimmy: Whoa, hold on a second. What exactly does the scanning process involve? I'm a little concerned about resource utilization. Also, you're asking for administrative credentials to all 200 servers? That doesn't sound very safe.
Berm: Those are completely valid concerns.
The scan engine generates network traffic to assess each server for known vulnerabilities. With administrative credentials, it can also inspect things like the Windows registry, identify outdated software, verify patch levels, and detect insecure protocols or weak cipher suites. That's why credentialed access is recommended—it provides much more accurate results than a standard network scan.
Jimmy: I see. As long as the scans don't impact performance or take any servers offline, I think we should be okay.
Berm: Absolutely. To be safe, let's start by scanning a single server and monitor its resource utilization. If everything looks good, we can proceed with the remaining systems.
Jimmy: That's a good idea.
Berm: Great. Regarding the credentials, would it be possible to create a dedicated Active Directory service account for the scans? You could keep the account disabled until we're ready to run the scan, enable it only during the scanning window, and then disable or deprovision it afterward. That would give us a just-in-time access model and help minimize security risk.
Jimmy: That sounds like a solid approach. I'll ask Susan to begin setting up the automation for provisioning the account.
Berm: Awesome. Thanks—I appreciate it. Talk to you soon.
Jimmy: Sounds good. I'll let you know once the credentials are ready.
Berm: Perfect. See you later.
Jimmy: See you later.
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:
- Windows OS Updates (Re-enable and apply updates)
- Guest Account Group Membership (Remove from Administrators)
- Third-Party Software Removal (Outdated Wireshark)
- Disable SMB Signing
- RDP Without Network Level Authentication (NLA)
- Weak LAN Manager Authentication Level
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).
Berm: Hey, Jimmy before we dive into the vulnerability findings, I wanted to ask how the scan went on your end. Did you notice any outages, performance issues, or unusually high resource utilization?
Jimmy: The scan actually went really well. We monitored the servers throughout the process, and aside from seeing a large number of open connections, we never would have known a scan was taking place.
Berm: That's great to hear. Honestly, that's about what I expected. We'll continue monitoring future scans, but I don't anticipate any resource utilization issues.
Do you mind if I walk you through the vulnerability findings?
Jimmy: Yeah, absolutely.
Berm: Great, so majority of the findings are related to Wireshark being installed on several servers. Most of those vulnerabilities are simply because the installed version is significantly out of date.
One finding that stood out to me is that the local Guest account is a member of the local Administrators group on several servers. I'm not sure if that's intentional, but it's definitely something we should investigate.
There are also a few Microsoft-related findings, such as the Microsoft Edge Chromium vulnerability. I suspect those will be resolved automatically once your regular Windows updates are applied, although we'll want to verify that after patching.
The self-signed certificate finding isn't something I'm overly concerned about since it's just the server's default self-signed certificate.
However, I do recommend prioritizing the deprecated TLS 1.0 and TLS 1.1 protocols, along with the medium-strength cipher suites. Those are no longer considered secure and should be disabled wherever possible.
So, from my perspective, our primary remediation items are:
- Updating or removing the outdated Wireshark installations.
- Removing the local Guest account from the Administrators group.
- Disabling the deprecated TLS protocols and weak cipher suites.
Jimmy: Very interesting.
The good news is I suspect most of our servers are configured the same way, so they'll probably all have similar findings. Hopefully that makes remediation a lot easier.
Berm: I actually see that as a positive. A standardized server configuration usually means we can remediate everything consistently.
Do you foresee any issues with fixing any of these findings, particularly the TLS settings or cipher suites?
Jimmy: I really don't think so. We'll submit the changes through our next Change Control Board meeting.
Uninstalling Wireshark and correcting the Guest account permissions shouldn't be an issue at all. Those really shouldn't be on the servers in the first place. I'll reach out to our CIS administrators to find out how that happened.
Berm: That's good news.
In the meantime, I'll start putting together some remediation guidance and deployment packages to make the remediation process as straightforward as possible.
Jimmy: That would be a huge help.
I did have one question. Do you already have something in place to address the Windows update-related vulnerabilities? Are you using a patch management solution?
Berm: Yes, we are. I'm not too concerned about those findings. Our patch management process is already in place, and Windows updates should be deployed automatically by next week.
Jimmy: Excellent. That's good to hear.
Berm: Perfect. I'll continue researching the best remediation approach for the remaining findings and get everything documented before the next Change Control Board meeting.
Jimmy: Sounds good. Talk to you soon.
Berm: 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.
Windows updates were re-enabled and applied until the system was fully up to date. A follow-up scan verified the changes.
The server team removed the guest account from the administrator group. A new scan confirmed remediation, and the results were exported for comparison.
Scan 3 - Guest Account Group Removal
The server team used a PowerShell script to remove outdated Wireshark. A follow-up scan confirmed successful remediation.
Scan 4 - Third Party Software Removal
SMB Signing was enabled on the server to enforce message authentication and prevent man-in-the-middle attacks. A follow-up scan confirmed successful remediation.
Scan 5 - SMB Signing Remediation
Network Level Authentication (NLA) was enabled for Remote Desktop connections to require authentication before a session is established. A follow-up scan confirmed successful remediation.
The LAN Manager authentication level was configured to only allow NTLMv2 responses and refuse LM and NTLM. A follow-up scan confirmed successful remediation.
Scan 7 - LAN Manager Authentication Remediation
The remediation process reduced total vulnerabilities by 81%, from 23 to 3. Critical vulnerabilities were fully resolved (100%), and high vulnerabilities dropped from 8 to 1 (88% reduction). Medium vulnerabilities were reduced from 12 to 2 (closely 80% reduction). The remaining vulnerabilities (SQLite, Microsoft Edge, SSL certificates, and ICMP Timestamp) will be addressed in the next remediation cycle. 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.