Here's a few things that I think would be helpful in the CSIDS development. In fact, more than a wishlist, I'd like to be hopeful we could see in near-future releases of the product. Feel free to suprise me by saying that these are planned for the 3.0 release. :-) Almost all of them call for a greater and tighter integration with existing Cisco products.
1 - PIX Configuration Integration - This would allow the CSIDS product to know where in relation to a PIX and the ruleset it sits before/after. Benefits would include PIX log management for IDS detects, an IDS response that could add to detail summary what was stopped by firewall and what wasn't, and a knowledge of what sockets are allowed to pass through the PIX and what wouldn't - this would allow respose differentiation. I'll add a possible and tempting example at the end of this list....
2 - Implement support for null route shunning complementing Cisco's enhanced unicast RPF. Ideally, I'd like to see an CSIDS control device that could shun through route updates via BGP as described in this document - http://www.cisco.com/public/cons/isp/documents/uRPF_Enhancement.pdf
We could then enable a multihop BGP session to the IDS, and receive and aggressively filter shun events via route updates(that don't over run a router as badly as thousands of Telnet attempts during a Code Red future event).
3 - NetSonar, or whatever it's called now, integration. It'd be nice, for instance, to have a single copy of the NSDB that covered both sides. :-) Also, once I had a detect of a run against my data center (sadmind/IIS worms come to mind), I could run a scan using the same detected vulnerabilities to determine if the system is vulnerable to a recent detect. For extra points, let that be a response option, so when the incident response team gets the call to investigate they know automatically whether a vulnerability exists before trying to get admins up and out of bed to see if they patched the OS.
4 - Real state inspection!!!! Get rid of those nasty Stick vulnerabilities, as well as the ease of a denial-of-service attack through shunning. (I know, there are those never-shun tables, but for a web-hosting provider those aren't near large enough)
5 - Add SYN/ACK response as an option. This is the method that could be used if the NetRanger's had a good view of the PIX activity behind it. If someone SYN port scans a web server that only has port 80 open through the firewall, let's give that evil attacker a real workout (not to mention those annoying Security Consultants that run a scanner and nothing more) by responding to every SYN packet that will be dropped by the PIX with a spoofed SYN/ACK packet ala the same mechanism that RST kills are done. :-) Add some tunable perameters for the spoofing for TTL and other OS fingerprinting methods and let's make those attackers really work to find a real target.
6 - Numbers 1 and 5 really deal with the CSIDS knowing about the PIX, but consider the PIX knowing about the IDS and being the primary response engine. PIX shunning should not need to be mentioned, but I will so y'all can have a freebie for telling me how quickly y'all are going to address my concerns. And now that it's been mentioned, let me mention also the ability to throttle latency on SYN flooding and maybe to the SYN scans (for those of us that don't like too many packets generated by our IDS going back to the attacker as in number 5 above). This way an ever increasing latency could be introduced as the SYN flood (or Half Open SYN if you prefer) or scan progresses.
OK, so it's still too early for Santa to bring me all this, but a pleasant way to finish a day of incident response. Please take these seriously, wouldn't it be nice if Cisco lead the way into next-generation IDS?
Forwarded to the Dev Team management and Product Marketing folks...
PS: some of this is on our roadmap, some is not...PIX integration being a difficult nut to crack, although your "freebie" in #6 should be coming to a CSIDS near you soon, if not already ;)
Santa has received your list of requests and is considering them. As a matter of fact Santa's elves are hard at work on some of the items in your list. Most of the things that you mention require a lot of coordination and could have significant impact on performance if not implemented carefully.
A quick example of how we are addressing a couple of your issues in 3.0, which is now available on CCO, follow.
I'm not exactly sure what your intention was for number 4, but we have added functionality to the sensors in 3.0 that allow them to be "aware" of the rate at which they are alarming. Their first line of defense if the alarm rate exceeds a prescribed threshold is to fall into what we are calling "Summary mode". In this mode the sensor will continue to maintain state on the offending signature by it's storage keyset, but will cease to alarm at every event. Rather it will begin to accumualte the occurrences of the event and will report a summary alarm every "X" seconds where "X" is user definable. The default value of "X" is signature dependent but is usually 15 seconds. If the alarm rate across signature keys is still too high we then enter what we call "Global Summary mode". This mode deals with those nasty spoofed DoS floods and zombie attacks. The sensor now will consolidate based on Signature ID alone all of the timing as above still applies. In both of these modes you will lose some information unfortunately, as we have no way to give a list of SRC's and or DST's hosts/ports in our current alarm format. (A possible enhancement to this feature, that I will take from your entry) would be to ignore the shun action if we have entered a summary mode. It certainly should be done for the Global mode.
6. Pix shunning has been added in the 3.0 release as well.
I can not unfortunately elaborate on the ideas that you have mentioned above that we are currently working on as well as many others that have gone unmnetioned. But suffice to say keep your eye on your stocking and be certain to leave room under your Christmas tree.
Having used the CSIDS archtecture for a while we would like to see major improvements in operational management for service providers.
For example, managing large numbers of sensors, i.e. lots of customer pods with one or more sensors in is really difficult in terms of globally updating Signatures, applying filters etc. This could be done quite easily for using more pick lists and allowing sensors to be grouped into all sensors and custom groups rather than just on network segments.
Also ability to send syslog and snmp alerts would be useful.
Scalability for more than 20-25 Sensors per CSPM or Director would help.
We have currently developed a perl script that filters out signatures and sends syslog messages into our cmc to get around these limitations.
Finally why is the 4210/4230 x86 solaris and the IDSM embedded NT.
Thanks for listening
>>Finally why is the 4210/4230 x86 solaris and the IDSM embedded NT.
The IDSM has hardware acceleration for packet processing. The hardware accelerator is not supported under solaris X86.
Finally why is the 4210/4230 x86 solaris and the IDSM embedded NT.
A little more detail on this. The actual sensing software is running on the hardware accelerator that Scott mentions in his post. The only software running on the NT host are host services and a communication API between the HW accelerator and the host. Packets are never sent to the host for any processing. This is also why you may see slightly different behaviors and develpoment cycles for the appliance and the IDSM. The sensing code is different. This was necessary as the host was not powerful enough to run our IDS SW at even 100 Mbps.
Expect to see significant improvements in the blade HW and convergence of the appliance and IDSM SW in the coming year (on the newer HW).
Thanks, That was really useful to know as explains alot.
We are waiting impatiently for 4.0 S5 for the idsm and hopefully then the version will be in sync. We have alot of customers lined up for this over the next couple of months.
It is crucial to the success of the CSIDS in the MSP environment to be able to mass update sensors. This is probaly the single most important feature required along with greater scalability.
Just to line you up with what's actually in the hopper. IDSM 4.0 is quite a way off we are curently shipping IDSM 2.5 what is due out of QA sometime soon is IDSM 3.0. This version will have the same auto update feature as the 3.0 appliance.
sorry I meant the IDSM 3.0.
How many sensors in your experience can you manage with a single CSPM Server Unrestricted. I think the figure is around 20-25 per CSPM Server max.
I would also like to see greater scalability for Sensor management.
sorry to be so greedy.
thanks for the info