A great deal of ossim's behaviour is configured through this section. Assets should be defined (both at host and at network level), IPS actions and responses can be configured and ports, sensors, servers and plugin groups need to be defined for policy setup.
This section controls part of the collection, priorization and correlation core of ossim, similar to a firewall policy GUI. You define a set of sources, destinations, events, what to do with them, how and to which targets it applies (which servers / sensors to apply the policy).
The Policy page displays the “policy” for your system, as displayed in Figure 29. The policy is essentially a group of settings that handle behavior and security. Here you can tune OSSIM in multiple ways, specifying what do you want to do with certain events or alarms. This page allows you to view those settings and to create new policies when necessary.
Every time you modify the policy it's best to restart the server since it modifies quite some internals.
Figure 29 – Policy > Policy
By default, there are no policies, so you must could create one by clicking Insert new policy. The Insert new policy page lets you set the following bit of information through the use of check boxes and radio boxes:
Basically when editing a policy you've got the following fields to fill in / adjust:
This field specifies the origin of the events we want to match. Events that don't have a target or where a target makes no sense (OS changes, mac changes, new service, identified vulnerability, etc…) only have source.
Source can take one of three values:
Here we set the target of an event. Event that don't have a target (os, mac, service, etc…) should be defined as ANY, theyr target will be inserted as 0.0.0.0 if inserted into a mandatory ip field.
Destination, again, can take one of three values:
Destination port specifies the destination port of an event and can be defined under Policy >Ports. Again, some events may not have a port related to it so ANY should be used for those.
Each event arrives with it's own priority and reliability, wich is taken from the DB. Besides events can be aggregated under new priorities and reliabilities as alarms. Both types of events can be further refined using policies and this parameter controls how to adjust the priority of a matching event.
The priority can be selected from a list and can take the following values:
All of them are self explaining, “Do not adjust” leaves the priority untouched, 0 makes the event invisible for anything risk-related inside ossim.
Each event is uniquely defined by two numbers, it's “plugin ID” and “plugin SID”. Using the Policy > Plugin groups you can define one or more groups suitable for your policy.
This is the sensor who must generate the events for this policy to match. You can setup sensors under Policy > Sensors.
Although somewhat limited right now this allows for a start and end time definition for the policy.
Where to “install this policy” on. This doesn't actually install it on the selected targets but tells the target that it has to take this policy into account. Set then up at Policy > Servers. (NOTE: This will be grouped along with sensors under 'targets'). Valid targets as of 2007/04/02 are servers, their name must match the <server name=””> entry under /etc/ossim/server/config.xml .
For example, “serverUP” herein:
<server port="40001" name="serverUP" ip="0.0.0.0"/>
These are some “yes/no” options that tell the targets what to do with the event once it has matched:
Just that, a simple description field.
A number of these settings allow you to add new options if the list of available choices do not fit your needs. For example, you can click Insert new sensor link below the Sensors header to add a customized sensor to the list of available sensors. Once you are finished, click OK. A dialog appears indicating that your policy was created successfully; click Back.
The new policy appears in the Policy page. You can click Refresh if it does not appear. Should you wish to modify or delete the policy, you can do so by using the links in the Action column. If you opt to modify the event, the Update policy page appears displaying the same list of options mentioned above maintaining the selected check boxes and radio boxes. Once finished, you can click OK to validate your changes or Reset to return to your initial parameters.
Getting this all together, this is how a sample policy setup looks like:
The Hosts page displays the list of hostnames as well as pertinent information about them, as shown in Figure 30 – Policy > Hosts.

Figure 30 – Policy > Hosts
Using the Action column, you can modify one of the existing hostnames. Once you click Modify for the desired hostname, you can modify the following pieces of information:
Details about these options may be found in the Policy > Details section.
A number of these settings allow you to add new options if the list of available choices do not fit your needs. For example, you can click Insert new sensor link below the Sensors header to add a customized sensor to the list of available sensors. Once finished, you can click OK to validate your changes or Reset to return to your initial parameters.
You may also opt to create a new host by clicking Insert new host from the Hosts page. The insert new host page displays the same list of parameters listed above that you can set. Any fields that are followed by an asterisk are mandatory. Once you are finished, click OK. A dialog appears indicating that your policy was created successfully; click Back.
The Networks page displays the list of available networks for your system, as well as relevant information for the network, as shown in Figure 31 – Policy > Networks. In general OSSIM will need that you define all the networks from where you want to get information.

Figure 31 – Policy > Networks
Like the other tabs for Policy, you can modify, delete, or add a network. To modify an existing network, click Modify in the Action column.
Once you click Modify, the Modify network page appears, allowing you to modify the following settings:
Details about these options may be found in the Policy > Details section.
A number of these settings allow you to add new options if the list of available choices do not fit your needs. For example, you can click Insert new sensor link below the Sensors header to add a customized sensor to the list of available sensors. Once finished, you can click OK to validate your changes or Reset to return to your initial parameters.
If you choose to create a network, you can do so from the Networks page by clicking Insert new network. The same list of settings is available to you as listed above. The only difference is that when creating a new network, you can set multiple or a range of IP addresses. Once finished, you can click OK to validate your changes or Reset to return to your initial parameters. If you are saving your network, a dialog box appears confirming that your operation was successful; click Back to return to the Networks page.
The Network groups page lists the available network groups available for your machine, as displayed in Figure 32 – Policy > Network Groups. You can use this option to organize your networks.

Figure 32 – Policy > Network Groups
By default, the Network groups page is empty. Like the other tabs for Policy, you can modify, delete, or add a network group. To do that, click Insert new network group.
You can set parameters for the following:
Details about these options may be found in the Policy > Details section.
A number of these settings allow you to add new options if the list of available choices do not fit your needs. For example, you can click Insert new network link below the Networks header to add a customized network to the list of available networks. Once finished, you can click OK to validate your changes or Reset to clear your changes. A dialog box appears confirming that your operation was successful; click Back to return to the Network groups page.
The new network group appears in the Network groups page; to modify it, simply click Modify from the Action columns. The information above relating to creating a new network group also applies when modifying a network group.
Policy details allow configuration of assets OSSIM monitors. Assets include Hosts, Networks, and Network Groups. While these are not similar, some have different parameters (e.g. host IPs versus network IPs), all share a number of common options (see Figure 10 33 – Policy Detail).

Figure 33 – Policy > Details
Common options include Asset, Threshold C, Threshold A, RRD Profile, Sensors, and Scan Options. Asset, Threshold C, and Threshold A are all values used to calculate the CALM Risk value for a host and some specific events. All other options are unique to the asset and explained in their respective section.
Asset is used to calculate the risk. Risk is the product of Asset, Priority, and Reliability divided by ten25. Asset is a number between zero and five. Assign a value relative to the intrinsic value of the asset, being 5 the highest value. Assigning a high asset value to all equipment is not an effective use of the asset value. Threshold C is the maximum compromise accepted value; If the Host exceed it thanks to some events, it will appear in the Control Panel → Metrics page. is the compromise risk level. Alerts have compromise values and this value indicate what values affect this particular host.
Threshold A is is the maximum attack accepted value; If the Host exceed it thanks to some events, it will appear in the Control Panel → Metrics pagethe attack risk level. Alerts have attack values and this value indicates what values affect this particular host.
RRD Profile is used to determine what alerts are generated based upon ntop statistics and prediction capabilities. OSSIM monitors these values and creates alerts based on the settings. RRD Profiles are defined under OSSIM > Configuration > RRD Config > Modify/New RRD Config.
Scan options indicate whether or not the checked plugin scans that particular asset. The options are nagios and nessus.
Sensors are connected and configured through the Policy > Sensors interface. OSSIM uses sensors to collect data. The information on this table may change when the web page reloads. There are two tables in this interface (see Figure 34 – Policy > Sensors).

Figure 34 – Policy > Sensors
The first table is a simple count overview of sensors. Active Sensors are sensors talking to the OSSIM Server at the moment the sensor page was loaded. Total Sensors is the number of sensors configured within the OSSIM database. This total includes sensors that are communicating with the server, sensors not communicating with the server, and misconfigured sensors. The number listed under Total Sensors is number of lines in the second table.
The second table lists all of the sensors and their configuration. This information comes from OSSIM’s database. There are five columns in this table.
IP is the IP address of a sensor with an OSSIM Agent. This field must be a valid accessible IP address from the OSSIM Server (although is the Agent who starts the connection usually). The sensor uses this address to connect to the OSSIM server.
Hostname is the name of the host. The hostname does not have to be the actual hostname as reported by the sensor. This has nothing to do with DNS name, it is the name it will be given to that specific host within OSSIM.
Priority determines how hosts sensors link within host reports. A host may have multiple sensors and the highest priority is the first sensor linked to the host. Priority may be a value in the range of zero through ten.
Port is the network destination port the agent uses to communicate with the OSSIM Server. This may be changed to facilitate access through a firewall, port forwarding or some obfuscation technique. Changing the port number is not recommended for novice users of OSSIM. Changing it here requires a configuration change within the OSSIM Agent, potentially the host where the agent is installed, and other network components.
Active identifies whether or not a sensor is active or not. Active sensors are those sensors that have an OSSIM Agent communicating with the OSSIM Server. A green YES indicates an active sensor. A red NO indicates that a sensor is not communicating with the OSSIM Server.
Description is a text used to describe the sensor. It is a particularly useful field for complex networks or when sensors have non-descriptive names. The description should be used to clarify what the sensor is actually monitoring.
Action contains hyperlinks to three options for each sensor: Modify, Delete, & Interfaces. Modify is used to change the configuration of the sensor. Use modify to repair misconfigured sensors or update descriptions as the network they monitor changes. Delete removes sensors from the OSSIM Database. Delete sensors that are unused and no longer have data. Interfaces takes you to the interface screen to define the interfaces that Ntop will see (if any).
Warning: Deleting sensors disassociates sensor information from data stored within the database. This means that you may not be able to find out where old data came from in your database. Deleting a sensor removes that information.
The Servers page displays the list of available children servers for your machine. This includes the number of active and total children servers. At the left, you will see “Master server at …” This is the main server - the one installed in this server - and informs you if it is active or not. Please note that if you have only one server (one level architecture) you won’t see any servers listed in the table - you will only see the “Master server.” This page also includes other relevant information, as shown in Figure 16.

Figure 16 – Policy > Servers page
Like the other Policy tabs, you can modify, delete, or add a server to your system. To insert a new server, click Insert new server, which is located at the bottom of the page.
Once the Insert new server page appears, you can set the following options:
Once finished, you can click OK to validate your changes or Reset to clear your changes. A dialog box appears confirming that your operation was successful; click Back to return to the Servers page.
To modify an existing server, click Modify from the Action column for the desired server. The only difference between adding and modifying a server is that you cannot modify the hostname when making modifications. If you made an error in setting the hostname, it is better to delete the server and create a new one. Once finished, you can click OK to validate your changes or Reset to clear your changes. A dialog box appears confirming that your operation was successful; click Back to return to the Servers page.
The Ports page lists the list of available ports and port groups, as displayed in Figure 17.

Figure 17 – Ports page
Like the other Policy tabs, you can modify, delete, or add a port or port group to your system. To insert a new port group, click Insert new Port Group, which is located at the bottom of the page.
Once the Insert new port group screen appears, add a name, select a port or ports, and add a description. Once finished, you can click OK to validate your changes or Reset to clear your changes. A dialog box appears confirming that your operation was successful; click Back to return to the Ports page.
To add a new port, click Insert new Port from the bottom of the Ports page. Add a port number, select a protocol, enter a service name, and add a description. Once finished, you can click OK to validate your changes or Reset to clear your changes. A dialog box appears confirming that your operation was successful; click Back to return to the Ports page. The new port will appear in the list of available ports when adding a new port group.
Even though you cannot modify a port number that you created, you can make edits to your port group. To do this, click Modify from the Action column. The only difference between modifying and creating a port group is that you cannot modify the name of the port group. Once finished, you can click OK to validate your changes or Reset to clear your changes. A dialog box appears confirming that your operation was successful; click Back to return to the Ports page
The Actions page displays the list of programmed actions for your machine. By default, this page is empty, as displayed in Figure 23 – Policy > Actions. When some alarm matches in the other Tab, Responses, then the specified action is executed. And here you can define that actions to be taken.

Figure 35 – Policy > Actions
Like the other Policy tabs, you can modify, delete, or add an action to your system. To insert a new action, click Add new action, which is located at the bottom of the page.
Once the Add new action screen appears, first enter a description in the text box. The Type field lets you decide whether to call an application or to send an e-mail to someone when appropriate.
If you select “send an e-mail message”, you must enter the sender’s e-mail address, the recipient’s e-mail address, and the subject of the e-mail. A text box is available for you to enter the body of your e-mail. Once finished, you can click OK to validate your changes or Reset to clear your changes. A dialog box appears confirming that your operation was successful; click Back to return to the Actions page.
If you select “execute an external program”, you must add the command line for the application. Once finished, you can click OK to validate your changes or Reset to clear your changes. A dialog box appears confirming that your operation was successful; click Back to return to the Actions page. Keyword substitution is an available feature here (see Keyword Replacement). Please beware; executing external programs may be a security risk and it should be done very carefully.
To modify an action, click Modify in the Actions column for the desired action. Please note that when modifying an action, you cannot change the action type (if you selected to send an e-mail, you cannot change your mind and call an application instead). Once finished, you can click OK to validate your changes or Reset to clear your changes. A dialog box appears confirming that your operation was successful; click Back to return to the Actions page.
Keyword substitution are variables that interpret into their corresponding values. This feature is available in Actions. You can take a look to the keywords in Policy > Actions. The keywords may be used with external scripts or with personalized e-mails when an alarm arrives. OSSIM substitutes the keywords with the appropriate values.
All the keyword values are referred to the alarm fields.
Note: this is for incidents, not actions.
The Plugin Groups page displays the name of the various groups of plugins, as well as relevant information about each, as displayed in Figure 37 – Policy > Plugin Groups.

Figure 37 – Policy > Plugin Groups
Like the other Policy tabs, you can modify, delete, or add a plugin group to your system. To insert a new plugin group, click Insert new group, which is located above the table.
Once the Plugin Groups page appears, you must add a name and description for your group using the text boxes. Then, select one or more plug-ins using the check boxes next to the list of plugins. Once you select a plugin, you must add its SIDs using the text box that appears next to the plugin name. Click Accept when finished, you automatically return to the Plugin Groups page where the new plugin appears at the bottom of the list.
To modify a plugin group, click Edit from the Actions column of the desired plugin group. Everything but the Group ID number (which was automatically assigned to your group when you created it) can be modified. Once you are satisfied with your changes, click Accept. You automatically return to the Plugin Groups page.
The Plugin groups are needed for Policy, for example. If you want to use just one plugin, you’ll need to create a group with only one plugin inside it. With this approach, is much more easy to create complex Policies.
Please add your name to the list above if you make significant improvements to this document