Data models
Introduction to data models¶
Data models are the most central element of Brinqa applications, structuring and determining relationships between all data and objects in the system.
Data models are referred to in two ways within Brinqa applications. When an administrator creates a data model, they are creating a set of attributes that objects of that type will have in the system. That data model is a structure used to build datasets. “Data model” can also refer to the group of all datasets built with that structure. So, when an administrator is creating a report and selects a data model to be visualized, they are selecting the group of datasets to display.
Creating a data model structure allows you to specify which pieces of data you want to store about particular objects in your system. For example, the ticket data model defines what attributes will exist for tickets in your application. Some of these attributes might be ticket id, title, creation date, and due date. Your administrator can determine exactly what pieces of data will be relevant to your team and omit anything you consider superfluous, even if that data is provided by your data sources like Qualys or Service Now. Once a set of attributes has been assembled into a data model, the attributes can be mapped to data sources that will populate them for each instance of that object created within the system.
Data models also allow you to build relationships between individual attributes and other data models. For example, vulnerabilities have a number of attributes, one of which is risk rating. Risk rating is calculated from another vulnerability attribute, risk score, which is in turn calculated from other vulnerability attributes like base CVSS score. Another vulnerability attribute is host. Host objects themselves have many attributes, like IP address, operating system, and owner. The relationship between the vulnerability data model and the host data model means that you can quickly display information like vulnerabilities by host IP or operating system, without storing host operating system as a piece of data about a vulnerability.
Purpose of data models¶
Apart from serving as the structure for objects within your applications, data models make it possible to automate data input and normalize data from different sources. By specifying characteristics certain objects should have, you can then map those characteristics to characteristics of objects in various data sources. When the data source provides information on a mapped object, it is then created according to the data model configurations within your Brinqa application. Data models normalize data by using the same structure for information from disparate sources. Having one vulnerability data model and mapping multiple sources to it means that information from different sources is restructured in a way that makes it easy to compare.
Data models also allow you to build your business model into the system by associating things like departments and business units with hosts, creating contextual information for vulnerabilities. For example, some hosts will be associated with certain business units that provide critical business functions. A high risk rating for that host will be more important to address than a high risk rating on a host that provides non-critical functions.
Default data models¶
Brinqa applications come with many pre-defined data models. Each application will start with different default data models. Data models defined at the platform level will be available to all Brinqa applications, whereas data models defined within a particular application will only be available to that application.
Table 1. Default Platform data models
Data Model | Description |
---|---|
Base Model | The base model defines characteristics that many other data models may have and exists to act as a parent model to other data models. Child data models inherit the parent model’s attributes, so the base model saves administrators the time of repeatedly adding the same attributes to many different data models. |
Ticket | The ticket data model defines characteristics of individual tickets created by your ticketing data sources. |
Company | The company data model defines characteristics of companies monitored by your Brinqa applications. Building companies into the system allows you to sort things like vulnerability data by company and create company-specific reports. |
Division | The division data model defines characteristics of divisions monitored by your Brinqa applications. Building divisions into the system allows you to sort things like vulnerability data by division and create division-specific reports. |
Business Unit | The business unit data model defines characteristics of business units monitored by your Brinqa applications. Building business units into the system allows you to sort things like vulnerability data by business unit and create business unit-specific reports. |
Department | The department data model defines characteristics of departments monitored by your Brinqa applications. Building departments into the system allows you to sort things like vulnerability data by department and build department-specific reports. |
Business Service | The business service data model defines characteristics of business services monitored by your Brinqa applications. Building business services into the system allows you to sort things like vulnerability data by business service and build business service-specific reports. |
Location | The location data model defines characteristics of office locations monitored by your Brinqa applications. Building locations into the system allows you to sort things like vulnerability data by location and build location-specific reports. |
Role | The role data model defines characteristics of user roles within the system. Instances of roles can be created by Active Directory if your company has AD set up as a data source. |
User | The user data model defines characteristics of individual users within the system. Instances of users can be created by Active Directory if your company has AD set up as a data source. |
Table 2. Default Threat & Vulnerability Management data models
Data Model | Description |
---|---|
Host | The host data model defines characteristics of the network hosts within your company. Instances of hosts can be created by your data sources. |
Vulnerability Definition | The vulnerability definition data model defines characteristics of types of vulnerabilities. Vulnerability types can be created by your data sources. |
Vulnerability | The vulnerability data model defines characteristics of individual vulnerabilities identified by your vulnerability data sources. Instances of vulnerabilities can be created by your data sources. |
Working with data models¶
Administration > Data Management > Data Models will take you to the Manage Data Models page, which displays a list view of all existing data models.
Table 3: List view contents
Columns | Description |
---|---|
Title | Title of data model |
Description | Description of data model |
Date Created | Creation date of data model |
Last Updated | Last time the data model was updated |
Create a new data model¶
- Navigate to Administration > Data Management > Data Models
- Click Create Data Model
- Fill in the following and click Create:
Table 4: New data model properties
Field | Description |
---|---|
Title | Title of the data model. The title will be displayed wherever the data mapping appears in the UI. |
Name | Reference name for queries and scripts. The name can contain only letters, numbers, and underscores. |
Description | Description of the data model. Description is displayed on the data model list view and can be searched from the data model list view search bar. |
Active | Whether the data model is active. Inactive data models will not be used and are in effect archived. |
Starts with a vowel sound | If the title starts with a vowel sound, the application will precede it with the correct article (“an”) where necessary. E.g. an account vs. a ticket. |
Track History | Sets all attributes in the data model to have their history tracked without having to mark each individually. Tracking the history of attributes allows you to create visualizations of their historical values. |
Allow Reports | Makes the data model available for use in visualizations on reports. |
Extensible | Flags the data model as one that can be used as a parent for other data models. Child data models inherit the attributes of their parent data model. |
Display Attribute | When this data model is referred to in another data model, which attribute value will display. E.g. Vulnerabilities display the host they were found on, but the Host data model contains many attributes. Selecting “IP address” as the display attribute for Host means that when a vulnerability lists its host, the information it displays about the host is its IP address. The display attribute cannot be selected until attributes have been assigned to the data model. |
Classification | Gives the data model certain default attributes (like a parent), but also flags the data model as a specific type for use elsewhere in the system. E.g. data models with ticket classification will appear as potential data models for use in ticket creation rules. |
Parent Data Model | Which data model is the parent of the data model being created. Child data models inherit attributes from their parent data models. When creating a new data model, you must select the base model as a parent in order for show, list, and form views to be created. |
Accessible from | Specifies whether this data model will be available to all Brinqa applications or only the application you are currently administrating. |
Adding attributes¶
Once the data model has been saved its attributes can be created. All data models will start with some attributes based on the classification selected during creation.
An attribute should be created for every piece of data you’ll want to gather about this type of object. The attributes you select for each data model will determine what’s available when creating mappings to data sources.
For more information on creating attributes, navigate to the Attributes section of the documentation.
Working with attributes¶
Attributes associated with a data model appear on a list view in the middle of the data model edit/create form.
The list view allows you to edit, delete, and order attributes. Attributes can be ordered by dragging them up or down the list. Order is referenced by calculated attributes. For example, the calculation for Risk Rating refers to Risk Score, which is itself a calculated value. Placing Risk Score higher on the attribute list ensures it is calculated first, and is therefore available for the Risk Rating calculation later.
Table 5: Attribute list view contents
Columns | Description |
---|---|
Order | Referenced for evaluation order for calculated attributes. Attribute order can be changed by dragging and dropping entries on list view. |
Title | Title of the attribute. The title will appear wherever the attribute appears throughout the system, e.g. as a column header on a list view. |
Type | Type of attribute. Type determines what kind of values the attribute can accept from data sources. |
Description | Description of the attribute. This description will only appear to administrators when viewing the data model. |
Actions | Mouseover of attributes on this list will cause the Actions button to appear in this column. |
Deleting data models¶
Data models are the most central element of Brinqa applications and therefore have a large number of dependencies. To delete a data model, it can't be in use anywhere else in the system. If a data model is referenced by a data mapping, data set (individual instance of a data model), data model mapping, mail template, notification, rule, close ticket action, create ticket action or a child model, it is considered in use and cannot be deleted.
If you do delete a data model, all views associated with that data model (show, list, and form) will also be deleted.