1 Radware s Smart IDS Management FireProof and Intrusion Detection Systems Deployment and ROI North America Radware Inc. 575 Corporate Dr. Suite 205 Mahwah, NJ Tel International Radware Ltd. 22 Raoul Wallenberg St. Tel Aviv 69710, Israel Tel
2 Page Introduction A high awareness of security-related issues in the past year has caused organizations to allocate more of their IT budget to security-related issues. Of those budgets, Giga claims that 54 percent of security-related spending this year was allocated to intrusion detection. 1 While budgets exist, IDS deployment is considered difficult and costly because NIDS (see below) should be installed on every network segment. This makes deployment and management very complex, and requires medium and large organizations to potentially require tens or hundreds of sensors for their networks. In addition, currently available NIDS are unable to keep up with high network bandwidth. This document will give some background on Intrusion Detection Systems (IDS), the challenges in deploying them, and the benefits of Radware s IDS Management solution. 1 Giga, July 2002,
3 Page Introduction to IDS Deployment An intrusion detection system (IDS) is a software product or hardware device that is capable of applying the latest security or attack expertise to separate relatively few potentially destructive events from a vast amount of benign activity. There are two system-monitoring approaches, network-based IDS (NIDS) and host-based IDS (HIDS), explained below. Organizations generally choose a combination of these approaches, based on their perceived vulnerabilities. Network-based Intrusion Detection System (NIDS) Network-based IDS monitors all network traffic passing on the segment where the agent is installed, reacting to a suspicious anomaly or signature-based activity. NIDS analyze every packet on their segment for attack signatures. Some Network-based IDS are unreliable at high speeds, when loaded they can drop a high percentage of the network packets. There is a limit to the number of packets that a network intrusion detection sensor can accurately analyze for potential intrusions in a given period of time. The portion of network traffic volume that exceeds this volume threshold is subject to receive partial and often inaccurate intrusion analysis. The higher the network traffic level and the more complex the analysis, the higher the error factor and potential security breach may be. Host-based Intrusion Detection System (HIDS) Host-based IDS monitors activity confined to the local host on which they are installed, and can see in detail what the attacker does, be it command execution, file access, system calls, and the like. The HIDS can then react to unusual activity on that host. A HIDS is best equipped to see attacks directed towards a specific operating system or application. Typical IDS deployment The following two components are usually part of a typical enterprise IDS deployment: NIDS Sensors sit in strategic locations and listen to all the traffic passing by them and optionally take action based on pre-defined or dynamic rules. Deciding on the location of these sensors, and matching the sensor s capacity to the segment s throughput, is the major challenge of a successful IDS implementation. IDS Console is the back-end. This is where the data gets gathered, processed, and presented to the end user. HIDS Software is installed on vulnerable hosts for additional protection.
4 Page IDS Deployment Challenges Costs: Deploying one NIDS per network segment is extremely costly, as devices can start at $25,000. The costs do not decrease after deployment as licenses must be renewed annually, and are also costly. Capacity: Current NIDS are limited in the throughput they can handle. As NIDS are passive devices, packets dropped are not blocked traffic, but rather packets that the NIDS did not have the capacity to inspect. These un-inspected packets could compromise network security. Redundancy: Since one NIDS is deployed per each network segment, there is no ability to deploy a back-up. If that device fails, all traffic on that segment will not be inspected. Scaling: Since NIDS are installed in promiscuous listening mode, and all devices on a specific network segment will all listen to the same content, upgrades or increasing bandwidth require replacement of sensors instead of scaling. SSL-based communication: NIDS sensors cannot understand SSL-encrypted traffic, so that encrypted traffic is allowed to pass un-inspected, even though it may hide a malicious attack. Network performance: Installing a NIDS sensor on a network segment requires the addition of a hub for that segment, where traffic is routed through the hub, while the NIDS is connected promiscuously. Introducing a simple hub, a lower-mtbf component with lower performance than the network s high-performance switch, can degrade overall network performance.
5 Page IDS Management with FireProof Meeting the Challenges FireProof provides high availability, load balancing, traffic aggregation, and optimization for IDS sensors. By creating IDS farms, and managing them with FireProof, organizations can overcome the following deployment and performance challenges: Cost savings with efficient deployment. Organizations can use FireProof to reduce IDS deployment costs by aggregating several segments that require inspection, therefore reducing the overall number of IDSs needed. Inspection of SSL-encoded traffic. With the addition of a CertainT 100 to passively decrypt SSL communication, FireProof can forward decrypted traffic to the IDS sensors. Thus, the sensors are always able to inspect all traffic. This is the only solution available today that allows NIDS to inspect encrypted traffic, which they would otherwise leave unexamined. Cost savings by optimizing IDS performance. FireProof can be configured to filter the traffic copied to an IDS by several parameters, including source and destination IP, application, or content. This can reduce the amount of traffic copied to an IDS device by 20% to 40%, thus lowering the overall number of IDSs needed and further reducing deployment costs for the organization. Providing fault tolerance to all IDS sensors. By creating a farm, IDS sensors provide high availability and redundancy, so that all traffic is always inspected. Inspection of all traffic, even for high throughput segments. In high throughput segments, the IDS may be unable to inspect all the traffic, which means that security can be compromised. With FireProof, adding NIDS sensors to a farm provides all required scalability and ensures that all traffic for that segment is inspected. Optimizing IDS performance by distribution of traffic by application. FireProof can be configured to send certain types of traffic, such as HTML, to IDS sensors that are optimized to handle it, and therefore inspect it more efficiently, further reducing the number of sensors required. Simplifying network management. Centralizing the location of all NIDS sensors in a network, as opposed to installing a sensor on each network segment, eases and simplifies network management. Safe software upgrades. When on NIDS is down for maintenance or upgrades in a farm, other sensors are up and securing the network.
6 Page FireProof Configurations with IDS There are two possible ways to manage IDS farms with FireProof: In-line IDS load balancing. The advantage of this configuration is that FireProof can provide traffic management capabilities to firewalls and VPN gateways, as well as for the IDS sensors. In this configuration, the IDS farm is typically connected to the internal FireProof: Out-of-path IDS load balancing. In this configuration, FireProof is connected to one or more copy ports on the switch, and is fully transparent to the network elements so that there is no need for complex routing changes on the network. The IDS farm is connected to the out-of-path FireProof: FireProof Redundancy While setting up an IDS farm provides fault tolerance for IDS sensors, in order to eliminate a single point-of-failure, redundancy needs to be provided for FireProof itself. Redundancy is achieved by using two FireProofs, where the IDS farms, clusters and policies are configured identically on both the main and backup devices. Additionally, the physical ports used for each IDS sensor must be the same for both FireProofs. As the IDS devices used for each session are kept in the Client Table, enabling Client Table mirroring ensures the appropriate IDS sensor(s) will be used for each session. IDS devices can either be directly connected to physical ports of FireProof, or via hubs.
7 Page IDS Deployment with FireProof the SSL challenge Some companies mistakenly believe that SSL (Secure Sockets Layer) will mitigate all security risks. Although SSL ensures business transactions, SSL-based communication can inhibit other parts of a security strategy. IDS sensors cannot interact with SSL, so encrypted traffic is allowed to pass without question. 2 IDS sensors are usually deployed at network locations where the SSL traffic is still encrypted, usually closer to the network edge. However, since SSL traffic is decrypted only very close to the servers or on the servers themselves, it cannot be terminated at the point where the sensors are installed. Additionally, since they are deployed out-of-path, as sniffers, they cannot terminate an SSL session. However, since they need to understand the SSL traffic, it must be decrypted for them. These two restrictions will only continue to exacerbate the problem as the percentage of SSL traffic grows. Radware offers the only solution to this problem: CertainT 100, operating in passive SSL mode, decrypts all SSL-based communication for the IDS sensors without terminating the session, so that they can inspect every packet for malicious attacks. Radware s smart IDS management solution introduces the only passive SSL capability in the industry. To assist the IDS sensors in decrypting SSL traffic, a CertainT 100 farm is added to the FireProof, as in the diagram, below: FireProof receives network traffic and performs the following to optimize intrusion detection: Drops traffic that does not require inspection, such as packets from trusted sources. Sorts traffic according to configured policies, that define which traffic should be copied to which IDS farm. Thus each IDS sensor receives the type of traffic that it processes most efficiently. Forwards SSL traffic to the Passive SSL farm for decryption. Forwards decrypted traffic to IDS farms for inspection according to configured policies. In this manner, all traffic that needs to be inspected - is inspected, with unlimited performance, scalability, and guaranteed availability. 2 Cover Your Assets, Web Style July 2002,
8 Page ROI for Smart IDS Management FireProof optimizes IDS deployment and the management of an IDS solution. Without FireProof, IDS devices are required to be installed one device per network segment. Deployment can be costly as each IDS sensor can run to tens of thousands of dollars, and a typical enterprise switched network can require hundreds of sensors for full coverage. With the creation of an IDS farm connected to FireProof, traffic from multiple lower throughput segments can be aggregated to one IDS sensor, while multiple IDS devices can be deployed for the higher throughput segments. This allows for the deployment of devices according to the total throughput requirements and not based on a specific segment s requirement, thus bypassing the one-ids-per-network-segment restriction. Additionally, FireProof can be configured to filter the traffic copied to an IDS sensor by several parameters. This means that trusted traffic, such as traffic coming through the Virtual Private Network (VPN) gateway, or other high-volume but intrusion-free traffic, such as streaming media and bit images, do not need to be copied to the IDS for inspection. This can reduce the amount of traffic copied to an IDS device by 20% to 40%. For example, a typical network with 35 segments with a throughput of about 10 Mbps each, a FireProof deployed out-of-path and controlling an IDS farm provides an immediate Return on Investment (ROI) in the following manner: Assuming that each IDS sensor can handle 40 Mbps capacity and costs $25,000. Without FireProof, one sensor is required per segment, requiring 35 sensors in all, an initial investment of $875,000. With FireProof, aggregating all segments requires capacity for 350 Mbps, which can be handled by only 9 sensors. Optimization by filtering traffic to the IDS reduces traffic to IDS by 20%-40%. The number of IDSs can be reduced by 20%, bringing the number to 7 sensors. This requires an initial investment of $175,000. Cost of two Application Switch II FireProofs is $50,000 Total deployment costs without FireProof, the 35 sensors, are $875,000, while the total deployment costs with a FireProof are $225,000, which is the cost of 7 sensors and the two FireProofs. This is a savings of $650,000 during IDS deployment. Additional savings can be realized every time the network configuration changes. In the example above, every new network segment would require an additional sensor, a cost of $25,000. However, scaling up with FireProof is cost-effective, so that a new sensor is required for every four new segments, reducing scaling costs by a quarter. Finally, since annual licensing fees for IDS are expensive as well, reducing the number of sensors required for network deployment can reduce costs even for companies who have initially deployed an IDS solution without FireProof.
9 Page Selling Radware s Smart IDS Management Qualifying Script for IDS Deployment Generally, the benefits of an IDS management solution will appeal more to security managers in an organization. At the higher level, the ROI benefits of Radware s solution can be stressed, while for others, the technical benefits of solution may be more appealing. Some possible questions that can help determine the match between a potential client and the IDS management solution are: Are you concerned about malicious attacks on your network? Have you thought about implementing an intrusion detection system to block attacks? If so, what breadth of deployment have you planned? Do you have a budget for it? Are you worried about the high cost of deploying numerous IDS sensors? How many network segments do you have? Are you considering deploying IDS sensors on all segments? How do you set fault tolerance for each sensor in each network segment? Do you have any high-throughput (above 40 Mbps) in your network? Are you worried about leaving some segments under-protected because of IDS sensor throughput limitations? Are you worried about the scalability of your IDS deployment? Are you scanning SSL-encrypted traffic with your IDS sensors? Four Reasons Radware s IDS Management is better than the competition: As Radware is an innovator in IDS traffic management, the competition is scarce. No other vendor has any passive SSL solution, and Radware s only current competition in the IDS traffic management is Top Layer s IDS Balancer Top Layer s maximal capacity is 120 Mbps 3, as opposed to FireProof s 1 Gbps capacity. 2. FireProof can support up to 20 IDS farms, and route traffic to as many or as few of them as needed. Top Layer cannot make this distinction and can only route traffic based on load balancing criteria. 3. Top Layer does not have a solution for SSL traffic. 4. Top Layer s box can only perform IDS load balancing, while FireProof can also provide attack mitigation with DoS Shield and Application Security, thus freeing up IDS sensors to deal with the less popular signatures. FireProof can also provide traffic management benefits to firewalls and VPN gateways. 3 Pushing firewall performance December 2001, Boxes from TopLayer, Nokia and NetScreen each clocked at more than 120M bit/sec throughput with short packets and 200M bit/sec with long packets. TopLayer and Nokia edged out NetScreen slightly in peak performance with small packets, with a peak of 130M bit/sec each vs. NetScreen's 120M bit/sec peak performance.