AlienVault: the Future of Security Information Management

Many client agents can communicate with OSSIM, but because of space limitations, I am covering the one I believe is the most valuable to security administrators: OSSEC. OSSEC is a freely available host intrusion detection system (HIDS) maintained by Trend Micro that performs a multitude of client security tasks, such as logging, alerting, integrity checking and rootkit detection. Additionally, a large number of OSSIM plugins for OSSEC already are installed with your server that can monitor virtually any part of a UNIX/Linux/Windows system.

First, let's install OSSEC on the CentOS Web server. Download and extract the client tar from the OSSEC Web site. If you have difficulty finding the OSSEC agent, or any other agent, links to OSSIM's supported third-party agents are available in the Tools/Downloads section of the management page. Next, run the install.sh script from the unpacked tar folder. Verify your machine information and select the agent install option. Accept the default install directory. Enter the IP address of the server (the OSSIM server). Run the integrity-check dæmon and enable the rootkit-detect engine. When asked to enable active response, answer “no”. To start the agent, run:

/var/ossec/bin/ossec-control start

Now, from the CentOS Web server, ssh to the OSSIM server, and run the following command to add your client agent to the OSSEC server:

/var/ossec/bin/manage_agents

Select A to add an agent, and enter a unique name for it. Add the IP address of your CentOS Web server and give the agent a unique ID. The default ID usually is fine, unless you plan on implementing a naming convention for your OSSEC clients. Enter Y to confirm adding the agent. This returns you to the main menu. Select E to extract. Input the client ID you want to extract (the ID you assigned to the CentOS server). From another terminal window on the CentOS Web server, run the local manage_agents command. Select I to import the unique key. Copy and paste the unique key from the SSH window to the Web server's local prompt. Enter Y to confirm the key, and select Q to quit. Close the SSH connection, and from the local prompt, restart the agent by running the command:

/var/ossec/bin/ossec-control restart

On your XP client, download and install the OSSEC agent as well as the Putty SSH client. When finished, run the Putty client to SSH to the OSSIM server and repeat the same manage_agents command to generate and extract the XP client's unique key from the server. Once extracted, paste it into the XP client by opening the Manage Agent applet from the start menu under the OSSEC program group.

Finally, to begin receiving OSSEC events in OSSIM, open the file /etc/ossim/ossim_setup.conf on the OSSIM server and in the [sensor] section add ossec to the end of the line that begins with the word detectors. Save and exit the config file, and restart your OSSIM server using the shutdown -r now command. Upon reboot, you should start to see OSSEC events appear in OSSIM. To test this, restart the OSSEC agent on the XP machine and look in the Events→SIM Events section of the OSSIM management page. You should see messages related to the OSSEC agent (Figure 7). As you now have an external feed coming into your OSSIM server, let's look at how it digests and analyzes the data.

Figure 7. Verifying the OSSEC Agent Is Talking to OSSIM

For OSSIM to decipher data from any source, it first must have a plugin. A plugin is an XML-based configuration file that tells OSSIM how to read information from a particular data source and when to register a security event. According to the AlienVault site, more than 2,300 plugins currently are available (see the Popular OSSIM Plugins sidebar for a brief listing of the leading ones).

An event is any occurrence that a plugin's native software deems important enough to log or warn on. Events in OSSIM should be treated like log entries. They are not necessarily indicative of a problem, but should be reviewed nonetheless. When multiple events take place in such a way that an administrator has marked them as being “suspicious”, OSSIM throws an alarm. It is also possible for a plugin to set a single event's settings high enough that it can throw an alarm when the single event occurs. The criteria used to trigger an alarm from multiple different events is known as a directive. The process of analyzing multiple events within a directive is called correlation. Correlation is central to OSSIM's operation. With correlation, administrators can take data from a multitude of disparate security devices and tailor directives to reduce false positives and extrapolate threat data in real time.

Take a typical IDS (Intrusion Detection System) device, for example. An improperly tuned IDS can record a large number of false positives. However, with OSSIM, you can create a directive that correlates your IDS events with known vulnerabilities in Nessus. By doing so, you reduce false positives and refine questionable data into a valuable security check. As another example, you could correlate multiple port scans from Nmap with failed logins from syslog (or OSSEC, as I explain later) to detect break-ins. A third example would be to correlate aberrant network behavior using ntop with rootkit checks from OSSEC or virus detections from Sophos, ClamAV or McAfee to monitor for client-based threats. With the number of plugins available for OSSIM, the possibilities for correlation are almost limitless.