Tip

Next-generation intrusion prevention: Time zero (during the attack)

Previous installments of this series cited the need to consider the entire attack timeline to comprehensively address intrusion prevention. It carved the attack continuum into three distinct periods – before, during and after the exploitation of a vulnerability – and subsequently described the processes and technologies associated with the first of these in greater detail. This part in the series elaborates on the remaining two periods and further establishes the foundation for discussing the requirements for next-generation

    Requires Free Membership to View

intrusion prevention systems.


Given the variety of attacks, it is somewhat difficult to precisely define this part of the attack timeline. Some attacks are immediately recognizable, perhaps taking the form of one or more packets operating over a short time period (e.g., less than one second). Others are characterized by intermittent activity spanning a much longer timeframe (e.g., hours, days or even weeks) and may not even be identified as attacks until a vast collection of event records are considered in aggregate. Thus, while every attack has a definitive beginning, this starting point is not always discernible at the time of occurrence. Neither is the time it takes for such an attack to unfold or its ultimate duration predictable.

To simplify matters, for now we'll just focus on the initial onset of an attack and that subset of attacks that are essentially recognizable in real time – in other words, true time zero plus some arbitrarily small time slice beyond that (i.e., less than a couple seconds). From a technology perspective, this is the realm of the current generation of intrusion detection and intrusion prevention products.

Devoting a great deal of text to these technologies is unwarranted given the extent of coverage they have received in the past couple of years. The forerunner of the two, intrusion detection, passively monitors a copy of production traffic for suspicious activity and patterns associated with attacks. For the most part, intrusion detection products are dependent on external response mechanisms. In contrast, intrusion prevention devices are typically positioned in-line as active participants in the traffic flow, and therefore can respond directly (i.e., natively) to detected attacks.

Of course, an implication of implementing any degree of automated response is the need for a high degree of detection accuracy. Excessive blocking of non-attacks is ultimately counter-productive. Accordingly, this has been an area of development for both types of intrusion management products. The addition of protocol anomaly and vulnerability-based signatures to many products are two common examples. However, in terms of detection accuracy, there is always room for improvement.

For example, most products focus solely on the traffic stream that goes by or through them. In doing so, they ignore a wealth of information regarding the potential targets, or hosts, in a networked environment. Properly collected and put to use, such information enables a degree of automatic tuning that can yield significant improvements in both accuracy and performance.

At the same time, with today's ever-changing threat environment, it is unrealistic to expect any single product to catch absolutely everything. However, this should not preclude gathering input from other products after an attack has occurred to support automatic prevention of future occurrences.

And speaking of "after an attack" …


NEXT-GENERATION INTRUSION PREVENTION

  A continuum of capabilities
  The pre-attack period
  Time zero (during the attack)
  The post-attack period
  The power of an integrated system

ABOUT THE AUTHOR:
Martin Roesch founded Sourcefire in 2001 and serves as its Chief Technology Officer. A respected authority on intrusion detection technology and forensics, he is responsible for the technical direction and product development efforts. Martin, who has 17 years industry experience in network security and embedded systems engineering, is also the author and lead developer of the Snort Intrusion Detection System (www.snort.org) that forms the foundation for the Sourcefire 3D System.

This was first published in September 2005

There are Comments. Add yours.

 
TIP: Want to include a code block in your comment? Use <pre> or <code> tags around the desired text. Ex: <code>insert code</code>

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy
Sort by: OldestNewest

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to:

Disclaimer: Our Tips Exchange is a forum for you to share technical advice and expertise with your peers and to learn from other enterprise IT professionals. TechTarget provides the infrastructure to facilitate this sharing of information. However, we cannot guarantee the accuracy or validity of the material submitted. You agree that your use of the Ask The Expert services and your reliance on any questions, answers, information or other materials received through this Web site is at your own risk.