[Rtir] New RT/IR User

Fri Mar 29 09:41:15 EDT 2013

Kevin,

I installed RT4 and RTIR as well. Our team didn't really like the RTIR workflow either, so you're not alone. I take RTIR's workflows to be a great example of how one team does it, but that doesn't mean it's right for every team. We still have RTIR installed but are considering removing it and only leaving the parts we like (e.g. the makeclicky stuff)

Our workflow is to use a single ticket from start to finish. An alert comes in and is triaged. If it requires further investigation, we do so with the original ticket. If more alerts come in and are discovered to be related to the same event/incident, we just merge the tickets.

The advantage we see in our workflow is twofold. First, you only ever have to remember one ticket number. That's handy for forwarding documentation into RT for archival. Second, there is less administrative overhead in working an event/incident since we don't have to create several tickets and maintain a mental map between them.

The great news is that RT is configurable and extensible enough for you to implement any workflow your heart desires.

Hope my description helps.

-keith

> -----Original Message-----
> From: rtir-bounces at lists.bestpractical.com [mailto:rtir-
> bounces at lists.bestpractical.com] On Behalf Of James McLoughlin
> Sent: Friday, March 29, 2013 5:13 AM
> To: Kevin Holleran; Carlos Fuentes (Forwarding)
> Cc: rtir at lists.bestpractical.com
> Subject: Re: [Rtir] New RT/IR User
> 
> 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
> 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
> --
> --
> 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
> 