This content is part of the Essential Guide: Evaluating intrusion detection and prevention systems and vendors
Get started Bring yourself up to speed with our introductory content.

Intrusion detection project design and rollout

Evaluating intrusion detection technology requires an understanding of its capabilities. Get help with getting started on an intrusion system program design and uncover technical considerations your enterprise needs to know.

Intrusion detection and prevention system technology evolved out of real-time network packet inspection, or packet...

sniffing as it's known.

In packet sniffing, network packets are captured and examined later for encapsulated data content as well as the packet's protocol settings. Intrusion detection and prevention system (IDS/IPS) technology captures packets based on pre­defined parameters: either using packets that are different from expected traffic or using packets that match predefined attack signatures.

IDS/IPS technology also performs predefined actions once an anomalous packet is detected. These actions can include sending alerts of various types, as well as blocking or resetting malicious packets. Each device that acts as an IDS/IPS is called a sensor, and sensors usually re­port to a management system responsible for configuring sensors and updating their attack signatures.

What is IDS? What is IPS?

Intrusion detection systems are passive devices that monitor network packets through mirrored network switch ports or network taps that make copies of network packets and pass them on to the IDS for analysis.

HIPS software is designed to protect endpoints from network-based attacks and may even report to the same management console.

A separate network interface card in the IDS can issue TCP reset packets to disrupt the TCP connection between a malicious device and the targeted system. An IDS product cannot block malicious ICMP or UDP traffic.

An IDS can collect net­work packets from a variety of network segments connected to a network aggregator appliance that passes the packets on to the IDS.

Intrusion prevention systems are active devices that monitor and block network packets by being connected between network segments.

IPS devices take network packets in and then inspect, block and pass on "good" network packets to the downstream devices. By nature, they can stop any kind of network packet. Since they are inline devices, they can be set to either fail in an open or closed state, depending on the level of accepted risk security administrators set. Because an IPS sensor can only address the incoming network packets for its network segment, more than one IPS sensor is needed to protect sensitive network assets, such as Web and data­base servers.

IDS, IPS or both?

Use of IDS or IPS sensors are not an either/or prospect. They can be used together, with IDS sensors monitoring network segments of lower risk, while inline IPS sensors can be used to protect higher-risk targets. Additionally, both can be used with host-based IPS software called HIPS. This soft­ware is designed to protect endpoints from net­work-based attacks and may even report to the same management console.

Proper design and deployment of IDS/IPS products will require three-fold work with vendor or value-added reseller (VAR) engineers, the cybersecurity project team and networking staff. Most network engineers understand the value of IDS/IPS technology but will want to ensure that the implementation is properly sized, configured and deployed to provide as little disruption as possible -- especially on high-availability networks. They will favor a phased rollout, with plenty of time to evaluate possible effects on network throughput.

IDS/IPS project design

Organizations should also consult industry-specific cybersecurity information sources that can help quantify external threats that every part of the industry faces.

The first step in the intrusion detection project design is to determine the scope of the IDS/IPS implementation. Using the organization's annual risk assessment re­port, pertinent regulatory compliance directives and security incident after-action reports, planners should establish a prioritized list of network re­sources to monitor and protect. The organization should also consult industry-specific cybersecurity information sources that can help quantify external threats that every part of the industry faces.

Typical external threats can range from denial-of-service attacks for e-commerce and financial organizations to intellectual property attacks using advanced persistent threat attacks against engineering and research firms to industrial control attacks and denial-of-service attacks for critical infrastructure organizations like power and gas utilities. Resources at risk should be identified by IP ranges, virtual LANS, protocols, applications, operating systems and any service-level agreements both with the organization's business units as well as external entities.

This information should be mapped at a high level using network schematics and overlays for existing network maps to identify likely spots where IDS/IPS sensors can be placed. The organization's networking staff will be instrumental in helping the planners understand the organization's network design on many levels and even point out monitoring points based on their extensive knowledge of networking hardware and the network topography.

At the outset, the intrusion detection project team should decide if an open source product -- such as Snort, along with one of its many supporting IDS management projects -- could be used as the primary IDS/IPS technology. Since IDS/IPS sensors can be pricey, using an open source tool or service can offer a lower upfront cost by using open source software on either already-owned hardware or virtual machines. Such an approach will require the long-term retention of subject matter experts in these open source technologies and require more hands-on administration of the sensor's operating system as well as the installed IDS/IPS software.

IDS/IPS technical considerations

Once the deployment scope has been worked out, project planners can consult the technical specifications of candidate IDS/IPS sensors to determine if a sensor's throughput is adequate to protect the resources behind it. Of importance are the number and type of interfaces in the sensor, be it copper or fiber. Also the processing power of the sensor should be gauged against the anticipated traffic level, the protocols and applications data packets monitored by the sensor.

While these choices sound mundane, the devil is in the details, so working with VAR engineers and manufacturers' representatives can really help, especially with new features or capabilities that may not be documented in sales materials.

Software-defined networking promises to offer an abstract way to configure and control a network using inexpensive network switches managed by a central software-based controller.

Much has been made of breaching the net­work perimeter with technologies like the Inter­net of Things (IoT), cloud-based software as a ser­vice (SaaS), bring your own devices, the smart grid and the "consumerization of the Internet" by introducing consumer products to the workplace. While each of these adds complexity to cybersecurity architecture, all are based on existing operating systems and network protocols. Hence, no matter what direction the packets come from, they are all going to act according to the rules of Internet-based protocols or they won't be able to traverse the Internet. From the engineering perspective, these technologies are evolutionary, not revolutionary.

Security practitioners can't dictate how various devices are designed, so security features are not of­ten in the forefront of manufacturers' minds. Take, for instance, the compromised IoT "smart" refrigerator hosting a spambot, which was discovered by cybersecurity researchers. The cybercriminals had not reverse engineered some exotic technology; rather, cybercriminals found that the operating system for the smart fridge was a Linux-derived embedded system that had not been patched and they exploited it.

The malicious uses of the IoT are not game-over moments. Using the network maps and diagrams created as part of the planning process, IDS/IPS project planners can consider the risks that new technologies like IoT and cloud SaaS represent and place their sensors accordingly. The key is to both understand where an organization's "crown jewels" are located and how cybercriminals might access, disrupt or corrupt them. Once these data flows are mapped out, sensors can be placed to monitor and protect those flows in concert with other security measures, such as network segmentation and access control lists.

The same can be said of multipath TCP, which arguably has good benefits by providing multiple communication paths between endpoints. While multipath TCP packets may fly hither and yon across the Internet on separate paths, at some point they must converge to deliver the data. These points can be dictated by network design, and consequently IDS/IPS systems can be there to monitor the converging stream. Security issues for multipath TCP are not a mystery and can be found described in RFC 6181 ("Threat Analysis for TCP Extensions for Multipath Operation with Multiple Addresses") and in RFC 6824 ("TCP Extensions for Multipath Operation with Multiple Addresses").

Issues with IDS/IPS technologies are discussed in RFC 6824, which describes how multipath TCP is intended to behave with "middle boxes" like fire­walls and IDS. RFC 6824 states that a multipath TCP-aware IDS/IPS will be able to correlate multiple sub-flows and reassemble them for analysis. So again, multipath TCP is not a game-over moment for IDS/IPS.

Granted, these new technologies may require new adaptable ways to provide monitoring points beyond the conventional SPANs and network taps. Software-defined networking promises to offer an abstract way to configure and control a net­work using inexpensive network switches managed by a central software-based controller. Using this approach it is possible to create an out-of-band net­work connected to the production network. This out-of-band network serves as the monitoring connection points for the production network while not affecting the production network throughput.

IDS/IPS rollout

The project team will have to determine the scope of the project based on available resources. Very rarely do project teams get budgets big enough to handle the project, so a phased multi-year rollout is often used.

Once the number of sensors has been determined, a rollout plan should be developed based on the importance of the to-be-protected resources and the importance of any disruptions to the net­work during installation. The deployment should go in phases as recommended by the networking group so as to minimize downtime and to see if over time there are any unforeseen side effects, such as dropped packets and degraded SLA levels.

In any rollout plan, an organization should have a back-out plan in order to regroup and try a sensor deployment again. Generally, sensor deployments do go well.

Finally, as part of any project rollout, the persons charged with administering sensors and analyzing the IDS/IPS reports should be trained in advance of a project rollout. In addition to vendor training, third-party training such as the SANS Institute course "Security 503: SEC503: Intrusion Detection In-Depth" helps prepare staff for the challenges of IDS/IPS work.

About the author:
Bill Hayes is a former oceanography student and military veteran, and a journalism school graduate. After flirting with computer game design in the 1980s, Hayes pursued a full-time career in IT support and currently works as a cybersecurity analyst for a Midwestern utility company as well as a freelance expert consultant and writer.

Next Steps

Do you need IDS and IPS? Find out now

Uncover the basics of IDS and IPS

This was last published in February 2015
