Vulnerability Assessment (VA)

Go back to Tutorial

Vulnerability assessment also known as vulnerability analysis is the process of identifying, quantifying, and prioritizing (or ranking) the vulnerabilities in a system. Examples of systems for which vulnerability assessments are performed include, but are not limited to, information technology systems, energy supply systems, water supply systems, transportation systems, and communication systems. Such assessments may be conducted on behalf of a range of different organizations, from small businesses up to large regional infrastructures. Vulnerability from the perspective of disaster management means assessing the threats from potential hazards to the population and to infrastructure. It may be conducted in the political, social, economic or environmental fields.

It has many things in common with risk assessment. Assessments are typically performed according to the following steps

• Cataloging assets and capabilities (resources) in a system.
• Assigning quantifiable value (or at least rank order) and importance to those resources
• Identifying the vulnerabilities or potential threats to each resource
• Mitigating or eliminating the most serious vulnerabilities for the most valuable resources

It can forecast the effectiveness of proposed countermeasures and evaluate their actual effectiveness after they are put into use.

It consists of several steps:

• Defining and classifying network or system resources
• Assigning relative levels of importance to the resources
• Identifying potential threats to each resource
• Developing a strategy to deal with the most serious potential problems first
• Defining and implementing ways to minimize the consequences if an attack occurs.

If security holes are found, a vulnerability disclosure may be required. The person or organization that discovers the vulnerability, or a responsible industry body such as the Computer Emergency Readiness Team (CERT), may make the disclosure. If the vulnerability is not classified as a high level threat, the vendor may be given a certain amount of time to fix the problem before the vulnerability is disclosed publicly.

The third stage is sometimes performed by a white hat using ethical hacking techniques. Using this method to assess vulnerabilities, security experts deliberately probe a network or system to discover its weaknesses. This process provides guidelines for the development of countermeasures to prevent a genuine attack.

Every effective security practice is built on a strong foundation of policies and procedures, and the vulnerability assessment process should be no exception. Before beginning to conduct any VA it is important to ensure that the underlying policies relevant to the organization are in place to facilitate the process. These documents will be the principles, outlining the actions to be taken when planning and performing all aspects of the VA each and every time it is conducted.

• Conduct Assessment – This phase consists of two main objectives, the planning and performing of the vulnerability assessment. The planning component will include gathering all relevant information, defining the scope of activities, defining roles and responsibilities, and making others aware through the change management process. The method for performing the VA will include interviewing system administrators, reviewing appropriate policies and procedure relating to the systems being assessed and of course the security scanning.
• Identify Exposures – This phase can include an assortment of tasks. For example, reviewing the resulting data from the assessment phase and tying it into the issue management process so that accountability for the issues are established and the exposures can be resolved. The data can also be stored and reviewed allowing for enterprise wide risk analysis and trending.
• Address Exposures – This phase tries to resolve the exposures identified in the previous phase. Before any steps are taken to fix the problem an investigation must be conducted to determine if the service that caused the exposure is in fact needed. If the service is needed then the system should be upgraded, or if no upgrade exists management must be informed of the potential risk that system presents. If the services is not needed then it could simply be disabled.

Identifying and Removing Vulnerabilities

Many software tools exist that can aid in the discovery (and sometimes removal) of vulnerabilities in a computer system. Though these tools can provide an auditor with a good overview of possible vulnerabilities present, they can not replace human judgment. Relying solely on scanners will yield false positives and a limited-scope view of the problems present in the system.

Vulnerabilities have been found in every major operating system including Windows, Mac OS, various forms of Unix and Linux, OpenVMS, and others. The only way to reduce the chance of a vulnerability being used against a system is through constant vigilance, including careful system maintenance (e.g. applying software patches), best practices in deployment (e.g. the use of firewalls and access controls) and auditing (both during development and throughout the deployment lifecycle).

Vulnerability Naming

Administrators and security experts are usually flooded with attack and vulnerability information, generated by the different security products like Firewalls, Intrusion Detection systems and Vulnerability Assessment tools. To react in a timely manner it is essential that these tools are naming events in a common way. The today’s de facto standards CVE (Common Vulnerability Exposures) and the SecurityFocus Bugtraq database will be presented. CVE and Bugtraq have some limitations, they do not describe the vulnerability in enough detail and a common format.

These limitations inspired two new proposals: AVDL (Application Vulnerability Description Language) and VulnXML, both enable direct import of a describing XML document into a scanning tool and the tool will generate and launch the vulnerability scan.

A vulnerability naming scheme is used for creating and maintaining a standardized dictionary of common names for a set of vulnerabilities, such as software flaws in an operating system or security configuration issues in an application. The naming scheme ensures that each vulnerability entered into the dictionary has a unique name, and this standardized vulnerability naming scheme supports interoperability.

Each organization typically has many tools for system security management that reference

vulnerabilities; e.g., vulnerability and patch management software, vulnerability assessment tools, antivirus software, and intrusion detection systems. If these tools do not use standardized names, it may not be clear that multiple tools are referencing the same vulnerability in their reports, and extra time and resources may be required to resolve these discrepancies and correlate the information. This lack of interoperability can also cause delays and inconsistencies in security assessment, reporting, decision-making, and vulnerability remediation, as well as hampering collaboration both within an organization and between organizations. Use of standardized names also helps minimize confusion regarding which problem is being addressed, i.e., which vulnerability is being mitigated by a new patch. All of this helps organizations to quickly identify the remediation information they need when a new problem arises.

NIST SP 800-51 Rev. 1, provides the guide to using vulnerability naming schemes for the US Government. SP 800-51 provides information and recommendations related to two commonly used vulnerability naming schemes: Common Vulnerabilities and Exposures (CVE), and Common Configuration Enumerations (CCE). The Common Platform Enumeration (CPE) version 2.2 specification provides standardized, consistent names for referencing operating systems, hardware, and applications. CPE names are often used in conjunction with CVE and CCE names.

The official CPE dictionary is available at http://nvd.nist.gov/cpe.cfm. The document also presents recommendations for software and service vendors relative to the manner in which they should use vulnerability names and naming schemes in their product and service offerings. Both CVE and CCE are described in detail in the following sections.

Tools

When conducting a vulnerability assessment the tool set being used should be very similar to that of the identified adversary. This will ensure that the systems are secure from attacks that are currently being employed out in the wild.

• Nmap – It is a utility for network discovery and/or security auditing. It can be used to scan large networks or single hosts quickly and accurately, determining which hosts are available, what services each host is running and the operating system that is being used.
• Nessus – It is a remote security scanner. This software can audit a given network and determine if there are any weaknesses present that may allow attackers to penetrate the defences. It launches predefined exploits, and reports on the degree of success each exploit had.
• Whisker – It is a CGI web scanner. It scans for known vulnerabilities found in web servers, giving the URL that triggered the event as well, it can determine the type of web server being run. It is easy to update and has many useful features.
• Enum – It is a console-based Win32 information enumeration utility. Using
• null sessions, enum can retrieve userlists, machine lists, sharelists, namelists, group and member lists, password and LSA policy information. enum is also capable of a rudimentary brute force dictionary attack on individual accounts.
• Firewalk – It is a technique that employs traceroute-like techniques to analyze IP packet responses to determine gateway ACL filters and map networks. It can also be used to determine the filter rules in place on a packet forwarding device.

Go back to Tutorial