Vulnerability assessment

What is vulnerability assessment?

The term vulnerability assessment applies to all vulnerability analysis activities that result in evaluating the impact and importance of a security vulnerability in an IT system. Based on vulnerability assessment, businesses can prioritize mitigation and remediation. Vulnerability assessment is an integral step of vulnerability management and is either performed automatically by vulnerability scanning software or manually during penetration testing.

Vulnerability assessment is essential for improving security posture because most organizations find more cybersecurity vulnerabilities than they can resolve immediately. This means they need to prioritize issues to decide which vulnerabilities need to be addressed as soon as possible and which can wait.

As with vulnerability management, vulnerability assessment is not limited to specific types of vulnerabilities or classes of security issues. It can apply equally well to network security and web application security. For web application security assessments, the process usually includes not just vulnerabilities but also issues such as web server and host operating system misconfigurations. Sometimes, vulnerability assessment is considered a part of more general information technology risk assessment and the risk management ecosystem.

Types of vulnerability assessment methodologies

Vulnerability assessments can be based on several different metrics. Here are the most common assessment criteria, though organizations may use additional ones based on their specific needs:

• Vulnerability severity. This is a general indication of how much damage a malicious hacker can do if they exploit this vulnerability and attack the organization. Severity is based on a few different factors, including:
  • Direct impact – evaluates whether the security risk could directly (without escalation) lead to severe consequences such as sensitive data access or gaining system control during a cyber attack. For example, an SQL injection (SQLi) vulnerability would have a high direct impact because it can lead to a major data breach. In contrast, a cross-site request forgery (CSRF) vulnerability would have a low direct impact because it is aimed at a single user only, most browsers automatically protect against it, and it could cause direct harm only in very specific circumstances.
  • Ease of exploitation – evaluates how easy it is for a malicious hacker to take advantage of the vulnerability, how skilled the attacker must be, and how much time they would need to exploit the vulnerability from scratch. For some software vulnerabilities, it may be enough to send just one string to the server to gain unauthorized access to sensitive data, while for others, such as blind SQL injection, attackers have to send many requests to extract even small amounts of information.
  • Availability of exploits – evaluates whether exploits already exist that make it possible for even an unskilled attacker to take advantage of known vulnerabilities. For major vulnerabilities in popular software, such as log4shell, there are usually many publicly accessible exploits. On the other hand, if you have an XSS vulnerability in a custom application developed internally by your organization, the availability of ready exploits is near zero because it’s unlikely that malicious hackers would bother to create an exploit just for your custom system.
• These factors are combined into a single severity rating, which is usually on a three to five-level scale, for example, critical, high, medium, and low.
• Target importance. This is a general indication of how important the assessment target is to the organization. The target may be a system, application, or any other piece of hardware or software that may have vulnerabilities. As with severity, there may be several factors at play, for example:
  • Business impact – evaluates how essential the target is for everyday business operations. For example, if your core business is selling products online, then your online store would have a critical impact. On the other hand, a marketing campaign website built on WordPress and hosted on a subdomain or a separate campaign-specific domain would have a low impact.
  • Escalation potential – evaluates how easy it is for an attacker to escalate their attack to other targets once this target is compromised. For example, a low-impact website located on the same physical server as a high-impact application would have a high escalation potential, but if the same low-impact website is hosted in a separate cloud environment from the high-impact application, it will have a low escalation potential.
  • Ease of access – public-facing systems are obviously much more accessible to black-hat hackers than internal applications or B2B systems that are only provided to specific customers. Limited access systems can use complex authentication, enforce IP address limits on firewalls, or require a VPN to ensure that only authorized users can gain access. This makes it much harder to perform attacks from the outside because attackers would first need to get onto the internal network/VPN or obtain a specific IP from the same provider.
• Again, these factors are combined into a single target rating. The importance rating can be evaluated separately or combined with the severity rating to automatically prioritize specific vulnerability types for specific targets. Unlike vulnerability severities, importance ratings need to be assigned manually because it takes human expertise to assess the impact of a specific target on a business and its internal systems.

Vulnerability assessment tools

Vulnerability assessment is rarely a standalone feature and is typically included in the functionality of security tools. Here are the three most common cases:

• Vulnerability assessment with vulnerability scanning. In this case, vulnerability assessment functionality is built into the vulnerability scanner and scan results immediately include information about vulnerability severity. Since there is no vulnerability management, there is no way to prioritize targets. This is the most common approach for web application security, being used in simple DAST and most SAST tools.
• Vulnerability assessment with vulnerability management. In this case, the vulnerability management system allows you to import vulnerability information from external sources (without scanning for vulnerabilities). The data is immediately assessed for impact, accounting both for vulnerability severity and target importance (usually assigned manually to targets). This is the most common case for network scanning because network vulnerabilities are all known vulnerabilities with clear identifiers, such as CVE codes. This makes it easy for the vulnerability management system to assign a severity to a specific CVE code based on external databases.
• Vulnerability assessment with both vulnerability scanning and vulnerability management. This type of integration is common for advanced web application security tools such as Invicti and Acunetix by Invicti, where the tool discovers vulnerabilities, automatically assesses them, and creates internal or external tickets/issues with priorities based on the assessment.

The vulnerability assessment process

The level of automation and integration of a vulnerability assessment process greatly depends on the software solutions selected by the business for security testing. Here are three examples of such processes.

• In a manual vulnerability assessment process, the security team performs manual penetration testing or runs vulnerability scanning using simple open-source tools with no vulnerability assessment functionality. The targets are usually live systems or staging servers. The result is a list of security weaknesses that security engineers then triage manually according to their specialist knowledge. This is a common process for third-party security audits, and it results in an assessment report.
• In a semi-automatic vulnerability assessment process, the security team runs an automated tool with vulnerability assessment functionality and then manually imports the data into a separate vulnerability management solution. Based on all the imported information and automatic assessment data from the scanning tool, the team then decides which vulnerabilities should be prioritized for mitigation and remediation. One variation on this process is to run a scan without vulnerability assessment and then import scan data into a vulnerability management platform with vulnerability assessment capabilities.
• In a fully automatic vulnerability assessment process, the security team is not involved in vulnerability assessment at all except for special circumstances. Vulnerability assessment is built into an automatic solution that can run scans during the software development lifecycle (SDLC) after every source code commit, in staging, and even in production (on a scheduled basis). The results are automatically assessed and the vulnerability management solution creates tickets on the basis of weights assigned to vulnerability severity and target importance. Such a setup is possible with vulnerability management tools that have a built-in vulnerability scanner and a high degree of automation and integration, for example, Invicti and Acunetix by Invicti. Note that this level of automation is only practical for solutions that inherently have very low false positive rates.