In this article, we will discuss vulnerability identification, discussing what it means and how best to conduct it. We’ll also look at how organizations take the initiative of publicizing identified security issues using different approaches. Finally, we’ll discuss one approach that can be taken in identifying vulnerabilities and the different levels of occurrence, impact and overall risk.
What is a vulnerability?
A vulnerability is a flaw that could lead to the compromise of the confidentiality, integrity or availability of an information system. Vulnerability identification involves the process of discovering vulnerabilities and documenting these into an inventory within the target environment.
Special care should be taken so as not to go out of scope of the allowed targets to identify vulnerabilities on. If care is not taken, there are consequences that can follow: for instance, disruption of service, breach of trust between yourself and the client or, worst of all, legal action against you by the client.
In order for vulnerabilities to be identified, they need to be accurately mapped. There are vulnerability lists that make this easy to do.
What are vulnerability lists?
A vulnerability list is a documented listing of common vulnerabilities. The documented vulnerabilities are usually assigned an identification number, a description and public references. These vulnerabilities have been found to occur commonly and often lead to the exploitation of systems on the internet.
There are various authentic sources of documented vulnerabilities, including the following:
Databases: These databases include various information on vulnerabilities. For instance, information might include security checklist references, security-related software flaws, misconfigurations, product names and impact metrics. The following are some examples:
NVD by NIST: This is a repository managed by the U.S. government
OWASP: OWASP manages a list of vulnerabilities in a project known as theOWASP Top 10. Here, vulnerabilities are classified based on their frequency of attack. The list is updated only as OWASP decides it is necessary, with several years often passing between updates
Vendor advisories: Software vendors may issue advisories on how to deal with security vulnerabilities by applying patches that fix these security issues. The following are common vendors that take this approach to make security issues known:
Microsoft: Microsoft Security Response Center manages a comprehensive library of security documents that discusses security issues affecting Microsoft products
SANS Internet Storm Center: This is a security bulletin that often discusses security-related topics, especially those that are currently trending
What are some tools that can be used for vulnerability identification?
Over the years, security researchers and vendors have sought to make the process of vulnerability identification as simple and quick as possible. This has been made possible by the development and contribution to projects such as the Kali Linux project, which involves the integration of multiple security tools into a security operating system. This Linux OS incorporates tools for various security tasks such as vulnerability identification.
The following are some of the vulnerability identification tools present within the Kali Linux operating system:
Nessus Vulnerability Scanner: This is one of the common vulnerability scanners available today, capable of identifying vulnerabilities both on web applications and multiple systems
OpenVAS Vulnerability Scanner: This is a network vulnerability scanner capable of identifying vulnerabilities present on devices within a network
Nikto Vulnerability Scanner: This is a web server vulnerability scanner capable of identifying vulnerabilities present on web servers
Nmap Vulnerability Scanner: This is perhaps the most well-known vulnerability scanner to hackers today. It is capable of identifying a trove of vulnerabilities across multiple targets
Wapiti Vulnerability Scanner: This is a web application vulnerability scanner, capable of identifying web application-related issues such as SQLi and XSS
These tools make it possible for security testers to identify a trove of information from a system, then cross-check this information for vulnerabilities. Information checked can vary from the operating system version to the patch level, software versions and so on. You can find a good overviewhere of a couple of tools we used to introduce vulnerability mapping with Kali Linux.
It is important to take note of the amount of resources that will be consumed before executing a scan using these tools. If, for instance, the target system will end up consuming a lot of resources, this should be considered in advance.
How is vulnerability identification achieved?
In order to properly identify and classify a vulnerability, a number of considerations need to be made. First of all, the scan runs; once complete, vulnerabilities are issued with industry standard identifiers such as CVE numbers, EDB-ID and vendor advisories. These identifiers, when combined with the vulnerability’s CVSS score, can be used to calculate a risk rating.
Penetration testers will usually consider the risk rating of a scan in order to understand the security posture of an environment. However, the results are usually generic and may vary, as shown below:
True positives: These confirms that a vulnerability has been identified
False positives: Even though a vulnerability is found, the issue is not a true vulnerability
True negatives: In this case, a vulnerability is not found since the signature is not matched
False negatives: In this case, the signature is not matched; however, a vulnerability exists
Since there is no universally-defined risk rating that is agreed upon, we recommend going by the NIST special publication 800-30 as a baseline for evaluation of risk ratings. NIST approaches the true risk of a vulnerability as a combination of the likelihood of occurrence and the potential impact. Let’s discuss this approach below:
Likelihood of occurrence: NIST approaches the likelihood of occurrence as a probability of a particular threat being able to exploit a vulnerability. Ratings here will vary from Low to Medium and High. The three levels are as follows:
High: This indicates that the attacker is highly skilled and motivated, with the measures put in place insufficient in preventing an attack
Medium: This indicates that the attacker is highly skilled and motivated, with the measures put in place somehow being capable of thwarting an attack
Low: This indicates that the attacker is less skilled and lacks enough motivation to execute a successful attack. Also that the measures in place are effective
Impact: In order to understand impact, we need to determine the amount of harm that can be done in case the vulnerability in question was to be exploited. The following is an analysis of the possible levels of impact:
High: In case an exploit is successful, it could lead to the damage of the organization’s reputation, financial losses or even worse, the loss of life
Medium: A successful exploit could lead to the damage of the organization’s reputation, financial losses and more, but with not quite as deadly stakes as the “high” listing above
Low: If an exploit is successful in this category, it could lead to a certain amount of financial losses or reputational losses, but with lower stakes
Overall risk: The overall risk rating is calculated by taking into account the likelihood of occurrence and the level of impact. There are also three levels, as shown below:
High: This requires that additional measures be put in place in order to safeguard against the vulnerability in question. This often is urgent and requires timely action
Medium: This also requires that additional measures be put in place in order to safeguard against the vulnerability in question. While often time-dependent, risks in this category are not necessarily as crucial as those above
Low: This requires that additional measures be put in place in order to safeguard against the vulnerability in question. However, the system may be left unchanged and yet still remain functional
Even though vulnerabilities may be identified and classified as shown above, it is possible and usually common for organizations to accept risk and give consent to allow the operation of systems with known vulnerabilities. This can be true for many reasons, including the lack of a budget to perform upgrades for systems that require expensive upgrades.
Why should vulnerability identification be conducted?
Without vulnerability identification, it would not be possible to determine what vulnerabilities exist within a network. Being paranoid that a vulnerability might exist within your network is very important.
In a story on TechSoup for Libraries, Claire Staffordshares her concern about security at Madelyn Helling Library, CA. She says, “The issue we have is that we have the public accessing the Internet on a network that needs to be secured due to the nature of some of the county businesses. We don’t know that we’ve had any security breaches, but the potential is there. So the manager of our county IS Department has requested that our public computers be moved off of the county network. So we are in the process of moving to a cable modem system. Both our wireless and our public computers will be operating directly through Comcast.”
In this article, we discussed vulnerability identification. We’ve looked at vulnerability identification lists, a few vulnerability assessment tools and even discussed the approach that NIST uses to identify and classify vulnerabilities and their impact. Vulnerability identification is an important security exercise that helps to secure your environment.