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 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.
|
|
