The components of an IDS work together as a whole to provide an early warning or post intrusion alerting system. In explaining how things work, we will use a network-based IDS as a point of reference.
On network-based IDS, the sensor will typically run as a separate host, and the backend and frontend will generally run on another host. In a bigger environment, there will be more than one sensor, and the backend and frontend are on a separate host.
Sensors Detect and Report
Sensors typically have a capture network interface and a management network interface. Sensors tap into the network so that it can listen to the various communications within its reach. Fifteen years ago, network hubs were common, and as such connecting the network interface of a sensor to any port would give it access to all traffic that goes to any ports of that hub. When network switches became common, ports used by sensors required configuration to span other ports (i.e. to copy traffic from ports of interest).
As the sensor sees traffic from the network, its capture engine quickly passes it into a buffer, necessary to help it to keep up with the load, and if the buffer isn't large enough or if the engine isn't fast enough, it could drop packets. The detection engine then goes through the buffer and performs network protocol analysis. In performing protocol analysis, it may sometimes have to find multiple packets in order to properly compose a complete higher level protocol message, or in order to see if certain event thresholds are exceeded. Signature-based event detection happens here. As soon as it detects an event, it reports it to the backend.
Behavioral malicious events require more processing and thus will require the sensor detect certain activities that are fundamental to malicious network attacks. As soon as the sensor detects a malicious behavioral event, it sends this event to the backend. Note that behavioral event detection is more complex and may require the detection of multiple primitive events and event count thresholds before triggering.
Backend Collect and Alert
The IDS backend is the hub of the IDS. All events reported by one or more sensors end up in the event repository database. It is in the backend where it determines how an event is handled. Most IDS allow the user to configure how it responds to events. Critical events typically are setup to send email, SNMP traps, displayed, and in more advanced IDS cause a block. The least significant events may simply be logged.
Frontend- Command and Control
An IDS would be difficult to use without a frontend. The frontend is where a user can setup, configure, and update the entire IDS.
As events collect in the backend, the frontend when opened shows events that have been configured to display (with its appropriate color coding or display indication). It is here where the user can manage detected events. IDS typically can get very event-noisy, meaning that it will report way too many events so that a user can get complacent and thus start to ignore reported events.
In order for an IDS to be useful, it should be fine-tuned to report only events of real significance and use. It is through the console that the user is able to fine tune the IDS detection and response, and if done correctly, will provide the user an early warning system from any intrusion. And if an intrusion actually occurs and is somehow missed, the IDS can report on actual intrusion events.