Network Security
Device-ID Overview
Table of Contents
Expand All
|
Collapse All
Network Security Docs
Device-ID Overview
Learn about Device-ID.
| Where Can I Use This? | What Do I Need? |
|---|---|
|
|
According to the 2020 Unit 42 IoT Threat Report,
30% of all network-connected devices in an average enterprise are
IoT. This presents a growing area of risk with many possibilities
for exploitation by malicious users. Additionally, once you identify
these devices, how do you secure them from vulnerabilities such
as outdated operating software? Using Device-ID™ on your firewalls,
you can get device context for events on your network, obtain policy
rule recommendations for those devices, write policy rules based
on devices, and enforce Security policy based on the recommendations.
Similar to how User-ID provides user-based policy rules and App-ID
provides app-based policy rules, Device-ID provides policy rules
that are based on a device, regardless of changes to its IP address
or location. By providing traceability for devices and associating
network events with specific devices, Device-ID lets you gain context
for how events relate to devices and adds policy rules that are
associated with devices, instead of users, locations, or IP addresses,
which can change over time. You can use Device-ID in Security, Decryption, Quality
of Service (QoS), and Authentication policy rules.
For Device-ID features to be available on a firewall, you must
purchase an Device Security subscription and select the firewall during
the Device Security onboarding process. There
are two types of Device Security subscriptions:
- Device Security Subscription
- Device Security – Doesn’t Require Data Lake (DRDL) Subscription
With the first subscription, firewalls send data logs to Strata Logging Service, which streams them
to Device Security for analysis and to a Strata Logging Service instance
for storage. The data lake instance can either be a new or existing one. With the second
subscription, firewalls send data logs to Strata Logging Service, which streams them to
Device Security for analysis but not to a Strata Logging Service instance for storage.
It’s important to note that both Device Security and Device Security (DRDL) subscriptions
provide the same functionality in terms of Device Security and Device-ID.
To permit connections to Device Security, a firewall needs a device
license; and to permit connections to Strata Logging Service, it needs
a Strata Logging Service license. A firewall also requires a
device certificate to
authenticate itself when connecting to Device Security and
Strata Logging Service.
If you use PAN-OS version 8.1.0 through PAN-OS 9.1.x on a firewall,
the Device Security license provides device classification, behavior
analysis, and threat analysis for your devices. If you use PAN-OS
10.0 or later, you can use Device-ID to obtain IP address-to-device
mappings to view device context for network events, use Device Security
to obtain policy rule recommendations for these devices, and gain
visibility for devices in reports and the ACC.
You can create a device-based Security policy on any Panorama
or firewall that uses PAN-OS version 10.0 or later. To enforce the
Security policy, the device must have a valid Device Security license.
To identify and classify devices, Device Security uses
metadata from logs, network protocols, and sessions on the firewall.
This does not include private or sensitive information or data that
isn’t relevant for device identification. Metadata also forms the
basis of the expected behavior for the device, which then establishes
the criteria for the policy rule recommendation that defines what
traffic and protocols to allow for that device.
When a firewall imports Security policy rule recommendations
and IP address-to-device mappings from Device Security, the firewall
sends its device certificate to
an edge server to authenticate itself. The edge server authenticates
itself to the firewall by sending its own certificate. The firewall
uses Online Certificate Status Protocol (OCSP) to validate the server’s
certificate by checking it against the following sites using HTTP
on TCP port 80:
- *.o.lencr.org
- x1.c.lencr.org
Panorama performs the same check to validate the edge server’s
certificate when Panorama imports policy rule recommendations from
Device Security.
After Device Security identifies and classifies the devices in your
network using the Palo Alto Networks firewalls already there—so
you don’t have to implement new devices or third-party solutions—Device-ID
can use this data to match devices with policy rules and provide
device context for network events. Through the visibility that the
firewall or Panorama provides for traffic, apps, users, devices,
and threats, you can instantly trace network events back to individual
devices and obtain Security policy rule recommendations for securing
those devices.
All firewall platforms that support PAN-OS 10.0 also support
Device-ID and Device Security except the VM-50 series,
VM-200, and the CN-Series.
There are six levels of classification (also known as attributes)
for devices:
| Attribute | Example |
|---|---|
|
Category
|
Printer
|
|
Profile
|
Sharp Printer
|
|
Model
|
MX-6070N
|
|
OS Version
|
ThreadX 5
|
|
OS Family
|
ThreadX RTOS
|
|
Vendor
|
SHARP Corporation
|
To obtain policy rule recommendations for devices in your network, the firewall observes traffic
to generate Enhanced Application logs (EALs). The firewall then forwards the EALs to the
Strata Logging Service. Device Security receives logs from the Strata Logging Service for analysis,
provides IP address-to-device mappings, and generates the latest Security
policy rule recommendations for the device profiles of your devices. You can
then import the rule recommendations to the Security policy rulebase on a firewall or,
through Panorama, to the rulebase on multiple firewalls and commit your Security
policy.
To identify devices with dynamically assigned network settings,
the firewall must be able to observe DHCP broadcast and unicast
traffic on your network. Device Security also supports devices with static IP addresses.
The more traffic the firewall can observe, the more accurate the
policy rule recommendations are for the device and the more rapid
and accurate the IP address-to-device mappings are for the device.
When a device sends DHCP traffic to obtain its network settings,
the firewall observes this type of request and generates EALs to
send to the Strata Logging Service, where Device Security accesses them for
analysis.
To observe traffic on a Layer 2 interface, you must configure
a VLAN for that interface. By allowing the firewall to treat the
interface as a Layer 3 interface for a DHCP relay, it can observe the
DHCP broadcast traffic without impacting traffic or performance.
Because the firewall needs to both detect the devices based on
their traffic and then enforce Security policy for those devices,
the firewall acts as both a sensor to collect metadata
from devices and an enforcer by enforcing your Security
policy for the devices. Device Security automatically detects new devices
as soon as they send DHCP traffic and can identify 95% of devices
within the first week.
In addition to the traffic that traverses firewalls, there are options to obtain
traffic metadata from other areas of your network where device traffic does not reach
the firewall. You can
mirror traffic from network switches through GRE
tunnels,
forward server logs from DHCP servers,
use SNMP to query switches,
and integrate with third-party products.
Device Security automatically creates a policy rule recommendation for each application used by
devices in the same profile and pushes all its latest rule recommendations for a profile
when you choose a profile in the PAN-OS web interface (Device or Panorama Policy RecommendationIoT). After you import a policy rule recommendation into the Security policy
rulebase, the firewall or Panorama creates a source device object that identifies the
device profile where traffic originates.
If any of the device objects already exist on the firewall or
Panorama, the firewall or Panorama updates the device object instead
of creating a new one. You can use these device objects in Security,
authentication, decryption, and Quality of Service (QoS) policy
rules.
Additionally, the firewall assigns two tags to each rule:
- One that identifies the source device, including the category (such as Amazon Device).
- One that indicates that the rule is an IoT policy rule recommendation (IoTSecurityProfileBehavior).
For optimal deployment and operation of Device-ID, we recommend
the following best practices:
- Deploy Device-ID on firewalls that are centrally located in your network. For example, if you have a large environment, deploy Device-ID on a firewall that is upstream from the IP address management (IPAM) device. If you have a small environment, deploy Device-ID on a firewall that is acting as a DHCP server. For more deployment suggestions, see Device Security.
- During initial deployment, allow Device-ID to collect metadata from your network for at least 14 days. If devices are not active daily, the identification process might take longer.
- Create device-based policy rules in order from your most to
least critical devices. Use the following considerations to prioritize
them:
- Class (secure networked devices first)
- Critical devices (such as servers or MRI machines)
- Environment-specific devices (such as fire alarms and badge readers)
- Consumer-facing IoT devices (such as a smartwatch or smart speaker)
- Enable Device-ID on a per-zone basis for internal zones only.