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.
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 this is not just "asset management"#
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. 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.
What is in scope#
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.
What is out of scope#
Two exclusions matter, because a framework that claims everything explains nothing.
Video ASM is not video quality or 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".
Video ASM is not 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.
The privacy and lawful-processing 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.
The claim this framework makes#
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.
On the term itself#
"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.
Next#
- 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.