Lab 1.2: Default Jira Ticket Settings¶

Est. Time: 30 minutes

Goals:

Set up your Resolutions
Create a Workflow
Create a Screen
Create a Request Type

Instructions¶

Let’s start by updating the ticket resolutions.
1. Navigate there by going to Settings -> Work items -> Work item attributes: Resolutions
2. How to navigate there
The resolutions already here are primarily for software dev, not necessarily SOC. Let’s add some new ones and delete some ones that we aren’t going to use.
1. Note: Jira has recently made a change that prevents you from deleting or modifying system-managed resolutions. You won’t be able to delete or rename specific resolutions, like “Done”.
2. Let’s delete “Won’t Do” and both “Declined” resolutions. We aren’t going to just choose not to do a SOC ticket or decline a SOC ticket. You’ll get a confirmation dialog each time asking you to re-map any tickets with that resolution to a new value; if this is a new Jira Space that doesn’t matter, so select any other resolution of your choosing.
3. Leave “Duplicate” there, it would be useful for classifying duplicate alerts.
4. We’re going to create a new “Done” to be more specific. You can name it to your preference but it should be something to inform that the activity is non-malicious; For example:
  1. Let's also make this our default option since this is what you’ll likely see the most of.
  2. Create another resolution for the opposite, something to inform that this was a true positive event, some form of malicious activity.
    1. For example:
Here’s how we’re going to understand the statuses we just created:
1. “Done – Non-Malicious” means the SOC ticket has been investigated and analysts determined that this event isn’t malicious in nature.
2. “Done – Malicious” means the SOC ticket has been investigated and analysts determined that this is a true positive event.
3. “Duplicate” just means this ticket is a duplicate of another which sometimes can happen if an action continues to create alerts.
4. “Done” is sort of our catch-all for anything that is maybe an internal ticket or just doesn’t fall into the other above categories.
  1. Note that this “Done” likely can’t be changed since it’s system-managed.
5. Let’s create a default workflow for Incident Management, which is the workflow we will later apply to our incoming alerts.
6. Select “Workflows” from the menu. Also note that there is an “Active workflows” section and an “Inactive workflow” section. If you leave the editing view and after can’t find the workflow you’re working on, make sure to check in “Inactive workflows”.
  
  Active vs Inactive workflows
7. Start by viewing the workflow “SOC: Incident Management workflow for Jira Service Management” to get an understanding of the default. Click the triple dot menu to the right side and select “Edit”.
  1. The “SOC” in “SOC: Incident Management workflow for Jira Service Management” will be replaced with your Space key. So if your key is “Training”, the workflow you’re looking for will likely be named “Training: Incident Management workflow for Jira Service Management”
  2. You may also receive a Jira pop up about how you’re using the “new workflow editor”- that’s fine, that’s what you want.
8. You now have a workflow you can edit. There are two view modes; Text and Diagram. Personally I prefer to switch to “Diagram” view if you are put into Text mode by default.
9. Avoid renaming the statuses already in this workflow because that affects EVERYTHING they are associated with. Instead lets add new statuses and connect them into the workflow.
  1. This workflow doesn’t look like an incident management workflow to me. Let’s fix that.
  2. We don’t need “Pending”, so click on that status bubble and click “Remove status”. This will also delete the transitions.
  3. Do the same for the “Canceled” and “Completed” status bubbles.
  4. Jira now shows us that we don’t have a complete flow by highlighting the orphaned statuses. That’s fine, we are going to connect everything back together now.
  5. Let’s add a connection between “Work in Progress” to “Closed” by dragging from the bottom-most dot of Work In Progress to the top most of Close.
10. This prompts you to select or create a transition. This transition value will show up when someone goes to modify your ticket status. Let’s name this “Close”.
11. Your workflow should now look something like this:
12. These definitely aren’t all the scenarios for working a SOC ticket. With the help of the tips below, create the necessary statuses and transitions until your workflow looks like something this:
13. A few notes to keep you on track:
  1. To add a new status, click “Add status” in the top left of your workflow
    - Note: Jira now requires statuses to feature a Category of To Do, Done, or In Progress. Select the one most resembling your new status. 2. You may need to create a few transitions. That’s OK. We can always edit and change them later if necessary. 3. There may already be a transition called “Investigate”. You can reuse this, but it’s a bit confusing. You will need to select that transition, and select the statuses that can use it in the “From” section. See an example below:
  2. The default Investigate “Investigate” transition uses a Screen. You can see this under the “Request Input” section. This screen just prompts the user to add an assignee. Let’s drop this requirement for now. Let’s remove that.
    1. Select the transition, expand “Request Input” and delete that rule.
    1. You could use a screen input like this to require analysts to assign themselves to a ticket when they move it from Open to Work in Progress, but since we’re re-using this transition, we don’t want this.
      1. As one last step, I’m going to change the “Work in progress” status to be “Under Investigation” because I feel like that suits our purposes better.
        
        Select the status, and next to the Name field click the edit icon.
  3. Select the “Create a new status” option, and then name it “Under Investigation” and click Update. While we may not use “Work in Progress” in the future, renaming statuses may have unintended ramifications.
14. Something to note is that if you close a ticket, by default you won’t have permissions to re-open it, which I do not like. Sometimes a ticket is closed accidentally or needs to be reopened. To fix this you can do one of two things:
  1. Create a new transition called something like “Re-Open” that goes from “Closed” to “Under Investigation”.
    - Why this is the preferred method, and why shouldn’t we just re-use the Investigate transition?
      
      It all has to do with the transitions. Transitions can have actions or automations associated with them- so by future proofing this workflow with a “Re-open” transition, you leave yourself open to developing automations or improvements to track, alert, or take actions when tickets are re-opened from a supposedly completed state.
      
      Additionally, when you have a separate “Re-open” transition, rather than using the “All statuses can transition to” checkbox, you have a much cleaner view when changing statuses on a ticket. For example, when changing the status on a new ticket, if you go with the checkbox method this is what you’ll see:
      
      Two different transitions to “Under investigation”, one is your transition, the other is created by the checkbox since every status, including “Open” can transition to “Under investigation”. This may just break your workflow if you have automations tied to the “Investigation” transition and a user instead clicks the one created by the checkbox.
  2. Edit the workflow to allow all statuses to transition into “Under Investigation”. To do this, click on the “Under Investigation” status and check the box labeled “Allow all statuses to transition to this one”.
  3. When you’re done, select “Update workflow” in the top right. You’ll be presented with a summary of the changes you are making. Confirm by selecting Update.
  4. Your workflow should now look something like this:
Now that you have a basic workflow, we need to make a few other items, namely request types and screens, to interact with this workflow or vice versa.
Let’s start with the Screen for ticket resolutions. This is the pop-up that will show when you go to close your ticket.
1. If still in the workflow viewer, click Close. Navigate to the Screens menu and select “Add screen” in the top right and name it something like “SOC Ticket Resolution”
  - Navigating there
2. Once you add your screen, you will need to search for your it and select “Configure” from the triple dot menu. This takes you to the screen configuration menu where you can select the fields you want to be part of that box that will show upon a ticket being marked as Closed.
3. Select at least the following fields:
  1. Resolution
  2. Assignee
  3. Log Work
4. Your screen should look something like the below. It should be saved by default (no save button).
You have a screen, but as of right now it’s not in use. It needs to be assigned within your workflow inside of a transition. Return to the SOC workflow you made a few minutes ago.
1. On the side menu, go back to “Workflows” and once again edit your Incident Management workflow for your space.
2. Click on your “Close” transition under “Request input” select “Add request input rule” and specify the Screen you just created.
3. When you click on the status is should now show your Screen:
4. Make sure to update your workflow.
5. Last but not least, we need to create a Request Type. Under the main settings menu (top right cog wheel) return to the Space settings page and in the side menu go down to “Request types” then select “Incidents” under the categories.
6. How to navigate there
7. There will likely be couple pre-existing request types. We are going to make a new one called something like “SOC Investigation”.
8. Select “Create request type” and go with “Create blank” and name it something like “SOC Investigation”; make sure that [System] Incident is specified as the Issue type. For “Portal group”, just select “Common Requests”. Click “Add”.
  1. “Portal group” is used to determine what request types are shown to customers via the Jira ticketing portal. This can be customized, for more detail on how, see here.
    1. The next page takes you to a builder that lets you define exactly the fields you want to be filled in when someone or something submits a ticket.
    2. The “Instructions” panel is a way to provide a note to anyone submitting a ticket of this type. In this case for test purposes, I put: “Please include a timestamp, hostname, username, and/or IP address of the affected device(s), as well as any other relevant indicators.” That note will be displayed to a customer submitting a ticket.
    3. Populate the details as you please, but make sure you have at least the fields: Instructions, Summary, and Description
  2. To add new fields, drag them from the right side of the screen to where you would want them to appear on the request form.
  3. I kept mine very simple. I will be populating most of the fields I need when the alert comes from the SIEM, this is just what it will look like for users submitting manually. You can also update fields in the ticket itself as a user, so again, this is just setting the initial prompt to create the ticket.
9. Save the changes and move over to “Work item view”. This tab will show how the ticket looks when viewed inside of Jira. You will see this view a lot as an analyst.
  1. Within this view you will see a couple subheadings: “Context fields”, and “Hidden when empty fields”. Context fields will be prominent and should be information important to see at a glance. The other fields, Hidden when empty, are just that; hidden from view when empty, and will generally appear under a “Show more” option on the ticket.
  2. This is one of those ad-lib sections; feel free to customize your ticket’s feel as you see fit, or copy some variation of how I did mine. Just make sure you include a few key fields:
    - Summary and Description will automatically be included as they are part of the Request form.
    - SLAs , Assignee , Priority , and Request Type are particularly useful under Context fields. Context fields will show up on the side panel of an open work item. 3. I also set a number of fields to be hidden when empty by dragging them under that subheading. You can do as you please here, or just copy what I did. 4. This is what my completed Request type looks like on the Work Item view:
  3. Make sure to save your changes when done.
  4. Finally move over to the “Workflow statuses” tab.
1. Here you you can customize if you want fields to display differently to customers than to your analysts. If you have a status named “Incident” or “Wow this host is on fire”, you could rename those here to show as something different to customers.
2. Finally, we have a new default ticket workflow, featuring updated statuses and resolutions that match out goals. In the future, your SOC will be able to use those key Jira fields to track very important metrics.
3. Make sure your new ticket workflow functions as intended. Navigate to your Space and create a ticket; Step it through the paces!
4. To get back to your Space itself, the easiest way is to click the Jira logo in the top left and select your Space from “Spaces” or “Recent spaces”
5. Create a [System] Incident issue type and use your new request type.
  1. Can be done either through the “Create” option in the top of the screen, or within the Space itself.
6. When you create the ticket, the fields available to you will be dictated by your Request type (and you will also see your instructions!)
7. Click Create, then either refresh or get to the ticket via a pop up from Jira.
8. Now move it through the statuses to make sure your workflow and transitions show up how you want them to.
9. Lastly when you mark your ticket as closed, you should see your resolution Screen pop up with the fields you selected.
  
  The Closure transition screen

Help and Tips¶

There are lots of templates available for Request types; clicking on one can show you what it entails. This could be helpful if you need to create more for specific use cases.
Tip: If you need to make sure that your Request type is using your newly created workflow (it should be), a quick way to check this is to go to that Request type and select “Manage workflow” and then “Replace with existing”. The workflow it shows you is the one it is using.

Lab 1.2: Default Jira Ticket Settings¶

Instructions¶

Help and Tips¶

Additional References¶