Managing Cisco's IDS Sensors
In conjunction with Cisco's flexible approach to security management, Cisco has developed several means of managing IDS platforms in the network. Each has different intents and benefits to better address the varying needs of security administrators. Some of the methods by which security professionals can manage their Network IDS infrastructure include
-
Command Line Interface (CLI) via console, Telnet, or SSH access
-
Cisco IDS Event Viewer (IEV)
-
Cisco IDS Device Manager (IDM)
-
Cisco Secure Policy Manager (CSPM)
-
CiscoWorks VPN/Security Management Solution (VMS)
Of these management techniques, all but CSPM and CiscoWorks VMS are provided as part of the Cisco IDS 4.0 Sensor software. Cisco Host IDS sensors can also be managed by VMS or, for smaller environments, by the Cisco IDS Host Sensor Console software. While we'll briefly examine each of these methods in this section, these administrative tools will be covered in detail in subsequent chapters.
As the most simple and perhaps quickest method of management, the CLI is available on all NIDS products, including the IDS modules for Cisco routers and switches. The CLI is accessible from the device console, but also from remote terminals via Telnet and Secure Shell (SSH). Using the CLI enables administrators to efficiently monitor and maintain their devices from virtually anywhere in the network.
The Cisco IEV and IDM are both graphical interface tools that allow administrators less experienced in CLI operations to manage the IDS infrastructure. IEV is a Java-based event viewer that runs on Windows platforms and includes MySQL as a backend database for event storage. Using IEV, administrators can view event and alert data from up to five IDS sensors in the network. The Cisco IDM is a browser-based configuration tool from which the security team can view and manipulate any number of IDS devices in the network. Although the IDM can be used to manage over 1000 IDS devices, Cisco typically recommends a ratio of 20 to 25 sensors per management console. Additional sensors can overwhelm administrators with high volumes of information that they may be required to analyze. For deployments larger than 25 sensors, multiple IDM consoles should be installed to manage the sensors. Both Cisco IEV and IDM provide secure management of the IDS infrastructure through Secure Sockets Layer–based (SSL) access.
Alternatively, large enterprise administrators may choose to implement Cisco VMS. Cisco VMS can run on either a Windows/Intel platform or on a Sun SPARC running Solaris. The Cisco VMS software is part of the CiscoWorks Suite of products and is intended as a large-scale, enterprise solution for security management. Using the VMS, an organization can manage all of their security devices including
-
Cisco Network IDS sensors
-
Cisco Switch IDSM sensors
-
Cisco IDS Network Module for routers
-
Management Center for Cisco Security Agents
-
Cisco PIX Firewalls
-
Cisco Firewall Services Modules
-
Cisco IOS Routers
As can be seen, the Cisco VMS enables an enterprise wide view of security. It includes all of the IDS management capabilities available via IEV, IDM, and the CLI, but facilitates management of a far greater scale of devices. VMS has several modules itself. Among those, the Cisco VMS 2.1 Security Monitor and IDS Management Center v1.1 are required from IDS management.
Because security devices (such as IDS) transport potentially sensitive data, secure techniques, such as SSH, IEV, or IDM, should be used to monitor and maintain the security infrastructure. Cisco has also developed two protocols by which IDS equipment can be managed, PostOffice Protocol and Remote Data Exchange Protocol (RDEP). We'll discuss both of these protocols next.
Cisco PostOffice Protocol
To manage and maintain the Cisco IDS devices, Cisco first developed a proprietary protocol known as PostOffice Protocol. It is now being replaced by RDEP, which we'll describe later. The PostOffice Protocol is not to be confused with the Post Office Protocol POP3 (TCP port 110) commonly used by mail clients to retrieve Internet mail. Rather, the Cisco PostOffice Protocol is a UDP service that functions, by default, over port 45000 to provide messaging between the management console and IDS sensors. After Cisco IDS Software Version 2.2.1, this default port is configurable. The PostOffice Protocol provides messaging for:
-
Command data
-
Error and alarm messages
-
Command and IP logs
-
Redirects
-
Device heartbeats
The PostOffice Protocol is primarily a "push" technology as opposed to the "pull" mechanism of RDEP. Because PostOffice Protocol was the primary means of communication between security devices, Cisco developed reliability, redundancy, and fault-tolerance schemes within the protocol to ensure messaging success.
While a UDP-based service, PostOffice Protocol requires acknowledgement of alarm message delivery. This promotes reliability since the IDS sensor will continue to send alert messages until it receives acknowledgement from the console. Redundancy and fault tolerance are enabled via multiple IDS console devices configured to service the same group of sensors. The PostOffice Protocol permits sensors to propagate messages up to 255 destinations, which allows for redundant alarm notifications and ensures the appropriate personnel are notified when an alarm is received. Similarly, up to 255 addresses can be specified for a single console host. This facilitates fault tolerance; should one route to a console address fail, another could easily initiate connectivity.
With PostOffice, administrators must assign each IDS sensor a unique identifier composed of some of the following attributes:
-
Host ID The Host ID must be a unique numeric value greater than zero, such as 30.
-
Organization ID The Organization ID must be a numeric value greater than zero, such as 100. This number can be the same for multiple sensors.
-
Host name The Host name is an alphanumeric string that identifies the host, such as Sensor1B.
-
Organization name The Organization name is an alphanumeric string that identifies the company or organization, such as AcmeCorp.
An example of the PostOffice naming convention is shown in Figure 2.1.
This helps the security team identify sensors in large environments, but it is also required for the PostOffice Addressing scheme, which is composed of three components. The host and organization identifiers signify the first two components of the addressing scheme, while the third component is a unique application identifier. All three of these unique identifiers are used by the protocol to route command and control communications.
For example, in Figure 2.2, a sensor with Host ID 3 and Org ID 20 issues a PostOffice Protocol alert using Application ID 10006 destined for an IDS console with Host ID 30 and Org ID 20. Upon receiving the alert, the Console acknowledges it via Application ID 10000 to the sensor.
Remote Data Exchange Protocol
As of the Cisco IDS 4.0 software, PostOffice Protocol is no longer used for communication between console and IDS sensor devices. Instead, Cisco implements the Remote Data Exchange Protocol (RDEP), which is a proprietary HTTP and XML-based configuration and event generation messaging system. It employs "pull" mechanisms for event collection and analysis.
With Cisco IDS 4.0 Sensors, management and control functionality used an SSL-based XML messaging format for communication. Alarm notification from sensors still requires acknowledgement as it did with PostOffice Protocol. The RDEP protocol is TCP-based however, so it employs the reliability routines present in TCP as well. Because the transport uses Secure Socket Layer to encrypt communications, the protocol is secure.
The RDEP protocol is simpler and easier to manage than the PostOffice Protocol. It uses well-known TCP port 443 by default for quick firewall rule set modification. When configuring RDEP communications, administrators will need to provide a device name for the sensor, whether they intend to use encryption for communication, and on what port they wish to run the service.