Analyze Network Events with OSSIM Toolset

It’s nearly impossible to keep track of every event that occurs on a network, much less determine whether each event is a security risk or not. But this tool can help: the comprehensive Security Information Management (SIM) application called Open Source Security Information Management (OSSIM). It provides both active and passive information-gathering capabilities to help you get a security-focused view of your network.

OSSIM is certainly not alone in the SIM field, but as an open-source framework, it provides a very powerful, scalable, and inexpensive solution that can analyze events from various sources (e.g., network scanning and asset information) and determine whether a security event has occurred. I’d like to show you OSSIM, run through a test installation, and discuss the first few steps you should take after installation. You’ll learn about defining network and host policies, running a manual scan against a host, and configuring an automatic network probe.

OSSIM Revealed

OSSIM is actually many tools combined into a single application (see Table 1 [PDF] for a list of specific tools). OSSIM’s main components are a database, a correlation- and risk-assessment engine, collectors, sensors, a control daemon, and a web-based front end. The database stores all of the events OSSIM detects on the network, whether the event is found via passive or active scanning. The correlation- and risk-assessment engine is what helps to set OSSIM apart from other open-source security management solutions, as it provides a way to define rules for determining when a security incident has occurred. Collectors provide the capability to aggregate log information from Linux, UNIX, and Windows hosts as well as from applications and network devices, while sensors actively probe hosts and networks with tools such as the Nessus security scanner. The control daemon ties this process together, including providing the capability to control many of these tools in the background. Finally, the web interface provides administrators with a way to both configure OSSIM and to view reports and security incidents detected by the application.

OSSIM can be installed on a single host, but in larger deployments it can be split into each of the components mentioned above. Furthermore, collectors and sensors can be distributed across an entire network, letting you scale this important activity and also locate OSSIM components geographically closer to monitored devices.

Installing OSSIM

Because OSSIM includes so many components, it was tedious to install. However, OSSIM is now available as an ISO image preloaded on an instance of Linux so that you can easily take it out for a test run. To try it, download the ISO image from the OSSIM download page. You can install OSSIM on a hardware server or as a Virtual Machine (VM) under VMware, Microsoft Virtual PC, or Xen. Regardless of whether you choose a hardware server or a VM, you need to boot from the ISO, follow the on-screen instructions (for supplying the OSSIM server’s IP, DNS, gateway, and other related settings), then perform a final reboot.

Accessing the UI

After you install and boot OSSIM, you should be able to access the web interface for initial configuration. Go to the URL ossim-ip and you should see a logon screen. When installed from the ISO, OSSIM has a default administrative account with the username “admin” and the password “admin.” Log on using these credentials to start configuration.

At this point, you should see the Executive Panel, which provides a dashboard-like view highlighting key information about your network, such as the most recent and common security events. The dashboard is configurable, and you can update or replace the elements of this page later after you’re more comfortable with OSSIM and after OSSIM has started to collect useful information about your network.

Feel free to click all of the menu items to get used to navigating OSSIM. Unfortunately, OSSIM can be unwieldy because of the many features it provides, and it’s not unusual to be a little bewildered at first. That’s okay, because we walk through an initial OSSIM configuration next.

Configuring OSSIM

Now that you’ve clicked around within OSSIM, it’s time to provide the initial configuration so you can get some useful data. Let’s walk through how to define the policies that drive OSSIM’s actions, inventory example servers on your network, and configure network and individual hosts Then, I’ll show you how to initiate a manual security scan against one of those servers and schedule automatic scans to alert you of new problems.

Policies in OSSIM are groups of settings that drive OSSIM’s behavior. Essentially, policies are configuration parameters specifying networks, hosts, alert types, scanning actions, and more. Like much of OSSIM, policies can be rather confusing, especially because of the sheer quantity available. Because of this, I simply focus on the minimum number of policies that need to be defined so that you can start using OSSIM. Later on, you can begin experimenting with policies to see all of the capabilities that OSSIM actually provides.

Defining Your Network

The first configuration step is to specify every network you own. OSSIM contains many tools that can passively detect hosts (e.g., p0f, which detects OSs being used on a network), but it won’t store all the information it detects about these systems unless the host’s network is defined. This makes sense: You don’t want your OSSIM database trying to store information about every network it detects. In addition, when defining a network, you can define which OSSIM sensors should be assigned to that network, which allows you to allocate sensors by capacity or geography as needed. You define your initial OSSIM-monitored network by following the steps below:

Threshold C and Threshold A bear further explanation, and it takes a lot of hands-on experience with OSSIM to really use them well. Threshold C (compromise) determines whether OSSIM should store information about the event. Threshold A (attack) in a similar way defines the minimum attack score that will prompt OSSIM to respond. Admittedly, understanding when and how these values are to be used is confusing to many, if not most, users, and hopefully the OSSIM team will address this in a future release. For now, experience says to use the defaults provided.

When you add, delete, or modify policies in OSSIM, you need to click the Reload option on the policy screen after you make your change. OSSIM automatically detects a change after several minutes, but it’s usually best to make OSSIM immediately rescan its policy database to reload its configuration. In this example, I defined a single network. If you have multiple networks, you can add them now as well. Of course, if you don’t have an OSSIM sensor instance on a network, you won’t get as much information as you will on a local network, but OSSIM can still gather information if there is a lot of communication across networks.

Defining Hosts

Even though you’ve configured your network in OSSIM, you still need to configure individual hosts. This is due to the same reason I mentioned earlier: To save on storage, OSSIM doesn’t store much information about undefined hosts. Admittedly, having to configure your networks then configure hosts within those networks can be both tedious and confusing. However, OSSIM provides an automated host-detection mechanism to make host configuration easier; we’ll discuss the automated host-detection mechanism momentarily.

You can manually define a host within a network recognized by OSSIM. To do so, follow these steps:

When entering the host information, you’ll see well-known settings, which Figure 1 shows, such as host name and IP address, but also a new one, RRD Profile.

An RRD profile simply specifies when an ntop statistic should be used to generate an alert in OSSIM. (Ntop is a tool in OSSIM that builds a network information database to help detect anomalies indicating aberrant behavior.) Again, as with the Threshold C and Threshold A values, RRD Profiles confuse many users, and the OSSIM team needs to provide a clearer way to define and use them.

At this point, OSSIM will now begin storing information about the defined host (e.g., any vulnerability it finds during an active Nessus security scan). However, defining all of the devices on your network using this manual approach is tedious and error prone. In addition, the manual process requires that you know every device on your network, which isn’t always the case, and, in fact, lack of knowledge about the devices on one’s network is also a reason why security administrators often use tools such as OSSIM.

Instead of manually adding hosts to OSSIM, you can run a network scan using the Net Scan tool located at Tools. I found that Net Scan can take a considerable amount of time, sometimes up to an hour on a single subnet. After Net Scan has finished, you’ll see a button for saving all of the detected hosts. Save your list of hosts immediately so that these hosts can be actively monitored by OSSIM from now on.

Performing a Vulnerability Scan

Vulnerability scanning via OSSIM is one of the first capabilities that you should try. OSSIM relies on the open-source Nessus vulnerability scanner for active scanning and the Open Source Vulnerability Database (OSVDB) to provide additional information on detected vulnerabilities. This integration of tools is an example of the many ways in which OSSIM provides more than just a simple front end for security tools. Nessus is a powerful tool, but when used alone it’s very difficult to track changes to a host over time. By integrating Nessus with OSVDB, as well as being able to run Nessus in the background and on an automatic, scheduled basis (as we’ll discuss later), OSSIM can automate much of the information gathering that’s part of a security administrator’s job.

Actually, performing a vulnerability scan is one of the most confusing tasks in OSSIM due to where the activity is located. To run a vulnerability scan, you need to “gather” new events” by going to the Events menu and performing the actions below:

OSSIM will begin background scanning of the selected host. Unfortunately, you don’t know when the scan is completed unless you wait for OSSIM to populate the Incidents or Vulnerabilities view, which I’ll cover later on. First, however, go ahead and configure automatic scanning while you’re at this location by doing the following:

The example above should provide you with enough information to be able to further tweak your scanning schedule at a later date. Keep in mind that OSSIM will run scans from a network’s assigned sensor, so you don’t need to define that here.

Oddly enough, the OSSIM ISO installs the scheduler for OSSIM scanning in a non-executable state, so you’ll need to fix that. Log in as the root user (via SSH) to the OSSIM server and set the execute bit on the DoNessus.py script, by entering the following:

 ossim:/# chmod ugo+x /usr/share/   
  ossim-framework/ossimframework/   
  DoNessus.py ossim:/# 

Viewing the Scan Results

OSSIM automatically generates incidents whenever one of its rules is triggered, even during passive scanning (e.g., events detected by the passive Network Intrusion Detection System Snort, which is included on OSSIM sensors). However, you don’t need to wait for any events to be passively detected since you just ran a Nessus vulnerability scan. Figure 2 shows incidents found by Nessus.

Of course, in your production environment you don’t want OSSIM to treat every piece of information as an incident. Therefore you should further explore the use of Threshold C, Threshold A, and RRD Profiles when defining your networks and hosts, because these parameters are what OSSIM uses to determine when an event is of enough value to be recorded and placed in the incidents database.