Video ASM and VMS health monitoring
Every VMS ships health monitoring, and it holds the best device inventory in the building. It answers a different question, and the difference is worth stating precisely, because the two are routinely conflated in procurement.
This document exists because the confusion is common and expensive. An organisation with comprehensive VMS health monitoring frequently believes the video estate is monitored, and in one sense it is; the question that monitoring answers is not the security question.
Requirement keywords (SHALL, SHALL NOT, SHOULD, SHOULD NOT, MAY) are used throughout with the meanings fixed in the framework, clause "Normative language".
What health monitoring covers#
Every serious video-management platform includes system monitoring, and there is a category of third-party tooling that does it in more depth. Between them they cover:
- Whether each camera is online and recording
- Whether the video signal is present, and whether the image has changed unexpectedly: a camera that has been moved, defocused, obscured or spray-painted
- Recording integrity and retention: whether footage exists for the period it should
- Storage health, disk failures, array status
- Server and service availability, failover status, licence state
- Frame rate, bitrate and stream errors
- Certificate and time synchronisation state, on some platforms
This is genuinely valuable and often better instrumented than anything in the security estate. Camera-verification tooling in particular solves a real problem: a camera that has silently stopped producing usable footage is an operational failure that only shows up when someone needs the footage.
What health monitoring does not cover#
Health monitoring is built around availability and quality. It does not establish:
- What firmware each device is running, and whether that firmware has published vulnerabilities
- Whether the device is using default or shared credentials
- Which network services the device is exposing
- Whether the device is reachable from networks it should not be reachable from
- Whether it maintains an outbound connection to a vendor cloud service
- Whether the product is still supported by its manufacturer
- Who is accountable for changing any of the above
A camera can be healthy by every monitoring metric, including online, recording, in focus and at the correct frame rate, while running four-year-old firmware with a publicly exploited vulnerability, reachable from the office network, with the same administrative password as every other camera on the site.
The monitoring is accurate within its scope: it answers "is it working", and the answer is yes.
Using the VMS inventory#
The VMS is the single best inventory source in most organisations, and a Video ASM programme SHOULD take it as the first source in the discover stage, ahead of a network scan.
What it typically holds: every camera it records from, with IP address, manufacturer and model, frequently firmware version, the recording server each device is attached to, and often the physical location as a human-readable name. This is most of the identify stage already assembled, by a system that has been maintaining it accurately because the operation depends on it.
Two caveats apply.
- It holds only devices connected to the VMS. Cameras on a standalone recorder, cameras commissioned and never added, and devices from a decommissioned system still powered on do not appear. The difference between the VMS list and an independent source, usually switch PoE status, is the interesting number, and the discover stage makes producing that difference its conformance test.
- Its firmware field may be stale. Some platforms record the version seen at commissioning rather than the current one.
The procurement confusion#
This document sits in the specification rather than in a footnote because of a usage problem. The sentence "we monitor our video system" ends security conversations, and its two meanings are not distinguished in most organisations.
A useful test in a procurement or audit conversation is to put a security question to the health-monitoring tool: which of our cameras are running firmware with a known vulnerability? Where the tool cannot answer, the estate is monitored for availability and unmonitored for security, and both facts are true at once.
| VMS health monitoring | Video ASM | |
|---|---|---|
| Question | Is it working, and is the footage usable? | What can be done to it, and by whom? |
| Owner | Physical security or operations | Security, with physical security |
| Alerts on | Offline, signal loss, storage failure, tamper | New device, firmware drift, new vulnerability, exposure change |
| Knows firmware | Sometimes, sometimes stale | Must, or records the gap |
| Knows credentials posture | No | Yes |
| Coverage | Devices attached to the VMS | The estate, including what the VMS does not see |
| Useful to the other | Its inventory is the best starting point | Finds the devices the VMS never knew about |
The two are complements. A security programme SHOULD consume the VMS inventory rather than rebuild it, and SHALL NOT treat the presence of health monitoring as security coverage.