Hi, what standards/considerations are implemented in RTIR. By this I mean things like, ITIL, IODEF, CVE, etc.
Robert Floodeen
Member-Technical Staff
CERT Resilient Enterprise Management Team
Carnegie Mellon Software Engineering Institute
Enterprise Risk and Resilience Management | Software Engineering Institute<The CERT Division | Software Engineering Institute>
Hi,
I’m not sure how to answer your question. RTIR is an implemented ready
to use workflow for incident response teams. It works on top of RT and
allows you to use RT for other things you need.
I can not say how close workflow in RTIR to flows described in
ITIL/ITSM recommendations. RTIR was released earlier than ITIL gain
its current popularity.
RTIR can win from using IODEF to export information, but it’s not implemented.
CVEs are out of scope of RTIR. It’s not a problem to record related
CVEs identifiers in RTIR DB while investigating attacks, but
preventing attacks by managing your software using informations from
CVEs is out of scope.
Additional information about RTIR you can find in tutorials that are
shipped in tarballs and available in the repository.On Fri, Oct 28, 2011 at 7:30 PM, Robert Floodeen floodeen@cert.org wrote:
Hi, what standards/considerations are implemented in RTIR. By this I mean
things like, ITIL, IODEF, CVE, etc.Robert Floodeen
Member-Technical Staff
CERT Resilient Enterprise Management Team
Carnegie Mellon Software Engineering Institute
Enterprise Risk and Resilience Management | Software Engineering Institute
Rtir mailing list
Rtir@lists.bestpractical.com
The rtir Archives
Best regards, Ruslan.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
v 0.06 is in the wings, hasn’t been released yet (will work with things like XML::IODEF::Simple, etc).
I wrote it, been using it for a number of years now.
hth,On Oct 28, 2011, at 12:03 PM, Ruslan Zakirov wrote:
RTIR can win from using IODEF to export information, but it’s not implemented.
Wes
claimid.com/wesyoung
soc@ren-isac.net
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.16 (Darwin)
iEYEARECAAYFAk6q1xEACgkQKezpZd226UYbCgCfY2V2A6L422WLP5qy4Emcjeiy
7iEAnRmsRKCdohi28gk+6KNnycXbvgPW
=Ym0z
-----END PGP SIGNATURE-----
Hi,
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
- un-wraps IODEF xml and maps to custom fields
- generates an IODEF message based on your Incident or Incident Report
v 0.06 is in the wings, hasn’t been released yet (will work with things like XML::IODEF::Simple, etc).
I wrote it, been using it for a number of years now.
Thanks for clarification. Didn’t know about this extension.
hth,
RTIR can win from using IODEF to export information, but it’s not implemented.
Wes
claimid.com/wesyoung
soc@ren-isac.net-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.16 (Darwin)iEYEARECAAYFAk6q1xEACgkQKezpZd226UYbCgCfY2V2A6L422WLP5qy4Emcjeiy
7iEAnRmsRKCdohi28gk+6KNnycXbvgPW
=Ym0z
-----END PGP SIGNATURE-----
Rtir mailing list
Rtir@lists.bestpractical.com
The rtir Archives
Best regards, Ruslan.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
np, we have a vested intrest in a lot of this:
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] Google Code Archive - Long-term storage for Google Code Project Hosting. Oct 28, 2011, at 4:17 PM, Ruslan Zakirov wrote:
Thanks for clarification. Didn’t know about this extension.
Wes
claimid.com/wesyoung
soc@ren-isac.net
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.16 (Darwin)
iEYEARECAAYFAk6uiQkACgkQKezpZd226UZbigCfdJpO74PLjhuZv9tg9c0rcgi2
0bMAoJ0vzjaHty5GZ7fmMrzgC7QnaKww
=ocgj
-----END PGP SIGNATURE-----