Rules
Introduction to rules¶
Data source rules are used for setting up outbound syncs, e.g. when you want to update tickets in external ticketing systems or update your CMDB with changes that were made within your Brinqa instance. Creating these rules allows you to choose when outbound syncs should be performed and what they will update.
Administration > Data Integration > Rules will take you to the Manage Data Source Rules page, which displays a list view of all existing data source 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 will not run. |
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
- Navigate to Administration > Data Integration > Rules .
- Click the Create Rule button
- Fill in the following and click Create:
Table 2: New rule properties
Columns | 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. The description will appear in the list view on the Manage Data Source Rules page. The search bar on the Manage Data Source Rules page searches the description field, so include phrases and keywords that will make the rule easy to search for later. |
Data Model | What data model the rule is run on. 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 do not run. |
Events | When the rule will run. Event times refer to changes to the objects in the data model (e.g. when a ticket is deleted). Event options are covered below. |
Conditions | Additional conditions for when the rule should run (e.g. when an attribute has a certain value). Condition options are covered below. |
Data Source | Data source that will be updated by the rule. Depending on the source selected, an additional field for a unique identifier may appear. |
Accessible From | Specifies whether this 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 run a rule.
Table 3: Event options
Event | Description |
---|---|
After Sync | If no data model is selected, “after sync” is an available event. “After sync” rules will run after the selected data source is synced. |
After Sync and Calculations | If no data model is selected, “after sync and calculations” is an available event. “After sync and calculations” rules will run after the selected data source has been synced and its calculated attributes recalculated. |
On Startup | If no data model is selected, “on startup” is an available event. “On startup” rules will run after the application starts up after a reboot. |
Before/After Delete | Rule will run before or after any instance of the selected data model is deleted. |
Before/After Update | Rule will run before or after any instance of the selected data model is updated. |
Before/After Insert | Rule will run before or after any new instance of the selected data model is created. |
Before/After Calculate | Rule will run before or after any instance of the selected data model has calculated attributes recalculated. |
Conditions¶
Conditions allow you specify additional requirements beyond an event that will determine whether a 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: Push ticket data to an external ticketing service¶
Brinqa tickets can be modified manually or automatically, for example by a ticket closing rule that closes tickets whose associated vulnerabilities have been closed. Data integration rules allow you to update the corresponding tickets in your external ticketing service (e.g. JIRA or ServiceNow) according to certain conditions. This tutorial will cover how to create a rule that updates ticket information in external services when it is updated within Brinqa applications.
- Navigate to Administration > Data Integration > Rules
- Click Create Rule
- Enter a Title
- Enter a Description of what the rule does, e.g. Updates JIRA tickets when Brinqa ticket is updated
- Select "Ticket" for the Data Model
- Enter "1" for the Order, unless you have other rules that require precedence.
- Select "After Update" for the Event. This tells the system that this rule should be run after any ticket is updated.
- Leave the Conditions empty, unless only certain tickets should be updated.
- Select your external ticketing service for the Data Source. This field tells the system which service's data will be updated.
- Select "External ID" for the External ID attribute. This is the unique identifier external systems use to differentiate between e.g. individual tickets.
- Using the Accessible from field, choose whether this rule should be available to all your Brinqa applications or only the application you are currently administrating.
- Click Create