Video ASM and vulnerability management
Vulnerability management assumes that you know what you have and that published vulnerability data describes it. For video estates both assumptions fail, and the second fails in a way that produces false comfort.
Vulnerability management is a mature discipline with good tooling. Applied to a video estate it meets two problems, of which only the first is widely understood. This document states both, states what this specification adds in consequence, and states the two cases where vulnerability management remains the better instrument.
Requirement keywords (SHALL, SHALL NOT, SHOULD, SHOULD NOT, MAY) are used throughout with the meanings fixed in the framework, clause "Normative language".
Problem one: the scanner has to know the device exists#
A vulnerability management programme operates on an asset list. Where the cameras are not on it, the programme is complete and silent about them simultaneously.
This is the ordinary scoping problem and it is solvable: add the ranges, add the credentials, run the scans. It is the easier of the two.
Three complications are worth stating. Credentialed scanning, which is what makes vulnerability management accurate for servers, generally does not work here, because most cameras offer no mechanism for it. Unauthenticated scanning of embedded devices carries a real risk of disruption: devices in this class have historically responded badly to aggressive port scanning and protocol fuzzing, and a scan that reboots a recorder during an incident is worse than no scan. And a scanner's fingerprinting of embedded devices is frequently wrong at the model level, which matters when the CVE mapping depends on it.
Scanning remains one input to the assess stage. It SHALL NOT be treated as the whole of it.
Problem two: the vulnerability data is structurally incomplete#
This is the problem that produces bad decisions, because it produces a clean report.
A vulnerability management programme's output is only as complete as the vulnerability database behind it. For mainstream server and application software, that database is a reasonable approximation of what is known. For video products it is not, for three reasons that have nothing to do with the products' actual quality.
- Many vendors do not assign CVEs. Publishing a security advisory and requesting a CVE identifier is a deliberate process a company has to invest in. Some video vendors run a mature product security function and publish consistently. Others publish advisories with no CVE. Others publish nothing, and fix issues silently in a firmware release whose notes say "improvements and bug fixes".
- CPE identifiers for these products are inconsistent. The mapping from "this device" to "this entry in the vulnerability database" runs through a CPE string, and for camera products those strings are irregular: the same vendor appears under multiple names, hardware and firmware are separate entries, and model naming follows no scheme. A scanner that fingerprints a device correctly can still fail to match it to the vulnerability, and a vendor can appear to have almost no vulnerabilities because their products are catalogued under a name nobody queried.
- Component vulnerabilities are rarely attributed to the device. Where a camera embeds a vulnerable third-party library, the CVE names the library. Unless the vendor issues its own advisory saying "our product contains this", no scanner will connect the two.
The consequence is normative: a low CVE count for a product is a statement about a vendor's disclosure practice and not about the product's soundness, and SHALL NOT be read as evidence that the product is sound. A programme that ranks vendors by CVE count will systematically favour the vendors who disclose least.
What this specification adds#
Given the above, published vulnerabilities are one of four independent assessment inputs rather than the assessment.
- Lifecycle position is often more decisive than any individual CVE. A product past end of support has no route to remediation for anything found in future, which is a permanent condition rather than an open finding.
- Configuration, including shared credentials, unnecessary services and unencrypted management, produces more real-world compromise in this asset class than published vulnerabilities do, and none of it appears in a CVE feed.
- Exposure, in both directions. Inbound reachability changes what a vulnerability means. Outbound cloud connectivity is a security-relevant property that no vulnerability scanner reports, because it is not a vulnerability.
- Ownership, which is not a security property at all until something has to be changed.
Where vulnerability management is the better instrument#
Two cases fall to vulnerability management rather than to this specification, and both matter.
For the VMS servers, which are Windows or Linux machines running video-management software, database engines and web services, conventional vulnerability management is exactly right, and often better than anything a video-specific programme would do. These are ordinary servers, and they SHOULD be scanned as ordinary servers.
For prioritisation signal quality, the vulnerability management world has built instruments the video world has not: exploitation catalogues, exploit-prediction scoring, and a shared vocabulary for severity. The prioritise stage adopts all of it rather than inventing an alternative.
Summary of the delimitation#
| Vulnerability management | Video ASM | |
|---|---|---|
| Input | An asset list you already have | The estate, discovered from physical and operational sources |
| Primary evidence | Published vulnerabilities | Vulnerabilities, lifecycle, configuration, exposure |
| Assumes | The vulnerability database describes your assets | It does not, and says so |
| Fails silently when | The asset is not in scope | Not applicable: the coverage gap is the reported output |
| Handles VMS servers | Well | Defers to vulnerability management |
| Handles cameras | Partially, with fingerprinting and coverage caveats | This is the scope |
A vulnerability management run over a camera estate that returns few findings has usually measured coverage rather than risk. Per-product vulnerability history, including which vendors publish and which do not, is catalogued on CameraRisk.