Mises à jour sécurisées
Ce que le règlement exige
Quatre exigences, réparties entre les deux parties de l’annexe I :
- les vulnérabilités peuvent être corrigées par des mises à jour de sécurité, y compris, lorsque c’est approprié, automatiques et activées par défaut, avec un mécanisme de refus clair et une information sur les mises à jour disponibles ;
- les correctifs de sécurité sont fournis séparément des évolutions fonctionnelles lorsque c’est techniquement possible ;
- des mécanismes de diffusion sécurisée garantissent que les correctifs parviennent aux utilisateurs sans altération ;
- les correctifs sont diffusés sans délai et gratuitement, accompagnés de messages consultatifs indiquant les actions à entreprendre.
Le mécanisme technique
| Propriété | Mise en œuvre |
|---|---|
| Authenticité | Signature du paquet de mise à jour, vérifiée par le produit avant application |
| Intégrité | Empreinte vérifiée ; échec propre en cas d’altération |
| Confidentialité du canal | Transport chiffré et authentification du serveur |
| Protection contre le retour arrière | Refus d’installer une version antérieure, sauf procédure explicite de restauration |
| Résilience | Reprise après coupure ; le produit reste fonctionnel si la mise à jour échoue |
| Vérifiabilité | L’utilisateur peut vérifier la version installée et l’historique |
| Racine de confiance | Clé de vérification protégée, procédure de rotation prévue et testée |
La rotation de clé est le point le plus souvent oublié. Sur un produit supporté dix ans, la clé de signature devra changer. Si le mécanisme ne le prévoit pas dès la conception, le produit deviendra non maintenable.
Les mises à jour automatiques
Activées par défaut lorsque c’est approprié. Ce qualificatif appelle une décision documentée, appuyée sur l’analyse de risques : un équipement industriel dont un redémarrage inopiné arrêterait une ligne de production relève d’un autre régime qu’une application grand public.
Dans tous les cas :
- information de l’utilisateur sur l’existence du mécanisme et sur ses effets ;
- possibilité de désactivation claire, avec information sur les conséquences ;
- possibilité de différer une mise à jour ;
- notification des mises à jour disponibles lorsqu’elles ne sont pas automatiques.
Ces éléments doivent figurer dans la notice utilisateur — voir Documentation utilisateur.
La séparation des correctifs
C’est l’exigence qui a le plus de conséquences sur l’ingénierie.
Fournir un correctif de sécurité sans évolution fonctionnelle suppose :
- des branches de maintenance par ligne de version supportée ;
- une capacité de rétroportage du correctif vers ces branches ;
- une numérotation qui distingue clairement un correctif de sécurité ;
- des environnements de construction conservés pour les branches anciennes — sur dix ans, cela signifie archiver les outils, pas seulement le code ;
- des tests de non-régression exécutables sur ces branches.
Un modèle de publication en flux continu, sans branches de maintenance, ne permet pas de satisfaire cette exigence : le client doit alors accepter les évolutions fonctionnelles pour obtenir le correctif. La décision d’architecture doit être prise avant le premier incident.
La gratuité
Les correctifs de sécurité sont gratuits pendant la période de support, sauf accord contraire pour des produits sur mesure entre professionnels.
Conséquence commerciale à instruire : un contrat de maintenance ne peut pas conditionner l’accès aux correctifs de sécurité. Voir Traduire la période de support en engagements.
Les messages consultatifs
Chaque diffusion s’accompagne d’un message indiquant à l’utilisateur ce qu’il doit faire. Contenu minimal : les vulnérabilités corrigées, les produits et versions concernés, la gravité, l’urgence d’application, et les éventuelles actions manuelles requises.
Publier ces messages dans un format lisible par machine — CSAF 2.0 — permet à vos clients de les traiter automatiquement. Ce n’est pas exigé explicitement, mais c’est ce que les grands comptes demanderont, et cela réduit vos propres sollicitations.
Le cas de l’embarqué et de la connectivité contrainte
Contraintes spécifiques, à traiter dès la conception :
- taille du paquet de mise à jour et bande passante disponible ;
- alimentation : une mise à jour interrompue par une coupure ne doit pas rendre l’appareil inutilisable — d’où les schémas à double partition ;
- absence d’interface utilisateur : comment informer et recueillir un refus ?
- parc déployé non joignable : comment atteindre un équipement derrière un réseau d’entreprise fermé ?
- durée de vie matérielle longue : la capacité de stockage doit absorber dix ans de correctifs.
Ces contraintes ne dispensent d’aucune exigence. Elles doivent être traitées dans l’analyse de risques et refléter dans les hypothèses d’environnement de sécurité communiquées à l’utilisateur.
Les preuves à produire
Description du mécanisme au dossier technique, procédure de gestion des clés, rapports de tests de mise à jour — y compris les tests d’échec et de retour arrière —, historique des publications et des messages consultatifs.