| ACARM-ng | |
| Developer: | WCSS |
| Latest Release Version: | 1.1.1[1] |
| Operating System: | Linux |
| Replaces: | ACARM |
| License: | GPLv2 |
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.
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 became 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]
ACARM-ng's main features include:
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:
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.
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.
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 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:
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:
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:
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:
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.