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

Reply via email to