jeudi 23 février 2012

Le renouveau de la Gouvernance, c'est maintenant !


Edit :

A noter la très ferme prise de position de M. Eric Schmidt qui dénonce dans ses propos ce projet de révision du traité de 1998 (pour y inclure Internet) notamment en évoquant les risques qu'il y voit...


=======================================================

Le 27 février devrait débuter à Genève une série de négociations relatives au futur d'Internet et en particulier sur son système de gouvernance.

Les lecteurs qui suivent un peu nos écrits auront décelé l'exagération du titre (mais il faut bien publier :) ) ainsi qu'une erreur dans la première phrase. Bien évidemment, cette série de négociations n'a rien de bien nouveau car elle s'insère dans une dynamique visant à modifier drastiquement les enjeux de pouvoirs au sein de ce système de gestion de ressources du Net.

Les échanges diplomatiques relatifs à Internet peuvent être, selon moi, classés en deux catégories : une première relative aux conflits intéressant l'information et l'informatique dont nous avons déjà parlé et une seconde relative aux enjeux de possession et de contrôle sur les infrastructures techniques et de décisions qui font encore aujourd'hui l'Internet que nous connaissons. Ceci a longuement été évoqué dans divers articles précédents.

En particulier, la Chine et la Russie ont depuis longtemps promu des approches différentes en insistant sur la nécessité de donner un caractère internationale et surtout inter-gouveremental à ce qui est parfois considéré comme relevant d'un bien commun. Dans cette acceptation, l'organisme de régulation tout désigné serait évidemment l'UIT ou Union International des Télécommunications qui relève de l'ONU. A l'instar de l'assemblée onusienne, la représentation au sein de l'UIT connait des équilibres de pouvoirs différents et surtout, l'organisation est présidée par un secrétaire dont les amitiés envers la Russie sont notoires...pour y avoir fait une bonne partie de son éducation supérieure (c'est anecdotique certes mais éclairant).

Et les enjeux sont relativement importants car bien que, depuis 1988, le traité écartant Internet de la régulation des télécoms ait permis justement l'essort qu'on lui connait aujourd'hui, force est de reconnaître que de nombreuses pressions poussent à l'évolution du système. Ainsi sont parfois évoqués la main-mise des Etats-Unis sur le système, certaines incapacités à le faire évoluer ou encore la balkanisation de l'Internet...

Une opinion toute personnelle est que le système a assuré jusqu'à aujourd'hui de nombreux services et mêmes certaines évolutions majeures comme le DNSSEC. De même, il n'est pas sur du tout que l'ensemble des pays soit bien conscient de ce qu'ils doivent au Net et de la perte que pourrait constituer un aspect balkanisé...Cela sans compter la technologie qui peut, parfois, bouleverser l'approche géopolitique de la chose.

Et pourtant, les ambitions des pays soutenant cette approche bien particulière des choses sont parfois considérables. Ainsi, les objets de régulation sous contrôle de l'UIT pourront être :

=> la cyber-sécurité et les données personnelles

=> développer diverses pratiques tarifaires et de régulation en ce qui concerne l'échange de trafic internationaux : téléphonie, peering, usage différencié suivant les réseaux de transits utilisés...

=> subordonner l'ICANN et ses fonctions techniques de régulation à diverses autorités de l'UIT

Ces quelques mesures sont un peu plus détaillées par l'article (cf. ci-dessous) du Wall Street Journal qui les tient d'une liste de propositions établies pour un sommet précédent, à Dubaï. Il est vrai que l'on pourrait craindre pour certaines des qualités de l'Internet dans sa conception actuelle et notamment la neutralité.

Ces discussions et évolutions sont de nature à bouleverser profondément l'écosystème d'Internet et de sa gouvernance et sonne comme un retour en force de l'Etat au sein du système international. Il demeure très intéressant, à mon sens, de s'intéresser de près à ce qui pourrait être, ou non, un changement très profond.

Source :




mardi 21 février 2012

Cybersecurity Act of 2012 ou S.2105

Après le Cybersecurity and Internet Freedom Act of 2011, voici une autre loi proposée aux parlementaires américains et destinés à mieux protéger l'ensemble de leurs systèmes d'informations, organisations...

Celui-ci, proposé par un sénateur dont le nom ne nous est pas inconnu, John D. "Jay" Rockefeller IV, met l'accent sur des sujets de préoccupation qui ne sont pas nouveaux mais qui agitent la communauté "cyber sec/def" aux Etats-Unis.

A noter d'ailleurs que si M. Rockefeller est un des supports de cette loi en tant que responsable d'une commission chargée notamment des questions technologiques, le texte semble avoir été déposée par M. Lieberman, un nom également connu pour les nombreuses initiatives législatives auxquelles il a participé et notamment le texte de 2011 cité ci-dessus.

On le voit donc, il existe un "landernau" du "cyber" chez les parlementaires américains, une information intéressante en elle-même mais qui n'étonne évidemment pas.

Sans avoir, je l'avoue, lu les dizaines et dizaines de pages de la prose mi-politique mi-juridique des projets de loi américain, il est possible de retenir deux éléments principaux de ce texte :

=> le DHS obtient un rôle accrue avec notamment celui de sécurisation des réseaux et son importance semble être confirmé par la hausse de sa dotation budgétaire que l'on évoquait dans un article précédent.

Il est également l'interface pour les déclarations d'incidents ou les problématiques que nous évoquions également dans des travaux précédents.

=> Il pilote aussi les phases et processus de partage et échange d'informations. Cette problématique structurelle parait parfois délicate à comprendre : il faut pour cela se souvenir que, selon l'article cité en source, il était expressément interdit par la loi à la CIA et au FBI d'échanger des informations avant 2001. Alors avec les partenaires du privé...

Lors d'un récent échange avec des passionnés du débat stratégique, il fut évoqué la question des causes d'un certain retard et d'un manque d'organisation en matière de sécurité aux Etats-Unis.

Une des hypothèses reposait notamment sur l'aspect sacralisé du territoire américaine même si les attentats auront changé en partie cet état de fait. La sacralisation était ainsi perceptible dans le refus absolu de l'intervention de certains agences sur ce même territoire et l'interdiction d'échanger qui leur était faite. La question de la sécurité "locale" est donc relativement récente aux Etats-Unis et d'ailleurs, le DHS doit être un des plus jeunes départements même si son gain constant de compétences est impressionnant.

A cela pouvait s'ajouter l'organisation fédérale qui pèse tout de même très lourd dans la balance, les pouvoirs locaux étant ainsi responsables d'un grand nombre de fonctions et susceptibles d'être des acteurs importants dans cet aspect de la sécurité. Par ailleurs, même si l'Etat fédéral semble ne pas avoir cesser de gagner des compétences (pouvoirs) depuis la création des USA, ce n'est pas pour autant qu'il détient, comme on l'évoquait, un contrôle fort et comparable à celui que l'on peut trouver dans un pays comme le nôtre sur des industries et des pouvoirs locaux...

Cet aspect de choses peut ainsi expliquer les difficultés de mises en oeuvre des lois "cyber" régulièrement votées et la nécessité d'y "revenir" ainsi chaque année, parfois plusieurs fois par an.

Source :


La Sécurité de l'information est-elle un échec ? Chronique N°4 - Spaghettis et complicités


Il s'agit du 4ème "épisode" de notre série, rédigé avec le blog ami Si-Vis Pacem entrepris après de nombreuses déclarations sur l'état, problématique, de la SSI en France dénoncé par de nombreux praticiens.

Nous avons eu envie de réfléchir aux causes profondes de cet état de fait et de vous livrer nos réflexions !

Les autres articles : le premier, le second et le troisième.

mercredi 15 février 2012

IP à vendre !


Sujet que ce blog oublie parfois mais que l'actualité rappelle à notre mémoire, la gouvernance internet présente, selon nous, des intérêts stratégiques réels et son fonctionnement appelle à des analyses multiples.

Dans un article traitant de l'épuisement de la ressource en IPv4, on évoquait le risque de développement d'un marché noir et les problématiques d'accès et de dissymétrie ou d'inégalité qui pourrait se produire. Rappelons que, à titre d'exemple, les organismes responsables de distribution des IP (les RIR) n'ont pas tous le même âge. Les plus récents concernant par exemple des zones comme l'Afrique sont clairement moins bien lotis car arrivant après un premier découpage hasardeux et un historique assez lourd.

Pragmatique, les différents acteurs ont ainsi anticipé le risque en créant une place d'échange et un marché pour l'échange des adresses IP : Addrex. Celui-ci fournit donc un cadre entre vendeurs et acheteurs d'adresse IP et permet sans doute de concrétiser une tendance que l'on prévoyait : la gestion commerciale des adresses IP, en conservant un certain contrôle. Cette solution ne parait toutefois pas satisfaisante. Dés 2011, on trouve des traces de l'estimation de la valeur de l'adresse IP, à environ 11.25 dollars...

On se souviendra qu'il est dans les capacités des RIR et de l'ICANN de "récupérer", bien évidemment sous certaines conditions, des adresses IP pour reconstituer des blocs cohérents. Cette politique a été longtemps mise en oeuvre à la fois pour éviter la désagrégation des blocs d'IP, ce qui peut avoir un impact sur la viabilité du routage, mais également pour compenser un partage initial inéquitable et sans doute illégitime.

Toutefois, le mode de distribution de l'adresse IP n'est pas réalisée en mode commercial. Bien au contraire, les RIRs sont membres d'une organisation rattachée à l'ICANN. Les "clients" des RIRs, quant à eux, ne le sont pas vraiment puisqu'ils sont plutôt des "adhérents" à l'organisation qui leur attribue des portions de l'espace d'adressage, les RIRs le détenant de IANA qui en assure l'historique, le suivi et la traçabilité. Notez cependant que l'adhésion est bel et bien payante pour un adhérent aux RIRs.

En conséquence, on ne peut pas dire que IANA ou l'ICANN détient (sous la forme de propriété) les adresses IP puisque justement, celle-ci conserve des enregistrements des allocations qui sont faites ! De plus, les RIRs ne "vendent" pas au strict sens du terme les portions de leurs allocations : ils en seraient bien incapables n'étant pas propriétaires...

Donc, on se demande bien comment des détenteurs non-permanents mais non propriétaires - des allocataires - pourraient échanger sur un marché ces adresses, sans parler des problématiques de déséquilibre dans les accès que cela est susceptible de créer. On peut imaginer que les entités relevant de RIRs positionnés sur des espaces géographiques à ressources faibles seront moins capables d'obtenir des adresses IPv4 ! A moins de faire un choix stratégique, un peu comme avec le mobile, et de sauter le pas vers IPv6 directement.

Sauf qu'il existe certaines subtilités : lors de la phase initial de répartition de portions d'adressage, les RIRs n'existaient pas encore ou alors sans leurs capacités de régulation actuelles. C'est pourquoi, lorsqu'on regarde l'état des allocations, il est possible de voir que certains grandes parties de l'espace d'adressage (/8) sont allouées directement à des entités privées...Et l'une d'entre elles vient justement de "mettre en vente" un /8 entier : c'est à dire 16 777 216 d'adresses...

La légitimité de ces transaction et de l'ensemble du système demeure très largement douteux. On serait même en droit de se demander si les adresses IP ne font partie d'une ressource commune à protéger convenablement d'autant qu'elles appartiennent et relèvent d'un espace relativement conflictuel et présentant aujourd'hui des enjeux en termes de souveraineté, défense et sécurité. Une question à rapprocher des Global Commons...sujet d'ailleurs évoqué par l'Alliance géostratégique ?

Source : dans le texte

mardi 14 février 2012

Des vases communiquants en matière de dépense...


EDIT :

A noter la proposition hier d'une loi aux parlementaire américains, le Cybersecurity Act of 2012 qui établit clairement une élévation des pouvoirs du DHS notamment en matière de protection des infrastructures critiques.

====================================================

Deux articles, apparemment sans lien direct, ont attiré l'attention de l'auteur de ces lignes et permettent d'illustrer une évolution dans la répartition des pouvoirs et responsabilité en matière de capacités de lutte informatique. Notez ici qu'il s'agit des expressions de besoins en matière de budget pour l'année...2013 !

Le premier évoque la réduction d'une partie du budget IT du Département de la Défense (Ministère de la Défense) américain. Environ un milliard et demi de dollars devraient ainsi être ôtés du budget initial en dotation pour ce ministère. Selon l'article, une partie de l'allègement des coûts pourrait provenir de la réduction et de la consolidation des data-centers et serait réparti sur l'ensemble des armées. Même la DISA, Defense Information System Agency, qui assure notamment une partie des services de sécurité pour l'exploitation des data-centers de la Défense aurait diminué ce budget.

Alors même que l'ensemble des textes et déclaration semblent semble aller vers une consolidation des capacités au sein de la Défense, force est de constater que des coupes dans le budget IT de la défense ne semble pas forcément cohérent avec un fort besoin de sécurité.

Un second article toutefois apportait, de manière inattendue, un éclairage nouveau sur cette question. Il semblerait en effet que le budget du DHS en matière de questions "cyber" et notamment celles concernant la sécurité doublerait, passant à près de 800 millions de dollars.

Nous savons que se discute en ce moment de profondes évolutions réglementaires et budgétaires aux Etats-Unis. Une des tendances fortes est la croissance des pouvoirs et compétences du DHS. Cette évolution de budget semble donc logique mais la question demeure : pourquoi correspondrait-elle à une baisse du budget de la Défense qui présente aussi de forts besoins en matière de sécurité ?

On peut ainsi évoquer plusieurs hypothèses. L'une d'entre elles serait que la Défense américaine est très bien pourvue en matière de sécurité avec notamment la NSA et n'aurait donc que partiellement besoin de cette élévation en matière de sécurité. A contrario, le secteur civil (public et privé) semble souffrir de profondes lacunes en matière de sécurité et ce serait donc également logique d'y voir un renforcement.

On peut aussi voir en ces évolutions budgétaires les nouveau dessin des relations et responsabilités en matière de lutte informatique. Le DHS détiendrait alors LA place prépondérante et la responsabilité en matière de Lutte informatique défense et de "cyber-sécurité" tandis que la Défense américaine se consacrerait plus vers l'offensive...

A ce jour, les déclarations officielles attribuent un strict périmètre au Cyber Command avec notamment la protection des infrastructures et réseaux de la défense tandis que le DHS prendrait en charge l'aspect civil. Il n'en demeure pas moins que des questions se posent sur la frontière justifiant l'intervention, notamment en matière de défense, du Cyber Command où de sa principale ressource technique que semble être la NSA.

Les "faveurs" attribuées aux DHS en termes budgétaires peuvent donc être vu comme un indice du renforcement de ses prérogatives en matière d'action sur le territoire et les systèmes US. Les entités militaires ou de la Défense aurait alors instruction de préférer une protection de leur "pré-carré" et de se concentrer sur des "opérations cyber" à vocations offensives ou défensives dont on ne mesure que mal les contours.

Une vision et une analyse très personnelle, évidemment !

A suivre (sources dans le texte).

lundi 13 février 2012

Réediter Fortitude à l'ère de l'Internet par Lignes Stratégiques

Un article à lire : http://alliancegeostrategique.org/2012/02/11/reediter-fortitude-a-l%E2%80%99ere-de-l%E2%80%99internet/

Pour bouleverser quelques idées reçues et proposer des modèles de compréhension adaptées sans être forcément en rupture !

vendredi 10 février 2012

Chrome et SSL : nouvelles mesures


Dans un article récent, nous évoquions l'évolution du modèle SSL avec diverses initiatives permettant de pallier aux multiples faiblesses du système.

Les lecteurs assidus et avisés savent bien que le navigateur détient une place importante dans le schéma de confiance sous-tendance ce modèle : il a une action de validation, de vérification ainsi que de prévention en alertant l'utilisateur. Il est donc partie prenante du système et peut avoir une action décisive. Pour autant, est-ce à cet intermédiaire qu'il faut confier la responsabilité des évolutions de sécurité ?

Pourquoi évoquer le navigateur ? Car Chrome, le navigateur proposé par Google se propose d'adopter une mesure relativement radicale en changeant en profondeur le mode de validation des certificats.

En bref, les ingénieurs de Google se proposent de ne plus utiliser le système classique de contrôle de la révocation auprès des entités valides que sont, par exemple, les CA ! Ne criez pas au crime, chers utilisateurs, car, bien évidemment, la firme propose des palliatifs.

Plus intéressantes néanmoins sont les raisons évoquées par Google pour affirmer que le système de révocation est en l'état inutile - la comparaison, osée, évoque une ceinture de sécurité qui casse dés qu'on en a besoin - :

=> tout d'abord, ils affirment que le système ne pallie plus du tout aux attaques du moment. En effet, un pirate ayant la capacité d'usurper des certificats de sécurité a clairement les moyens d'altérer le processus de vérification et de contrôle : de tels outils proposent ainsi des mécanismes qui font état d'une erreur réseau (on ne peut pas contacter le serveur pour vérifier) et certains cas sont, par nature, des obstacles à la vérification : les portails captifs des aéroports ou hôtels selon un des responsables de la solution.

Dans ce cas, lorsque une erreur réseau est produite (on parle de soft-fail), la plupart des navigateurs établissent quand même la connexion vers...le site utilisé par le pirate et produisant un certificat usurpé.

=> de plus, la plupart des utilisateurs ignorent sciemment, sans lire ou regarder, les avertissements de sécurité produits par les navigateurs...

Il était donc temps de trouver une solution alternative à cette problématique. La plupart des navigateurs utilisent souvent le système de mise à jour afin de révoquer des certificats ou des CA sur les navigateurs mais cette méthode présente des inconvénients : il faut que des mises à jour soient faites, que le navigateur soit redémarré et surtout, ce n'est pas du tout préventif !

Celle retenue par les équipes de Google se propose donc de faire des mises à jour des certificats de sécurité sur un mode plus "invisible" pour l'utilisateur en "poussant" des listes de certificats révoqués sans nécessité spécifique de mettre à jour ou de redémarrer.

Conscient de la "masse" de révocations éventuelles à traiter, les ingénieurs de Google affirment que la majorité des certificats révoqués le sont pour des raisons administratives et non pour des raisons de sécurité...Dans le cas des révocations "administratives" (date de péremption, non-renouvellement...), les mécanismes habituels suffisent car une attaque est moins à craindre.

Pour les autres, Google propose que les CA mettent en place un système de révocation que le moteur de recherche pourra obtenir en "crawlant" les adresses. Si les raisons de sécurité sont évoquées, le moteur pourra alors filtrer et les listes directement poussées vers les navigateurs seront alors uniquement des "urgences de sécurité".

L'idée de Google apporte donc quelques nouveautés : elle se base dans le continuité du système en essayant de l'améliorer (pour reprendre mes hypothèses de l'article précédent). Elle appelle cependant quelques réflexions :

- la "masse critique" de Google peut être un facteur déterminant dans la réussite du déploiement de cette mesure dont rien ne dit qu'elle ne met pas les autorités de certification dans une position inconfortable.

- en effet, les autorités demeurent le "point d'entrée" de la vérification même si elles ont connu une perte affligeante de légitimité après des attaques réussies. De fait, l'offre de Google les prive de leur rôle de point central tout en leur permettant de continuer à oeuvrer (et à faire des affaires).

- Google prend ici un rôle de "gentil gendarme" tout en se préservant le rôle central, rôle qu'il a déjà dans de nombreux domaines. Si Google devenait à son tour, un validateur effectif des certificats émis, pour son navigateur, il serait, certes responsable, mais avant tout un acteur qui se serait rendu indispensable dans l'écosystème de sécurité d'Internet !

- Notons aussi qu'à la marge, seul son moteur de recherche et son navigateur serait susceptible d'offrir un service de sécurité complémentaire à l'écosystème SSL classique, ce qui lui vaudrait certainement des parts de marché en plus...

Une idée intéressante qui ne nécessite pas tout un nouveau modèle certes mais qui n'est pas sans modifier l'équilibre des pouvoirs du Net. Pour résumer, cette solution est très proche de celle décrite dans l'article précédent sauf que le seul "notary" serait alors...Google !

A suivre attentivement !

Source :




lundi 6 février 2012

Sécurité et routage : du nouveau !


Dans un article précédent, j'évoquais les travaux menés par un groupe de travail de l'IETF et portant sur la sécurisation du routage. En effet, entre les acteurs principaux (AS - Autonomous System) comme le sont les fournisseurs d'accès ou de services...le routage est effectué de manière complexe.

Sans entrer dans les détails, il existe peu de sécurité sur les échanges entre les routeurs permettant de suivre l'évolution des routes sur Internet (ou encore des chemins permettant de joindre un point d'un autre). Ces lacunes ont été évoqués lors de cas relativement récents de détournement de trafic : dans le climat actuel, cela représente donc d'importants problèmes potentiels. Cela a notamment conduit aux travaux de l'IETF.

Conduit par le groupe de travail SIDR, nous devons notamment à Stéphane Bortzmeyer une analyse exhaustive des multiples RFC qui établissent l'architecture technique de la solution. Ils sont listés à la fin de cet article.

Quel est l'objectif ?

L'objectif premier de cette solution est d'assurer que les routeurs qui annoncent des routes ont la légitimité pour le faire. Cette question n'a rien de simple et c'est la solution d'une infrastructure à clé publique pour le routage ou RPKI, Routing Public Key Infrastructure qui a été choisie.

En effet, en annonçant, par exemple, que j'ai la route la plus intéressante (la plus rapide, la moins consommatrice de ressources...) pour un site que je ne connais pas et héberge encore moins, j'ai de fortes chances, si bien évidemment, j'ai un routeur permettant d'émettre des annonces BGP, d'obtenir qu'une partie du trafic à sa destination passe par mes infrastructures.

Parfois, il s'agit d'une erreur - ex. : lorsque le Pakistan "coupe" Youtube" ou quand "tout" l'internet est annoncé par un seul AS - mais parfois, l'objectif peut-être d'étudier ou d'obtenir des informations sur certaines portions du trafic.

Quel sont les principes ?

Le principe de base est relativement simple : lorsqu'un organisme détiendra légitimement un bloc d'adresse IP, il sera également titulaire d'un certificat (de type x.509) permettant de signer des objets et autorisant ainsi certains AS à l'annoncer et donc, les routeurs en suivant à en vérifier la légitimité...

Cette architecture rappellera sans doute à certains celle de SSL, ce qui n'est pas tout à fait exact, mais le nouveau système emprunte certaines caractéristiques comme les certificats X.509.

Selon l'article de S. Bortzmeyer, on trouve 3 éléments principaux dans cette solution :

=> une infrastructure de clé, plaquée sur la logique actuelle d'attribution des blocs IP. L'IANA d'abord, suivi des RIR puis des attributeurs locaux (LIR) éventuels.
=> des objets numériques (signés par les certificats pour en attester la validité) qui expriment les autorisations de routage accordés ou non.
=> un mécanisme sécurisé de distribution (et de révocation)

Notons toutefois une distinction importante : cette première étape de la solution permet de valider l'origine de l'annonce. En bref, elle permet de certifier techniquement que celui qui annonce "détenir" une adresse IP (ou plutôt un bloc) en est bien le détenteur légitime. On valide donc l'origine.

Le chemin annoncé et pris par un paquet au départ d'une machine et à destination d'une autre est un problème qui sera traité plus tard : il est en effet bien plus compliqué car les chemins ne sont pas forcément stables et dépendent de relations entre opérateurs. La validation du chemin est donc encore à attendre.

3/ Quelques changements...

Bien que ne rentrant pas sciemment dans les détails techniques, quelques éléments sont à noter. Tout d'abord, il assiste à un renforcement de la pérennité de la structure de distribution d'adressage, structure très certainement contestable sur certains points : le cas de blocs entiers attribués à des structures privées et favorisées au détriment de pays et régions arrivés plus tard dans l'internet.

Cette structure apporte cependant ici une notion de pérennité et de constance et donc de sécurité. Le fait de pouvoir apporter une preuve technique, aux routeurs, de la légitimité de l'origine d'une annonce repose sur une chaine de confiance : IANA atteste des blocs attribués aux 5 RIRs qui eux-mêmes attestent avoir distribué les blocs à des LIRs ou à des FAI.

Cependant, auparavant, comme cette chaine n'avait pas de répercussion technique dans la validation, le processus de retrait d'un bloc à son détenteur précédent n'avait aucun effet pratique : désormais, en envoyant des informations de révocation, les annonces relatives à l'origine d'un bloc d'adresse ne seront plus valides et le détenteur en sera...dépossédé.

Cependant, pour le moment, IANA ne constitue pas la racine de certification : ce sont les RIRs qui sont chacun une racine de certification, ce qui tendrait à prouver que certains ne souhaitent pas que le pouvoir soit concentré à l'IANA. Vous pouvez lire quelques articles sur la modification de la structure de pouvoirs et opérationnelle de la gouvernance.

Enfin, cette solution nécessite cependant des changements au niveau des routeurs et des organisations offrant des services réseaux. Pour le moment, rien n'oblige un routeur à utiliser un système de vérification : il peut accepter les routes sans effectuer de contrôle...Cela pourrait varier mais pas pour le moment.

Conclusion :

Pour ceux qui persistent à croire qu'Internet est un espace absolument non-sécurisé, force est de constater la profonde évolution du milieu.

La fin d'IPv4 pousse à une adoption d'IPv6, la mise en place de DNSSEC est croissante et l'arrivée de RPKI représente, pour moi, une révolution du même acabit. Cette ensemble de solutions, issues de la gouvernance, apporte des fonctionnalités de sécurité importantes à un système qui en avait certainement besoin, notamment depuis que les attentes à son égard ont évoluées.

Il est à noter que sa naissance au sein de l'IETF est intéressante car elle est aussi une preuve de la capacité des mécanismes de la gouvernance à faire évoluer positivement ce système. Il faudra cependant demeurer attentif quant à son adoption et au développement de la seconde étape, plus compliquée mais déjà très attendue.

Source :

Une description globale du système et l'ensemble des RFCs de l'architecture de RPKI

jeudi 2 février 2012

Evolutions réglementaires aux USA


Pour ceux qui observent un peu la vie réglementaire relative au cyber outre-atlantique, peut-être avez-vous remarqué que celle-ci s'émeut considérablement ces derniers temps.

En effet, l'on peut observer une recrudescence des textes et propositions avec une volonté affichée de modifier en profondeur le système et l'organisation de la sécurité.

A cet égard, certaines nouvelles sont intéressantes comme celle-ci, dernière en date, qui occasionne divers affrontements entre le deux chambres parlementaires. Il s'agit en effet, de donner un certain pouvoir au Département de la Sécurité Intérieure (DHS) afin de lui permettre d'avoir un regard accru sur la protection des réseaux relevant des industriels. Les affrontements en question portent notamment sur les capacités à avoir une action coercitive ou punitive sur les manquements constatés.

Au-delà de cet aspect, cela permettrait de formuler quelques remarques relatives à des tendances récentes. La première tendance serait une forme de confusion entre la sécurité et les actions militaires (au-delà de la défense) et la seconde, des questions relatives à nos capacités vis-à-vis des autres pays.

La première tendance se démarque par une confusion et un glissement sémantique entre défense et sécurité ou cybersécurité et cyberdéfense. La seconde est notamment matérialisée par divers articles mais surtout par la parution récente d'étude de type "risque-pays" permettant d'établir des index des cyber-puissances ou des pays bien protégés sur cet aspect.

Sur le sujet de la confusion, il est à noter qu'un pays qui présente d'excellentes références en matière de sécurité ou de capacités d'attaques n'est pas forcément un coffre-fort ou ne présente pas une capacité de résistance conséquente aux attaques.

A l'égard des Etats-Unis, rappelons qu'ils sont, à ma connaissance, le seul pays dont une des agences a réussi à intégrer de très forts composants de sécurité dans le noyau linux (SELinux) et à avoir donc des répercussions potentielles très largement au-delà de leur strict domaine d'action. Remarquons aussi que les chiffres relatifs aux Cyber Command (qui fait d'ailleurs moins l'actualité) révèle un potentiel humain et technologique impressionnant dont peut légitiment présager beaucoup...

Mais tout cela concerne la sphère militaire ou la défense et c'est d'ailleurs le crédo du Cyber Command et de son chef : l'objectif est la sécurité des infrastructures militaire et de la défense. Que cela inclut des capacités d'attaques à l'instar de ce que laisse présager les derniers documents stratégiques ne serait pas pour nous étonner...

En revanche, ne confondons pas ! Ce n'est pas pour autant que la sécurité en deviendra meilleure de manière globale. A cet égard, rappelons que la première puissance mondiale/première armée du monde n'a su ni empêcher des attentats sur son sol ou ne peut se targuer d'une victoire décisive dans ses différents engagements...

Ceci posé, revenons à notre sujet : ne peut-on s'étonner que les responsables de la sécurité intérieure (DHS) n'aient pas déjà un droit de regard sur les organisations internes de la sécurité de certaines infrastructures (réseaux privés) ?

Pour ma part, et bien sur sans préjuger de ce que je ne connais pas, cela me semble étrange ! Regardons maintenant chez nous en évoquant notre seconde tendance !

La question qui se pose est alors de savoir si l'Etat a un droit de regard sur les réseaux privés et l'organisation de la sécurité ? Et bien, la réponse est oui et depuis un quelques temps déjà !

Par exemple, le décret de 2006 relatif aux infrastructures vitales oblige et contraint les opérateurs à la mise en place de dispositif et prévoit très certainement des mesures de contrôle. Ce dispositif a d'ailleurs fait "tâche d'huile" car il a été reproduit au niveau européen, démontrant ainsi un certain succès. De même, il est fort probable que les organisations privées liées à la défense nationale (industriels, fournisseurs...) et traitant des dossiers relevant de niveaux confidentiels soient également contrôlées. Elles doivent d'ailleurs être probablement autorisées et habilitées de même que leurs personnels.

Une analyse rapide révèle donc les problématiques auxquelles sont confrontées les Etats-Unis ainsi qu'une certaine avance française en la matière. Rappelons également la conclusion d'un classement selon lequel la taille pouvait représenter un facteur handicapant. Tout cela doit donc nous conduire à des approches prudentes dans le traitement des questions de sécurité et de défense avec un regard plus précis sur ce qui les distingue...sans que cela n'empêche au final de conclure sur une réelle "égalité" ou identité. De même, notons une certaine réussite française dans le domaine qui apparaît ici relativement favorisée.

Source :

mercredi 1 février 2012

Des rustines pour SSL ?


Dans un article précédent, ce blog proposait une synthèse des problématiques récentes qui ont touché "SSL", c'est-à-dire à la fois les vulnérabilités intrinsèques mais également les problématiques spécifiques qui ont touché de manière plus générale l'écosystème de cette solution de sécurité.

En particulier, la population des autorités de certification laissent de nombreux analystes dubitatifs après les très importantes problématiques de sécurité rencontrées par Comodo ou encore Diginotar.

Rappelons en effet que lors de la présentation du certificat qui assure une partie de la sécurité de la transaction, celui-ci est contrôlé notamment via l'autorité de certification qui constitue une garantie de confiance...Si cette dernière s'avère "mal placée", alors le modèle souffre alors d'une vulnérabilité.

Conscient de tout cela, il est fort probable que les chercheurs s'activent afin de trouver des solutions. En tentant de résumer, on pourrait dire qu'il existe 2 méthodes principales pour traiter cela :

=> bouleverser le système ou le changer complètement. Cela implique de disposer d'un modèle de sécurité remplaçant adéquat et adapté.

Mais cela suppose aussi de pourvoir l'appliquer. On peut ici alors distinguer deux cas d'usages, soit le modèle est "centralisé" et ce sont les acteurs du Net concernés qui devront l'appliquer. Soit il est "décentralisé" et l'utilisateur aura tout le travail à faire...

On ne préjuge pas des modèles futurs ici et il peut exister une solution intermédiaire comme l'est SSL/TLS à mon sens : il faut que chacune des parties s'impliquent : version à jour, vulnérabilités corrigées rapidement etc etc...Des attaques comme "Firesheep" consiste ainsi à profiter d'une application laxiste (quelques pages en HTTPS - donc utilisant SSL/TLS - seulement).

=> Une autre approche consiste à apposer des "rustines" sur le système existant afin d'en corriger les vulnérabilités. Dans le cas qui nous occupe, certaines relèvent purement de questions d'organisations ou d'humains : c'est parfois bien plus compliqué !

C'est pourtant ce que propose "Convergence" : un système dont l'objectif est de garantir une plus grande souplesse, côté utilisateur, dans la gestion de la confiance accordée aux CA et à ceux qui utilisent leurs certificats.

Plus précisément, le constat opéré par son créateur, est que le système nécessiterait une propriété supplémentaire qu'il dénomme "trust agility" que l'on pourrait traduire par "confiance à degré multiples".

L'idée est assez simple : si vous n'avez plus confiance dans un CA (VeriSign ou encore Comodo), la seule solution que vous avez est alors de le supprimer de votre base de confiance....Non seulement, ce n'est pas à la portée du premier quidam venu mais c'est également se priver de tous les sites qui utilisent un certificat "garanti" par ceux-ci ...Ou alors, il faut à nouveau leur faire confiance, ce qui n'a pas de sens.

Aussi, Marlinspike propose-t-il d'introduire un nouvel intermédiaire dans les acteurs de la transaction sécurisée par SSL. Un add-on firefox est d'ailleurs déjà disponible.

Se basant sur un système distribué, l'objectif est que des "notaries" attribuent des "notes" ou des jugements de sécurité aux CA et surtout aux sites webs les utilisant notamment en entretenant un historique et en détectant des modifications suspectes. N'importe qui peut acquérir ce type de qualification même si, dans l'esprit, son créateur attend plus les sociétés de sécurité et autres passionnés, chercheurs, universités...que le quidam moyen.

Celui-ci, en revanche, pourra décider quel sont les "notaries" auxquels il fait confiance...et de là, avoir accès à des CA notés en fonction et une connaissance plus avancée de l'historique "SSL" du site web auquel l'utilisateur accède.

Ainsi, en reprenant un exemple, si vous visitez Google.fr (en HTTPS), le certificat reçu sera soumis à un ou plusieurs "notaries". Si ceux-ci révèlent une modification récente (un changement brusque de CA par exemple), l'utilisateur sera alerté.

Quelques commentaires maintenant...Commençons avec le positif :

=> ce système est ouvert, relativement distribué et laisse une grande place à l'utilisateur qui peut adapter son comportement et mettre en oeuvre ses choix...

=> il met fin à une forme de toute-puissance des CAs que les problématiques de sécurité ont déjà largement entamé en les faisant passer par les fourches caudines de personnes plus intraitables en matière de sécurité...

=> il permet également d'aller plus loin dans le contrôle et l'authentification. Des critères associés à l'historique du site permettent très certainement de distinguer plus de choses et d'être plus efficaces dans la prévention de l'attaque. On peut même imaginer un contrôle plus poussé associant un regard sur les mises à jours et les corrections de vulnérabilités ou encore l'usage de SSL/TLS sur l'intégralité des pages du site.

Le négatif est associé, comme souvent, aux qualités du système :

=> l'aspect décentralisé et ouvert laisse craindre des dérapages : j'imagine déjà des "notaries" malveillants qu'il faudra également détecter, supprimer...ce qui suppose un contrôle supplémentaire. On est alors dans le contrôle du contrôle du contrôleur !

=> Par ailleurs, il est nécessaire d'atteindre une masse critique de notaries...Considérant l'implication des acteurs de la sécurité sur Internet, c'est loin d'être impossible mais pour le moment, on compte seulement 2 notaries...

=> de manière générale, l'ajout d'une couche de sécurité présentant quelques doutes n'est pas forcément une bonne idée pour sécuriser une autre "couche"...

=> le système fait appel à l'utilisateur pour gérer des listes, ajouter un add-on firefox et être attentif à un avertissement de la machine...En ai-je dit assez ???

Convergence est donc un système qui vise à "patcher" la logique de sécurité de SSL/TLS et son écosystème. Comme on l'a vu, certaines de ses caractéristiques paraissent très intéressantes et bienvenues malgré une certaine jeunesse du système.

A contrario, on peut craindre certaines dérives issues de la nature même du système. Se situant dans un objectif de continuité, cet exemple est la preuve que la communauté ne se satisfait plus du système et que celui-ci doit évoluer : nous verrons comment !

Source :