Device Security Device Details Page
The Device Details page in the Device Security portal shows
detailed information about a specific device.
| Where Can I Use This? | What Do I Need? |
|---|
|
|
One of the following subscriptions:
Device Security subscription
Precision AI bundle subscription
Device Security X subscription
|
To see details about a device, click its device name. The Device Security
portal then displays the device details page, with content grouped into the
following sections:
Identity: The Identity section at the top of the page provides
identifying data such as the category and profile of a device, its vendor and
model, its OS, and various network-specific details.
The Device Security portal only shows a field if it has a value for it.
You might see more or fewer details than shown here, depending on the amount
of information Device Security has.
Active Directory Attributes (appears when Cloud Identity Engine
integration is enabled)
If you have on-premises Active Directory (AD) synchronized with Cloud Identity
Engine(CIE) and have a CIE tenant in the same tenant service group (TSG) as
your Device Security tenant, you can integrate Device Security with CIE.
Through this integration, you can identify devices discovered by Device Security
that are part of your AD and collect some AD attributes for display on the Device
Details page. To view only devices that are in Active Directory, you can filter
and search for devices in your inventory by their AD join status.
To integrate Device Security with CIE, log in to the Device Security
portal as a user with owner privileges, select
,
and toggle the integration on. The toggle is in the upper right of the page.
The External Link icon (
) opens the portal of your CIE tenant.
Because Device Security learns from the hub if a CIE tenant is part of its
TSG, it will either let you enable integration if Device Security and CIE are
both tenants in the same TSG, or the toggle will be inoperable if they are not.
Assuming you can enable integration, Device Security will do an immediate
retrieval of Active Directory attributes only if it's the first time or if the
last sync was more than 24 hours ago and then do a daily retrieval every 24
hours going forward. (Toggling the integration off and back on won't trigger a
new sync if it's less than 24 hours since the last one.) When you enable the
toggle, Device Security connects with your CIE and starts matching devices
against the CIE/AD database to identify which ones are in your AD. The matching
process compares the device name in Device Security with the Common Name in
AD. For devices that are in AD, Device Security also retrieves the following
attributes for display on the Device Details page:
|
Device attributes learned from Active Directory
|
| AD Domain | OS |
| Common Name (Device Security looks for Common Names in
Active Directory that match Device Names in Device Security.
When it finds a match, Device Security then retrieves device
attributes from Active Directory.) | OS Version |
| Distinguished Name | OS Service Pack |
| Security Accounts Manager (SAM) Account Name | Serial Number |
| AD Groups | Last Login (This is the last time a device authenticated to
AD. It comes from the AD lastLogon attribute.) |
When CIE integration is enabled, these attributes are displayed in columns on
the
page and in an Active Directory Attributes section on Device Details pages.
Device Security displays the source for attributes learned from Active
Directory through CIE integration as On-prem AD via CIE.
For most device attributes, Device Security uses the latest value it learns
regardless of whether it's discovered through network traffic or through an
integration. However, there are eight attributes for which a value learned
through network traffic has priority even if Device Security later learns of
a different value through integration:
|
Device attributes whose values when learned through network
traffic have priority over values learned later through
integration
|
| Model | Firmware |
| Vendor | Serial number |
| OS group | Wired or wireless |
| OS version | VLAN |
If Device Security learns a conflicting value for one of these attributes,
it prioritizes the value learned through network traffic first and then through
an integration (including CIE integration) second. The basic logic is as
follows:
Whatever new value is learned through network traffic replaces a value
learned previously by any means.
A new value learned through integration will replace a previously learned
value learned through the same type of integration. It won't replace a
value learned through network traffic or through another type of
integration.
Security (summary): The information in the next section relates to
security and includes the individual risk score for the device and whether
baseline modeling is complete or still in progress. The current behaviors
diagram shows evaluations for five types of behavior ranging from normal (near
the center) to anomalous (near or beyond the edge).
When the Device Details page is for a medical device for which
Device Security has an
MDS2 file, it displays
information about device capabilities and operational states learned from the
file such as the following:
Remote service and patch support
Personal health information (PHI) types and transmission support
Antivirus installability and patchability
Data storage and encryption
Whether unnecessary applications and ports have been disabled
Device communications both within and outside its local network
Support for external user authentication
Device Security uses the attributes listed in the MDS2 file to adjust the
baseline risk level of the device. Risk factors based on MDS2 attributes
contribute to a portion of the overall
device risk score.
Risks: The Risks section contains the alerts, vulnerabilities, and
anomalies that occurred to the device during the time range set at the top of
the page. The events are displayed along a timeline and in a list with detailed
information about each one.
When Device Security has recommendations for responding to a risk, it
displays More Insights. Click it to expand the section
and read more about how the impact of the risk on the device and network and
what you can do to address it.
For medical IoT devices with MDS2 risks that were summarized near the top of
the page, the risks are also listed with a few more details here.
Device Security displays them after any other detected vulnerabilities.
Alerts: This section contains only the alerts that the device raised
during the specified time range. Alerts are a subset of risks, and
Device Security generates them when it detects irregular behavior and
activity matching an alert rule. You can see when alerts occurred along a
timeline, read details about them, and take action to resolve them.
Security: The Security section contains three subsections that show how
a device connects to other devices on the network and which applications it's
using.
Network Traffic: View a conceptual network topology displaying
the nodes with which the device has formed connections. Use filters to
display inbound or outbound connections; nodes with various alert levels;
connections to nodes within the same VLAN, same intranet, or in the
internet; and so on.
If you click Explore Topology, a new browser window opens with
an informative display of internal and external connections from the
device in focus. You can interact with the information, viewing details
about each node and clicking different ones to put them in focus and see
their connections.
Any node with "S" on it is a server.
To learn more, watch a pair video explanations of the Topology Explorer.
Part 1 covers navigation,
information pop-ups, zoom, device category filters, and SMB filters.
Part 2 looks at the information
panel, how to explore the topology, and how to start a new path. Each
video is about two to three minutes long.
Applications: This section shows the applications the device
uses, their risk levels (a 1-5 scale with numbers closer to 5 indicating
increased risk), and how many other devices and device profiles use the
same application. Click a number in the Used by Devices column to open
the Devices page with its contents filtered by the corresponding
application. Hovering your cursor over the blue text of an entry in the
Profiles column displays a list of all profiles that use that application.
Software Components: Most software makes use of various
third-party software components such as libraries, modules, binaries,
compilers, executables, files, and source code. The details of these
components are increasingly being documented within Software Bills of
Materials thanks to the Software Component Transparency initiative led
by the
U.S. National Telecommunication and
Information Administration and with the participation of
numerous manufacturers. A Software Bill of Materials (SBOM) is a
comprehensive record detailing all the bits and pieces of software
within a system or device and their relationships with each other. It's
essentially a nested inventory of software components and subcomponents,
including firmware and embedded software. It also typically includes
licensing, author, and version information plus other metadata. The
purpose is to provide as much transparency as possible into the software
contents running on devices so that we can better protect them from
attack.
Some exploits specifically take advantage of the very lack of
transparency and target vulnerabilities that occur in software components
such as Spring4Shell, Urgent/11, Ripple20, and Log4j 2. Knowing which
software components are on a device can expedite vulnerability detection,
risk analysis, and remediation efforts. For example, the Log4j 2
vulnerability affects specific versions of the Apache Log4j 2 Java
logging library, an open-source Java-based logging framework used by
Java applications around the world. Attackers can exploit the
vulnerability to launch denial-of-service attacks or gain remote control
of target devices. The first step in responding to this threat is to
identify which devices use the Log4j 2 Java logging library and, if so,
if it's a vulnerable version. With Device Security, you can search
your inventory for devices using this particular library and version–or
for devices vulnerable to one or more of the related CVEs–in just
seconds and save days or even weeks of response time.
Device Security primarily learns SBOM information from traffic
inspection of, for example, the user agent field in HTTP headers and to
a lesser degree from other sources like FTP banners and HTTP URL
information. It then shows the software components and version numbers
identified in the SBOM for a device in the Software Components column on
the Devices page. Device Security also shows the software component
name, version number, and any related CVEs in the Software Components
section on the Device Details page.
You can download a device inventory report from the Devices page. The
report includes a list of software component names and version numbers
for all devices with software libraries detected by Device Security.
You can also download the software library details for an individual
device in Software Package Data Exchange (SPDX) format, which is one of
the most common data standards for capturing SBOM data. To download the
SPDX file, click Download SBOM at the bottom of
the Software Components section. You can then open and read the SPDX
file with any standard text editor.
The amount of data Device Security learns is limited to whatever
SBOM information devices send over the network and by what can be
extracted from network traffic.
Network Usage: The last section shows a Sankey diagram with
lines indicating network connections. The red line indicates it's
involved in an alert of high severity. Click one of the blue bars and
then click the Create Policy option that appears
to create a policy with the following fields in the Policy Editor auto
filled: ("Group #1" = source, and "Group #2 = destination).
MDS2 (for medical IoT devices)
Medical device vendors often list the security-related features of their
products in Manufacturer Disclosure Statement for Medical Device Safety (MDS2)
forms, which they share with their customers. Vendors issue these MDS2
documents for each version of a medical device and include valuable information
such as whether a device processes PHI (personal health information); if it
stores PHI and, if so, if it's encrypted; and if antivirus software is
installed on the device.
Over time, healthcare providers can collect thousands of MDS2 documents for
thousands of medical devices. When used as intended, MDS2 documents can greatly
enhance your security posture and incident response (IR). However, absorbing
the details from these documents for the specific version of the software
running on their connected devices is a daunting task. As a result, MDS2 files
often go unused.
Device Security simplifies the management and use of the MDS2 files you
have. If you upload an MDS2 file for a device to Device Security, it then
includes this data along with other environmental factors when assessing the
risk to the device. For example, if the software version of a device specified
in an MDS2 file has a known vulnerability, Device Security more precisely
identifies it as a vulnerability instead of just a potential vulnerability.
Device Security supports MDS2 files in 2004, 2008, 2013, and 2019 formats.
To upload an MDS2 file for one of your medical devices, click the MDS2 button
on the Device Details page, click the upload icon in the lower right corner,
and then navigate to your MDS2 document (its format must be PDF) and upload it.
A prompt appears to apply the MDS2 file to all devices sharing the same model,
vendor, and profile. To apply the MDS2 file to all devices with the same
attributes, click Yes. To apply it to just this
particular device, click No.
To upload MDS2 files and automatically apply them to all devices with
matching model, vendor, and profile attributes, use the upload option on
.
For more information, see
MDS2.
An entry for the uploaded MDS2 file appears in the MDS2 section on the Device
Details page with some upload details, device manufacturer name, and software
revision number (if available). In addition, if you selected
Yes when prompted to apply the MDS2 file to other
devices with the same model, vendor, and profile and there are such devices,
then Device Security applies the uploaded MDS2 file to them as well.
The upload date shows when this file was uploaded to Device Security.
The timestamp uses the time zone specified on the Preferences page (
> Preferences).
The source of an uploaded MDS2 file is always Directly
Uploaded, which means that a user manually uploaded the file to
Device Security.
The status of an uploaded file indicates one of the following states:
Matched – The uploaded file is a PDF containing
correctly formatted fields
Cannot Extract Data – The file is a PDF with
incorrectly formatted fields
Unsupported File Type – The uploaded file is not
a PDF
If the file status is either of the last two states, hover your cursor over
the table row with the MDS2 file and then click the Delete icon that appears
on the far right (
).
To see more details about the device and MDS2 file, expand the row.
A manufacturer might release an updated MDS2, perhaps to add more models to
the Device Model list, change its Manufacturer Contact Information, or for some
other reason. If so, delete the first MDS2 file and then upload the new file.
To see a preview of an MDS2 file, hover your cursor over its table row, which
causes the preview icon to appear (
). Either click the icon or hover your
cursor over it to see the file in a pop-up preview window.
Use the viewing options to scroll through the file and zoom in and out.
To view the file itself, click the filename. Device Security downloads the
PDF file so you can open and view it locally.
Device Security uses several fields in MDS2 forms for risk detection:
Can this device display, transmit, or maintain private data?
What types of private data elements can be maintained by the device?
Can security patches or other software be installed remotely?
The wording for these questions varies in different versions of MDS2.
This information can help Device Security assess risk. For example, if an
MDS2 file states that a device doesn't support remote servicing and
Device Security detects an inbound connection from an external source, it
will flag this as anomalous behavior and generate a security alert. Similarly,
if an MDS2 file states that a device cannot be remotely patched, any attempted
inbound file transfer from an external location will also be treated as
anomalous and trigger an alert.
