At the core of any successful cyber vulnerability management remediation process is an alignment of competent resources, cybersecurity best practices, and continuous assessment. In practice, these factors are not always satisfied for various reasons ranging from budgetary constraints, incomplete stakeholder buy-in, limited executive support, or a broader combination of factors. Recent news reports of supply chain attacks by nation-states have led many organizations to snap into action, adopting increasingly stringent security strategies by extension of growing precedent. In late April of 2021, NPR reported that the Biden administration was putting final touches on an executive order introducing new requirements for companies doing business with the government, a result of the SolarWinds cyberattack.
It is clear that without a functioning vulnerability management remediation process, an organization is in danger of becoming the next news headline. As considerations increasingly take aim at broader environmental risks introduced by vendors, it is equally important to continually refine your vulnerability management program and remediation process overall.
What is Vulnerability Management?
It is only reasonable to know the depth of a pool before diving in and the same is true for building a robust vulnerability management remediation process. It may first be prudent to level-set that achieving organizational security nirvana seems the end goal to focus efforts on.
The truth is that a good process of continuous improvement should be the focus and the rest becomes a natural result. A prerequisite is knowing what “good” looks like before defining and mapping contingencies for getting there over time. In ideal circumstances, the following items would be formalized or at minimum socialized among teams with a recurring basis for re-evaluation and refinement:
Cybersecurity governance outlines executive management’s strategic direction in setting scope, remediation cycle, term objectives, budget, and realistic expectations of performance as negotiated with stakeholders. Without a clear picture and guidance, key decisions are difficult to make and will lower the chances of program success drastically. Failure to account for progress may lead to a shift of priorities for personnel toward more straightforward efforts that have clear lines of sight for risk and reward. Inadequate budget might prevent the right resources from being hired, thus disenfranchising overleveraged existing resources who might leave the organization in response.
Cybersecurity strategy that defines roles, responsibilities, prioritizations of what is critical or required to protect for both business continuity and legal reasons such as regulatory compliance needs. This should set a profile of baseline standards of risk tolerance for the organization and ideally includes security framework decisions. Mature organizations are wise to also formalize an exception management subtask in tracking vulnerabilities that can’t be fixed immediately, detailing the reason why and identifying all associated stakeholders which typically include the application owner and line leader. These items should be reported up through management in-band of the cadence that progress for patch management is reported. Without having prioritization of criticality, “low hanging fruit” remediations will often take precedence in the exploitation of poorly designed Service Level Agreements (SLAs) or Key Performance Indicators (KPIs), seemingly showing progress but not impacting the critical core items.
Cybersecurity policies that establish authority, provenance, and onus of accountability in the simplest of terms. Everyone is a stakeholder when it comes to security, and without officially recognizing constituency levels, participation or cooperation can be limited or considered optional. The formalization of responsibility in policy acceptance shifts the mentality of tertiary constituents like an end-user who may not otherwise feel compelled or responsible in supporting the program objectives.
Program solutions such as vulnerability management scanners to enumerate vulnerabilities of configuration and patching levels. It is important to ensure proper configuration and tone of messaging in the remediation process, as the quality of findings can differ due to poor or insufficient configuration enacted in the solution, or errors in the product content is released. Traditional scanning has been impacted in recent history with distributed workforces further increasing the reliance on SaaS-based endpoint resident solutions for distributed endpoints. Additionally, cloud-based security posture management tools are also being increasingly adopted in digital transformations to wrangle risk born of configuration complexities of these new architectures of which most security products companies treat as separate products now. The need for these solutions would be identified in the exercise of security strategy dialog and stakeholder consensus. An endpoint management solution for orchestrating remediation of issues discovered by scanning activity is also ideal in the process as manual effort does not scale. A ticketing system supporting CMDB type information for tracking, measuring, and reporting out both performance and exceptions is also important. Having a CMDB context helps in prioritizing risk threat contexts when determining what to prioritize more intelligently for maximum impact.
The Vulnerability Management Remediation Process
You will find that several different perspectives exist when representing the vulnerability management cycle ranging that of vendors, analyst firms, or security community consortiums. While there exists a tremendous diversity of opinion and subtle nuance in the difference between them all, there are key elements of which they all share in practice that includes:
Assess Cyber Vulnerabilities
Scanning for vulnerabilities is the tip of the sword for the vulnerability management remediation process itself. There are many different types of assets that a scanner may support from servers, workstations, and a whole host of other devices such as network, IoT, and more. The quality and quantity of vulnerability findings are also subject to whether credential-based scanning is configured as the scanner can log in to go deeper as opposed to only what can be determined externally, especially if not agent-based.
You can’t fix what you don’t have awareness of, and vulnerability scanning is required to discover what is out there to get a full view of the threat surface to be managed. It is typical to define scan windows for different logical sites or network segments based on risks within. Assessing vulnerabilities using a scanner is not without its own risks. It is important to have some level of understanding around risks that may be specific to your industry. A poorly configured vulnerability scanner can create network congestion, overload state tables on firewalls, and create denial of service type conditions that disrupt business, occasionally even taking a device offline. For example, HVAC systems can be impacted causing office environmental issues. In organizations with industrial SCADA type equipment, scanning can even impact manufacturing and cause loss potential for critical business processes. In healthcare, an errant scan could potentially cause a critical medical device to fail, creating a life-threatening situation. Risk management for these circumstances may require vendor involvement and the risks will need to be addressed in the security strategy process with appropriate stakeholder involvement and input.
Prioritize Vulnerability Findings By Impact
Depending on circumstances such as existing security controls, a vulnerability may be significant on paper, but in practice may not be mitigated due to configuration or existing enforced policy. Vulnerabilities can vary but most typical are the remediation of patch level and configuration based findings. Context of asset or functional value to business continuity helps to localize priority in maximizing risk addressed as a process and program-level performance measurement. The security strategy of the organization provides the needed clarity in most cases and guidance on further action scope. Exceptions may be made depending on risk appetite as documented or agreed to by vulnerability management remediation process stakeholders.
Vulnerability Remediation Action On Findings
After exercise of prioritization, the next step may outwardly seem the easiest but is often the hardest. As they say, knowing is only half the battle. If the asset in need of remediation is constrained by politics or included in business critical functions, it can be difficult to get participation to remediate out of fear of loss and impact. In addition, distributed teams can unintentionally inundate remediators with hundreds of thousands of vulnerabilities. This is where appropriate prioritization, incentive alignment, and function over faction set precedence for streamlined results vs what would often be called “ocean boiling.” Having clearly defined roles in security strategy provides a structured chain-of-command for accountability and appeal, especially when addressing contentious remediation items by removing the ambiguity of responsibilities and next-step requirements.
Re-assess & Validate Progress
Throughout any action, there is the possibility of unintended consequences, and any remedy may itself exacerbate that problem or even create new ones. The need to re-assess and validate progress becomes crucial to ensuring consistency and continuity across people, processes, and technology as a complete system of interrelated, critical, fallible components. It’s not entirely uncommon to find a one-off device or even a group of similar devices reverting configuration due to automation, errant policy enforcement, or a user acting inconsistent with policy directives while having administrator access. When presenting vulnerability findings, it is important to constantly message with all stakeholders that findings are not always 100% accurate. This can be annoying for some stakeholders and it must be accepted as fact for the vulnerability management remediation process to be truly successful. This is because trust is inherently at the core of action on the part of any invested stakeholders and without acceptance of circumstance, cherry picked findings can become fodder for infighting and politics vs meaningful progress and security posture improvement.
Vulnerability Remediation Reporting Metrics / KPIs
When it comes to reporting progress, there are many factors of consideration that come to mind. Different solutions involved in the progress offer different optics and curation of environmental estate. Depending on organizational maturity, these may not fit the needs of stakeholders with more nuanced and custom demands. For customers developing their programs, these are often adequate.
It’s vitally important to ensure that all constituents understand the relationship between scanning, remediation, validating, and reporting. Reporting out more often than scanning and remediating creates an optic of inaction and lack of progress due to stale state data. The impact must be measured in cycles of what the solutions available are able and configured to produce, timely in nature. It is also common for organizations to rally toward tracking metrics that appear to represent quantity vs the quality of remediations in proportion to the impact of total risk addressed. Process specific metrics that encompass the fluidity of the complete process from discovery to remediation are best practices when tracking performance and should include:
- Critical Open Vulnerabilities
- Mean Detection Time
- Mean Resolution Time
- Coverage & Coverage Deltas
- Average Vulnerability Exposure Window
- Risk By Business Unit
- Risky By Type
- Exceptions
Moving beyond in-product reporting to business level insights requires a capable business intelligence (BI) solution. For example, an organization might want to perform device reconciliation of known estate vs expected, from a custom CMDB or internal database, on a monthly or quarterly basis. Using a BI solution would provide the ability to compare these respectively and identify coverage risks. Alternatively, there may be a desire to incorporate other forms of reporting insights from teams into a single, corporate level for executive consumption.
Vulnerability management, and the vulnerability remediation process itself, are team sports. The success of the program requires stakeholder buy-in, mutual respect, understanding, and the support of everyone in order to be successful. There are many great considerations in building a successful process across an organization, and industry specific nuance does apply as we’ve discussed over the course of this blog.
Automox for Easy IT Operations
Automox is the cloud-native IT operations platform for modern organizations. It makes it easy to keep every endpoint automatically configured, patched, and secured – anywhere in the world. With the push of a button, IT admins can fix critical vulnerabilities faster, slash cost and complexity, and win back hours in their day.
Grab your free trial of Automox and join thousands of companies transforming IT operations into a strategic business driver.
