What Video Attack Surface Management is
Video Attack Surface Management is the continuous discovery, assessment and reduction of the cyber attack surface created by video-security infrastructure — cameras, recorders, management platforms, and the network and cloud services they depend on.
Purpose and scope of this document#
This document defines the term Video Attack Surface Management, fixes the boundary it draws, and states what a programme takes on by using it. It applies to enterprise and multi-site video estates.
It assumes a reader who already knows what a video estate is made of and why it is a security problem, and does not re-argue that here. Everything downstream of the definition — the stages, the artefact each one produces, the levels — is specified in the documents listed at the end.
The definition#
Video Attack Surface Management (Video ASM) is the continuous discovery, assessment and reduction of the cyber attack surface created by video-security infrastructure.
That surface includes the cameras themselves, the recorders and servers that store and index what they capture, the management software that operators use, the network paths that connect them, the remote-access mechanisms that make them usable from outside the building, and the third-party services the whole arrangement quietly depends on.
The word doing the most work in that sentence is continuous. A camera estate is not a static inventory. Devices are added by contractors during unrelated building work. Firmware is updated on some devices and not others. A vendor cloud service changes what it exposes. A site that was air-gapped acquires a route to the corporate network because someone needed to view a feed from a desk. None of these events generates a ticket.
Why "asset management" does not already cover it#
Every mature security programme claims to manage its assets. Most of them exclude this equipment without ever deciding to.
The exclusion is structural rather than negligent. Video systems are usually procured by a physical-security or facilities function, installed under a construction or maintenance contract, and commissioned by an integrator who leaves when the handover is signed. The budget line is capital, not IT. The support relationship is with the installer, not the manufacturer, and the credentials are often held by the installer as well. The result is a set of networked computers with an owner who does not think of themselves as operating computers, and a security team that does not know the devices exist. Neither party is behaving unreasonably. The gap is in how the estate was bought, not in anyone's competence.
Video ASM exists to name that gap so it can be assigned.
The boundary: what the term covers#
A Video ASM programme covers, at minimum:
- Cameras — fixed, PTZ, multi-sensor, thermal, and the increasingly capable edge analytics running on them.
- Recorders and storage — NVRs, DVRs, hybrid recorders, storage arrays dedicated to video, and the servers running recording services.
- Management platforms — VMS servers, client workstations, mobile clients, failover and archive nodes, and the database engines underneath them.
- Encoders and decoders — including the analogue-to-IP encoders that keep decades-old camera cabling in service.
- The access-control and intercom systems that share the same network segment, the same installer and frequently the same management platform.
- Remote access paths — vendor cloud relays, peer-to-peer services, port forwards, VPNs set up for the integrator, and the mobile applications that use them.
- Supporting services — the DNS, NTP, certificate, directory and licensing dependencies that determine whether the system keeps working and who can authenticate to it.
An item deliberately left out of a particular programme is an exclusion to be written down, not a gap to be discovered later.
The boundary: what the term does not cover#
The following sit outside it, and a Video ASM programme should not be cited as covering them.
Video quality and system health monitoring. Whether a camera is in focus, correctly aimed, recording at the expected frame rate, or has a failing disk is an operational concern with mature tooling and a different owner. Those tools do sometimes hold inventory data worth borrowing, which is covered in the framework's discovery stage — but health monitoring answers "is it working", and Video ASM answers "what can be done to it".
Physical-security design. Camera placement, coverage, lighting, retention policy and evidentiary handling are the discipline that video systems exist to serve. They are not this.
Privacy and lawful processing. The questions attached to surveillance are real, consequential and adjacent. They are not treated here, and this framework should not be cited as though it addressed them.
What adopting the term commits you to#
Using the term is a commitment rather than a label. A programme that describes itself as Video ASM should be able to show that it:
- holds a boundary at least as wide as the one above, with any exclusion recorded;
- treats discovery as continuing rather than finished — an inventory with a date on it and no process behind it does not meet this definition;
- can produce the artefact each stage of the framework names, or say plainly which one it cannot;
- can state the maturity level it is at by the model's own test, rather than asserting one.
The claim underneath that requirement is narrow. Video estates are large, long-lived, weakly inventoried, and connected. Each of those properties is individually manageable. Together they produce a class of asset that generic asset-management and vulnerability-management programmes reliably miss — not because the tools cannot see the devices, but because nobody has scoped them in. That is the entire claim. It does not require the devices to be uniquely insecure, and this framework deliberately avoids arguing that they are. Some are; many are ordinary embedded computers with ordinary embedded-computer problems. The distinguishing factor is ownership, not badness.
When you do not need this#
The boundary limits the claim in the other direction too. A single site with a handful of cameras on one recorder, administered by the person who administers everything else, does not need a stage model or a maturity level to know what it has. The definition still describes the surface; the programme machinery around it is for estates no one person can hold in their head, which is why this document is scoped to enterprise and multi-site estates. Adopting the term below that size adds process the estate has no use for.
Status of the term#
"Video ASM" is a working label, coined here to make the scope discussable. Attack surface management is an established category; applying it to a specific asset class is not a novel idea, and several vendors in the OT, IoT and cyber-physical security markets already discover camera estates as part of a broader product.
What does not exist, as far as we have been able to establish, is a published, citable framework specific to this asset class — one that states what the stages are, what each stage should produce, and how an organisation can tell which level it is actually at. That is the gap this document tries to fill. If prior art exists and we have missed it, we would rather correct the page than defend the coinage.
The rest of the specification#
- The framework — six stages, and the artefact each one is supposed to produce.
- The maturity model — six levels, each with a test you can fail.
- Camera attack surface — what is actually exposed, enumerated.
- Boundaries — where this stops and an existing discipline takes over.