Cisco Secure IDS

Overview

Cisco offers a compelling product line in the IDS and IPS space based on the availability of NIDS, HIPS, and strong software management capabilities. Cisco refers to its product line as the Cisco Intrusion Detection System (IDS), made up of the various NIDS and HIDS solutions offered. Given the wide acceptance of Cisco’s technology solutions, many real-world organizations (businesses, governments, universities, and others) have found effective solutions using the Cisco product line. Further, recent improvements to deployment options and the acquisition of the leading host-based, intrusion-prevention provider Okena show Cisco’s commitment to being a significant player in the IDS/IPS space.

Cisco focuses on four goals in its product line:

• Accuracy
• Enabling Investigation and Response
• Comprehensive Management
• Flexible deployment

The “current” (at press time) Cisco product line includes appliance-based NIDS, modules compatible with many routers and switches, and software-based solutions for certain releases of the Cisco IOS. These combine to create a flexible offering that allows each organization to tailor the product offerings to meet their needs. The CiscoWorks VPN/Security Management Solution (VMS) version 2.2 manages all the different platforms. Prior to the release of the 2.2 version of VMS, Cisco had been working to consolidate the number and type of management solutions for the suite of products. In most cases, Cisco has acquired technology for its IDS/IPS line. Each acquired product has had its own management software, which Cisco has integrated under the CiscoWorks umbrella. Cisco Threat Response (CTR) is a new software solution released last year by Cisco. CTR enables investigation by quickly assessing victim hosts to determine if they’re vulnerable to attacks they’ve received. CTR adds an automated investigation component to the product mix.

The Cisco IDS Sensor 4200 series are appliance-based network equipment carefully constructed for fast and efficient networking monitoring to enable detection and response. The hardware is Intel-based PCs, with fast Pentium processors, and large amounts of RAM and disk space. The products support up to five monitored interfaces, while always using a separate interface for command and control. The 4250 and 4250 XL support fiber interfaces, while the rest of the product line supports standard Ethernet (copper).

Cisco produces the Cisco Catalyst 6500 Series Intrusion Detection System (IDSM-2) Services Module. This module is again a PC style appliance, but Cisco designed this option on a board that allows it to integrate into the 6500 series chassis in exactly the same way a module with fast Ethernet ports is integrated. This module runs the same codebase including the same Red Hat Linux based kernel and uses a Pentium 3 processor with a 232 MHz IXP 32-bit StrongARM policy processor on the built-in accelerator. Currently the IDSM-2 is rated for 600 Mbps of monitored traffic. From a pure software perspective, the IDSM-2 is identical to the 4200 sensors.

Cisco’s offering for its routers include hardware modules and an IDS feature set implemented in software. This software feature set allows the router to monitor for 59 unique attacks. Cisco chose which signatures based on factors such as severity and real-world likelihood. The IDS feature set allows the router to take real-time action once it discovers an attack. It can take three actions: alarm, drop packets, or reset a TCP connection. This creates the option for a proactive defense in situations where little protection was previously unavailable. The router modules are once again an Intel chip with Linux, and the same code as the appliance and switch module.

The recent addition of the Okena product line as Cisco’s Security Agent (CSA) is a significant step forward for the network equipment maker. The CSA enables the host-level implementation of a fundamental security strategy: “That which is not expressly allowed, is denied.” This means that product enforces a strict policy governing the actions of a particular piece of software, where the normal activities of the application are allowed, and everything else is denied. This is an example of an anomaly based approach to IPS. Cisco has integrated the CSA management software into the CiscoWorks VMS 2.2 allowing for even greater advantage of the common management platform.

The VMS platform version 2.2 represents the first time that Cisco allows control from a single product suite, including control of VPNs, routers, and network- and host-based IDS. CiscoWorks VMS 2.2 allows configuration management, monitoring, device inventory, and software release (version) management features. VMS 2.2 allows administrators to configure network, switch, and host IDS sensors, and can also capture, view, and report on events from these IDS sensors, as well as from Cisco PIX and Cisco IOS devices. More importantly, one can obtain notification of events and alarms. In the near future, the Threat Response module will allow automated investigation. Current CTR is a stand-alone product offered as a free beta.

The VMS 2.2 suite runs on both Solaris- and Windows-based infrastructures. IT managers typically view deciding between platforms as a challenge in some organizations. Selecting the platform that will be easiest to support is best, as the best-operated management center will also produce the best-operated infrastructure. For organizations already standard on Windows or Solaris, it’s best to continue with the platform of general choice. For large enterprise environments where excellent support for either platform exists, experience has shown that Solaris is better suited for large installations, and security administrators can more easily secure that platform. Please note, minor differences exist between some the reporting and minor features in the releases across the platforms. Cisco documented these differences in the release notes, and we discuss them in the section “Collecting Requirements.”

Designing Your Cisco Based Solution

In every environment, several key factors contribute to the success of an IDS/IPS infrastructure. Many experts agree that the processes for infrastructure management and incident response are the most critical success factors. While these are clearly important, you can’t fully use these processes unless they’re applied based on a sound infrastructure. Given the wide adoption of the Cisco product lines in today’s enterprises, many organizations are making the choice to use a single vendor to product IDS/IPS infrastructure. Based on the mix of products and the strong support through the Technical Assistance Center (TAC), Cisco becomes a viable choice for a single vendor solution.

The best place to start the design process is with a clear plan. We generate this plan typically from stated goals or objectives and combined with requirements. Determining up front how you will use the IDS/IPS system is important. In some environments, they provide detailed, near real-time records of current network activity. Other environments want the infrastructure to provide proactive defense leveraging capabilities to block attackers and stop malicious activity as soon as possible. Often overlooked is how to divide operational responsibilities for the maintenance, use, and operation of IDS/IPS infrastructure.

Collecting Requirements

Accurate requirements can be difficult to collect in many organizations. Table 9-1 contains example requirements that can be used to drive this process. This table discusses specific areas requiring careful consideration. Analysis of these requirements will allow the proper design and implementation.

Table 9-1: IDS Best Practice Requirements

Area	Component	Intrusion Detection Requirements IDS System Characteristics	Where Cisco's Product Line Stands
IDS system characteristics	Comprehensive set of intrusion signatures	Signature-based IDS systems suffer from a fundamental flaw. They only identify events that can be described (in detail) before they take place. However, the majority of intrusion detection systems operate by recognizing signatures of network attacks. These signatures can describe the details of violations of network protocols, packets destined for suspicious ports, the presence of particular byte sequences in the data payload of a packet, suspicious packet sequences, and so forth. The number and type of signatures available is a key requirement of an IDS system.	Cisco has a comprehensive set of signatures developed by its Cisco Countermeasures Research Team (C-CRT). The C-CRT is made up of engineers from the WheelGroup acquisition. They develop signatures based on years of experience in both commercial and government roles.
IDS system characteristics	High performance on sensors	The IDS sensors must be able to process packets at a rate fast enough to keep up with network load. If the sensor becomes overloaded, it might begin to drop packets, and those dropped packets could lead to a significant increase in false negatives. Therefore, it's important to build network sensors capable of handling the traffic load on the segment they'll be monitoring.	Cisco offers a comprehensive product line with solutions to fit most needs. This includes stand-alone appliances, router and switch modules, host-based intrusion prevention, and integration into existing Cisco infrastructure.
	Capability to create custom filters	One might want to identify specific events of interest for which monitoring is required, but public-domain activity signatures don't exist. The capability to create custom filters gives us the capability to record and analyze these events.	Cisco provides the capability to create highly detailed custom signatures through a comprehensive wizard.
IDS system characteristics	Acceptable false-positive and false-negative rates	While this rate (ratio of false positives to false negatives) is entirely dependent on the type of network traffic seen by the IDS, managing these failure rates is essential. The false-negative rate can be reduced through a well-designed engine that recognizes a large number of attack signatures. The false-positive rate can be reduced through an engine that supports threshold tuning and well-defined filters.	Cisco's TAME is a leading engine based on years of development. In addition, Cisco offers customization of all signatures to increase accuracy.
Architecture	Network-based IDS component	Network-based IDS places a crucial role in appropriately covering an environment. Network IDS is best at covering aggregated network segments, places where different portions of a network architecture meet.	Cisco offers several options for network-based deployment with flexible options for integration into existing infrastructure.
Architecture	Host-based IDS component	Host-based IDS provide protection of critical assets. Host-based IDS (HIDS) takes advantage of the existing processing on each host process, packet, and data stream, adding a small overhead for inspection. Typically, these operate at the kernel layer of a host, and are given an excellent vantage point into attempted operations on a host. Because network-based IDS must account for the multiple ways that hosts reconstruct network traffic, HIDS holds a distinct advantage in terms of accuracy.	Cisco's acquisition of the Okena product line provides best in class host-based intrusion prevention for Windows, Solaris and (soon) Linux.
Architecture	Distributed architecture	The most common (and most effective) design for an IDS is that of a distributed system, with remote sensors deployed throughout the network, a central data collection facility, and one or more analyst consoles on the analyst's desktop.	Cisco offers a highly scalable distributed system for event processing from detection to alerting and response.
Architecture	Communication architecture	In a “push” communication architecture, the sensors feed their data into the analysts console as events of interest are identified. This gives us a near real-time intrusion-detection capability. This is in contrast to a “pull” communication architecture, in which the analyst console polls the sensors periodically for newly identified events of interest.	Cisco has recently switched from a push-based to a pull-based architecture.
Analysis support	Intrusion reporting, response, and recovery policies and procedures	The IDS is a tool that will provide a skilled analyst with the information needed to identify network intrusion attempts.The analyst is ultimately responsible for decisions regarding response and recovery. The use of software to automate these steps, however, is attractive in some scenarios. To ensure these actions are carried out in a manner both consistent and acceptable, specific policy elements should be implemented to govern response and recovery.	Cisco offers a comprehensive set of reporting and response options. These are the free Event Viewer and CiscoWorks VMS. Also, Cisco is automating investigation with the release of the Threat Response software.
Analysis support	Integrated console and database for host- and network-based components	An integrated console and database provides several advantages to the intrusion analyst. The integrated database gives the analyst the capability to do thorough event correlation through database queries, reducing the need for manual correlation. The integrated console allows the analyst to identify and respond to alerts from a single interface, improving the efficiency of their work.	CiscoWorks VMS 2.2 offers the capability to manage events from all Cisco IDS products, including the Cisco Security Agent and the Network IDS.
Analysis support	Significant drill-down capability to provide detailed information on demand	A well-designed IDS console will provide basic information at first glance, and allow the analyst to “drill down” to important details. On request, the IDS should give the analyst significant and complete data for analysis and classification of the event.	Cisco provides drill-down capability all the way to captured packets from attacks. Views are customizable and filterable to ensure the right data is presented.
Analysis support	Relational database back end	An RDB back end can be queried, giving the analyst the capability to mine the IDS data for trends, patterns, and detailed information about events of interest. A database back end can also be used for building reports and archiving data.	Cisco uses a MySQL backend for the Event Viewer with export capability.VMS uses an MS SQL run time (a.k.a. MSDE) back end.
Analysis support	Report generation capability	IDS should give the capability to create reports. This capability, directly from the system itself, removes the requirement to add additional software to the solution. The system would ideally provide some canned reports and should offer the capability to create customized reports.	Cisco provides comprehensive reporting in both the Event Viewer and VMS products. These features are maximized on the Windows version of the CiscoWorks Monitoring Module. Some areas aren't supported on Solaris yet. There's no support for events from the Management Center for Cisco Security Agents, version 4.0. Also, the Cisco IDS Network Module for routers IDS version 4.1 isn't supported, but IDS 4.0 is supported. No additional reports are available for firewall and Cisco Security Agents. Also, there's no support for saving the preferences of column ordering in the Event Viewer on the Solaris version.
Analysis support	Well-built analyst console	A well-built analyst console is important. A console that isn't reliable and robust can render the work done by the sensors. Advanced features for distributing administration responsibilities and required access are also important factors in the construction of the console.	The VMS console is a mature product with a world-class software-engineering group developing it. CiscoWorks VMS offersCentralized Role-Based Access Control (RBAC).
Analysis support	False-positive management	False positives can be a time-consuming failure mode for the intrusion analyst. To combat this problem, the IDS should offer a mechanism for false-positive management. Common techniques include adjustable alarm thresholds and console enhancements to facilitate information management.	Cisco offers fully tunable signatures and alarm thresholds.
Analysis support	Event correlation capability	Network activity that triggers IDS alerts could be more than a traffic anomaly or a single attack. Some of the events of interest identified by the IDS might, in fact, be part of a coordinated (possibly distributed) attack. The IDS should offer tools to identify any correlation in these events of interest. If the back end is a relational database, then this correlation can be done through database queries. If the back end isn't a relational database, it might be possible to achieve this correlation through custom scripts or other techniques.	Cisco's Security Monitor (part of VMS's Monitoring Center) supports basic event correlation. It does this by allowing the analyst to leverage the Event Viewer, the Event Rule, and Reporting subsystems.
Analysis support	Database stores raw data	The database should store be able to store completed packets. because complete packets providee a much more powerful trend analysis/correlation capability particularly as new features are added.	Cisco's network IDS products have the capability to perform packet capture when a signature fires. This means that the entire packet or stream of packets can be analyzed at a later time when required.
Internal (IDS) security	Encrypted traffic between sensor and console	Because IDS management traffic is the “key to the kingdom,” the capability to protect this data is crucial.	Cisco's RDEP uses SSL/TLS to protect network communications.
Internal (IDS) security	Hardened agent and console hosts	The IDS is a key component in the defense of the network. If the IDS is easily compromised, not only do we lose this critical piece of our security solution, we run the risk of the IDS giving up valuable information about the network environment. To mitigate this risk, we must protect ourselves from attacks against the IDS itself. An essential component of this protection is hardening of the OSs on machines hosting IDS sensor and console components. These hosts should be completely dedicated to their IDS functions, running nothing other than that required by the IDS software.	Cisco provides the capability to use the CSA to protect the VMS station. The network IDS line is difficult to attack on the network because it doesn't have an IP address.
Response and recovery capabilities	Intrusion response capability	An attractive approach to intrusion response would be for the IDS to generate a real-time “recommended response” to a detected intrusion. This assists the analyst in quickly responding to intrusions, but provides the opportunity to sanity-check the response to avoid disaster.	Cisco is adding the threat response software to automate investigations and speed response. With the highly accurate data this produces, response options are clear.

Defense in Depth

Designing the solution is the combination of applying the technology to the existing infrastructure, while considering the requirements generated. Cisco has defined its SAFE Blueprint for designing, implementing, and tuning a Cisco-based IDS/IPS solution. The reference architecture presents an excellent guideline and you should consider that starting point for a sound design. The SAFE Blueprint breaks down the components of a corporate network into modules. Each module is a self-contained set of infrastructure (routers, switches, firewalls, IDSs, and so forth) working together to perform a specific network function. Modules are mixed together to build an enterprise network.

The SAFE blueprint recommends placing network IDS sensors at

• Corporate Internet Access
• Remote Access
• Major LAN Interconnections
• Server Farms
• Management LANs
• Extranets and DMZs
• Data Centers/E-Commerce

In choosing where to start first, you should consider factors such as criticality of assets, robustness of design, and accessibility of assets. While Assets deemed to be critical infrastructure because of their business value clearly will benefit from IDS deployment, systems not processing millions of dollars of transactions aren’t likely to be first in line for protection. You’ll want to consider the robustness of design, meaning the protections already in place when deciding between assets. Systems already built to withstand attacks might not be in urgent need when compared to systems without protections, such as network firewalls and application proxies. Accessibility of assets is a key measure of the level of risk. Systems not exposed to large portions of internal networks could present a lower risk profile. Clearly the converse is true: highly critical systems, systems you haven’t built to withstand attacks, and systems connected to large numbers of networks or the Internet need IDS protection.

Packet Capture Options

The Cisco Network IDS product line is no different from any other NIDS product, in that it can only detect attacks in traffic that it can “see.” This means capture must be given to monitoring interface using techniques like adding a hub, using port mirroring, or using a tap.

Management and Operations

In general, three options exist for managing a Cisco IDS infrastructure: local interfaces (web and command-line access), CiscoWorks VMS, and third-party tools. Most organizations will find that overall management is best accomplished using a clearly defined suite of tools and not relying on any single tool to be the best fit in all situations. While the Cisco Security Agent requires the use of CiscoWorks VMS, the NIDS products (4000 series, router modules, and switch modules) can be managed either locally or remotely.

For local management, this means two options: the command line interface (CLI), which Cisco revamped as of version 4.0, and a local web interface called the IDS Device Manager (IDM). For Cisco IOS-based solutions, Cisco provides management via both CLI and VMS. In all but the smallest deployments, CiscoWorks VMS will be required to achieve the best possible results. In particular, this will decrease the amount of time spent tuning individual sensors or sensor groups by allowing changes to be applied to groups of sensors. third-party software tools mostly concentrate on pulling events and alarms from the sensors.

Event Viewer

Cisco also provides the Event Viewer application for small installations. The Event Viewer is capable of remotely pulling data from Cisco NIDS products, such as the 4200 series and IDSM-2 running 4.0 or later. The Event Viewer allows quick and powerful analysis of the status of events analyzed by the IDS infrastructure. The Event Viewer is a powerful tool that contains drill-down capability down to view captured packets from real attacks.

The Event Viewer presents both real-time reports of activity and historical viewing of data. The primary mechanism for helping sort through this data is the use of filters. You can create filters to match particular sets of events based on characteristics such as Severity, Source or Destination Address, Signature or Sensor Name, or Time and Status. When you create filters, it’s important to document what filters you created and what purpose they serve. This assists in the response process because incident handlers can reliably understand the context of events from the IDS system. Typically, organizations develop a set of filters over time that meet their needs, so it’s equally important to ensure that documentation is kept current.

Some typical filters that we’ve found to be useful in separating data are as follows:

• Using Source and/or Destination Address to isolate systems serving a particular function, such as Enterprise Resource Planning (ERP) or E-Commerce.
• Using Source and/or Destination Address combined with Signature Name to look for signatures of attacks when a particular set of systems is known to still be vulnerable.
• Using Time to help isolate a specific series of events noticed in other data, such as firewall logs or Syslog events.

The Event Viewer enables the use of customized Views to control what data is displayed related to a specific event. Because the Event Viewer can display over 40 data elements for a single event, it’s important to customize what information is displayed to allow accurate analysis. The Event Viewer ships with the following five default views:

• Destination Address Group Shows events sorted by Destination Address (typically the victim host). This allows quick analysis to determine which machines are most significantly under attack.
• Sensor Name Group Shows events generated by a specific sensor. This shows where in the network the IDS sensors are finding attacks. This enables comparisons that can validate assumptions, such as that Internet-connected networks are more dangerous.
• Severity Level Shows the alarms sorted by criticality.
• Signature Name Group Shows activity sort by specific Signature names. This is extremely useful during widespread attack, such as during worm outbreaks.
• Source Address Group Shows activity by source address, typically attacking hosts. This can be compromised or infected hosts.

Network IDS

The centerpiece of the Cisco lineup is the IDS built around the Threat Analysis Micro Engine (TAME) and its accompanying policy language. Cisco has unified the underling code base in version 4.0 across all the NIDS deployment options. This means you can expect similar features and performance from all the product line. This solution is widely considered simply as “signature based,” but Cisco has identified that it uses a hybrid approach to combine different detection techniques to achieve maximum results. Primarily protocol decodes are used because of the number of Cisco's signatures that have been written this way.

Heuristic-based signatures are the second most-often used. Cisco uses pattern matches almost as much as heuristic-based signatures. Cisco doesn’t currently use classic anomaly detection (in its NIDS product line) outside of protocol anomaly detection but, let’s remember, this is only protocol decoding. Cisco doesn’t use anomaly detection primarily because it hasn’t found a solution it views appropriate for its customers. Clearly, Cisco’s R&D team will continue to look for better ways to detect malicious activity and examine all avenues.

System Features

Cisco NIDS offer the capability to capture packets, log, and alert events, and to take proactive action to stop attacks. The Cisco NIDS can capture packets for historical records, troubleshooting, and forensic analysis. The primary function for IDS in the eyes of many people is to log an alert on events, so the incident response process can initiate quickly. Clearly the capability to take proactive action by resetting connections (session sniping) and blocking attacking devices (shunting) is a powerful tool in the protection of critical infrastructure.

The NIDS can capture packets either when firing signatures or when manually configured to find packets associated with a particular IP address. For either scenario of starting a packet capture (a.k.a. IP Log), a specific number of bytes, length of time, or a specific number of packets binds it.

Assigning Packet Capture to Signatures

All signatures can result in IP Logging. This includes Cisco provided signatures or custom-developed signatures. To configure the Cisco NIDS to start an IP Log for a specific event, the signature parameter “EventAction” must to set to “Log”. Because data is exchanged via XML-based RDEP, this is accomplished by a specific name/value pair. In this case, “EventAction=log”. Using the IDM, you can configure from the screen Configuration |Sensing Engine | Virtual Sensor Configuration | Signature Configuration mode. From this screen, you must drill down to the specific signature in question.

Let’s assume you want to add an IP Log for all the times there are fail logins to a critical HTTP server.

First, start by selecting Service HTTP from the Signature Configure Mode screen. Next, drill down and click the check box next to the line number for signature ID #6256 HTTP Authorization Failure. Then, select Edit across the bottom. Now, you’re presented with the screen for Signature Configuration. From here, change the EventAction to Log by selecting that menu item.

Session Sniping and Shunning

Instructing the IDS to take proactive action is sometimes considered a controversial topic. IT managers cite concerns on the impact of false positives. In many cases, this is a valid concern and certainly must be addressed. You learn about reducing false positives in the section “Tuning.” Assuming these concerns have been appropriately addressed, let’s discuss how these features work.

Session Sniping is a method of stopping attacks by closing the TCP session associated with that attack. The Cisco NIDS accomplishes this by sending a TCP RST (reset) packet from the command and control interface to the identified attacking host and to the victim or target host. For this to work properly, it’s important to ensure that the IDS command and control interface (typically interface 0) have IP connectivity (be able to route packets) to the attacker and victim hosts. In particular, if network firewalls are in the path, it could be difficult to implement this without changes to the policy applied to the firewall.

Shunning is the process of applying access control lists (ACLs) to nearby routers or switches to block individual connections or hosts to stop attacks. Cisco supports shunning on all IOS devices, the Catalyst 6500 line, and the PIX firewall. This is enabled by configuring the IDS Sensor with a user name and a password to specific devices where ACLs will be applied (see Figure 9-1). This must be carefully configured and managed in concert with other tools, such as configuration management and troubleshooting.

Figure 9-1: Cisco’s architecture diagram

TAME

Cisco’s architecture for the Network IDS products is based on the TAME microengine. The TAME microengine processes individual engines for different traffic types. These engines are a comprehensive set of network protocols used today, and they encompass network, transport and application levels, as shown in Table 9-2.

Table 9-2: Microengine Details

Engine	Description
ATOMIC.ARP	Analyzes ARP packets both individual packets and groups.
ATOMIC.ICMP	Analyzes ICMP packets for the following parameters Type, Code, Sequence, and ID.
ATOMIC.IPOPTIONS	Analyzes IP packets for IP options in the layer 3 header.
ATOMIC.L3.IP	Analyzes layer 3 IP headers.
ATOMIC.TCP	Analyzes TCP headers for these parameters: Port, Destination, Flags, and single packet Regex.
ATOMIC.UDP	Analyzes UDP headers for these parameters: Port, Direction, and DataLength.
FLOOD.HOST.ICMP	Detects ICMP floods for a single victim.
FLOOD.HOST.UDP	Detects UDP floods for a single victim.
FLOOD.NET	Detects multiprotocol floods for a single victim subnet.
OTHER	Available for changing common parameters to groups of signatures.
SERVICE.DNS	Protocol breakdown for DNS service.
SERVICE.FTP	Protocol breakdown of FTP service.
SERVICE.GENERIC	Cisco recommends for expert use only.
SERVICE.HTTP	HTTP protocol breakdown based on a string engine. Includes capability to normalize URLs.
SERVICE.IDENT	Analyzes the IDENT service.
ERVICE.MSSQL	Analyzes Microsoft SQL.
SERVICE.NTP	Protocol decode of Network Time Protocol.
SERVICE.RPC	Analyzes the RPC service.
SERVICE.SMB	Cisco's SMB SuperInspector signatures. Cannot be used in custom signatures.
SERVICE.SMTP	SMTP protocol decode.
SERVICE.SNMP	Analyzes SNMP packets.
SERVICE.SSH	SSH header decode signatures. Cannot be used in custom signatures.
SERVICE.SYSLOG	Analyzes syslog messages.
STATE.STRING.CISCOLOGIN	Analyzes Cisco Login's ( via telnet).
STATE.STRING.LPRFORMATSTRING	LPR protocol decode.
STRING.ICMP	ICMP-based string search engine.
STRING.TCP	TCP-based string search engine.
STRING.UDP	UDP-based string search engine.
SWEEP.HOST.ICMP	Detects a single host performing discovery ICMP.
SWEEP.HOST.TCP	Detects TCP port scans.
SWEEP.MULTI	Detects cross-protocol sweeps.
SWEEP.OTHER.TCP	Detects fingerprint scans.
SWEEP.PORT.TCP	Detects port sweeps for a pair of hosts.
SWEEP.PORT.UDP	Detects UDP port sweeps between two hosts.

Signatures

Cisco’s IDS sensors work by examining network traffic against its knowledge of malicious traffic types. Each time the sensor finds a match, the sensor takes an action, such as logging the event or sending an alarm to IDS Event Viewer. Sensors enable you to modify existing signatures and define new ones. Cisco ships a comprehensive database of signatures. While you can’t delete or change the names of built-in signatures, you can disable them. Cisco enables most signatures by default.

A signature can be made up of several variants known as a subsignature, which allows parameters for the subsignatures to be modified without affecting each other. Changes to event action such as log vs. shun will affect only the specific signature (or subsignature) being modified.

Cisco provides a comprehensive capability to create your own signatures. The sensor will be assign them to a specific ID range (2000) and are flexible to model nearly any known traffic type. Custom signatures use the same engines as the built-in signatures. This enables you to create signatures that work as well as the Cisco shipped database.

Sensor Models

The current lineup of IOS sensors includes the 4200 series of appliances, as well as IDS modules for routers and switches. The 4200 series are stand-alone appliances built as effective IDS sensors. Currently, Cisco offers four models: 4215, 4235, 4250, and 4250-XL. Sharing similar PC-based platforms, they offer increasing amounts of performance and support for gigabit interfaces, although only the 4250-XL supports 1000 Mbps performance. All come standard with a single command and control interface, and one monitoring interface.

Table 9-3 provides a brief comparison between models.

Table 9-3: 4200 Series Options

Feature	4215	4235	4250	4250-XL
Performance rating	80 Mbps	250 Mbps	500 Mbps	1000 Mbps
Max Ethernet monitoring interfaces	5	5 (with support for gigabit)	5 (with support for gigabit) Use of all Ethernets eliminates capability to support fiber	1 (with support for gigabit)
Max Fiber monitoring interfaces	0	0	1	1

The performance ratings for each assume packet sizes of 445 bytes for TCP-based connections, but the ratings for the 4250-XL assumes 595 byte packets. These assumptive packet sizes might not be realistic for many network environments, however, this doesn’t mean they’re inaccurate. One clearly prudent planning step would be to analyze packet sizes and network use before deploying the IDS sensors. Also, Cisco provides a dropped-packet signature that alarms when the IDS drops packets. This signature can be used to monitor for overloaded sensors. As with all signatures, it can be applied to any model, including the router and switch modules.

Catalyst Switch Module The IDSM 2

The IDSM-2 is the module for the Catalyst 6500 line. You can use it in any of the entire 6500 line of switches. It takes up one slot and you can use multiple modules in a single chassis. B The IDSM-2 can be expected to operate identically to the 4200 series. The main difference is this: the IDSM-2 is able to acquire packets directly from the switch backplane using VACLs. One common misconception is that the IDSM-2 monitors all packets going through the switch. Instead, you must tailor your VACLs to monitor the traffic that required IDS detection. Because the ISDM-2 offers 600 Mbps of performance, careful consideration to what traffic it monitors is required to prevent overloading. The IDSM-2 can push ACLs for blocking to the switch that hosts.

When the IDS is oversubscribed, it will drop (not process) individual packets. These packets will, most likely, be part of TCP streams and affect context for most signatures, as well as the capability to normalize data. Because you cannot control what traffic can be dropped first with the sensor, avoiding oversubscription altogether is important. Because oversubscription is a significant concern in many environments, you can take several steps to avoid it. First, you can enable Cisco’s SigID993. This signature fires when dropped packets reaches a high-enough rate. The default for this signature is to fire on any percentage higher than zero. Typically, you want to monitor for anything over the zero level, and take action as it approaches 5 percent or higher. Because the IDS sensor family uses the same code throughout, oversubscription is handled identically across the product family.

Router Modules

One of the newer additions to the Cisco product line is the Cisco IDS Network Module for the Cisco 2600, 3600, and 3700 series routers. These modules provide “IDS on a card,” which can be deployed in existing Cisco routers. Given the wide deployment of these routers, this presents an attractive option in many cases. Because Cisco has unified the code base, once again, exactly the same features are available from the router modules as from the 4200 sensors and IDSM-2. The router modules support significantly less performance (as low as 10 Mbps in the 2600XM and 45 Mbps in the 3600), so this isn’t an issue because these routers aren’t typically passing more traffic than these ratings. These cards include a 20GB hard drive.

Router and Firewall Sensors

Cisco rounds out the product line with software-based solutions for its IOS routers and Firewall IOS. This software supports a subset of signatures (total of 59), however, it uses the same TAME-based architecture. Cisco selects signatures from its database, enabling you to customize which of the available signatures to apply.

Alerting

In versions below 4.0, Cisco used the PostOffice Protocol (POP) to exchange messages between the IDS sensors and management platforms. Cisco replaced POP with Remote Data Exchange Protocol (RDEP). RDEP is an XML-based protocol that uses a subset of HTTP/1.1 for network communications. RDEP is a major shift from POP because it changes from a push to a pull method of data exchange. This means management stations “subscribe” to feeds from the sensors, and “pull” or request updates. This places the responsibility to ensure alerts are received on to the management platform. Cisco does support backward compatibility, so version 4.x managers (such as VMS) can pull events from 3.x sensors. Cisco requires that older managers be upgraded to support 4.x sensors.

Tuning

Tuning your IDS infrastructure is a critical step to ensure it operates effectively. Tuning consists of taking steps to adjust the configuration to ensure the right data is analyzed and, when it is analyzed, that it’s analyzed correctly. Issues like false positives, false negatives (missed attacks), dropped packets, and data overload must be considered together to devise an effective tuning strategy. Tuning can be a time-consuming process, however, the author found in several scenarios that it’s significant enough to warrant concern. The author’s experience shows 80 percent of most tuning efforts happen during pilot or test phases of a new IDS system and ongoing tuning activities can either be a small portion of a daily administration process or bunched into weekly, or even monthly, analysis sessions.

The following process shows the typical lifecycle for tuning your IDS:

1. Select signatures
2. Adjust signature properties
   • Parameters
   • Severity
3. Eliminate traffic
4. Monitor and reevaluate

Signature Selection

Depending on the type of network and network traffic expected, not all of the 3000+ signatures in Cisco’s Network Security Database (NSDB) make sense to apply. Signatures that detect vulnerabilities that cannot exist in the environment are the first candidates. For instance, attacks specific to Solaris infrastructure might not be of interest. Although the first reaction of many is to consider that any attack is meaningful, when tuning the IDS to provide clear data, some compromises must be made.

Cisco enables the selection and deselection of groups or individual signatures. Because some signatures have subsignatures (IE variants on a specific attack), reviewing the subsignatures also makes sense. Some environments might not expect certain protocol types, such as ICMP traffic or HTTP traffic. This allows quick elimination of these protocol types. (I know you’re still worried you’ll miss attacks, but don’t worry. You’re managing risk!)

Adjust Signature Properties

One of the greatest strengths in the Cisco NIDS product family is the capability to tune signature properties easily. With roughly 30 editable properties for each signature, the capability to customize signatures creates a powerful tool to increase accuracy. Each signature can be customized to change its behavior, such as changing the AlarmDelayTimer to a longer value to increase the sensor’s capability to consider events with a long delay between them. That capability is crucial to look for events such as slow port scans.

Signature Properties Detail

Table 9-4 is a review of the properties in a typical signature from Cisco. Some of these properties go all the way back to the NetRanger product aquired from the WheelGroup. Cisco appears to have taken a solid foundation from the WheelGroup and expanded it over time.

Table 9-4: Configurable Engine/Signature Properties

Property	Information
AlarmDelayTimer	Time in seconds to wait to continue inspection after an alarm is generated. Used either to make sure a single event isn't lumped in with multiple events or used to lump multiple events together. Think two failed logins vs. ten: sometimes two matter, but, sometimes, only ten matter.
AlarmInterval	Amount of time to consider firing a signature-related events, such as, – “Fire this signature for five hits in AlarmInterval ten seconds.”
AlarmSeverity	The preassigned severity of the signature.
AlarmThrottle	This parameter is for limiting alarm firings. You can select “FireAll” to send all alarms; “FireOnce” to send one alarm, and then start the inspecting again; “Summarize” to send alarms at the rate prescribed in “IntervalSummary”; or “GlobalSummarize” to send a GlobalSummary alarm.
AlarmTraits	Signature-specific value for extra information about the alarm.
ChokeThreshold	Value used to determine when the AlarmThrottle action should be taken.
Enabled	Used to tell the sensor to apply the signature.
EventAction	Determines which action (Log, Reset, ShunHost, or ShunConnection) the sensor should take. A Log event is stored for events Reset, ShunHost, and ShunConnection.
FlipAddr	Use this when the traffic that fired the alarm is response traffic from the host being attacked. The IDS would normally show the source address as the attacker, however, this signature allows this to be reversed when needed. One example is looking for a directory listing on a DMZ that should support a custom web application. If the web application never needs to send a directory listing, seeing one could mean a compromise occurred. A custom signature looking for a directory list, when fired, would show the attacker as the web server unless you use the FlipAddr property.
MaxInspectLength	Here you can control the number of bytes that need to be inspected.
MaxTTL	This can be used to configure signatures that look for patterns over time. This can enforce a global limit when inspecting a series of events.
MinHits	This sets the low-water mark for hits to cause a signature to fire. Many times MinHitswill be set to one but, for instance, when looking for port scans, setting MinHits higher can be useful to decrease false positives.
Protocol	What type of traffic does the signature inspect?
ResetAfterIdle	Length of time (in seconds) for a signature to reset counters after watching traffic go idle.
ServicePorts	Used to specify ports (or lists of ports) to inspect for a signature. Comma-separated for lists.
SigComment	Comment/Info.
SIGID	Number used to identify signatures. 993–19999 is used for Cisco shipped signatures. 20000–50000 used for custom signatures.
SigName	Name used for signature.
SigStringInfo	Text information sent with alarm.
StorageKey	Used to determine how to store persistent data.
SubSig	Subsignature ID number.
SummaryKey	Defines the type of storage used for the signature.
ThrottleInterval	Used to control the throttling of alarms. Defines the duration of an AlarmThrottle event.
WantFrag	Seldom used parameter to determine if a fragment is needed. Can be set to True, False, or ANY.

The first step in tuning your IDS is to manage the amount of traffic “seen” by the sensor. This is important to perform first because the IDS cannot send an alert on traffic it doesn’t see. Next, you need to address normalization. Normalization is the process used by the IDS to ensure it reconstructs packets the same way the target systems do. Finally, individual parameters are changed or “tuned” to improve accuracy and reduce false positives.

The most basic decision to make in choosing which traffic the sensor monitors is placing the sensor. It’s important not to oversubscribe the sensor by attaching it to networks carrying more traffic than the sensor is rated to handle. This is particularly important when using the module for the 6500 family of switches. These switches can handle significantly more traffic than the module itself.

Cisco provides the capability to reconstruct or normalize traffic by host type. Cisco’s 4.1 sensors support Windows NT, Solaris, Linux, and BSD. This can be applied using the Device Manager and selecting Configuration | Sensing Engine | Virtual Sensor Configuration | IP Fragment Reassembly. On this screen, you can select the reassembly mode.

The last step in this process is changing signature parameters. Because this will vary widely for signature types and different networks, following a consistent generalized process is best. First, examine an alarm to determine why the sensor issued it. Many times, alarms are considered false positives without fully understanding the signature that matched the traffic type. Read Cisco NSDB and analyze the traffic. Next, consider the need for the traffic itself. Many times. traffic that is the result of a misconfigured system matches a signature and causes an alarm. The last step is to identify the specific pattern that matched the signature and decide to change the signature itself. Sometimes it’s best to change severity, but not to change the underlying signature.

Cisco Security Agent

Cisco has added the Cisco Security Agent (CSA) as Cisco’s in-house entry in the host-based intrusion prevention space. This product comes from the acquisition of the Okena System. CSA is widely considered to be extremely effective protection. In the wake of the Blaster worm, many companies have turned to CSA to protect critical hosts. With the capability to lessen the impact of these worms, many companies have found CSA to be well worth the investment.

Endpoint Protection

In the past few years, it’s been apparent that signature-based products on the endpoints are no longer sufficient in protecting against the increasing amount of malicious code circulating in the wild, including viruses, worms, and malicious mobile code. These types of technologies also forced you to use numerous different agent-based technology, such as personal firewalls, host intrusion detection (HIDS), file integrity products, and malicious mobile code products. Also, the OS had to go through a rigorous hardening process.

The CSA is a behavior-based approach to security. This single agent is proactive compared to the reactive nature of signature end-point security, for example, Virus Scanner and Host IDS. CSA protects your endpoints, that is, laptops, desktops, and servers from known, new, and unknown attacks. The technology looks like all the products previously mentioned because it has this functionality built in already.

The CSA currently supports NT, Windows 2000, and Solaris 8 (64 bit) on servers and NT, Windows 2000, as well as XP Corporate Desktop (Professional). The CSA MC is part of Cisco Works VMS 2.2 management solution and supports up to 5000 agents.

All agents are created and maintained on the management console (CSA MC). All the rules and policies are enforced locally on the agents. The agents contact the MC at their appropriate polling interval, which you can set, anywhere from ten seconds to once a day. They also send the logs back to the MC in case they’re experiencing an attack.

Kernel Mode

The CSA agent gets installed in kernel mode, which is similar to your standard antivirus products and VPN drivers. The kernel itself has no modifications, it only has a module loaded. When an application or process wants to do something, such as open a file or establish a network connection from A to B, it must go to the kernel and ask for resources. The application that’s running in user mode is making a call to the kernel that’s in kernel mode. This call is funneled through the CSA shims, which are similar to print drivers or VPN drivers. These shims then forward the calls to the CSA rules engine, which makes allow or deny decisions based on your rules and policies.

System Shims

The CSA agent has numerous shims placed to make sure it can look at all these calls.

• Lower-level network shim at the NDIS layer This is the shim that protects your hosts against network-/IP-based attacks like ping scans, syn floods, malformed IP packets, and any other RFC-type violations.
• Network shim at the TDI layer This is the shim in charge of the interaction between applications and the network. This is the personal firewall-type functionality, that is, which application is allowed to talk to which IP address over which port.
• File shim The shim watches for file and directory access. The agent provides you with File Monitoring, as well as with File Integrity, ensuring important files can’t be changed.
• Configuration shim This shim watches the registry for read or write access, as well as access to configuration files, such as the rc files or any other files in /etc on Unix.
• Execution space shim The execution space interceptor is worth an explanation. While this doesn’t refer directly to a specific resource like file or network, it deals with maintaining the integrity of each application’s dynamic run-time environment. Requests to write to memory not owned by the requesting application are detected and blocked. Attempts by one application to inject code (for example, by injecting a shared library like a DLL) into another are also detected and blocked. Finally, buffer overflow attacks are detected as well. The result is this” not only is the integrity of dynamic resources like file system and configuration preserved, but the integrity of highly dynamic resources, such as memory and network I/O are also preserved.
• HTTP shim This shim uses dataset variables (strings of data) to match against Uniform Resource Identifier (URI) information in a HTTP request either to allow or deny the action. These datasets can include the following:
• Known exploits classes
• Association of metacharacters (“or”)
• Specific attacks against web servers

The CSA ships with predefined datasets that you can use out of the box or change to your environment. New ones can also be added.

Proactive Security on the Endpoint

New and unknown attacks need to be stopped cold, as do new variants of old, known attacks. This introduces an interesting problem on your endpoint. Can you keep up with all the patches and updates mandated by the OS and application vendors? And are you ready for the next zero day exploit or virus? This dependence on reactive technology is causing considerable grief and has cost many companies millions of dollars.

The CSA introduces a security paradigm shift from reactive signature-based technology to proactive intrusion-prevention technology. The agent uses policies and rules to ensure good behavior is allowed and bad/malicious behavior will be stopped. It also can enforce your corporate security policy. You can make sure the employees can do their work, but you can prevent them from downloading or installing software, as well as prevent them from listening to music or watching videos at work. You can also enforce application control: instant messenger applications are allowed, but only Yahoo! and, within that instant messenger application, you can only use the chat functionality, but not the file transfer, e-mail, or audio/video features.

Security functionalities include the following:

• Application Related
  • Application run control
  • Executable file-version control
  • Protection against code injection
  • Protection of process memory
  • Protection against buffer overflows
  • Protection against keystroke logging
• Resource Related
  • File access control
  • Network access control
  • Configuration access control
  • Execution space access control
• Control of Executable Content
  • Protection against e-mail worms
  • Protection against automatic execution of downloaded files or ActiveX controls
• Network Related
  • HTTP filtering to remove bad behavior before it gets to the web server
  • Connection rate limit where you can make sure your server only receives so many connections in a certain timeframe from a single host or from all the hosts Outbound limitations as well
• Detection
  • Packet sniffers and unauthorized protocols
  • Network scans
  • Monitoring of OS event logs

Implementation—A Safe Approach

The CSA infrastructure is already part of Cisco’s SAFE architecture. Make sure the MC is deployed in a physically safe environment because it’s the key to the kingdom. As with any other security product it is important to have a deployment strategy, this deployment strategy includes getting familiar with the product by evaluating it first, deploying it in test mode, and then, when you’re satisfied, putting it in production.

Installation

Insert the Cisco Works VMS 2.2 CD into the drive. If autorun is enabled, the installation will begin automatically. If not, go to My Computer and double-click the CD. VMS 2.2 provides you with the management capabilities for IDS, PIX, and VPN Routers, as well as the CSA agents. We suggest you install the CSA MC on a separate machine. You must install both the Common Services and the Managing Cisco Security Agents. After you install the Common Services, the Managing Cisco Security Agents installation prompt you for the typical information, such as what directories to use. It will also install and configure the Microsoft SQL Server run-time engine (MSDE) for you.

In case you already have Microsoft SQL Server installed with Service Pack 3, the CSA will use that. At the end of the installation, the VMS/CSA MC agent will be installed to ensure utmost security. Because SQL has been the center of attention lately with the SQL Slammer exploit, the suggestion is that you fully patch the SQL server with the latest security patches and hotfixes. Remember, the agent service will protect the SQL Server from being exploited, so it’s good security practice to be fully patched.

System Requirements for the VMS 2.2 Installation

These are the system requirements for the Windows version of the VMS platform.

• Minimum of Intel Pentium 1 gigahertz or higher and up to two processors
• 1 gigabyte of RAM Memory (more memory will give you better results)
• 1 gigabyte of Virtual Memory
• 9 gigabytes of HDD Space
• 1 NIC Card only

Getting Started

1. Log on to VMS2.2 by going to Start | Programs | Cisco Works | Cisco Works
2. Acknowledge the certificate
3. Type admin and your password in the login prompt
4. Click VPN Security Management Solution (VMS2.2)
5. Click Management Center
6. Click Security Agents

The CSA MC will open a new window in your browser. Let’s examine the interface and the options available. Table 9-5 gives an overview of each option and how it can be used.

Table 9-5: Overview of Menu Options

Monitor	Status Summary	Quick Network overview. This view shows you the alerts, the active agents, and the agents that need to be updated or haven't polled.
	Event Log	The Event Log displays a snapshot of the current events.
	Event Log Management	This option lets you manage your event log by setting up jobs to delete old events you no longer want.
	Event Monitor	This is the same as Event Log, but it cycles every 15 seconds to give you the latest event information.
	Alerts	You can have alerts sent to you via pager, e-mail, or SNMP.
	Event Sets	Event Sets are information you want to be alerted about, such as Trojan events or mission critical events.
System	Groups	Groups are setup by functionality, such as HR or web servers. See the following for more information on groups.
	Hosts	When a host registers with the MC, it appears in this view. You can click on it and get detailed information about the host as to what OS, which groups it belongs to, and so forth.
Configuration	Policies	The CSA ships with over 30 policies for applications that are commonly used. You can use these or add new ones. The default policies are a great start.
	Variables	These are variables. The CSA uses variables like $email-clients to make administration of policies easier. Instead of writing executables over and over, you use a File Set. File Sets include Applications, Registry, COM and Network addresses, and Services.
	Application Classes	Application classes are groupings of application executable files that you combine under one name, generally as part of a File Set Variable.
	Application Class Management	You can manage all your Application classes here.
	Global Event Correlation	The CSA has built-in event correlation for network scans, potential worms, Event Log messages, as well as antivirus events.
Maintenance	Audit Trail	The audit trail keeps track of all changes that were made and who made them.
	Export/Import	The Export/Import feature lets you move data from one MC to another by exporting the data and importing it on the other MC.
	Registration Control	The MC can set restrictions on who can register with the MC. This is done by IP addresses.
	Agent Kits	The CSA ships with pre-built agent kits that can be deployed. You can also create new ones from groups you created.
	Software Updates	You have two options: Available Software Updates and Scheduled Software Updates. After the management console is upgraded or updated, this new version will display under Available Software Updates. You then schedule updates for the agents under Scheduled Software Updates to execute when this is convenient for you.
	License Information	You can see your licensing information here, as well as apply a new license if you made additions.
	Backup Configuration	Backing up your database is important because all your information is saved in the SQL database.
Profiler	Analysis Job	Create a new profiling job to analyze an application to create a new policy.
	Analysis Report	This provides you with a report of what the profiler has seen, for example, what files were accessed, which network ports were used, and so forth.
Reports	Events by Severity	This report shows you all the events sorted by severity.
	Events by Group	This report shows you all the events sorted by group.
	Host Detail	This report gives you the host detail, name, OS, and which groups and policies it uses.
	Policy Detail	This report gives you a detailed list of all the policies.
	Group Detail	This report gives you a detailed overview of all the groups.
Search	Hosts	You can search for specific hosts here.
	Groups	You can search for groups here.
	Policies	You can search for policies here.
	Rules	You can search for rules within policies here.
	Variables	You can search for Variables, such as File Sets, and so forth.
	Application Classes	You can search for Application Classes.
	All	This lets you search for everything.
Help	Online Help	Online Help will bring you to the help of where you're located right now. If you're in Policy creation, it displays step-by-step instructions on how to do that.
	Technical Support	This gives you the contact information for technical support.
	About…	Information about the agent for example, version is displayed.

Agent Kits

Agent kits are the actual binary that will get installed on the laptops, desktops, and servers. These agent kits contain groups. The CSA ships with predefined kits for you to use for both Windows and Unix systems.

To create new agent kits, go to maintenance, and then click on agent kits. Choose new and, when prompted, choose the OS for which you want this kit. Add a description and choose the groups you want to be part of this agent kit. Agent kits can be part of more then one group, that is, web and database server.

The agents are created on the MC, and then are deployed via your software distribution method of choice, such as logon script, ftp, Tivoli, SMS, CA, link to pull it from the MC or ghost images. Ensuring that the agent can talk to the MC over SSL is also important. Otherwise, it can’t register.

Groups

This is the streamlined process to assign policies to numerous hosts at once. These groups are collections of policy modules with specific behavior enforcement for the functionality of the host.

Make sure your group hosts according to the following criteria:

• System functionality, such as web or database servers. You would create a policy that corresponds specifically to the needs of your web and database servers, and distribute it to that group.
• Business groups, such as HR, finance, operations, security, and marketing. Tailor policies based on each business group's individual needs. Allow your security group to make its own decisions, but not your other groups.
• Geographical or topological location. For example, group hosts based on their subnet designation for reporting purposes.
• Importance to your organization. Place mission-critical systems into a common group to apply critical alert-level configurations to them.

Policies

Every corporate enterprise should have security policies in place. The policies you create on the CSA MC should enforce these guidelines. CSA ships with over 30 preconfigured policies you can use. Additional policies can be created manually, as well as via the profiler.

Table 9-6 shows a list of a few policies already included.

Table 9-6: Preconfigured Policies in CSA

Unix	Windows
Apache	Apache
IPlanet	IIS
IDS Systems	IDS Systems
Default Server	Default Server
Mission Critical System	Default Desktop
Sendmail	Restrictive DNS/DHCP

Rules

Rules give you control over all the different shims. They make sure good behavior is allowed and bad behavior is stopped. Table 9-7 lists the types of rules you can create.

Table 9-7: Rules to Create

Agent service control	Controls who can suspend security, as well as turn off or uninstall the agent. Options are Administrators, everyone, or a certain application.	Unix and Windows
Application control	Enforces which application can start another application.	Unix and Windows
COM component access control	Controls which application can access COM objects.	Windows
Buffer overflow	Controls specific buffer overflow. Windows has built-in control.	Unix
Connection rate limit	Creates a rule that enables you to limit how many concurrent connections from a single host or from all the hosts it can receive. This also works for outbound traffic.	Unix and Windows
Data access control	Lets you filter out behavior before it hits the web server.	Unix and Windows
File access control	Creates rules that controls read and write access to files. You can control the download or installation of any file.	Unix and Windows
File monitor	Monitors for file changes.	Unix and Windows
File version control	Enforces which versions are allowed to run on the endpoint. IE version 6.2 is allowed, but not the next beta release.	Unix and Windows
Network access control	Controls which application can act as a client or server talking to what IP addresses over what service.	Windows
Network interface control	Controls whether an interface can be put in promiscuous mode.	Unix
Network worm protection	Protects against worm damage and propagation.	Windows
Network shield	Protects against network-based exploit, such as malformed IP packets, and so forth. This is a built-in rule under Windows.	Unix
NT Event log	Enables you to control which event log information you want to collect.	Windows
Resource access control	Controls access to system resources.	Unix
Registry access control	Governs which application can read or write which registry keys.	Windows
Rootkit/Kernel protection	Protects against root kits and kernel modification.	Unix
Service restart	Lets you have services, such as IIS, to restart automatically, in case it doesn't respond to the user or the system.	Windows
Syslog control	Enables you to control which syslog information you want to collect.	Unix
Trojan detection	Controls which applications can trap keystrokes, execute code from memory, and so forth.	Windows

Rules are enforced by six different action levels, as shown in Table 9-8.

Table 9-8: Action Levels

Add Process to Application Class	Priority 1
High-Priority Deny	Priority 2
Allow	Priority 3
User Query (Default Allow)	Priority 4
User Query (Default Deny)	Priority 5
Deny	Priority 6

Rules are created as follows:

1. Go to Configuration.
2. Go to Policies.
3. Choose a policy you want to add rules to or create a new one.
4. Click modify rules.
5. Click add.
6. Chose a rule from the drop-down menu.
7. Add a description.
8. Choose an action level from the drop down menu.
9. Only deny and user query rules are logged by default.
10. Choose application class, that is, network application, all applications (see Figure 9-2).

    
    Figure 9-2: The process of creating a rule

11. Depending on the rule you have chosen, make the appropriate choices.
12. Save and generate the rules.

These rules are automatically sent out to the groups they’re associated with.

Evaluation

Cisco provides you with an evaluator’s guide that shows you how to test this type of technology. This guide is available at http://www.cisco.com/en/US/partner/products/sw/secursw/ps5057/index.html. This will prompt you to log in with your CCO account. It’s important for you to test this technology completely. Make sure you use at least two desktops and servers, so you’re comfortable deploying these agents. You’ll quickly discover the difference between a personal firewall, an IDS, file integrity, and malicious mobile code product and the CSA technology. Understanding the defense in-depth that the CSA uses is important. Reactive products usually only use a single line of defense.

Train Learn

CSA offers you the capability to create custom policies for any applications. This could make such a system fairly complex. Because the default policies cover any application—store-bought or homegrown—you should start by using the default server and default desktop groups, make copies of them, and then create the agent kits you want to deploy. These default policies are what Cisco believes should be your basic security measures. Agents always should be deployed in test mode, which is a nonintrusive way of observing how the agent is going to impact your system. Instead of preventing the action, test mode lets you know what it would have done if it had been in prevent mode. You should run in test mode until you’ve adapted to your environment. After a few weeks of running in test mode, you can change to prevent mode.

Note

Always deploy in test mode first

The CSA also has an add-on product called the profiler, which lets you take any executable and run an analyzer against it. The profiler is a snap-in to the CSA MC that turns on functionality in the agent itself. It uses the same technology used to prevent the malicious behavior by using the shims (network, file, configuration, execution space) to collect all the behavior of the application, such as what network connections the application is performing, what files and directories it’s touching, which registry keys are read or written, and what COM objects were used during the run. That information is then analyzed and a policy is created that can be imported into the MC and deployed to the agents.

• Test Make sure you run all your applications to check if they trigger any of the default rules. Common mistakes are things like monthly backups get forgotten and denied because backup.exe tried to touch all the files. Check the event log periodically to make adjustments by using the wizard functionality. The wizard lets you create exceptions right from alerts that were reported to the MC.
• Promote to production After you run the agents in test mode for a few weeks (most people run it for two to four weeks in that environment), move a few machines in to prevent mode. Beware, though, because prevent mode is done by group. If you create agent kits with more than one group, if one group is in test mode, the agent kit will be in test mode. Let these systems run and observe them. When you feel comfortable, move the rest of the agents over to prevent mode.
• System maintenance The CSA doesn’t require constant changes and updates as you’re used to from other signature-based reactive technologies. There are no signature updates or pattern updates because this system doesn’t use any. Therefore, changes are much less frequent then you usually would see. These changes might include the following:
  • Configuration changes These types of changes are usually changes in your environment. A database server is now located at a different IP address, so the policy needs to reflect this change to make sure your web server now points to the new IP address. Other changes might be if you want to introduce a new application and you want to make sure it’s secure. The CSA MC includes over 30 default application policies of applications commonly used in the corporate environment, such as Microsoft Office, SQL, ISS, DNS/DHCP, Apache, IPlanet, and so forth. These policies give you more granular control over these applications.
  • Application patches Patches to the applications usually don’t require any changes made to the policies or rules. If you feel you need to make sure of that, run the profiler against the patched application. In that case, you can quickly see if something has changed.
  • OS patches Unless some fundamental changes exist, they don’t require you to make any changes to the policies and rules or the CSA agent code itself. Service Packs usually are tested by Cisco, and then officially supported in the next release. Service Pack 4 is officially supported in CSA version 4.01. No changes were made to the agent because of the Service Pack. You can install this OS patch in two ways: one is simply to turn the agent service off while you install it. The reason is the agent would prompt you because of the behavior of the patch-overwriting system files. The other way to install the OS patch is to create a job with the profiler. The profiler would analyze the patch as to what it does and how it behaves. After it finishes, you can then deploy this policy to all the endpoints before you patch. In that case, the behavior is expected.
• OS upgrades OS upgrades usually require changes made to the agents because some fundamental differences exist between OS releases. Changes from NT to Windows 2000 were quite fundamental, as are the changes from Windows 2000 to Windows 2003. The procedure for an OS upgrade suggests the agent kit be removed first, and then the upgrade be performed. At the end, deploy a new agent kit to the machines.

Agent Maintenance

The agent has two different versions of maintenance: one is a new version upgrade and one is patches. These upgrades are all made to the Management Server.

New Versions

Cisco releases upgrades periodically where it introduces new functionality, as well as new OS support. This happens about once a year. Version 4.0 introduced the following new functionality:

• Policies for CiscoWorks, VPN Client, Unity, Call Manager, and Personal Assistant
• HTTP shim
• Connection rate limiting
• Integration into Cisco’s SecMon

Patches

Patches are released as needed. Remember, no pattern or signature updates are necessary at any time. The CSA doesn’t use them.

• Upgrading the management server After a new upgrade or patch is released, you can go to www.cisco.com. Log in your CCO user name and password, and then download the new software. First, uninstall the agent running on the CSA MC. To upgrade the Cisco Security Agent, run the setup.exe file on the CSA MC system. When you run the setup file, follow the instructions that appear onscreen. After the installation is complete, install a new agent kit.

Application Forensics

The CSA offers security for store-purchased applications, as well as homegrown applications. By using the profiler functionality, the CSA enables you to create specific policies for that critical application you were worried about.

• Learning what your applications are “really” doing A great benefit of running the profiler against any of your applications is that it will tell you exactly what this application is doing. For example, you have a legacy application that was written for NT many years ago. The programmer left the job and you need to make sure you understand the application and that proper security is deployed. This is, indeed, a difficult task because that programmer probably used classes or modules from other programmers for functions that someone already created before him. This leaves you with many potential security holes. The CSA Profiler is a snap-in to the CSA MC. It turns on functionality in the agents to collect all the information about the behavior of an application. The CSA Profiler uses the shims the CSA technology uses to collect this data. After the data is collected, it’s then sent back to the MC for analyzing. A report is generated, so you can see all the different behavior, such as file access, network access, and so forth.
• Ensuring software performs are promised The profiler can also help you to make sure all the applications perform as designed. You could quickly see if an application is spawning off processes to start other applications or use COM objects to send out information over e-mail or IRC.

Patching

Patching has become an increasing nightmare. It’s a constant race to stay on top of the latest updates mandated by the OS vendors. Rolling out patches requires a strict change management control system to be in place.

• Take control of the patch process The CSA gets you out of the constant race of keeping up with patches. You can take control of the process by testing the patch rigorously before you deploy it out to the hosts, making sure you aren’t breaking anything. The behavior enforcement ensures these hosts are protected at all times.

Integration with Other Cisco Products

• SecMon The CSA agent has been fully integrated with the security monitoring offered by VMS2.2. This enables you to collect and view logs from your IDS devices and Pix firewalls, as well as VPN Routers and CSA agents. When you compare the network-related events to the events reported by the hosts, you can quickly analyze this data to see where threats came in.
• VPN Client 4.0 The CSA integrates with the Cisco VPN Client version 4.0. The initial integration currently offered is the VPN Client will check for the presence of the CSA agent. If the agent isn’t running, the VPN Client will be unable to establish a tunnel. Because of the nature of the CSA agent, you can ensure end-to-end protection by controlling which application on which server the VPN users are allowed to use.
• SIMS The CSA MC offers full integration with all the major Security Information Management Systems, including Netforensics, Microsmuse, Arcsight, and so forth. It can also forward any events to SNMP Collectors. These Security Information Management Systems try to support all vendors. They enable you to collect information for all different network devices, as well as different hosts agents.

Summary

This chapter focused on the Cisco product line of IDS products uncluding appliance-based NIDS, compatible modules for routers and switches, and software-based solutions for certain releases of the Cisco IOS. The chapter also covered the Cisco safe architecture and how it has evolved. We also examined implementation issues and how the products should be maintained.