Les erreurs de configuration de Schrödinger

Nous sommes jeudi après-midi et vous vous apprêtez à quitter le travail un peu plus tôt parce que… vous le pouvez. Mais voilà que cet agaçant Distributeur de Notifications (autrement appelé Slack) fait surgir un nouveau message dans votre canal d’alertes de sécurité :

Eh bien, zut. Quelqu’un vient de rendre public un instantané d’un volume de stockage. S’agit-il d’une attaque ? D’une erreur ? De quelqu’un qui ne connaît tout simplement pas les politiques en vigueur ?

Les erreurs de configuration ont trois états d’existence

C’est ce que j’ai commencé à appeler les erreurs de configuration de Schröedinger car j’ai la mauvaise habitude de recourir aux principes de la mécanique quantique pour expliquer la sécurité de l’information. Je serais stupéfait que vous ne connaissiez pas déjà le chat de Schröedinger, la célèbre expérience de pensée qu’Erwin Schröedinger a utilisée pour illustrer le paradoxe de la superposition quantique auprès d’Albert Einstein. En version très courte : si vous enfermez un chat dans une boîte avec un poison déclenché par une désintégration radioactive, le chat n’est ni vivant ni mort, et se trouve donc dans un état où il est à la fois vivant ET mort, jusqu’à ce que vous ouvriez la boîte pour vérifier.

Oui, c’est absurde, et c’était bien là l’objectif. Surtout pour ceux d’entre nous qui ont des chats qui N’AIMENT PAS ÊTRE ENFERMÉS DANS DES BOÎTES. Je pourrais d’ailleurs consacrer toute une série d’articles aux chats qui se glissent d’eux-mêmes dans des boîtes mais se fâchent très fort si on les y met et… je m’égare.

Revenons à la sécurité du cloud. Le concept fondamental derrière cette expérience de pensée est qu’une chose existe dans plusieurs états simultanés jusqu’à ce que vous l’observiez, et que cet acte d’observation impose une réponse. Je déforme et simplifie bien sûr les choses pour les besoins de ma démonstration ; que ceux d’entre vous qui ont une formation en physique s’abstiennent donc de m’envoyer des e-mails furieux.

La version cloud de ce concept est la suivante : toute erreur de configuration existe dans un état où elle est à la fois une attaque, une erreur ou une violation de politique, jusqu’à ce que vous enquêtiez et en déterminiez la cause.

Cinq caractéristiques du cloud viennent étayer ce concept :

• Les équipes cloud et de développement disposent généralement d’une plus grande autonomie pour gérer directement leur propre infrastructure cloud.
• Le plan de gestion du cloud est accessible via Internet.
• La source la plus fréquente (aujourd’hui) d’attaques dans le cloud est le vol d’identifiants.
• De nombreuses erreurs de configuration créent des états identiques aux actions d’un attaquant (par exemple, rendre un instantané public).
• Il est facile de créer accidentellement une erreur de configuration ; parfois, elle est même intentionnelle pour répondre à un besoin, mais la personne qui agit ne réalise pas qu’il s’agit d’un problème de sécurité.

Ce concept reste valable dans une infrastructure traditionnelle, quoique dans une bien moindre mesure, puisque les équipes y ont moins d’autonomie. Un développeur travaillant sur une application n’a généralement pas la possibilité de modifier directement les règles de pare-feu et les tables de routage. Dans le cloud, c’est assez courant, du moins dans certains environnements.

Présumer l’attaque jusqu’à preuve du contraire

L’un des principes les plus importants de la réponse à incident dans le cloud est que vous devez absolument traiter les erreurs de configuration comme des événements de sécurité, et partir du principe qu’il s’agit d’attaques jusqu’à preuve du contraire.

C’est un changement de mentalité, car la sécurité a l’habitude de raisonner en termes de vulnérabilités et de surface d’attaque, mais nous considérons celles-ci comme des éléments à analyser périodiquement et, pour l’essentiel, comme des problèmes à corriger. Je propose que, dans le cloud computing, nous élevions les erreurs de configuration détectées au même rang qu’une alerte IDS ou EDR. Il ne s’agit pas de simples problèmes de conformité ; ce sont des indicateurs de compromission potentiels.

Et non, cela ne s’applique pas à toutes les erreurs de configuration dans tous les environnements. Nous devons filtrer et hiérarchiser. Mieux encore, nous devons communiquer, car le moyen le plus simple de déterminer si une erreur de configuration relève d’une attaque malveillante consiste généralement à demander à la personne qui a effectué la modification si elle avait bien l’intention de le faire.

Comme je dois synthétiser les choses pour mes formations, j’ai retenu trois principaux flux de télémétrie de sécurité :

• Les journaux
• Les événements du fournisseur cloud (par exemple, les événements Security Hub)
• Les erreurs de configuration cloud, qui peuvent provenir de votre outil CSPM, de scanners open source ou d’outils similaires

La plupart des personnes travaillant dans la sécurité du cloud ont déjà intégré ce concept, mais nous ne l’explicitons pas toujours. Si vous examinez certains outils de détection et de réponse dans le cloud (CDR), ils génèrent des alertes sur certaines erreurs de configuration. Cela diffère du mode de fonctionnement par défaut des outils CSPM, qui créent des constats dans des rapports et sur des tableaux de bord. Ces derniers sont importants pour la conformité et l’hygiène de sécurité générale, mais comme les attaquants font des choses déplaisantes telles que partager des images disque avec d’autres comptes ou créer des accès dérobés vers des rôles IAM, un sous-ensemble d’erreurs de configuration doit réellement être traité comme des indicateurs de compromission jusqu’à preuve du contraire.

En interne (et dans la plateforme DisruptOps), nous traitons cela avec un ensemble de détecteurs de menaces en temps réel qui déclenchent des évaluations à partir d’appels d’API identifiés. Il faut environ 15 à 30 secondes pour identifier une erreur de configuration et la transmettre à la sécurité et au responsable du projet via Slack (ou Teams), comme vous le voyez ci-dessus. Ces alertes sont traitées de la même façon qu’un constat GuardDuty ou tout autre indicateur de compromission, mais le recours au ChatOps pour valider les activités nous aide également à trier ces cas très rapidement, sans avoir à mener une analyse approfondie à chaque fois.

La recommandation en résumé : traitez les erreurs de configuration cloud critiques en temps quasi réel et considérez-les comme des indicateurs de compromission jusqu’à preuve du contraire.

Aucun chat n’a été maltraité lors de la rédaction de cet article.