Skip to content
Notifications
Clear all

Thoughts on the new IoT security module? Seems like a repackaged network scanner.

2 Posts
2 Users
0 Reactions
30 Views
(@integration_ian_2)
Honorable Member
Joined: 4 months ago
Posts: 525
Topic starter   [#11815]

I've been testing the new IoT security module in our staging environment for the past three weeks, and I have to say my initial impression is... underwhelming. It feels less like a dedicated IoT security solution and more like the existing network scanner with a fresh coat of paint and a new dashboard label. The core functionality—device discovery, classification, and baseline policy—appears to be leveraging the same asset discovery engine and signature database that have been part of the network scanning suite for years.

My main concern stems from trying to build automated workflows around it. The API endpoints for the IoT module (`/web_api/v1.5/show-iot-devices`, `/web-api/v1.5/set-iot-device-tag`) are virtually identical in structure to the generic device APIs, just with a different path prefix. This suggests it's the same data model underneath. For example, when I pull a device list:

```json
{
"objects": [
{
"uid": "94ac5c60-5f77-0e34-8a8a-abcdef123456",
"name": "Manufacturing_Floor_Sensor",
"ipv4-address": "10.50.30.15",
"type": "iot-device",
"iot-properties": {
"category": "Industrial",
"vendor": "Generic",
"risk": "Medium"
}
}
]
}
```

The `iot-properties` object is new, but the surrounding structure and the method of polling for changes is identical to the standard `show-hosts` command. This creates a few practical integration headaches:

* **No dedicated IoT event log:** Security events from these devices still flow into the general threat log. To filter for IoT-specific incidents, you must rely on the same `type:attack` or `service:iot` filters, which aren't always precise.
* **Webhook limitations:** The trigger events for "IoT Device Violation" use the same webhook payload schema as a generic "Security Event," forcing you to parse the `additional-information` field to confirm it's IoT-related. This adds unnecessary complexity to my Make (formerly Integromat) scenarios and Zapier zaps.
* **Policy sync delays:** When a new IoT device is profiled, there's a noticeable lag before its dedicated policy objects are available via API, similar to the delay we see with regular network objects after a scan.

I was hoping for a truly specialized framework—something with deep, out-of-the-box understanding of OT protocols, behavioral baselining for device chatter, and native integration hooks for ticketing or asset management systems like ServiceNow for these unique devices. Instead, it seems we're getting a filtered view of the network.

Has anyone else dug into the APIs or tried to build external automations with this module? I'm particularly interested in:
* Whether you've found a true dedicated IoT event stream I might have missed.
* Your experience with the accuracy of the `iot-properties` classification versus manual audits.
* Any workarounds you've built to get real-time alerts for IoT-specific anomalies into platforms like Salesforce CRM or a dedicated Slack channel for the facilities team.

The promise of IoT security is huge, but for automation enthusiasts like us, the implementation needs to be more than a repackaged dataset.

api first


api first


   
Quote
(@danielb)
Reputable Member
Joined: 3 months ago
Posts: 252
 

Your API observation is correct. They're using the same ORM mapping with an `iot-devices` view. The risk scoring is just a weighted lookup against the existing vulnerability database.

Run a benchmark. Query `show-devices` filtered by type and time it against the new IoT endpoint. I'd bet the latency and query plans are identical.



   
ReplyQuote