Note: latest versions of Azure DevOps and Jira don't allow password authentication anymore so you'll need to use API tokens instead. below you can find the guides to generate the API token on both systems.

Azure DevOps: https://docs.microsoft.com/en-us/azure/devops/organizations/accounts/use-personal-access-tokens-to-authenticate?view=azure-devops&tabs=preview-page

Jira: https://confluence.atlassian.com/cloud/api-tokens-938839638.html

At IriusRisk, we are always introducing new and powerful features, often informed by the feedback and requirements of our customer base. If you are a customer and would like to suggest enhancements to this feature/product, please raise a support ticket, or reach out to your account team.

Settings

Issue trackers can have a default (aka global) configuration for all products that can be overwritten with a specific per-product configuration so that different trackers or settings can be used for different products. Currently, we support integration with Atlassian JIRA, Redmine, CA Rally and Team Foundation Server issue trackers.  Integration with other trackers can be built on request.

Default settings

Default settings can be found in the settings menu. Different behaviors of the issue trackers can be configured, for example, creating tickets automatically for failed Weakness tests and closing tickets when a failed test is changed to passed (further details):   

Per-product settings

A different combination of settings can be configured for a particular product through the option Settings in the project's action menu:

Global Settings vs per Product or Component Settings

By default when a new product or component is created, it uses the settings specified in the Global Settings. So if we change a value on the Global Settings, this value change will affect to all created products by default. 

We can override this behavior by editing the Product or Component Settings, if we modify any field at this level, this field will be used instead the one coming from Global Settings. So a change on the Global Settings won't affect this field for that specific product. 

If we want to roll-back changes at a product or component level and have them using the Global Settings, we can use the "Restore Default Values" button. That will restore Global Settings and will use them for any change. 

The relation between product and component settings works exactly the same way that between global settings and product settings. 

For more information on this topic, pelase refer to https://support.iriusrisk.com/hc/en-us/articles/360030930292-Settings-inheritance-system.

JIRA Integration 

JIRA configuration can be provided in the same Global Settings or in the project settings window.

The following parameters are needed: 

• URL: Url to connect to issue tracker API.
• Username: Username used for authentication.
• Password/API Token: Password or API token used for authentication.
• Project Key: Issue tracker project identification key.
• Issue type: Classification of the synchronized issues.
• Issue priority: Preference of the Synchronized issues.
• Open issues as: Status name for issues in progress.
• Closed issues as: Resolution name for completed issues.
• Rejected issues as: Resolution name for denied issues.
• Link Type: type of link (i.e: relates to, is blocked by...)
• [Optional] Default Values: default format depending on the field type - the value to use with all the required custom fields configured in the JIRA connected project. For further information on Default Values, please see the below section 'Default Values & JIRA Components'.
• [Optional] Proxy URL: The URL of your network HTTP proxy.
• [Optional] Proxy user: User to authenticate to the proxy.
• [Optional] Proxy password: Password to authenticate to the proxy.

Default value format depending on the field type

• • • • Selector: Set the exact name of the option to use in default field (Example "Option 1", without quotes).

      • Check box: Not supported yet.

• • • • Date picker: Set the date in format yyyy-MM-dd.

• • • • Date time picker: Not supported yet.

• • • • Label: Not supported yet.

• • • • Number: Not supported yet.

• • • • Radio buttons: Set the exact name of the option to use in default fields (Example "Option 1", without quotes).

• • • • Select list (Cascading): Not supported yet.

• • • • Select list (Single): Set the exact name of the option to use in default fields (Example "Option 1", without quotes).

• • • • Text field (Multi line): Write the desired text to use for the custom fields.

• • • • Text field (Singleline): Write the desired text to use for the custom fields.

• • • • URL field: Write the URL in standard URL format (Example: https://www.iriusrisk.com or file://host/path).

• • • • User picker: Write the user's username.

For the [Optional] Default Values field, we can define the default values for JIRA fields when creating a ticket. IriusRisk supports mandatory fields, and these must be provided for validation using the Validate Fields button (mandatory fields are marked with a red asterisk). Additionally, default values can be set for non-mandatory fields:

IriusRisk also supports JIRA Components. JIRA's Component feature helps make projects and teamwork more organised. First, a JIRA Component needs to be defined in JIRA; an issue assigned to a Component can then be used for JIRA team allocation, lead, actions etc., and helps segregate projects at a component level for easy management. If your organisation is using JIRA Components, IriusRisk can map issues to them using the Component/s field - this can contain multiple Component values. 

The JIRA Component value is often changed for the IriusRisk Component Settings. Consider the below example of an AWS API Gateway we wish to map to an existing JIRA Component called 'API', we simply right click on the IriusRisk Component, and select 'Edit Settings':

We can then set the Component value to our corresponding JIRA Component 'API':

Also, take note above of the Labels. We can comma-separate these if we wish to have multiple Labels for the raised JIRA issue. Once we've raised an issue for all countermeasures belonging to this component, we can see them in JIRA. On this occasion, we've only raised the one to begin with, however we can see it mapped below: 

Also notice how the JIRA Issue itself is created with the two labels we defined previously as Default Values: 

Redmine Integration

Redmine integration is similar:

• URL: Url to connect to issue tracker API.
• API access key: Key used for API authentication.
• Project identifier: Issue tracker project identification.
• Issue category: Classification of the synchronized issues.
• Issue priority: Preference of the Synchronized issues.
• Target version: version number of the Redmine project
• Open issue name: State name for issues in progress.
• Closed issue name: State name for completed issues.
• Rejected issue name: State name for denied issues.
• Issue relation type name: type of link (i.e: Related to, Blocked by...)

Team foundation server integration

• URL: Url to connect to issue tracker API.
• Username: Username used for authentication.
• Password: Password used for authentication. In newer versions of TFS is the API token instead.
• Project Name: Issue tracker project's name.
• Work Item Type: Classification of the synchronized issues.
• Open issue name: State name for issues in progress.
• Closed issue name: State name for completed issues.
• Rejected issue name: State name for denied issues.
• Tags (Comma separed): Labels added to the issues
• Severity levels by ascent order (Optional): Severity level of the issue (i.e: 1-Critical, 2-High, 3-Medium, 4-Low)

Rally integration

• URL: Url to connect to issue tracker API.
• API access key: Key used for API authentication.
• Project ID: Issue tracker project's identification.
• Priorities: Priority of the issue (i.e: None, Resolve inmediately, High attention, Normal, Low)
• Severities: Severity of the issue (i.e: None, Crash/Data loss, Major problem, Minor problem, Cosmetic)
• Open issue name: State name for issues in progress.
• Closed issue name: State name for completed issues.
• Rejected issue name: State name for denied issues.
• Tags (Comma separed): Labels added to the issues.

Synchronization

This sync action is performed in a background job on a 5-minute schedule. We can force the sync by using the Sync with issue Tracker option on the Countermeasures Action menu in real-time:

Once the synchronization is done, the Countermeasures with linked issues can be viewed on the Countermeasures Tab, Issue IDs are direct links to the specific issues on the external tracking system:

Linking Countermeasures to Issues

There are three routes to create tacker issues from the required Countermeasures. The first is through the New Project wizard where one of the final popup screens will prompt the user to upload Required countermeasures to an issue tracker. 

The second option is to explicitly create new issues for all required countermeaures from the Countermeasures Tab's Action menu.  Note that only countermeasures in the "Required" state will be uploaded. 

And finally, issues can be created for individual countermeasures by using the Action menu on the countermeasure itself:

Once a Countermeasure has been linked to an issue, the issue acts as a master source for the status of the Countermeasure. This means that changes in the countermeasure status within IriusRisk will be overridden by the status of the ticket on the Issue Tracker. 

The status of the Countermeasure is mapped as indicated by the configuration fields: Open issue name, Closed issue name and Rejected issue name.  On the creation step, the issue will be assigned the type and priority based on the configuration fields: Issue type and Issue priority.

Linking Countermeasure Test Results

When a Countermeasure is tracked with an external issue tracker, the test result directly affects the issue status. If a Countermeasure status changes to Failed and the tracker issue was marked as "Closed", then the ticket is automatically reopened and a comment with the failure information is included on the ticket. 

In the same way, if a Countermeasure's test changes to a Passed status, the related tracker issue is automatically closed.  This behaviour can be changed using the settings for the tracker.

Linking Weakness Test Failures

If the configuration setting "Create tickets for failed Weakness Tests"  is set and an issue tracker is configured then Weaknesses will also be associated with issues. We can force this process by using the Create issues for all failed weakness tests in threats tab. The links to weakness issues will be displayed in threat detail pannel:

This situation will happen when a Weakness test changes its status to Failed, in that moment, a new tracker issue will be created with information on the Weakness, testing steps and the results of the performed test. This issue will also include the related Countermeasures for reference purposes.

When the Weakness test is changed back to Passed, then, the associated issue will automatically be changed to a Closed status.  

An example of an issue created for the JIRA tracker would be: