Hi, I'm Michael!
Cybersecurity Professional
At the start, the organisation has no policy, no structure, and no established process for handling vulnerabilities. By the end, a formal policy is in place, key stakeholders are aligned, and the organization has successfully carried out a full end-to-end vulnerability remediation cycle.
A vulnerability is a weakness or flaw in a system, application, network, or process that could be exploited by an attacker to gain unauthorised access, disrupt operations, or cause harm.Vulnerabilities can come from many sources, such as:
- Software bugs (coding mistakes or logic flaws)
- Misconfigurations (e.g., insecure default settings, open ports)
- Missing patches (outdated software with known issues)
- Weak credentials (e.g., easy-to-guess passwords)
- Design flaws (security wasn’t considered during development)
On its own, a vulnerability doesn’t cause damage, but if a threat actor discovers and exploits it, it can lead to data breaches, privilege escalation, system compromise, or service disruption.
A threat is anything that has the potential to cause harm to an organisation’s information, systems, or operations. It represents a possible danger that could exploit a vulnerability to compromise confidentiality, integrity, or availability.Threats can be:
- External: Hackers, malware, phishing attacks, and natural disasters.
- Internal: Disgruntled employees, accidental data leaks, misconfigurations.
- Environmental/Technical: Power outages, system failures, software bugs.
In short, a threat is the “who or what” that could take advantage of a weakness (vulnerability) and cause damage.
Risk is the potential for loss or damage when a threat exploits a vulnerability. It measures the likelihood that a harmful event will occur and the impact it could have on an organization’s systems, data, or operations.In simpler terms:
Risk = Threat × Vulnerability × Impact
- Threat: Who or what could cause harm (e.g., hacker, malware).
- Vulnerability: Weakness that could be exploited (e.g., unpatched software).
- Impact: The damage or loss if the threat is realised (e.g., data breach, downtime).
In other words, a system with many vulnerabilities facing high-level threats has a higher risk than a well-protected system.
Vulnerability Management is the ongoing process of identifying, evaluating, prioritising, and addressing security weaknesses (vulnerabilities) in an organisation’s systems, applications, and networks to reduce the risk of exploitation.Key steps include:
- Discovery: Continuously scanning and identifying vulnerabilities in software, hardware, and configurations.
- Assessment & Prioritisation: Evaluating the severity of each vulnerability and determining which ones pose the greatest risk.
- Remediation: Applying patches, configuration changes, or other fixes to eliminate or reduce vulnerabilities.
- Verification: Testing to ensure that remediation was successful and vulnerabilities are resolved.
- Reporting & Monitoring: Documenting findings, tracking trends, and maintaining continuous monitoring to prevent new vulnerabilities.
Therefore, vulnerability management is a proactive security practice that helps organisations stay ahead of threats and minimise the chances of a successful cyberattack.
- Tenable (enterprise vulnerability management platform)
- Azure Virtual Machines (Nessus scan engine + scan targets)
- PowerShell & BASH (remediation scripts
- Vulnerability Management Policy Draft Creation
- Meeting: Policy Buy-In (Stakeholders)
- Policy Finalisation and Senior Leadership Sign-Off
- Meeting: Initial Scan Permission (Server Team)
- Initial Scan of Server Team Assets
- Vulnerability Assessment and Prioritisation
- Distributing Remediations to Remediation Teams
- Meeting: Post-Initial Discovery Scan (Server Team)
- CAB Meeting: Implementing Remediations
- Remediation Effort
- First Cycle Remediation Effort Summary
This phase involves creating the initial draft of the Vulnerability Management Policy, which serves as the foundation for discussions with stakeholders. The draft defines the scope, roles and responsibilities, and expected remediation timelines. It may be revised based on input from different teams to ensure the policy is realistic, workable, and ready for final approval by senior leadership.
During this phase, the server team is briefed on the draft Vulnerability Management Policy, and their ability to meet the proposed remediation timelines is evaluated. The discussion offers several advantages, such as clarifying expectations early and ensuring the policy aligns with real operational capacity. However, it also highlights challenges, for example, limited staffing or maintenance windows that make rapid remediation difficult. Based on the team’s feedback, adjustments are made, such as extending the critical remediation deadline from 48 hours to one week, helping ensure the policy is both effective and achievable.
After incorporating the server team’s feedback and adjusting unrealistic remediation timelines, the revised policy is presented to senior management for final approval. Once signed off, it becomes the official framework guiding the vulnerability management program. This approval not only ensures organisational alignment and compliance but also provides a formal reference point when resolving any future disagreements or pushback.
In this phase, the team meets with the server team to coordinate the start of scheduled credentialed scans. To address concerns about performance impact or unexpected disruption, both teams agree to begin with a single test server. This allows them to monitor CPU, memory, and service stability before expanding the scan to the full environment. Just-in-time Active Directory credentials are used to maintain secure, time-limited access. Potential issues, such as service slowdowns, permission failures, or scan interruptions, can be resolved by adjusting scan windows, tuning scanner settings, or refining access controls based on the results of the initial test run.
For the initial scan, a purposely vulnerable Windows Server is deployed to mirror the server team’s environment. Several weaknesses are introduced to create realistic testing conditions. An authenticated vulnerability scan is then performed, and the results are exported to serve as the baseline for the upcoming remediation work.After the initial vulnerability scan is conducted, an assessment is done as well, based on:
How severe each vulnerability is based on the CVSS score. This helps quickly determine what’s low, medium, or high risk. High-severity findings usually require immediate attention because they can be exploited more easily.
How important the affected system is. For example, an issue on a production server or domain controller is far more urgent than one on a standard user workstation. The more critical the system, the higher the priority.
Consideration of what could happen if the vulnerability were exploited — could it allow an attacker to gain access, disrupt a service, or cause data loss? Understanding the real-world impact helps determine how quickly the issue needs to be remediated.
In this scenario, the team decided the remediation should be carried out in the following order:
- Third-Party Software Removal (Wireshark)
- Windows OS Secure Configuration (Protocols & Ciphers)
- Windows OS Secure Configuration (Guest Account Group Membership)
- Windows OS Updates
- WinTrustVerify Fix
The Server team, having received the initial scan result and the email with the suggested remediation scripts, reviewed what was required. A meeting between the Server team and the Vulnerability Management team was organised. The process involved making changes to the server e.g. removal of outdated software. Therefore, the changes need to be submitted to the Change Advisory Board (CAB) for assessment and approval.
The Change Advisory Board (CAB) plays an important role in vulnerability management by reviewing and approving changes required to remediate vulnerabilities. Their main responsibilities include:
-
Evaluating Risk vs. Impact
CAB assesses how urgent the vulnerability is and balances it against the potential impact of applying the fix such as downtime, service interruptions, or compatibility issues. -
Approving Remediation Actions
Many vulnerability fixes require configuration changes, patch deployments, or system updates. CAB ensures these changes are safe, planned, and won’t negatively impact critical business operations. -
Ensuring Proper Testing
CAB verifies that updates or patches have been tested in a staging or QA environment before being rolled out to production. -
Scheduling the Change
CAB determines when the fix should be applied, for example, during maintenance windows to minimise disruption. -
Coordinating Across Teams
CAB ensures all affected teams (security, IT operations, application owners, network teams, etc.) are aware of upcoming changes. -
Tracking and Documenting Changes
All approved vulnerability-related changes are documented so that remediation efforts can be audited and traced later.
After obtaining CAB approval, both teams can move forward with the remediation efforts
The server team uses the suggested script to remove the outdated software and informs the vulnerability team once the process is complete. The vulnerability team then runs a scan to verify that the software has been removed.Results show that the outdated software has been removed
The server team remediates insecure protocols and ciphers. After the vulnerability team runs scans to verify that the vulnerability has been remediated. In some instances, a reboot of the server is required.
After reboot, some of the software is automatically updated by the Windows update. An example of this is Microsoft Edge. In the initial scan, Microsoft Edge was flagged. But in subsequent scans, it had been remediated.
The server team then runs a script to remediate the vulnerability of the Guest account belonging to a group.





