Skip to main content

Generate Tickets from Findings

This article details how to create an automation that generates tickets without the use of sprints. While this article specifically focuses on generating vulnerability tickets, you can also generate tickets for other findings, such as dynamic code findings, open source findings, pentest findings, and more.

Generating tickets with and without sprints varies mainly in how your findings are managed and tracked over time. Choosing between these two methods depends largely on your organization's workflow and how you prefer to manage and track your findings. If you prefer to work with tickets using a sprint model, see generate tickets with sprints.

Comparing tickets with and without sprints​

When you generate tickets with sprints, the process is organized around time-boxed iterations, or sprints, which typically cover a week or two weeks, where a specific set of vulnerabilities or findings are addressed. At the end of each sprint, unresolved issues and new findings discovered during the sprint are moved to a backlog ticket and a new sprint begins with a fresh set of tickets. This approach provides a structured way to manage vulnerability remediation and can help you understand your remediation performance over time.

Unlike the sprint model, when you generate tickets without sprints, findings do not move cyclically between a backlog and a sprint. Instead, every finding either belongs to an active ticket or is queued for the next ticket. This approach eliminates backlog management seen in ticketing with sprints. Although these tickets are not bound by sprint timeframes, they still adhere to the timelines established by their respective Service-level Agreement (SLA) due dates.

When new findings emerge, they are not added to existing tickets by default. Instead, a new ticket is generated, ensuring that each ticket accurately represents its corresponding findings. Additionally, if a finding associated with a closed ticket reopens, it moves into a new ticket, providing a straightforward way of tracking reopened issues. However, there's an option to add findings to existing tickets based on a condition. See the Continue adding new findings to open tickets section in step 2 of the Create tickets without sprints tutorial for additional information.

Ticket closing​

In the Brinqa Platform, the life cycle of a ticket is directly tied to the vulnerabilities or findings associated with that ticket. In other words, a ticket remains in an "open" state as long as it has associated findings that need addressing. Tickets in the Brinqa Platform are not manually deleted but rather they reach a "closed" status. Tickets can reach a "closed" status for the following reasons:

  • Resolution of findings: Once all of the findings tied to a specific ticket have been resolved, the ticket doesn't close immediately. Instead, it's marked for closure, and upon the next run of the automation, if the system confirms that all the findings tied to a specific ticket have been resolved, that ticket is then closed. This process ensures that the ticket status accurately reflects the current state of associated findings.

  • BQL criteria: The Brinqa Query Language (BQL) query is written to determine the findings or vulnerabilities that are included in the ticket(s). If the associated findings or vulnerabilities no longer match the BQL criteria of the automation created, they can be removed, and the ticket is then closed.

    For example, suppose you have a BQL query that identifies high severity vulnerabilities with a patch available:

    FIND VulnerabilityDefinition AS v
    WHERE v.severity = "Critical"
    AND v.patchAvailable EXISTS

    If a vulnerability initially matches this criteria and is included in a ticket, but later its severity is downgraded (e.g., to 'high' or 'medium'), it no longer matches the BQL criteria. As a result, the automation removes this vulnerability from the ticket. If all vulnerabilities associated with the ticket are removed because they no longer meet the criteria, the ticket is then closed.

This approach not only ensures comprehensive tracking of all identified vulnerabilities and their remediation status, but also maintains a clean, efficient, and structured way to manage the backlog of tickets. As a result, this makes the review of historical data and understanding your organization's vulnerability management performance over time easier and more accurate.

Create tickets without sprints​

Users with the Configurator or System Administrator role can create a new automation that generates tickets without sprints. To do so, follow these steps:

  1. Navigate to Automation.

  2. Click Create and fill in the following fields:

    • Title: The title of the automation.

    • Description: The description of what the automation accomplishes.

    • BQL query: The BQL query that determines the findings that are included in the ticket. For example: FIND Vulnerability AS v WHERE v.status = "Confirmed active" AND v.severity = "Critical". Click Test to check if your query is valid and returns any data.

      warning

      Avoid using "Finding" in the BQL query. Instead, choose a data model that extends the "Finding" model, such as Alert, Manual finding, Pentest finding, Violation, Vulnerability, etc. If you create an automation for generating tickets and use "Finding" in the BQL query, it will not work as intended and will result in tickets being created with empty counts.

    • Actions: The action that the automation performs. Since we used "Vulnerability" in our BQL query, click the drop-down and select Create vulnerability ticket without sprints. The options for the "Create vulnerability ticket without sprints" action are as follows:

      • SLA: The SLA definition to associate with the tickets. See Service-level agreements for additional information.

      • Grouping: Grouping consolidates tickets by grouping similar findings into a single, all-inclusive ticket. This means that each group of similar findings, as determined by the BQL query and grouping criteria, results in one ticket, as opposed to generating individual tickets for every separate finding returned by the query. This approach is beneficial when the same solution can be applied across multiple assets. Click the drop-down and indicate how you want the findings to be grouped. Figure 2 illustrates some of the common uses of groupings:

        • Vulnerabilities with the same solution (Type): This grouping is often used when dealing with multiple vulnerabilities that share the same solution. These are grouped by type, risk rating, or owner.

        • Vulnerabilities discovered on the same asset (Target): This grouping is often used when numerous vulnerabilities are found on the same asset, such as a specific laptop or server. These are grouped by target, risk rating, or owner.

        Common ticket groupings

        Figure 1. Common ticket groupings

      • Assignment policy: Select a default owner. You can assign it to a specific user, assign it based on an attribute, or leave it unassigned.

      • Continue adding new findings to open tickets for as long as this condition is met: (Optional) Configure the automation to determine, based on the specified condition, if newly found vulnerabilities should create a new ticket or be added to an existing open ticket. If a new finding emerges when this condition is true, it is added to the existing ticket. If not, a new ticket is generated.

    • Run: Choose a method for the automation to run. You can run the automation manually, set a schedule for the automation to run, or you can set it to run when your data orchestration runs.

  3. Click Create.

The Automations page reloads and the new automation appears in the list view. See launch the automation and view the generated tickets for details on running the ticket automation and viewing tickets generated by the automation.

Launch the automation​

Once you've created your automation, you can run the automation and view the tickets generated by it. Running the automation uses your BQL query to identify the vulnerabilities or findings that should be included in the tickets. To launch the automation, follow these steps:

  1. Navigate to Automation.

  2. Hold the pointer over the automation you want to run, and then click Run.

  3. Click Confirm when prompted.

Upon confirmation, the automation initiates the ticket generation process. It uses your BQL query to identify matching findings and depending on your specified grouping settings, the findings are categorized and grouped into tickets.

View the generated tickets​

After your automation runs successfully, you can then view the tickets generated by the automation. To do so, follow these steps:

  1. Navigate to Remediation > Tickets > All.

  2. Use the filters to zero in on the tickets generated by your automation.

    For instance, you can use the Assigned filter to display only the tickets assigned to the owner specified when you created the automation. Similarly, the Created by filter displays tickets by a particular user. Click on the "Date created" column header to sort tickets by their creation date.

  3. Hold the pointer over one of the tickets and click Details to view information about a specific ticket.

These details may include a summary and description of the vulnerability, recommendations on how to address the vulnerability, open and closed vulnerabilities, assignment information, risk and SLA information, and more.

Tutorial: Generate tickets on critical vulnerabilities​

This tutorial demonstrates the process of creating an automation for generating tickets without sprints, from defining your BQL query, to assigning tickets, and setting the automation run schedule. While this guide specifically focuses on generating vulnerability tickets, you can also generate tickets for other findings, such as dynamic code findings, open source findings, pentest findings, and more. You may want to create such an automation for the following reasons:

  • Vulnerability management: Enable real-time tracking and management of critical vulnerabilities. This can help ensure prompt and effective remediation.

  • Risk prioritization: Tickets are generated for only active and critical vulnerabilities. This can let your team focus on the most pressing issues first.

  • Efficient remediation: Ensure that your remediation efforts are not delayed or overlooked. This can boost the overall efficiency of your vulnerability response processes.

To create an automation that generates tickets for active, critical vulnerabilities without sprints, follow these steps:

  1. Navigate to Automation.

  2. Click Create and fill in the following fields:

    • Title: Type "Generate active and critical vulnerability tickets".

    • Description: Type "This automation generates tickets for critical vulnerabilities".

    • BQL query: Type the following (BQL) query to find all active vulnerabilities with a critical risk rating in your data. Click Test to ensure that the query is valid and returns the expected data:

      FIND Vulnerability AS v
      WHERE v.riskRating = "Critical"
      AND v.status = "Confirmed active"

    • Actions: Click the Select an action drop-down, and select Create vulnerability ticket without sprints. More options appear below.

      • SLA: Select an SLA definition to associate with the tickets. For example, Default ticket SLA definition, where the SLA starts when the ticket is created or Default finding SLA definition, where the SLA starts from the date that the findings are initially identified. See Service-level agreements for additional information.

      • Grouping: Click the drop-down and select Type > Name and Type > Risk rating. This groups the vulnerabilities by their name and risk rating levels.

      • Assignment Policy: Click the drop-down and select a default owner. You can assign it to a specific user, assign it based on an attribute, or leave it unassigned.

      • Continue adding new findings to open tickets for as long as this condition is met: (Optional) Enter a BCL condition that determines whether an existing open ticket should accept new findings or if a new ticket should be created. This condition is applied to the tickets, not the findings. For example, the BCL could be:

        dateCreated IN LAST 1 week

        In this case, any new vulnerabilities are added to tickets that were created within the last week.

    • Run: Choose a method for the automation to run. You can run the automation manually, set a schedule for the automation to run, or you can set it to run when your data orchestration runs.

  3. Click Create.

The Automations page reloads and the new automation appears in the list view. See launch the automation and view the generated tickets for details on running the ticket automation and viewing tickets generated by the automation.

Last updated on