Cisco IPS Software Architecture

The Cisco IPS 5.x software was built based on its predecessor, CIDS 4.x. The architecture is similar to the 4.x software, but with several enhancements. This section provides a complete overview of the CIPS 5.x architecture while highlighting some of these differences.

One of the major differences of CIPS 5.x is that it uses the Security Device Event Exchange (SDEE) protocol instead of the Remote Data Exchange Protocol (RDEP) used in versions 4.x. SDEE is a standardized IPS communication protocol developed by Cisco for the IDS Consortium at the International Computer Security Association (ICSA). Remote applications such as Adaptive Security Device Manager (ASDM), IPS Device Manager (IDM), Intrusion Prevention System Management Console (IPSMC) and Cisco Security Monitoring, Analysis and Response System (CS-MARS) can retrieve events from the sensor through this protocol.

Note

ASDM/IDM IPS configuration and troubleshooting is covered in Chapter 19, "Firewall Management Using ASDM."

Cisco IDS Event Viewer (IEV) does not support 5.x events; however, it can still accept 4.x events. SDEE is not backward compatible with RDEP.

Another difference of CIPS 5.x over 4.x is its ability to run IPS operations in inline mode.

The major components of CIPS 5.x software include the following:

• MainApp
• SensorApp
• Network Access Controller (NAC)
• AuthenticationApp
• cipsWebserver
• LogApp
• EventStore
• Transactional Services for Security Device Event Exchange (SDEE)
• CLI

Figure 14-1 illustrates the main components of CIPS 5.x in correlation with the AIP-SSM.

Figure 14-1. CIPS 5.x Architecture Overview

 

MainApp

MainApp is responsible for several critical tasks in the AIP-SSM (as well as all other platforms that support CIPS 5.x software). These tasks include:

• Initializing all CIPS components and applications
• Scheduling, downloading, and installing software updates
• Configuring communication parameters
• Managing the system clock
• Gathering system statistics and software version information
• Cleanly shutting down/restarting all CIPS services

MainApp is initialized by the CIPS operating system and starts the CIPS applications in the following sequence:

1. Reads and validates dynamic and static configurations.
2. Synchronizes dynamic configuration data to system files.
3. Creates EventStore and the Intrusion Detection Application Programming Interface (IDAPI) shared components.
4. Initializes status event subsystem.
5. Launches IPS applications as stated in the static configuration.
6. Waits until an initialization status event from each application is sent.
7. Generates an error event identifying all applications that did not start, if all status events are not received within 60 seconds.
8. Listens for control transaction requests and processes them accordingly.

MainApp controls the CIPS software installation and upgrades. It also controls network communication parameters such as:

• AIP-SSM host name
• IP addressing and default gateway configuration for the AIP-SSM command and control interface
• Network access control list

MainApp manages the system clock (whether NTP is configured or not) and collects system statistics.

SensorApp

SensorApp is the application that is responsible for the analysis of network traffic, examining it for any malicious content. The packets flow through it from the Gigabit Ethernet network interface on the AIP-SSM which is directly connected to the Cisco ASA's backplane.

If the Cisco ASA AIP-SSM configuration is set for promiscuous mode, the packets are discarded after processing by SensorApp. If configured for inline operation, the packets will either be forwarded back to the Cisco ASA or dropped according to the defined policy.

SensorApp has two modules crucial for the operation of the AIP-SSM or any other device running CIPS 5.x:

• Analysis Engine Configuration Module (Virtual Sensor)
• Alarm Channel Module (Virtual Alarm)

The Virtual Sensor is the Analysis Engine Configuration Module, which handles the AIP-SSM configuration. This module interprets the configuration and maps it into internal configuration objects. Figure 14-2 illustrates both of these modules.

Figure 14-2. SensorApp Virtual Sensor and Virtual Alarm

In CIPS 5.x, a new protocol is introduced called the Intrusion Detection Configuration (IDCONF) protocol. This framework provides clean, consistent, and accurate signature definitions. This replaces the old IDIOM framework in previous versions. It supports multiple layers of parameters to ensure that a signature is defined in terms that are understandable and valid for the inspection engines. The Virtual Alarm is the alarm channel module, which is responsible for processing all signature events generated by the traffic inspector engine. The primary function of the Alarm Channel Module is to generate alarms for each event as it is passed. Event or alarm filters may be configured and will be processed by the alarm channel module, as illustrated in Figure 14-2.

Network Access Controller

NAC is the application that is responsible for communicating with the Cisco ASA or any other supported device while shunning (blocking) connections if the AIP-SSM is configured in promiscuous mode.

Note

Do not confuse this application with the Cisco Network Admission Control industry-wide initiative sponsored by Cisco to enforce endpoint security policy compliance to mitigate damage from viruses and worms.

One of the functions of CIPS NAC is to forward shunning information to other IPS devices on the network to collectively control network access devices. IPS sensing devices that perform this operation are referred to as master blocking sensors.

AuthenticationApp

AuthenticationApp, as its name suggests, is the process that controls user authentication on the AIP-SSM or any other device running Cisco IPS 5.x software. Additionally, it administers all the user accounts, privileges, Secure Shell (SSH) keys, and digital certificates, while also controlling what authentication method is used.

AuthenticationApp controls authentication when the user connects via Telnet, SSH, a session through ASA, ASDM, IDM, or IDSMC. This is illustrated in Figure 14-3.

Figure 14-3. AuthenticationApp Architecture

 

cipsWebserver

The CIPS web server (cipsWebserver) within AIP-SSM provides configuration support for IDM and provides support for SDEE transactions such as:

• Reporting security events
• Receiving IDCONF transactions
• Processing IP logs

ASDM is hosted and controlled by the Cisco ASA; however, it launches IDM, which uses SDEE to communicate with the AIP-SSM hosted by the CIPS web server. The CIPS web server supports HTTP 1.0 and 1.1 running Secure Sockets Layer (SSL)/Transport Layer Security (TLS).

LogApp

The AIP-SSM logs alert, error, status, and debug messages as well as IP logs. These messages and IP logs are accessible through the CLI and SDEE clients such as IDM, IDSMC, CiscoWorks Security Monitor, and CS-MARS. LogApp sends log messages with the following five levels of severity:

• Debug
• Timing
• Warning
• Error
• Fatal

These messages are written to the following file on AIP-SSM module:

/usr/cids/idsRoot/log/main.log.

Note

To access this file, you must be logged in with the service account. Instructions on how to create the service account are discussed later in this chapter, in the "User Administration" section. These messages are mostly used by Cisco TAC engineers for troubleshooting purposes.

Example 14-1 shows a sample of the information stored in main.log.

Example 14-1. The main.log File

-bash-2.05b$ more main.log

01Feb2005 20:44:49.643 0.001 cidwebserver[447] Cid/E errTransport WebSession::

 sessionTask(10) TLS connection exception: handshake incomplete.

01Feb2005 20:45:09.646 20.003 cidwebserver[4548] tls/W errWarning received

 fatal alert: certificate_unknown

 

EventStore

All IPS events are stored in the EventStore with a time stamp and a unique ascending identifier. Additionally, CIPS internal applications write log, status, and error events into the EventStore.

Note

IPS alerts are only written by the SensorApp application.

The EventStore is designed to store CIPS events in a circular fashion. In other words, when it reaches the configured size, the oldest events are overwritten by new events and log messages.

Note

In CIPS 5.x code, the EventStore is reduced to 30 MB from 4 GB in earlier code.

 

TransactionSource

SDEE and HTTP remote-control transactions are handled by an internal application called TransactionSource. It handles all TLS communications with external management servers and monitoring systems. TransactionSource performs basic authentication to remote management applications and monitoring systems. When an application attempts a remote-control transaction, IDAPI redirects the transaction to TransactionSource, as shown in Figure 14-4.

Figure 14-4. TransactionSource Functionality