Sécurité et architecture informatique
PRECOG fonctionne dans un cloud hébergé par le fournisseur pour un pilote, et sur un serveur du client en production. Les deux modèles suivent les mêmes principes de sécurité.
Déploiement
Modèles de déploiement
L’API Web PRECOG et les services applicatifs fonctionnent dans un environnement cloud exploité par Vida Soft et sont accessibles par internet. L’appareil de mesure utilise le réseau existant du client, en Ethernet ou en Wi-Fi d’entreprise, et n’a besoin d’aucune passerelle dédiée. Les utilisateurs autorisés travaillent dans un navigateur. Les données sont stockées et traitées dans l’UE.
Un serveur PRECOG dédié, dans la salle serveurs du client, exécute l’API, l’analyse, l’IA, la base de données et l’interface de navigateur. Les appareils se connectent au point d’accès local de l’API, si bien que le fonctionnement normal ne dépend d’aucun service cloud externe.
Le système est observationnel. Il lit des mesures et n’envoie aucune commande aux machines.
Périphérie
Appareils de mesure
- Seuls les services nécessaires à la mesure, à la connexion et à la communication avec l’API sont actifs.
- Le trafic sortant passe par un canal HTTPS chiffré.
- Chaque message est signé avec une clé de machine (HMAC), qui protège son origine et son intégrité.
- L’accès réseau à l’appareil est limité par les contrôles Wi-Fi ou Ethernet du client.
- L’accès physique, la gestion du micrologiciel et la maintenance suivent des processus contrôlés.
- Si la connexion est perdue, l’appareil conserve les enregistrements dans son propre stockage et les envoie dans l’ordre. Un enregistrement n’est considéré comme livré qu’après confirmation par l’API.
Interface
API et communication
Transport
TLS 1.2 ou ultérieur, et TLS 1.3 dans le pilote. HTTP non chiffré, FTP et Telnet ne sont pas nécessaires en fonctionnement normal.
Authentification
Les appareils utilisent une signature HMAC et une identification d’appareil. Les services utilisent des comptes dédiés sans connexion interactive. Les intégrations utilisent un secret ou un certificat.
Entrées et erreurs
Le serveur valide le type, la plage, la longueur et le format de chaque entrée. Les messages d’erreur sont génériques et ne révèlent rien du système.
Les identifiants de session ne sont jamais transmis comme paramètres d’URL. L’accès suit le principe du moindre privilège. Les événements d’API réussis et échoués sont journalisés.
Données
Données et propriété
PRECOG traite de la télémétrie technique, des informations sur les équipements, des résultats d’analyse, des événements, des fiches utilisateur et des journaux d’administration. Le traitement a une finalité définie, l’accès dépend du rôle et les modifications importantes peuvent être auditées. Un paquet de pilote peut se limiter à des valeurs techniques anonymes avec un horodatage, un numéro de séquence et un identifiant d’appareil qui ne décrit rien. Il ne contient alors aucune donnée personnelle ni nom de machine, numéro de série ou emplacement exact.
Les données suivent un cycle de vie maîtrisé : collecte, conservation, utilisation, sauvegarde et suppression contrôlée. Les fichiers de données, les sauvegardes et la configuration sensible sont chiffrés au repos. Les clés et les secrets sont gérés séparément des données, avec un accès restreint et une rotation et une révocation documentées.
Accès
Contrôle d’accès
- Appareils : authentification de machine HMAC avec un secret unique et protection contre le rejeu.
- Utilisateurs : un identifiant unique et un mot de passe robuste, avec authentification multifacteur lorsqu’elle est intégrée.
- Administrateurs : comptes nominatifs distincts, authentification multifacteur lorsqu’elle est intégrée, et journalisation des sessions.
- Accès fondé sur les rôles : lecteur, technicien de maintenance, responsable de maintenance, administrateur système et auditeur.
- Chaque rôle ne voit que les fonctions et les données dont il a besoin.
- Les droits privilégiés sont revus régulièrement, les comptes inactifs sont révoqués et les événements d’accès sont journalisés.
Exploitation
Journalisation, sauvegarde et correctifs
Journalisation
Les journaux d’audit, d’API, de sécurité, d’application, de base de données et de système d’exploitation partagent une source de temps commune, un identifiant de source, un type d’événement, un résultat et un identifiant de corrélation. Lorsqu’un SIEM est intégré, les journaux peuvent lui être transmis.
Sauvegarde et restauration
Le modèle de sauvegarde s’intègre à la sauvegarde centrale du client : sauvegardes fréquentes de la base de données, sauvegarde complète quotidienne, sauvegarde de la configuration après chaque modification approuvée et image du système avant les changements majeurs. La restauration suit une séquence documentée.
Directive
Directive NIS2 : ce qu’elle demande
La directive (UE) 2022/2555, dite NIS2, fixe des règles communes de cybersécurité pour les entités essentielles et importantes de l’UE. Chaque État membre l’applique par sa propre législation nationale. L’article 21 énumère les mesures de gestion des risques qu’une entité doit prendre. L’article 23 décrit la notification des incidents importants.
Les obligations incombent à l’organisation exploitante. Un fournisseur ne peut pas les reprendre. Un fournisseur peut proposer un produit conçu de façon sûre, clairement documenté et facile à intégrer au programme de sécurité de l’exploitant. C’est ainsi que PRECOG est conçu.
PRECOG est un système observationnel. Il lit des mesures et n’envoie aucune commande aux machines, il n’ajoute donc aucun moyen d’agir sur un processus. L’architecture et les contrôles sont décrits dans les sections ci-dessus.
Article 21
Mesures NIS2 et PRECOG
Chaque fiche nomme une mesure de l’article 21, paragraphe 2, et indique ce que PRECOG fournit pour elle.
Le modèle de déploiement, les zones de sécurité et chaque connexion réseau sont documentés, avec la source, la destination, le protocole, le port et la justification métier. L’exploitant peut utiliser directement cette description dans sa propre analyse des risques.
Les événements d’audit, d’API et de sécurité sont journalisés avec une source de temps commune, un type d’événement, un résultat et un identifiant de corrélation. Les journaux peuvent être transmis à un SIEM. Les événements de sécurité suivent un processus classifié avec une investigation fondée sur les journaux, un test de vérification et une clôture documentée.
Le modèle de sauvegarde s’intègre à la sauvegarde centrale du client : sauvegardes de la base de données, sauvegarde complète quotidienne, sauvegarde de la configuration après chaque modification approuvée et image du système avant les changements majeurs. La restauration suit une séquence documentée. Un appareil de mesure conserve ses enregistrements pendant une panne de réseau et les envoie dans l’ordre.
L’infrastructure prise en charge est listée. Les composants dont le support du fournisseur est terminé sont migrés. La propriété des données et du logiciel est définie par écrit, de sorte que l’exploitant peut évaluer PRECOG en tant que fournisseur.
Des évaluations des vulnérabilités sont menées avant le déploiement, après les changements importants et à intervalles réguliers. Les constats sont classés selon le risque, l’exploitabilité et l’impact métier. Avant la mise en service, la surface d’attaque externe et interne est testée, et un nouveau test confirme les corrections. Les changements suivent un processus de livraison contrôlé.
Les tests d’intrusion et leurs nouveaux tests, les évaluations régulières des vulnérabilités et la surveillance de la plateforme elle-même fournissent des preuves de l’efficacité des mesures. La surveillance de la plateforme suit la disponibilité, le temps de réponse, le taux d’erreurs et l’utilisation des ressources.
Seuls les services nécessaires sont actifs. Les ports inutiles sont fermés, les services s’exécutent sous des comptes non privilégiés et il n’y a pas de connexion d’administrateur directe à distance. La formation du personnel est une mesure organisationnelle de l’exploitant.
La communication utilise TLS 1.2 ou ultérieur, et TLS 1.3 dans le pilote. Chaque message d’appareil est signé avec une clé de machine (HMAC). Les fichiers de données, les sauvegardes et la configuration sensible sont chiffrés au repos. Les clés sont gérées séparément, avec une rotation et une révocation documentées. Les anciennes versions de SSL et de TLS ainsi que les algorithmes faibles sont désactivés.
L’accès est fondé sur les rôles, avec cinq rôles du lecteur à l’auditeur, et suit le principe du moindre privilège. Les droits privilégiés sont revus régulièrement, les comptes inactifs sont révoqués et les événements d’accès sont journalisés. Chaque appareil possède un identifiant unique et un secret unique.
Les utilisateurs et les administrateurs peuvent utiliser l’authentification multifacteur lorsqu’elle est intégrée, et les administrateurs disposent de comptes nominatifs distincts. La connexion sans fil des appareils peut être protégée par WPA3 Enterprise et 802.1X. Le trafic sortant utilise un canal chiffré.
Article 23
Notification des incidents NIS2
Une entité doit envoyer une alerte précoce dans les 24 heures suivant la connaissance d’un incident important, une notification dans les 72 heures et un rapport final dans un délai d’un mois. Pour cela, l’exploitant a besoin de faits fiables, rapidement.
Les journaux de PRECOG partagent une même source de temps et comportent un identifiant de source, un type d’événement, un résultat et un identifiant de corrélation. Ils peuvent être transmis au SIEM de l’exploitant, où ils rejoignent les autres journaux. La décision sur le caractère important d’un incident, et la notification à l’autorité, restent du ressort de l’exploitant.
Secteurs
Où NIS2 s’applique
La directive énumère des secteurs tels que l’énergie, les transports, y compris aérien et ferroviaire, l’eau potable et les eaux usées, la santé, les infrastructures numériques et la fabrication d’équipements électriques et de machines. Les aéroports, les chemins de fer, les services publics et les industriels font partie des organisations où PRECOG surveille des moteurs électriques.
Le fait qu’une organisation entre dans le champ d’application dépend de son secteur, de sa taille et de la législation nationale du pays où elle exerce.
Périmètre
Périmètre de la section NIS2
Avez-vous des exigences informatiques, de sécurité ou NIS2 auxquelles nous devrions répondre avant un pilote ?