Ticket closing rules
Introduction to ticket closing rules¶
Tickets within your Brinqa application can be closed manually or automatically. The ticket closing rule module allows you to specify conditions that will automatically close tickets. For example, tickets can be closed automatically when all vulernabilites associated with the ticket have moved to the closed status.
Administration > Remediation > Closing Rules will take you to the Manage Ticket Closing Rules page, which displays a list view of all existing ticket closing rules.
Table 1: List view contents
|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¶
1. Navigate to Administration > Remediation > Closing Rules
2. Click Create Rule
3. Fill in the following and click Create
Table 2: New rule properties
|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 closing 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 closing 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.|
|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 should perform actions on (e.g. closing or updating a ticket).|
|Closing Value||The status the ticket will be set to by the rule.|
|Auto comments on update||Comments that can be automatically added to the comment field of when a vulnerability/issue associated with the ticket is updated. Comments can contain variables.|
|Closing actions||Actions that can be performed while closing the ticket, e.g. setting values on attributes or running a script. Closing action options are listed below.|
|Accessible From||Specifies whether this ticket closing rule will be available to all Brinqa applications or only the application you are currently administrating.|
The events field allows you to specify an event that will cause a ticket closing rule to run.
Table 3: Event options
|After Sync||Rule will run after any data source is synced.|
|After Sync and Calculations||Rule will run after any data source has been synced and its calculated attributes recalculated.|
|On Startup||Rule will run after the application starts up. This event is used when tickets should be closed after the application has been taken offline for a database backup, then restarted.|
|Before/After Delete||Rule will run before or after any dataset of the selected data model is deleted.|
|Before/After Update||Rule will run before or after any dataset of the selected data model is updated.|
|Before/After Insert||Rule will run before or after any new dataset of the selected data model is created.|
|Before/After Calculate||Rule will run before or after any dataset of the selected data model has calculated attributes recalculated.|
Conditions allow you specify additional requirements beyond an event that will determine whether the closing rule is run.
Table 4. Condition interface
|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.|
Closing actions are additional actions that can be performed when the ticket closing rule runs, e.g. setting the value of other attributes on that ticket.
Table 5. Closing action options
|Create/Update/Delete||Create/update/delete an object in an external system, e.g. ServiceNow or JIRA.|
|Set attribute value||Sets the value of an attribute on the selected data model.|
|Run script||Allows the user to enter a Groovy script that will be run on ticket closing.|
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: Close ticket when all associated vulnerabilities are closed¶
This ticket closing rule will close a ticket when all of its associated vulnerabilities have been closed. It includes the optional step of adding a "Closed Date" timestamp by adding a "Closed Date" attribute to the ticket data model and setting it during the ticket closing process. Tracking the closing dates of tickets can creates useful data on the ticket lifecycle, which can be referenced in reports.
1) (Optional) Create a "Closed Date" attribute.¶
- Navigate to Administration > Data Management > Data Models while in the Platform application
- Open the Ticket data model
- Click Create Attribute
- Enter "Closed Date" as the Title
- Select "Date Time" as the Type
- Check "Active" and "Supports filter" under Options. Making this attribute filterable means it can be used in conditions, filters, and inputs elsewhere in the system.
- Click Create
- Click Update. It's important to remember this step, since this saves the change just made to the data model.
2) Create the ticket closing rule.¶
- Navigate to Administration > Remediation > Closing Rules
- Click Create Rule
- Enter "All Vulnerabilities Closed" for the Title
- Enter "Closes a ticket when all vulnerabilities associated with it have been marked as status 'Closed'." as the Description
- Select "Vulnerability" as the Data Model
- Enter "1" as the Order
- Select "After update" as the Event. This means the rule will check whether it needs to run after vulnerabilities are updated, since that update might be an update to their status.
- Set the Condition to "Status Equals to Closed". This tells the rule that it is specifically looking for vulnerabilities that have just been updated to Closed status.
- Select "Ticket" as the ticket Data Model
- Select "Closed" as the Closing Value
- Enter "Closed automatically by ticket closing rule." as the Auto comment
- (Optional) Click Add Action
- (Optional) Select "Run script" as the Action
- (Optional) Enter
source.closed_date = new Date()as the Script. This sets the attribute "Closed Date" (created in step 1) to the current date.
- Click Create
- Select "Owning application only" for the Accessible from field
- Click Create