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:
- Click Policy, Hosts.
- Click Insert new host.
- Enter the host’s information.
- Click OK.
- Click Reload.
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:
- Click Events, Vulnerabilities.
- Click Please update scan.
- Click NetGroup / Nets / HostGroup / Hosts.
- Select a target host.
- Click Submit.
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:
- Click Events, Vulnerabilities.
- Click Schedule scans.
- Click Add another schedule.
- Choose NetGroup / Nets / HostGroup / Hosts.
- Choose LAN.
- Schedule the scan to run monthly.
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.
Register
