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.

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.

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.

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.

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.

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.

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.

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

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.

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.