Hiya Kevin, In a simple way the most used workflow are:
IR -> Incident -> Investigation or Multiple IRs -> Incident -> Investigation or IR->Incident-> Multiple Investigations or Mutiple IRs -> Incident -> Multiple Investigations or IR -> Multiple Incident -> An Investigation per Incident or IR -> Incident or Incident -> Investigation I hope this make more clear what kind of relationship you can hold between IR, Incident and Investigation. Cheers, Carlos El 29/03/2013, a las 14:59, Kevin Holleran escribió: > That was my understanding, its just the link between the Incident Report & > Incident is odd... You have to create an Incident Report, investigate, then > go BACK AFTER you create an incident to tie the incident to the incident > report.... just seems like a better workflow to add 1:M incident reports to > an incident (you could have one incident report turn into an incident or > perhaps three different people report the same behavior & treat it as one > incident) so that confused me. > > Thanks for your help. > > > -- > Kevin Holleran > Master of Science, Computer Information Systems > Grand Valley State University > Master of Business Administration > Western Michigan University > SANS GCFA, SANS GCFE, CCNA, ISA, MCSA, MCDST, MCP > > "Do today what others won't, do tomorrow what others can't" - SEALFit > > "We are what we repeatedly do. Excellence, then, is not an act, but a > habit." - Aristotle > > > On Fri, Mar 29, 2013 at 6:13 AM, James McLoughlin > <[email protected]>wrote: > >> Hello Kevin, >> >> I think that you may be taking the word 'report' too literally. >> In this instance it is used to describe 'new information that has been >> received'. >> >> Take the following example: >> "We have had a report that there might be scanning coming from x.x.x.x. >> Please can you investigate. >> The Janet work flow would then compromise of the following: >> >> 1. Read 'incident report' (new information that has been received). >> 2. Validate >> 3. Decide whether to open an incident and start an investigation >> >> So an incident report is : a report of an incident occurring >> >> >> -- >> Jamie Mcloughlin 0870 850 2340 PGP: FF7746C1 >> JANET CSIRT (+44 1235 822 340) >> Lumen House, Library Avenue, Didcot, Oxfordshire, OX11 0SG >> >> ________________________________ >> From: [email protected] [ >> [email protected]] on behalf of Kevin Holleran [ >> [email protected]] >> Sent: 28 March 2013 19:59 >> To: Carlos Fuentes (Forwarding) >> Cc: [email protected] >> Subject: Re: [Rtir] New RT/IR User >> >> Good afternoon, >> >> I have configured both an RT/IR instance for Incident Response & an RT4 >> instance that we are going to use for a handful of approval workflows. >> Through this process, I think I understand a bit better how RT works. I >> have also reviewed the JANET.pdf document which led me to the below >> workflow. >> >> However, I am still confused... >> >> Incident Report ---validate---> Incident ---> Investigation >> |--------->Blocks >> (interface with sys admins/network ops) >> >> >> Now, this logic seems flawed because there is a link when creating an >> Incident Report to tie it to an incident, but not a in reverse. So this >> would tell me that the INCIDENT comes first, & from that an incident >> report..... >> >> Is the definition of incident report 1.) a report of an incident >> occurring or 2.) post-investigation wrap up of what happened? >> >> If it is #2 then the workflow would be: >> >> Incident ----validate---> investigation -----------> Incident Report >> (wrap up) >> |----> Blocks >> >> It seems like #1 based on the Janet Workflow and the fact that the >> Resolution field is in Incident not Incident Report but I do not understand >> why the link to an incident is set when the incident report is created. >> >> Thanks for your help in understanding this. >> >> -- >> Kevin Holleran >> Master of Science, Computer Information Systems >> Grand Valley State University >> Master of Business Administration >> Western Michigan University >> SANS GCFA, SANS GCFE, CCNA, ISA, MCSA, MCDST, MCP >> >> "Do today what others won't, do tomorrow what others can't" - SEALFit >> >> "We are what we repeatedly do. Excellence, then, is not an act, but a >> habit." - Aristotle >> >> >> On Thu, Feb 14, 2013 at 4:09 PM, Kevin Holleran <[email protected]<mailto: >> [email protected]>> wrote: >> Thank you for the response, that definitely helps. >> >> >> On Thursday, February 14, 2013, Carlos Fuentes Bermejo wrote: >> Hiya Kevin, >> >> First answer the question about blocks, the blocks are used to interact >> with the Network guys, i.e. for asking a block of an IP(s) or port in the >> network, so you will be able to keep tracking of the talks with NOC guys, >> and all the actions you take over the network to solve the incident. In >> case you see the block queue is not useful for you, you can deactivate in >> the RTIR config file. >> >> About incidents, if you have two complaints in your incident reports queue >> related to two different IPs of your institution, or related to two >> different issues, you won't want to open only one single incident to handle >> everything, and mix the information you can receive, what you have to do is >> to open two different incidents, and each IR will be linked to its own >> incident, handling them separately, and launching investigations to fix the >> problems. You can be in front of cases where you have a incident report >> asking something, where you will have to open an incident, but an >> investigation won't be needed as you are acting as a security helpdesk team. >> >> I hope it clarify a bit more your workflow understanding, as James said >> the document is a bit basic, and I think it should be more complete, having >> use cases and more examples. >> >> Cheers, >> Carlos >> >> Sent from my iPad >> >> On 14/02/2013, at 21:12, Kevin Holleran <[email protected]> wrote: >> >> Thanks again. I am not understanding some of the workflow. >> >> An incident can be defined. One (or more?) incident reports can be linked >> to the incident. One or more investigations can be linked to the incident. >> What are the blocks for? >> >> Thank you! >> >> >> -- >> Kevin Holleran >> Master of Science, Computer Information Systems >> Grand Valley State University >> Master of Business Administration >> Western Michigan University >> SANS GCFA, SANS GCFE, CCNA, ISA, MCSA, MCDST, MCP >> >> "Do today what others won't, do tomorrow what others can't" - SEALFit >> >> "We are what we repeatedly do. Excellence, then, is not an act, but a >> habit." - Aristotle >> >> >> On Tue, Feb 12, 2013 at 10:33 AM, James Davis <[email protected]> wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA256 >> >> On 12/02/2013 15:20, Kevin Holleran wrote: >> >>> I just set up RT 3.8 with RT/IR. I am new to this and need to ramp >>> up quickly. What is a good resource rather than just fumbling >>> around and learning through trial and error or stumbling through >>> bits and pieces of documentation? I noticed the RT Essentials book >>> but I was wondering if it was dated based on the publication date. >>> >> http://bestpractical.com/static/rtir/janet-workflow.pdf is a useful >> resource that explains the RTIR workflow[1]. >> >> James >> >> 1. I may be a little biased. >> >> - -- >> James Davis 0300 999 2340 (+44 1235 822340 >> <tel:%28%2B44%201235%20822340>) >> Senior CSIRT Member >> Lumen House, Library Avenue, Didcot, Oxfordshire, OX11 0SG >> -----BEGIN PGP SIGNATURE----- >> Version: GnuPG v1.4.11 (Darwin) >> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ >> >> iF4EAREIAAYFAlEaYL0ACgkQjsS2Y6D6yLyQWAEAlUIuiH+glbsOFXEQP45B9zXI >> SAK+txSS2PeVfWcESMIBANIJ5SNcMH+hxXEfKEEeY923XsgoxPEIBgIr8rbi7ryE >> =m8+Z >> -----END PGP SIGNATURE----- >> >> Janet(UK) is a trading name of Jisc Collections and Janet Limited, a >> not-for-profit company which is registered in England under No. 2881024 >> and whose Registered Office is at Lumen House, Library Avenue, >> Harwell Oxford, Didcot, Oxfordshire. OX11 0SG. VAT No. 614944238 >> >> _______________________________________________ >> Rtir mailing list >> [email protected] >> http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rtir >> >> _______________________________________________ >> Rtir mailing list >> [email protected] >> http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rtir >> >> >> -- >> -- >> Kevin Holleran >> Master of Science, Computer Information Systems >> Grand Valley State University >> Master of Business Administration >> Western Michigan University >> SANS GCFA, SANS GCFE, CCNA, ISA, MCSA, MCDST, MCP >> >> "Do today what others won't, do tomorrow what others can't" - SEALFit >> >> "We are what we repeatedly do. Excellence, then, is not an act, but a >> habit." - Aristotle >> >> >> >> Janet(UK) is a trading name of Jisc Collections and Janet Limited, a >> not-for-profit company which is registered in England under No. 2881024 >> and whose Registered Office is at Lumen House, Library Avenue, >> Harwell Oxford, Didcot, Oxfordshire. OX11 0SG. VAT No. 614944238 >> >> _______________________________________________ Rtir mailing list [email protected] http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rtir
