Le diable est dans les détails

Ainsi donc l'activité d'audit sécurité va être réglementée en France. Le projet est encore en phase expérimentale, mais le processus étant enclenché, il est inéluctable (modulo le temps de convergence des autorités concernées). Il faut dire que l'ARJEL avait déjà ouvert cette voie[1] en fournissant une liste d'organismes certificateurs.

C'est une idée qui circule depuis quelques temps, sans que j'en aie bien compris les avantages. Car si tout un chacun peut effectivement constater que le marché est inondé par des charlatans ou des sociétés unipersonnelles[2], l'apport effectif d'une réglementation reste à prouver. En théorie "la main invisible du marché" est censée faire son travail. Et elle le fait plutôt bien: la plus grosse partie de l'activité fonctionne par bouche à oreille. Quant aux "tests d'intrusion qui n'intrusent pas", ils correspondent aussi à une demande de certains clients: les mauvais ont donc leur place dans l'écosystème, c'est pour cela qu'ils y survivent.

Maintenant regardons de plus près l'avant-projet produit par l'ANSSI (version 0.9).

Chapitres 3 et 4: de la mesure des compétences techniques

Ce qui frappe en premier lieu, c'est le très haut niveau d'exigence requis par ce document. J'ai immédiatement pensé à la VAE ESSI, qui nécessite des compétences aussi diverses que la cryptographie, l'intelligence économique, la gestion d'une équipe et d'un budget, et un anglais parfait. Au passage, si quelqu'un a des chiffres sur le nombre de VAE ESSI délivrées, merci de les poster en commentaire …

Dans l'avant-projet, on peut lire que "le prestataire d'audit doit s'assurer que les compétences [techniques | organisationnelles], théoriques et pratiques, de l'ensemble des auditeurs qu'il emploie couvre les domaines suivants […]". S'en suit une longue liste à la Prévert, allant des systèmes & réseaux, du développement d'outils intrusifs[3], à la maitrise de la norme ISO 27001, de la méthode EBIOS et du RGS, entre autres. Cette liste est détaillée dans les grandes largeurs en annexe A.

Puisque nous sommes dans le chapitre 3, cette exigence s'applique a priori à la société prestataire et pas à chaque auditeur individuellement. Mais la plupart des prestataires de taille moyenne (disons, moins de 20 personnes) - et il en existe beaucoup dans le secteur - sont quasiment assurés d'avoir un "trou dans la raquette" … Quant aux autres, il restera très difficile de valider que toutes les compétences soient disponibles, persistantes (dans un contexte de turn-over important), et utilisées si la mission le requière.

Dans le chapitre 4 - qui concerne les auditeurs eux-mêmes - il est recommandé que les auditeurs, disposent d'un bac+5 reconnu d'état, justifient en sus de 2 ans d'expérience en informatique "pure", 1 an d'expérience en sécurité, et 1 an d'expérience en audit. Autant dire qu'on n'est pas loin du mouton à 5 pattes, surtout avec les difficultés de recrutement actuelles (et futures, à en juger par la production du système éducatif dans le domaine).

De mon expérience, la mesure objective des compétences techniques est un exercice très difficile … et inutile.

Difficile, car à moins d'enfermer le candidat dans une pièce pendant des heures (sans accès Internet) pour le faire plancher sur des travaux pratiques, il n'est possible d'estimer "au jugé" qu'une infime partie des compétences annoncées sur le CV (dont la liste dépasse souvent les 50 entrées).

Comme l'ANSSI, nous disposons d'un questionnaire technique "infaisable"[4] qui sert uniquement à disqualifier de manière objective un candidat "qu'on ne sent pas". Mais un simple QCM ne peut pas valider des compétences techniques très poussées (tout au plus peut-il servir à délivrer une certification ;).

Inutile, car c'est plus la capacité à apprendre rapidement qui est importante. Le document cite des technologies de bases de données: Oracle, MS-SQL, MySQL et PostgreSQL. Mais j'ai également été confronté à SolidDB (produits Cisco), Access, SQLite (Android), Sybase SQL Anywhere, et probablement d'autres oubliés depuis.

Or aucune société ne peut maintenir à jour des auditeurs sur toutes ces technologies: ce qui compte c'est la rapidité avec laquelle l'auditeur appréhende une nouvelle technologie. Tout candidat qui n'a pas déjà réellement utilisé au moins 3 systèmes d'exploitation, 3 architectures matérielles, et 3 langages de programmation est pour moi un rookie (quelle que soit son expertise dans un domaine très pointu tel que "l'assembleur Intel x86 en environnement Microsoft Windows").

L'exemple des challenges de sécurité (tels que celui du SSTIC) est frappant: le top 10 est à peu près toujours le même. Or je ne peux pas croire que les gagnants récurrents ont étudié a priori des technologies aussi variées que le mode V8086 du processeur Intel ou le système d'exploitation Android. Ils ont appris sur le tas, en temps contraint. C'est à mon avis la seule qualité nécessaire à la pratique du test d'intrusion, compte-tenu de la diversité des missions et de l'environnement technologique mouvant dans lequel nous évoluons.

Chapitre 5: incise sur l'obsolescence des technologies

Le chapitre 5, comme l'Annexe A, contiennent des détails techniques tout à fait inattendus.

Il est question de chercher des failles de type Cross-Site Scripting (le terme n'a pas été francisé ;), injection SQL, et Cross-Site Request Forgery. Pourtant la liste des erreurs potentielles est bien plus longue.

Il me semble ambitieux de citer des technologies, voire des produits commerciaux, dans un document de référence sur les technologies que doit maitriser un auditeur ou un prestataire d'audit. Il m'a déjà été donné de voir du code FORTRAN en audit, tout autant que des applications Android. Comme explicité précédemment, c'est la maitrise de quelques concepts fondamentaux et la capacité à apprendre qui me semblent essentiels à mesurer.

Le paradoxe français, premier acte

J'aimerais ici parler du voile pudique jeté sur l'audit d'applications en source fermée.

Compte-tenu des technologies mentionnées en annexe, on sent que le document s'applique à un nombre limité de prestations d'audit: les réseaux internes, les réseaux d'interconnexion, les applications Web, la téléphonie (sur IP … ou pas), et les environnements virtualisés.

Exit donc par exemple les audits de systèmes embarqués (comme les imprimantes, les caméras WiFi les caisses de cantine ou les badgeuses). Le cas de "l'audit d'applications lourdes de type client/serveur" est réglé en une ligne dans l'annexe ... Quant au problème du Cloud Computing, il ne semble pas encore avoir atteint l'administration:

"Les tests d'intrusion ne devraient pas être réalisés sur des plate-formes d'hébergement mutualisées."

D'après ce document, aucune compétence en reverse engineering n'est donc requise pour être un excellent auditeur sécurité. Ce qui est bien entendu faux dans la pratique, ne serait-ce que pour le développement des codes d'exploitation dont il va être question juste après.

Le paradoxe français, deuxième acte

Bien entendu, l'administration se doit d'être exemplaire et ne peut mentionner la pratique du reverse engineering dans un document officiel. D'ailleurs il est bien précisé que: "f) Le prestataire d'audit est tenu de respecter la législation et la réglementation en vigueur […]".

Mais là où ça devient cocasse, c'est lorsqu'il est dit plus loin que: "Le prestataire d'audit doit fournir, à la fin de l'audit, les développements spécifiques réalisés lors de l'audit pour valider les scénarios d'exploitation des vulnérabilités. Ces développements peuvent être fournis sous la forme de scripts ou de programmes compilés, accompagnés de leur code source, ainsi que d'une brève documentation de mise en œuvre et d'utilisation".

Non seulement il me semble difficile de mettre au point des codes d'exploitation sans pratiquer un minimum de reverse engineering (passons là-dessus), mais surtout cela me semble tout à fait coller avec ce texte (pour avoir fait l'expérience de la rigueur avec laquelle il était interprété par les instances de la SSI française):

"Le fait, sans motif légitime, d'importer, de détenir, d'offrir, de céder ou de mettre à disposition un équipement, un instrument, un programme informatique ou toute donnée conçus ou spécialement adaptés pour commettre une ou plusieurs des infractions prévues par les articles 323-1 à 323-3 est puni des peines prévues respectivement pour l'infraction elle-même ou pour l'infraction la plus sévèrement réprimée."

En clair, livrer à ses clients des exploits "clé en main", c'est (probablement) mal.

Des chiffres et des lettres (et des couleurs, aussi)

Un dernier point qui me tient à cœur, c'est la caution officielle apportée aux matrices de risque, d'impact, etc. qui doivent enrichir et colorer[5] le rapport.

Pour mémoire, ces matrices ont pour but:

• De lutter contre les consultants qui n'hésitent pas à faire mousser la production d'un outil automatique et brodent sur la dangerosité des "ICMP Timestamp".
• D'en faire le moins possible après l'audit (c'est-à-dire d'économiser des sous), en supprimant toute action qui n'a pas été parée de rouge[6] dans le rapport.

En ce qui me concerne, j'essaie de résoudre le problème à la source: la seule classification que j'utilise dans les rapports est PWN ou PAS PWN. Ce qui évite de ratiociner pendant des heures sur la criticité d'une faille sur une échelle de 0 à 4, 10 ou 20.

En guise de conclusion

Il y a de bonnes idées dans ce document.

Par exemple, il y est rappelé que le test d'intrusion ne prend tout son sens qu'en complément d'un audit préalable du système (au sens large), d'abord dans le chapitre 2:

"Un test d'intrusion seul n'a pas vocation à être exhaustif. En revanche, il s'agit d'une activité qui peut être effectuée en complément des activités décrites dans les chapitres 2.1, 2.2, 2.3, 2.4 afin d'en améliorer l'efficacité (…)".

… mais surtout en annexe B:

"En revanche, l'activité de test d'intrusion ne devrait jamais être réalisée seule et sans aucune autre activité d'audit."

Cette même annexe B rappelle que l'audit "à l'arrache" d'un sous-système juste avant sa mise en production est inefficace, voire contre-productive:

"Les audits devraient être le plus exhaustif possible (…)".

Personne ne me demande mon avis, mais puisque je suis sur mon blog, je vais le donner quand même :)

Il me semble qu'une certification aussi ambitieuse, à destination essentiellement des grosses entreprises, va:

• Disqualifier tout un tas de petits prestataires pourtant très compétents dans leur(s) domaine(s).
• Etre inapplicable en pratique, particulièrement dans la phase d'évaluation des compétences (aussi bien collectives qu'individuelles).

Enfin ce document continue à nier la réalité de l'activité d'audit sécurité, ce dont Cédric s'est par ailleurs ému sur son blog, et ne règle pas le problème du bootstrapping (comment former des auditeurs qualifiés alors qu'il faudrait une vie pour acquérir les compétences recommandées à titre individuel).

Voici donc une proposition alternative:

• Faire du métier d'auditeur en sécurité une profession réglementée (sur le modèle des notaires, des pharmaciens, des médecins, etc.).
• Certifier les personnes sur leurs compétences (un gynécologue n'est pas un urologue), en organisant de réelles sessions d'examens.
• Exiger (éventuellement) un renouvellement périodique de la certification.
• Créer une instance représentative de la profession, qui collecterait tous les rapports d'audit, ce qui permettrait d'avoir un catalogue de produits audités un peu plus étoffé que celui de la CSPN. Cette instance pourrait éventuellement servir d'interface avec les éditeurs logiciels, ou de tiers de confiance pour l'achat/revente de codes d'exploitation (missions qui ne sont pas actuellement dans les compétences du CERTA, sauf erreur de ma part).

Les commentaires sont ouverts.

---

[1] Comme celle du filtrage d'Internet diront les mauvaises langues.
[2] HSC n'en est plus une depuis quelques temps.
[3] Avec un "motif légitime" je suppose.
[4] Curieusement, aucun candidat n'a été capable de reconnaitre une implémentation MD5 en assembleur MIPS à ce jour.
[5] Sauf avec Latex, puisqu'on ne peut pas mettre de couleurs dans les tableaux.
[6] Certains préfèrent le noir pour les failles critiques, les goûts et les couleurs …

Une semaine avec l'iPad

Il se trouve que j'ai récupéré par hasard un iPad, dans des circonstances qui ne peuvent s'expliciter qu'autour d'une bonne bière. N'ayant aucune attente particulière par rapport à cet objet - qui commence à fasciner et inquiéter les entreprises - je vais donc pouvoir en faire un compte-rendu dépassionné et objectif.

Pour commencer, l'engin est assez élégant, quoique pesant. On reconnait la qualité du design Apple, y compris en ce qui concerne l'emballage.

La prise en main est bonne - il y a peu de chances de le laisser choir par inadvertance.

Ce qui ne marche pas

A l'usage, voici plusieurs lacunes qui apparaissent assez rapidement:

1. Tout d'abord, ça n'est pas l'objet ubiquiteux qu'on nous promet. J'ai un toujours un téléphone dans la poche, mais emporter son iPad demande une certaine planification (y a-t-il un vestiaire à destination, etc.). Et le sortir dans le métro pour lire son journal favori relève encore de la science-fiction.
2. C'est très cher à l'usage. Autant l'iPhone nous avait habitués à des applications gratuites (en version bridée, ou financée par la publicité), autant les applications iPad se destinent immédiatement à un public de gens "qui ont les moyens".
3. Même les applications gratuites font un usage intensif du "in app purchase". Laisser ses enfants jouer avec l'iPad peut rapidement se transformer en drame. Le jeu "village des schtroumpfs" en est la caricature: tous les éléments du jeu sont payants. Si les enfants aiment la salsepareille, papa va devoir sortir l'oseille …
4. L'absence de multifenêtrage fait cruellement défaut quand on vient de la bureautique traditionnelle. Impossible de copier/coller rapidement un morceau de texte d'une application dans une autre: il faut suspendre la première application, ouvrir la deuxième, puis revenir à la première …
5. La communication avec le monde extérieur se limite au navigateur Web (impossible de brancher une clé USB par exemple). Du coup la suite d'applications Google devient rapidement indispensable pour entrer et sortir de l'engin (prendre des notes, sauvegarder des signets, etc.)
6. Impossible d'avoir confiance dans les applications disponibles sur l'App Store. Il existe bien des clients RDP et SSH gratuits par exemple, mais il faut réaliser un sérieux background check sur l'éditeur avant de saisir son mot de passe root dans une telle application.
7. Mon efficacité au clavier virtuel reste inférieure à celle d'un clavier réel, en particulier à cause de la séparation entre lettres, chiffres et signes de ponctuation dans trois claviers distincts. Autant dire que taper des lignes de commandes shell avec un clavier virtuel relève de l'épreuve de nerfs. Les gens qui utilisent des mots de passe robustes prennent rapidement l'habitude de les mémoriser dans les applications ...
8. Il est impossible d'imprimer (par exemple un plan Mappy).

Maintenant il est clair que cet objet remplit parfaitement son rôle dans plusieurs domaines.

Ce qui marche

Sa supériorité sur un PC (et sa qualité principale à mon avis) c'est que … ça marche ! Grâce à la maitrise complète du matériel et du système d'exploitation par Apple, et au cloisonnement des applications tierces, plus besoin de se préoccuper d'une incompatibilité entre un antivirus et une protection logicielle par exemple …

Sans parler des problèmes de drivers insurmontables sur PC (surtout depuis la cohabitation entre drivers Windows XP, drivers Windows Seven 32 bits, et drivers Windows Seven 64 bits - lorsqu'ils existent). Sur mon Dell E4300, même en installant la "suite de sécurité Trust Wave Embassy" livrée par Dell, je ne sais pas comment utiliser le lecteur d'empreinte digitale ou le lecteur RFID intégré. Quant au "hub de sécurité Broadcom", il contient des commandes cachées[1], et ne peut être reflashé officiellement que sous MS-DOS. De même pour la carte 3G intégrée[2], qui est horriblement instable par ailleurs.

Alors que sous iPad … tous les périphériques (WiFi, accéléromètre, etc.) fonctionnement out of the box !

La gestion de l'énergie est également un point fort de l'appareil. Plusieurs jours d'autonomie en veille, plusieurs heures en fonctionnement, et surtout un allumage instantané.

A contrario, sous Windows et encore plus sous Linux, la gestion de l'énergie a toujours été un problème insurmontable:

• Autonomie ne dépassant pas les 4h quel que soit le matériel.
• Charge erratique (Windows et Linux ne s'accordent pas sur la capacité et la performance de ma batterie).
• Impossibilité de prévoir l'autonomie réelle lorsque la batterie se dégrade (ce qui arrive de plus en plus rapidement).
• Modes de fonctions incompréhensibles (veille, veille hybride, hibernation) et ne fonctionnant pas toujours (selon le matériel ou le support du noyau).
• Mise en veille ne fonctionnant pas à cause d'un driver bogué.
• Allumage intempestif de la machine (par exemple pour installer des correctifs de sécurité[3]).
• Et surtout … plusieurs secondes pour sortir de veille dans tous les cas.

Dès qu'il me faut consulter rapidement un article ou un plan, je sors désormais l'iPad - je sais que j'en ai pour moins de 5 secondes et que je peux m'interrompre à tout moment sans risquer de tout perdre.

Quant aux logiciels, on trouve par exemple des jeux de qualité tout à fait correcte pour moins de 10 euros. Disponibles immédiatement et sans problèmes de protections logicielles incompatibles.

Enfin l'écran tactile est un must pour les jeunes enfants qui ne peuvent pas se servir d'un clavier et d'une souris. D'ailleurs les éditeurs ne s'y sont pas trompés et proposent de nombreuses applications pour les plus jeunes (livres interactifs, jeux, etc.). En 10 minutes, un enfant de 18 mois maitrise complètement l'interface graphique (y compris l'allumage et le déverrouillage) - il est autonome sur n'importe quel jeu (testé et approuvé).

Conclusion

En bref, l'iPad n'est pas cet engin révolutionnaire et indispensable qui vous est décrit par les fanboys ayant fait la queue pour dépenser leurs 500€ (au bas mot et hors frais d'utilisation).

Mais quand on manipule l'engin au quotidien, on réalise à quel point l'informatique "traditionnelle" s'est endormie dans un statu quo frustrant pour les utilisateurs, qui ont pris l'habitude de travailler avec des systèmes contre-intuitifs, lents et difficiles à maintenir, alors que rien ne le justifie vu l'argent injecté chaque année dans l'industrie logicielle.

C'est pourquoi je ne jetterais pas Chrome OS avec l'eau du bain comme le fait Gartner. En repensant les fondements de l'informatique (mais à quoi peut bien servir un BIOS en 2011 ?) et en s'appuyant sur les interfaces graphiques conviviales du Web 2.0, Google a une chance lui aussi de secouer le cocotier avec un produit un peu différent dans l'esprit (ne serait-ce que par son facteur de forme).

Quant aux entreprises, il leur faudra bien renoncer un jour à leurs applications VB6 et IE6, sous peine de se retrouver avec une informatique tellement dépassée que la "cloudification" massive (et tant redoutée) sera le fait des utilisateurs mécontents. Mais ceci est une autre histoire …

Billet rédigé avec Windows Live Writer 2011

---

[1] http://natisbad.org/E4300/
[2] http://natisbad.org/E4300/Dell_Wireless_5530_AT_cmd_ref.html
[3] http://www.nynaeve.net/?p=160

CyberWar AfterMath

J'ai reçu un abondant courrier des lecteurs (ou plutôt un téléphone arabe des lecteurs devrais-je dire) autour de mon dernier billet, se résumant en gros à un déluge de critiques fondées sur ma prétendue illégitimité dans le domaine (pour simplifier).

Il est vrai que je n'ai pas eu l'occasion de présenter dans des conférences spécialisées, ou de participer à des "cyber-exercices" (même si je vais me permettre de bloguer là-dessus prochainement).

Mais puisque la première cyberguerre mondiale n'a pas encore eu lieu, il me semblait pourtant que mon opinion sur le sujet était tout aussi recevable que celle de n'importe qui - tout le monde en est réduit à des spéculations dans le domaine.

J'oserais même penser qu'en tant que professionnel de l'informatique, mon opinion est plus qualifiée. Car si tout le monde peut intuiter la dangerosité d'une grenade ou d'une baïonnette sans jamais en avoir utilisé une, il en est autrement dans le domaine informatique où aucune analogie avec le monde physique ne fonctionne. Les théoriciens de la cyberguerre n'ont pour la plupart aucune idée de ce qui se produit lorsqu'ils allument leur téléphone ou lorsqu'ils envoient un email. Ce qui les conduit à des conclusions absurdes, comme HADOPI l'installation d'un bot contrôlé par le gouvernement américain sur le PC de tout bon citoyen, ou le bouton rouge qui permet d'arrêter Internet.

Il en est ainsi des domaines techniques comme l'informatique ou la réparation de télé: personne ne peut avoir d'intuitions sans expérience. Le problème c'est qu'en informatique comme dans beaucoup de domaines de la vie courante (l'économie, la politique, etc.), absolument tout le monde a une solide opinion.

La différence entre un professionnel de l'informatique et un technicien, voire un simple utilisateur, est la même qu'entre un prof de maths qui enseigne en prépa et un prof de collège. Le premier doit faire face constamment à des situations qui le poussent aux limites de ses capacités, tandis que le second rabâche à des ignorants des concepts à apprendre par cœur (ton mot de passe doit être complexe, tu ne dois pas le noter sur un post-it, tu dois utiliser un antivirus, etc.).

Bien sûr, dans l'éducation nationale comme dans l'informatique, il existe de vrais passionnés à tous les niveaux, qui s'attaquent à des problèmes non résolus – le plus souvent sur leur temps libre.

Malheureusement, au bout du compte, l'opinion majoritaire reflétée par les médias et couramment admise (même au plus haut niveau) est bien loin des réalités techniques les plus élémentaires. Si vous avez 30 minutes à perdre, et que vous voulez vous payer une bonne tranche de rigolade, je vous conseille de regarder un récent reportage intitulé "les nouveaux pirates de l'informatique", suivi par "alerte à la cyberguerre". C'est disponible partout sur Internet, mais je ne peux pas vous donner de lien ici – seul Google a le privilège d'être au-dessus des lois.

Revenons à nos moutons

Ce débat sur la cyberguerre est né de mes réflexions sur StuxNet. Tout le monde s'extasie sur la "complexité" d'un tel code. Au gré des conférences ou de mes lectures sur Internet, j'ai pu entendre que StuxNet représentait 9 mois*hommes de travail, ou 10 millions de dollars. Ces chiffres sont bien entendu totalement fantaisistes, puisque le pays d'origine du virus – et donc le salaire moyen des développeurs – reste inconnu :)

On peut noter toutefois que la complexité d'un tel code est largement surestimée par les personnes qui ne sont pas des professionnels de l'informatique – tout comme un collégien va trouver la démonstration du grand théorème de Fermat incroyablement complexe, ce qui n'est pas forcément l'avis d'un professeur de prépa.

Prenons le cas du laboratoire privé Sogeti/ESEC. Malgré les fonds et les effectifs limités dont ils disposent, ils viennent pourtant de réimplémenter une attaque sur des cartes réseau, dont l'implémentation précédente était le fait d'un laboratoire de l'ANSSI. Est-ce à dire que "cinq gus dans un garage" peuvent rivaliser avec les services de l'état ? Je pense que oui (au facteur d'échelle près, les ressources de l'état étant illimitées), car la sécurité informatique est avant tout une affaire de matière grise – une ressource impossible à produire et difficile à capter.

Les techniciens informatiques (et a fortiori le grand public) sous-estiment les capacités des "vrais" hackers de plusieurs ordres de magnitude. Un seul homme (ou femme :) vraiment compétent remplace aisément 10 à 100 informaticiens peu motivés comme on en rencontre presque partout. Les exemples de Google (ou de Free) sont là pour nous le rappeler.

Pourquoi on ne voit rien … et ce qui se passe vraiment

Ce biais de perception provient essentiellement de la structuration du monde de la sécurité (aussi appelé le Security Circus).

Il faut bien comprendre que toutes les publications (dans les magazines ou les conférences) sont intrinsèquement sans valeur: ce ne sont ni des résultats produits pour des clients, ni des attaques dangereuses ou illégales, ni des technologies revendables ou brevetables.

Tout ce qui est réellement dangereux, parfois à la limite de la légalité, passe complètement en dessous du radar et "n'existe pas" pour la presse et le grand public en général. Et pourtant cette "masse manquante" représente l'essentiel des travaux produits par les professionnels de la sécurité dont l'activité présente suffisamment d'intérêt pour être financée (c'est-à-dire ceux qui en vivent d'une manière ou d'une autre).

Vu de l'extérieur, ceci donne l'impression que ce petit monde ronronne gentiment, de sauteries en conférences, sans vraiment empêcher le business de tourner rond. Ce qui est loin d'être représentatif de l'état de la menace aujourd'hui …

En vérité, tous les systèmes connectés à Internet sont sous le feu permanent d'intrus (qu'on va appeler "les chinois" pour simplifier – et c'est probablement d'ailleurs le cas). Suis-je mythomane ? Probablement pas, car j'ai eu l'occasion de les rencontrer "pour de vrai" à plusieurs reprises …

La véritable cyberguerre a déjà commencé, mais elle ne ressemble pas à ce qu'on nous présente d'habitude (pays désorganisé, infrastructures critiques en panne, etc.). Pour cela, quelques centimètres de neige suffisent :)

La véritable cyberguerre, c'est le pillage systématique de toutes les ressources technologiques occidentales par des individus entrainés, opiniâtres, et opérant en dehors de toute juridiction. Toutes les entités, des instances étatiques à la plus petite PME, sont victimes de ce ratissage systématique opéré par des attaquants qui ne connaissent pas le repos ni la compassion.

Là où les cybergénéraux attendent des DDoS massifs, par analogie avec les bombardements bien connus dans le monde physique, le réel danger provient de la cinquième colonne qui a probablement infiltré tous les systèmes connectés à Internet à l'heure où j'écris ces lignes (l'opération Aurora n'étant que la partie émergée de l'iceberg).

Une autre cyberguerre est possible

Ce qui se passe actuellement avec le site WikiLeaks me semble également relever de la cyberguerre, du moins de l'attaque non conventionnelle.

En me gardant bien de me prononcer sur le fond, cet épisode met en évidence la dépendance très forte du "cybermonde" vis-à-vis d'entités commerciales américaines bien réelles (à savoir EasyDNS, Paypal, MasterCard, Visa, … dans le cas présent).

Sans rentrer dans des scénarios trop compliqués, on imagine assez aisément que si demain un secrétaire d'état américain demande à l'ICANN, Microsoft, VeriSign, Cisco, et tous les opérateurs Tier-1 américains de bloquer les infrastructures d'un pays occidental, le résultat risque d'être assez catastrophique … et ce sans utiliser un seul virus !

Tout comme la redirection de l'Internet mondial au travers d'un opérateur chinois pendant une vingtaine de minutes (avril 2010) expose une autre fragilité rarement abordée dans les cyberdoctrines: BGP.

Conclure sur StuxNet

Le sabotage informatique est une activité à peu près aussi ancienne que l'informatique. En 1982 déjà, l'explosion d'un pipeline russe a très probablement été provoquée par le sabotage d'un système SCADA par la CIA. On doit pouvoir trouver des exemples similaires du côté de la fusée Ariane, même s'ils ne sont pas sur Wikipedia.

Aujourd'hui le PC sous Windows XP est effectivement devenu le consommable de base qui permet de contrôler à peu près tout et n'importe quoi. Un sabotage réussi aura toutes les chances d'impliquer de l'informatique à un moment ou un autre. Mais cela n'a rien de "magique" ou d'exceptionnel: c'est un métier !

Il est déjà assez simple (dans la plupart des cas) d'analyser des systèmes "fermés", comme le démontrent toutes les conférences de sécurité ces 15 dernières années, au cours desquelles les sujets les plus divers ont été abordés: logiciels propriétaires bien sûr, mais aussi faiblesses de conception des architecture PC, modems/routeurs, téléphones, consoles de jeu, radiocommunications comme le GSM ou le RDS/TMC, puces RFID, TPM, satellites, etc.

Si un étudiant arrive à pirater l'iPhone et la PlayStation 3 (avec un hyperviseur matériel conçu par IBM), on peut supposer que n'importe qui est capable de pirater un système SCADA avec très peu de moyens.

Mais si j'étais demain à la tête de l'opération "StuxNet 2", je ne m'embarrasserais pas des détails. Avec ses 427,000 collaborateurs, on peut supposer qu'il n'est pas trop difficile de pénétrer le réseau interne de Siemens. Il suffit ensuite d'aller y chercher la documentation et les codes sources nécessaires. Comme 100% des tests d'intrusion internes sont couronnés de succès, il n'est pas trop difficile d'être optimiste.

La présentation donnée par Val Smith lors de BlackHat 2010 sur le dynamisme de la "scène" chinoise permet de se rendre compte à quel point de telles opérations sont monnaie courante ... même si personne n'en parle.

Conclusion

Avant de coller le préfixe "cyber" à toutes les sauces, il est recommandé de passer le test suivant.

Car si une chose telle que la "cyberguerre" existe, elle ne ressemble ni à un DDoS, ni à StuxNet.