HEIST est-il un risque ou une menace ?

Lori Mac VittieIngénieur émérite et évangéliste en chef | F5

Les professionnels de la sécurité doivent comprendre la différence entre les risques et les menaces et agir en conséquence. Pour le profane (c’est-à-dire la plupart d’entre nous), cette différence peut sembler inexistante. Après tout, ces deux termes ne sont-ils pas sémantiquement équivalents ? Ne les employons-nous pas indifféremment pour parler des vulnérabilités, des attaques DDoS et de la toute dernière exploitation d’une faille zero-day ?

C’est possible, mais les professionnels de la sécurité se montrent souvent bien plus précis, principalement parce que, dans le cas contraire, leurs budgets dépasseraient ceux de l’ensemble du service informatique tandis qu’ils mèneraient une guerre numérique contre l’arsenal croissant d’outils, de techniques et de technologies utilisés pour contourner leurs défenses. En effet, toutes les menaces ne présentent pas le même niveau de risque.

Le risque est une mesure calculée qui tient compte de plusieurs facteurs, notamment la probabilité qu’un événement se produise et les conséquences qu’aurait son exploitation. Nous savons tous qu’en traversant la rue aujourd’hui, nous pourrions nous faire renverser par un bus et en subir de graves conséquences. Toutefois, la probabilité que cela se produise est si faible que la plupart d’entre nous considèrent ce risque comme très faible, à supposer même qu’il soit détecté par notre « baromètre du risque ». À l’inverse, porter des talons de huit centimètres sans semelles antidérapantes en plein hiver dans le Wisconsin présente une forte probabilité de chute aux conséquences fâcheuses. Personnellement, je considère donc que le risque est assez élevé pendant les mois d’hiver.

C’est ça, le risque.

Les menaces, c’est autre chose. Quelque chose que nous ne pouvons pas contrôler, comme la météo, les lignes de bus ou la décision d’un attaquant de lancer aujourd’hui une attaque volumétrique contre notre site web.

L’un des objectifs des professionnels de la sécurité et de leurs organisations est de réduire au minimum les risques en atténuant les menaces et en diminuant la probabilité qu’une vulnérabilité soit exploitée. S’il fait -20 °C et que l’allée est verglacée, je porte des bottes plates dotées de semelles bien crantées. La menace est atténuée (mais pas éliminée), ce qui réduit le risque. Si une nouvelle vulnérabilité est soudainement découverte, je dois déterminer le risque que cette nouvelle menace représente pour mon organisation.

En fait, cette méthodologie d’évaluation des risques est si largement reconnue que le secteur la décrit sous forme mathématique :

A(ctif) + V(ulnérabilité) + M(enace) = R(isque)

Cela permet à chaque organisation non seulement de pondérer les différents facteurs en fonction de ses impératifs métier et de sa tolérance au risque, mais aussi d’agir de manière cohérente. Cela peut éviter les réactions de panique et les décisions précipitées lors de l’annonce de nouvelles vulnérabilités, en particulier si le risque évalué s’avère inférieur aux seuils de tolérance de l’organisation.

Et qu’en est-il de HEIST ?

Ce qui nous amène à HEIST, acronyme de « HTTP Encrypted Information can be Stolen through TCP-Windows » (les informations HTTP chiffrées peuvent être dérobées par le biais des fenêtres TCP). HEIST est évidemment beaucoup plus facile à prononcer et évoque un peu Mission Impossible, n’est-ce pas ? Cette vulnérabilité a été présentée à la BlackHat et fait actuellement le tour d’Internet, notamment dans des articles publiés par Ars Technica et Engadget. Jusqu’à présent, elle n’a pas été observée dans la nature. Cette vulnérabilité n’est pas simple à exploiter, et les chercheurs — y compris les nôtres — soulignent que l’exploitation de HEIST est loin d’être triviale. Il s’agit d’une attaque complexe par canal auxiliaire qui combine le comportement des API de navigateur (elle observe le fonctionnement habituel de TCP à l’aide d’une API de navigateur capable de mesurer le temps de réponse), le comportement des applications web, la compression du contenu, TCP et la cryptographie.

Cette attaque pourrait générer un trafic réseau important si plusieurs requêtes doivent être effectuées, mais elle relève surtout de la catégorie des attaques « bruyantes ». Ces deux caractéristiques sont peu attrayantes pour les acteurs malveillants qui ne veulent pas se faire repérer. Pourtant, si elle était exploitée avec succès, les attaquants pourraient la combiner avec BREACH ou CRIME pour déchiffrer les charges utiles et décrocher le proverbial gros lot numérique, en exposant des données personnelles et professionnelles sensibles, voire critiques. Dans ce cas, ils se soucieraient probablement peu du bruit généré s’ils parvenaient à obtenir des informations personnelles identifiables (PII) — le gros lot numérique.

Il s’agit d’une menace. Elle pourrait être utilisée pour exfiltrer des données. C’est ce qu’on appelle une fuite de données, et c’est une Très Mauvaise Chose™. La question est de savoir à quel moment cette menace devient un risque réel.

Eh bien, aujourd’hui (au moment où j’écris ces lignes, pour être précis), cette menace n’était pas avérée. Autrement dit, elle n’avait pas encore été observée dans la nature. Mais cela ne signifie pas qu’elle n’y est pas présente, simplement qu’elle n’y a pas encore été observée. Pas encore. Aujourd’hui. À l’heure actuelle.

Vous avez déjà la tête qui tourne ? Vous comprenez maintenant pourquoi les professionnels de la sécurité ont toujours l’air un peu hébété. C’est parce qu’ils doivent constamment gérer ce type de réflexion et de prise de décision.

La question est donc la suivante : si cette menace devient existentielle, quel est le risque ? Pour y répondre, vous devez déterminer quelles seraient les conséquences si la vulnérabilité était exploitée. Si quelqu’un parvient à exfiltrer des données de votre application ou de votre site, quelles en seraient les répercussions ? Combien cela vous coûterait-il ? N’oubliez pas de prendre en compte l’impact sur votre image de marque : cela fait partie de l’équation, qui devient de plus en plus complexe. Il en va de même pour le coût des mesures d’atténuation. L’équation change lorsque ce coût est élevé par rapport à une solution ayant un impact relativement faible. Si vous devez intervenir sur chaque serveur web du centre de données — et du cloud — pour modifier un seul paramètre afin d’atténuer la menace, cela représente beaucoup de temps, et donc d’argent, pour quelque chose qui pourrait constituer une menace existentielle. Si le risque est faible, vous adopterez probablement une attitude compréhensible consistant à « attendre de voir », plutôt que de vous précipiter parce que quelqu’un a crié au loup.

Si la mesure d’atténuation est relativement peu coûteuse à mettre en œuvre — par exemple, un simple script qui déroute l’attaquant en faisant varier la taille des données renvoyées, rendant ainsi l’attaque HEIST plus difficile à exécuter —, vous pourriez envisager de la déployer. Après tout, le coût d’une réduction supplémentaire du risque est minime et presque certainement bien inférieur aux conséquences qu’aurait une telle attaque HEIST si elle était menée à l’avenir.

Un exercice de (ré)équilibrage permanent

En réalité, la sécurité est un combat permanent visant à réduire les risques en atténuant les menaces, tout en naviguant dans le champ de mines politique que constituent la plupart des services informatiques. Trop souvent, les professionnels de la sécurité renoncent à mettre en œuvre des mesures d’atténuation, même simples, face à des menaces dont la probabilité varie, car les fonctions informatiques sont cloisonnées.

Elles attendent que le risque augmente et les contraigne à réagir, au lieu d’atténuer la menace de manière proactive. Par exemple, bon nombre des exploits les plus commentés de ces deux dernières années ciblaient les applications. Pour les contrer, des solutions doivent être déployées sur le chemin des données, en amont de l’application, car l’emplacement le plus efficace reste le point où les applications sont finalement regroupées afin d’assurer leur mise à l’échelle et leur distribution. Or, ce point de contrôle stratégique est géré par les équipes chargées de la distribution des applications, et non par les équipes de sécurité. Les efforts nécessaires pour atténuer ces menaces en amont sont jugés disproportionnés par rapport au risque. Comme la capacité des deux groupes à trouver un terrain d’entente reste un défi permanent pour les organisations, la réduction proactive des risques et l’atténuation des menaces au niveau de la couche applicative ne se concrétisent tout simplement pas.

À l’heure actuelle, HEIST est probablement considéré comme présentant un faible risque pour la plupart des organisations. Mais ne vous y trompez pas : il s’agit bien d’une menace, qui mérite donc d’être prise en compte dès maintenant, alors que nous avons tous été avertis de son existence avant qu’elle ne soit mise à exécution. Une coordination entre les différentes équipes est nécessaire afin que des solutions de sécurité « sans serveur », comme cette mesure d’atténuation contre HEIST, puissent être déployées avant que la menace ne devienne existentielle et que le risque d’exploitation ne pousse tout le monde à se lancer dans une frénésie d’activités et de déploiements coûteux pour y remédier.

À propos de l’auteur

Lori Mac VittieIngénieur émérite et évangéliste en chef | F5

Lori MacVittie est ingénieure émérite et évangéliste en chef au sein du bureau du directeur technique de F5. Elle possède une expertise approfondie dans la fourniture d’applications, les stratégies d’automatisation et les infrastructures. Elle est réputée pour sa capacité à rendre la complexité intelligible, qu’elle définisse des garde-fous pour les agents d’IA, analyse des architectures multicloud fragiles ou explore les limites des systèmes évolutifs. Elle cumule plus de trente ans d’expérience dans le secteur, couvrant le développement d’applications, l’architecture informatique ainsi que l’exploitation des réseaux et des systèmes. Avant de rejoindre F5, elle a été rédactrice spécialisée dans les technologies et a reçu plusieurs distinctions. MacVittie est titulaire d’un master en informatique et est une autrice prolifique dont les publications couvrent la sécurité, le cloud et l’architecture d’entreprise. Elle est également une passionnée de jeux de société et de jeux vidéo, et assume pleinement ses avis bien tranchés sur le fromage.

Autres articles de Lori Mac Vittie