The sound of intrusion-detection systems (IDS) sifting through the torrents of data entering networks and sending alerts about hacker attacks might be music to the ears of most security administrators. But if the IDS isn't tuned properly, those alarms can sound like fingernails scraping a chalkboard.
Despite better event correlation and centralized management consoles, fine-tuning an IDS so that it detects and generates alerts about only bona fide intrusions remains a classic security challenge. The answer to the IDS tuning dilemma rests not so much in technology but in people, processes and policies, say analysts and IT security professionals.
IDSs don't seem to work unless users have the time to stand guard with them and investigate every unusual incident, no matter how minor.
IDS tuning involves more than simply configuring the system to look for port scans and other attack signatures (software code that indicates malicious activity). Each IDS must be tuned to detect incidents that are pertinent to the specific network or subnetwork on which it's deployed. And if you try to detect everything, you're asking for trouble, says Bill "Ches" Cheswick, chief scientist at Lumeta Corp., a developer of network security monitoring software in Somerset, N.J.
"This leaves network administrators with two problems: An IDS that misses some things, which can cause sleepless nights, and an IDS that is constantly whining about things that are OK," he says. "Eventually, it cries wolf too much and the overworked network administrator tunes it down, weakens the rules or doesn't check the logs as often. I don't believe this problem is solvable."
Perhaps not, but to make progress, you should know what you want to protect, determine what you'll do if an incident is detected and have trained IDS analysts available, says Steve Prather, director of network services at ViaWest Internet Services Inc. in Denver.
"Companies tend to struggle with their IDS most when they have not properly tuned their system to their environment and their security policy," says Prather. "In some cases, a company may even try to implement an IDS without first putting a security policy in place." And not knowing how you should respond to an incident can be as problematic as not tuning your IDS properly, he says.
"Much of an IDS's effectiveness relies on what the company has stated they will do when an incident occurs," says Prather. "Who responds to what type of alert? At what level do we shut off connectivity or take servers down? This means a company needs a solid incident-response procedure for their IDS to be effective."
"It's more than just intrusion detection; it's intrusion protection," says Jeff Gorball, senior vice president of operations at Kingland Systems Corp., a financial sector e-commerce service provider in Clear Lake, Iowa. "You have to ask yourself, What am I trying to protect, and what or who am I trying to protect against?"
Gorball set up his IDS as part of a larger defense-in-depth security architecture. He uses increasingly tougher IDS rules as traffic passes through the network's rings of defense. "If you set up your alerts for those rings that are inside the outer rings, you'll have fewer alerts to reckon with," Gorball says.
The Right Technology Mix
But can a few IDSs alone do the job? Not by a long shot, say experts. For example, most companies should have multiple IDSs deployed throughout the organization, including network-based IDSs, which monitor network connections; host-based IDSs, which monitor server and workstation activity; and a mix of signature-based and knowledge-based IDS technologies.
Knowledge-based IDSs tune themselves to your network environment and look inward to learn how to spot anomalies or unusual behavior -- a critical capability today, when most security incidents originate from inside the firewall. In addition, some experts recommend using decoy servers, called honey pots, in conjunction with IDS technologies to divert an intruder's attention and give the security staff more time to respond.
"All of these layers need to be protected," says Chris Klaus, chief technology officer at Internet Security Systems Inc. in Atlanta. "Do not rely on just network IDS or server and desktop IDS. They need to be looked at holistically and integrated to maximize protection against intruders."
While some IDS vendors have come out with systems that are capable of active response to real-time intrusions, Mike Stute, CTO at Global DataGuard Inc. in Dallas, recommends that users stay away from this feature. "In general, this doesn't work well. Human intelligence is required to respond appropriately," he says.
But there are other ways you can inadvertently kill your IDS deployment project, says Gorball. "When you first put it online, you're going to want to do so in monitor mode to make sure the rules you've set up will not adversely impact your workflow when you put it into an active state," he says. "If you don't get the rules exactly right, you could leave vulnerabilities in place or, worse yet, kill legitimate traffic."
And there's only one way to get the rules right, says Stute. "It takes constant human involvement. Tuning reduces false positives but creates false negatives. Once someone is paged 30 times a night for five nights and finds that in all cases it was a false [alarm], most administrators will just remove that signature from the database and call it good.