ACID news

[roman () danyliw com]

- Rough ACID performance benchmarking: 
http://acidlab.sf.net/acid_perf.html

- Release of v0.9.6b12 which contains some bug-fixes, and
  the removal of the BCMath dependency in PHP (thanks for pointing this out
  Christopher Ostmo <tech () appideas com>)

- Introduction of "alert event caching" in v0.9.6b13 (in CVS)

The alert event cache is an optimization introduced to decrease the processing time of
various
analysis operations.  With the growing functionality of ACID, the SQL queries to the
database
are becoming increasing complicated requiring at a minimum the JOINing of several tables. 
The
JOIN of tables can become extremely memory intensive as the size of the tables (i.e. the
number
of alerts grows).  In an effort to minimize these table JOINS, an alert event cache tables
was created (table: acid_event).

The newly introduced acid_event table combines the most commonly used information
about an alert into a single table: IP address, ports, signature name, classification, and
priorities.  Two observations can be made about this new table: it redundantly stores
information,
and is not normalized.  While these are usually undesirable features, it was felt that
with the
declining price of storage this was a reasonable trade-off to yield much better
performance.

All analysis operations now are performed from this event cache.  This reality introduces
a
new paradigm shift for ACID: alerts are no longer processed in real-time from the same
tables
as they were logged by Snort or other security devices.  Hence, the event cache must now
be maintained; that is, newly logged alerts must be moved into a new table structure in
order
to be "seen" and analyzed by ACID.  It must be stressed that this "caching" operation is a
one
time cost and must be done only once per alert.

There are two possible strategies by which to manage the alert event cache:

  - Automatic: By setting the $event_cache_auto_update variable, ACID
      will automatically check and as required update the event cache on the loading of
      every page.  With this configuration, the existence of the event cache becomes
      transparent.  It should be noted that when a given page is loaded and there are
      a substantial number of uncached alerts, page loading time will be impacted as these
      alerts are cached.

  - Manual: Alerts will not be moved into the cache (and not visible to ACID) unless
      the user manually moves the alerts into the cache from the acid_maintenance.php
page.

See you all at Blackhat and Defcon,
Roman


---------------------------------------------
This message was sent using Voicenet WebMail.
      http://www.voicenet.com/webmail/



_______________________________________________
Snort-users mailing list
Snort-users () lists sourceforge net
Go to this URL to change user options or unsubscribe:
http://lists.sourceforge.net/lists/listinfo/snort-users
Snort-users list archive:
http://www.geocrawler.com/redir-sf.php3?list=snort-users