The Video ASM framework
Six stages, each defined by the artefact it produces rather than the activity it describes. A stage you cannot evidence has not been done.
Frameworks fail in a predictable way. They describe activities — "discover your assets", "assess your risk" — which are impossible to fail, because any amount of effort counts as having done them. This one is organised around artefacts. Each stage names a specific thing that must exist afterwards. If the thing does not exist, the stage is not complete, however much work went into it.
The stages are ordered, but the programme is not a waterfall. Discovery never finishes. A real programme runs all six concurrently, at different rates, with the later stages operating on a subset of what the earlier ones have produced.
Discover#
Purpose: establish that a device exists and is reachable, before knowing anything else about it.
Discovery for video estates is unusual in one respect: several rich sources of truth already exist inside the organisation, and none of them is the security team's asset database.
Sources worth exhausting before running a single scan:
- The VMS itself. A video-management platform knows about every camera it records. This is usually the single most complete list in the building, and it is queryable — most platforms expose an API or at minimum a device-list export. It will not include devices nobody connected to the VMS, which is exactly the gap worth measuring.
- Switch infrastructure. PoE port status, MAC address tables and LLDP/CDP neighbours give you devices by physical port. For camera estates this is often better than a network scan, because it finds devices that are powered and cabled even when they are not answering on the network you scanned.
- DHCP leases and IPAM. Reservations for cameras are frequently static and documented, and the OUI in the MAC address identifies the manufacturer without touching the device.
- The integrator's commissioning documentation. Handover packs contain device schedules, IP plans and, uncomfortably often, credentials. Obtaining these is a contractual conversation, not a technical one.
- Active network discovery. ONVIF's WS-Discovery, mDNS, and targeted probes of the ports these devices are known to use. Run last, because it is the source most likely to be incomplete and most likely to disrupt something.
The artefact is not "we ran a scan".
Artefact — device register. Every device, with: IP address, MAC address, physical location or switch port, the source that found it, and the date it was last seen. Devices found by one source and not another are the interesting rows; the register must preserve which source found what.
Completion test: you can state how many video devices exist, and for any two discovery sources you can produce the set difference between them.
Identify#
Purpose: turn a reachable address into a known product with a known owner.
Identification is where most video estates stall, and the reason is mundane: the information is inconsistently exposed. A camera may report its model in an ONVIF device-information response, in an HTTP response header, in a web interface title, in an SNMP sysDescr, or nowhere at all. Firmware version is worse. Two devices of the same model, from the same purchase order, may report their version in different formats depending on which firmware branch they are on.
Four attributes matter, in descending order of how hard they are to obtain:
- Manufacturer — usually derivable from the MAC OUI alone, and rarely wrong.
- Model — usually obtainable, sometimes only from an authenticated interface.
- Firmware version — frequently requires authentication, and frequently requires per-vendor parsing to be comparable across devices.
- Owner — the human or team accountable for the device's configuration and patching. This is not a technical attribute and cannot be discovered from the network. It has to be assigned, and the assignment has to be recorded.
The fourth is the one programmes skip and the one that determines whether anything downstream happens.
Artefact — identified inventory. The device register, plus manufacturer, model, firmware version, and named accountable owner. Fields that could not be established are recorded as unknown, with the reason. An unknown that is visible is manageable; an unknown that has been silently defaulted is not.
Completion test: for every device you can name who would apply a firmware update to it, and you can produce the list of devices whose firmware version you do not know.
Assess#
Purpose: determine what is wrong with each device, and what about its configuration or position makes that worse.
Assessment has four independent inputs, and treating them as one number too early is the most common analytical mistake in this space.
Known vulnerabilities. Map model and firmware to published CVEs. This is harder than it sounds: CPE strings for camera products are inconsistent, many vendors do not assign CVEs at all, and a vendor's own advisory may describe an issue that never received a CVE identifier. The absence of published vulnerabilities for a product is not evidence that the product is sound — for several vendors it is evidence that they do not participate in the CVE system.
Lifecycle position. Whether the product is still supported, when support ends, and whether firmware is still being published for it. A supported device with three open vulnerabilities is usually a better position than an unsupported device with none, because the first has a route to remediation and the second does not.
Configuration. Default or shared credentials, unnecessary services left enabled, unencrypted management interfaces, authentication modes weaker than the device supports, and logging that goes nowhere.
Exposure. What can reach the device: the internet directly, the corporate network, a dedicated VLAN, or a genuinely isolated segment. And, in the other direction, what the device can reach — outbound connectivity to vendor cloud services is the part most often overlooked, because it survives every inbound firewall rule an organisation writes.
Artefact — findings by device. For each device: open vulnerabilities with source and date, lifecycle status with source, configuration deviations from a stated baseline, and observed network reachability in both directions.
Completion test: for any device you can produce its findings with a source and a date for each, and you can state which of the four inputs you have no data for.
Prioritise#
Purpose: decide which findings represent enough organisational risk to spend effort on.
An estate of several thousand cameras will produce more findings than any team can act on. The prioritisation problem is therefore the central one, and severity scores alone will not solve it — CVSS describes a vulnerability's characteristics, not your exposure to it.
Signals that change the ordering materially:
- Confirmed exploitation. A vulnerability listed in CISA's Known Exploited Vulnerabilities catalogue is being used against real organisations. This is categorically different evidence from a high severity score.
- Exploitation probability. EPSS gives a modelled probability of exploitation activity in the next 30 days. It is a forecast, not an observation, and should be read as one.
- Reachability. An unauthenticated remote-code-execution vulnerability on a device that is reachable only from an isolated VLAN with no outbound route is a different problem from the same vulnerability on a device with a port forward.
- Blast radius. What the device holds and what it can reach. A recorder holding months of footage and holding credentials for a hundred cameras is not equivalent to one camera.
- Remediability. Whether a fix exists at all. Findings with no available fix belong in a different queue — one about compensating controls or replacement, not patching.
Artefact — a ranked queue with stated reasoning. Not a score. A queue, ordered, where each item's position can be explained by reference to the signals above, and where items that were deprioritised are still visible.
Completion test: you can explain why item 40 is below item 39, and someone who disagrees can argue with the reasoning rather than the arithmetic.
Remediate#
Purpose: change something so the finding no longer applies.
Video estates constrain remediation in ways that general IT does not, and a framework that ignores this produces queues nobody works.
- Patching may require physical access. Some devices update only from a local interface, or require a technician on site with a laptop.
- Patching may void a maintenance contract, or fall outside the integrator's scope, or require the integrator to perform it at cost.
- Firmware updates carry real operational risk. A failed update on a camera at height is an expensive truck roll. A failed update on a recorder can lose retention.
- The estate may be evidentially significant. In regulated or law-enforcement contexts, changing a recording system's configuration has consequences beyond the technical.
- Some devices cannot be fixed. End-of-support products with no patch and no replacement budget are common, and pretending otherwise produces a queue full of permanently open items.
The realistic set of responses is wider than "patch":
Patch where a fix exists and can be applied. Reconfigure to remove the condition — turn off the unused service, replace the shared credential, enable the stronger authentication mode the device already supports. Isolate by moving the device to a segment that changes its reachability. Restrict by removing an outbound path or a port forward. Replace when the device is beyond support. Compensate with monitoring or network controls when nothing else is available — and record that this is what happened, rather than closing the finding.
Artefact — a change record per finding. What was done, when, by whom, and — where nothing was done — the accepted risk, its owner, and its review date.
Completion test: every closed finding has a change record, and every accepted risk has a named owner and a date on which it will be looked at again.
Monitor#
Purpose: detect that the picture has changed, without repeating the whole programme.
Four things change independently, and a monitoring design should say which of them it watches:
- The estate changes. New devices appear. Devices move. Devices are decommissioned physically but not logically, or the reverse.
- The devices change. Firmware is updated by someone else. Configuration drifts. A service that was disabled is re-enabled by a factory reset after a power event.
- The vulnerability picture changes. A new CVE affects a model you already hold. A vulnerability you deprioritised is added to KEV. A vendor publishes an advisory for a product you thought was unaffected.
- The exposure changes. A firewall rule is added for a project and never removed. A device acquires a route it did not have.
The third is the one that requires no action on your part to occur, and the one most likely to be missed by a programme built around periodic scanning.
Artefact — a change feed with a review cadence. Additions, removals and drift since the last review, new vulnerabilities affecting held models, and exposure changes — each with a date and a stated review interval.
Completion test: you can answer "what changed since last month" without re-running discovery from scratch.
Applying the framework partially#
Most organisations will not run all six stages at once, and should not try. The stages are ordered because each depends on the one before it: prioritisation over an inventory you know is incomplete produces a confident ranking of the wrong things.
The maturity model sets out what a defensible partial implementation looks like at each level, and what the next increment should be.