The Devices List

The devices list lists devices in respect to their vulnerability and cyber risk. It allows you to focus on your most vulnerable devices, rather than on the most severe and widespread vulnerabilities. You can limit the scope of the listing by expanding the scope pane and filtering for specific locations, device groups, networks etc.

By default, the table is sorted by risk score. Risk score is a product of cumulated CVSS scores and device criticality (see below). You can re-sort the table by clicking on any column header.

The different columns have the following meaning:

Device ID
The device ID of the device.

Name
The hostname of the device.

Type
The hardware type of the device.

Vendor
The hardware vendor of the device.

Model
The hardware model.

OS/Firmware
The operating system or firmware version running on the device.

Description
The description of the device.

Criticality
The criticality of the device (see below).

#CVE
Number of CVEs for this device.

VScore
The vulnerability score for this device, computed as the cumulation of CVSS base scores of the vulnerabilities of this device.

RScore
The risk score for this device, computed as a product of vulnerability score and criticality index (see below).

Using device criticality qualifications

If your OT infrastructure is not totally atypical, you will never be able to patch all vulnerabilities. This given, a smart strategy is to prioritize mitigation efforts for "critical" devices. What is a critical device? Well, your engineers will most likely be able to tell. Usually, if a device has any of the following characteristics, it is considered critical:

• the device performs a safety function
• the device performs a security function (not limited to cyber security; think about physical security as well)
• the device is critical for business continuity (example: trunk switches/routers that will cause multiple processes to fail if not properly functioning, or automation devices controlling support systems that are required by multiple machines)
• the device assures product quality and, if not functioning properly, could cause compromised products to leave the factory.

There is no standard on how to qualify and assess criticality, so your organization may well have other or additional criticality categories. For this reason, OTbase allows you to express criticality as free text.

Note: You don't have to set criticality for every single device; whenever possible you will take advantage of the bulk edit feature. Device criticality can also be set via JSON import and via the REST API.

A criticality qualification in OTbase consists of a string value that expresses a cricitality dimension, such as safety, and an optional scalar (numeric) value that can be added following a colon. If no scalar value is provided, a value of 1 is used as a default. It is recommended to use 2 or probably even 3 as a maximum value. Higher values will have a dramatic effect on risk computations.

The "Safety" field for devices is not used for risk computation. It is intended to reflect any safety certifications that a device may have.

You can combine multiple cricitality dimensions where it makes sense. For example, a device that is critical both for a security function and for a business continuity function may be qualified by "SECURITY, BCONTINUITY". Just separate the different dimensions by commas. Scale values will be cumulated.