Basic steps
Establish surveillance and security objectives
Before implementing the VMS, Milestone recommends that you establish surveillance objectives. Define goals and expectations related to capturing and using video data and related metadata. All stakeholders should understand the surveillance objectives.
Specifics of surveillance objectives can be found in other documents, for example BS EN 62676-1-1: Video surveillance systems for use in security applications.System requirements. General.
When surveillance objectives are in place, you can establish the security objectives. Security objectives support the surveillance objectives by addressing what to protect in the VMS. A shared understanding of security objectives makes it easier to secure the VMS and maintain data integrity.
With the surveillance and security objectives in place, you can more easily address the operational aspects of securing the VMS, such as how to:
- Prevent data from being compromised
- Respond to threats and incidents when they occur, including roles and responsibilities.
Learn more
The following control(s) provide additional guidance:
- NIST SP 800-53 PL-2 System Security Plan
- NIST SP 800-53 SA-4 Acquisition Process
Establish a formal security policy and response plan
In compliance with NIST SP 800-100 Information Security Handbook: A Guide for Managers (http://csrc.nist.gov/publications/nistpubs/800-100/sp800-100-mar07-2007.pdf), Milestone recommends that you establish a formal security policy and a response plan that describe how your organization addresses security issues, in terms of practical procedures and guidelines. For example, a security policy can include:
- A password policy defined by the internal IT department
- Access control with ID badges
- Restrictions for smartphones from connecting to the network
Adopt existing IT policies and plans if they adhere to security best practices.
Learn more
The following control(s) provide additional guidance:
- NIST SP 800-53 IR-1 Incident Response Policy and Procedures
- NIST SP 800-53 PM-1 Information Security Program Plan
Use Windows users with Active Directory
There are two types of users in VMS XProtect:
- Basic user: a dedicated VMS user account authenticated by a combination of username and password using a password policy. Basic users connect to the VMS using a secure socket layer (SSL) with current Transport Layer (TLS) security protocol session (https://datatracker.ietf.org/wg/tls/charter/) for login, encrypting the traffic contents and username and password.
- Windows user: the user account is specific to a machine or a domain, and it is authenticated based on the Windows login. Windows users connecting to the VMS can use Microsoft Windows Challenge/Response (NTML) for login, Kerberos (see Kerberos authentication (explained)), or other SSP options from Microsoft (https://msdn.microsoft.com/en-us/library/windows/desktop/aa380502(v=vs.85).aspx).
Milestone recommends that, whenever possible, you use Windows users in combination with Active Directory (AD) to authorize access to the VMS. This allows you to enforce:
- A password policy that requires users to change their password regularly
- Brute force protection, so that the Windows AD account is blocked after a number of failed authentication attempts, again in line with the organization password policy
- Multi-factor authentication in the VMS, particularly for administrators
- Role-based permissions, so you can apply access controls across your domain
If your organization does not use AD, you can add Windows users to workgroups on the management server instead. Workgroups give you some of the same advantages as Windows users with AD. You can enforce a password policy, which helps protect against brute force attacks, but Milestone recommends that you use a Windows Domain because this gives you central control over user accounts.
Windows users have the advantage of being authenticated via the directory as a single authoritative source and enterprise service for the network and not ad hoc for their local machine. This lets you use role based access controls to assign permissions to users and groups consistently across the domain and the computers on the network.
If you use local Windows users, the user must create a local user name and password on each machine, which is problematic from security and usability perspectives.
To add Windows users or groups to roles in Management Client, follow these steps:
- Open Management Client.
- Expand the Security node.
- Select the role to which you want to add the Windows users.
- On the Users and Groups tab, click Add, and select Windows user. A pop-up window appears.
- If the domain name does not appear in the From this location field, click Locations.
- Specify the Windows user, and then click OK.
To verify that the Windows user is an AD user, the domain name must appear as a prefix, for example "Domain\John".
Learn more
The following control(s) provide additional guidance:
- NIST SP 800-53 CM-6 Configuration Settings
- NIST SP 800-53 SA-5 Information System Documentation
- NIST SP 800-53 SA-13 Trustworthiness
Secure communication (explained)
Hypertext Transfer Protocol Secure (HTTPS) est une extension de Hypertext Transfer Protocol (HTTP) pour une communication sécurisée sur un réseau informatique. Sur HTTPS, le protocole de communication est crypté en utilisant Sécurité de la couche transport (TLS), ou son prédécesseur, Couche de sockets sécurisés (SSL).
Dans VMS XProtect, la communication sécurisée est obtenue en utilisant SSL/TLS avec un cryptage asymétrique (RSA).
SSL/TLS utilise une paire de clés, une privée et une publique, pour authentifier, sécuriser et gérer les connexions sécurisées.
Une autorité de certification (AC) peut émettre des certificats aux services Web sur des serveurs utilisant un certificat de l'AC. Ce certificat contient deux clés, une clé privée et une clé publique. La clé publique est installée sur les clients d'un service Web (clients de service) en installant un certificat public. La clé privée est utilisée pour la signature des certificats de serveur qui doivent être installés sur le serveur. Lorsqu'un client de service appelle le service Web, le service Web envoie le certificat du serveur incluant la clé publique au client. Le client de service peut valider le certificat de serveur utilisant le certificat public de l'AC déjà installé. Le client et le serveur peuvent désormais utiliser le certificat de serveur public et privé pour échanger une clé secrète et par conséquent, établir une connexion SSL/TLS sécurisée.
Pour plus d'informations sur TLS : https://en.wikipedia.org/wiki/Transport_Layer_Security
Les certificats possèdent une date d'expiration. VMS XProtect ne vous préviendra pas lorsqu'un certificat est sur le point d'expirer. Si un certificat expire :
• Les clients ne feront plus confiance au serveur d'enregistrement dû au certificat expiré et ils ne pourront donc plus communiquer avec lui
• Les serveurs d'enregistrement ne feront plus confiance au serveur de gestion dû au certificat expiré et ne pourront donc plus communiquer avec lui
• Les périphériques mobiles ne feront plus confiance au serveur mobile dû au certificat expiré et ils ne pourront donc plus communiquer avec lui
Pour renouveler les certificats, suivez les étapes figurant dans ce guide que vous avez suivies lors de la création des lesdits certificats.
Lorsque vous renouvelez un certificat avec le même nom de sujet, et que vous l'ajoutez à la Windows Certificate Store, les serveurs choisiront automatiquement le nouveau certificat. Cela rend plus facile la rénovation des certificats pour plusieurs serveurs d'enregistrement sans avoir à sélectionner de nouveau le certificat pour chaque serveur d'enregistrement et sans avoir à redémarrer les services.
Cryptage du serveur de gestion (explications)
Vous pouvez crypter une connexion bidirectionnelle entre le serveur de gestion et le serveur d'enregistrement. Lorsque vous activez le cryptage sur le serveur de gestion, il s'applique aux connexions depuis les serveurs d'enregistrement se connectant au serveur de gestion. Si vous activez le cryptage sur le serveur de gestion, vous devez également activer le cryptage sur tous les serveurs d'enregistrement. Avant d'activer le cryptage, vous devez installer des certificats de sécurité sur le serveur de gestion et tous les serveurs d'enregistrement.
Distribution de certificat pour les serveurs de gestion
Le diagramme illustre le concept de base de comment les certificats sont-ils signés, fiables et distribués dans VMS XProtect dans le but de sécuriser la communication vers le serveur de gestion.
Un certificat de l'AC agit en tant que tiers de confiance, jouissant de la confiance du sujet/propriétaire (le serveur de gestion) et de la partie vérifiant le certificat (serveur d'enregistrement)
Le certificat privé de l'AC doit être fiable sur tous les serveurs d'enregistrement. De cette manière, les serveurs d'enregistrement vérifient la validité des certificats émis par l'AC
Le certificat de l'AC est utilisé pour établir une connexion sécurisée entre le serveur de gestion et les services d'enregistrement
Le certificat de l'AC doit être installé sur un ordinateur exécutant le serveur de gestion
Prérequis pour le certificat privé sur le serveur de gestion :
- Émis au serveur de gestion, donc le nom d'hôte du serveur de gestion est inclus dans le nom du certificat, soit en tant qu'objet (propriétaire) ou dans la liste des noms DNS auxquels est émis le certificat
- Fiable sur le serveur de gestion lui-même en utilisant un certificat de l'AC qui a été utilisé pour émettre le certificat du serveur de gestion
- Fiable sur tous les serveurs d'enregistrement connectés au serveur de gestion de préférence en utilisant un certificat de l'AC qui a été utilisé pour émettre le certificat du serveur de gestion
Cryptage du serveur de gestion vers le serveur d'enregistrement (explications)
Vous pouvez crypter une connexion bidirectionnelle entre le serveur de gestion et le serveur d'enregistrement. Lorsque vous activez le cryptage sur le serveur de gestion, il s'applique aux connexions depuis les serveurs d'enregistrement se connectant au serveur de gestion. Le cryptage de cette communication doit suivre les paramètres de cryptage sur le serveur de gestion. Ainsi, si le cryptage du serveur de gestion est activé, celui-ci doit être également activé sur les serveurs d'enregistrement et vice versa. Avant d'activer le cryptage, vous devez installer des certificats de sécurité sur le serveur de gestion et tous les serveurs d'enregistrement, dont les serveurs d'enregistrement de redondance.
Distribution de certificat
Le diagramme illustre le concept de base de comment les certificats sont-ils signés, fiables et distribués dans VMS XProtect dans le but de sécuriser la communication depuis le serveur de gestion.
Un certificat de l'AC agit en tant que tiers de confiance, jouissant de la confiance du sujet/propriétaire (le serveur d'enregistrement) et de la partie vérifiant le certificat (serveur de gestion)
Le certificat de l'AC doit être fiable sur tous les serveurs de gestion. De cette manière, le serveur de gestion vérifie la validité des certificats émis par l'AC
Le certificat de l'AC est utilisé pour établir une connexion sécurisée entre les serveurs d'enregistrement et le serveur de gestion
Le certificat de l'AC doit être installé sur les ordinateurs exécutant les serveurs d'enregistrement
Prérequis pour le certificat privé sur le serveur d'enregistrement :
- Émis au serveur d'enregistrement, donc le nom d'hôte du serveur d'enregistrement est inclus dans le certificat, soit en tant qu'objet (propriétaire) ou dans la liste des noms DNS auxquels est émis le certificat
- Fiable sur tous les serveurs de gestion connectés au serveur de gestion de préférence en utilisant un certificat de l'AC qui a été utilisé pour émettre le certificat du serveur d'enregistrement
Cryptage entre le serveur de gestion et le Data Collector Server (explications)
Vous pouvez crypter une connexion bidirectionnelle entre le serveur de gestion et le Data Collector affilié lorsque vous disposez d'un type de serveur distant suivant :
- Recording Server
- Event Server
- Log Server
- LPR Server
- Mobile Server
Lorsque vous activez le cryptage sur le serveur de gestion, il s'applique aux connexions depuis les serveurs Data Collector se connectant au serveur de gestion. Le cryptage de cette communication doit suivre les paramètres de cryptage sur le serveur de gestion. Ainsi, si le cryptage du serveur de gestion est activé, celui-ci doit être également activé sur les serveurs Data Collector affiliés à chacun des serveurs distants et vice versa. Avant d'activer le cryptage, vous devez installer des certificats de sécurité sur le serveur de gestion et tous les serveurs Data Collector affiliés aux serveurs distants.
Distribution de certificat
Le diagramme illustre le concept de base de comment les certificats sont-ils signés, fiables et distribués dans VMS XProtect dans le but de sécuriser la communication depuis le serveur de gestion.
Un certificat de l'AC agit en tant que tiers de confiance, jouissant de la confiance du sujet/propriétaire (le serveur de collecteur de données) et de la partie vérifiant le certificat (serveur de gestion)
Le certificat de l'AC doit être fiable sur tous les serveurs de gestion. De cette manière, le serveur de gestion vérifie la validité des certificats émis par l'AC
Le certificat de l'AC est utilisé pour établir une connexion sécurisée entre les serveurs de collection de données et le serveur d'enregistrement
Le certificat de l'AC doit être installé sur les ordinateurs exécutant les serveurs de collection de données
Prérequis pour le certificat privé sur le serveur de collection de données :
- Émis au serveur de collection de données, donc le nom d'hôte du serveur de collection de données est inclus dans le certificat, soit en tant qu'objet (propriétaire) ou dans la liste des noms DNS auxquels est émis le certificat
- Fiable sur tous les serveurs de gestion connectés au serveur de gestion de préférence en utilisant un certificat de l'AC qui a été utilisé pour émettre le certificat du serveur de collection de donnée
Le cryptage s'applique à tous les clients et serveurs recueillant des flux de données depuis le serveur d'enregistrement (explications)
Lorsque vous activez le cryptage sur un serveur d'enregistrement, les communications depuis tous les clients, serveurs et intégrations récoltant des flux de données depuis le serveur d'enregistrement sont cryptées. Dans ce document, dénommé comme « clients » :
- XProtect Smart Client
- Management Client
- Management Server (pour le Système de surveillance et les images ainsi que les vidéos AVI dans les notifications par email)
- Serveur XProtect Mobile
- XProtect Event Server
- XProtect LPR
- Milestone Open Network Bridge
- XProtect DLNA Server
- Les sites collectant des flux de donnée depuis le serveur d'enregistrement par le biais de Milestone Interconnect
- Quelques intégrations tierces de MIP SDK
Distribution de certificat
Le diagramme illustre le concept de base de comment les certificats sont-ils signés, fiables et distribués dans VMS XProtect dans le but de sécuriser la communication vers le serveur d'enregistrement.
Un certificat de l'AC agit en tant que tiers de confiance, jouissant de la confiance du sujet/propriétaire (le serveur d'enregistrement) et de la partie vérifiant le certificat (tous les clients)
Le certificat privé de l'AC doit être fiable sur tous les clients. De cette manière, les clients peuvent vérifier la validité des certificats émis par l'AC
Le certificat de l'AC est utilisé pour établir une connexion sécurisée entre les serveurs d'enregistrement et tous les clients et services
Le certificat de l'AC doit être installé sur les ordinateurs exécutant les serveurs d'enregistrement
Prérequis pour le certificat privé sur le serveur d'enregistrement :
- Émis au serveur d'enregistrement, donc le nom d'hôte du serveur d'enregistrement est inclus dans le certificat, soit en tant qu'objet (propriétaire) ou dans la liste des noms DNS auxquels est émis le certificat
- Fiable sur tous les ordinateurs exécutant des services qui collectent des flux de données depuis les serveurs d'enregistrement, de préférence en utilisant un certificat de l'AC qui a été utilisé pour émettre le certificat du serveur d'enregistrement
- Le compte du service exécutant le serveur d'enregistrement doit avoir accès à la clé privée du certificat sur le serveur d'enregistrement.
Si vous activez le cryptage sur les serveurs d'enregistrement et que votre système applique des serveurs d'enregistrement de basculement, Milestone vous recommande de préparer également le serveur d'enregistrement de redondance pour le cryptage.
Cryptage des données du serveur mobile (explications)
Sur VMS XProtect, le cryptage est activé ou désactivé par serveur mobile. Lorsque vous activez le cryptage sur un serveur mobile, vous aurez l'option d'utiliser une communication cryptée avec tous les clients, services et intégrations récoltant des flux de données.
Distribution de certificat pour les serveurs mobiles
Le diagramme illustre le concept de base de comment les certificats sont-ils signés, fiables et distribués dans VMS XProtect dans le but de sécuriser la communication avec le serveur mobile.
Un certificat de l'AC agit en tant que tiers de confiance, jouissant de la confiance du sujet/propriétaire (le serveur mobile) et de la partie vérifiant le certificat (tous les clients)
Le certificat privé de l'AC doit être fiable sur tous les clients. De cette manière, les clients vérifient la validité des certificats émis par l'AC
Le certificat de l'AC est utilisé pour établir une connexion sécurisée entre le serveur mobile et les clients et services
Le certificat de l'AC doit être installé sur un ordinateur exécutant le serveur mobile
Prérequis pour le certificat de l'AC :
- Le nom d'hôte du serveur mobile doit être inclus dans le certificat, soit en tant qu'objet/propriétaire ou dans la liste des noms DNS auxquels est émis le certificat
- Un certificat doit être fiable sur tous les périphériques exécutant des services qui collectent des flux de données depuis le serveur mobile
- Le compte du service exécutant le serveur mobile doit avoir accès à la clé privée du certificat de l'AC
Exigences du cryptage du serveur mobile pour les clients
Si vous n'activez pas le cryptage et que vous utilisez une connexion HTTP, la fonctionnalité appuyer pour parler dans XProtect Web Client ne sera pas disponible.
Kerberos authentication (explained)
Kerberos is a ticket-based network authentication protocol. It is designed to provide strong authentication for client/server or server/server applications.
Use Kerberos authentication as an alternative to the older Microsoft NT LAN (NTLM) authentication protocol.
Kerberos authentication requires mutual authentication, where the client authenticates to the service and the service authenticates to the client. This way you can authenticate more securely from XProtect clients to XProtect servers without exposing your password.
To make mutual authentication possible in your VMS XProtect you must register Service Principal Names (SPN) in the active directory. An SPN is an alias that uniquely identifies an entity such as a XProtect server service. Every service that uses mutual authentication must have an SPN registered so that clients can identify the service on the network. Without correctly registered SPNs, mutual authentication is not possible.
The table below lists the different Milestone services with corresponding port numbers you need to register:
|
Service |
Port number |
|---|---|
|
Management server - IIS |
80 - Configurable |
|
Management server - Internal |
8080 |
|
Recording server - Data Collector |
7609 |
|
Failover Server |
8990 |
|
Event Server |
22331 |
|
LPR Server |
22334 |
The number of services you need to register in the active directory depends on your current installation. Data Collector is installed automatically when installing Management Server, Recording Server, Event Server, LPR Server or Failover Server.
You must register two SPNs for the user running the service: one with the host name and one with the fully qualified domain name.
If you are running the service under a network user service account, you must register the two SPNs for each computer running this service.
This is the Milestone SPN naming scheme:
VideoOS/[DNS Host Name]:[Port]
VideoOS/[Fully qualified domain name]:[Port]
The following is an example of SPNs for the recording server service running on a computer with the following details:
Hostname: Record-Server1
Domain: Surveillance.com
SPNs to register:
VideoOS/Record-Server1:7609
VideoOS/Record-Server1.Surveillance.com:7609
Use Windows update
Milestone recommends that you use Windows Update to protect your VMS against vulnerabilities in the operating system by making sure that the latest updates are installed.VMS XProtect is Windows-based, so security updates from Windows Update are important.
Updates can require a connection to the Internet, so Milestone recommends that this connection is open only as required, and that it is monitored for unusual traffic patterns.
Windows Updates often require a restart. This can be a problem if high-availability is required, because the server cannot receive data from devices while it restarts.
There are several ways to avoid this, or minimize the impact. For example, you can download updates to the server, and then apply them at a time when a restart will disrupt surveillance as little as possible.
If high availability is a concern, Milestone recommends that you run management server and event servers in clusters that include one or more failover servers. The failover server will take over while the recording server restarts, and surveillance is not interrupted. Do not include recording servers in the cluster. For recording servers, use a failover recording server.
Before implementing Windows updates across the organization, Milestone recommends that you verify the updates in a test environment. See NIST 800-53 CM-8 Information system component inventory and sandboxing and SC-44 Detonation Chambers.
Learn more
The following control(s) provide additional guidance:
- NIST SP 800-53 SI-2 Flaw Remediation
Keep software and device firmware updated
Milestone recommends that you use the latest version of VMS XProtect and firmware for the hardware devices, for example the cameras. This will ensure that your system includes the latest security fixes.
For hardware, network components, and operating systems, check the CVE database as well as any updates pushed out by manufacturers.
Before you upgrade the device firmware, verify that VMS XProtect supports it. Also, make sure that the device pack installed on the recording servers supports the device firmware.
Do this in a test environment for configuration, integration and testing before putting it into the production environment.
To verify that the VMS supports a device, follow these steps:
- Open this link (https://www.milestonesys.com/da/community/business-partner-tools/supported-devices/).
- Click the link that matches your VMS XProtect product.
- In the Device pack column, select the version of the current device pack.
- Select the manufacturer of your device, and then click Filter. The version of the firmware that the device pack supports is listed in the Tested Firmware column.
Learn more
The following control(s) provide additional guidance:
- NIST SP 800-53 SI-2 Flaw Remediation
Use antivirus on all servers and computers
Milestone recommends that you deploy anti-virus software on all servers and computers that connect to the VMS. Malware that gets inside your system can lock, encrypt, or otherwise compromise data on the servers and other devices on the network.
If mobile devices connect to the VMS, this includes ensuring that the devices have the latest operating systems and patches (though not directly anti-virus) installed.
When you do virus scanning, do not scan recording server directories and subdirectories that contain recording databases. In addition, do not scan for viruses on archive storage directories. Scanning for viruses on these directories can impact system performance.
For information about the ports, directories, and subdirectories to exclude from the virus scan, see the section About virus scanning in the VMS XProtect - Administrator manual.
Learn more
The following control(s) provide additional guidance:
- NIST SP 800-53 PL-8 Information Security Architecture
- NIST SP 800-53 SI-2 Flaw remediation
- NIST SP 800-53 SI-3 Malicious Code Protection
- NIST SP 800-53 SI Information Systems Monitoring
Monitor logs in the VMS for signs of suspicious activity
VMS XProtect provides features for generating and viewing logs that provide information about patterns of use, system performance, and other issues.Milestone recommends that you monitor the logs for signs of suspicious activities.
There are tools that leverage logs for operational and security purposes. Many businesses use syslog servers to consolidate logs. You can use syslog to note activities at a Windows level, however, VMS XProtect does not support syslog.
Milestone recommends that you use the Audit Log in VMS XProtect, and enable user access logging in Management Client. By default, the Audit Log notes only user logins. However, you can turn on user access logging so that the Audit Log notes all user activities in all of the client components of VMS XProtect products. This includes the times of the activities and the source IP addresses.
The client components are XProtect Smart Client, Web Client, the XProtect Management Client component, and integrations made by using the MIP SDK. Examples of activities are exports, activating outputs, viewing cameras live or in playback, and so on.
The Audit log does not note unsuccessful login attempts, or when the user logs out.
Logging all user activities in all clients increases the load on the system, and can affect performance.
You can adjust the load by specifying the following criteria that controls when the system will generate a log entry:
- The number of seconds that comprise one sequence. The VMS generates one log entry when a user plays video within the sequence.
- The number of frames that a user must view when playing back video before the VMS generates a log entry.
To turn on and configure extended user access logging, follow these steps:
- In Management Client, click Tools, and select Options.
- On the Server Logs tab, under Log settings, select Audit Log.
- Under Settings, select the Enable user access logging check box.
- Optional: To specify limitations for the information that is noted, and reduce impact on performance, make selections in the Playback sequence logging length and Records seen before logging fields.
To view the Audit Log in VMS XProtect, follow these steps:
- Open Management Client.
- Expand the Server Logs node.
- Click Audit Log.
Learn more
The following control(s) provide additional guidance:
- NIST SP 800-53 AU-3 Content of Audit Records
- NIST SP 800-53 RA-5 Vulnerability Scanning
- NIST SP 800-53 AU-6 Audit Review, Analysis and Reporting