This guide will walk through some additional details of our JIRA integration.

Benefits of using the JIRA integration

Our updated JIRA integration automates compliance checks and evidence collection forfive requirement categories (which are presented as tests in Secureframe).

1. Vulnerability Tracking: Security vulnerabilities are tracked to resolution, as per applicable SLAs
   • Example vulnerability sources: internal vulnerability scans, external vulnerability scans, ASV scans, penetration tests, bug bounty programs, inbound reporting, and vendor announcements
2. Security Incident Tracking: Security incidents are tracked to resolution, as per applicable SLAs
3. System Change Tracking: Significant system changes are tracked to deployment, as per applicable SLAs
   • Note: This is not required for HIPAA compliance
   • Example system changes: general infrastructure changes, network & router changes, firewall changes
4. Access Tracking: System access changes are tracked to resolution, as per applicable SLAs
   • Example access changes: access onboarding, access offboarding, permission modifications, and transfers
5. Nonconformity and Corrective Action Tracking: Nonconformities are tracked and resolved via corrective actions, as per applicable SLAs
   • Note: Requirement is specific to ISO 27001
   • Example access changes: access onboarding, access offboarding, permission modifications, and transfers

Feature 1: Issue Tracking

By defining your JIRA issue label(s) within Secureframe on a per requirement basis, our integration pulls in all of your issues with matching label(s). This shows auditors that you properly track issues pertaining to these requirement categories.

Feature 2: Timely Issue Close Out

Additionally, for each label defined within Secureframe, you can specify an SLA (# in days) for that label. Secureframe flags issues that remain open longer than the specific SLA for that label. This shows auditors that you close out issues in a timely manner.

• Note: Most compliance frameworks require an SLA to be in place for medium, high, and critical vulnerabilities and for all security incident priorities. Nonconformities are specific to ISO 27001 and SLAs are required.

By taking advantage of these two features, you can avoid taking many screenshots that are traditionally required for audits. Our integration can prove that issues are tracked (labels) and closed out in a timely manner (SLAs).

Understanding JIRA labels

Within JIRA, you can assign labels to issues. This is useful for categorizing issues. You can specify labels in use within Secureframe to pull in tickets with the respective labels.

Important Note: Each row should contain only one Label. If you need to add additional labels, use the "Add label" button below. 

How to enable the JIRA functionality

1. Within "Monitoring," navigate to "Integrations" > "JIRA - Settings"
2. Edit or acknowledge the "Testing Start Date." This date defaults to the date that you connected JIRA in Secureframe. It can be used to prevent tickets prior to a certain date from being pulled into Secureframe.
3. For each requirement category you wish to automate, specify one or more labels.
   • For each label, you can specify data for additional fields - these fields are defined in Secureframe and do NOT pull from JIRA.
     • SLA in days: You can assign an SLA to take advantage of Feature 2 mentioned above
       • Note: Secureframe will display failing tickets underneath tests when those tickets exceed specified label-SLA pairs. Even when theses issues are closed, if it breached an SLA, the test will remain failing for your audit as it would count as an exception for sampling evidence. Reverting the ticket to passing after correcting it after it breached SLA would give false confidence going into audit. Please be mindful of this as an auditor could bring this up during your audit and ask for justification. If this particular ticket that has fallen out of SLA is a non-compliance item, you may choose to ignore the result.
     • Priority: You can specify the priority of the label.
     • Source/description: You can specify other details about the label. This field can be useful for giving auditors context on the label’s purpose.
   • If you do not specify a label for a requirement category, the equivalent test called out underneath the requirement category will remain an upload.
   • Important Note: If the SLA field is left blank for a label it will treat that SLA as ZERO, which may cause tickets under that label to appear as failing evidence in tests
4. Example label setups/strategies for Vulnerability Tracking

Example 1: Tracking all medium+ vulnerabilities to resolution under a single label

Example 2: Tracking all vulnerabilities to resolution under multiple labels, segmented by priority

Example 3: Tracking all vulnerabilities to resolution under multiple labels, segmented by source

JIRA API permissions

We request the following permissions when you connect to Jira. No additional permissions are needed to opt into ticket tracking.

Permissions, Fields Pulled, Controls, and Automated Tests

1. Click the provided link or navigate to the “Integration” page.
2. Select the “Available” tab.
3. Search for the integration.
4. Click “View Details”.

Configuring JIRA resolution fields

With this integration, Secureframe allows you customize the resolution field to match your project types. In one scenario a JIRA project might be resolved by a "Done" status where another project is resolved by "Completed" status.

To configure the resolution fields start on the Jira side and find a relevant Jira project and issue type from an existing ticket.

From here, a valid resolved status can be found in a few different ways:

• If the ticket is already complete, look at its current status
• Otherwise, look at the status transition dropdown on the ticket. From here, the valid resolved status should be visible as an option in the dropdown. Alternatively, you can select View workflow to see the entire workflow and choose the correct resolved status from there.

In these examples below, Done is the last status in green, and in the workflow view, it is the final status with transition arrows pointing to it.

Each customer may have different projects that will each have different workflows (Ex, Done vs Completed) so the project selection matters when you choose as a resolution status.

Finally, under Resolution fields, select the valid resolved status in the status field. Since these fields can different by project and Jira does not provide a way to determine the field via their API, we display all available statuses for the selected project, and it will be the user's responsibility to select a valid status.

 

Ticket Filtering

Before we pull all tickets into Secureframe, we do some basic filtering based on the following criteria:

• Were created after the Testing start date
• Have labels
• Share at least one label with any of the labels configured in the Jira connection’s settings in Secureframe (ex, penTest, onboarding, offboarding).

Frequently Asked Questions (FAQ)

I have my configuration set properly, but the test are still failing?

• A common issue with JIRA configuration is having more than one label applied in the same field.
• Each row should contain only one Label. If you need to add additional labels, use the "Add label" button below. 

We have tasks integrated with Jira and they show as failed under the Vulnerability & threat tracking and resolution (Jira) test, but I can see they have been marked as Done or Canceled in Jira?

• In this scenario, we recommend checking the Asset Inventory > Tickets tab, often times they do not have a date in the "date closed" column and why you may not see results.

Is there anyway to mark them as passing automatically once they go from an open to a closed task in Jira?

• Yes, the closed date comes from the resolution field and you may need to add an automation for the resolution field to be marked as done automatically. Here are a few articles to assist with automation:
  • https://confluence.atlassian.com/cloudkb/best-practices-on-using-the-resolution-field-968660796.html
  • https://support.atlassian.com/jira-cloud-administration/docs/configure-advanced-issue-workflows/#Essential-post-functions
  • https://confluence.atlassian.com/jirakb/resolution-field-not-updated-when-closing-ticket-1318390464.html

Why are some of my JIRA tasks showing a green check box, but with an error "failed to send?"

• The most common scenario here is that your JIRA workflow does not match your Secureframe resolution status.
• We don’t currently support editing Jira tickets associated with tasks, so this will be a situation you correct internally going forward by ensuring your team follows the process located here.

Why are some of my JIRA tickets missing in the Asset Inventory?

• Secureframe only pulls in relevant tickets - ones that match the following criteria:
  
  • Created after the "Testing start date" configured in the connection settings in Secureframe
  • Contains at least one matching label from the labels configured in the connection settings

Why are some of my JIRA users missing in Secureframe?

• To avoid pulling in service accounts, Secureframe only pulls in users with an Atlassian "Application Role". Most often this role is "jira-software" from being added as a user to the "jira-software-users" group. JIRA admins should be able to access and edit user roles from the "Directory" tab in https://admin.atlassian.com/. For more details, see this JIRA article:
  
  • https://confluence.atlassian.com/adminjiraserver/assign-users-to-groups-project-roles-and-applications-938847026.html

I have 2 failed tests because of the Jira tickets are not closed within the SLA. However, there is no SLA set up for Infrastructure changes?

• The most common issue here is that there are no SLAs specified so the platform is treating the SLA for these labels as zero.
• We recommend either adding a high SLA, or ignoring the failing results with justification if an SLA does not apply.