[prev in list] [next in list] [prev in thread] [next in thread]
List: rtir
Subject: Re: [Rtir] New RT/IR User
From: Carlos Fuentes Bermejo <carlos.fuentes () rediris ! es>
Date: 2013-04-01 12:03:04
Message-ID: 73320A3F-3C73-4B88-8FCA-A6ED2D310AB8 () rediris ! es
[Download RAW message or body]
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@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@lists.bestpractical.com [
> > rtir-bounces@lists.bestpractical.com] on behalf of Kevin Holleran [
> > kdawg44@gmail.com]
> > Sent: 28 March 2013 19:59
> > To: Carlos Fuentes (Forwarding)
> > Cc: rtir@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@gmail.com<mailto:
> > kdawg44@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@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@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@lists.bestpractical.com
> > http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rtir
> >
> > _______________________________________________
> > Rtir mailing list
> > Rtir@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
> >
> >
_______________________________________________
Rtir mailing list
Rtir@lists.bestpractical.com
http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rtir
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic