HEIST est-il un risque ou une menace ?

Les professionnels de la sécurité ont pour mission de comprendre la différence entre les risques et les menaces et d’agir en conséquence. Pour le profane (c’est-à-dire la plupart d’entre nous), la différence entre les deux peut paraître inexistante. Après tout, ne sont-ils pas sémantiquement équivalents ? Ne les utilisons-nous pas de manière interchangeable pour décrire les vulnérabilités, les attaques DDoS et le dernier exploit zero-day ?

C’est possible, mais les professionnels de la sécurité sont souvent beaucoup plus précis que cela, principalement parce que s’ils ne l’étaient pas, leurs budgets dépasseraient ceux de l’ensemble de l’informatique alors qu’ils mèneraient une guerre numérique contre le stock croissant d’outils, de techniques et de technologies utilisés pour vaincre leurs défenses. C’est parce que toutes les menaces ne comportent pas le même risque.

Le risque est une mesure calculée impliquant un certain nombre de facteurs, notamment la probabilité d’occurrence et l’impact en cas d’exploitation. Nous savons tous que nous pourrions être heurtés par un bus et subir de graves conséquences en traversant la route aujourd’hui, mais la probabilité que cela se produise est si faible que la plupart d’entre nous considèrent qu’il s’agit d’un risque très faible (si tant est qu’il soit mesuré sur notre indicateur de risque). À l’inverse, porter des talons de trois pouces sans semelle au milieu d’un hiver dans le Wisconsin présente une forte probabilité de chute avec des conséquences défavorables, c’est pourquoi je considère personnellement qu’il s’agit d’un risque assez élevé pendant les mois d’hiver.

C’est un risque.

Les menaces sont autre chose. Il y a aussi quelque chose que nous ne pouvons pas contrôler, comme la météo, les itinéraires de bus ou la décision d'un attaquant de lancer une attaque volumétrique sur notre site Web aujourd'hui.

L’un des objectifs des professionnels de la sécurité et de leurs organisations est de minimiser les risques en atténuant les menaces et en réduisant la probabilité d’un exploit. S’il fait -20 degrés et que l’allée est recouverte de glace, je porte des bottes plates et bien cramponnées. La menace est atténuée (mais pas éliminée) et donc le risque est réduit.  Si une nouvelle vulnérabilité est soudainement découverte, je dois décider quel risque cette nouvelle menace représente pour mon organisation.

En fait, cette méthodologie d’évaluation des risques est tellement acceptée que l’industrie la décrit mathématiquement :

A(sset) + V(ulnérabilité) + T(menace) = R(isk)

Cela permet aux organisations individuelles non seulement de pondérer les facteurs individuels en fonction de leurs besoins commerciaux et de leur tolérance au risque, mais également d'agir de manière cohérente. Cela peut permettre d’éviter des réactions de panique et instinctives lorsque de nouvelles vulnérabilités sont annoncées, en particulier si le risque évalué s’avère inférieur aux tolérances organisationnelles.

Et alors, qu'en est-il de HEIST ?

Ce qui nous amène à HEIST, qui signifie HTTP Encrypted Information can be Stolen through TCP-Windows. HEIST est évidemment beaucoup plus facile à prononcer et ressemble à Mission Impossible, n'est-ce pas ? Cette vulnérabilité a été présentée à BlackHat et fait encore son chemin sur Internet dans des articles sur Ars Technica et Engadget . Jusqu’à présent, il n’a pas été aperçu dans la nature. Ce n’est pas une vulnérabilité simple à exploiter et les chercheurs, y compris les nôtres, notent que ce n’est pas une tâche triviale d’exploiter HEIST. Il s'agit d'une attaque complexe par canal auxiliaire qui combine le comportement de l'API du navigateur (elle observe la manière dont TCP fonctionne normalement avec une API de navigateur qui peut chronométrer les réponses), le comportement de application Web, la compression de contenu, TCP et la cryptographie.

Cette attaque peut être lourde en termes de réseau si plusieurs requêtes doivent être traitées, mais elle est mieux adaptée à la catégorie « bruyante ». Les deux ne sont pas attrayants pour les mauvais acteurs qui ne veulent pas se faire remarquer. Et pourtant, si cette faille est exploitée avec succès, les attaquants pourraient la combiner avec BREACH ou CRIME pour décrypter les charges utiles et décrocher le jackpot numérique proverbial, exposant ainsi des données personnelles et commerciales sensibles (peut-être critiques). Dans ce cas, ils ne se soucieraient probablement pas de leur niveau de bruit s’ils parvenaient à obtenir des informations personnelles identifiables (PII) – le jackpot numérique.

C'est une menace. Il pourrait être utilisé pour exfiltrer des données. C’est ce qu’on appelle une violation et c’est une très mauvaise chose™. La question est : quand cette menace devient-elle un risque réel ?

Eh bien, aujourd’hui (quand j’écrivais ceci, pour être précis), cette menace n’était pas existentielle. C’est-à-dire qu’on ne l’avait jamais vu dans la nature. Mais cela ne veut pas dire qu’il n’est pas dans la nature, cela veut juste dire qu’il n’a pas été vu dans la nature. Encore. Aujourd'hui. Tout de suite.

La tête tourne déjà ? Vous savez maintenant pourquoi les professionnels de la sécurité semblent toujours avoir un air abasourdi. Parce qu’ils doivent gérer ce genre de processus de réflexion et de prise de décision en permanence. 

La question devient alors : si cette menace devient existentielle, quel est le risque ? Pour répondre à cette question, vous devez déterminer quel serait l’impact si la vulnérabilité était exploitée. Si quelqu’un parvient à exfiltrer des données de votre application, de votre site, quel est l’impact ? Quel sera votre coût ? N’oubliez pas d’inclure l’impact de la marque, cela fait partie de l’équation (de plus en plus complexe). Il en va de même pour le coût de l’atténuation. L’équation change lorsque le coût de l’atténuation est élevé par rapport à une solution à impact relativement faible. Si vous devez toucher à 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 d’« attentisme » plutôt que de vous précipiter parce que le garçon a crié « au loup ».

Si l'atténuation a un impact relativement faible en termes de coûts de mise en œuvre, par exemple un simple script qui déroute l'attaquant en faisant varier la taille des données renvoyées et rendant ainsi HEIST plus difficile à réaliser, vous pouvez envisager d'aller de l'avant et de le mettre en place. Après tout, le coût d’une réduction encore plus importante des risques était minime, et il est presque certainement bien inférieur aux conséquences si le HEIST était réalisé à l’avenir.

Un (ré)équilibrage constant

La réalité est que la sécurité est une bataille constante pour minimiser les risques en atténuant les menaces tout en pataugeant dans le champ de mines politique que constituent la plupart des organisations informatiques. Trop souvent, les professionnels de la sécurité décident de ne pas faire l’effort de mettre en œuvre même des mesures d’atténuation simples pour les menaces dont la probabilité de risque est variable, car l’informatique existe dans des silos de fonctionnalités.

Ils attendent que le risque augmente et forcent une réaction, plutôt que d’atténuer la menace de manière proactive. Par exemple, la plupart des exploits dont on a le plus parlé au cours des deux dernières années étaient axés sur les application . Pour les atténuer, des solutions doivent être déployées dans le chemin des données, en amont de l’ application, car l’emplacement le plus efficace et le plus efficient pour le faire reste le point où les applications sont finalement agrégées pour la mise à l’échelle et la livraison. Mais ce point de contrôle stratégique est géré par les équipes de distribution application , et non par les équipes de sécurité. L’effort requis pour atténuer ces menaces dès le début est supérieur au risque. Étant donné que la capacité des deux groupes à se rencontrer au milieu, pour ainsi dire, reste un défi constant pour les organisations, il n'est tout simplement pas possible de réduire de manière proactive les risques et d'atténuer les menaces au niveau de la couche application .

HEIST est, à l’heure actuelle, probablement considéré comme un risque faible pour la plupart des organisations. Mais ne vous y trompez pas, c’est une menace, et elle mérite donc d’être prise en considération maintenant, alors que nous avons tous été informés de son existence avant qu’elle ne soit mise en œuvre. Une coordination croisée est nécessaire pour que des solutions de sécurité « sans serveur » telles que cette atténuation pour HEIST puissent être déployées avant que la menace ne devienne existentielle et que le risque d’exploitation ne pousse tout le monde dans une frénésie d’activités et de mises en œuvre coûteuses pour y faire face.