- Reports, reports, reports: The current set of reports
accessible from the Reports tab is limited. Not only should
there be more reports, they also need to be output in file
formats that are easily merged with other documents. Also,
the capability of displaying the information graphically needs
to be added.
- Configuration handling: All XML configuration files
need to be maintained in the database (currently only rule
configurations are maintained). Also there needs to be a
configuration/rule validator function.
- Integrate information: The database maintains incident
data, reports, and statistics information. It is possible to
implement queries to any of these using the current display to
define the search parameters. It is also possible to implement
the use of data from collected statistics to assist in building
- Export to libpcap file format: While the IDS reads
libpcap formatted data, it modifies the format to be stored
in the database. All of the information needed to produce
libpcap output is kept, so this capability is possible to
- Convert to AWT/Swing: Currently, the eclipse.org SWT
interface is being used. However, this makes distribution
complicated. By using the Java AWT/Swing interface, the only
external requirement would be the database interface (JDBC).
- Export to problem tracking systems: The Incident
Reports functionality is not a problem tracking system, but
can provide useful input to such a system.
- Rewrite in C++: The current implementation of the
Database Daemon is written in Java. This should not be a
performance consideration for most sites if the goal of
reducing false postives is achieved. However, there are
some technical issues in using Java that could be eliminated
by using C++. And if better performance results, so much
- Support additional databases: The supplied scripts
for initializing and managing the database should be sufficient
for most sites, and with most of the administrative functions
implemented in the GUI, the database would be transparent.
However, it is understood that there may be other reasons for
some sites to prefer a different database.
- IPv6 features: The Realeyes IDS system was designed
with support for IPv6. However, very little testing has been
performed with the protocol, and not all functionality
available for IPv4 is also available for IPv6.
- System status: The status of Realeyes IDS sensors,
including CPU utilization, memory usage, and disk space
availability can be transferred to the DBD using the same
mechanism as the rules export.
- Special handlers: There are several special handler
functions that have been discussed during the pilot project
such as the ability to define profiles for encrypted sessions.
- Variables in rules: To make rule definitions more
flexible, variables which are set in one part of a session
should be usable throughout the session such as, the domain
name in the original URL of an HTTP session.
- Documentation: The current documentation for the
Realeyes analysis engine library consists of doxygen output of
source code documentation. While an attempt has been made to
organize the source code so this documentation can be read
easily, a manual for developers using the library is needed.
- ISO: A Debian based ISO has been built, but work needs
to be done on it before it can be distributed. In particular,
there are kernel patches that can improve libpcap performance that
should be applied.
- Installation: The installation and configuration
scripts are currently only for the initial installation. They
need to be modified to allow for updates which selectively change