Il est un concept relativement simple, voire évident, qu'on désigne par le terme barbare de "fail safe". C'est quand le plantage d'un équipement ou d'une fonction ne porte pas atteinte aux propriétés essentielles votre système. Selon votre domaine d'application et vos priorités, cette propriété se déclinera sur différents axes. En particulier, quand vous vous lancez dans la sécurité, c'est une des toutes premières choses que vous allez apprendre. Le plantage d'un équipement de sécurité, ou d'un de ces services, ne doit pas porter atteinte à votre niveau de protection. Comprendre par là que la protection offerte par l'équipement ne doit pas diminuer ou s'évaporer. Typiquement, dans le cas d'un firewall, on préfèrera souvent qu'il ne laisse plus rien passer quand il tombe en panne, plutôt que le contraire. C'est certes une perte de disponibilité[1], mais au moins, vous ne vous retrouvez pas à poil sur Internet.

Et bien dans le cas de SonicWall, c'est exactement le contraire qui s'est produit. L'expiration de la licence, au lieu d'entraîner un blocage complet de l'équipement et l'arrêt du service de messagerie, a tout simplement généré l'effet inverse, c'est à dire l'ouverture aux quatre vents des flux de messagerie. Autant vous dire que les clients ont très moyennement apprécié la plaisanterie et ne manquent pas de se lâcher sur les forums utilisateur. On les comprend, ne serait-ce qu'à imaginer le flood massif consécutif à l'arrêt de l'antispam...

Mais au delà de toutes ces conséquences pratiques regrettables, cet incident est surtout une belle leçon de choses par la pratique, que certains ont malheureusement reçue d'une manière on ne peut plus désagréable. D'abord sur le concept de "fail safe" précédemment évoqué, en ce qu'il est essentiel que votre équipement, lorsqu'il a un problème, ne se mette pas en mode passoire[2]. En particulier dans cette histoire, puisque l'éditeur n'a manifestement pas su mettre en place les mécanismes qui s'imposaient pour assurer la continuité de son service, qu'au moins son indisponibilité passagère ne porte pas atteinte à la sécurité de ses clients en annulant ou réduisant le niveau de protection offert par ses produits.

C'est à mon avis le plus gros grief qu'on puisse nourrir à l'encontre du constructeur. D'avoir mal conçu son produit sur ce point précis. Mais les utilisateurs ne sont pas en reste, et c'est d'ailleurs ce qui doit les énerver au plus haut point, de ne pas s'être demandé ce qui allait se passer si l'interrogation du serveur de licence ne passait plus. Je ne sais pas vous, mais si un contructeur commence à m'expliquer que je dois rajouter une règle dans mon firewall pour que son appliance puisse fonctionner, je vais commencer à me demander l'objet de ce flux d'une part, et les conséquence de son interruption d'autre part. Et d'en tirer mes conclusions, qui en l'occurence, seraient d'aller voir ailleurs...

Ce qui devrait nous rappeler ensuite que les mécanismes de "phone home" ne sont pas synonymes de bonnes choses. Et s'il s'agit d'en faire dépendre votre sécurité, là, ça n'est carrément pas une bonne idée. Un tel mode de fonctionnement vous rend en effet dépendant de facteurs complètement extérieurs, comme la simple disponibilité du chemin de communication entre vous et l'éditeur de la solution. Dans la vaste majorité des cas, ça marche. Sauf que des fois, non. Genre quand le lien qui vous relie ne marche plus, si votre connexion tombe[3], ou celle de l'éditeur, voire pire, si les deux opérateurs principaux dont dépend ce lien se mettent à se faire la gueule. Et comment vous faites si votre environnement de déploiement n'est pas connecté à Internet ?...

En outre, j'ai toujours trouvé que le système de licences attachés par certains constructeurs à leurs équipements de sécurité posait problème, ce que je n'ai pas manqué de pointer dans quelques interventions sur l'utilisation du logiciel libre en sécurité. Car ces licences sont un facteur non seulement limitant dans l'utilisation de ces outils, mais également de dépendance. Genre la limite sur le nombre d'utilisateurs ou de machines protégées, qui vous oblige à souscrire un nouveau contrat, voire parfois à changer de matériel, juste pour pouvoir ajouter une poignée de nouvelles mailboxes. Bizarrement, toutes ces histoires de licence et de vérification, plus largement le concept de DRM, n'a l'air de poser de sérieux problème qu'à ceux qui les utilisent en toute légitimité, pas aux autres... C'est con...

De manière plus générale, si on décrit la situation des utilisateurs de ces équipements de manière très pragmatique, on se retrouve en face d'une situation que, personnellement, je trouve assez inacceptable dans un contexte de sécurité. Je veux dire, réfléchissez-y deux secondes. Vous avez un élément de protection qui, pour fonctionner, doit recevoir régulièrement la permission de son constructeur. C'est à dire que sa pleine efficacité, et donc celle de votre organisation, dépend du bon vouloir d'une société commerciale, laquelle se trouve être originaire d'un certain grand pays de l'autre côté de cette grande marre qu'on appelle l'Atlantique. Chacun, selon son contexte, appréciera les risques induits par ce genre de situation pas très catholique, et imaginera de sympathiques scénarios pas si fous que ça pour illustrer ses craintes...

Quoi qu'il en soit, quand on voit le barouf qui a été fait autour du Blackberry sur le même genre d'argumentation autour des relais SRP, le cas SonicWall devrait déclencher un émoi sans précédent dans la sécurisphère[4]. Il n'y a pas de doute, la visibilité médiatique d'un produit est devenu un facteur essentiel d'appréciation du risque...


Sinon, ceux qui veulent rigoler un bon coup pourront aller browser l'interface[5] du tout nouveau serveur de licences fraichement mis en place par SonicWall, probablement dans une volonté d'apporter son soutien au SANS... À moins qu'ils ne soient trop occupés à sortir de nouveaux firmwares pour modifier le comportement de leurs outils... Pour la prochaine fois...

Notes

[1] Ceci dit, chacun apprécie sa situation et privilégie un aspect ou autre, ce qui peut amener certains à préférer un firewall ouvert à un firewall en rade.

[2] Ou dans un état que vous considérez inacceptable.

[3] Auquel cas vous ne devriez pas recevoir énormément de saloperies, je vous l'accorde.

[4] J'espère que le buzzword n'est pas déposé... Y'en a bien qui déposent des couleurs...

[5] Vous trouverez d'autres liens marrants sur Full Disclosure.