Important NIDS Features

Let’s now discuss the important features of an NIDS.

Maintenance

Most NIDS systems support centralized installation, configuration, and updating since in an enterprise network a security administrator cannot physically access each sensor. In addition, most vendors support the automated download of signatures and software updates. Distribution and customization of the signature libraries and policies should be possible on a per-sensor basis and on a per-group basis (these groups should be defined by the security administrator) so the group signatures and policies do not have to be pushed to each sensor individually.

Communication between the IDS components (sensors and management console) should be encrypted using strong authentication (via key exchange or challenge). And as mentioned earlier, NIDS Ethernet interfaces should be stealthy Transmission of data via the sensing interface is prohibited, unless it is configured intentionally (TCP resets, which we discuss later in this chapter, may be an exception).

Alerting

The management console should be configurable to support alerting via a variety of mechanisms, including SNMP traps, e-mail alerts, pager messages, syslog messages, SMS (short message service), IM, and console alerts.

Logging

All alerts and header and payload data should be automatically stored in a central event database that is backed up regularly via SCP or other secure means.

Extensibility

The NIDS should support simple integration of additional vulnerability assessment tools such as Nmap or Nessus, and should provide support the correlation of data from other IDSs (for example, NIDS and HIDS).

Response

Some NIDS are able to actively respond to attacks or misuse by interfering with the particular message stream that generated the alert. This is normally accomplished via targeted TCP resets that eventually tear down the connection, or by dynamically altering firewall rules or Access Control Lists to block the connection. These active-response NIDSs are often referred to as intrusion prevention systems (IPSs).

Most administrators do not activate these features because of the risk of blocking normal traffic. Imagine that this functionality was enabled on a system directly connected to the Internet. A clever attacker could send traffic to an IPS with the source address spoofed to that of an upstream router, and designed to trigger the IDS. The resultant blocking of the upstream router could effectively remove the organization from the Internet. In a VoIP environment where availability is a key metric, IPSs are not recommended because of this potential to obstruct voice traffic.