IoT Security Administrator’s Guide
    : IoT Security Device Details Page
    Focus
    Download PDF
    Focus
    1. Home
    2. IoT
    3. IoT Security Administrator’s Guide
    4. Discover IoT Devices and Take Inventory
    5. IoT Security Device Details Page
    Download PDF

    IoT Security Administrator’s Guide

    IoT Security Device Details Page

    Table of Contents

    IoT Security Device Details Page

    The Device Details page in the IoT Security portal shows detailed information about a specific device.
    To see details about a device, click its device name. The IoT Security portal then displays the device details page, with content grouped into the following sections:
    • Identity
    • Active Directory Attributes (appears when Cloud Identity Engine integration is enabled)
    • Security (summary)
    • Risks
    • Alerts
    • Security
      • Network Traffic
      • Applications
      • Software Components
      • Network Usage
    • MDS2 (for medical IoT devices)
    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 IoT 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 IoT 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 IoT Security tenant, you can integrate IoT Security with CIE. Through this integration, you can identify devices discovered by IoT 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 IoT Security with CIE, log in to the IoT Security portal as a user with owner privileges, select IntegrationsCloud Identity Engine Integration, 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 IoT Security learns from the hub if a CIE tenant is part of its TSG, it will either let you enable integration if IoT 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, IoT 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, IoT 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 IoT Security with the Common Name in AD. For devices that are in AD, IoT Security also retrieves the following attributes for display on the Device Details page:
    Device attributes learned from Active Directory
    AD DomainOS
    Common Name (IoT Security looks for Common Names in Active Directory that match Device Names in IoT Security. When it finds a match, IoT Security then retrieves device attributes from Active Directory.)OS Version
    Distinguished NameOS Service Pack
    Security Accounts Manager (SAM) Account NameSerial Number
    AD GroupsLast 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 AssetsDevices page and in an Active Directory Attributes section on Device Details pages. IoT Security displays the source for attributes learned from Active Directory through CIE integration as On-prem AD via CIE.
    For most device attributes, IoT 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 IoT 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
    ModelFirmware
    VendorSerial number
    OS groupWired or wireless
    OS versionVLAN
    If IoT 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 IoT 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
    IoT 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 IoT 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. IoT 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 IoT 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 IoT 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.
      IoT 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. IoT 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 IoT 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 IoT 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.
    IoT Security simplifies the management and use of the MDS2 files you have. If you upload an MDS2 file for a device to IoT 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, IoT Security more precisely identifies it as a vulnerability instead of just a potential vulnerability. IoT 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 AdministrationMDS2. 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 IoT Security applies the uploaded MDS2 file to them as well.
    The upload date shows when this file was uploaded to IoT 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 IoT 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. IoT Security downloads the PDF file so you can open and view it locally.
    IoT 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 IoT Security assess risk. For example, if an MDS2 file states that a device doesn't support remote servicing and IoT 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.

    © 2024 Palo Alto Networks, Inc. All rights reserved.