ACARM-ng
 | |
| Original author(s) |
|
|---|---|
| Developer(s) | WCSS |
| Initial release | 14 February 2011 |
| Stable release |
1.1.1[1]
/ 29 May 2012 |
| Written in | |
| Operating system | Linux |
| Type | |
| License | GPLv2 |
| Website |
www |
ACARM-ng (Alert Correlation, Assessment and Reaction Module - next generation) is an open source IDS/IPS system. ACARM-ng is an alert correlation software which can significantly facilitate analyses of traffic in computer networks. It is responsible for collection and correlation of alerts sent by network and host sensors, also referred to as NIDS and HIDS respectively. Correlation process aims to reduce the total number of messages that need to be viewed by a system administrator to as few as possible by merging similar events into groups representing logical pieces of malicious activity.
History
The initial version of ACARM was being developed in the frame of POSITIF European research project between 2004 and 2007. It has been written in Java as a practical proof of concept, presented in the article.[2] Despite its poor scalability and efficiency issues, the software proved to be highly useful.
At the end of 2009 it become obvious that the current design had serious shortcomings with poor performance in the first place. As a result of that the project was discontinued. Later that year, a new project nicknamed ACARM-ng was launched aiming to replace the original ACARM. ACARM-ng was to bring the alert correlation to a new dimension thank to its scalability and plug-in-based architecture. It has been actively developed since 2009 by Wroclaw Centre for Networking and Supercomputing as a part of the PL-Grid project.[3]
Features
ACARM-ng's main features include:
- generic framework (system can be easily extended with plug-ins)
- multi-threaded implementation
- low CPU utilisation and memory footprint
- implementation using state-of-art, object oriented design methods
- recurrent alerts processing
- real-time informing and reaction
- web-based data visualisation
- long correlation time windows, that do not delay reporting
Architecture
ACARM-ng consists of 3 main elements: correlation daemon, WUI and (optional) a database engine.
ACARM-ng's daemon has been designed from scratch as a framework solution. It provides core system functionalities, like logging, alerts and correlated meta-alerts passing between system parts, error recovery, multi-threading, etc.. The rest of the package are plug-ins, separated into following classes:
- persistency (data abstraction)
- input (data gathering)
- filter (data correlation and modification)
- trigger (automatic reporting and reaction)
Built-in software watchdog provides up-to-date information on system status.
WUI makes browsing of correlated data easy via graphical and tabular representation of gathered and correlated events. System administrator can easily see what is going on at every moment of system's lifetime.
The WUI and the daemon interoperate through a database. Daemon stores gathered data along with the correlation results and its runtime configuration. WUI is entitled to read and display this data.
Notice that even though data base engine is not required for running daemon, it is strongly recommended to save data persistently. Rejecting to use database makes it impossible to obtain system information via WUI and leads to a loss of historical data when system is restarted. Events that are no longer processed by the daemon are discarded as well.
Preprocessor
It is often required to limit the amount of incoming data (for example: remove alerts raised periodically by cron scripts). In order to allow users to adapt system's input to their own needs a special "preprocessor" component is provided. It allows to define a chain of accept-if-match and reject-if-match rules to accept or reject incoming alerts before they enter the correlation engine.
Plugins
ACARM-ng's daemon allows addition and removal of new plug-ins without the need to recompile the core package. It makes system development and testing much easier.
Each plug-in to be used, has to be configured in the main configuration file first.
Persistency
Persistency provides abstraction at the storage level. This generic interface can be used to implement any data-saving back-end, as long as transaction mechanism is provided.
Recent, stable release of ACARM-ng provides following persistency implementations:
- stubs (ignores all write requests - data is not saved)
- postgres (uses PostgreSQL data base for storing information)
Input
An input provides an abstraction of a data gathering mechanism. The only requirement on the implementation is to output alerts in an ACARM-ng-compatible form.
Recent, stable release of ACARM-ng provides following input implementations:
- file (reads XML files in IDMEF format)
- prelude (read alerts from Prelude-Manager data gathering point)
Filter
A filter provides an abstraction of the correlation and data update mechanism. There are no restrictions on what the filter can do with the meta-alert, though the most common use is to correlate similar alerts (specially tuned API is provided for this special case).
Recent, stable release of ACARM-ng provides following filter implementations:
- one to one (correlates events between a pair of hosts)
- one to many (correlates events, where the source host is the same for all alerts)
- many to one (correlates events, where the destination host is the same for all alerts)
- many to many (correlates events, where a set of source and destination hosts of correlated alerts are similar)
- DNS resolver (resolves IP addresses to DNS names, if possible)
- IP black list (changes the priority of alerts with source/destination addresses belonging to suspicious networks)
- same name (correlates events with the same name)
- event chain (correlates events that happened in a chronological order, on next-in-line machines; such a solution is rare and may indicate "scan, brake-in, escalation" sequence)
- users monitor (correlates events triggered by actions of one user)
- similarity (correlates events similar to each other, above a given threshold; all data is taken into consideration during comparison of two elements)
- new event (changes priority of events, that were not previously seen on the system)
- python (uses user-provided Python script for event correlation)
Trigger
A trigger provides an abstraction of the reporting and reaction mechanism. Triggers by design, are not allowed to change the content of the data, but initiate a response to alerts. Typical use is real-time reporting of suspicious events to administrators (for example via e-mail) and automatic reaction to the detected thread (for example blocking malicious host on a firewall).
Recent, stable release of ACARM-ng provides following trigger implementations:
- informing administrator about suspicious events:
- file (creates files in IDMEF format, with correlated events)
- gg (uses Gadu-Gadu instant messenger's protocol)
- jabber (uses XMPP (formerly named Jabber) instant messenger's protocol)
- mail (sends electronic mail)
- providing means of automatic reaction:
Each trigger can be set independently to react to a specific threshold, correlated alerts count, or any other rule, defined the same way as daemon's main preprocessor. Such approach gives a fully configurable solution, allowing to define arbitrary complex rules, to minimize false-positives, especially when system is configured to perform autonomous reaction on the suspicious events.
See also
References
- ↑ ACARM-ng downloads page
- ↑ Fredrik Valeur; Giovanni Vigna; Christopher Kruegel; Richard A. Kemmerer (2004). "A comprehensive approach to intrusion detection alert correlation". IEEE Transactions On Dependable And Secure Computing.
- ↑ Bartłomiej Balcerek; Bartosz Szurgot; Wojciech Waga; Mariusz Uchroński (2012). "ACARM-ng: Next Generation Correlation Framework". In Marian Bubak; Tomasz Szepieniec; Kazimierz Wiatr. Building a National Distributed e-Infrastructure - PL-Grid. Springer.