Hypothèse de vulnérabilité : surveiller le comportement des microservices pour la sécurité

Dans un article publié sur le blog Kubernetes en janvier 2023, David Hadas, d'IBM Research Labs, a soutenu que les développeurs doivent accepter l'inévitable vulnérabilité inhérente à leurs microservices. Il a proposé de déplacer le focus de la construction de systèmes impénétrables vers la surveillance des anomalies comportementales qui signalent des tentatives d'exploitation.

Ce qui s'est passé

Les investissements dans la cybersécurité augmentent chaque année, mais le nombre d'incidents cyber réussis continue de croître. Hadas a noté que cette tendance suggère l'échec des stratégies traditionnelles visant à éliminer chaque faiblesse. Les outils offensifs deviennent plus sophistiqués, et les incitations financières pour les attaquants garantissent qu'ils trouveront toujours un point d'entrée si celui-ci existe. Par conséquent, compter sur la création d'un service totalement exempt de vulnérabilités n'est plus une stratégie viable.

L'article avance que les organisations devraient consciemment admettre que leurs services contiennent des faiblesses inconnues. Au lieu d'essayer de supprimer toutes les vulnérabilités, ce qui est souvent impossible en pratique, les équipes devraient se concentrer sur la prévention de leur exploitation. Si un attaquant ne peut pas exploiter avec succès une faiblesse, le risque reste théorique plutôt que réalisé. Ce changement de mentalité déplace le périmètre de défense de l'intégrité du code vers le comportement à l'exécution.

Hadas a introduit le concept d'« Analyse Comportementale de Sécurité » comme mécanisme principal de cette nouvelle approche. En analysant la façon dont les clients interagissent avec les services et dont les services répondent, les équipes peuvent détecter des irrégularités indiquant qu'une attaque est en cours. Cette méthode ne nécessite pas de connaître la vulnérabilité spécifique à l'avance ; elle exige seulement de reconnaître que l'interaction actuelle s'écarte des normes attendues.

Comment cela fonctionne

La surveillance comportementale de la sécurité repose sur la prévisibilité des interactions entre microservices. Dans un système bien conçu, les clients envoient des demandes régulières et structurées, et les services répondent de manière cohérente. Un exploit, tel qu'une injection SQL, force le système à se comporter de manière irrégulière. Par exemple, un client malveillant pourrait envoyer un nom d'utilisateur contenant des caractères spéciaux comme des espaces ou des signes égal, ce que les utilisateurs bénins ne font jamais. De même, le service pourrait mettre plus de temps à répondre ou renvoyer des jeux de données anormalement volumineux lors du traitement d'une telle demande.

En surveillant ces écarts, les outils de sécurité peuvent bloquer les attaques à plusieurs étapes. La surveillance côté client détecte les schémas de demandes irrégulières avant qu'elles n'atteignent la logique applicative. La surveillance côté service identifie les appels internes anormaux, les temps de réponse ou les sorties de données. La combinaison de ces deux couches crée une défense robuste qui rend de nombreuses vulnérabilités inexploitables, même si le code sous-jacent reste défaillant. L'attaquant doit concevoir un exploit qui imite parfaitement le comportement normal, ce qui est considérablement plus difficile que de trouver un bug de code.

Cette approche est particulièrement efficace dans les architectures de microservices par rapport aux monolithes. Les applications monolithiques entrelacent diverses fonctions, rendant difficile la distinction entre différents types de demandes et de comportements internes. Les microservices, par conception, ont des contextes limités et des interfaces claires. Cette modularité expose le trafic interne et définit des attentes strictes pour chaque composant, facilitant ainsi la détection d'anomalies dans des services spécifiques sans bruit provenant de processus non liés.

Détails clés

• L'article identifie quatre étapes de la vie d'un service nécessitant différentes stratégies de surveillance : fonctionnement normal, présence de CVE connues, disponibilité active d'exploits et mauvaise utilisation des pods.
• Pendant l'étape « Vulnérable », lorsqu'une CVE est publiée mais que le patching prend des semaines, la surveillance peut bloquer les demandes correspondant au modèle de vulnérabilité spécifique.
• À l'étape « Exploitable », les outils peuvent filtrer le trafic entrant basé sur des signatures d'exploits connus pour empêcher leur exécution.
• Si un contrevenant abuse d'un pod, le système peut identifier l'instance compromise et la redémarrer tout en maintenant les pods sains en activité.
• Guard, un projet open source sous l'égide du projet Knative de la CNCF, est cité comme un outil fournissant cette surveillance comportementale de sécurité autonome pour les charges de travail HTTP de Kubernetes.
• L'architecture de microservices est intrinsèquement mieux adaptée à cette surveillance car sa nature modulaire expose des limites claires et des schémas d'interaction prévisibles.

Pourquoi c'est important

Pour les ingénieurs logiciels et les responsables techniques, cette perspective réduit la pression pour atteindre une sécurité de code parfaite, un objectif souvent irréaliste. Elle met plutôt l'accent sur la résilience opérationnelle. En acceptant que des vulnérabilités existeront, les équipes peuvent prioriser la construction de mécanismes de détection et de réponse dans leur infrastructure. Cela s'aligne avec les principes Zero Trust, où la confiance n'est jamais supposée et la vérification est continue.

La mise en œuvre d'une sécurité basée sur le comportement change également la façon dont les équipes perçoivent la réponse aux incidents. Plutôt que d'attendre un correctif pour résoudre une CVE connue, elles peuvent déployer des règles comportementales pour atténuer la menace immédiatement. Cela permet aux services de rester en ligne et fonctionnels pendant que les équipes de sécurité traitent la cause racine. Cela transforme la sécurité d'une fonction de gardiennage en une protection opérationnelle continue.

De plus, cette approche tire parti des avantages existants des microservices. Les équipes investissent déjà dans l'observabilité et la surveillance pour des raisons de performance. Étendre ces outils pour inclure l'analyse comportementale de sécurité ajoute une couche de protection sans nécessiter une refonte architecturale complète. Cela transforme les données de télémétrie standard en un actif de sécurité, faisant payer doublement l'investissement dans l'observabilité.

Ce que vous pouvez faire

• Auditez votre configuration de surveillance actuelle pour vérifier si elle capture les métadonnées détaillées des demandes et réponses nécessaires à l'analyse comportementale.
• Définissez les comportements de base pour vos microservices critiques, y compris les structures typiques de demandes, les temps de réponse et les volumes de données.
• Implémentez des alertes pour les écarts par rapport à ces bases, tels que des jeux de caractères inhabituels dans les champs d'entrée ou des pics dans la taille des charges utiles de réponse.
• Explorez des outils comme Guard du projet Knative pour ajouter une surveillance comportementale de sécurité dédiée à vos clusters Kubernetes.
• Développez des playbooks pour redémarrer automatiquement les pods compromis lorsque l'abus est détecté, assurant la continuité de service.
• Faites évoluer les revues de sécurité vers des analyses de conformité comportementale plutôt que uniquement statiques.