Page 182 - DCAP516_COMPUTER_SECURITY

Computer Security

Notes As an integral element of the network fabric, the Network IPS device must perform much like a
network switch. It must meet stringent network performance and reliability requirements as a
prerequisite to deployment, since very few customers are willing to sacrifice network performance
and reliability for security. A NIPS that slows down traffic, stops good traffic, or crashes the
network is of little use.
Dropped packets are also an issue, since if even one of those dropped packets is one of those used
in the exploit data stream it is possible that the entire exploit could be missed.

Most high-end IPS vendors will get around this problem by using custom hardware, populated
with advanced FPGAs and ASICs – indeed, it is necessary to design the product to operate as
much as a switch as an intrusion detection and prevention device.
It is very difficult for any security administrator to be able to characterize the traffic on his
network with a high degree of accuracy. What is the average bandwidth? What are the peaks? Is
the traffic mainly one protocol or a mix? What is the average packet size and level of new
connections established every second – both critical parameters that can have detrimental effects
on some IDS/IPS engines? If your IPS hardware is operating “on the edge”, all of these are
questions that need to be answered as accurately as possible in order to prevent performance
degradation.
Another potential problem is the good old false positive. The bane of the security administrator’s
life (apart from the script kiddie, of course!), the false positive rears its ugly head when an
exploit signature is not crafted carefully enough, such that legitimate traffic can cause it to fire
accidentally. Whilst merely annoying in a passive IDS device, consuming time and effort on the
part of the security administrator, the results can be far more serious and far reaching in an
in-line IPS appliance.
Once again, the result is a self-inflicted Denial of Service condition, as the IPS device first drops
the “offending” packet, and then potentially blocks the entire data flow from the suspected
hacker.
If the traffic that triggered the false positive alert was part of a customer order, you can bet that
the customer will not wait around for long as his entire session is torn down and all subsequent
attempts to reconnect to your e-commerce site (if he decides to bother retrying at all, that is) are
blocked by the well-meaning IPS.
Another potential problem with any Gigabit IPS/IDS product is, by its very nature and capabilities,
the amount of alert data it is likely to generate. On such a busy network, how many alerts will
be generated in one working day? Or even one hour? Even with relatively low alert rates of ten
per second, you are talking about 36,000 alerts every hour. That is 864,000 alerts each and every
day.
The ability to tune the signature set accurately is essential in order to keep the number of alerts
to an absolute minimum. Once the alerts have been raised, however, it then becomes essential
to be able to process them effectively. Advanced alert handling and forensic analysis capabilities
including detailed exploit information and the ability to examine packet contents and data
streams can make or break a Gigabit IDS/IPS product.
Of course, one point in favour of IPS when compared with IDS is that because it is designed to
prevent the attacks rather than just detect and log them, the burden of examining and investigating
the alerts – and especially the problem of rectifying damage done by successful exploits – is
reduced considerably.

176 LOVELY PROFESSIONAL UNIVERSITY