MESURES DE SÉCURITÉ
La sécurité informatique est un point de repère très important qui est souvent négligé et qui peut avoir des conséquences catastrophiques. Ritter Technologie GmbH attache une grande importance à un concept de sécurité sans faille qui évolue avec ses exigences. Nous respectons les recommandations MITRE / LIST et nos mesures de sécurité sont régulièrement contrôlées par des spécialistes externes afin de détecter les failles de sécurité. Les tests automatiques ne constituent pas seulement une base importante au niveau des logiciels, dans la mesure du possible, le matériel est également contrôlé automatiquement pour détecter les irrégularités.
L'organisme de certification de TÜV SÜD Management Service GmbH atteste que l'entreprise Ritter Technologie GmbH, Essener Straße 2-24, 46047 Oberhausen (Allemagne) a mis en place et applique un système de gestion de la sécurité de l'information conformément à la "Déclaration d'applicabilité" pour le domaine d'application mentionné ci-contre. Un audit, rapport n° 707066405, a démontré que les exigences de la norme ISO/CEI 27001:2017 sont remplies. Ce certificat est valable du 01.01.2023 au 31.12.2025.

Le domaine d'application du système de gestion de la sécurité de l'information de Ritter Technologie GmbH s'étend au site d'Oberhausen, Essener Straße 2-24, en application de la norme DIN EN ISO 27001:2013, pour le profil de prestations "Solutions informatiques innovantes et sûres, conseil, infrastructure, exploitation de centres informatiques, logiciels & prestations de service".
CYCLE DE VIE DU LOGICIEL
- Concepts de sécurité : par ex. CRS, OWASP contre SQLi, XSS, LFI, RFI, PHPci
- Utilisation des normes BSI 2020
- Tests manuels et automatiques, par ex. Cypress / Postman
- Centre de données et développement matériel / logiciel certifiés 27K

À PARTIR DES RECOMMANDATIONS MITRE / NIST
- Stabilité du composant en termes de fonctionnalité
- Utiliser principalement des produits open source pour effectuer ses propres revues de code source (créer un fork si nécessaire)
- Utiliser uniquement des projets actifs
Le risque le plus important est celui de l'abandon des projets open source. Dans ce cas, les développements ultérieurs doivent être réalisés en interne ou il faut passer à des produits alternatifs.
Les produits sont en outre testés et contrôlés par des spécialistes externes en matière de sécurité informatique.
SCAN DE VULNÉRABILITÉ
Nous avons déjà mis en place une procédure pour vérifier quotidiennement tous les référentiels de code pour les nouvelles CVE sur une base quotidienne. Cette procédure utilise Trivy, qui publie automatiquement des rapports et les crée sous forme de tickets pour les départements concernés. L'intégration de Trivy pour Buildroot se fera par le biais d'un analyseur syntaxique pour les statistiques PKG générées par Buildroot.

DROITS D'ACCÈS IEC 60870-104
haque processus serveur IEC60870-104 ne peut se connecter qu'à 1 client, connexion passive redondante exclue. Si plusieurs systèmes clients comme Salvador et SCADA veulent se connecter au RTU, il est donc nécessaire de faire fonctionner 2 processus serveur CEI6087-104 sur le RTU. Cela peut se faire via le fichier de mappage, en créant 2 objets de configuration. Chaque processus serveur IEC60870 a son propre espace d'objets IOA. Si vous souhaitez fournir des objets de surveillance/contrôle pour les deux processus serveur 104, il est nécessaire de créer 2 objets au sein du mappage. 1 objet pour chaque serveur.

Cette procédure permet de définir précisément quels objets de surveillance et de contrôle doivent être mis à disposition pour chaque processus serveur. Un filtre IP est fourni à cet effet.
CONTRÔLE D'ACCÈS

CONTRÔLE D'ACCÈS (SCADA)
Accès basé sur le filtrage IP, sécurisé par VPN Ipsec

VALIDATION DES FICHIERS DE CONFIGURATION
Toutes les configurations sont mises à disposition par Node-Red et sont automatiquement vérifiées.

GESTION DES CLÉS ET DES CERTIFICATS
Lors de la première mise en service et lorsque la date d'expiration est atteinte, le RTU récupère un certificat auprès du serveur PKI via SCEP. Ce certificat est utilisé pour établir la connexion IPsec entre la RTU et le réseau du client. En option, il est également utilisé pour la communication entre la RTU et DEMAS. Nécessité : mettre à disposition une CA racine appropriée pour DEMAS, car c'est l'ICP du client qui génère les certificats.
EN OPTION SUR DEMANDE
Sécurité - Confidentialité et intégrité de la communication réseau : sur RTU
Si la connexion WAN est déjà sécurisée par VPN, désactiver en option tout autre cryptage et donc bien sûr les certificats pour Deep Packet Inspection.

CONTRÔLE D'ACCÈS POUR LES INGÉNIEURS (DEMAS)
- La structure de notre protection technique est générique. Tous les fournisseurs Auth peuvent être connectés via Keycloak et NGINX.
- Nous avons choisi mTLS (certificat client TLS délivré par une PKI locale (SCEP)).
- Outre DEMAS, d'autres systèmes peuvent être sécurisés en option avec ce concept générique.

CONTRÔLE D'ACCÈS POUR LES INGÉNIEURS (RTU)
La RTU est gérée de manière centralisée par DEMAS. Par conséquent, un accès direct à la RTU via SSH est possible, mais pas nécessaire. Avec la RTU, il est possible de définir n'importe quel utilisateur, mot de passe et affectation de groupe dans la configuration du système.
Un service de connexion central gère les logins pour les modules DEMAS et les modules Node-Red. Cette configuration est normalement fournie par DEMAS, mais peut être modifiée localement. Dans ce cas, la modification est détectée et l'UUID 0 est renvoyé à DEMAS. Cela permet à DEMAS de réagir à la modification.
Les fichiers et les scripts de restauration fatale ne peuvent être modifiés ou exécutés que par des utilisateurs disposant de droits d'accès root.
L'utilisateur doit donc se trouver soit dans le groupe root, soit dans le groupe sudo. Dans le deuxième cas, l'utilisateur doit initier toutes les actions avec sudo.


- Nous utilisons Strongswan IPsec pour sécuriser le chemin de communication WAN du RTU au réseau du client. La configuration des paramètres IPsec peut être définie dans la configuration du système.
- Le certificat utilisé est récupéré par le serveur PKI lors du premier accès et de l'expiration via SCEP.
- L'authentification entre le serveur 104 et le client n'est pas encore implémentée ni mise en œuvre, car elle ne fait pas partie de la spécification du protocole.
- Pour sécuriser les communications, nous utilisons IPsec pour la confidentialité et l'intégrité.
CARACTÉRISTIQUES DE SÉCURITÉ RTU
- FIT (arbre d'images aplati)
- Déchiffré (Hashed) : SHA-256
- Crypté : AES-256-CBC
- Signed X.509 Cert (4096 Bit RSA Key)
- Contrôle Cert et décryptage d'image au démarrage
- Le chargeur d'amorçage est sécurisé via la signature HABv4 (source fermée par NXP)
- Le CPU fournit une fonction de démarrage sécurisé HABv4
- Le CPU ne charge que le chargeur de démarrage avec une signature HABv4 correcte
- Double démarrage pour le retour du firmware
- Cert programmé dans les fusibles OTP (One Time Programmable)

SÉCURITÉ DU FIRMWARE
Le firmware RTU utilise le format FIT. Ce fichier unique contient le noyau, l'arborescence du périphérique et le système de fichiers racine. Le RTU utilise un système de fichiers en RAM pour éviter d'endommager le FS racine. Le chargeur d'amorçage U-Boot vérifie à chaque démarrage la validité de l'image du firmware FIT, décompresse les données dans la RAM et exécute le noyau Linux. Toutes les modifications dans la FS racine sont perdues après un redémarrage.
Le processus rtu-mgr définit les paramètres de tous les services à chaque fois en fonction de la configuration du système fournie par DEMAS.
L'image FIT est signée en conséquence. La clé publique se trouve dans le bootloader car elle doit vérifier l'image. La clé privée se trouve uniquement sur le serveur de construction de firmware RITTEC et ne le quitte pas. Nous utilisons le format de clé maximal supporté par U-Boot, à savoir RSA 4096 bits avec SHA256.
Les données de l'image FIT sont cryptées et la clé correspondante n'est masquée qu'en sous-marin. Il ne s'agit pas d'une mesure de sécurité, mais uniquement d'une mesure contre la rétro-ingénierie.
En outre, chaque image FIT est dotée d'une signature HABv4. Il s'agit d'un procédé propriétaire
de NXP, qui est implémentée dans le CPU. Pour ce faire, une clé privée et une clé publique sont générées à l'aide d'un outil NXP. La clé privée ne quitte jamais le serveur de construction.
La clé publique est gravée dans le CPU par OneTimeProgrammable Fuses.
Une fois que la CPU est verrouillée de manière permanente par une autre sécurité OTP, elle ne peut plus exécuter que des chargeurs d'amorçage correctement signés HABv4. Le chargeur d'amorçage U-Boot que nous utilisons est donc signé HABv4, tout comme l'image FIT du firmware. Après le chargement de l'image FIT, le chargeur d'amorçage vérifie d'abord la signature HABv4 à l'aide du CPU, puis la signature FIT, décrypte les données dans la RAM et démarre le noyau.
Une mise à jour du firmware est effectuée en écrasant l'image FIT inactive complète. L'image précédemment inactive est activée et redémarrée. Toutes les opérations décrites ci-dessus suivent alors. Si l'image ne démarre pas, le chien de garde revient à l'ancienne image.