New RT/IR User

RTIR
1

Good morning,

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.

Also, my primary goal for this is to leverage the IR piece. I would like
to utilize the regular RT piece potentially for some other items if I can
get the workflows the way I want them but we use a different system for
normal trouble tickets & RT would not be used for that.

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

2

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256On 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)
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

3

Thanks for that. I came across that and its very nice. However, I am
still at the basics of RT and how to set up things like the queues and the
like…

Thanks for any direction to good resources.

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.” - AristotleOn 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)
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
The rtir Archives

4

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.” - AristotleOn 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)
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
The rtir Archives

5

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,
CarlosOn 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)
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
The rtir Archives

Rtir mailing list
Rtir@lists.bestpractical.com
The rtir Archives

6

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<javascript:_e({}, ‘cvml’, ‘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<javascript:_e({}, ‘cvml’, ‘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)
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 <javascript:_e({}, ‘cvml’,
‘Rtir@lists.bestpractical.com’);>
The rtir Archives

Rtir mailing list
Rtir@lists.bestpractical.com <javascript:_e({}, ‘cvml’,
‘Rtir@lists.bestpractical.com’);>
The rtir Archives

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

7

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.” - AristotleOn Thu, Feb 14, 2013 at 4:09 PM, Kevin Holleran 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)
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
The rtir Archives

Rtir mailing list
Rtir@lists.bestpractical.com
The rtir Archives

–

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

8

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 0SGFrom: 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

Thank you for the response, that definitely helps.

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

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

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

9

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

10

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.” - AristotleOn Fri, Mar 29, 2013 at 6:13 AM, James McLoughlin James.McLoughlin@ja.netwrote:

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:(%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
The rtir Archives

Rtir mailing list
Rtir@lists.bestpractical.com
The rtir Archives

–

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

11

Thanks. I agree that the workflow is not necessarily right for our team…
However, I have gone in an changed some things on the back end to make it
more applicable. For what it is, I think it is solid enough for us, I
just want to make sure I understand it properly.

Thanks for your response.

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.” - AristotleOn Fri, Mar 29, 2013 at 9:41 AM, Keith Twombley <Keith.Twombley@avivausa.com wrote:

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@lists.bestpractical.com [mailto:rtir-
bounces@lists.bestpractical.com] On Behalf Of James McLoughlin
Sent: Friday, March 29, 2013 5:13 AM
To: Kevin Holleran; Carlos Fuentes (Forwarding)
Cc: rtir@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@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.commailto: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
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
822340tel:(%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

12

Hiya Keith,

Just a little comment about your comments.

I know the workflow can be tedious and difficult to understand, but you have to know from where RTIR is coming. First RTIR was designed by a NREN CERT using a tracking system where they were using one single ticket for everything, like we did in IRIS-CERT, so we saw that as a problem, because these systems brought us several issues handling incidents:

1.- Sharing information: it’s quite common in our environment to getting a single complaint reporting a problem from different IPs (belonging to different of our users), so we need to split the information and send it to the right people, using a single ticket it was quite tedious to do it properly. Protection data law and common sense said us that sharing the kind of information, which we manage, with the wrong people it’s not that good.

2.- Many complaints about a single problems, if you handle with a single ticket, it’s difficult to keep them together, or to keep some relationship between them. Specially when they require a single answer, you don’t want to reply to an automatic system (IDS, …) but if it’s another CERT sending you information, then you will probably want to reply them properly, and give feedback about your issue.

…

When JANET-CERT designed RTIR, they wanted to solve the previous problems and improve the way how they handled incidents, and allow to store the information in a more structured way, this is why I think one of the key things is the RTIR structure, and it’s why the tool is used by most of National/Gob/NREN CERTs/CSIRTs here in Europe, even in some ISPs.

I know it’s not the perfect tool for all the teams, but I don’t think a workflow using a single ticket it would be helpful in my environment. I know RTIR should include mechanisms to make easier the way of how an incident is handled, more documentation with examples and use cases, and …

Best,
CarlosEl 29/03/2013, a las 14:41, Keith Twombley escribió:

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@lists.bestpractical.com [mailto:rtir-
bounces@lists.bestpractical.com] On Behalf Of James McLoughlin
Sent: Friday, March 29, 2013 5:13 AM
To: Kevin Holleran; Carlos Fuentes (Forwarding)
Cc: rtir@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@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.commailto: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
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
822340tel:(%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

Rtir mailing list
Rtir@lists.bestpractical.com
The rtir Archives

13

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,
CarlosEl 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.netwrote:

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:(%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
The rtir Archives

Rtir mailing list
Rtir@lists.bestpractical.com
The rtir Archives

–

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