The following sections present the design of the proposed approach. The first section outlines the Update Checker, a solution for checking for updates in virtual machines. The second section describes the Online Penetration Suite, an approach for online-scanning virtual machines for known software vulnerabilities.
Update checker
Since the primary goal of the Update Checker is detecting obsolete software in (dormant) virtual machines, the term virtual machine is used throughout this article. Nevertheless, the solution is applicable to physical machines as well.
The concept of the Update Checker is to build a central database that contains all the information required for the task of checking for updates. This includes the list of installed packages, including the exact version of the installed package as well as the list of repositories that are used for each virtual machine. This information has to be imported into the central database when the virtual machine is first registered, and updated after each change of the virtual machine, i.e., after the installation of new software or the update of already installed software.
Since the Update Checker is not targeted at a single Linux distribution (compared to, e.g., Landscape for Ubuntu [8]), at least the two prevalent software management solutions are supported: apt/dpkg, used for example in Debian and Ubuntu, as well as yum/rpm, used for example in Red Hat and Fedora as well as SuSE. Both solutions use a specific package database format as well as a specific repository format. While apt/dpkg uses the same plaintext file format both as package database and as repository database, yum/rpm uses a Berkeley database as package database and an XML file as repository database. Nevertheless, this has no influence on the structure of the database used to store the required information, since both systems have the concept of distinct package names and a consistent versioning scheme in common.
The design of the solution is shown in Figure 1. There are specific importers for the package databases and for the repository databases of the different software management solutions. This makes the Update Checker easily adaptable to other software management solutions. Information about the installed packages of a virtual machine is stored in the Package DB. Metadata about the VM, i.e., the time stamp of the import, the repositories used, etc., is stored in the Metadata DB. Information about the available packages on the different repositories is stored in the Repository Cache. When invoked, the Update Checker takes the information from these databases and the Repository Cache and matches installed and available packages to detect obsolete software and stores the results in the Result Cache.
When a query for the state of one or more virtual machines is issued, the Update Checker first checks to see if the result of that query is already available in the Result Cache and returns the cached result if it is not obsolete. Cached results are considered obsolete after a configurable amount of time, depending on factors such as the frequency of updates or the need for security. Otherwise, it checks if the package lists of all repositories assigned to the virtual machine are available in the Repository Cache and not obsolete, i.e., the configured validity period has not yet expired. If this is not the case, the package lists are downloaded from the software vendor’s repository, parsed and stored in the Repository Cache for future use. When using the Repository Cache instead of the real repositories, there is the chance that the Update Checker fails to identify an outdated package. Nevertheless, the Repository Cache is very useful for checking many virtual machines and by using a small validity period, the risk can be minimized. Finally, the actual check of the virtual machine is started, comparing the version of each installed package with the version available at the repository. Information about outdated packages is then stored in the Result Cache, so that subsequent queries regarding the same virtual machine can be answered faster.
To help the user to judge whether the identified outdated software poses a risk to the virtual machine, the Update Checker infers information about the priority of an update. Unfortunately, there is no common way to do this for multiple distributions. As a first approach, the source repository of the updated packages is evaluated, since distributions like Debian or Ubuntu use special repositories for security updates. The source of an update can therefore be used as a hint of its significance.
The Update Checker allows to query for the number of available updates for a single or multiple virtual machines as well as for details about the outdated packages and available updates for a single virtual machine. The former query allows a good estimation of the state of the virtual machine, where zero means the virtual machine is up to date, while a number greater than zero means that there are updates available. If significance information is available, individual numbers for each level of significance as well as the sum of the numbers are returned. This can either be used in situations where an overview over a number of virtual machines is required, e.g. , a list of virtual machines in a management tool like the ICS, or as a status check for a specific virtual machine, e.g., before it is started by the XGE.
Since the availability of updates itself allows no judgment about the threat resulting from the outdated packages, even when significance information is available, the latter query allows a detailed examination of the status of a virtual machine, by giving a list of outdated packages. This allows the user of the virtual machine to do a threat analysis based on the outdated packages and decide whether immediate action is required or not. The described functionality is used as an example of the integration of the Update Checker with other components. The complete solution is shown in Figure 2.
Two different interfaces are provided by the Update Checker: a command line interface (CLI) and an API for use by other software. The former can be used, when an administrator manually wants to execute an update check or register a virtual machine. The latter is provided for other tools like the ICS or XGE, allowing them to easily access the status information. This interface is provided using the language-independent protocol XML-RPC [9], to be available to tools written in any language.
The Update Checker can also be configured to run the checks at regular intervals, e.g., daily or weekly. This speeds up queries by other tools, because the information is already available. Users can be informed about obsolete software in their virtual machines via email. Additionally, administrators can also be informed about all virtual machines using obsolete software, to get an overview of the security of all virtual machines running on their infrastructure.
To ease the registration of virtual machines, the remote importer is provided (see Figure 1). It uses software management solution specific Data Collectors to gather the information required for the Update Checker, sends it to the machine the Update Checker is running on and triggers the registration process.
It might seem cumbersome to manually re-register virtual machines after every change, but with the remote importer it is merely a single command. Furthermore, it can be easily automated when software for management and maintenance of virtual machines is used.
Online penetration suite
This section presents the Online Penetration Suite (OPS) to scan an arbitrary number of virtual machines for security vulnerabilities utilizing multiple security scanners. The OPS combines and interprets the different results and generates a machine-readable and a human-readable report. Furthermore, the OPS is able to manage (start, stop, migrate, etc.) virtual machines if necessary. This allows automatic testing of virtual machines in a virtualized infrastructure to detect known security vulnerabilities. Once the vulnerabilities are known, the administrators and users can fix them to protect their systems with respect to unwanted attacks.
Architecture
The OPS is divided into two parts: the logic part, containing the flow control and the report generator, and the backend part, operating the registered vulnerability scanners and the virtual machines. The architecture of the OPS is shown in Figure 3, containing two adapters for OpenVAS [10] and Nessus [11].
The OPS Logic module controls the processes of the OPS. It configures the security scanners, boots the virtual machines to test (if required) and starts the actual scans. Since the vulnerability scanners are basically third-party products with individual characteristics and modes of operation, they are abstracted by Adapters that hide the differences and provide an unified interface to start and monitor the vulnerability scanners. They allow the OPS not only to start the actual scans, but also to watch the scanners during the execution to detect any failures and react accordingly.
For a scan, the OPS needs two input parameters: the names of the target virtual machines and the name(s) of one or more vulnerability scanners. If no scanners are provided, the OPS chooses all scanners by default. A name uniquely identifies a virtual machine and allows the OPS to obtain further information like the IP and MAC address, path to the disk image(s), etc.
The Report Generator module collects the reports from the different scanners and generates the final result: a summary, containing the number of detected vulnerabilities categorized by a risk factor, and a combined report, containing the results from the security scanners in a unified format. To enable the Report Generator to analyze and understand the reports, the adapters have to convert the reports from the native format of the scanner to the unified OPS format.
The backend part of OPS consists of adapters to the required tools and libraries. It provides a module to control virtual machines using the libvirt [12] library as well as the vulnerability scanner adapters. Currently, the OPS supports two different scanners: OpenVAS [10] and Nessus [11], both well-known and established security-products.
Running vulnerability scans
OpenVAS is built as a client-server-architecture. The server is divided into three parts: administrator, manager and scanner. All clients communicate with either the manager or the administrator that both call the scanner. The OPS uses omp, a tool from the OpenVAS command line client for interaction. In order to guarantee a seamless scan, some of the countless options of OpenVAS are preset by the OpenVAS adapter module using a configuration file. This prevents the user from choosing wrong options that could possibly lead to false results. Nevertheless, by modifying the adapter configuration file it is possible for an administrator to enable/disable tests or set/unset options.
Nessus, being the ancestor of OpenVAS, is also built as a client-server-architecture. To control it, an XML-RPC interface is used. Nessus needs a number of parameters to start the scan process: the IP address of the server, authentication data and a scan configuration. Similar to the OpenVAS adapter, the Nessus adapter module presets a number of options to guarantee a seamless scan process.
Structure of the reports
The combined report generated by the Report Generator is hierarchically divided into several parts. It starts with a summary of all reports and contains the results of each scanner structured by each tested virtual machine. Finally, the machine-specific report contains the vulnerabilities of this host. This includes a detailed description of the vulnerability, the severity level and if applicable, port number and transport protocol. The following paragraph shows an excerpt of a report:
<vulnerability>
<title>Microsoft Outlook SMB
Attachment
Remote Code Execution Vulnerability
(978212)</title>
<port>general/tcp</port>
<risk_factor>HIGH</risk_factor>
<description>
Overview: This host has critical security
update missing according to Microsoft
Bulletin MS10-045.
[...]
CVE : CVE-2010-0266
BID : 41446
</description>
</vulnerability>