Vulnerabilities list

CVEs describe a generic problem that is associated with a certain software or hardware product. Vulnerabilities are individual instances of such generic problems. Let's assume a given CVE affects FactoryTalk version x.y, and you have installed this product in this particular version on thirty devices, your one CVE turns into thirty vulnerabilities. In a way individual vulnerabilities are much more important than CVEs, because vulnerabilities is what you must remediate, and it certainly makes a difference if a CVE affects three or three hundred devices, because remediation may take so much longer.

So let's look at the vulnerabilities list. It is very important to understand because you will most likely use this list to define your remediation tasks. It is also the basis for generating vulnerability reports in the REPORTS/CVE section.

Note that table columns use different color codes.

• Anything that relates to the nature of the vulnerability uses the CVE color coding that you also find in the CVE table, which basically resembles kind of a heatmap for CVSS base scores: The higher the base score, the darker red the color code.
• Columns that refer to devices use the color code for the device type.

Available columns

The following columns are available in the vulnerabilities table:

Attack complexity

The complexity of a cyber attack exploiting this vulnerability, as assessed by MITRE (High, Medium, Low). As long as you don't already have a very good security posture, it's a good idea to filter for vulnerabilities that only require low attack complexity.

Attack vector

The proximity to the device that an attacker must have in order to exploit the vulnerability (Physical, Local, Adjacent Network, Network). "Network" basically means that the vulnerability is remotely exploitable via routing; something you should prioritize in your mitigation efforts.

Base score

The CVSS base score that MITRE uses to express the "badness" of the vulnerability (1-10).

Category

The category of the affected device (Computer, Automation Device, Network Infrastructure, ...).

Comment

A user-defined comment about this vulnerability.

Criticality

The criticality of the affected device, as rated by an SME.

CVE

The CVE ID of this vulnerability.

Description

Abbreviated description of this vulnerability as taken from the CVE.

Device ID

The device ID of the affected device.

Fixed

Indicates if the vulnerability is remediated, not necessarily by applying a security patch.

Model

The hardware model of the affected device.

Name

The name of the affected device.

Patched

Indicates if the vulnerability was remediated by applying a security patch. This field is set automatically when OTbase discovers that the appropriate patches have been applied.

Relevance

This field allows the user to determine that this vulnerability is irrelevant. It's good practice to use the Comment field to indicate why the determination was made.

Risk score

A user defined numeric risk score. This field is not set by OTbase. Here you can express your expert rating, which can then be used for sorting the vulnerability list.

Security

The security target level of the affected device, as assigned by a user.

Type

The device type of the affected device (Desktop, L2-Switch, PLC, ...).

Vendor

The vendor of the affected device.

Vulnerable

Indicates if the device is still vulnerable for this vulnerability. By default the vulnerability list contains entries for mitigated vulnerabilities as well. If you only want to see unmitigated vulnerabilities, filter the "Vulnerable" column using the value "yes".

Using the vulnerabilities table

Drill-down

As always in OTbase, you can drill down into more detail by double-clicking on a row in the table that you want to learn more about. In this case, the target profile that you will get depends on which column you click:

• Clicking on a CVE related field will open the CVE profile for this vulnerability.
• Clicking on a device related field will open the device profile of the affected device.

Filtering

You can use the CVE details list as a vulnerability mitigation worksheet.

• By filtering the list, you can define a result set that you want to use for a remediation task.
• By saving a given scope and filter combination as a managed view, you can pipe the result set directly into a remediation task. At the same time, a vulnerability REPORT will be created for you automatically.
• By exporting the result set to Excel, you can easily pass it to coworkers and contractors who don't have access to OTbase Inventory, or to auditors and regulatory authorities for documentation.

Filtering for more than one CVE

You can use the CVE column for filtering for one specific CVE just by entering the CVE identifier. What if you want to filter for a specific set of CVEs? For this scenario you go back to the CVE table and assign a tag to the CVEs that you want to cover.

Tags that you assign to CVEs are automatically inherited by vulnerabilities.

Therefore, if you go back to the vulnerabilities table, you can now filter this table using the tag that you have assigned in the CVE table. For example, if you have already filtered the CVE list for all CVEs that affect Google Chrome, and assigned a tag to those CVEs, you can then use that tag to filter the CVE details list as well.

Saved views

Just like in the device inventory, you can save a given filter setting as a "view". This is particularly useful for the definition and execution of remediation tasks where you and your team set out to mitigate a particular set of vulnerabilities. In order to save current filter settings, click on "Manage Views". Then use a catchy name and decide if the view shall be private or public.

You will now be able to revert to your saved filter settings by simply selecting the view from the drop-down next to "Manage Views".

Editing entries

Note that the CVE details list also allows you to enter comments, set risk scores etc. This is particularly useful to provide additional information the following situations:

• You decide that a particular vulnerability is irrelevant for a result set and therefore set the Relevance field to "No". In other words, you are documenting an exception.
• You mitigate a vulnerability using compensating controls, such as network segregation or application whitelisting and then manually set the vulnerability to "fixed".

Note that you can use bulk edit to edit multple entries at once.

Vulnerability reports

And it even gets better. Saving a filter setting will automatically generate a report that you can access in REPORTS/CVE. The report shows you all vulnerable devices, and a graphical representation of the decrease or increase in number of vulnerabilities over time.

Video