Advanced cybersecurity for video management software (VMS) (2024)

In our “fundamentals” article, we talked about disabling factory settings (including default passwords) on your security cameras. In the next guide, we explained how to use your VMS to automatically generate strong, unique passwords for each camera. Even if no one knows the password because it’s been generated by your VMS, it’s still important to regularly update passwords—at least once or twice per year.

Why? Because automated tools used for brute force attacks often work over extended periods. Frequent password updates can disrupt these automated processes, requiring the attacker to start over and reducing the chances of success.

Thankfully, it doesn’t take a lot of work to update passwords. Any decent VMS will let you do that in bulk. In the case of XProtect, you can do so by selecting all cameras connected to a specific recording server:

1. Open the Management Client.
2. Under “Servers” in the left-hand menu, click “Recording Servers”.
3. Right-click on the name of the specific recording server.
4. Click “Change Hardware Password” and follow the on-screen instructions.

In our “beyond the basics” guide, we explained why managed switches are vital to your cyber arsenal. So, assuming that this prerequisite is in place, it’s time to enable port security. Let’s look at two ways to do so and discuss why it’s a good idea to use them together.

• IEEE 802.1X is an example of port-based network access control (PNAC); a type of security protocol used to restrict network access to only authorized devices. In the context of video security, it can be used to authenticate devices (such as cameras) that are connected to a switch.

On the switch’s management interface, you can configure a port to only work with a specific camera. That way, if someone comes along and tries to connect a hacking tool to the switch, the switch will say “I don’t know you” and then shut down that port so that they can’t gain access to the network. You can also generate events based on failed authentication attempts that then trigger alarms.

• MACsec is a security protocol that encrypts the data on the wire that runs between the camera and the switch, securing Ethernet frames exchanged between network devices. As with IEEE 802.1X, it can be configured on the switch’s interface. MACsec prevents wire snooping, which is the physical interception and illicit monitoring or data using a clamp or test wires.

• Why use both? IEEE 802.1X is not strictly a prerequisite for MACsec. That said, it can enhance the security of MACsec by providing dynamic key management and authentication. Together, these form a strong defense—especially when it comes to cameras installed in public or semi-public areas where there is a heightened risk of tampering.

If you read our fundamentals guide, you might be wondering how HTTPS encryption comes into play. IEEE 802.1X and MACsec both operate at the data-link layer (Layer 2) in the OSI model (and they each do distinct jobs within this layer). HTTPS operates at the application layer (Layer 7). All three are complementary. HTTPS fulfills the need for security personnel to have safe, remote access to the VMS interface and video feeds via the internet. Moreover, HTTPS encrypts 1) the data exchanged between the VMS client (user interface) and 2) the video streams transmitted from security cameras to recording servers or management systems.

• What are the requirements? To use IEEE 802.1X and/or MACsec, the cameras and network equipment you plan on using need to support the respective standards. When it comes to triggering VMS events based on failed authentication or wire snooping attempts, you might need to leverage external systems and some custom configurations. Taking XProtect as an example, events can be received via its Event Server. To send events from the Syslog server or NMS to XProtect, you can use the XProtect Event Server API.

To monitor and react to events and threats on the network, a security information and event management (SIEM) product is needed. This provides real-time or near real-time analysis of events and alerts from your managed network equipment including firewalls, virus scanners, Windows OS, Syslog sources, etc. It provides you with a centralized interface to view the status of your network as well as define alarms and notifications on events and alerts of interest. Furthermore, a SIEM gives you access to investigating past events via centralized logs.

If you work in IT, you already know that a SIEM product helps secure your entire IT infrastructure, not “just” your video management system. Still, it’s worth mentioning that your SIEM shouldn’t only be applied to cameras and the ports they’re connected to. It should be applied holistically. We can’t recommend any single product as there are so many options on the market, but a couple of examples are Splunk Enterprise Security and Microsoft Sentinel.

Certificates encrypt the communication between your VMS servers and clients. A VMS can technically function without applying certificates. However, postponing this step comes with security and operational drawbacks.

• Self-signed certificates are something that you create as opposed to something from a CA. A self-signed certificate is not trusted by default; you need to “tell” your computers to trust it because they don’t automatically know who the issuer is.

• Why not just always use CA certificates if self-signed certificates require more work? One reason is that self-signed certificates are free. They save organizations a lot of money, especially in large-scale deployments that require a whole lot of certificates.

Another major reason has to do with how certificates are validated. CAs like the DigiCert Root Certificate Authority need to validate and verify every computer running the certificate. The problem is that they can’t validate computers inside a local area network (LAN) if it’s isolated from the internet, because validation is only possible with devices that are connected to the internet. In this scenario, a common solution is to use self-signed certificates.

• How can you create self-signed certificates? The exact steps depend on your specific installation. For XProtect customers, we have a long-form guide to certificates, including examples and scripts. The highlights of what you need to do are:

1. 1. Create a CA certificate.
   2. Use the CA certificate as the root to create dedicated certificates for each VMS server.
   3. Trust the CA certificate on all computers used for thick and/or thin VMS clients. For XProtect, “thick” clients are the Smart Client and Management Client, and “thin” refers to the Web Client and any third-party integration involving a web interface.

• Are self-signed certificates feasible for smartphones? It’s difficult to use self-signed certificates for XProtect Mobile, as both Android and iOS require manually installing the certificates on each phone. The process is intentionally cumbersome, as the manufacturers don’t want customers using self-signed certificates and display strong warnings against it. Why?

It’s not because self-signed certificates don’t offer robust encryption. Instead, it has to do with the CA certificates being a safer bet, as they’re a known and trusted issuer. Apple and Google are playing it safe to protect their users, which is understandable. It’s not impossible to get the certificates to work, but this factor might make you consider a hybrid implementation of certificates where CA certificates are used for smartphones and self-signed are used for the rest of your setup.

• Once you have the certificates, how do you enable them in the VMS? In the case of XProtect, applying certificates is usually done in the configuration rather than the installation phase. Assuming your servers are already installed, you can:

1. Right-click the XProtect server’s tray icon.
2. Click “Server Configurator”.
3. Enable encryption in each category and select a certificate in each field.
4. Click “Apply”.

• How can you tell if a certificate is self-signed or from a CA? If you look at the details of a certificate, the history won’t be very long for a self-signed certificate. In addition, there won’t be any centrally trusted source listed. In the below side-by-side view, the certificate on the left is self-signed and the one on the right is from a CA.

• How often should you update certificates? You specify how long certificates are valid for when you create them. The certificates created using the scripts in the XProtect Certificate Guide are valid for one year, as that’s our recommended limit. Windows, XProtect clients, browsers and smartphones won’t warn you if a certificate is nearing expiration, so you need to choose another way to initiate alerts. Certificates generated by a domain can be set up to be automatically renewed, and this brings us to a couple of alternatives to self-signed certificates for isolated networks.

• Is there a way to avoid self-signed certificates? Adding your computers to an Active Directory that trusts the PKI (private key infrastructure) in the domain can also encrypt communication. Yet another way to go is installing your own PKI and trusting that.

• How can operators know they’re on a secure connection? In XProtect, both the Smart Client and Web Client will show a “Not secure” message if encryption is not enabled on the VMS. When this changes for the Smart Client, the message will disappear (i.e., no news is good news). For the Web Client, the “Not secure” message will be replaced by either a padlock icon or similar.

Digitally signing recordings means that you and any independent authorities (e.g., law enforcement) can prove that video files have not been tampered with. The information for the signature isn’t embedded in the images, as doing so would inadvertently tamper with the images. Signatures don’t interfere with/re-encode the video itself. Instead, signatures “lie” beside the media database. Keep in mind that applying signatures doesn’t impact CPU load or recording performance; the difference is negligible. These factors apply to both server-side and client-side signatures:

• On the server level, through the Management Client (available in XProtect Expert and XProtect Corporate):

• In the Smart Client when you export a video (available with all XProtect variants):

Only new recordings will be signed from the time that signing is turned on. Any signed footage that’s archived will keep its signatures.

• How can you tell if a recording has been tampered with? The signatures won’t match up anymore. Signatures work a bit like a blockchain. All the files that the database contains on your disc are linked together with signatures referencing the previous database and the next database and so on, so it will flag if anything on the video has been changed.

In XProtect, you can go to a recording and click the “Verify signatures” button. If everything is in order, it will look like this:

The below image shows an example of how different users connect to various components of your VMS:

• On-site operators on the client network have access to the internet via a router and firewall.
• Roaming operators might need access to security footage on the go, meaning they’d need to connect to your VMS through the Web Client or Mobile Client. In this case, you would install a mobile server and allow roaming operators to view live and recorded video, remotely control cameras, etc. via these two clients.
• Remote operators who need access to “thick” clients (e.g., XProtect's Smart Client and Management Client) need to use a VPN to ensure a safe connection.

• Why not just use port forwarding for remote access? Port forwarding (a.k.a. “port-41ing") exposes a lot of resources on your network. You’ll have to make lots of holes in the firewall and handle a lot of naming and related issues. You would’ve maybe gotten away with this approach 10 years ago, but it’s not a viable solution today.

• How should you set up the VPN? The way to go is to install a VPN server or termination point in your VMS network, and then on the remote side, you install a VPN client. For the former step, many routers have a VPN server built in. The latter can be as simple as using the VPN built into Windows. A hardware client can tick the same box.

The VPN will allow remote operators to use the thick clients as soon as the VPN authenticates the connection. It will look as though your remote users and their clients are sitting on the surveillance network, and they’ll be able to access the VMS servers directly without any trouble. Many people are familiar with this setup, as having to connect your work laptop to your employer’s network with a VPN is common practice. While this setup requires a bit, it’s not too complicated.

Want to learn more about using Milestone XProtect in a cyber-resilient way? Here are a few of the many documents that are publicly available:

• XProtect GDPR Guide
• XProtect Certificate Guide
• XProtect Hardening Guide

Milestone is a CVE Numbering Authority, meaning that we are authorized by the CVE Program to assign CVE IDs to vulnerabilities and publish information about these vulnerabilities. This matters to our customers because they can expect:

• Timely disclosure of vulnerabilities, along with necessary information to understand the impact and apply any patches or mitigations.
• Standardized information that’s made accessible through the CVE database, making it easier to track and manage vulnerabilities.
• Proactive security measures, ensuring that vulnerabilities are not only identified and fixed but also publicly acknowledged and documented.

Have questions? We’d be happy to hear from you! Please send us a message or book a demo.