Device Matrix
Turning thousands of device-to-device traffic paths into one readable grid, with a guided path to fixing what’s wrong.
the problem //
A hospital or industrial network can have tens of thousands of devices talking to each other across dozens of segments. Security teams need to answer “what’s allowed to talk to what” at a glance, and then act on anything risky, but the underlying data is just a massive set of flow logs with no inherent visual structure.
From flow log to scannable grid
Turn a flow log into a grid anyone can scan. Every device group becomes a row and column; every cell shows the traffic status between them — a lightning bolt for allowed, a red icon for blocked, a flask for unreviewed, an arrow for one-directional traffic — so a security admin can spot a problem cell without reading a single log line.
One filtering pattern, both sides
Keep the filtering pattern identical on both sides. Source and Destination each use the same checkbox-list dropdown, so learning to filter one side means already knowing how to filter the other.
Source & Destination bucket filters
Narrow a huge matrix down to what matters. Source and Destination panels let users filter by Buckets, Groups, or Device Types (like IoMT → Medical Devices going to IT → Printers), collapsing an overwhelming full-network view into the one relationship they actually need to investigate.
A deliberate empty state
Click a flagged cell and the Create New Rule drawer opens. Before a violation or device is chosen, the Apply Policy panel shows a direct, plain-language prompt instead of a blank space — handling the “nothing selected yet” moment deliberately and keeping the user oriented on what to do next.
Apply Policy — Configure
For the analyst who wants full control, Configure Policy exposes the raw knobs — source and destination group, protocol, destination port, optional peer IP or domain, inbound/outbound, and allow/deny — so a precise rule can be tuned by hand.
Apply Policy — Apply Template
For speed and consistency, Apply Template offers pre-built policy profiles like DNS_NTP or IoT_Modbus, so a known-good rule can be dropped in with one click instead of authored from scratch.
Apply Policy — Generate ACL
For the network engineer, Generate ACL produces the exact CLI syntax for the target switch, ready to review or paste — the same rule, expressed in the language of the wire.
design strategies //
- 01Visual language over raw data — icons and color replace a text-based traffic log, so status is legible before anyone reads a value.
- 02Progressive narrowing — from full matrix, to filtered view, to a single violation, to a specific rule, each step reduces scope without losing context.
- 03Multiple paths to the same outcome — template, manual config, and raw ACL all produce a working rule, matched to the user’s expertise.
- 04Simulate-before-enforce — every rule can be tested before it goes live, reducing the risk of a misconfiguration in production.
outcome //
What used to require manually cross-referencing flow logs became a single scannable grid, with a guided path from spotting a violation to shipping a working, tested network policy, without ever leaving the page.
abstract //
At Ordr I owned core product flows and dashboards for Ordr Protect — a B2B SaaS platform unifying detection, investigation, response, and administration into a single coherent interaction model. I designed Ordr AI CAASM+ for comprehensive asset inventory across IoT and OT environments, the Asset Graph for vulnerability visibility across complex device relationships, and the Ask AI copilot using progressive disclosure to simplify dense security workflows.
Use case #04
Security Risk Configuration