Ticket creation rules
Introduction to ticket creation rules¶
Tickets within your Brinqa application can be created automatically from vulnerabilities or issues. The ticket creation module allows you specify what sorts of vulnerabilities will create tickets, when those tickets will be created, initial values for attributes like due date and owner, and whether similar vulnerabilities should be grouped into single tickets.
Administration > Remediation > Creation Rules will take you to the Manage Ticket Creation Rules page, which displays a list view of all existing ticket creation rules.
Table 1: List view contents
| Columns | Description |
|---|---|
| Title | Title of the rule |
| Description | Description of what the rule does |
| Order | Order the rule is run in |
| Active | Whether the rule is active. Inactive rules are effectively archived. |
| Created By | Who created the rule |
| Created On | When the rule was created |
| Last Updated | When the rule was last updated |
Create a new rule¶
Procedure
1. Navigate to Administration > Remediation > Creation Rules
2. Click Create Rule
3. Fill in the following and click Create
Table 2: New rule properties
| Fields | Description |
|---|---|
| Title | Title of the rule. Title will be displayed wherever the rule appears in the UI. |
| Name | Reference name for queries and scripts. The name can contain only letters, numbers, and underscores. |
| Description | Description of the rule. Description is displayed on the ticket creation rules list view and can be searched from the list view search bar. |
| Data Model | The data model the rule will look at to determine whether ticket opening criteria have been met, usually vulnerability or issue. The data model selected will change options available in the "When to Run" and "What to Do" sections of the form. |
| Order | Determines when the rule runs relative to other rules. If rules are not working as designed, check for interference from other rules on the same event. |
| Active | Whether the rule is active. Inactive rules are effectively archived and do not run. |
| Events | When the rule will run. Event options are listed below. |
| Data Source | Data source whose events will cause the creation rule to run. |
| Data Mapping | Data mapping on the data source whose events will cause the creation rule to run. |
| Conditions | Additional conditions for when the rule should run (e.g. when an attribute has a certain value). Condition options are listed below. |
| Data Model | Ticket data model this rule will reference when creating tickets. |
| Assignment Policy | How the ticket is assigned on creation. User allows specifying a particular user in the system. Attribute allows specifying based on a user reference attribute (e.g. host owner). Unassigned creates the ticket without an assignee. |
| Due in | Assigns the ticket a due date in number of days. This field is useful for building service level agreements (SLAs) into tickets. |
| Mapping | The data model mapping that the “after sync” or “after sync and calculations” event will look for for tickets with one vulnerability. |
| Include comments when ticket is created/re-opened | Comments that are automatically added to the comment field when a ticket is created or re-opened. Comments can contain variables and scripts. |
| Consolidate | Allows consolidation of multiple vulnerabilities with shared properties into a single ticket. If checked, the consolidation fields will appear on the form. |
| Minimum | The number of vulnerabilities needed with the same consolidation attributes for a ticket to be created. |
| Attributes | The attributes by which vulnerabilities should be consolidated. E.g. Consolidate vulnerabilities to one ticket if they have the same CVE and OS. |
| Mapping | The data model mapping that the “after sync” or “after sync and calculations” event will look for for tickets with multiple vulnerabilities. Tickets with multiple vulnerabilities should have their own mapping since some attributes should display a single shared value from the vulnerabilties, and some attributes should list each individual value from the vulnerabilities. |
| Add to existing ticket | Determines if newly found vulnerabilities matching a ticket from a previous consolidation should create a new ticket or add the vulnerabilities to the existing ticket. |
| Accessible From | Specifies whether this ticket creation rule will be available to all Brinqa applications or only the application you are currently administrating. |
Events¶
The events field allows you to specify an event that will cause a ticket creation rule to run.
Table 3: Event options
| Event | Description |
|---|---|
| After Sync | Rule will run after the specified data source is synced. |
| After Sync and Calculations | Rule will run after the specified data source is synced and its calculated attributes recalculated. |
| On Startup | Rule will run after the application starts up. This event is used when tickets should be created after the application has been taken offline for a database backup, then restarted. |
Conditions¶
Conditions allow you specify additional requirements beyond an event that will determine whether the creation rule is run.
Table 4. Condition interface
| Element | Description |
|---|---|
| Add AND Clause | Specifies conditions that must be met. (E.g. owner is Dave) |
| Add OR Clause | Specifies an alternate set of conditions that could be met. (E.g. owner is Dave OR owner is Marg) |
| Reset Filters | Clears all the filter options. |
| Attribute | Attribute referenced for the condition. (E.g. owner) |
| Operator | Operator for the specified value. (E.g. greater than, equal to, is not, contains) |
| Value | Value the operator compares the data to. (E.g. a specific name or host) |
| AND | Adds an additional AND condition to the associated section. |
| OR | Adds an OR between two different conditions within a clause (e.g. owner is Marg and status is New OR Active). These ORs must share the same attribute. E.g. Status is Active OR New, but not Status is Active OR Priority is Critical. |
Edit/Delete a rule¶
Existing rules can be edited or deleted by clicking the Actions button that appears to the right on mouseover of the entry on the list view.
TUTORIAL: Create tickets with vulnerabilities grouped by CVE and business unit¶
If multiple vulnerabilities exist with the same CVE and business unit, administrators may want to group them, as their fix could involve deploying e.g. the same patch to a group of hosts that are on the same network or in close physical proximity.
This tutorial will cover how to make a ticket creation rule that consolidates multiple vulnerabilities into one ticket based on those attributes. It also groups the vulnerabilities by host owner, so that each ticket can be assigned to the person responsible for implementing the fix.
- Navigate to Administration > Remediation > Creation Rules
- Click Create Rule
- Enter "Consolidated Vulnerabilities" for the Title
- Enter "Consolidates vulnerabilities by CVE and business unit." as the Description
- Select "Vulnerability" as the Data Model
- Enter "1" as the Order
- Select "After sync and calculations" as the Event. This will ensure tickets are created after risk scores and other important vulnerability attributes have been calculated.
- Set the Data Source to a data source that provides the vulnerabilities
- Set the Data Mapping to the vulnerability mapping for the selected data source.
- In Ticket Properties, select "Ticket" for the Data Model
- Select "Attribute" for Assignment Policy
- Select "Host.Owner" for the Assignment Attribute. This will assign the ticket to the user who owns the affected hosts.
- Enter a value for the Due In field. If SLAs vary by severity of issue, add a condition to the rule that looks for risk ratings equal to a certain value.
- Check the Consolidate box
- Enter "1" for the Minimum
- Select "CVE", "Host.BusinessService.BusinessUnit.Name", and "Host.Owner" as the Attributes. The Host.Owner attribute is important because it allows the ticket to be assigned by host owner. Without this attribute, tickets created by this rule might have vulnerabilities on hosts with different owners.
- Enter the appropriate vulnerability-to-ticket mapping for the Mapping field. If you have multiple vulnerability-to-ticket mappings, this should be the mapping designed for multiple vulnerabilities to a single ticket.
- (Optional) Check "Add to existing ticket" if you want new vulnerabilities that meet the same criteria to be added to these tickets if they are found later.
- Select "Owning application" for Accessible from
- Click Create