Edit : les infos du jour révèlent que l'audit lancé par les développeurs d'OpenBSD ont révélé deux failles dans les éléments de code associés à IPSec.
Cependant, comme le signale un des principaux collaborateurs du projet, ledit code a connu des modifications diverses au cours du temps. Rappelons que la révélation est intervenue à la fin de la clause de la non-divulgation de développeur à l'origine de l'information, soit 10 ans après !
En conséquence, affirmer que la cause de ces bugs est volontaire est déjà difficile. Faire porter la responsabilité à telle ou telle organisation est également délicat. Tout cela pour dire que, bien que les modifications soient suivies et enregistrées, sur une période de 10 ans, il faut se garder de conclusions hâtives...
En revanche, je pense que cela ne fait que confirmer les quelques leçons que j'ai cru pouvoir tirer de cet exemple : en matière de sécurité, la vérification fait partie des obligations...
================================================================================
Une information, à prendre avec beaucoup de précaution, m'a été donné aujourd'hui par un ami que je remercie. Elle illustre néanmoins quelques principes de sécurité qui paraissent intéressants de rappeler.
Une liste publique d'échange de mail a été le lieu choisi par l'un de ses membres pour révéler une information déroutante. Il s'agit d'une liste à vocation technique utilisée par la communauté technique développant OpenBSD. Il s'agit d'un système d'exploitation de type UNIX, libre, et clairement orienté sécurité. C'est à dire que ses développeurs sont très attentifs à ces questions et à la maitrise la plus aboutie du système.
Selon un de ses contacts, une entreprise, et ses collaborateurs auraient accepté des financements d'instances gouvernementales américaines pour introduire des portes dérobées (backdoors) dans le développement de composants réseau pour ce système d'exploitation. C'est tout de même relativement ennuyeux car le composant en question gère des fonctionnalités de sécurité réseau relativement avancé mais dont on espère beaucoup (IPSec pour ne pas le dire).
Je précise que bien que l'auteur de ces lignes ne déteste pas les aspects techniques, ce n'est pas le but de ce blog. Pour les plus techniques de mes quelques lecteurs, la source de cette article, comme toujours, vous donnera plus de précision.
En ces temps de "wiki-cyber-blabla", ce type d'information est à prendre avec des pincettes. L'information provient d'une source qui en connait une autre etc....J'ai pourtant choisi de diffuser cette information pour deux raisons principales : la prudence de l'auteur du mail ET ses recommandations de sécurité.
En effet, cette information, qu'elle soit vraie ou non, nous rappelle quelques mesures de sécurité particulièrement intéressantes :
1/ La sécurité par l'obscurité profite à la malveillance. Diffuser une telle information en recommandant un audit de code me parait une initiative bienvenue. Bien sur, on ne peut pas ré-auditer tous les codes à la moindre alerte mais la criticité éventuelle de ce composant justifie cet effort car son utilisation induit normalement un niveau de confiance supérieur, donc souvent, des usages de sécurité moins bien encadrés...Ex. : la sécurité des smartphones dont on use comme des PC en les protégeant comme....bref...
Plus généralement, ceci nous rappelle que l'introduction de la sécurité en amont dans un projet et la vérification, ou l'audit, sont des étapes de plus en plus incontournables.
2/ La maitrise des standards est un outil de souveraineté incontestable. Le fait même que cette hypothèse nous paraisse plausible et non tout à fait farfelue le prouve. On sent bien en effet que la possession de tels capacités d'intrusion serait à même d'intéresser tout acteur ayant des actions en termes de sécurité et de défense.
3/ La maitrise des matériels et des technologies est du même acabit. Etre dépendant d'une ou de quelques organisations et de leurs produits est un facteur de moindre maitrise qu'il convient d'évaluer et de faire évoluer !
4/ Quoi qu'on en dise, la sécurité des systèmes d'informations repose sur la notion de confiance et la capacité des systèmes et outils à transférer ces niveaux de confiance. Derrière un pare-feu, je me sens mieux...OU PAS!
Mais qu'importe, cela doit signifier une attention toute particulière sur les produits, techniques et technologies dont le but est d'élever le niveau de sécurité, donc d'élever la confiance car ils constituent, en quelque sorte, des SPOF...Peut-être une idée intéressante pour apprécier différemment les risques.
En conclusion, cette information peut être, ou non, une vraie nouvelle de type "breaking news". Elle reste néanmoins soumis à un impératif de vérification et de preuve. Elle a cependant l'avantage de donner un "petit coup de fouet" à ceux qui peuvent traiter de sécurité :).
Source :
http://marc.info/?l=openbsd-tech&m=129236621626462&w=2
UE - Avis du Conseil de l'UE à propos de l'ENISA
Il y a 2 jours
Enorme l'info !!!!!!
RépondreSupprimerBien vu :)
Merci :)
RépondreSupprimerComme je le disais, on me l'a transféré...Je l'ai pas vu tout seul :D
Mais c'est carrément intéressant ouais !