Le dictionnaire nous dit que le risque est un danger éventuel, plus ou moins prévisible, inhérent à une situation ou à une activité. Une (ou un) CISSP vous dira qu'un risque se détermine par la possibilité qu'une menace spécifique porte atteinte à un bien en exploitant une vulnérabilité spécifique. Deux mots sont soulignés : menace et vulnérabilité. En l'occurrence, la menace est la manipulation des entrées DNS et la vulnérabilité est donc la faible sécurité du protocole DNS (DNS ID). Si la vulnérabilité est tout sauf nouvelle, son exploitation (que l'on peut qualifier d'élégante) par Kaminsky en change totalement les paramètres : c'est ici qu'intervient la gestion du risque (ou Risk management).

La gestion du risque est l'art d'identifier, de mesurer, de contrôler et de minimiser les pertes associées aux risques. Cette définition nous permet d'expliquer (sans le justifier) pourquoi cette vulnérabilité n'a pas été corrigée avant le battage médiatique de Kaminsky. Encore une fois, je ne souhaite pas revenir sur l'explication de la vulnérabilité DNS ni sur les considérations de BIEN et de MAL, mais à l'époque la note définie pour la faible résilience aux attaques du protocole DNS ne jouait pas en la faveur d'une pondération du risque. Pourquoi ? Il faut comprendre que le vecteur d'attaque n'était pas aussi évolué et que donc sa probabilité de succès était réduite. Les chercheurs en sécurité s'étant arrêtés à la démonstration de la faible sécurité du protocole. La charge utile qui était alors la modification d'un seul enregistrement (IN A) en réduisait également la portée. Par contre la perte de performance liée à la minimisation de la vulnérabilité était largement supérieure (perte de performance et donc augmentation du nombre de serveurs DNS nécessaires).

La métrique du risque inclut également l'exposition de l'entité. Il est bien évident qu'une petite société de poterie en boue du Kurdistan disposant de son propre cache DNS est moins exposée qu'une grande banque (sans préjuger des capacités concurrentielles du marché de la poterie en boue du Kurdistan).

Le choix avait été fait à l'époque, par beaucoup d'acteurs, de privilégier performances (et donc coûts) car la note du risque n'était pas suffisamment élevée (à tort ou à raison) pour justifier la perte engendrée par la minimisation de la vulnérabilité.

Avec Dan Kaminsky et sa curiosité, la métrique a dramatiquement changé et a poussé les principaux éditeurs de solution DNS à mettre en œuvre la solution de minimisation de la vulnérabilité tant repoussée (DJB doit être content). Le besoin de "patcher" est donc devenu réel et impérieux alors pourquoi cela n'est-il pas fait partout ? Passons rapidement sur les serveurs qui ne seront jamais "corrigés" car oubliés ou parce que leurs administrateurs n'ont pas connaissance de cette vulnérabilité ainsi que sur les geeks qui se sont empressés de faire un apt-get upgrade sur leur Dedibox.

Abordons le sujet plus intéressant des entreprises qui ont les compétences ainsi que les moyens pour appliquer les correctifs. Prenons une société fictive, PoC (Proof-of-Concept) qui vend une solution de cache DNS. Cette dernière a quelques centaines de milliers de clients et Noël approche. Quel est le risque de ne pas patcher ?

Il y en a certes plusieurs, mais nous nous contenterons du principal : les clients risquent d'être redirigés vers de faux sites. L'impact financier est évident : 1) les clients ou leurs banques risquent de se retourner vers la société et 2) les clients de la société PoC ne risquent pas de renouveler leur abonnement DNS Cache... Ces deux risques suffisent à eux seuls à justifier l'application immédiate des correctifs. Oui, mais... imaginons que la société PoC est à 90% de sa capacité DNS et que l'application des correctifs signifie un arrêt de service par tranche de 5 serveurs et qu'avec l'explosion de trafic sur les sites de livraison à domicile qu'entraîne le "rush" de Noël, toute interruption de service se traduirait par 1) des clients ne renouvelleraient pas leur abonnement et 2) des sociétés de vente par correspondance qui pourraient se retourner vers PoC pour la perte de chiffre d'affaire. Ne pas patcher entraîne les mêmes impacts, peu ou prou. Seules les probabilités d'occurrence changent.

Notre pauvre société PoC se trouve donc face à un dilemme Shakespearien (to patch now or not to patch now...). Que faire ? Il faut minimiser la vulnérabilité, cela ne fait aucun doute, mais comment selon quel agenda ? Il ne me semble pas que cela soit à un chercheur en sécurité d'en décider pour les entreprises (ou tout du moins croire qu'il peut le faire). Cet exemple nous permet de comprendre que dans le monde de la sécurité et de la gestion du risque, tout n'est pas blanc ou noir et qu'il est un peu facile de conclure que toutes les sociétés qui n'ont pas encore appliqué un correctif sont forcément incompétentes ou que tout le monde peut appliquer un correctif en deux jours ou même une semaine.

Le choix de Kaminksy et de son groupe fermé de garder le secret sur la nouvelle exploitation de la vulnérabilité aussi longtemps que possible (lire ici : aussi longtemps que possible afin de s'assurer une meilleure couverture à la Black Hat et donc publicitaire) est quelque peu gênant pour les grandes sociétés : sans connaissance de l'impact (et donc des détails de l'attaque de Kaminsky) pas d'analyse de risque et donc pas de métrique. Sans métrique pas de gestion du risque, donc toute décision éclairée est rendue impossible. Ces sociétés avancent donc à l'aveuglette. Il est très difficile pour un RSSI d'aller voir son président et de lui dire qu'il faut patcher parce que Deputy Dan  et ses amis ont dit qu'ils savaient ce qu'ils disaient (la réponse "On ne sait pas vraiment pourquoi, mais il paraît que c'est grave" n'étant jugée pertinente que par très peu de CEO surtout lorsqu'ils vont devoir signer un chèque).

C'est donc ici que s'applique ma principale critique : le manque de communication ainsi que ainsi que le buzz généré que je qualifierais, sinon d'irresponsable, de totalement injustifié. La sécurité est une chose, la gestion du risque en est une autre et n'en déplaise à Kaminsky, c'est elle qui est la règle lorsqu'on touche à des systèmes critiques. Si toute cette affaire doit réellement servir à quelque chose, gageons qu'elle permettra à certaines personnes de comprendre que publicité et sécurité ne font pas bon ménage et que la rétention d'information pave l'enfer des systèmes d’information.