...but I feel comfortable in predicting the next thing every NIDS vendor will roll into their products: full packet logging.
In a nutshell, analysis will be removed one step further from capture. You'll have a tool that logs all packets to disk. Then packet and stream data will be analyzed on disk. It will work like your current IDS except that you can go back and get all of the packets, not just the ones that the IDS alerted on at the time. There are both performance and forensic advantages to doing this. The main drawback is the amount of disk it will take and how you will manage data retention over time. But disk is cheap and security products are expensive and this is something that will make the old seem new again.
3 comments:
Hi Paul,
I don't think that will happen. What will happen is IDS/IPS/SIM/SEM/SIEM vendors hooking into network forensic appliance APIs to access full content data. That's already happening, actually.
Richard,
Thanks for the response. While I don't doubt that you're correct about network forensics vendors making their products accessible to third-party SIM and IDS products, I don't see IDS vendors being able to leave this feature alone.
Infosec vendors (and maybe their customers) love appliances. You need look no further than Cisco, Symantec, or Check Point to see the 1-box-to-rule-them-all mentality at work.
Also, there are performance gains to be had here. Take what Sourcefire is doing with daemonlogger. Before, you had to run 1 Snort process per interface, and one barnyard instance per Snort process. That's CPU-expensive and forces vendors to use ASICs and other hardware tricks to offload the work to handle high throughput.
Now imagine running daemonlogger on multiple interfaces and a single Snort/barnyard instance to analyze the stored data at regular intervals. Cutting OEM hardware costs while offering a "new" feature has attractive possibilities for product margins at a time when IDS is leveling off I can easily see vendors like TippingPoint, McAfee, and Sourcefire doing exactly this. And if Gartner puts out something in support of it, expect it to become mandatory for all vendors.
Only time will tell which of us is right. In 2 years, if it hasn't happened yet, I owe you a beer at Black Hat 09? Deal? :-)
That makes no sense, if I understand what you're saying.
Where is the performance gain from writing traffic to disk, then inspecting it later? You can inspect live traffic much faster than you can write it to disk.
No one advertises their ability to write traffic at 8 Gbps. That's exceptionally difficult (albeit possible with expensive hardware). However, Snort's appliances can inspect at 8 Gbps.
You don't need to run one Snort instance per interface either, unless you want to separate the output.
As for the future, Snort 3.0 will be multithreaded and will have many more capabilities.
Post a Comment