According to Wikipedia: “Security Information Management (SIM) is the industry-specific term in computer security referring to the collection of data (typically log files; e.g. event logs) into a central repository for trend analysis. Due to historic reasons of terminology evolution; SIM refers to just the part of information security which consists of discovery of 'bad behaviour' by using data collection techniques. The term commonly used to represent an entire security infrastructure that protects an environment is commonly called Information Security Management (InfoSec)”.

SIM's focus in real time security monitoring, correlating differente log types and offering fast analysis and dashboard tools.

They store events in a SQL database which have a concurrent event storage limitation.

A SEM (Security Event Management) stores large amount of logs in disk devices for historical storage purposes. It typically offers integrity and confidentiality implementing cyphering and digital signature.

SEM's are slow but can store years of logs. OSSIM does not implement SEM functionalities, although an OSSIM professional edition developed by AlienVault implements a SIEM (SIM+SEM).

OSSIM is different of most SIM's beacause of two main reasons:

• It's open source
• It implements not only the SIM funciotionalities but also a Sensor or UTM, which includes many open source detecting tools as: IDS, Vulnerability Assessment, Anomaly Detection, Network and Availability detection, Firewall, etc.

A UTM (Unified Threat Management) it's a unique appliance that includes different security tools.

OSSIM UTM/Sensor include detection and monitoring tools as well as a firewall (check below for a list), but not the antivirus, antispamm and web filtering as they are typically deployed in most companies. Adding open source tools to the OSSIM Sensor/UTM should be easy, OSSIM includes plugins for them.

OSSIM is available under the GPLv2 license. It is free to download, install, upgrade and use under the terms of this license. The tools that make up OSSIM run under following licences: BSD, GNU, GPL, PBL, QPL and OSVDB Free.

SOC stands for Security Operation Centre. It is the place where security analysts use the OSSIM Console to analyze the security events of their internal Network.

An MSSP (Manages Security Service Provider) is a SOC which offers security to their customers.

Please check the sections: http://www.ossim.net/dokuwiki/doku.php?id=documentation:architecture

Please check the documentation section: http://www.ossim.net/dokuwiki/doku.php?id=documentation:3._tools_compiled

Yes. OSSIM is highly scalable and can be customized as needed. New tools can be easily integrated without any change in the basic management structure.

OSSIM includes a number of plugins to collect from external systems (see the actual list), as well as tools to easily create customized ones.

The OSSIM collector is responsible for gathering events from all critical systems and presenting them in a single format to the Security Operation Centre. The collector engine comprises of two parts i.e. agent and collector. The agent resides on sensor, while collector resides on server.

• The term sensor refers to software and hardware that is installed in local networks to collect and send data. Sensors are also known as probes.
• The Agent is the process that runs on Sensor to collect and send data to the Server.
• A Plugin is a piece of software coupled with the Agent to extend its functionality. A plugin knows the format of a specific system log (e.g. a firewall, an IDS etc) and allows collecting data from it.

OSSIM architecture allows multiple servers and agents to be arranged in a multi-level mesh topology. Each node in the mesh performs roles and tasks assigned through centralized policy. Events flow from agents to local servers, from secondary servers to primary servers or between n-level servers. This architecture allows creation of sophisticated analysis groups, with data storage in single or multiple databases.

The Agent normalizes the data it receives before storing or transmitting to server. The data is stored in both original and normalized form. Data can be received through various network protocols and can be stored in different places i.e. OSSIM server, databases, plain text, or CSV files.

There is no limitation on the number of agents in a network. OSSIM administrator can deploy as many agents as required. These agents can be installed on dedicated machines or integrated with the systems being monitored.

Agents use plugins for analysing the information they gather. The behaviour of the Agents directly depends on the type of plug-ins they use:

• Detectors: Event collection and normalization is continuous. Once events are normalized, the information is sent to servers and analyses are carried out in real time.
• Monitors: Agents remain in stand-by state until servers request any information regarding the status of any asset. These queries trigger the activation of the Agent. The Agent then fulfils the request by gathering and sending intended data to the servers.

The capacity of storage in databases directly depends on the hardware. As an example, using Hardware Intel 8 CPU Core & 8 GB RAM with EVA 4000 HP SAN storage, 100 million of simultaneous events have been stored.

The event processing capacity depends directly on the hardware used. As an example, using Intel Pentium-4 3.2 Ghz with 2 GB Ram, 172,800,000 events were collected and correlated in 24 hours.

The modular design of OSSIM makes it highly scalable, allowing easy integration of new elements without restructuring or replacing the existing system.

The multi-level architecture of OSSIM is a redundant structure. This architecture allows redundant servers with several databases, aggregating all events in a central database. Furthermore, with OSSIM’s modular design, redundancy depends on each module:

• Server: Keepalived/VRRP has been used for providing high availability to the correlation core. The entire correlation action relays in one active server with a virtual cluster IP. While, as many passive servers as needed remain in standby state. In case of a network or device failure, events are kept stored in collector queues until another server becomes available. Thus, no events are lost during the adjustment of roles.
• DB Cluster: Databases are configured as clusters. Cluster MySQL v4.0 or higher can be used for horizontal growing.

Yes, OSSIM allows the authentication of its management users using LDAP protocol against corporative servers.

The asset value must be manually assigned by the administrators. Only a person having in-depth knowledge of the network environment can determine the appropriate asset value.

The priority and reliability of fixed events

is assigned in one of the following ways - When the event is normalized and stored in the database, an initial priority and reliability value is assigned - When the event is generated by correlation module, the matching correlation rule assigns its own pre-defined priority and reliability values. - Using general policies, the administrator can adjust the priority and reliability of an event.

The accumulated risk metrics can be monitored from main console. This allows tracking the system in real time, gathering information about each machine, each subnet, or even global network and its evolution over the time.

Check out the Actual Plugin List

Yes, OSSIM allows maintaining the original format of all collected data. Every event sent from the network collectors is stored in the SQL database in both normalized and original format. Furthermore, an event can also be stored on the machine from which it is collected.

AlienVault also provides a SEM functionality for large forensic archiving within the AV SIEM which is a professional edition of OSSIM.

Searches can be performed based on number of parameters for e.g. Timestamp, network address, user name etc.

For improved security, the data can be stored in encrypted format. AES with a block cipher of 128 bits is used as the default encryption method. However, keys of 192 and 256 bits can also be used.

No with OSSIM , you would need to do it yourself storing hashes or something like that in other places.

AlienVault also provides a SEM functionality which allow legal evidence implementing digital signature.

Hosts can be added to policy in one of the following ways: - Inventory module: New devices are added manually. This is the best option as it allows precise definition of hosts’ properties. - Active discovery: Network scanner is used to find active hosts within the network. The devices discovered by scanner can be automatically added to the database for later use.

Events in non-supported format can be managed by building new plugins. New plugins can be developed easily with a “general pluing configuration”

Alarms and events can be sent to third party devices using several protocols e.g. SMTP, SNMP traps, FTP, and TCP/IP etc. Furthermore, variables can be included within the transmission for detail processing at other end.

Yes, it is possible to perform detailed forensic analysis using OSSIM. All the information is stored in databases. Analysis can be done from highest level (names of received alarms and events) to the lowest level (ASCII or HEX format).

Differences between the three possible collection methods from Cisco Networking devices:

1. Router / Switch syslog
2. Netflow
3. Port mirroring

Device Syslog

• Advantages
  • Accurate detection of attacks targeted at the device itself.
  • Low bandwidth usage
• Disadvantages
  • Plaintext logging through the network
  • No information about traffic traversing the device

Netflow

• Advantages
  • Can handle much higher traffic loads than direct sniffing (port mirroring).
  • Devices that can't mirror might be able to export Netflow
  • It's easier to setup than a Tap, a Port Mirror or something similar.
  • Non intrusive.
• Disadavantages
  • No packet payload, which means: No p0f, no Snort, no arpwatch, no pads. Mainly ntop and some limited statistical attack detection (intrusions, portscans)

Port Mirroring

• Advantages
  • Full data payload means full ossim functionality.
• Disadvantages
  • May slow down the device if overwhelmed by traffic (very rare).
  • May drop too many packets for high networks speeds (Gigabit).

Conclusion

• At typical environments port mirroring for important areas, netflow for “border” or “not_so_important” zones and syslog for very important devices is recommended.
• At high traffic environments netflow for everything and syslog for all the netflow spamming devices is recommended, separating snort, snort+spade, p0f, arpwatch, pads on different hosts.

No, it is not necessary to keep collector and correlation engine together in the same machine. In fact, keeping them on different machines increases security and performance and therefore it is the recommended option.

OSSIM’s multilevel architecture allows the addition of new correlation servers and their use as collectors for event normalization. This provides wide range of possibilities for event delivery towards higher levels or towards correlation engine. Policies can be applied for choosing the specific events to be analyzed e.g. events with specific source or destination, events involving specific ports, or events exceeding security threshold etc. Agents not only send events to correlation engine for the real time alerts or event correlation, but also for data storage and answering server requests.

The reception of events in collector and their transmission to correlation server occurs in real time. As the events are received in collector, they are immediately transferred to correlation engine. Thus, the processing and analysis in both engines is immediate.

If a temporary network failure isolates the correlation engine from rest of network, the events are kept into collectors until the connection is re-established.

The normalization process allows ignoring the origin of events and further analysis can be performed in OSSIM’s standard format.

Consolidation is done by installing servers on Sensors. Correlation Directives and configuration in the main policy allow defining the events that should be aggregated and the ones that should be forwarded.

All the correlated events are recursively introduced in the system as if they were new events. Thus, they are processed, modified, discarded, re-prioritised, or re-sent as new ones. This allows risk re-calculation for next events, modifying automatically the information without the user’s intervention.

Yes, currently more than 100 predefined correlation directives are available. New rules can be defined as required. These rules are defined using extensible mark-up language (XML), therefore addition of new rules can be done with ease. === How can I create customized correlation rules? ===

Correlation rules are defined using extensible mark-up language (XML). Therefore, using any editing tool, both the modification and addition of rules appears to be trivial.

The correlation engine is capable of performing event correlation using several processes:

• Logical correlation: Using pre-defined and customized correlation rules.

• Inventory correlation: Through inventory look ups the system is able to determine the validity of an event by simply checking the platform and applications running on the attacked machine. If the attacked system is not vulnerable to such type of attacks, the event is simply discarded. For e.g. An event announcing attack against IIS, won’t be relevant if the device is running Apache.

• Cross correlation: If the event announces an event trying to exploit a previously detected vulnerability on a device, the reliability of the attack is raised up.

Nessus is integrated to analyse the vulnerabilities, while OSVDB is used as the database for vulnerabilities, hot-fixes, and solutions.

Please look at http://www.osvdb.org

There is a complete scheduler available to automate periodic vulnerability analysis. All the information gathered is stored and organized based on hosts or networks and is available for the correlation process. Furthermore, the user can graphically visualize the vulnerabilities affecting each asset.

All such events are associated with a full description of vulnerability and the solution to be implemented. Once vulnerability is identified, the user can search all events to find the relevant one. Thus, one can quickly get information regarding which assets are affected by this vulnerability.

Please check http://www.ossim.net/dokuwiki/doku.php?id=documentation:automatic_inventory

Both software and hardware elements can be added to the inventory i.e. operating systems, installed applications, product IDs, network adapters, slots, BIOS manufacturers, and any other desired characteristic of the system.

Yes, the inventory module is an important integral part of OSSIM as

• It allows wide range of possibilities to OSSIM management, providing each network element with much detailed information.

• It allows remote installation of patches on devices belonging to the inventory.

• It can be connected with the vulnerability management module for determining the vulnerabilities affecting each device. This is very helpful for correlation process.

This module allows administrator to live track each incident: pending elements to review, pending tasks for users, most important incidents etc.

ticket is used for classifying and arranging incidents.

Events, vulnerabilities, alarms, anomalies and threshold exceeded metrics can result in generation of a ticket.

Yes, it is possible to do look ups and apply filters: pending incidents, incidents opened for a particular user, highest priority incidents etc.

Different actions can be defined to execute, when a critical threshold is exceeded, for e.g. generation of new alarms, customized email notification, firewall reconfiguration, third-party tool reporting etc.

Yes, OSSIM allows both manual and automatic response to alarms:

1. Manual management: The information panel permits alarms to be analysed in detail by looking at the events that generated it, the devices involved etc. Then further tracking and processing can be performed using the incident manager.
2. Automatic management: This method allows automatic execution of actions to handle the alarm. The particular action to be taken depends upon the policy in force. Even, network perimeter devices such as firewall and routers can be reconfigured to deny access after an intrusion attempt.

The predefined responses include: email notification, SNMP event sending, external command execution and SMS notification. All these responses are customizable as they are based on templates and use special variables to send the data.

Automatic responses are stored in OSSIM’s activity log. Also, the incident manager lists them and gives the opportunity to track them. The administrator can generate reports based on incident statistics.

All the information regarding management actions is kept in audit logs. Details about the action and user who performed it can be found by looking up these logs.

Every user or system action is logged in a registry and can be reviewed afterwards. There is a special visor for this registry that can be used as an object for the reports as well.

Customized reports can be generated through dynamic pages (using AJAX technology). Graphical reports can perform database query and present the information in any supported formats. A number of formats are supported: pie charts, tags clouds, Trends, and any graphic generated by OSSIM’s plugins. The reports are created using objects, which can be selected easily with drag and drop action. All the collected events are stored in forensic database and can be used as a source for object creation.

These reports can be generated in either HTML or PDF format, and can be periodically emailed and stored in the repositories.

There are a number of tools for vulnerability and risk level management and analysis. All the data relating to vulnerabilities is available as well formatted reports, which provides quick and easy browsing of data. Scans performed can be stored for further analysis, and on demand reports can be automatically generated.

Every customized report belongs to the user who created it. Hence both the administrator and operators will have different accessible reports.

A comprehensive set of well defined reports are available with OSSIM. These reports provide wide range of information regarding every aspect on network security. The variety of available reports can be seen by the following examples:

1. Alarm management or security reports
2. Incidents reports
3. Vulnerabilities reports
4. Availability reports
5. Devices and their properties reports

• Written by: Julio Casal.
• Translated by: Jorge Cuevas and Jon Urionague.
• Reviewed by: Zeeshan Ahmed.
• Contributors: Armando Machuca, Roberto Martínez and Alberto Rodriguez.

Please add your name to the list above if you make significant improvements to this document

A single server can be used to run all of the required OSSIM components without any problems although a typical deployment splits this up into at least two hosts (server + DB) and (sensor).

This depends on various factors. The answer would be yes under the following circumstances:

• You are able to install and run software as root on your remote host.
• The ISP agrees to place a sensor for you and gives you access to the data it collects.
• You only want to monitor access to a hosted site and additionally correlate some apache, ftp and other application logs to which you have access too.

No, not at this moment although it will be implemented in the near future. That should cover that need. The only thing you can do to agents centrally is to enable/disable a specific plugin or to start/stop the service associated to that plugin (Policy→Sensors).

Currently there is no such authentication. Both authentication and encryption has to be done using external methods like openvpn, stunnel or ssh tunnels. In the future we'll search for a way that works well for python, php and C in order to authenticate & cipher very much like the prelude folks do, it really looks solid & robust.

The Snort shipped with OSSIM has some modifications, and we suggest to use this. Anyway, if you have your own snort, you can integrate it with OSSIM installing an ossim-agent in the same machine than the snort:

• First you need to activate the download of the right OSSIM packets. Follow the point 0.2 Apt configuration in http://www.ossim.net/dokuwiki/doku.php?id=installation:debian#apt_configuration . Remember that if you want to upgrade your own snort, you should change this later to get it from the debian repository, and not from the OSSIM one.
• Update the packages and install the ossim-agent:

# apt-get update
# apt-get install ossim-agent

• Take a look at the /etc/ossim/agent/config.cfg file, and activate the snort plugin. Something like this:

[plugins]
snortunified=/etc/ossim/agent/plugins/snortunified.cfg

• Activate snort with the Unified output. In the /etc/snort/snort.conf file, add this output:

output unified: filename snort, limit 128

• Be sure that the snort stanza in /etc/ossim/agent/plugins/snortunified.cfg file is the same than the output one.

Communication is done in plain text between all the elements. The server and frameworkd both are listeners with ports 40001 and 40003 assigned by default. Agents will listen on 40002 when server initiated connections are supported.