Exemple STRIDE : une passerelle industrielle
Sytance · Mis à jour
STRIDE utilise six catégories de menaces pour examiner comment un système pourrait être attaqué. La passerelle industrielle fictive ci-dessous illustre, pour chaque catégorie, un scénario, une mesure de maîtrise proposée et un critère de test. Ces exemples décrivent des attaques possibles et des tests prévus.
La passerelle et ses frontières de confiance
Un opérateur utilise un navigateur pour appeler l’API d’administration de la passerelle. L’API lit et écrit dans un magasin de configuration local. Un contrôleur local envoie des données opérationnelles à la passerelle, qui transmet la télémétrie à un service distant. Un service de mise à jour distinct fournit les paquets de micrologiciel.
Dans cet exemple, les connexions d’administration et de télémétrie utilisent TLS. L’authentification de l’interface du contrôleur et le mécanisme de confiance des mises à jour restent des questions de conception ouvertes. Le fait d’être situé sur un réseau local n’établit pas à lui seul l’identité ou l’autorité de l’émetteur.
- Navigateur → API d’administration : sessions, demandes d’état et modifications de configuration.
- API d’administration → magasin de configuration : paramètres stockés et accès aux secrets.
- Contrôleur local → passerelle : données opérationnelles provenant du réseau du site.
- Passerelle → service de télémétrie : identité du dispositif et données de télémétrie.
- Service de mise à jour → passerelle : métadonnées du paquet et contenu du micrologiciel.
Usurpation d’identité sur l’interface du contrôleur
Un attaquant présent sur le réseau du site envoie des messages prétendant provenir du contrôleur local. Si la passerelle se fie uniquement à une adresse source, des données opérationnelles falsifiées peuvent entrer dans le flux de télémétrie.
Mesure proposée : établir l’identité du dispositif et la vérifier avant d’accepter des messages. Si le contrôleur ne prend pas en charge l’authentification, évaluer d’autres moyens de protéger l’interface ainsi que les attaques qui restent possibles. Un segment réseau ne prouve pas à lui seul l’origine d’un message.
Critère de vérification : les messages provenant d’une identité de test non reconnue sont rejetés, tandis que ceux du contrôleur autorisé continuent de fonctionner. Enregistrez le rejet et confirmez que la valeur falsifiée n’a pas atteint le service de télémétrie.
Altération du micrologiciel avant installation
Un attaquant remplace un paquet obtenu par l’intermédiaire d’un point de distribution compromis. Le chiffrement du transport jusqu’à ce point ne prouverait pas que le paquet a été autorisé par le fabricant.
Mesure proposée : vérifier la signature du paquet à l’aide d’une ancre de confiance autorisée avant l’installation. Lier la vérification aux octets effectivement installés et au produit autorisé. Définir séparément le traitement des anciennes versions signées et des clés de signature révoquées.
Critère de vérification : un paquet altéré et un paquet signé avec une clé non fiable sont rejetés avant l’installation. Après ce rejet, la passerelle doit rester dans l’état de fonctionnement ou de récupération spécifié.
Modifications de configuration non traçables
Un opérateur autorisé modifie la destination de la télémétrie, mais l’enregistrement ne contient ni identité individuelle ni résultat. L’équipe ne peut pas attribuer la modification de manière fiable ni distinguer une écriture réussie d’une demande rejetée.
Mesure proposée : consigner l’identité authentifiée, l’action, la cible, l’heure et le résultat. Protéger l’accès aux journaux et définir le comportement lorsque le stockage est saturé. Ne pas inscrire de mots de passe ni de jetons d’accès dans les journaux.
Critère de vérification : une modification contrôlée génère un enregistrement correspondant, un utilisateur non autorisé ne peut pas le modifier et le comportement d’audit lorsque le stockage est saturé correspond à la politique documentée.
Secrets exposés par les lectures de configuration
Un point de terminaison d’état renvoie l’objet de configuration complet, y compris l’identifiant d’accès à la télémétrie. Un utilisateur autorisé à consulter l’état reçoit des informations dont son rôle n’a pas besoin.
Mesure proposée : renvoyer une réponse adaptée à l’objectif, sans champs secrets, et appliquer les autorisations aux lectures de configuration. Le chiffrement en transit n’empêche pas une réponse contenant trop de données.
Critère de vérification : examinez les réponses associées à chaque rôle pris en charge et confirmez qu’aucune valeur secrète n’apparaît dans les réponses, les erreurs ou les journaux.
Le traitement des entrées épuise les ressources de la passerelle
Un émetteur transmet des messages de contrôleur surdimensionnés ou répétés. Leur analyse et leur mise en mémoire tampon consomment des ressources dont la passerelle a également besoin pour l’administration et la télémétrie.
Mesure proposée : limiter la taille des messages et des files d’attente, valider les entrées avant toute opération coûteuse et isoler le traitement critique. Définir les limites à partir de la capacité mesurée et du comportement requis du produit en situation de surcharge.
Critère de vérification : dans un environnement de test autorisé, exécutez les scénarios de surcharge convenus et observez la mémoire, la profondeur des files d’attente, la disponibilité des services et la récupération. Les limites d’acceptation découlent des exigences de ce produit ; aucun débit universel n’est présumé.
Un utilisateur en lecture seule accède à une opération d’écriture
Un utilisateur peut se connecter et consulter l’état. Il appelle directement une API d’écriture de la configuration en contournant l’interface. Si l’API vérifie seulement l’authentification, l’utilisateur obtient une capacité réservée aux administrateurs.
Mesure proposée : appliquer côté serveur les autorisations relatives aux actions et aux ressources pour chaque voie d’écriture. Appliquer la même règle aux demandes normales, aux opérations en masse et aux points de terminaison de maintenance.
Critère de vérification : les demandes d’écriture directes d’un compte en lecture seule échouent et la configuration enregistrée reste inchangée. Répétez le test avec un compte autorisé afin de vérifier que l’opération prévue reste possible.
Couverture et risques résiduels
Les six catégories suivent les définitions STRIDE de Microsoft. Les scénarios d’attaque et les mesures de maîtrise dépendent de l’architecture de la passerelle décrite ci-dessus.
Un produit réel peut comporter plusieurs scénarios d’attaque dans une même catégorie, et une attaque peut relever de plusieurs catégories. Si le produit en comporte, l’analyse doit aussi couvrir les interfaces de fabrication, de maintenance et de récupération.
Après la mise en œuvre et le test d’une mesure de maîtrise, évaluez les attaques qui restent possibles au regard des critères de risque convenus. La décision obtenue s’applique à la version du produit analysée.