Security Answers Blog

During his recent presentation at the 2025 Security Technology Forum, David Brent connected two topics that don’t always get discussed together: cybersecurity and video evidence. His message was simple. IP video is not just about watching cameras. In many environments it becomes evidence, and that means the integrity of the video and the way it is handled matters. 

(Jump to Engineering Notes section)

David started by explaining why cyber risk feels like it has accelerated. He pointed to AI-assisted cybercrime and described how tools like WormGPT can be used to generate attack scripts quickly. In that environment, anything with an IP address on a network becomes a possible target. Cameras, access control devices, and other connected components are all part of the attack surface.

He used phishing as a practical example. Modern phishing attempts can look nearly identical to legitimate links and websites because attackers can create lookalike domains and use subtle character substitutions that most people will not detect. The result is that phishing is no longer easy to spot at a glance.

From there, David moved into the purpose of IP video. He described it as a deterrent, a tool for safety and security, an investigative resource for law enforcement, and ultimately evidence that may need to hold up in court. That last point led into the Federal Rules of Evidence and the requirement to show that video has not been tampered with. If video integrity can be questioned, admissibility can be questioned.

A major myth David challenged is the idea that watermarking always proves authenticity. He described how in many systems the watermark is added by the recorder after the stream is pulled, and he warned that certain checksum-based watermarking methods have been viewed as altering the original video. His takeaway was that organizations should understand exactly how integrity is being established and whether it can stand up under scrutiny.

He then described how Bosch cameras can support evidentiary integrity by generating a cryptographic hash for the video as it is produced, and embedding that hash with the recorded content. In his explanation, BVMS can authenticate video recorded via VRM using that camera-generated hash, either with certificates or without certificates.

David also focused on evidence collection. He emphasized that chain of custody and the method of export matter. If the collection process itself can be challenged, the evidence can be challenged. He described how some guidance still reads like it was written for “DVR-era” systems where officers might seize entire recorders, which becomes unrealistic in modern enterprise video environments with massive storage footprints. He also highlighted the risk that courts may require original evidence rather than convenient copies.

To address that reality, David pointed to features in BVMS and VRM that many users don’t realize they already have. He described BVMS “Protect Video,” which allows specific video to be preserved beyond normal retention so it won’t be overwritten. He also described placing iSCSI storage into read-only mode so original blocks can be preserved while operations continue on other storage. And he highlighted the VRM Export Wizard, which he said can export raw iSCSI data in its original format quickly, including metadata and authentication elements, enabling later forensic work.

David also discussed cryptographic and cybersecurity evolution inside the camera hardware. He described a transition from older crypto co-processors to secure elements in newer platforms, enabling capabilities such as TLS 1.3 and stronger certificate support in newer generations. He tied these changes to FIPS 140 requirements, describing a shift from compliance toward certified cryptographic modules in current generations.

He closed with forward-looking points. He described stealth mode as a deployment option that reduces exposed services and unnecessary ports, keeping the camera focused on secure communications. He also described upcoming capabilities to further reduce attack surface, including the ability to disable the camera’s web interface entirely after installation so it only communicates to the VMS over secure protocols. On the VMS side, he described BVMS end-to-end encryption by default and upcoming improvements such as support for loading an organization’s own certificates, and token-based authentication to reduce reliance on traditional camera user accounts.

The bottom line from David’s session was not that cybersecurity is scary, but that cybersecurity directly affects the reliability of IP video as evidence. The good news, he argued, is that many of the practical tools to improve integrity, preservation, and secure deployment already exist, and more are on the way.

Engineering Notes 

Threat framing (why hardening matters)

• AI-assisted cyber tools reduce the expertise required to generate exploits (David used WormGPT as an example).

• Any IP-addressed device on the network is part of the attack surface, including cameras and other security IoT endpoints.

• CVEs are tracked vulnerabilities scored by CVSS; David cited that by September there were over 36,000 new CVEs.

Evidence integrity (court-admissibility concept)

• David referenced Federal Rules of Evidence requirements to show video has not been tampered with.

• Collection method matters. If the export or chain-of-custody process can be questioned, admissibility can be questioned.

• “Watermarking” implemented at the recorder level after pulling streams can be challenged. Brent specifically warned that CRC-checksum watermarking approaches can be characterized as altering original content.

• Hashing is the integrity mechanism David emphasized. Change a file even slightly and the hash changes.

Camera-level evidentiary integrity (as described)

• Cameras include a cryptographic module (crypto co-processor); newer devices include a secure element.

• Cameras can generate a SHA-256 hash of produced video and embed it with video for later verification.

• BVMS can authenticate VRM-recorded video using the camera-generated hash, with or without certificates.

• Cameras can sign certificates and embed them into workflows if an organization chooses certificate-based validation.

Evidence preservation inside BVMS/VRM (features David highlighted)

• Protect Video: preserve selected video beyond normal retention so it is not overwritten.

• Read-only iSCSI mode: place an iSCSI device into read-only to preserve original evidentiary blocks while the rest of the system continues normal operation on other storage and/or replacement storage.

• VRM Export Wizard:

  • exports raw iSCSI data in original block format with headers

  • includes authentication hash and metadata

  • supports mass export (Brent example: 15 cameras for 3 days exported in 15 minutes)

  • preserves ability to perform IVA forensic searches later after re-import

  • supports export of encrypted video by importing the system backup key

Encryption and transport security (as described)

• VRM encrypted video is available without additional licensing (as David stated).

• BVMS provides end-to-end encryption by default since BVMS 10.0.

• System communications are forced to HTTPS/TLS 1.2 minimum (as Brent described).

FIPS and crypto hardware mapping (as described)

• FIPS 140-2: compliance-focused.

• FIPS 140-3: emphasizes certified cryptographic modules and protecting keys inside the module.

• Older devices: crypto co-processor, TLS 1.2, 2K certs.

• CPP13/CPP14: secure element, TLS 1.3 capability, 4K certs.

• CPP15/CPP16 and beyond: FIPS 140-3 certified secure element (Brent stated shift from compliant to certified).

OS, firmware, and platform protections (as described)

• Older generations used Bosch-developed RTOS; newer devices moved to embedded Linux with Bosch lockdown measures.

• Three-stage secure boot to prevent booting after tampering.

• Firmware is encrypted and signed.

• Firmware is tied to hardware platform signature (prevents loading the wrong platform firmware onto a device).

Hardening feature: Stealth Mode (what it does, per David)

• Turns off unnecessary ports.

• Disables ping response.

• Disables RCP+.

• Leaves HTTPS as the primary communication path (Brent referenced TLS 1.2 / 1.2+ behavior).

• Prevents certificate inspection via scan tools.

• Nessus scans become informational rather than vulnerability-heavy in his example.

Camera security features David called out (9.40-era items)

• TLS modernization, with “TLS 1.2 plus” referenced for new devices.

• Web login tracker inside the camera.

• Anti-clickjacking protection in the web interface to reduce certain web-based manipulation risks.

Attack-surface reduction coming next (9.60 items, per David)

• Ability to fully disable the camera web interface after install so it communicates only to the VMS over HTTPS/TLS.

• Elliptic curve certificate support from newer secure elements.

• SCEP support and a new UI to simplify enrollment.

• EST interface planned as the next evolution for certificate enrollment for 802.1X.

• A certificate manager tool (developed by Level 2 tech support in Germany) for mass CSR creation and certificate deployment.

• Built-in “login firewall” behavior: three failed login attempts in ~20 seconds triggers a 24-hour block for that source IP.

• Firmware strengthening against post-quantum attack approaches.

BVMS roadmap items Brent cited

• BVMS 13.1: ability to load organization-issued certificates into BVMS (replace self-signed certs to satisfy vulnerability analysis tools).

• BVMS 14: token-based authentication concept:

  • no user accounts in the camera

  • communication only via certificate/token signed by BVMS

  • intended to pair with stealth mode and web UI disabled

• Micro Certificate Authority capability (previously in Configuration Manager) planned to be integrated into BVMS for easier at-scale certificate creation/signing.

Certifications after Bosch → KEENFINITY (as described)

• IEC product certifications continued with the product.

• PSIRT: Bosch retained the existing PSIRT team; Keenfinity is establishing a new PSIRT team.

• CVE authority: Bosch retained prior MITRE status; Keenfinity is working toward becoming a new CVE signing/numbering authority again.

Contact our team or David Brent for assistance securing your system >>