Shouldn't that go under the provider attribute? My point with the ID's vs UUID was that I prefer a numeric ID. Just as with IP space, we could provide a "number space" for local signatures. For instance, 0 through 2,000,000,000 would be public space, and 2,000,000,000 through 2^32 would be private space. I think the "opensshd" component would be assigned to the "name" attribute, or something similar, or maybe would be the "class" attribute. On Thu, Jul 1, 2010 at 5:53 AM, Balazs Scheidler <bazsi@balabit.hu> wrote:
On Wed, 2010-06-30 at 21:13 -0500, Martin Holste wrote:
Cool, I'll have a look at the OSE 3.2 roadmap.
I should note that while I've done extensive testing in MongoDB, I'm currently using MySQL and a standard SQL schema for production. The main reason is speed, though I expect MongoDB to catch up eventually. CouchDB is extremely slow, comparatively, for sustained inserts, and I doubt it will ever be a viable option for high-performance logging. At any rate, a SQL schema would be fine with me.
Yes, I mean UUID when I say CLSID. I think that requiring a central place to administer the ID's is actually a strength, not a weakness, because it encourages collaboration and peer review. By getting an ID, it means that the signature has been vetted. The EmergingThreats.net Snort signatures are borne from such a process and are much stronger because of the open discussion, debate, and peer review.
I understand, and I guess we could create a policy that makes it possible to create a private ID space (similar to private IP addresses), which is guaranteed not to collide with "official" IDs.
What about an
application-name[@provider.tld]
* official samples would only contain "application-name" * private samples would have their domain name appended
For instance, the official ID for OpenSSH log patterns would be:
opensshd
Whereas if you wanted to create your samples for application foo, that would look like:
foo@balabit.com
What do you think?
-- Bazsi
______________________________________________________________________________ Member info: https://lists.balabit.hu/mailman/listinfo/syslog-ng Documentation: http://www.balabit.com/support/documentation/?product=syslog-ng FAQ: http://www.campin.net/syslog-ng/faq.html