Skip to content

Aaniket09/vulnerability-management-program

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

13 Commits
 
 
 
 
 
 

Repository files navigation

Vulnerability Management Program Implementation

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 completed.


image

Technology Utilized

  • Tenable (enterprise vulnerability management platform)
  • Azure Virtual Machines (Nessus scan engine + scan targets)
  • PowerShell (remediation scripts)

Table of Contents


Vulnerability Management Policy Draft Creation

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


Step 2) Mock Meeting: Policy Buy-In (Stakeholders)

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.

Sample Dialogue

Aniket: Morning, Jimmy. How’s everything been? I know it’s been a busy few weeks.

Jimmy: Good morning, Ani. 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.

Aniket: I completely understand. It is somewhat aggressive, especially at the beginning. We could extend the critical timeline to one week as a compromise, and reserve the 48-hour requirement only for truly severe zero-day vulnerabilities.

Jimmy: That sounds reasonable, and we really appreciate the flexibility. Could we also have a bit of leeway in the beginning as we adjust to the remediation and patching process—just for the first few months?

Aniket: Absolutely. Once the policy is finalized, we’ll launch the program, but every department will have about six months to adjust and get comfortable with the new process. Does that sound fair?

Jimmy: Yes, thanks, Ani. We’ll do our best. I appreciate you including us in the decision-making process—it really helps us feel like part of the solution.

Aniket: Of course. We’re all in this together, and I appreciate you working with us.

Jimmy: No problem. Thanks for keeping this meeting short.

Aniket: My favorite kind of meeting. Take care!

Jimmy: See you later.


Step 3) Policy Finalization and Senior Leadership Sign-Off

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


Step 4) Mock Meeting: Initial Scan Permission (Server Team)

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.

Sample Dialogue

Jimmy: Morning, Aniket. Ready to start some scans?

Aniket: Good morning. Yes, now that our vulnerability management policy is in place, I’d like to begin scheduled credentialed scans of your environment.

Jimmy: Sounds good. What’s involved, and how can we help?

Aniket: We’re planning weekly scans of the server infrastructure. It should take about 4–6 hours to cover all 2,200 assets. We’ll need administrative credentials so the scan engine can remotely log into targets for a more accurate assessment.

Jimmy: Hold on—what exactly does the scanning entail? I’m concerned about resource usage. And you’re asking for admin credentials for all 2,200 machines? That doesn’t sound safe.

Aniket: Fair concerns. The scan engine sends traffic to check for vulnerabilities—things like outdated software, insecure protocols, or weak cipher suites. Credentials allow the scan to dig deeper, such as checking the registry and installed software.

Jimmy: Okay, as long as it won’t take servers offline, I think we can proceed.

Aniket: Absolutely. To be safe, let’s start with one server and monitor resource utilization.

Jimmy: Good idea.

Aniket: For credentials, could you set up an Active Directory account for us? Keep it disabled until a scan, then enable it just during the scan. Afterward, disable or deprovision it—essentially a just-in-time access setup.

Jimmy: That works. I’ll ask Susan to automate the account provisioning.

Aniket: Perfect. I’ll follow up once the credentials are ready.

Jimmy: Sounds good. Talk soon.

Aniket: See you later.


Step 5) Initial Scan of Server Team Assets

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.

initial-scan

Scan 1 - Initial Scan


Step 6) Vulnerability Assessment and Prioritization

We assessed vulnerabilities and established a remediation prioritization strategy based on ease of remediation and impact. The following priorities were set:

  1. Third Party Software Removal (Wireshark)
  2. Windows OS Secure Configuration (Protocols & Ciphers)
  3. Windows OS Secure Configuration (Guest Account Group Membership)
  4. Windows OS Updates

Step 7) Distributing Remediations to Remediation Teams

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.

image

Step 8) Mock Meeting: Post-Initial Discovery Scan (Server Team)

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).

Sample Dialogue

Aniket: Morning, Jimmy. How did the scan go? Any issues with resources?

Jimmy: It went well. Monitoring showed no outages or noticeable load.

Aniket: Great. Let’s go over the findings. Most vulnerabilities come from outdated Wireshark. Also, the Guest account is in the local Administrators group on some servers. Deprecated cipher suites and TLS 1.0/1.1 also need attention.

Jimmy: Good news—most servers share the same vulnerabilities, which should simplify remediation.

Aniket: Exactly. Do you foresee issues with fixing the cipher suites and protocols?

Jimmy: Unlikely. We'll run it through Change Control. Uninstalling Wireshark and fixing the Guest account shouldn’t be a problem.

Aniket: I’ll build remediation packages to make fixes easier.

Jimmy: Perfect. And Windows update–related issues are already handled with patch management.

Aniket: Yes. I’ll finalize the remediation approach and update you before the next Change Control Board.

Jimmy: Sounds good. Talk soon.

Aniket: Talk soon.


Step 9) Mock CAB Meeting: Implementing Remediations

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.

Sample Dialogue

CAB Facilitator: Next on the list are a couple of server team vulnerability remediations:

  1. Removal of insecure protocols
  2. Removal of insecure cipher suites

It looks like Aniket from Risk is working with Jimmy from Infrastructure. Jimmy, do you want to walk us through the technical aspects?

Jimmy: Normally, I would, but Aniket actually built the solution.

Aniket: Sure. Insecure protocols and cipher suites mean the system can negotiate deprecated algorithms or protocols. If a server requires them, the system might use them. These settings are controlled via the Windows registry. We wrote a PowerShell script that disables insecure protocols/ciphers and enables only current, secure standards. It’s straightforward.

Jay: Sounds good, but what if something goes wrong? Do we have a rollback plan?

Aniket: Absolutely. We’ll deploy in tiers: pilot group, pre-production, then full production. We also have an automated rollback script for each remediation that restores original protocols/ciphers if issues arise.

Jay: That makes sense. The fixes are just registry updates, so I’m not too concerned.

Aniket: Exactly. Any other questions?

CAB Facilitator: Great. That wraps up this week’s CAP meeting. See you all next week.

All: See you later.


Step 10 ) Remediation Effort

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

wireshark-removal

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

insecure-cipher-protocol-removal

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

guest-account-removal

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

post-windows-update

Scan 5 - Post Windows Updates


First Cycle Remediation Effort Summary

The remediation process reduced total vulnerabilities by 79.31%, from 29 to 6. Critical vulnerabilities were resolved by the second scan (100%), and high vulnerabilities dropped by 88.89%. Mediums were reduced by 76.47%. In an actual production environment, asset criticality would further guide future remediation efforts.

remediation-effort-graph

Remediation Data


On-going Vulnerability Management (Maintenance Mode)

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.


Acknowledgment

This project is inspired by Josh Madakor's project implementation.

Special thanks to LogNPacific Cyber Range for providing a live production environment that supported the testing and validation of this vulnerability management program.

About

No description, website, or topics provided.

Resources

Stars

Watchers

Forks

Releases

No releases published

Packages

 
 
 

Contributors