Features · v4.4.3
Discovery, identification, an asset inventory, behaviour baselines, explainable detection, industrial protocol visibility and optional, controlled response. Everything on this page is in the released version unless it is marked experimental or planned. Plans are on the roadmap.
New in 4.4
Connectors that show what a device hangs on, rules you can write and try first, alerts that are not lost, and keys you can rotate. Experimental parts are marked.
DENIS shows what a device hangs on: access points and switches under their controller, virtual machines under their host. New connectors: TP-Link Omada, MikroTik Wi-Fi and the Cisco Catalyst 9800 wireless controller, TP-Link Omada was tried on real equipment and is no longer Experimental (4.4.2); the other two are Experimental.
One dialog names the few responses that can work for this device and says why one is recommended.
The same address in two routing domains is no longer taken for one network, and an administrator can split a shared hardware address into separate devices.
The new detections arrive switched off and wait on the Rules page; three (name poisoning and industrial networks) are Experimental. Rules can run in a trial mode, exceptions can expire, and a view shows what a change would have done over the last days. You can write your own rules with several conditions, try them, export and import them or start from a template; counts and sequences are Experimental and off by default.
An MSP can send you rules. You decide: not allowed (the default), ask me, or into a trial. MSP management is no longer marked Experimental.
Alerts and notices go through a durable queue: a receiver that is down, a restart or a failover no longer loses a message.
Every customer has its own data key. You can rotate it and the master key while DENIS runs and keep a passphrase copy of the master key.
Two servers on one PostgreSQL database are safer, and customers can live in PostgreSQL. Tested in containers and in a local fault lab, not on a managed service.
A Start page, one-line enrolment of agents and single-use invitations for MSP customers. Licensing counts devices seen in the last 30 days, in the tiers DENIS 500, DENIS 5000 and DENIS 20000.
Security fixes from the code review and patch updates of libraries, among them certificate verification. Shipped lists can update themselves (off by default), and the abuse.ch feeds use the current ThreatFox and URLhaus interfaces.
Since 4.3
A new Network section with a real map, more than 40 new detections, an honest page about blind spots, and less noise from alerts you already know about. Experimental parts are marked.
What you get
Less guessing about what is connected, earlier warning when something is wrong, and a controlled way to contain it.
A register of every computer, printer, camera, phone and machine on the network, found automatically and kept current, with owner, location and warranty.
A new device, a camera talking to the internet, a controller told to stop: you get one alert that says what happened, why it scored what it did and what to do first.
Related alerts become one incident, routine events go to a daily digest, and you can tune a rule for one device instead of switching it off.
The Respond menu knows where a device is and which firewall sits on its path. An administrator can block a device or a connection, quarantine it or switch its port off through the switches and firewalls you already own, after a full preview, with a time limit and a release.
Laptops, IoT and industrial controllers in one inventory and one alert stream. On industrial networks DENIS only listens.
Several customers on one installation, each kept apart, with small collectors at every site and your own branding.
Automation and Autopilot are experimental and off by default; MSP remote management is off until a customer pairs. DENIS does not block anything by itself unless an administrator sets it up that way. Read the enforcement guide.
Since 4.2
4.2 made the response half more exact and the whole product easier to trust: it knows where a device really is, shows how the equipment is wired, and ships the material your own reviewers ask for.
The Respond menu shows where a device is and which firewall sits on its path. It offers a port or a firewall only when DENIS is sure, and says why an action is unavailable. Every plan states exactly what it covers, and what it does not.
The map now shows the cables between switches, firewalls and access points, each marked confirmed, best guess or set by hand, and you can fix one by dragging. The Equipment page lists one row per device, in the order of the wiring or your own.
A router or firewall seen under several hardware addresses is one device, linked when it lists them itself or when you confirm, and DENIS says why it suggests a link or why linking is paused.
A notification bell lists what needs your attention, and the messages to Slack, e-mail and the other channels name the device, so you do not have to look it up.
UniFi is reached with an API key and blocks through a firewall policy. Palo Alto blocks and quarantines through a dynamic address group: no commit, effective in seconds, checked every minute.
A rule can prepare a block for an administrator to approve, or block by itself once a trial of at least 7 days has shown what it would have done. Off by default, with the same preview, time limit and hourly limit as every other action.
The port scan and the ping can be switched off, for all networks or for one. A new documentation page, Security tools that may flag DENIS, lists exactly what DENIS sends so your IDS or endpoint product can be set up for it.
Security updates install automatically by default, with an opt-out, the same signature checks and automatic rollback. The secrets of authenticator apps are stored sealed, not in plain form.
Software bills of materials (CycloneDX and SPDX) attached to releases by the release process, a daily check of dependencies for known vulnerabilities, an architecture guide, an API reference and a Cyber Resilience Act readiness document. Evidence for your assessment, not a certification.
Automation, rule responses and Autopilot are experimental.
What DENIS does
Seven stages, one process, running on hardware you control.
Passive listening to ARP, DHCP, mDNS, SSDP, LLDP/CDP and PROFINET, plus polite active discovery (ARP sweep, ping, a light port scan) that you can switch off. Industrial devices are only ever listened to.
Manufacturer from the IEEE registry. Device type and operating system from weighted evidence: DHCP fingerprints, mDNS and SSDP announcements, open ports, names. Product and version from service banners. Every guess lists its evidence, and your correction always wins.
A baseline per device: the destinations it uses, its ports, how much data it moves and the hours it is active. Top talkers, traffic trends and country/ASN context for public addresses. Optionally, which of your own devices talk to each other: east-west recording is off until you switch it on.
New devices, new destinations and ports, unusual volume or hours, devices gone silent, rogue DHCP servers, ARP and gateway hijacks, internal scans, contact with known-bad addresses. Connections opened from the internet to one of your devices, such as a port forward to a solar inverter. Each alert gets a 0–100 score built from named reasons, and an Investigate section that puts it in context. Related alerts are grouped into incidents, and routine events go to a daily digest instead of your phone.
Passive decoding of Modbus, S7comm and S7comm-plus, EtherNet/IP-CIP, DNP3, BACnet, OPC UA, IEC 60870-5-104, IEC 61850, PROFINET IO and more. A communications matrix of reads, writes and control commands, and alerts for PLC stops, program downloads and Purdue-level violations, without sending a single packet to a controller.
Owners, locations, serial numbers, asset tags, warranties, criticality, tags and custom fields on top of what DENIS discovers, with full change history, a review queue for new devices and CSV import/export.
Findings with a concrete fix (known-exploited vulnerabilities, end-of-support software, exposed Telnet or RDP, devices without an owner), a daily ranked list of the devices that most need attention, compliance evidence, scheduled reports and exports to the tools you already run.
Explainable detection
Every DENIS alert carries a score from 0 to 100, and every point of it is attributed to a named reason. No black-box number. No “the model thinks this is bad”.
From the built-in demo network
Why this score
Why this score
Why this score
Why this score
Device guesses are explained too: Finance file server → nas: +5 vendor Synology, +5 SSDP server 'Synology' Real, from the demo data.
Asset inventory
DENIS starts from evidence: what is actually visible on the wire. You add what only people know: owner, location, criticality, warranty. Both stay in one place, with history.
| Device | Vendor | Type | OS | IP | MAC | Owner | Location | Risk |
|---|---|---|---|---|---|---|---|---|
| Core router | Ubiquiti Inc | router | Linux | 10.20.10.1 | 78:45:58:00:01:07 | IT | Server room | 0 |
| Finance file server | Synology Incorporated | nas | Linux | 10.20.10.20 | 00:11:32:00:05:23 | Finance | Server room | 26 |
| Entrance camera | Hangzhou Hikvision Digital Technology | camera | — | 10.20.10.41 | c0:56:e3:00:0a:46 | Facilities | Main entrance | 100 |
| Martin’s laptop | LENOVO | computer | Windows | 10.20.10.102 | 54:e1:ad:00:0d:5b | Martin Horváth | Office 2.07 | 42 |
| PLC Line 1 | Siemens AG | plc | — | 10.20.50.11 | 00:1b:1b:… | Production | Hall A, cabinet 3 | 37 |
Demo data. The real register also shows site, status, last seen, and anything you add.
OT / ICS security
Some PLC and RTU firmware does not cope well with unexpected connections, pings or port scans. So DENIS’s OT visibility is built on listening. Connect it to a mirror (SPAN) port or a network tap, and it decodes industrial conversations from a copy of the traffic. Nothing is sent to industrial devices.
--profile ot disables the ARP sweep, ping and port scan.
For the technical team
The key facts for the people who will install and run it. The full detail is in the documentation and on GitHub; what comes next is on the roadmap.
ARP, DHCP, mDNS, SSDP, LLDP/CDP, PROFINET DCP · TCP/IP stack fingerprinting · ARP sweep, ping and a light port scan (optional, switched off separately for all networks or one; never on industrial devices) · mirror/SPAN interfaces · mirrors delivered in ERSPAN, GRE, VXLAN or Geneve tunnels (opt-in) · VLAN tags read and shown per device (the same MAC on several VLANs is one flagged device) · opt-in IPv6 · offline pcap replay
IEEE OUI vendor identification · device type and OS from weighted evidence, with the evidence shown · product and version from SSH, FTP, SMTP, HTTP, Telnet, MySQL/MariaDB, SMB and MSSQL banners · JA3/JA3S TLS fingerprints · fleet-wide software inventory · a 0–100 risk score shown as its own sortable column in the Devices table
new in 4.4: twelve detections, switched off until you accept them on the Rules page (three are Experimental) · a trial mode for rules, exceptions with an expiry, a view of what a change would have done over the last days, and the reason a rule alerted or did not · your own rules with several conditions, tried first, exported, imported or started from a template (counts and sequences are Experimental and off by default) · new in 4.3: more than 40 detections, among them program uploads, several masters, a changed device identity and commands outside working hours on industrial networks, and brute force from outside, DNS threat domains (needs a free abuse.ch key), mining pools, VPN and anonymizer use, remote-access tools, a changed gateway and a rogue DHCPv6 server on office networks · detection on its own threads, measured per detection, pausing the heaviest optional detections under overload · This is normal on any alert, with accepted and dismissed counts per detection · per-device baselines · new device, new destination and a new service port in use · unusual volume and hours · silent devices · rogue DHCP, DHCP drift and starvation · ARP conflicts and gateway takeover · internal sweeps and port scans · outbound fan-out · known-bad destinations (your list, plus optional abuse.ch and Spamhaus feeds) · connections opened from the internet to one of your devices (needs --flows) · your own IT rules and OT rules, written from templates with a preview of what a rule would have done over the last 7 days · 0–100 explainable scoring · incidents · a quieter alert stream: routine events kept in the console and a daily digest with the reason, never threat-list matches, rogue DHCP or industrial control commands · an Investigate section on every alert: the device’s surrounding events, its recorded traffic with the other party, which other devices contacted that party, the incident link
traffic flows and conversations · relationships: which device talks to which, per protocol and port, first and last seen, observed or inferred · opt-in east-west recording of traffic between your own devices (off by default; bounded per device, every limit shown on the Health page) · top talkers · trend charts · destination history · country, city, ASN, AS organisation and reverse DNS for public IPs, from a local GeoIP database
what a device hangs on: access points and switches under their controller, virtual machines under their host, shown on the map (4.4) · the same address in two routing domains is not taken for one network, and a shared hardware address can be split by an administrator (4.4) · Wi-Fi clients and access points from TP-Link Omada (no longer Experimental since 4.4.2), MikroTik and the Cisco Catalyst 9800 (4.4; the last two Experimental) · a network map with zoom, search, groups and cable drawing that saves itself, and Equipment, Response and Setup pages (4.3) · any managed switch with standard SNMP can be read (4.3; port off and quarantine VLAN on such switches are Experimental, off by default, need a write test and are tested only on simulators) · client lists from UniFi and, Experimental, Meraki on the map, read only (4.3) · logical map by gateway, coloured by risk · switch ports, LLDP neighbours and MAC-to-port mapping over SNMPv2c or SNMPv3 (read-only; Cisco switches read per VLAN) · physical “switches and cables” view · cables between switches, firewalls and access points, each marked confirmed, best guess or set by hand (drag to correct one) · an Equipment page with one row per device, ordered by the wiring or by hand · one device identity: a router or firewall under several hardware addresses is one device, with the reason shown
Modbus, S7comm, S7comm-plus, EtherNet/IP-CIP, DNP3, BACnet, OPC UA, IEC 60870-5-104, IEC 61850 (MMS and ICCP, GOOSE, Sampled Values), PROFINET IO, Omron FINS, MQTT, CoAP, HART-IP, KNXnet/IP, CODESYS (recognised only), over IPv4 and, with IPv6 on, IPv6 · communications matrix · reads, writes and control commands · Purdue levels and zones · OT rules · ICS-CERT advisory matching by vendor
Messages split across TCP segments are followed. Since 4.1.2, messages cut by IP fragmentation are put back together too, within fixed limits; overlapping or too-small fragments are refused and shown on the Health page. Since 4.1.3 their TCP or UDP checksum is checked: a wrong one is counted on the Health page, and the message is still decoded, because some devices would carry it out.
a Not managed view of devices no management, directory, scanning or endpoint tool reports (4.3; tested against fixtures, not a real tenant) · a timeline per device (4.3) · owners, departments, locations · serial numbers and asset tags · warranties · criticality · tags and custom fields · lifecycle status · change history · review queue · CSV import/export
known-exploited vulnerabilities (CISA KEV) with EPSS score, matched against the versions devices reveal · end-of-support software · exposed Telnet, RDP, VNC, FTP, MySQL, Winbox, SMB and MQTT · lost or retired devices still online · critical devices without an owner · warranties · Check again and Accept this risk workflow · “Top exposures today”: devices ranked by known-exploited and critical vulnerabilities, unsupported software, open incidents and high findings, weighed by what is at stake, every point listed with its source
CIS Controls v8 · NIST CSF 2.0 · IEC 62443-3-3 · NIST SP 800-82 · ISO/IEC 27001:2022 Annex A · NIS2 · DORA · PCI DSS v4.0 · HIPAA Security Rule · SOC 2 · CMMC 2.0
Evidence for your own assessment, not a certification.
block a device or one connection, quarantine a device, switch a switch port off or end its sessions, through the Respond… menu of a device, an incident or a flow · switches over SNMPv2c or SNMPv3, FortiGate, Palo Alto, MikroTik, UniFi and TP-Link Omada, and the Cisco Secure Firewall FDM and FMC block (tested in the Cisco DevNet sandbox on virtual devices) and AWS security groups (tested in a lab AWS account) · experimental connectors for Check Point, Juniper SRX, SonicWall, WatchGuard, OPNsense, Cisco ASA, Meraki, MikroTik Wi-Fi, the Cisco Catalyst 9800 wireless controller, VMware NSX, Azure, Hyper-V, Proxmox and RADIUS Disconnect · a plan dialog that shows the action in full before it runs, a duration, the administrator’s password and a release for every action · one safety path with a kill switch, an hourly limit, per-action permissions and a record of what DENIS changed · block suggestions on the Alerts page and the device panel · the Respond menu shows where the device is and offers a port or firewall only when DENIS is sure it is on the path · UniFi through an API key and a firewall policy, Palo Alto through a dynamic address group (no commit, seconds) · rules can prepare a block for approval, or block automatically after a trial of at least 7 days (experimental) · a notification bell, and messages that name the device
Off by default. Verified integrations: see the supported infrastructure page. Every other connector is experimental and acts only after an administrator turns on two lab switches.
three automation levels: (a) a person decides every action, the default · (b) policies you mark may block or quarantine by themselves, always time-limited, never on DENIS itself, the gateway, OT devices or infrastructure · (c) Autopilot may block, a separate switch on top of (b) with its own conditions and limits · Autopilot: sorts alerts into the few that need you now and the many that can wait, explains each in plain language and asks one question at a time, in the console or on a phone through Telegram, ntfy or web push · starts in shadow mode, recording what it would have done
Off by default and experimental. Autopilot can miss real threats.
an optional PostgreSQL store alongside the default SQLite, with every store method ported · two nodes sharing one PostgreSQL database, with automatic failover tracked by a database lock · Experimental in 4.4, tested on PostgreSQL 16 in containers and in a local fault lab, not yet on a managed service · a write fence refuses writes from an old leader · a data key per customer, which you can rotate together with the master key while DENIS runs · customers can live in PostgreSQL (Experimental) · tenants on PostgreSQL are Experimental until measured
A default SQLite install has no second node, so it is never HA.
a Start page for the first minutes (4.4) · alerts and notices through a durable queue, so a receiver that is down, a restart or a failover no longer loses a message (4.4) · shipped lists that can update themselves, off by default (4.4) · licensing counts devices seen in the last 30 days (4.4) · what DENIS cannot see: blind spots, dropped and duplicated packets, silent VLANs (4.3) · duplicate packets from SPAN or TAP copies counted or removed (4.3) · capture sources grouped into separate networks, and hardware addresses marked as shared (4.3) · API tokens with scopes, expiry, rotation and an acts-as mode, and site administrators (4.3) · multi-site with outbound-only remote collectors · agents installed with one command (install.sh --agent, the Add agent dialog or Docker) and updated from the console: by hand by default, automatically, or through the master for sites without internet · per-user, per-site access · MSP overview · MSP remote management: an MSP opens a customer’s own DENIS at the level the customer chooses, with a banner, an activity list, co-approval, a one-click disconnect and a second factor for every operator · rules an MSP sends you, which you accept, trial or refuse (4.4) · single-use invitations for MSP customers and one-line enrolment of agents (4.4) · white-label branding · a choice of three console looks — Triage (the default), Scope and Clipboard — each in light and dark, picked per browser · data retention · signed self-update with automatic rollback, automatic for security updates of the minor line you run by default with an opt-out (stable releases only, pre-releases only if an administrator opts in; usedenis.com only if GitHub cannot be reached) · a search box in the built-in documentation · English, German, French, Spanish, Slovak, kept per account
Product tour
DENIS running its built-in demo network: a fictional company with an office, a production hall and a branch site. Shown in the default Triage look, in dark and light; Scope and Clipboard are the other two looks, and each browser picks its own.
The daily digest, twelve overview tiles, risk and severity breakdowns, Top exposures today, recent alerts, most at-risk devices and findings needing attention.
The device register: sort, group and filter by site, type, risk or review status; export or import CSV.
Asset details, why it is a priority, its findings and controls; the evidence behind the identification is one tab away.
Related alerts grouped into one incident with a single priority, a timeline, the devices involved and the findings on them, and Acknowledge or Resolve.
Work items with an owner and a due date on top, then the standing problems that stay until the cause is fixed, each with what to do.
How your network is cabled, from the internet down to the access points, with the devices behind each switch or access point in groups you can open. Zoom, search, drag, and draw a cable DENIS could not see; the layout saves itself.
Every switch, firewall, controller and cloud platform DENIS reads from or acts through, with its state, what DENIS may do with it, and how well that is tested.
Pick the product; DENIS asks only for what that product needs and recognises your gateway. Each card says what DENIS can do with it, and which products are tested only on simulators.
A guided path from discovery to a dry run: confirm the gateway, add equipment, settle which addresses are the same device and which cables DENIS is unsure about. Nothing is written to equipment before you press a button of its own.
Capture and mirror interfaces, the networks DENIS treats as your own, and active probing that each network can override.
The bell collects what needs a person: sites going offline, a capture interface that stopped, a connector that cannot be reached, changes to the hands-off list.
Industrial devices by Purdue level and zone, and every path’s reads, writes and control commands.
Which controls your current visibility supports, partially supports or does not address.
Blind spots and link quality, measured where possible and estimated where not: dropped packets, packets that arrive twice, silent VLANs, traffic seen in one direction only.
Devices on the network that none of your management, directory, scanning or endpoint tools reports. Tested against fixtures, not yet against a real tenant.
One history per device: addresses, switch port and VLAN, contacts, alerts, incidents, responses and changes, with how long each kind is kept.
Tell DENIS an alert is expected, for this rule on this device, this destination, or the whole device, for a time you choose. Industrial and high-severity alerts are never included in the widest choice.
What became of the alerts each rule raised: handled, marked normal, auto-closed, acted on, still open. Counted on your own system.
Every response in force, whoever created it: the action, the target, the equipment, the state DENIS last confirmed, and when it ends.
Give a capture interface its own network name when it sees another plant, so the same VLAN number or address there is a different network, not a conflict.
Tokens that reach only the areas you choose, read or change, with an expiry and an acts-as identity.
An administrator limited to some sites manages only those sites and does not see users, the audit log or installation settings.
Optional
Detection in DENIS is rule-based and explainable. An optional AI layer can help you read and act on what DENIS found. It never decides what gets alerted.
Each feature has its own switch. All are off by default.
When a cloud provider is configured, the alert or incident details needed for the request are sent to that provider. With a local model, they stay on your network.
Why DENIS
Discovery leans on listening. Active discovery is polite and optional, and industrial devices are never probed.
Every alert score is a sum of named reasons. Every device-type and OS guess lists its evidence. If DENIS is wrong, your correction wins.
DENIS runs on your hardware and keeps its data in one local database file. There is no DENIS cloud service and no telemetry.
Collector, detection, web console and documentation in a single program. No database server, no endpoint agents.
Laptops, printers, cameras, smart plugs and PLCs in one inventory and one alert stream, instead of a separate tool for each.
Know what exists, but also who talks to whom, how much, when, and what changed.
What DENIS is not. DENIS is an out-of-band visibility and monitoring layer. It is not a SIEM, an EDR, a firewall or UTM, or an inline blocking appliance, and it is not a vulnerability scanner. It observes and alerts. It does not block by itself unless you set it up to: the optional response actions are off by default and act through your own switches and firewalls. It complements those tools, and can feed your SIEM.