Intrusion detection systems are all the rage in the security market at present. Although they mean different things to different people, the general feeling is that something has made the jump from being a firewall to being an IDS if it’s started to do more than just analysing the traffic that comes in from the Internet. That could be, for example, passing it off to third-party applications such as anti-virus packages for further processing.
The additional functions found in IDSs include: • Using “agent” software, or standard interfaces into computers on the network to check whether system files are being altered as the result of traffic coming into the network. • Monitoring log files on networked computers to check for reports of illicit activity. • Acting as a “sandbox” – mimicking the behaviour of a networked computer to interact with a suspected intruder, and examining what the remote machine attempts to do. The aim is to see if it would adversely affect the real machine it’s pretending to be.
On the face of it, intrusion detection systems are an excellent idea. Traditional firewalls may let through traffic that causes problems because it appeared valid according to the firewall’s programming. The most obvious case is where a new attack has been devised by a cunning intruder and firewall makers haven’t yet spotted it and produced a fix. In such cases, the ability to do some extra sniffing around and find issues that are raised by apparently innocuous traffic sounds very attractive.
In reality, though, there are two types of detection algorithm used by such applications: definitive and heuristic. A definitive algorithm is one that will always give the correct answer: For instance, if the Administrator password on a Windows 2000 server suddenly became blank, you would always want to know about it.
In many cases, though, you can’t use a definitive algorithm. A typical example is deducing whether an email message is spam – it’s largely a subjective decision with a large dose of personal preference thrown in by the user. Even some algorithms that claim to be definitive for spam detection fall down through human error. For example, a system could be told not to deliver mail that’s come from servers listed in one of the lists of open SMTP relays that exist on the Internet. But there are hundreds of instances of servers being wrongly listed on these systems every day.
And herein lies the problem: false positives. A false positive is an instance where a transmission is blocked, when it should be let through. One school of thought (which tends to include the IDS manufacturers, unsurprisingly) says that it’s better to have false positives – wrongly bounced emails, refused VPN connections, etc – than to run the risk of intrusion. The other says that if you patch all your servers regularly, keep your AV software up to date, and examine the IDS logs properly, the risk of unwanted transmissions getting in is negligible. Issues that result from the few that do, are easily dealt with in most cases.
Going back to our earlier example of the Windows Administrator password being blanked out. Whichever side of the fence you sit, you’d probably find some reassurance in receiving a “false positive” report if you’d deliberately blanked it out yourself. So, just where do you draw the line between “report” and “don’t report”?
The problem is, there isn’t a right answer. After all, questions like how many emails per minute to a particular address constitutes a problem, depend largely on the nature of the address. If it’s a general address that’s publicised all over the world you might expect 20 per minute in peak periods but if it’s your MD’s personal address you’d smell a rat at more than a few dozen per hour.
The technology in IDSs is clever, advanced and useful. It’s actually the users that are the problem. That’s because the way you want to configure the systems depends on a combination of personal preference (on the part of the system manager who has to wade through the exception reports, and of the user who sometimes finds that emails are bouncing for no apparent reason) and the specific circumstances of each individual transaction.
If you buy an IDS you must be aware that, in the early days at least, you’ll have to spend a significant amount of time going round the loop of changing the settings and analysing the results. When you’ve found a happy medium between false positives and unwanted traffic getting through, you’ll still have to revisit the settings regularly as new types of traffic (and therefore new types of hack) arrive on the scene.
In short, then, an IDS will almost certainly improve on an existing firewall but don’t expect it to be install-and-forget.