How do you prioritize vulnerabilities based on risk and impact?

Speaking of vulnerability information and patching cycle alignment with business objectives, In reality, in many cases, Engineer who is Patching the vulnerability is a short term contractor and have no clue about business objective of the company.. for him it’s a pure technical job. He / she doesn’t attend any of the company all hands meeting because only FTEs are invited to all hands. Unless clear priority is given to the patch management team as to what systems are critical for business and which vulnerability to patch first, they will follow “first in->first out rule”.. this gap still exists in most of the organisations.

No, the first step in assessing vulnerabilities is to understand the context of your own estate, and your organisation's level of risk tolerance. Context is crucial in determining impact and likelihood. CVSS and CVEs are great tools to use in assessing this, but they're not enough on their own - they don't provide the business context.

Assessing the severity of vulnerabilities is crucial in prioritizing them based on the potential damage they could inflict if exploited. Factors considered include ease of exploitation, level of access gained, potential data loss, patch availability, and alignment with business goals and compliance. Utilize frameworks like CVSS or CWE to assign numerical scores or qualitative ratings to vulnerabilities.

It's important to assess the severity as it pertains to your environment. A CVSS score could be 10, an extremely high severity. The flaw could allow remote attackers into administrative parts of your network, with ease. But if you have this flaw on one sandboxed device with no access to sensitive data then this severity is much lower for your environment. A crucial part of this step is determining the mitigating controls you already have in place. Then adjust the severity score accordingly.

By context. The same vulnerability can cause different consequences if exploited on different assets. Risk and impact are good perspectives to establish the context. This is possible through risk analysis and through BIA. Knowing the risks and impacts associated with each asset, it is possible to prioritize the correction of vulnerabilities. An interesting model allows the identification of dependencies between assets, considering data, networks, communication, systems, equipment, people, physical structures, service providers and all components that are part of the business. This information helps you understand the most relevant assets to your business and the single points of failure.

A simple likelihood table can be as follows: level | Description | Example 1 | Low | 1 event in 3 years or more 2 | Medium | 1 event between 6 months and 3 years 3 | High | 1 event 6 months or less This should be adjusted to each business's situation.

When prioritizing vulnerabilities, the next step is to evaluate their likelihood of exploitation in the near term. Likelihood assessment considers factors like system exposure, active threats, attacker awareness, attack complexity, and adversary motivation and capability. Historical data, threat intelligence, and risk analysis methods can help estimate the probability or frequency of exploitation for each vulnerability.

This is where guidance from your SOC, red team, pentest firm, or other qualified InfoSec professionals familiar with attack techniques can be valuable. If you were attacking this system, would this be a useful vulnerability? This is information that a simple vulnerability reporting tool cannot provide.

When determining the likelihood indicator for a security control consider - How easy is it for a threat agent to determine the existence of a vulnerability - How easy is it for a threat agent to determine that a control to protect against the vulnerability is missing - How easy is it for a threat agent to exploit a vulnerability in the service when that control is missing - To what degree do missing security controls make it easier to discover vulnerabilities in the service - Are there current ongoing attacks on other services which are protected by this security control - How often has the service suffered an incident due to this or this type of missing control in the past?

In some quick points, here are some ways that you can evaluate the likelihood of a vulnerability being exploited: - Check for known exploits. - Assess all access controls and user privileges. - Consider the system's attack surface and exposure. - Review the effectiveness of mitigation’s put in place. - Understand the specific details of the vulnerability. (You can use the NVD.) - Analyse historical data for patterns in exploitation attempts.

When calculating risk, it is very important to consider your network architecture and configuration. The CVSS score and likelihood may be very different from the published score based on how your network is segmented. For example, something with public exposure should not have the same risk as a vulnerability behind a segmented and firewalled network that uses MFA.

In the process of prioritizing vulnerabilities, the third step involves calculating their risk, which quantifies the anticipated loss or impact resulting from exploitation. Risk is typically determined by multiplying the severity and likelihood of a vulnerability or using a matrix or formula that integrates both aspects. This enables comparison and ranking of vulnerabilities based on their significance and urgency for the organization. Assigning a risk score or level helps categorize vulnerabilities into high, medium, or low priority for mitigation efforts.

Severity: The severity of a vulnerability is a measure of the potential impact of exploitation. It is usually rated on a scale of low, medium, or high. Likelihood: The likelihood of a vulnerability being exploited is a measure of how likely it is that an attacker will be able to exploit the vulnerability. Risk: The risk of a vulnerability is calculated by multiplying the severity and the likelihood. A vulnerability with a severity of medium and a likelihood of high would have a risk of medium * high = high. Impact helps the business understand and prioritise risk, agree on your impact level, and consider Financial, reputational and customer service impact. A risk analysis matrix showing impact vs likelihood helps you to prioritise.

A lot of organisations categorise risks based on financial impact Relying solely on financial impact for risk categorization is inadequate. Small vulnerabilities may escalate into major security breaches. A holistic approach, considering potential broader impacts on data integrity and system availability, is crucial for accurate risk assessment. In my view, utilizing risk matrices is among the most effective approaches to calculate and prioritize risks. Examples of this are: - Binary risk assessment - Bowtie risk assessments

Calculating risk is reliant on data and tailored to specific use cases. In the context of cyber resilience and risk quantification, it often centers around the likelihood of a data breach. The base formula for quantifying risk is: {Data Breach Risk}={Breach Likelihood %}x{Breach Impact $} In today's complex environments, even assets that seem less critical can be attack vectors, so they must be included in the calculation. Therefore, it’s crucial to map the entire attack surface and automation technology is invaluable to help. Security ratings are also an important metric that offers a real-time snapshot of security postures and the impact of emerging risks, showing how a given action might affect the potential impact of a threat.

In the prioritization of vulnerabilities, the fourth step involves considering the context, encompassing factors that influence your vulnerability management process and decisions. This includes organizational culture, resources, constraints, policies, goals, and stakeholders. Context enables adjustment of prioritization criteria and methods to align with your unique circumstances and requirements. It allows for validation, modification, or supplementation of risk-based prioritization with factors like business impact, cost-benefit analysis, or stakeholder input. Context is essential in tailoring vulnerability management strategies to effectively address specific needs and challenges within your organization.

Consideration of the context often happens at levels above and outside Information Security. InfoSec provides information, which the business then contextualizes with a matrix of other business considerations. Often, the business may choose to accept a certain risk if they deem its mitigation to be more costly than business benefits derived from mitigation, and/or there are more pressing priorities on the organization’s agenda.

Look at your vulnerabilities. Do they have a fix? do they have a public exploit? Is it detected in a package, default package, library, OS, installed program, or file path in a specific resource? What are the trend assessments by region? Read your business security policies; what do they state? What's the compliance baseline?

Context is easy once you have accurate vulnerability information prioritised by automatic system based on asset criticality, exploit ability, exposure of asset to the external attack surface, asset role etc..

É preciso entender o negócio a ser protegido e, baseado na convergência entre risco “versus” impacto, saber priorizar cada vulnerabilidade, já que não podemos estabelecer planos de ação para todas simultaneamente. Um negócio de transporte, por exemplo, tem vulnerabilidades diferentes de um e-commerce. O que decide a vulnerabilidade mais importante? A continuidade dos negócios. Uma vulnerabilidade no TMS de uma empresa de logística é muito crítica. Já para uma empresa de e-commerce, um ataque DDoS pode inviabilizar o negócio por dias. Assim, a experiência diz que é preciso ir além do risco “versus” impacto e analisar como essa vulnerabilidade atinge a sobrevivência do negócio. Esse, ao meu ver, é o ponto principal de priorização.

The final step in prioritizing vulnerabilities is to implement remediation measures, which involve taking actions to address or mitigate the identified vulnerabilities. Remediation strategies may encompass patching, upgrading, configuring, isolating, or removing the vulnerable system, application, or process. Additionally, compensating controls like firewalls, antivirus software, encryption, or backup solutions can help reduce vulnerability impact. Leveraging prioritization results allows for resource allocation and time management to address critical vulnerabilities promptly. Monitoring and reporting on remediation progress and effectiveness is essential to ensure continuous improvement in vulnerability management practices.

The only risk management strategy that does not have a valid application here: risk ignorance. Rather than thoughtfully considering a risk and it’s implications and either mitigating it or accepting it, one simply chooses to ignore it. Like most bad things that are ignored, they almost never “go away”.

In large organizations, it's common to find hundreds of critical vulnerabilities that remain unresolved due to resource constraints. Making business owners accountable for the security of IT systems involved in their processes is crucial. This approach ensures that remediation becomes a business priority rather than an IT-only concern, aligning security efforts with business objectives. Without this responsibility, vulnerabilities may remain unaddressed until a security breach occurs, potentially leading to significant financial and reputational damage. Prioritizing and addressing vulnerabilities efficiently requires a collaborative effort between IT and business units, highlighting the importance of shared responsibility in cybersecurity.

To remediate the vulnerabilities always brings long discussions between IT and Security. The tip is to focus on most easy to be exploited. This funnel will help you to prioritize. But, even priority, even exploitable, even critical to the business, what to do when you are handling a heavy obsolete environment? Microsegmentation, network isolation and better log collection must be checked if can help. This dilemma is very common for OT environment.

The fifth step in prioritizing vulnerabilities is to implement the remediation plan. Remediation involves taking action to address or mitigate vulnerabilities. This can include patching, upgrading, configuring, isolating, or removing the vulnerable system, application, or process. Additionally, compensating controls such as firewalls, antivirus, encryption, or backup can be implemented to reduce exposure or impact. Using the results of your prioritization, allocate resources and time to remediate the most critical vulnerabilities first. Monitor and report on your progress and effectiveness to ensure that vulnerabilities are addressed in a timely and efficient manner.

The sixth and final step in prioritizing vulnerabilities is to regularly review and update your processes and outcomes. This practice ensures that your prioritization remains accurate, consistent, and aligned with evolving organizational objectives and environmental changes. By reviewing and updating, you can detect and address any gaps, issues, or challenges in your vulnerability management process and performance. Utilizing tools, metrics, audits, and feedback mechanisms helps in revisiting and refining your vulnerability assessment, evaluation, calculation, consideration, and implementation strategies. This iterative approach fosters continuous improvement and enhances the effectiveness of your vulnerability management practices.

There are a few things to consider here when reviewing, This is not a one-and-done process! : The latest security threats and risks. The security landscape is constantly changing, so it is important to review your vulnerability prioritization process to ensure that it is still aligned with the latest threats and risks. The changing needs of your organization. As your organization grows and changes, so too will your security and compliance needs. The effectiveness of your current process. It is essential to review the effectiveness of your current vulnerability prioritization process to see if it is actually achieving the desired results. If not, you may need to make some changes.

Keep It Simple You don’t need a complex system in order to improve or support your organization’s security environment. However, your organization’s leaders need tools that show them where to spend time and resources in order to reduce potential risks to the company. That’s how risk assessments can shed light on the key factors in this decision-making process.

What is often overlooked is that patches themselves can be flawed. Especially in the Microsoft ecosystem, it is crucial to go beyond vulnerability management and read Microsoft KB articles to understand and evaluate potential issues. Known issues frequently arise and are not uncommon. Sometimes, these issues may go unnoticed by vulnerability management. Assuming that everything is patched can lead to an inability to accurately assess the associated risks.

For large enterprises, Have formal Vulnerability management as a program. Define multiple projects to integrate vulnerability management in your security operations centre. Co relate Vulnerability with incidents live and asset context as incidents happen.

Exposure of Vulnerability(what %of organisational devices are exposed), Vulnerable Device type, device business criticality and device connectivity(underline connectivity/location of device) based on your organisation’s network infrastructure, you need to assess the impact of vulnerability along with the criticality of vulnerability not only based on CVSS score, you must consider the exploitation probability. The overall collective results of all factors would drive the final criticality of vulnerability. Now you need to consider your risk appetite and closely work with Risk Management and Incident Management team. You can build a tailored model based on the above mentioned attributes to assess any vulnerability’s impact and next actions.

Many organizations have hidden risks throughout their extended IT and security infrastructure. Whether the risk is introduced by organic cloud growth, IoT devices adoption, or through mergers and acquisitions, the hidden risk lies dormant. IT and security teams do not always have an up-to-date picture of the extended ecosystem they need to defend. Legacy tools often have static lists of the ‘known’ asset inventory but lack the capabilities to comb the internet for ‘unknown’ assets that belong to the organization. To close visibility gaps and uncover hidden risk, establishing and maintaining a comprehensive attack surface management program is critical. Benefits include removing sprawl, reducing environmental drift and fast remediation.

A minha experiência diz que ficamos, muitas vezes, buscando soluções tecnológicas complexas quando devemos iniciar pelo mais simples: uma boa Política de Segurança da Informação (PSI), com especial atenção ao gerenciamento de riscos, utilizando-se, por exemplo, a ISO 27005 ou, até mesmo, a ISO 31000, bastante simples e eficientes. Adicione-se um treinamento que tenha início na Alta Direção e desague no nível operacional, e obtêm-se, em um curto espaço de tempo, uma redução robusta na superfície de ataque. Quando me deparo com situações de baixa maturidade em SI, adoto sempre soluções “do simples para o complexo”. Tendem a ser mais palatáveis e duradouras para a organização, além de evitar “ruídos” desnecessários ao longo da implementação.