[Rtir] New RT/IR User
Carlos Fuentes Bermejo
carlos.fuentes at rediris.es
Mon Apr 1 08:03:04 EDT 2013
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
> <James.McLoughlin at ja.net>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: rtir-bounces at lists.bestpractical.com [
>> rtir-bounces at lists.bestpractical.com] on behalf of Kevin Holleran [
>> kdawg44 at gmail.com]
>> Sent: 28 March 2013 19:59
>> To: Carlos Fuentes (Forwarding)
>> Cc: rtir at lists.bestpractical.com
>> 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 <kdawg44 at gmail.com<mailto:
>> kdawg44 at gmail.com>> 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 <kdawg44 at gmail.com> 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 <james.davis at ja.net> 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
>> Rtir at lists.bestpractical.com
>> http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rtir
>>
>> _______________________________________________
>> Rtir mailing list
>> Rtir at lists.bestpractical.com
>> 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
>>
>>
More information about the Rtir
mailing list