Video ASM and attack surface management

Attack surface management is the parent discipline. The difference is not method but scope: which assets a programme ends up holding, and why video assets usually are not among them.

Version

1.0

Status

Draft for comment

First published

5 September 2026

Revised

5 September 2026

Attack surface management is the parent discipline of this specification, which does not claim to improve on its method. The method is the same method: enumerate what exists, determine what is exposed, reduce it, repeat. This document states which assets an ASM programme ends up holding, why video assets tend not to be among them, and the conditions under which an existing programme already satisfies the scope defined here.

Requirement keywords (SHALL, SHALL NOT, SHOULD, SHOULD NOT, MAY) are used throughout with the meanings fixed in the framework, clause "Normative language".

Definitions of the neighbouring terms#

Three overlapping labels are in market use, and each is defined by its starting point.

EASM, external attack surface management, looks inward from the internet. It starts from domains, IP ranges and certificates, and asks what an unauthenticated outsider can see. It is discovery without prior knowledge, which is its strength: it finds things you did not know you had.

CAASM, cyber asset attack surface management, works from the inside out. It aggregates what existing systems already know, including the EDR console, the cloud provider, the CMDB and the identity provider, into one asset view, and finds the gaps between them.

ASM is used both as the umbrella term and, loosely, as a synonym for whichever of the two a given vendor sells.

Coverage of video assets by each#

EASM finds some of the estate, and reports it misleadingly. An internet-exposed camera or recorder is exactly the kind of thing external discovery is good at spotting. Most video estates are not internet-exposed in the inbound sense, and the parts that matter most, such as the recorder holding credentials for four hundred cameras and the VMS server on the corporate network, are invisible to it. The outbound cloud connectivity that most modern cameras maintain is not an external attack surface in the EASM sense at all, so a clean EASM result says very little about this asset class.

CAASM finds video assets only where something already knows about them. This is the decisive limitation. CAASM's value comes from correlating existing sources, and video devices are characteristically absent from all of them: they run no agent, they are not domain-joined, they are not in the CMDB, they were not procured through IT. A CAASM platform integrating six excellent data sources will produce a confident, complete-looking asset inventory with the camera estate missing, and nothing in the tool will indicate that anything is absent.

That outcome is a property of correlation-based discovery meeting a population that appears in none of its inputs, rather than a defect in any particular tool.

The differences, enumerated#

The differences are three, and none of them is methodological.

1. The discovery sources differ. For video estates, the richest sources are not the ones an ASM programme normally integrates: the VMS's own device list, PoE port status on the access switches, and the integrator's commissioning documentation. The framework's discover stage treats these as primary rather than supplementary, which is a genuine departure from how ASM discovery is usually configured.
2. Identification is unusually hard. In general IT, an agent or a credentialed scan gives manufacturer, model, OS and patch level reliably. Here, firmware version is inconsistently exposed, often requires authentication with credentials nobody holds, and is formatted differently across firmware branches of the same product. A programme that assumes identification is a solved problem will produce an inventory whose most important field is mostly empty.
3. Remediation is contractual. Patching a server is an internal decision. Patching a camera may require a third party under a maintenance agreement written before anyone thought about this, a technician on site, and acceptance of the risk that the device does not come back. Prioritisation that ignores this produces queues nobody works.

When this specification is not required#

This clause takes precedence over the differences enumerated above; a document that stated the differences and omitted this clause would be advertising.

A separate Video ASM programme is unnecessary where all of the following hold:

1. the ASM or CAASM programme ingests the VMS device list;
2. it resolves model and firmware version for the camera estate;
3. it assigns those devices an owner who can actually change them.

A programme meeting all three conditions is doing Video ASM, and the label adds nothing to it. The test to apply is the maturity model's evidence tests rather than the label: a programme that can pass them SHALL be treated as having settled the scope question.

The term is useful only where the answer to "does your asset inventory include the cameras" is no, or is unknown.

Summary of the delimitation#

Video ASM is a scoping instrument rather than a new discipline. Where an attack surface programme holds the cameras, the term is unnecessary. Most such programmes do not hold them.