Hearbleed défraie les manchettes depuis la semaine dernière, mais déjà la nouvelle a fait son petit bout de chemin. En commençant par les excuses du malheureux programmeur derrière l’erreur de programmation responsable de la vulnérabilité. Les rapports préliminaires laissaient penser à d’une porte dérobée, placée délibérément à l’intérieur du code d’OpenSSL, mais les origines du bogue semblent finalement tout à fait banales.
Une autre hypothèse discutée est que la NSA connait l’existence de Heartbleed depuis un certain temps déjà, mais a décidé de ne pas en avertir les développeurs et le grand public. C’est du moins ce que laisse entendre cet article qui prétend que l’agence américaine avait identifié le bogue dès son introduction malencontreuse en début 2012, et l’exploitait depuis à ses propres fins. Des accusations que la NSA s’est empressée de démentir, mais la réputation de l’organisation étant ce qu’elle est depuis un an, mon petit doigt me dit qu’un simple communiqué ne sera pas suffisant pour convaincre les sceptiques.
Qu’elle soit véridique ou non, cette accusation ramène sur le tapis une question intéressante, que plusieurs commentateurs n’ont d’ailleurs pas hésité à soulever: la NSA (ou les autres agences de renseignement ayant de semblables activités) devrait-elle dévoiler publiquement les vulnérabilités logicielles découvertes par ses employés dans l’exercice de leur travail? C’est un problème fort épineux et qui met en lumière les différents objectifs des deux cultures impliquées.
Pour les professionnels de la sécurité informatique, les bonnes pratiques en matière de traitement des vulnérabilités logicielles font l’objet de discussions depuis plusieurs années. La plupart des développeurs ont depuis adopté des processus encadrant la découverte des vulnérabilités, leur divulgation, la production des correctifs appropriés et leur distribution et installation chez les utilisateurs. La philosophie promulguée par la communauté à travers ces pratiques en est une de transparence: les nouvelles vulnérabilités affectant un logiciel doivent être communiquées rapidement à tous, afin que les propriétaires et utilisateurs de système puissent prendre les mesures nécessaires pour protéger leur information contre le risque encouru. Parfois, un court laps de temps est laissé aux développeurs afin qu’ils soient en mesure de produire le correctif nécessaire et éviter une trop longue période de temps entre la divulgation de la vulnérabilité au public et la disponibilité d’un correctif. En contrepartie, les entreprises sont sévèrement blâmées s’ils tardent à procéder à cette divulgation pour des raisons d’image – ce qui arrive encore de temps en temps.
Cette approche n’a évidemment du sens que dans un contexte où les acteurs cherchent à se défendre contre des attaques utilisant ces vulnérabilités. Les cybercriminels, qui ont leur propre raison de découvrir et d’exploiter des vulnérabilités logicielles, n’ont évidemment aucun avantage à se plier à ces bonnes pratiques; au contraire, ils cherchent à garder secrètes ces vulnérabilités le plus longtemps possible.
Les objectifs des agences de renseignement s’apparentent à la fois à ceux des professionnels en sécurité et des cybercriminels. Dans le contexte de la sécurité informatique, leur mission est à la fois de protéger l’infrastructure stratégique de leur pays face à l’espionnage international, mais également d’effectuer des opérations clandestines à l’étranger visant à recueillir de l’information jugée d’importance stratégique, souvent confidentielle.
C’est pour cette seconde mission, dite offensive (connue en anglais par le terme « offensive security », ou OFFSEC) que les agences de renseignement ont développé au cours des dernières années l’expertise interne nécessaire à l’identification et l’exploitation de vulnérabilités logicielles inédites. Ces vulnérabilités ne sont pas communiquées aux développeurs; plutôt, on les garde secrètes dans le but ultime de les utiliser pour exploiter des cibles, généralement étrangères. Stuxnet, le ver qui a infecté les centrifugeuses nucléaires iraniennes il y a quelques années, utilisait des vulnérabilités jusqu’alors inconnues du grand public car jamais dévoilées. D’une grande complexité, il a probablement été développé par les services Américains et Israéliens.
Évidemment, ces agences pourraient très bien communiquer leurs découvertes aux développeurs de logiciel, et ainsi participer à la philosophie de transparence en gestion des vulnérabilités mentionnée plus haut. La NSA pourrait ainsi aider l’industrie du logiciel commercial à rendre leurs produits plus sécuritaires qu’ils ne le sont présentement, et contribuer de façon positive à la communauté. C’est certainement ce qu’un grand nombre de professionnels en sécurité souhaitent. Cela dit, il y a peu de chance que ça arrive.
D’un point de vue offensif, et tel que mentionné plus haut, publier ces vulnérabilités diminue leur valeur. Une agence de renseignement désire pouvoir se fier à des vulnérabilités encore inédites pour infiltrer un système d’information étranger avant que les correctifs applicables ne soient conçus et installés. C’est une tâche qui devient plus difficile du moment où la cible est mise au courant du risque pour sa sécurité.
D’un point de vue défensif, c’est plus compliqué. Les agences de renseignement, en adoptant un rôle dans la recherche de vulnérabilité pour le compte de l’industrie logicielle, se retrouveraient également à faire un travail qui n’est, à la base, pas le leur. C’est normalement aux développeurs que revient la tâche de s’assurer que les logiciels vendus sont exempts de vulnérabilités. Comme c’est un objectif qui s’avère difficile à atteindre, on s’attend à ce que ces entreprises soient réceptives face aux vulnérabilités trouvées sur leurs produits par des chercheurs indépendants; certaines d’entre elles allant jusqu’à offrir des primes pour les cas les plus sérieux. Est-ce une si bonne idée de demander à une organisation comme la NSA de s’introduire (gratuitement?) dans cet écosystème, surtout lorsque ce sont tous les acteurs internationaux qui en bénéficieraient, puisqu’ils utilisent souvent les mêmes produits? Si un gouvernement désire diminuer le nombre de vulnérabilités présentes dans les produits informatiques (ce qui est, en soi, un objectif fort valable), il devrait probablement s’y prendre autrement, en stimulant la sécurité de l’information à même l’industrie logicielle par exemple, ce qui serait probablement plus efficace et moins coûteux pour tout le monde, et ne mettrait pas la NSA en conflit d’intérêts.
Face à la grogne engendrée par le silence de la NSA sur des vulnérabilités connues, mais non divulguées, l’administration Obama a récemment suggéré d’obliger le service de renseignement à publier ses découvertes… sauf lorsqu’elles présentent un enjeu national stratégique pour les ÉU. Compte tenu de la difficulté à déterminer ce qui devrait être un enjeu et ce qui ne l’est pas, ce n’est pas une proposition qui risque de changer les habitudes. Cela pourrait quand même les inciter à dévoiler les vulnérabilités qui ne leur sont plus utiles: celles dont on soupçonne la publication imminente ou quand d’autres vulnérabilités, plus efficaces et insidieuses, sont déjà connues et utilisées, rendant la nouvelle superflue du point de vue des agences de renseignements.
Finalement, une troisième option s’offre, qui est peut-être déjà sur le bout de votre langue si vous vous êtes rendu jusqu’ici dans votre lecture: celle de demander aux agences de renseignement de complètement se retirer de la recherche en vulnérabilités logicielles. C’est une proposition qui en cache en fait une autre: celle de leur interdire tout simplement d’effectuer des opérations offensives. Pour diverses raisons, je ne pense pas qu’on doit s’attendre à ce que ça arrive de sitôt… mais il s’agit d’un tout autre sujet, que je vais me réserver pour une discussion future.
Cryptique César! 