Tips for Testing An Intrusion Prevention System

By Cameron Sturdevant  |  Print this article Print


Re-Imagining Linux Platforms to Meet the Needs of Cloud Service Providers

Testing an intrusion prevention system is still as much an art as a science, although the science is slowly gaining ground.

Testing an intrusion prevention system is still as much an art as a science, although the science is slowly gaining ground.

eWEEK Labs' testbed for Top Layer Networks Inc.'s Attack Mitigator IPS 5500 combined an artificial, lab-created Internet connection with traffic carried by our ISP.

To get repeatable, comparable results, we also ran attack tools such as the open-source Nessus (www.nessus.org) on network devices while exposing them to the outside world. Using predictable attack traffic significantly speeds up proof-of-concept testing.

Effective testing of any IPS requires thorough knowledge of how an organization's network is configured, both logically and physically. It is as important to know the protocols, applications and services running on a network as it is to know the routers, switches, firewalls and servers that are connected to a network.

We invited Top Layer to send an engineer to our San Francisco Labs site to help us install and configure the two Attack Miti- gator devices we used in our tests. Because an IPS is meant to be used in a high-performance, mission-critical environment, it's not unusual to have vendor engineers involved early in the testing process. Security managers should expect to have at least several days of on-site support to ensure that the IPS is configured correctly.

Whenever possible, security managers should evaluate IPS devices in the environment in which they will be used. The listen-only mode of the Attack Mitigator and all the IPS devices we have tested allow the systems to operate with little to no noticeable impact on normal network performance. We think it's worthwhile to put the IPS in-line right away.

Click here to read more about IPSes.

After getting the IPS devices in place, it's advisable to let them run in listen-only mode for at least one week. When eWEEK Labs first implemented the Attack Mitigator devices, we ran them using mostly default rule configurations. We spent most of our time at that point viewing log files to see what traffic was coming in to the network and what was getting blocked by the IPS.

Whether you run IPSes in front of or behind firewalls depends on many factors. It's a good idea to work with the IPS vendor to determine the best configuration for your organization.

We decided to run the Attack Mitigator devices in front of our firewalls because we wanted the IPSes to perform the bulk of the security work in our network.

Check out eWEEK.com's for the latest security news, reviews and analysis. And for insights on security coverage around the Web, take a look at eWEEK.com Security Center Editor Larry Seltzer's Weblog.

Cameron Sturdevant Cameron Sturdevant is the executive editor of Enterprise Networking Planet. Prior to ENP, Cameron was technical analyst at PCWeek Labs, starting in 1997. Cameron finished up as the eWEEK Labs Technical Director in 2012. Before his extensive labs tenure Cameron paid his IT dues working in technical support and sales engineering at a software publishing firm . Cameron also spent two years with a database development firm, integrating applications with mainframe legacy programs. Cameron's areas of expertise include virtual and physical IT infrastructure, cloud computing, enterprise networking and mobility. In addition to reviews, Cameron has covered monolithic enterprise management systems throughout their lifecycles, providing the eWEEK reader with all-important history and context. Cameron takes special care in cultivating his IT manager contacts, to ensure that his analysis is grounded in real-world concern. Follow Cameron on Twitter at csturdevant, or reach him by email at cameron.sturdevant@quinstreet.com.

Submit a Comment

Loading Comments...