-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 np, we have a vested intrest in a lot of this:
http://www.ren-isac.net/ses/ we leverage RT+IR for the front end "human tracking" bits, IODEF is the standard we use to normalize all the threat information, so we maintain XML::IODEF and RT::IODEF for that reason. I'm probably going to build a complimentary component to RT::IODEF that stores the tickets as IODEF blobs (similar to how CIF[1] works). I think the custom field architecture does some things well, but it might make RT scale better (for what we need it to do down the road) if we add a sort of NoSQL-ish architecture to it (married with the the standardized IODEF bits). Understanding this might not work very well for RT itself, for the +IR process it's proven to be most useful over the last few years... so right now, CIF sits behind RT (RT pushes IODEF messages into CIF, RT can unwrap IODEF messages into it's CF's too) and collects it's intel along-side of all the other various lists out there (think of your RTIR/Tools.html page, with all it's whois lookups, but now it has the ability to see things in other data-repositories, malwaredomains.com, spamhaus, etc...) food for thought.. [1] http://code.google.com/p/collective-intelligence-framework/ On Oct 28, 2011, at 4:17 PM, Ruslan Zakirov wrote: > Thanks for clarification. Didn't know about this extension. - -- Wes claimid.com/wesyoung [email protected] -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.16 (Darwin) iEYEARECAAYFAk6uiQkACgkQKezpZd226UZbigCfdJpO74PLjhuZv9tg9c0rcgi2 0bMAoJ0vzjaHty5GZ7fmMrzgC7QnaKww =ocgj -----END PGP SIGNATURE----- _______________________________________________ Rtir mailing list [email protected] http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rtir
