The Video ASM framework
Six stages, each specified by the artefact it produces rather than the activity it names. A stage that cannot be evidenced is not complete.
Normative language#
This document specifies the stages of a Video Attack Surface Management programme. The requirement keywords below carry a fixed meaning wherever they appear in it.
- SHALL and SHALL NOT state requirements. A programme that does not meet them does not conform to this framework.
- SHOULD and SHOULD NOT state recommendations. A programme MAY depart from them and still conform, provided the departure and its reason are recorded.
- MAY states an option. Neither choice affects conformance.
Each stage clause specifies three things: the objective of the stage, the artefact the stage produces, and the conformance test that decides whether the stage has been completed. The artefact is the unit of completion. A stage SHALL be treated as incomplete until its artefact exists and can be produced on request, whatever quantity of work has been done under the stage's name. Activity descriptions of the form "discover your assets" or "assess your risk", and activity reports of the form "we ran a scan", are not conformance criteria, because no amount of effort against them can fail.
The six stages are ordered by dependency and not by schedule. A programme MAY run all six concurrently and at different rates, with the later stages operating on a subset of what the earlier ones have produced. Discovery does not terminate.
Discover#
Objective. Establish that a device exists and is reachable, in advance of any other attribute of it.
Several rich sources of truth about a video estate already exist inside the organisation, and none of them is the security team's asset database. A programme SHALL draw on more than one source, and SHOULD exhaust the following before treating active discovery as authoritative:
- The VMS. A video-management platform holds a record of every camera it records from. 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 does not include devices nobody connected to the VMS, which is the gap this stage exists to measure.
- Switch infrastructure. PoE port status, MAC address tables and LLDP/CDP neighbours give 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 that was scanned.
- DHCP leases and IPAM. Reservations for cameras are frequently static and documented, and the OUI in the MAC address identifies the manufacturer without the device being touched.
- The integrator's commissioning documentation. Handover packs contain device schedules, IP plans and, uncomfortably often, credentials. Obtaining them is a contractual exercise rather than a technical one.
- Active network discovery. ONVIF's WS-Discovery, mDNS, and targeted probes of the ports these devices are known to use. This source SHOULD be taken last: it is the one most likely to be incomplete and the one most likely to disrupt something.
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. The register SHALL preserve which source found which device. Devices found by one source and not another are the rows this stage exists to produce.
Conformance test. The programme can state how many video devices exist, and for any two discovery sources it can produce the set difference between them.
Identify#
Objective. Resolve a reachable address into a known product with a named owner.
Identification is the stage at which most video estates stall, for a mundane reason: 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 are in scope, in ascending 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 before it is comparable across devices.
- Owner. The human or team accountable for the device's configuration and patching. This attribute is not technical and cannot be discovered from the network. It SHALL be assigned, and the assignment SHALL be recorded.
The fourth attribute is the one programmes skip and the one that determines whether anything downstream of this stage happens.
Artefact: identified inventory. The device register, plus manufacturer, model, firmware version and named accountable owner. A field that could not be established SHALL be recorded as unknown, with the reason, and SHALL NOT be inferred or left blank. An unknown that is visible is manageable; an unknown that has been silently defaulted is not.
Conformance test. For every device the programme can name who would apply a firmware update to it, and it can produce the list of devices whose firmware version is not known.
Assess#
Objective. Determine what is wrong with each device, and what about its configuration or position makes that worse.
This stage has four independent inputs. They SHALL be recorded separately, and a programme SHALL NOT combine them into a single number before the prioritise stage: doing so 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. A programme SHALL NOT treat the absence of published vulnerabilities for a product as 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, in both directions. What can reach the device: the internet directly, the corporate network, a dedicated VLAN, or a genuinely isolated segment. And 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.
Conformance test. For any device the programme can produce its findings with a source and a date for each, and it can state which of the four inputs it holds no data for.
Prioritise#
Objective. 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, which makes this the central clause of the framework. Severity scores do not discharge it: CVSS describes a vulnerability's characteristics, and not a given estate's exposure to that vulnerability.
An ordering SHALL account for the following signals, and SHALL record which of them were unavailable:
- 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 rather than an observation, and SHALL be read as one.
- Reachability. An unauthenticated remote-code-execution vulnerability on a device 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 credentials for a hundred cameras is not equivalent to one camera.
- Remediability. Whether a fix exists at all. Findings with no available fix SHALL be held in a separate queue, governed by compensating controls or replacement rather than by patching.
Artefact: a ranked queue with stated reasoning. An ordered queue, not a score. Each item's position is explicable by reference to the signals in this clause, and items that were deprioritised remain visible.
Conformance test. The programme can explain why item 40 is below item 39, and a reader who disagrees can argue with the reasoning rather than with the arithmetic.
Remediate#
Objective. Change something so that the finding no longer applies.
Video estates constrain remediation in ways that general IT does not. A programme SHALL account for the following constraints, because a queue that ignores them is a queue 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, 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 recording them as ordinary open findings produces a queue full of permanently open items.
The permitted responses are 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 where the device is beyond support.
- Compensate with monitoring or network controls where nothing else is available. A compensating control SHALL be recorded as such, and SHALL NOT close the finding.
Artefact: a change record per finding. What was done, when and by whom. Where nothing was done: the accepted risk, its owner, and its review date.
Conformance 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#
Objective. Detect that the picture has changed, without repeating the whole programme.
Four things change independently. A monitoring design SHALL state 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 already held. A vulnerability that was deprioritised is added to KEV. A vendor publishes an advisory for a product thought to be unaffected.
- The exposure changes. A firewall rule is added for a project and never removed. A device acquires a route it did not have.
Item 3 requires no action by the programme in order to occur, and is the class most likely to be missed by a design 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.
Conformance test. The programme can answer "what changed since last month" without re-running discovery from scratch.
Partial conformance#
Most organisations will not run all six stages at once, and SHOULD NOT attempt to. The stages are ordered because each depends on the one before it: prioritisation over an inventory known to be incomplete produces a confident ranking of the wrong things.
A programme running a subset SHALL state which stages it operates and which artefacts it holds. The maturity model specifies what a defensible partial implementation looks like at each level, and what the next increment costs.