The discussions I've lurked over seem to dance around the intended application (target audience) of the IDS system. If the intended application is for management purposes, such as to monitor a particular 'service level' of security, an IDS system would be the best tool we currently have (best evidence) to measure what drifted through the window and what fanged beast scratches at the doors. A CIO is typically measured by Service Level Agreements (SLA), and one agreement which targets security may state that the servers or network will be 98% secure. Maybe 2% of the time there will be detected security intrusions which could include internal WinNuke 'testing', viruses, or even downtime caused by fixing what was installed insecurely in the first place. I believe it's widely accepted that if the intended IDS application is to guarantee 100% security, it ain't gonna happen. There's no way to predict the future, or to forsee stealthy hacks crafted by clever intruders. Concerning active responses or integrating Artificial Intelligence (now often called 'Applied Intelligence'), as with all applications, one could also automate an IDS system to do stupid things. Better yet, the 'knowledge base' contained in the IDS should trigger alerts, and use 'AI' to give detailed instruction on what to do to zoom in on an attack to focus on the source, and/or to fix what allowed the attack, maybe even determine what does not require paging someone, to prevent a denial-of-sleep attack. If the administrator sets the system to respond a certain way automatically, with experience he'll learn what he can get away with and what not to do in the future. An IDS system needs an intelligent source of understanding to update the knowledge base, Farmer correctly pointed out that you can't only work off knowledge, you have to work off understanding (my translation). If the administrator is not a good source of understanding for that knowledgebase, an outside source (subscription) should be used. This is basically outsourcing intrusion detection to those who should know what it looks like. An IDS system should also collect only as much data as possible until it detects something worth the cost of detailed logging. We could collect all network traffic always, but that would constitute a self-inflicted denial-of-storage attack. Farmer is right that during the time you debug or track something down down you need to collect as much seemingly mundane data as possible during that instance. What is actually needed is a state-snapshot of configuration files from routers, systems, firewalls, etc, maybe a 'cops-like' functionality to review what the security of the systems were defined to be, or to determine what should not be, or could have been changed. An IDS system can be marketed as a network analyzer bits & bytes tool, or a high-level executive SLA measurement system. I predict IDS systems will catagorize or absorb components of themselves into monitoring tools, management tools, executive tools, and maybe even apply the knowledge base to network/systems security planning tools. Personally I view the future view of firewalls as much bigger than a proxy box, it's a collection of boxes and high-level coordination between systems to create a perimeter or area security system. Bill Stout
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 12:56:11 PDT