Perseus Products
Limited release
NetOps
Proactive vulnerability monitoring for automation and control estates. NetOps is in limited release: it is in final testing, with proof-of-concept deployments at organisations running large-scale estates, and we make it available to selected organisations. Built for system integrators and maintenance providers who want to offer SOC services to the plants they know, and for large SOCs that want to see exposure before an incident. Multi-tenant by design, and it works for air-gapped estates: the import modules carry everything the engine needs, without network reach.
From inventory to exposure, per site
Overview
NetOps holds the estate: tenants, entities, sites, systems under consideration, zones and conduits, and the devices inside them. For every device it keeps the operating system, installed software, installed patches and, for industrial products, the vendor, order number and firmware version. That inventory is what the Vulnerability Core Engine assesses.
Inventory can arrive three ways: a remote collector at the site that only ever talks outbound, central probing where the network allows it, or an import. The import path is the one that matters for air-gapped plants: a document produced on the isolated network carries the host and device inventory across, and NetOps assesses it exactly as it would a connected estate.
Estate model
Tenants, entities, sites, systems under consideration, zones and conduits, and the devices inside them.
Import modules
Host and device inventories from isolated networks: operating system, software, patches and product versions.
Remote collector
An outbound-only agent packaged for Debian-based hosts; it leases jobs and returns results, and nothing reaches in.
Engine-backed findings
Every device's findings come from the Vulnerability Core Engine through its API: scores, exploited-in-the-wild flags, vendor statements and fixes.
Every NetOps finding comes from the Perseus Vulnerability Core Engine, which NetOps consumes through its API. This is what the engine holds.
vulnerabilities in the corpus
exploit and proof-of-concept records
affected products
vendors
Capabilities
What is in the current release
Status is stated honestly: features marked as not yet shown are in the release but not yet captured in a demonstration.
Device inventory and estate tree
Devices with types, tags, interfaces and addresses, organised by entity, site and system under consideration.
Offline inventory and estate import
Import a host inventory produced on an isolated network, or a whole estate document with sites, zones, conduits, links and devices. The air-gapped path.
Remote collector
Outbound-only agent with per-collector keys and sealed credentials; it leases jobs, executes them at the site and returns results.
Per-device vulnerability assessment
Findings with scores from every scoring party, exploited-in-the-wild flags, exploit probability, remediation actions and vendor statements, from the engine's API.
Vulnerability explorer
Search the engine's corpus by vendor and product with indexed product identities, and open a detail drawer with attack path, remediation guidance and vendor statements.
Fleet master plan
Fix once, resolve many: the engine's fleet assessment ranks the single actions that clear the most findings across the estate.
OT posture by site
Product-family exposure per site for industrial products the engine knows at family level, with the unmatched shown as unmatched, never as clean.
VEX export per device
Export a device's assessment as OpenVEX or CycloneDX VEX, with every vendor statement the engine holds for its findings.
Order-number matching
Industrial devices are matched by vendor order number and firmware version, the identity plant engineers actually record.
Incomplete-scan surfacing
When an assessment is capped, the device says so. A capped device is never counted as clean.
Change-feed reactions
Exploited-in-the-wild listings and delistings, vendor withdrawals and product-scoped changes trigger targeted re-assessment and land in the event log.
Alert rules
Threshold, reachability, backup, exploited-in-the-wild and site-exposure rules with derived severities.
Command view
A SOC wall: exposure levels per site and zone, a map of sites clustered by level, an intelligence ticker and a maintenance planner that turns exposure into work orders.
Zones, conduits and topology
IEC 62443 zone and conduit model with a Purdue-style diagram, undeclared crossings highlighted, and a routed layer-3 view.
Certificates, subnets and backups
Certificate inventory with expiry sweeps, subnet and address utilisation, and configuration backups with change detection.
Reachability and resource monitoring
ICMP, SNMP, WMI, SSH and vendor-API probes into a time-series store, with a per-device kill switch for assets that must never be probed.
The import path
What an offline import carries
The import document is produced on the isolated network and moved across by whatever means the site allows. This is what it contains, and therefore what the engine can assess without any network reach.
| Section | What it carries | What it enables |
|---|---|---|
| Host operating system | Type, edition, version, build, architecture, install date | Patch-state-aware matching of operating-system vulnerabilities |
| Installed software | Name, version, publisher | Application findings with fixes and upgrade paths |
| Installed patches | Hotfix identifiers | Suppression of findings the installed build already fixes |
| Services and interfaces | Service state and start mode; addresses, MAC, speed, status | Context for exposure and reachability |
| Industrial devices | Vendor, model or order number, firmware version | Order-number matching and product-family posture |
| Estate structure | Entities, sites, zones, conduits, systems under consideration, links | Exposure per site and zone; undeclared crossings |
The host inventory document and the estate import document, as used in the sample estate.
Inventory in, exposure out
How it works
- 1
Collect or import
A collector at the site, central probing, or an import document from an isolated network.
- 2
Model the estate
Entities, sites, zones, conduits and systems under consideration hold the devices.
- 3
Assess
Each device's inventory goes to the Vulnerability Core Engine through its API and comes back as findings.
- 4
Watch the feed
Exploited-in-the-wild listings, withdrawals and product-scoped changes trigger targeted re-assessment.
- 5
Prioritise
Fleet master plan, exposure levels per site and a maintenance planner turn findings into work.
- 6
Report
Alerts, VEX exports and posture views for the plant, the SOC and the customer.
Showcase
On a sample estate
A sample estate: three tenants and more than two thousand devices, every one assessed through the Vulnerability Core Engine. Device vendors and product families are real, because the findings are real engine answers for those products; sites, hosts and addresses are made up. Nothing on this page takes input.
Command view: a distribution utility, 300 substations
The SOC wall for the largest sample tenant: 2,100 devices across 300 substations in three divisions, every site clustered by exposure level on the map, the live intelligence ticker, the top maintenance actions with the sites each one clears, and the consolidation meter showing how many engine calls the baseline cache saved.
Sample data
Command view: a SOC provider watching air-gapped plants
The same wall for the SOC-provider tenant: three isolated plants on two continents whose inventories arrived by offline import. Ninety-nine devices, all assessed, with newly applicable vulnerabilities surfacing in the ticker as the engine's corpus moves.
Sample data
Monitoring is disabled for this device. NetOps asks for its operating system, packages and updates, by hand or from a file.
The import moment, on one workstation
An engineering workstation in a refinery control room that nothing has ever probed. The offline inventory document is uploaded on its device page; NetOps records the operating system, updates and software, and the engine's assessment fills the Vulnerabilities tab. Step through the four screens; each one enlarges in place.
Sample data
- 5Critical
An exploited-in-the-wild finding on a control device or inside a zone with a security-level target of 2 or more, or a network-reachable exploited-in-the-wild finding that has a public exploit.
- 4High
Any other exploited-in-the-wild finding, or a network-reachable critical finding with a public exploit.
- 3Elevated
A critical finding, or a network-reachable high finding whose exploit probability is not negligible.
- 2Guarded
A high finding.
- 1Low
Assessed devices with only lower findings, or none.
- 0Unknown
No assessed device at the site. Never shown as clean.
Levels are decided per site, zone and entity from the engine's active findings on the devices there, and the driver that set the level is named next to the badge. Sites on the same level are ordered by a weighted score, and every level-5 site raises an alert.
The alarm scale behind the Command view
Six exposure levels, decided per site, zone and entity from the engine's active findings. The rule is deliberately conservative: a site with no assessed device is unknown, not clean, and the finding that set the level is named next to the badge.
Maintenance planner
Ranked updates by what each one clears across every site and device that carries it: one operating-system build, one browser package, one controller firmware. Rankings come from the engine's assessment of the inventory, with findings and exploited-in-the-wild counts per action.
Sample data
OT posture by site and vendor
Advisory exposure for the industrial products at each site: product-family counts from the engine's shared corpus, by sector and vendor, with the honest note that these are exposures for the product families, not host-confirmed findings.
Sample data
Zones and conduits with reconciliation findings
Every device zoned, every observed crossing checked against the declared conduits, and each unmanaged path listed with its evidence. Security-level targets shown as not assessed until someone assesses them.
Sample data
Every device with a position, live
The distribution utility's 2,100 devices across 300 positions, clustered at this zoom, with layers for reachability, alerts, vulnerabilities and exposure. Devices whose last check is missing are shown as unknown, never as online.
Sample data
Network topology
Physical links discovered over neighbour protocols and MAC tables, drawn per network, with pending and manual links marked and unknown neighbours shown as such. Subnet and routed views sit on the same page.
Sample data
Device inventory and estate tree
Devices grouped by entity, industrial system and system under consideration, with type, addresses, reachability, status and patch level. Devices that must never be probed simply are not.
Sample data
One controller order number with its firmware version returned 568 findings, all matched by order number at confidence 0.9. One device's VEX export carried 1,119 vendor statements and took six seconds. One feed tick drained 7,116 vendor withdrawal events in under seven seconds. An explorer query by product identity answered in 0.27 seconds.
Measured against the production engine
Probes run by NetOps against the live engine API.
A script writes one document per host
Here an engineering workstation, Dell Precision workstation, never probed by anything. The file crosses the air gap by whatever means the site allows.
Produced by an inventory script run on the host.
Operating system
Microsoft Windows 10 Enterprise LTSC 2019, build 10.0.17763.3650, 64-bit
enables patch-state-aware matching of operating-system vulnerabilities
Installed software
12 entries with versions, for example Mozilla Firefox ESR 115.10.0
enables application findings with fixes and upgrade paths
Installed patches
5 hotfix identifiers
enables suppression of findings the installed build already fixes
Services and interfaces
4 services, 2 interfaces
enables context for exposure and reachability
The inventory is assessed through the engine
The device keeps its "monitoring disabled" state and gains a software list, a patch level and a Vulnerabilities tab: findings with scores, exploited-in-the-wild flags, fixes and vendor statements. A capped assessment says so on the device; it is never counted as clean.
The workstation is a sample; the software names are real, because those are what get assessed.
How an offline import becomes findings
The air-gapped path, step by step, on one workstation's inventory document: what the site produces, what NetOps reads from it, and what the device page gains once the engine has assessed it. The captured screens follow.
Sample data
One Debian package
It carries its own runtime and every protocol library, so the host needs no interpreter, no container runtime and no network access at install time. An air-gapped site is a normal install, not a special case.
The technician enters the NetOps address and the collector's key once; the collector enrols.
- Hello: the collector introduces itself and receives its poll intervals.
- Heartbeat: about every thirty seconds; a silent collector is shown offline, not assumed healthy.
- Lease: it asks for jobs; the lease is the only channel that carries credentials.
- Result: it posts results back, and each result acknowledges its job.
- · SNMP, WMI and firewall-API metrics
- · Configuration backups
- · Software inventory
- · Device enrichment over SNMP, SSH, Telnet and WMI
- · LLDP and CDP topology
- · Live TLS certificate probes
NetOps keeps all configuration and credentials centrally; the collector holds none at rest. Credentials travel only inside a leased job, sealed to the collector's own key, and the collector's identity survives upgrades and reinstalls so sealed jobs keep opening. A built-in doctor command prints the key fingerprint a site can check against the console.
How the remote collector works
Where the network allows it, a collector inside the site does the device work: one package to install, outbound connections only, jobs leased from NetOps and results posted back. Credentials never rest on the collector.
Collectors online at three air-gapped plants
The SOC provider's collectors page: one collector per plant, each online with its agent version and last heartbeat, and actions to review jobs, rotate the key, pause or revoke. Collector keys are masked.
Sample data
Questions we are asked
FAQ
Not on general release. NetOps is in final testing, with proof-of-concept deployments at organisations running large-scale estates. We are opening it to selected integrators, maintenance providers and SOCs whose estates fit the current release. Tell us about yours and we will say whether it fits now.
Join the limited release
Tell us about the plants you maintain or monitor and how inventory reaches you. If your estate fits the current release, we will take you through the estate model and the import path.