In integrating IDS events into Portalegde one question becomes paramount. Namely: “Which events do we include?” As Portaledge will perform correlation and aggregation on all of the events “fed” to it, choosing a set of events that provides critical network information, without overwhelming the administrator is important.
To include every IDS event, especially on an untuned IDS, could possibly result in a data deluge. And many administrators when faced with such a deluge simply choose to ignore the alerts, as finding the relevant and real alerts, while weeding out the false positives, grows difficult.
In order to facilitate the Portaledge and IDS administrator’s life we have included a few (3) mechanisms for filtering out IDS results. First, we have tagged the Qucikdraw Snort preprocessor rules’ output with a flag: “SCADA_IDS”. The Portaledge IDS module will grab and add as an event, any such flagged syslog event.
Secondly we have included a flat file in which specific Snort event classes can be included. The Snort event classes are described in the Snort Users Manual and many Snort rules include this class information. The majority of the “Snort Community” rules have the class information. We are currently including as defaults all of the “High” severity classes, most of the enumeration classes, and DOS classes. The Portaledge administrator will be able to tune which classes they would like to include and add into the Portaledge alerts.
Thirdly, we have included a flat file that lists Snort rule IDs (SIDs) to be included. The IDs can be included individually, or by ranges. By default I have included all of the Digital Bond SCADA IDS signatures.
Through these mechanisms the administrator can tune Portaledge to include only the IDS alerts that he/she deems relevant and important.