Compensations Modbus — état

Diffusion : interne. Décrit des faiblesses de l'interface des centrales : à ne pas diffuser hors de l'organisation.

Objet

Modbus TCP/RTU n'offre ni chiffrement ni authentification applicative. Cette limite est tracée comme risque accepté dans ../cra/02-evaluation-des-risques.md §3.6. La sécurité du lien dépend de deux côtés : le firmware des centrales, développé par un tiers (exigences adressées au fournisseur dans ../cra/07-exigences-securite-fournisseur-firmware.md), et les compensations portées par le Superviseur. Ce document couvre le second volet : ce qui est en place, et ce qui ne l'est pas.

Ces mesures ne sécurisent pas Modbus. Elles réduisent le risque et documentent la diligence raisonnable attendue à l'article 13.5 du règlement (UE) 2024/2847 pour les composants tiers intégrés.

En place

Imputabilité des écritures de commande

Toute commande envoyée à une centrale est tracée deux fois par PanelsController.ExecuteCommand :

• un enregistrement SystemLog nominatif (User, EventType.Command, centrale, commande, cible) ;
• une entrée au journal d'audit réglementaire via IAuditTrailService (AuditCategory.Operation, action panel.command, cible Panel), conservée cinq ans.

Le refus d'une commande est également consigné : une tentative de réarmement ou d'essai de zone par un compte non SuperAdmin produit une entrée d'audit en AuditOutcome.Failure. Ces deux commandes sont réservées au SuperAdmin — le réarmement solde les alarmes de toute l'installation, l'essai retire à une zone sa fonction de détection le temps de la manœuvre — et le contrôle est appliqué côté service, non par le seul affichage.

Couvre l'exigence de journalisation de l'activité pertinente pour la sécurité (annexe I, partie I).

Rejet des trames parasites INIS

InisAdapter.IsGarbageData écarte les trames parasites émises par le firmware INIS-E16 (octets 0xA8, 0xAA, 0xAB, 0xF0, 0xFF) avant tout décodage d'état, sur les tables de points comme de zones. Une trame reconnue comme parasite n'est pas interprétée : aucun feu ni défaut n'en découle.

Vérification de l'adressage déclaré

Un service confronte le modèle déclaré au comportement réel d'une centrale, à la demande :

• JbusValidationService — campagne de lectures pures, confronte le modèle structurel aux registres.

Il sert la mise en service et le diagnostic. Il ne fonctionne pas en continu.

Modèle de confiance documenté

La limite protocolaire et les mesures compensatoires sont énoncées dans ../cra/02-evaluation-des-risques.md §3.4 et §3.6.

Non couvert

Filtre de vraisemblance AVISS

AvissAdapter ne comporte aucun filtre équivalent à celui d'INIS. Les octets parasites écartés côté INIS sont propres au firmware INIS-E16 ; l'équivalent AVISS-DABUS n'est pas caractérisé.

Un filtre mal calibré masquerait un état réel. En logique incendie, un faux positif affiché est préférable à un danger filtré. La caractérisation demande des essais sur centrales AVISS réelles, non réalisés à ce jour.

Surveillance continue de la cohérence type ↔ comportement

Les trois services de vérification s'exécutent à la demande. Aucun contrôle permanent ne signale qu'une centrale cesse de se comporter conformément à son type déclaré, ce qui serait l'indice d'un mauvais raccordement ou d'une usurpation d'esclave. Établir ce contrôle suppose de formaliser des invariants observables par type, ce qui dépend des mêmes essais terrain.

Guide de segmentation réseau

La segmentation du lien Modbus sur un segment dédié non routé est le contrôle compensatoire principal tant que le protocole reste en clair. Elle est citée comme mesure en §3.6 et abordée dans REFLEXIONS.md §3, sans procédure de mise en réseau opposable rattachée à la notice technique.

Rattachement aux exigences

Exigence (règlement (UE) 2024/2847)	État
Journalisation de l'activité pertinente pour la sécurité — annexe I, partie I	Couverte pour les écritures de commande
Diligence raisonnable sur composants tiers — art. 13.5	Exigences adressées au fournisseur firmware ; compensations locales documentées
Évaluation et traitement des risques — annexe I, partie II	Limite protocolaire tracée comme risque accepté, §3.6
Protection contre les entrées non fiables — annexe I, partie I	Couverte côté INIS, non couverte côté AVISS