• RTIR Tutorial
  • Incident Response Workflow
    • Incident Reports
    • Incidents
    • Investigation
    • Countermeasures
  • Operations with Tickets
    • Creating Tickets
      • Suppress Sending Emails
    • Merging Tickets
      • Technical Details
    • Splitting Tickets
    • Rejecting an IR
      • Rejecting Many IRs at Once (Bulk Reject)
    • Abandoning Incidents
      • Abandoning Many Incidents at Once (Bulk Abandon)
    • Locking
    • Correspondence
      • Reply to Reporters
      • Reply to All
      • Correspond with Correspondent
    • Linking
      • Linking IRs to Incidents
      • Linking Incidents to IRs, Investigations, etc.
    • Resolution
      • Resolving an Incident
      • Quick Resolve
    • Investigation
      • Launching an Investigation
    • Countermeasures
      • Creating a Countermeasure
  • Managing 'RT at glance' and 'RTIR at a glance' Pages
    • Available Portlets
  • Custom Fields
    • IP
      • Searching by IP
  • Glossary

RTIR Tutorial

Incident Response Workflow

RTIR automatically creates four RT queues for tracking incidents: Incident Reports, Incidents, Investigations and Countermeasures.

Incident Reports

Incident Reports is where new reports appear. When a user sends email to the address you set up, RTIR automatically creates an Incident Report (IR), and sets its due date according to SLA rules configured by your Administrator. New Incident Reports appear on the RTIR main page, ordered by due date.

Incidents

Once you've verified that a new Incident Report is valid, you can create a new Incident from it, or link the IR to an existing Incident. RTIR fills in relevant information from the Incident Report, so there's no need to cut-and-paste. If you receive multiple reports about the same issue, you can link all of these reports to the same parent Incident, to keep them together.

Investigation

From an existing Incident, you can launch an Investigation to an outside party, asking them to look into and/or fix a problem. Once again, relevant information from the Incident is filled in when you create the new Investigation, so there's no need to cut-and-paste.

Countermeasures

Countermeasures are used to track any blocks placed on the borders of the network. You can create them from an existing Incident. Some sites don't require countermeasures, so they may be disabled by your Administrator. Countermeasures have several states: pending activation, active, pending removal, removed. These states can be set from sub-menu items on ticket display pages.

Operations with Tickets

Creating Tickets

Suppress Sending Emails

When creating a ticket in RTIR, you can check the "Don't send any emails to correspondents" checkbox, which will suppress all outgoing emails to all correspondents. Note that this works only during creation, and users added later will receive emails as normal based on the system configuration.

Merging Tickets

If it turns out that two Incidents are actually the same (which can occur when, for example, dynamic IP addresses are involved), they may be merged. The merge operation effectively makes one ticket out of two, containing the data and correspondence of both. Only tickets within the queues of the same type should be merged, with the notable exception of merging an Incident Report into an Investigation when a correspondent's reply accidentally could not be recognized as such and thus got misfiled as new Incident Report.

You can find the Merge link on the ticket display page. The Merge page is split into two sections. The first one is a list of other children of the parent Incident(s) of the current ticket. It's empty if the ticket is not linked to any Incidents or if there is no candidate to merge into. By default this page contains only active tickets.

The second box contains other tickets you can merge into. Tickets are grouped by queue, if it's possible to merge the ticket into a ticket in another queue. For example, you can merge an IR into an Investigation. Note that if you merge an IR into an Investigation, the Investigation will always be used as the target ticket.

If the merge completes successfully, you'll be redirected to the target ticket's display page.

When the merge page doesn't have the ticket you're looking for, you can click 'Refine' to adjust the search conditions before returning to the merge page by clicking the 'Merge' tab.

After the merge, the IDs of both tickets point to the target ticket, so you can still use the old ticket's ID in the subject of replies, but RTIR will send new notifications with the ID of the merged into ticket.

The merge operation can't be reversed and should be used with caution.

Technical Details

The merge operation is pretty straight forward, everything that RT can merge from the source ticket is added to the target ticket. When only one value can be selected, RT prefers the value from the target ticket, so the result of the action depends on the direction of the merge: "merge ticket #1 into #2" is not the same as "merge ticket #2 into #1".

When you merge ticket #1 into #2 some properties of ticket #1 are joined with the respective properties of ticket #2: TimeEstimated, TimeWorked, TimeLeft, Requestors, Cc and AdminCc and Links. Duplicated links or watchers will be condensed; if there were links between tickets #1 and #2 then RT will drop them. Other fields from ticket #1 are ignored, such as status, queue or single-value custom fields.

By default RTIR shows only active tickets as candidates for the merge, so you typically will not merge a ticket into one that's been resolved or rejected. However, you can use the Refine Search option to find an inactive ticket. If you do so, note that merging into a resolved ticket is not the same as explicitly resolving the ticket and RTIR will not send notifications or run other scrips.

Users can merge tickets only if they have the right 'ModifyTicket' on both tickets.

You can also access RT's standard merge from an RTIR ticket's 'Advanced' tab. This option allows you to merge any ticket into any other, avoiding 'the same queue type' and other RTIR restrictions. For example, you can merge an Investigation into an IR, or an IR into a ticket in non-RTIR queues. Access checks and permissions still apply. In the normal course of work, this operation should be avoided.

Splitting Tickets

The Split operation allows you to create a new ticket from an existing one. When you click the Split tab, you get a new ticket creation form with information pre-filled from the original ticket, for example Subject, Owner, Correspondents(Requestors), Ccs, AdminCs, as well as the original ticket's history, formatted as text in the message box. You can change any and all values before splitting off the new ticket.

Split tickets can only be created in the same queue as the ticket they're split from.

Note that the split action is implemented with the "create" function and if your RTIR is configured to notify requestors (correspondents) then email will be sent after the split. However you can use "Don't send any emails to correspondents" checkbox from the split page to avoid notifications.

Rejecting an IR

Rejecting means "we're not going to work on this report." There are several reasons to do this: the ticket is spam, problem wouldn't be solved, it's out of scope, etc. Rejected tickets are still available for searches and can be reopened, but RTIR's default interfaces are designed to hide such tickets, so people can concentrate on new and open tickets.

When you click the Reject tab on the ticket display page you'll see the 'Reject Incident Report' page with a box for a message and other common input fields. You can write a message and choose whether it would be comment or response. By default correspondents don't receive comments. You submit the form and RTIR sets the status of the ticket, records the message and unlinks the IR from any Incidents.

If you don't want to write any comment or change any properties of an IR when rejecting, you can submit the reject form immediately or use the Quick Reject tab and reject the current IR without even opening the reject form.

Rejecting Many IRs at Once (Bulk Reject)

On the RTIR home page at the top right corner of 'New unlinked Incident Reports' you'll find a Bulk Reject link, which allows you to reject many tickets at once. On the Bulk Reject page, you can check/uncheck all tickets displayed or you can select individual IRs. Click the Reject button to reject the selected tickets and remain on the Bulk Reject page or click Reject and Return to reject the selected tickets and return to the RTIR home page.

A link to Bulk Reject is also available in the menu of searches for Incident Reports, so you can go to RTIR's Incident Reports menu, refine search conditions, and go to Bulk Reject from the search results page.

Using this interface you might unknowingly reject IRs that have links to Incidents, so the search results on the Bulk Reject page have a 'Has Incident?' column which indicates whether an IR is linked to an Incident. However this column is informative only and you still can reject IRs that are linked to an Incident.

Using the Bulk Reject interface, you can reject IRs you own or that are unowned, but you can't reject IRs that are owned by someone else. IRs owned by others will be skipped with a warning even if you selected them.

Abandoning Incidents

This operation is quite similar to rejecting an IR, but when you're abandoning an Incident you also reject IRs, resolve Investigations and remove Countermeasures linked to it.

Once you open the Abandon page under the Incidents tab you see a list of its children grouped by queue. You can select children with checkboxes and only children you've selected will be rejected, resolved or removed.

The Incident's Resolution is set according to the %RTIR_CustomFieldsDefaults config option. By default its value is "no resolution reached," however, you can choose any value you'd like to.

You can write a message that will be added to the selected children as a comment or response according to value of the 'Update Type' field.

When you submit the form, RTIR updates the selected tickets and then checks the state of the Incident's children to decide whether it's OK to abandon it or not. In the simplest case the Incident you're abandoning has children that aren't linked to any other open Incident. RTIR marks the Incident as abandoned if all children are inactive (resolved, rejected or removed) otherwise you see a notice "State of the Incident left unchanged; not all children were updated."

RTIR supports IRs linked to many Incidents and in this case abandoning is a little bit trickier. When you're abandoning an Incident linked to an IR that is linked to another open Incident, RTIR doesn't reject the IR, but adds a comment to the IR noting that the Incident has been abandoned while this ticket is still linked to an open Incident and left unchanged. In this situation the original Incident is successfully abandoned.

Abandoning Many Incidents at Once (Bulk Abandon)

The Bulk Abandon subtab under the Incidents tab allows you to abandon multiple Incidents at once.

Locking

Note that this functionality is available only when the RT::Extension::TicketLocking extension is installed.

An automatic lock is created whenever a user performs an action on a ticket that takes multiple steps (unless a hard lock is already in place for that ticket). The following actions produce an auto lock:

    - Edit
    - Split
    - Merge
    - Advanced
    - Reply
    - Resolve
    - Reject
    - Comment
    - Remove

Locks are advisory: if a ticket is locked by one user, other users will be given a notification (in red) that another user has locked the ticket, with the locking user's name and how long he has had it locked for, but they will still be allowed to edit and submit changes on the ticket.

An auto lock is removed once the user is done with whatever he was doing on the page (e.g., when he clicks "Save Changes" on the Edit page). It is also removed if the Unlock link is clicked from a page that generated an auto lock.

For more information, see RT::Extension::TicketLocking.

Correspondence

Reply to Reporters

This operation lets you send a message to all of the parties who created IRs. You may exclude individual recipients by removing the check next to their name.

Reply to All

This operation lets you send a message to all of the parties who created IRs, those involved in the Investigation, and those involved in the Countermeasures. You may exclude individual recipients by removing the check next to their name.

Correspond with Correspondent

This operation lets you send a message to the parties involved in an Investigation. This is available when you "Reply to All" on an Incident.

Linking

Linking IRs to Incidents

When creating a new IR, you may enter the ID number of an Incident in the "Incident" field. This will create a link from the IR to the Incident.

If you have an existing IR, you can link it to an Incident by clicking the "[Link]" button next to the "Incident" field. You may also create new Incidents and link them to the IR by clicking the "[New]" button next to the "Incident" field in the "The Basics" section of the IR display.

Linking Incidents to IRs, Investigations, etc.

You may link Incidents with existing Incident Reports, Investigations, Countermeasures, and Articles. On the Incident display page there are sections for each of these, each with a Link button and the list of already-linked tickets. Clicking on Link lets you link one or more tickets of that type to the Incident.

Clicking on Create (or in the case of Investigations, Launch) lets you create a new ticket and link it to the Incident automatically.

Resolution

Resolving an Incident

Once you open the Resolve page under the Incidents tab you see a list of its children grouped by queue and an update form. The children you select will be resolved with the incident.

You can write a message that will be added to the selected children as a comment or response based on the value of the 'Update Type' field.

When you try to resolve an Incident, RTIR checks the state of that Incident's children to decide whether it's OK to resolve it or not. In the simplest case, the Incident you're resolving has children that aren't linked to any other open Incident. RTIR marks the Incident as resolved if all children are inactive (resolved, rejected or removed) otherwise you see a notice "State of the Incident left unchanged; not all children were updated."

Quick Resolve

Incidents and IRs have a "Quick Resolve" feature which changes a ticket's status to 'resolved' immediately. No intermediate form is presented and you don't need to provide a message, note time worked, attach files, etc.

Investigation

Launching an Investigation

To launch a new Investigation, create a new ticket in the Investigations queue. You will be required to provide one or more correspondents.

Countermeasures

Creating a Countermeasure

To create a new Countermeasure, create a new ticket in the Countermeasures queue. You will be required to link the Countermeasure to an Incident.

Managing 'RT at glance' and 'RTIR at a glance' Pages

You can add, delete, or reorder portlets on the RT and RTIR at a glance pages using preferences. You can either click 'Edit' on the portlets or go to Logged in user -> Settings and then go to the section you want to customize.

The default home pages are split into two columns, however you can leave one column empty if you need a wider one-column layout.

Available Portlets

QuickSearch

Lists queues with the number of active tickets in them. Allows you to quickly jump to all active tickets in a queue or to tickets with a particular status.

Other

There are more portlets you can use with self-descriptive names.

Custom Fields

IP

This custom field allow you to associate IPs or IP ranges with a ticket. You can enter information in several formats:

* IP - single IP with decimal units separated by dot;

* IP range - interval separated with -, for example 192.168.20.0-192.168.20.255, both ends of the interval are included in the range;

* CIDR block - IP range in the CIDR format, for example 172.16/24, as you can see short form is also supported, RTIR converts ranges in this format to the IP range form.

You can set the value of the custom field on create or later with an edit. You can enter several values at once, one per line, or comma-separated, or you can mix different formats. Values are validated for proper format when you submit and any errors are reported. When tickets are created, IPs and CIDR blocks are also parsed from the body of the message and added to the ticket.

Searching by IP

You can use the same input formats to search by IP, CIDR or range. On a query builder page you can use the IP field to enter an IP, range or CIDR and add the condition to the current query or return back to search results. You should see tickets that have at least one IP from the range. But you should note that validation of the input is not implemented in the query builder so you may enter invalid values. Double check the format if you don't see the tickets you expect in search results.

Glossary

active ticket

An active ticket in RTIR is a ticket with a status that indicates work will still be done on it. RTIR uses this to determine what tickets should be shown by default in various searches and pages in the user interface.

The available active statuses are defined as part of the RTIR configuration and differ for each queue (see %Lifecycles in RTIR_Config.pm and RT_Config.pm for more information). Active tickets in the incidents queue, for example, are those with a status of open. In the Countermeasures queue, tickets can be active or pending removal. These values are configurable and may be different on your system.

inactive ticket

An inactive ticket in RTIR is a ticket with a status that indicates work on it is complete. RTIR uses this to filter tickets out of various searches and pages in the user interface, although the tickets can still be found with searches.

Inactive statuses are defined as part of the RTIR configuration and differ for each queue (see %Lifecycles in RTIR_Config.pm and RT_Config.pm for more information). Inactive tickets in the incidents queue, for example, can be resolved or abandoned. In the Countermeasures queue, tickets can have a status of removed. These values are configurable and may be different on your system.

← Back to index