RangerIDS - Intrusion Detection System (IDS)
Monitor-Evaluate-Modify: The Security Cycle
Once you have your IDS deployed and working effectively, that is not the time to sit back and relax. In fact it is only the beginning of a cycle that must be constantly repeated if security is to be maintained. IDS is a valuable component of an organization’s security plan, but it is just that – a component. The first point of defense may well be the firewall, and behind the Network and Network Node IDS system may well be additional port monitoring and File Integrity Assessment products to alert you as to when an intrusion attempt has been successful.
All of these components must operate within the confines of a strict security policy, which should determine what is and is not allowed on the corporate network. This, in turn, will help specify how the individual components are to be deployed and configured, as well as offer guidelines as to how alerts are to be handled. There is no point in using the latest IDS technology only to have it log intrusion attempts to a file that is only examined once a month.
There should be differing levels of importance assigned to different types of intrusion attempts, and the alert and response procedure should be scaled accordingly. There is little point in raising the roof should you discover your network is being port scanned by someone using nmap – that happens all the time, and it is enough to log that for periodic examination just to make sure it is not happening too often within a set time interval.
On the other hand, a successful BackOrifice ping that elicits a reply from somewhere within your organization indicates a serious compromise, and for that you may deem it appropriate to page the security administrator any time day or night. Between those two extremes are various other possible responses such as e-mail, SNMP alerts, session termination, firewall reconfiguration, and so on. Use them to the full, and make sure that your security staff take the time to examine the various log files at regular intervals to keep tabs on the more mundane intrusion attempts.
And, of course, there is the constant battle against false positives. An IDS can only alert on what it sees compared with what it thinks is “bad”. A particular binary file on your network might, coincidentally, contain the exact pattern of bytes used in a particular shell code exploit. Or perhaps you actually have a file called cgi-bin/test-cgi and it is in common use. Both of these situations would cause numerous alerts to be logged on a daily basis by the IDS causing frustration for the administrator.
One approach is to simply turn off the signatures that cause the alert, refining the security policy and reducing the number of false positives. Of course, this could have wider reaching consequences, in that should an attacker attempt to launch that shell code exploit or scan for your test-cgi file, the attempts will no longer be logged. It is far better to tune the signatures instead, if at all possible. This is dependent both on your chosen IDS product allowing the definition of custom signatures and your ability to research the exploit thoroughly enough to produce a sound signature. Is there, perhaps, a longer binary pattern to identify that shell code exploit that will not be triggered by your legitimate application? And could you simply rename that test-cgi file to something else?
Intrusion Detection Systems are good at sounding alarms, but unless there is someone around who is prepared – and trained – to respond (even if it is only to determine that the alert is a false positive), it is no better than a car alarm that everyone ignores. An effective response is every bit as important as detecting the attack in the first place.
Maintenance is equally important. Security is certainly not static, and new vulnerabilities are being discovered and exploited all the time. This should result in new signatures for your IDS and VA tools, patches for your operating systems and updates for your firewalls. Even so, it is a wise security administrator that keeps an eye on the various underground hacking sites and security alert mailing lists for himself. Between the point of discovery to the point where a patch is issued and applied, there is a window of opportunity for the hacker to exploit. It is up to the security administrator to minimise this window as much as possible.
If an OS vendor is slow in bringing out a patch for a new vulnerability, for example, perhaps the administrator can reconfigure the corporate firewall to eliminate the sort of traffic that could exploit that vulnerability, or add a temporary custom signature to the IDS in order to detect it. Certainly as soon as new IDS signatures are made available from the vendor, they should be downloaded and deployed to every appropriate sensor on the network.
Finally, the administrator should be using Vulnerability Assessment tools on a regular basis (or employing outside consultants to do the same) in order to continually test defenses and update security policies accordingly. A VA scan may well highlight additions or changes to the network and its applications which might necessitate a rethink on how IDS sensors are deployed and which signatures are monitored by each sensor.
Monitor – evaluate – modify. Then back to the beginning. It is a cycle that must be repeated over and over if you want to keep your network as secure as possible. Only by continual vigilance and refinement will you stay one step ahead of (or at least no more than one step behind) the hackers.