>Has anyone else looked at this? Is anyone on this list involved with the >editorial board? One of the senior tech staff of NFR is involved in it, and represents us on the board. I don't think, honestly, that the vendors have had a lot of real input into the effort. :) I know I was kind of surprised to see us listed in a press release without anyone asking us first. :) The idea's got some merit - things will/would/can be better if we all use the same terms to describe the same kinds of events. That's just common sense. How far it'll go is still somewhat open to question. I, for one, don't think it was a good idea to convert human readable text into a non-human-intuitive numeric code. My experience with computing systems is that when you do that, usability goes into the toilet. For example: CVE-1999-0002 == Buffer overflow in NFS mountd gives root access to remote attackers, mostly in Linux systems. Does that mean my IDS should generate messages saying: "66.66.66.66 just tried the old CVE-1999-0002 on 10.10.10.1"? instead of: "66.66.66.66 NFS mountd buffer overrun against 10.10.10.1 (CVE-1999-0002)"? I know which I'd rather read. ;) Giving it as an option, with the default being "human readable" is always a good idea. There's another problem - what if a vendor knows of something they want to look for but doesn't want to share the alert point with all their competition? We'd have to fall back on our own strings and codes, and pretty soon the taxonomy falls apart. This is just another instance of the "standards committees in internet time" problem - it's very hard to keep up with _anything_ anymore. :( I think it may be a good start. Honestly, I probably won't have my team invest effort in re-writing our alert outputs to use CVE (because we'd have to add over 500 alert points to the CVE database to do so) unless there's a huge demand for it. I suspect other vendors will also take a "wait and see" approach. For now, it's too basic, I feel. Obviously, we can't all agree on the significance of a CVE-1999-0303 (oops, excuse me, a BNU uucpd buffer overrun) to any given network - and the current messages are not reliably tagged to O/S rev, host software rev, affected files, hardware architecture, and configuration information. That'd be useful. mjr. -- Marcus J. Ranum, CEO, Network Flight Recorder, Inc. work - http://www.nfr.net home - http://www.clark.net/pub/mjr
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 13:44:11 PDT