Ticketing systems are, in many ways, the engine that drives DevOps and many other facets of modern IT. To be most effective, cloud security platforms need to integrate well into this ecosystem, putting the right intelligence into tickets instead of trying to pull developers and other consumers of this intelligence into the platform, while allowing security teams to monitor tickets easily.

In this blog, we’ll focus on Jira, a project management system from Atlassian, used for product and issue tracking and popular with software development, IT, and DevOps teams. For cloud security to be effective, it is important that it fits seamlessly into existing workflows and that users do not need to change the way they work. 

However, companies face several challenges in integrating their security platforms with a ticketing system like Jira. The challenges may differ from implementation to implementation but several of the key problems that I’ve seen organizations wrestling with are:

  • Getting the right intelligence into Jira tickets, particularly as organizations customize the format and fields in their projects to meet their needs.
  • Navigating multiple different Jira projects, each of which may need different customizations.
  • Finding a balance between automating ticket creation and empowering security analysts to create tickets.
  • Ensuring that security analysts have visibility into the state of tickets as they progress and validating that issues were resolved were actually resolved.

This is where I get excited about Orca Security’s Jira integration and I want to show you why.

Right intelligence, right ticket

Ticketing platforms like Jira allow for a great deal of flexibility in building out projects and workflows – this is necessary, to cover the different ways that teams and organizations use them. While many integrations have a hard time solving this problem, Orca’s integration offers administrators a great deal of flexibility in delivering the right information to the right teams.

The Jira Integration template editor shows the fields available in Orca alerts with graph connections to output them to fields in the Jira ticket.
Orca’s Jira template editor allows unparalleled capabilities to map Orca alerts to Jira tickets.

As you can see, Orca imports the configuration of Jira tickets within the selected project, enabling administrators to map anything in an Orca alert into the ticket being created. Orca is aware of customizations, configuration, and required fields in the project, simplifying configuration.

Supporting multiple Jira workflows

As I mentioned in the introduction, organizations rarely have only one Jira project. Different teams will create projects to track work and issues and different projects may have wildly divergent requirements. Orca allows you to create multiple templates so that each use case is covered – not only can you have a template per project, you can have multiple templates per project if needed. For example, a particular team may want different formats for new vulnerabilities than for a critical threat.

The Orca Security platform UI shows a dialog box for editing existing Jira Cloud templates and creating new ones. Templates for “Sauce App Issues” and “BarbecueTool” currently exist in the TwoBibRibs Jira tenant.
Orca allows creation of different templates to address the differences between projects & use cases.

Now, create tickets

Security teams may want to automate the creation of tickets for particular categories of problems; for example, you may want to automatically create a high-priority ticket if a critical vulnerability is discovered in a production environment. In other cases, security teams may want analysts to triage alerts and create Jira tickets only where they believe it’s necessary.

For automated creation of tickets, Orca has a powerful approach to automation that allows you to define specific criteria (such as “Any time a new IAM risk is found in the BarbecueTools business unit”) and specify what action will be taken (“Create a new sub-task in Jira under a particular parent ticket”).

The page for creating automations in Orca is shown with a trigger query of “When an alert Alert State is open and Business Unit is BarbecueTool and Category is IAM misconfigurations”.
Create automation triggers that are as simple or detailed as needed.
The new automation is shown with options to open a single ticket, with subtickets for each alert, in the BarbecueTool template.
Take action with alerts that meet the trigger

But, as I said, sometimes we want an analyst to make the decision to create a ticket. Once we’ve integrated Jira and created templates, those integrations are available to take action as required. For example, if an analyst is concerned about this AWS Secret Access Key found in a code repository, they can effortlessly create a new ticket with the right template to ensure that a serious risk receives the right attention.

An open alert for a detected AWS Secret Access Key is depicted with a dropdown menu for creating a Jira ticket using the “Sauce App Issues” template.
Effortlessly send an Orca alert to Jira for followup.

After the ticket

After creating the ticket above, our security analyst will be eager to follow the progress as it moves towards resolution; however, depending on how the organization works, they may not have access to Jira or, at the very least, they may not be as familiar with navigating Jira as developers are. Fortunately, security analysts can always check the status of an associated ticket directly from the Orca alert and, if necessary, follow the link directly to the ticket in Jira.  Orca’s integration is bidirectional so, as changes are made to the ticket, those changes are reflected here – for example, if the Jira ticket owner closes the ticket, the corresponding alert will also be closed.

An open alert for a detected AWS Secret Access Key shows that Jira ticket SAUC-296 is in the “To Do” state.
Security analysts can always find the status of outstanding Jira tickets.

Finally, an analyst may want to verify that a ticket has been resolved when it’s marked as closed. By default, Orca automatically performs this verification and, if the actual problem hasn’t been resolved, will automatically reopen both the Orca alert and the Jira ticket.

An open alert for an AWS Secret Access Key detection shows that, while the Jira ticket was closed, verification showed that the problem still exists. The Orca alert and the Jira ticket were both reopened.
Orca’s bi-directional Jira integration will verify that a closed ticket has been resolved and, if it hasn’t been, reopen it.

Whether you’re dealing with multiple projects, automated alerts, or manual ticket creation, Orca’s Jira integration adapts to your needs. To see how this integration can enhance your security operations and streamline your workflows, schedule a demo of the Orca Security platform today. Let us show you firsthand how Orca can turn your security alerts into actionable, trackable tickets in Jira.