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.


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 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 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.


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, 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



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).


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:



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



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.


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.


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



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

Part I: Product Overview

Introduction to Network Security

Product History

Hardware Overview

Part II: Firewall Solution

Initial Setup and System Maintenance

Network Access Control

IP Routing

Authentication, Authorization, and Accounting (AAA)

Application Inspection

Security Contexts

Transparent Firewalls

Failover and Redundancy

Quality of Service

Part III: Intrusion Prevention System (IPS) Solution

Intrusion Prevention System Integration

Configuring and Troubleshooting Cisco IPS Software via CLI

Part IV: Virtual Private Network (VPN) Solution

Site-to-Site IPSec VPNs

Remote Access VPN

Public Key Infrastructure (PKI)

Part V: Adaptive Security Device Manager

Introduction to ASDM

Firewall Management Using ASDM

IPS Management Using ASDM

VPN Management Using ASDM

Case Studies

Cisco Asa(c) All-in-one Firewall, IPS, And VPN Adaptive Security Appliance
Cisco ASA: All-in-One Firewall, IPS, and VPN Adaptive Security Appliance
ISBN: 1587052091
EAN: 2147483647
Year: 2006
Pages: 231 © 2008-2020.
If you may any questions please contact us: