In this section we will discuss NIPS technology. NIPS essentially breaks down into two categories:
In addition to these architectural classes, NIPS designers make a choice between two types of technology: general-purpose CPUs and application-specific integrated circuits (ASICs). General-purpose CPUs tend to be the easier choice from a development standpoint because you can build on a ready-to-deploy appliance such as the Nokia IP130. ASICs have the ability to support much higher performance because the chip can be optimized for a particular application. However, products built on ASICs require much more development. The good news is that a lot of the work has already been done; a number of off-the-shelf ASICs have been designed for TCP/IP processing. If a developer chooses an ASIC solution, he still needs to decide whether to implement a single ASIC "board-level" solution or a parallel implementation. If you can devote a processor to each IP flow, you have a massive speed and latency advantage. A single Adaptec TCP Offload Engine (TOE) ASIC can maintain sustained performance at rates above 900Mbps.
ASIC-based devices still have general-purpose CPUs. The performance increases only apply when processing can be done on the ASIC. If you have to signal the bus to transfer the packet(s) to the general-purpose CPU(s), the NIPS will probably suffer a significant drop in performance.
How Chokepoint NIPS Work
A chokepoint NIPS could be located outside of your firewall or on your screened subnet in front of a device you want to protect, such as your web server. They will often be configured without an IP address on either of the chokepoint interfaces to minimize their impact on the network's architecture. Traffic that originates from the Internet is passed through the NIPS to your corporate firewall and beyond if it does not generate any alerts. In IPS mode, traffic that does generate an alert can be dropped or rejected by the NIPS and never delivered inside your network. These can also be run in IDS mode, where a report is generated but the packet is not dropped. These tend to either be a "firewall plus something" or an "IDS plus something."
Firewall Plus Something
Firewalls fall into three major categories, listed in increasing security protection: packet filter, stateful, and proxy or application gateway. The overwhelming majority of deployed firewalls are stateful. Firewalls are the original IPS; the first time you heard the term intrusion prevention system you were probably wondering if the person was talking about a firewall. To be credible as an IPS, the firewall needs to add additional functionality, such as the ability to run IDS-type rules. Stateful firewall inspection has been a very strong technology for many organizations. The next logical progression for many firewall vendors is to add intrusion detection capacity to their firewalls. Because the firewall is an inline network device, it is in an excellent position to identify malicious events on the network, performing analysis at the transport through application layers to identify attacks. Because the firewall must collect and retransmit each packet that flows through it, a logical advancement would be to allow policy to define whether traffic identified as malicious should generate an alert and be forwarded to the destination or whether it should generate an alert and be dropped, thereby preventing the attack from being successful.
A fourth category of firewallscircuit firewallshas you authenticate once and then use a path through the firewall conceptually to nullify intrusion prevention. They were never widely deployed, so though it is doubtful you would find a large number of SOCKS protocol connections in your network, you might well find internal VPNs that are conceptually similar. It is okay to bypass a perimeter or chokepoint control as long as you have equivalent controls on both of the endpoints.
Vendors such as Cisco, Jupiter (Jupiter acquired NetScreen), and Check Point have been rapidly acquiring intrusion prevention technology for integration into their product lines, or they have been developing their own tools for the job. The resultant products are often classified as "smarter" firewalls instead of classic intrusion prevention devices, but we expect this trend to change as more organizations become comfortable with the term intrusion prevention as well as the benefits and limitations of the technology. Let's take a quick look at some of the firewall-plus-something implementations, including FireWall-1, Border Guard, and modwall.
Check Point FireWall-1 NG
Check Point's central product is FireWall-1, which is the best-known example of a "firewall plus something" positioned as a NIPS.
Check Point FireWall-1 NG has the following IPS features:
FireWall-1 protects network resources against attacks and unauthorized access at both the network and, increasingly, the application level. Enterprises attain this degree of security by defining and enforcing a single, comprehensive security policy. What makes Check Point stand out in the industry is the advantage of utilizing the Open Platform for Security (OPSEC), the most widely used application programming interface (API) of any security device. Instead of trying to be the best at everything, Check Point has focused well on partnering. Third-party products can access the Check Point security policy using the OPSEC Management Interface (OMI). Intrusion detectionstyle capabilities are available via the Suspicious Activity Monitoring Protocol (SAMP). Also, Check Point has been doing content inspection for years with the Content Vectoring Protocol (CVP).
Modwall was developed by Bill Stearns and is available from http://www.stearns.org/modwall. Modwall is a set of firewall/IPS modules that can be inserted into an existing IPTables firewall on Linux. Rather than focusing on the normal "allow this kind of traffic from here to here" firewall rules, modwall focuses on illegal packet traffic, which includes invalid or unassigned source or destination IP addresses, invalid TCP flag combinations, and packets that have been intentionally fragmented. Modwall then allows the administrator to define what action to take, including dropping the traffic, logging it, and blocking traffic from the source for a limited amount of time. Let's use the L (list rules) option of IPTables to examine the rules in the "address check" module (one of 38 modules in the package) as an example:
[root@sparrow modwall]# ./address start Starting address [root@sparrow modwall]# iptables -L address -n Chain address (3 references) target prot opt source destination DROP all -- 127.0.0.0/8 0.0.0.0/0 DROP all -- 0.0.0.0/0 127.0.0.0/8 DROP all -- 22.214.171.124/4 0.0.0.0/0 DROP !udp -- 0.0.0.0/0 126.96.36.199/4 DROP all -- 240.0.0.0/4 0.0.0.0/0 DROP all -- 0.0.0.0/0 240.0.0.0/4 DROP all -- 255.255.255.255 0.0.0.0/0
After it is started using the command address start (like IPTables, modwall also supports start, stop, and restart command-line directives), the following default address checks are performed on all non-loopback traffic (that is, traffic on all real network interfaces). Note the keyword DROP, which means just what you think: If the packet matches the rule, it will be dropped.
The first and second DROP entries drop all traffic found on the real network with loopback addresses. Note that 0.0.0.0 simply means the default network, whereas 0.0.0.0/0 would match anything, essentially serving as a wildcard. The reason the first and second entries are paired is to manage traffic in both directions (that is, the first one in the case of 127 in the source address and the second in the destination address). However, there is a very remote possibility this rule pair could have unintended consequences because 0.0.0.0 could also indicate a legacy broadcast. (In the early days of the Internet, BSD UNIX systems used 0 for broadcast.) However, that would mean the machine is very old.
In the third and fourth rule pairs, DROP is for network 224, which is multicast. Before you filter out multicast internally, you might want to sniff for a while and make sure you are not using it (some enterprise backup systems rely on it). The reason for !udp (meaning not UDP) is that UDP might legally multicast, but TCP should never multicast. Therefore, a safer rule, one that is less likely to cause a self-inflicted denial of service, might be this:
DROP tcp -- 0.0.0.0/0 188.8.131.52/
The fifth and sixth DROP rule pairs are for the IP addresses reserved for experimental applications (240).
The final rule is used to quench directed broadcasts.
The "firewall plus something" concept in intrusion prevention is here to stay. As time goes on, firewalls will continue to add packet-scrubbing functionality and decrease in latency as they benefit from Moore's law.
Moore's law is based on an observation by Gordon Moore from Intel in 1965. He said that computer processing capability would double every 18 months or so. It has proven to be remarkably accurate, and most analysts believe it will continue to hold true at least until the end of the decade.
Next we will take a look at another category of the early intrusion prevention devices: IDS plus something.
IDS Plus Something
The "IDS plus something" classification for IPS products refers to those vendors who have traditionally had strong IDS tools and have added active functionality to stop the activity that generates an alert before it is delivered on the network or executed on a host. An IDS plus somethingstyle IPS would generally be referred to as a NIPS, where blocking is done at the network level.
False-positive detects can be a nuisance with IDS technology, but they are a much more significant problem in IPS technology. A false positive from an IDS generates an alert that may be false, but the activity from the IDS is benign. A false positive from an IPS stops legitimate services from being delivered. This could be intended functionality of a production application on a database server or it could be a customer visiting your website. False positives in the IPS realm have a significant cost to the organization because they can ultimately lead to self-imposed denial of service on production resources.
IntruShield is an example of a commercial IDS plus somethingstyle of NIPS. In 2002, McAfee (McAfee was formerly named Network Associates) acquired the IPS company Entercept for integration into its product line. The Entercept product line merged with the IDS products previously available from Network Associates to offer both NIPS appliances and a host-based IPS suite of products to protect desktops and servers.
IntruShield is a chokepoint architecture that uses classic IDS signature and anomaly techniques to identify attacks. The standard product is shipped with a base rule set that can be customized. You can enable or disable features to best meet the demands of your network. A lot of work has been put into the IntruShield user interface, and it is easy to switch between IDS (passive) mode and IPS (active) mode.
A NIPS that is directly positioned against IntruShield is NFR's Sentivist appliance. Intrusion prevention is designed and built with a focus on three distinctive areas in this "IDS plus something" NIPS technology:
Sentivist's IPS leverages NFR's historical detection capability and advanced but difficult to customize signature engine to offer a combination of pattern-matching signatures, protocol anomaly detection, and heuristics. It is able to perform context-based detection of attacks via the use of OS or application fingerprinting techniques, a capability you should insist on seeing demonstrated before purchasing any NIPS.
Instead of blocking only by IP address or port, NFR Sentivist's IPS is able to block discrete attack traffic carried in the application layer. Fine-grained blocking should be enabled by attack type, by impact, or by a qualitative confidence score. Blocking by confidence score is critical because it allows the user to block attacks on the basis of a system's confidence that the detected event is truly an attack. Users can choose to calibrate the level of prevention appropriate to their risk tolerance.
NFR Sentivist provides resistance to self-inflicted DoS by using multiple techniques such as whitelisting and graceful session termination.
HogWash and Snort-Inline
HogWash was originally developed by Jed Haile and was the first to use Snort rules in a security gateway device. This development effort seems to have stalled, and the work is being continued by Snort-Inline. Rob Mcmillen was the next to lead the effort, hosted at http://snort-inline.sourceforge.net/.
With Snort 2.3, Snort-Inline became part of the Snort distribution. The huge new change is that Snort-Inline gets its packets from the kernel using IPTables instead of libpcap, just like modwall. The Snort rule language has been extended for three new types of rules: drop (standard IPTables drop and log), sdrop (silent drop, no logging), and reject, the noisiest rule (drop, log, forge a TCP reset or "ICMP Port Unreachable" message, as appropriate). Because it is open source and part of a wildly popular distribution, Snort-Inline will probably accelerate the understanding and acceptance of active response.
LaBrea Technologies Sentry
We end the discussion of external NIPS with a fascinating product that is neither a firewall or an IDS at its heart. Perhaps the best classification would be to call it a deception device. Sentry was developed by Tom Liston, author of the famous Code Red tarpit. At the time of this writing, this is primarily a proof of concept for an appliance that uses attempted connections to unused IP address space as an indicator of an attack. The logic is that any ARP request for an unassigned IP address can be considered hostile. Sentry responds by forging an ARP response, claiming Sentry is the IP address. It then uses a variety of techniques to tie the attacker up for as long as possible. It is fairly simple and would only cause a self-inflicted denial of service if its information about the unused address space is incorrect. Liston hopes to roll it out with an additional capability using an Internet Storm Centerlike correlation database so that whenever one of the devices learns about an attacking address or attack pattern, that information can be passed to all Sentries.
So far we have discussed chokepoint-style systems with roots as firewalls and similar devices with roots as IDS systems. We have also mentioned the use of a deception system. The fourth classification of NIPS is an intelligent switch you plug your network in to. This is probably the most effective of the NIPS products available on the market place today, making the best use of firewalls, IDS tools, and routers/switches, ideally in a single parallel-processing, high-performance, low-latency device.
These switches have enough processing power to do more than just enhance the performance of a network by preventing Ethernet collisions. Expect to see antivirus, traffic-shaping, load-balancing, and intrusion prevention in the network itself. Of course, this next generation of switches that use massive arrays of parallel ASICs to connect the internal and external segments of your network together are going to be expensive. By using many of the techniques employed by advanced NIDS tools, the NIPS device can identify events on the network that are hostile. Because of its position (inline with the traffic of your entire network), the NIPS device can stop the hostile activity from ever being delivered to the target system. This also strongly enhances anomaly detection and network learning because all the traffic passes through the switch.
Protocol Scrubbing, Rate Limiting, and Policy Enforcement
Sitting inline has some advantages that aren't always directly related to thwarting malicious attacks. In some cases, a NIPS device can be used to clean garbage from the traffic stream, thus reducing the overall network load. For example, a server that is attempting to close a connection with a workstation that has shut down may continue to send packets to the destination waiting for a response saying "I'm done." The NIPS tool can use intelligence to recognize that the conversation is finished and then either drop the traffic received from the server or send a spoofed packet to the server on behalf of the nonresponsive workstation to stop the traffic altogether.
Another feature of switch-type NIPS devices is the ability to use rate limiting to apply Quality of Service (QoS) mechanisms to network traffic. The administrator can identify traffic on the network that should receive higher or lower priority than other traffic, or he can limit the total amount of traffic from a particular network, host, or specific application. This feature is particularly useful when trying to manage throughput on Internet connections, where the administrator can limit the ability for a single application or host to consume all the available bandwidth for the organization.
Because the NIPS device is already classifying traffic based on application, administrators can use this functionality to enforce organizational policy to drop traffic from unauthorized applications. A common use of this feature is to stop the activity of peer-to-peer applications on the network. Because the switch type NIPS device already recognizes peer-to-peer applications, it doesn't require any additional processing requirements to apply the policy and drop the traffic, generating alerts to indicate the policy violation from a specific workstation.
Environmental Anomaly Analysis
What is anomalous with a given application or protocol in one environment may not be anomalous in the next environment. One organization may utilize a busy public web server farm, with hundreds of web requests per minute. Another organization may utilize a single internal-use-only web server for the finance department. If the finance department network receives hundreds of web requests per minute, that dramatic short-term change in network behavior would be considered anomalous for that environment, but not for the server farm.
One of the immediate benefits of this capability is the support of an active change control program. NIDS and NIPS tools alike can detect a new version of an operating system or application and raise an alert, or even modify the rule set to take the new information into account. This could help the operations administrators manage unauthorized change. Obviously, you can only process so many alerts, so this would be managed by the analyst or administrator to help determine where appropriate thresholds should be set. Because the NIPS device is simultaneously tracking connection state for thousands or even millions of connections, it can take a "broad perspective" view to detect anomalies that involve many connections across an entire enterprise.
In order for NIPS devices to be deployed as reliable, effective devices, they must overcome several challenges:
Let's examine each of these in turn.
Detection Capabilities and Evasion Resistance
NIPS devices must utilize the same techniques of traditional network IDS tools to reduce the risk of false negatives. At the same time, they have to be extraordinarily careful not to generate false positives on the network because these types of mistakes would lead to a denial of service condition. A NIPS device uses a combination of application analysis, anomaly analysis, and signature-based rules to identify events that are malicious on the network. Traffic that is identified as malicious is dropped and may also be logged for review by the analyst to ensure it should have been dropped. A switch-type, "bump in the wire" NIPS must also use many of the same evasion-resistance techniques, such as normalizing traffic employed by IDS to reduce the threat of attackers obfuscating data in an effort to bypass the NIPS's detection capability. After all, because the switch-based NIPS is going to see all the traffic, evasion techniques and attacks for which there are no signatures (zero day) are going to be the most successful tools for attackers. This is a significant challenge for the NIPS to overcome, and the end result is that for the near future it will not be possible for NIPS devices to have as many active signature as IDSs are able to employ in passive sniffing mode.
In order to detect the greatest number of attacks without false positives, effective NIPS tools use passive OS and vulnerability assessment, as you will see later in this chapter.
Because the NIPS is inline with network traffic, it represents a single point of failure for the network. NIPS devices must be as stable as a firewall or switch to gain market acceptance. They must also be resistant to malformed traffic and cannot break existing network protocols. This is a very similar risk to that of false positives by the NIPSif a NIPS cannot properly interpret traffic or should fail in any way, it causes a failure on the network and denies legitimate requests. These failures can be accidental (as in the case of hardware or software failures) or intentionally performed by an attacker executing a denial of service on a network. One of the critical design features to understand when considering the purchase of a NIPS is whether it is designed to fail open or fail closed, or if this is user configurable. If network availability is critical to your organization, you want to be pretty certain that if the NIPS application should crash, the switch part of the product continues to pass traffic.
NIPS devices must be able to keep up with the throughput of network traffic, and in modern networks that means Gigabit Ethernet speeds. It is important to understand how the device degrades when it reaches its limits. For instance, when switches reach their limits, they may simply cease to forward traffic to a spanning or monitoring port and concentrate their resources on their core function. With a NIPS, traffic forwarding may well be more important than monitoring or protecting.
Despite the requirements to use extensive analysis techniques on network traffic to identify attacks, the NIPS must also provide low latency for network traffic. Additional latency on traffic that is analyzed should be in the low millisecond range. In general, latency will prove to be the primary difference between higher priced solutions and more moderately priced solutions because the easiest way to reduce latency is by adding more ASICs in parallel.
The NIPS device must be secured against compromise because a compromised NIPS would give an attacker the ability to establish a man-in-the-middle attack against all the traffic entering or leaving the network. This is typically performed by configuring the NIPS without IP or MAC addresses on data interfaces, using a hardened operating system that resists common attacks, and using a secured management interface that strictly defines who is permitted to connect to and administer the system. Attackers will seek opportunities to break NIPS, whether using denial of service or to circumvent the protection the NIPS provides, so the NIPS device must be able to withstand any direct attacks.
Although not specifically an innovative advancement through NIPS technology, many NIPS vendors are looking for ways to properly classify and identity malicious activity with fewer demands on system processing and memory capacity. One technique is the use of a rule classification scheme to quickly sort through traffic in order to rapidly identify malicious events. Some vendors have coined the term multiresolution filtering for this technique, where simple analysis tests are first applied to traffic. The simple tests represent a portion of the overall detection capacity of the NIPS device, where a packet that matches a simple test is then processed using the more thorough tests.
For example, a NIPS device may require traffic to have data on the payload of the device for analysis. If this simple test fails (overall length packet header length = 0), the NIPS device does not attempt to further classify this packet and sends it onto the network. This way, the NIPS can reserve its available system resources for more complex analysis.
After applying the simple rules, the NIPS device proceeds to apply more rule sets of additional complexity, including the examination of packet header information, transport layer session state information, application layer session state information, context-sensitive string matches against the packet payload, application layer analysis, and, finally, complex regular expression matching. The NIPS device is able to quickly and effectively classify traffic using only the required processing to complete the analysis, thereby allowing itself to process additional traffic.
In order to help the NIPS identify false-positive traffic, vendors make use of passive analysis techniques to identify host operating systems, network architecture, and what vulnerabilities are present on the network. Three of the most well-known standalone tools for this purpose are P0f (available at http://www.stearns.org), RNA by SourceFire, and NeVO from Tenable Security, and they should be available to some extent on every NIPS. Figure 11.1 provides a sample analysis using the NeVO system. Once this information is gathered, the NIPS can use it to classify attacks against internal systems based on their operating system and vulnerabilities.
Figure 11.1. The screenshot shows the types of analysis data that can be captured and displayed by the NeVO system.
Increased Security Intelligence in the Switch Products
Switch-based, "bump in the wire" NIPS is a fast growing market segment, and there is no possible way to predict what all the players will do. By the time this book hits the marketplace, expect to see a large number of switch products with intelligence, ranging from antivirus and malware detection to network signature detection, from Symantec, TippingPoint, Enterasys, and Radware. All our efforts to get Cisco to share its plans have failed; however, between the existing Cisco Security Agent, the Network Admissions Program, and educational efforts to help network administrators get more security out of their existing IOS products, it seems certain Cisco will be a player. A subset of these products includes the true NIPS devices, which are categorized as wire-speed switches, have IPS capability, and, in general, are based on parallel ASICs. These products include TippingPoint's UnityOne IPS and TopLayer Attack Mitigator.
TippingPoint's UnityOne IPS
At the time this chapter was written, TippingPoint's UnityOne IPS product was currently the overwhelming market leader for a switch-type NIPS. It offers an inline NIDS that provides multigigabit performance, low latency, and multiple mechanisms to detect known and unknown attacks on the network. In addition to providing IPS features, UnityOne provides the ability to traffic-shape or rate-limit traffic for QoS measures. It also provides policy enforcement by blocking applications that are prohibited by your organization's acceptable-use policy (such as peer-to-peer apps, web mail, or instant messaging).
When the UnityOne device identifies malicious activity or activities that violate policy rules, the engine uses one of four available response mechanisms:
Whenever you are speaking with a vendor and he says, "We are the only company in the space that can provide X," it is always a good lead in to ask, "Why are you the only company in the space?" If the vendor cannot provide a good answer, you know the company is either marketing fluff or it has put in some silly feature that no one else finds important. However, sometimes you learn the vendor you are talking with has a patent or other legal device so that it is very hard for others to effectively compete with the company he represents. This may prove to be the case with switch-based NIPS. 3Com (TippingPoint) has applied for patent on a technology it calls a "Threat Suppression Engine," which uses massively parallel ASIC hardware to perform packet inspection on traffic. If TippingPoint is granted this patent and it withstands the almost certain legal challenge, it could really change the future of the NIPS marketplace. One unique twist is that 3Com (TippingPoint) implements the "looks like a duck, walks like a duck, quacks, so it must be a duck" logic in hardware. The UnityOne uses "vulnerability filters" that identify attack behavior, not just specific exploits or vulnerabilities. This way, TippingPoint is able to identify and stop some attacks that exploit applications in an observable fashionthrough buffer overflows, SQL injection, and other common exploitative techniques. TippingPoint sells a "Digital Vaccine" subscription service, similar to an antivirus subscription service, to its customers, who then receive regular updates for their UnityOne device so it can defend against emerging threats.
TopLayer Attack Mitigator
In the days before true gigabit IDS, TopLayer gained fame as the solution for high-bandwidth monitoring via load balancing. Like TippingPoint's product, this is a very fast box with high availability, hot-swappable components, parallel ASICs, and a price tag to match the performance. Attack Mitigator's roots are more from quelling distributed denial of service resource exhaustion and protocol anomaly attacks than a true IPS, but it certainly has the chassis to build on and, like FireWall-1, is very good at well-known, well-understood attacks. TopLayer calls its inspection technology TopInspect.
Switch NIPS Deployment Recommendations
Deploying a NIPS solution is a major project, and we recommend you begin planning for it now. Start off with reporting-only mode, study the false positives and negatives for your chosen solution carefully, invest the time in creating a sustainable process for configuration management, make sure Operations is a full partner in the process of NIPS deployment, and remember that your NIDS is still a valuable source of information.
Begin Budgeting Now
You will probably be strongly considering the next generation of switches with security intelligence sometime in the next two years. This is going to be expensive, so speak to your manager and see what can be done to plan for this expense in a technology refresh cycle.
Review Products in Report-Only Mode
Before you start using a NIPS device to start blocking attacks on your network, run the device in report-only mode. Use this information to identify what events the NIPS would have dropped on your network, and what the impact would have been to the network.
Work with Vendors Identifying Test Procedures for False Positives and False Negatives
Ask your vendor to detail its testing procedure for new rules and anomaly analysis techniques. Ensure the vendor uses a combination of "live" and "attack" scenarios at rates that are appropriate for your network environment before shipping you updates. Ask your vendor what techniques it uses to eliminate false-positive traffic, and how it exercises auditing to ensure it isn't missing attacks.
Be Wary of Absence of Auto-Update Mechanisms
In 2004, we saw a decrease in the time from a vulnerability announcement to the release of a worm. Instead of the month we were used to, the Witty worm was released three days after the vulnerability announcement. Because one of the main reasons an organization would consider the purchase of expensive switch NIPS is worm management, this makes being able to keep the device up to date with the latest signatures critical.
Be Wary of Auto-Update Mechanisms
The technology for automated analysis or signature database updates has been around for various products for a while, with NIPS vendors touting this feature for the ability to quickly respond to new threats. The ability to respond to new threats is certainly desirable, but with it comes the risk of poor traffic-identification patterns that lead to false positives on the network. Exercise caution when implementing such features, using organizational policy to dictate the tradeoff between the risks of new threats and the risks for dropped traffic.
Auto-update mechanisms ease the implementation and deployment of NIPS products but can assert a new set of challenges on your organization. Ask your vendor to support a mixed-reporting mechanism, where new rules are placed in report-only mode for a specified amount of time. This way, the organization can take advantage of existing functionality in the NIPS while the analyst has the ability to identify false-positive alerts or performance burdens that affect throughput and latency on the network.
Document a Change-Management Mechanism
Identify who should be responsible for managing updates to NIPS software, and how often the software should be updated. Include information about how the organization should react to updates based on new Internet threats, such as a new worm or other exploitative threat. Having this policy in place before a new threat emerges will define how well your organization will be able to leverage NIPS technology.
Expect the NIPS to Be Blamed for All Problems
Veterans of network security will remember that when they first installed a firewall, every time anyone had a problem, the firewall administrator's phone rang. A new product like a NIPS is potentially invasive toward network operations. At some point, someone in the organization is bound to experience a problem and cast blame on the NIPS device. The best way to mitigate this problem is to clearly document the use and functionality of the NIPS device and utilize the logging features that come with the NIPS to identify traffic that is dropped, shaped, or altered in any way. Over time, other people in the organization will come to understand the benefits and limitations of the technology, and they will accept the NIPS device as a critical security component for the network.
Use a Combination of NIPS and NIDS Where Appropriate
NIDS investments don't go out the window after a NIPS device is deployed. We can still leverage the technology of NIDS devices to aid in assessing threats, baselining attack statistics, and troubleshooting network problems with the addition of a NIPS device. After deploying a NIPS tool, many organizations focus their NIDS tools to monitor internal networks, to aid in identifying attacks that make it past the NIPS device, and to identify insider threats. We don't expect NIDS technology to go away anytime soon; instead, we expect the technology to continue to mature and add value to organizations that take full advantage of the functionality available.