mardi 17 septembre 2013

Fiat Lux

J’ai assisté à la réunion d’information PASSI du mardi 10 septembre dernier. Et je n’étais pas le seul. Vu l’épaisseur du listing au point de contrôle, il devait bien y avoir 500 personnes invitées, pour une centaine effectivement présentes dans la salle.

Personnages principaux

Pour cette réunion clé dans le paysage de la prestation de services en SSI, il faut admettre que l’ANSSI avait réellement effectué un travail amont de fourmi en recensant toutes les structures qui réalisent des audits de sécurité en France. SSII de toutes tailles, freelances, et même associations – Club PSCO, CESIN, OSSIR, CLUSIF, Club 27001 – à l’exception notable des FPTI (canal historique ou pas).

Sur scène :

  •  Contre-amiral Dominique Riban (directeur adjoint de l’ANSSI)
  • Yann Tourdot (ANSSI)
  • Armelle Trotin (LSTI)
  • Hervé Schauer (HSC)
  • AMOSSYS
L’absence de Sogeti/ESEC, troisième larron de la procédure expérimentale, a été remarquée. Y avait-il un message politique ?

Hervé Schauer a été égal à lui-même, et nous a gratifié des quelques saillies drolatiques telles que « je ne sais pas combien ça a coûté car je n’ai jamais été très fort en comptabilité analytique » ou « vous n’avez pas besoin de formation pour présenter le PASSI mais on est prêt à vous en vendre quand même ».

Enfin il faut rendre hommage au maitre de cérémonie - Yann Tourdot - qui a encaissé pendant presque 3 heures le feu roulant des questions de la part d’un public pas vraiment conquis (c’est un euphémisme) avec un calme olympien. Je cherche encore à découvrir le secret de cette incroyable résistance au troll : pratique de la méditation Asubha ou perfusion de Lexomil ?

Acte 1 : le message est délivré

Les hostilités démarrent à 14h, modulo les quelques minutes de retard de M. Schauer. Le contre-amiral Dominique Riban nous remémore par son bref exposé que l’ANSSI est la digne héritière de la DCSSI. On ne va pas parler audit de code Java ou recherche de XSS dans des applications PHP – non, nous sommes ici entre représentants de la « chaine de cyberdéfense » (le terme a été employé une bonne demi-douzaine de fois).

Son allocution brève et précise délivre la clé du PASSI en quelques minutes seulement : l’ANSSI pourra se faire remplacer dans ses interventions par un PASSI de son choix, au TJM de 1000€/jour (indexé sur le point de la fonction publique), et ce pour une durée illimitée. Car malgré un effectif cible de 500 personnes à horizon 2015, l’ANSSI est débordée par la situation calamiteuse dans les administrations et les grandes entreprises françaises (sans toutefois oser employer le mot d’échec de la sécurité).

J’aurais alors pu me lever et partir à la suite du contre-amiral, mais j’aurais peut-être eu l’impression d’avoir fait le déplacement pour rien (d’autant qu’il n’y avait ni café ni goodies). Je restais donc pour l’acte 2, durant lequel les détails d’implémentation allaient être âprement débattus.

Acte 2 : la principale subtilité

Mon objectif n’est pas de retranscrire ici deux heures de questions par ordre chronologique, mais plutôt par ordre de pertinence.

L’un des points essentiels qui a été soulevé concerne le niveau de technicité recherché chez les auditeurs (tout le monde connaît la rigueur des entretiens d’embauche à l’ANSSI). L’objectif du PASSI est de labelliser des prestataires de confiance, non pas de trier sur le volet les meilleurs experts français. La différence est subtile ; sans vouloir faire de mauvais esprit je pense qu’elle conduira les usual suspects à être automatiquement labellisés indépendamment de leur capacité à délivrer une prestation de qualité.

Acte 3 : le diable est dans les détails

Le schéma de certification est un processus assez lourd, à l’instar du transparent consacré au sujet. Pour obtenir le précieux sésame, l’entreprise devra se faire auditer, et disposer de consultants labellisés dans les domaines pour lesquels elle candidate (audits organisationnels, audit de code, etc.).

En ce qui concerne l’entreprise, elle devra se plier à un audit de son réseau interne, et démontrer que le service « audits et tests » n’a aucune adhérence avec le reste de l’entreprise, considéré comme « hostile ». Curieuse approche qui consiste à laisser les auditeurs gérer eux-mêmes leur infrastructure ; on sait pourtant qu’ils ne sont pas les premiers à appliquer les conseils qu’ils donnent aux autres.

Le niveau d’exigence n’a pas été clairement défini, mais des gros mots ont été utilisés, tels que « produits certifiés » ou « IPSEC ». On peut s’attendre toutefois à un saut qualitatif par rapport aux pratiques actuelles, car il a été évoqué le fait que les tests et la rédaction du rapport devaient être réalisés sur deux machines distinctes, l’auditeur n’étant pas administrateur de la deuxième. Par ailleurs tous les échanges de documents avec les clients devront être chiffrés, ce qui promet des heures d’amusement compte-tenu du niveau d’interopérabilité entre les différentes solutions.

En ce qui concerne les personnes, elles devront passer un examen écrit (de type QCM) et un examen oral par catégorie. Visiblement le taux de succès selon les catégories varie entre 50% (test d’intrusion) et 90% (audit organisationnel) ; en phase expérimentale 15 consultants ont été labellisés sur le test d’intrusion.

Pour l’anecdote, bien qu’elle se défende avec véhémence de piller les ressources du privé, l’ANSSI a d’ores et déjà recruté la majorité de ces consultants. Par contre l’histoire ne dit pas ce qu’il est advenu des autres… qui peuvent toutefois retenter leur chance jusqu’à 2 fois par an.

Une fois l’étape initiale franchie, il reste pour l’entreprise à payer un audit de contrôle tous les 18 mois et un audit de re-certification tous les 3 ans, sauf si un événement vient à remettre en cause la labellisation, comme par exemple le départ de tous les auditeurs dans une activité donnée.

Tout ceci a bien évidemment un coût, à propos duquel il a été difficile de tirer les vers du nez de LSTI, qui est de facto la seule société habilitée à dérouler la procédure de labellisation.

Une estimation grossière donne 6 jours pour l’audit de l’entreprise et environ 600€ par consultant présenté à l’examen, ce qui reste modeste. Mais de l’aveu même des participants au programme beta, le temps de préparation est considérable, aussi bien pour l’entreprise que pour les candidats. Ce qui fait dire à un participant : « c’est le même prix qu’un stand aux Assises, mais avec un ROI moins évident ».

Acte 4 : il est frais mon label

L’implémentation retenue par l’ANSSI est la suivante : une « attestation de compétences » est remise à l’auditeur labellisé. Il peut s’en prévaloir lors de la réponse aux appels d’offres, mais la liste des auditeurs certifiés reste « secrète ». Ce qui veut dire qu’elle ne sera pas publiquement affichée ni sur le site de l’ANSSI ni sur le site des entreprises labellisées, mais aucune sanction n’est prévue s’il se crée demain un groupe LinkedIn des auditeurs PASSI. Une sorte de secret de polichinelle, donc.

L’ANSSI, soucieuse d’éviter la débauche de personnel (ou pas), précise que l’attestation de compétences n’est valable que pour exercer dans l’entreprise qui l’a financée. Si l’auditeur change d’entreprise, il devient automatiquement « incompétent », mais peut être admis à repasser l’examen.

Détail amusant : afin d’éviter les conflits d’intérêt lors des audits de labellisation, LSTI a choisi de faire appel à des profs (voire des étudiants). « Ce n’est pas de la sous-traitance, c’est du mandatement » nous signale Armelle Trotin. Comme quoi il peut exister des passerelles entre l’industrie et le monde universitaire !

Acte 5 : le futur

Bien entendu tout ceci n’a de sens que si le RGS 2.0 est publié un jour, puisque le PASSI ne sera contraignant que pour les victimes de ce document. L’ANSSI est confiante dans le fait que ce document verra le jour « avant 2015 ». Avec un délai de 5 ans entre la publication du RGS 1.0 et le décret d’application, on est en droit de ne pas partager le même optimisme.

Néanmoins l’ANSSI poursuit dans sa lancée afin d’adresser toutes les activités de la « chaine de cyberdéfense ». Après la prévention avec les audits et tests d’intrusion (si tant est que cela prévienne quoi que ce soit), des labels vont être créés pour les prestataires en détection d’intrusion (SOC), en investigation (forensics) et en reconstruction – ainsi que dans un tout autre domaine, celui du Cloud.

Petite anecdote : il est d’ores et déjà prévu de tester les candidats dans ces catégories sur leur capacité à rétro-concevoir des échantillons de malwares. Une double révolution culturelle est donc en marche …

Conclusion

Une poignée de sociétés ont d’ores et déjà fait la démarche de candidater à la procédure PASSI « finale ». Toutefois pour l’écrasante majorité des prestataires avec qui j’ai pu discuter en « off », il est urgent d’attendre. Les coûts engendrés sont considérables eût égard au volant d’activité que représentent réellement les clients soumis au futur RGS 2.0. Même les appels d’offres publics les plus récents – dont certains sont des contrats « cadre » sur 4 ans – ne font aucune mention du PASSI.


A moyen terme, on risque donc de voir le marché se fragmenter entre quelques « gros » opérateurs, qui pourront être imposés par l’ANSSI chez certains « clients » (essentiellement les OIV), et le reste des SSII qui continueront à traiter 95% des affaires courantes. Tout ça pour ça.

lundi 9 septembre 2013

PASSI cool

Vous rêvez d’une carte de visite à rallonge – CISSP CEH MCSA CCNA – mais vous n’avez pas les moyens de cotiser à la fois à l’ISC2, à l’EC Council, chez Microsoft, et chez Cisco ? Rassurez-vous, grâce à l’ANSSI vous aurez bientôt la classe américaine. Après les certificateurs ARJEL, les laboratoires d’évaluation CSPN, les PSCE, les PSHE, le nouveau titre à la mode s’appelle PASSI (ce qui est – vous en conviendrez – beaucoup plus facile pour les jeux de mots). D’autres suivront, tels que les opérateurs certifiés de sonde ANSSI, les prestataires certifiés de réponse à incident, etc. mais il conviendra d’en parler en son temps.

Il n’y a PASSI longtemps (à l’échelle administrative)

Souvenez-vous, il y a deux ans : trois sociétés – Sogeti/ESEC, HSC et AMOSSYS – étaient retenues pour « beta-tester » la procédure expérimentale. Après moult péripéties, la phase de test est déclarée concluante, et la procédure de labellisation officiellement « bonne pour le service ».

Je ne voudrais pas ennuyer le lecteur avec tous les réglages techniques qu’il est nécessaire d’apporter pour mettre au point une telle mécanique, mais je vous laisse vous délecter de cette anecdote : pour valider la certification, un inspecteur de l’ANSSI doit assister à une prestation en conditions « réelles » chez un client. On imagine les difficultés du pauvre prestataire qui essaie de vendre à son client que s’il est retenu, il faudra faire ménage à trois avec l’ANSSI. Une fois le client enfin convaincu, il reste un détail à régler : l’administration ne se déplace jamais en province car … elle n’a pas de processus pour établir des notes de frais !

Un exercice de PASSIence

Bref, la certification entre en service. Petit détail (mais qui a son importance) : après avoir gracieusement travaillé pendant plus d’un an pour l’administration, tous les prestataires de service retournent désormais à la case départ. Il n’existe aucun prestataire officiellement labellisé actuellement.

La re-certification, une simple promenade de santé pour les vétérans du programme « beta » ? Pas vraiment, car chez la majorité d’entre eux, le turn-over a frappé : plus aucun consultant ayant participé à la phase expérimentale n’émarge encore aux effectifs …

On touche ici l’une des limites (prévisibles) de l’exercice : comment délivrer un label à une entreprise dans sa globalité, alors que ce sont des personnes qui sont auditées ? N’est-ce pas un manque de clairvoyance sur le consultant en SSII, dont l'objectif principal est de s'en évader ? Et pour une fois, le système PCI-DSS – avec sa liste de consultants accrédités intuitu personae – ne serait-il pas plus cohérent ?

PASSI rentable

Autre détail qui a son importance : depuis que le processus de labellisation est « en production », celui-ci est entièrement délégué au secteur privé. L’organisme certificateur est évidemment la société LSTI – qui dispose d’un monopole de fait sur l’activité de certification en France dans de nombreux domaines.

Et donc, la certification est payante. Voire pas donnée, compte-tenu des coûts annuels liés au maintien de la certification. Vous n’avez pas voulu cotiser à l’ISC2, vous participerez au redressement productif.

Pour les petites sociétés, l’équation n’est pas évidente : entre le coût de préparation, le coût de passage, et les coûts récurrents liés à la certification, il faut vraiment aimer les appels d’offres publics pour rentrer dans ses frais. Et savoir fidéliser ses consultants certifiés, tout en leur faisant quand même faire un peu d’EBIOS en régions. Bref, le mariage de la carpe et du lapin.

Car bien sûr, le « label » PASSI n’a des valeur contraignante que pour les administrations qui doivent se conformer aux RGS et donc recourir exclusivement à des prestataires labellisés. Du moins quand le RGS 2.0 entrera en vigueur, ce qui laisse le temps de la réflexion, celui-ci étant en relecture à Bruxelles.

Pour tous les autres appels d’offres, on peut supposer que le label PASSI sera un nice to have. Enfin comme d’habitude, la réponse sera jugée selon les critères suivants : prix 90%, bullshit (dont les labels) 10%.

Vous l’aurez compris, le point d’inflexion sera atteint dans les prochains mois. Les prestataires vont-ils jouer le jeu, dans un contexte économique difficile où les marges diminuent sans cesse ? Les administrations vont-elles jouer le jeu, au risque de se faire dépouiller par les mastodontes habituels ? Est-ce qu’un tel label est de nature à conserver la compétence technique en France et stimuler les PME ultra-pointues, comme il en existe quelques-unes en sécurité informatique ?

PASSI vite

Il s’agit d’une vraie question, car autre chose a fondamentalement changé depuis deux ans : tout le monde a compris que la sécurité était un échec. Pas une table ronde, pas une WebTV, pas un éditorial qui ne surfe sur ce concept. Ou plutôt devrais-je dire : « la sécurité informatique défensive » est un échec.

Il y a dix ans, on pouvait faire briller des étoiles dans les yeux d’un jeune sorti d’école en lui proposant un poste de pentester. Aujourd’hui il sourit gentiment en disant « merci mais je préfère aller chez VUPEN ». Un poste de RSSI, n’en parlons même pas.

Même l’ANSSI, qui a jouée les vierges effarouchées tant de fois à SSTIC, a finalement choisi « l’option offensive » : la future Loi de Programmation Militaire s’apprête à en faire le shérif de l’Internet. Quoi de mieux pour attirer les derniers jeunes qui hésitaient encore à quitter leur SSII, sinon que le frisson de la cyber-action ?

En clair, si à 30 ans t’es PASSI, t’as raté ta vie. Ou pas loin.

Conclusion

Pour une fois je vais mouiller la chemise et me lancer dans l’exercice périlleux de la futurologie.

Je pense qu’il y aura des sociétés labellisées PASSI d’ici quelques mois (au mieux). Mais que la prestation de service labellisée restera un marché de niche dans lequel se retrouveront piégées quelques administrations. Et que les prestataires eux-mêmes finiront par jeter l’éponge si les règles sont appliquées de manière trop stricte (comprendre : s’il faut vraiment démontrer une compétence pointue et continue).

Je pense que le seul qui profitera à coup sûr du système sera le vendeur de pioches, comme dans toutes les ruées vers l’or.

Je pense que l’ANSSI n’aura jamais le courage politique de retirer le label à un quelconque acteur majeur du domaine, ce qui aura pour conséquence de dégrader lentement mais irrémédiablement le fondement même de la labellisation comme processus de création de confiance. C'est ce qui se passe actuellement – mais dans une moindre mesure, car il ne s'agit que de produits – avec la CSPN.

Je pense que dans cinq ans, les seuls endroits où se pratiquera encore de manière professionnelle la sécurité informatique en France seront les acteurs de l’offensif (ANSSI, DGSE, DGA … ainsi que quelques privés comme VUPEN). Aucun jeune ne fera l’effort nécessaire pour se mettre à niveau sur les technologies actuelles avec pour seul horizon de piloter une analyse EBIOS ou une matrice de couverture des risques. Le métier d’auditeur en sécurité dans le privé – s’il existe encore – se réduira à l’utilisation d’outils simples tels que pst2ppt (ou l’inverse).

Sur ce, souhaitons que l’ANSSI s’attaque à un chantier encore plus fun : labelliser les RSSI :) Et à demain pour la réunion de lancement du PASSI.


Déni de responsabilité : je ne suis pas prestataire de service, je n’ai aucunement contribué au PASSI (sauf par mes écrits), je ne dispose d’aucun canal d’information en dehors des circuits publics, tous les propos retranscrits dans cet article ont été collectés sous l’emprise de l’alcool, donc certainement faux. Ou pas.

lundi 29 juillet 2013

Vers une certification … utile

Contexte

Avec les nouvelles CSPN très symboliques délivrées ces derniers mois, il apparaît clairement que la certification sécurité de produits logiciels est une activité politico-marketing, dont l'efficacité réelle a largement été battue en brèche lors de la conférence SSTIC 2013.

Les questions fondamentales qui se posent alors sont les suivantes : est-il possible d'améliorer la sécurité des logiciels commerciaux ? D'aider à la sélection des meilleurs, lorsque ni Darwin, ni la main invisible du marché n'y arrivent ? Et si oui, par quel miracle ?

La sûreté logicielle est un domaine curieux. La majorité des problèmes avaient été résolus il y a 30 ans. La quête de la perfection a produit les langages formels, la preuve de programme, ainsi que des certifications fiables - comme la DO-178 en aéronautique. L'ANSSI semble d'ailleurs redécouvrir aujourd'hui que les systèmes critiques sont programmés en ADA. L'industrie informatique était alors à son apogée. On entrait dans les salles machines en blouse blanche, et les informaticiens étaient promis à de brillantes carrières dans leurs entreprises respectives. Bref, le paradis originel.

Puis tout a basculé avec l'informatique personnelle. En quelques années, tout le monde est devenu informaticien. Les systèmes MS-DOS, puis Windows 3.1, sont devenus des références pour le grand public, habituant les utilisateurs à tolérer les bogues et les redémarrages intempestifs. La science informatique est devenue une commodité dont la valeur ajoutée a été remise en cause, jusqu'à être complètement niée, ouvrant la voie à l'externalisation puis à la "cloudification", voire au BYOD, qui sont les négations suprêmes de toute forme d'informatique interne.

Ce billet ne va donc pas essayer de résoudre un problème qui n'existait pas avant d'avoir été inventé. Il va juste pointer les défauts du processus de certification actuel, en proposant (une fois n'est pas coutume) des solutions concrètes.

Point de vue de l'éditeur

Pour l'éditeur, l'équation est simple : une CSPN coûte environ 30k€ et permet de mettre le logo "ANSSI" sur toutes ses plaquettes commerciales.

Même si le produit n'a aucune qualité, deux ou trois itérations sur la cible de certification permettront d'obtenir le précieux label sur un périmètre tellement contraint que l'échec est impossible. Rappelons que Windows NT4 est certifié "C2" (soit EAL4) sur un système qui n'a pas de lecteur de disquette, de lecteur de CD-ROM, ni de carte réseau.

Au pire le produit est une bouse innommable qui échoue même à remplir les fonctions de sécurité élémentaires pour lesquelles il a été conçu. Il n'obtiendra donc (probablement) pas la certification, mais personne n'en saura jamais rien.

Point de vue de l'auditeur

Pour l'auditeur, l'équation est plus compliquée, car elle fait intervenir son "éthique" (une notion si difficile à définir) …

La première réaction d'un auditeur qui découvre une faille peut être de la garder sous le coude. Car cela lui permettra de "réussir" tous ses pentests futurs dans le même environnement. Et après tout, No More Free Bugs.

Supposons maintenant que l'auditeur décide de remonter les failles de sécurité. C'est une obligation pour les sociétés certifiées PASSI (certification qui va être un échec, mais ceci est une autre histoire Sourire).

La communication avec le vendeur est la suivante : "Votre produit souffre d'un Cross-Site Scripting (XSS). Voici une preuve de concept en Python permettant de reproduire la faille."

Et là, tout est possible …

  • Réponse A : "C'est quoi Python ?"

Décision : vendez la faille au plus offrant. Vous allez perdre du temps avec cet éditeur, au pire il va vous menacer.

  • Réponse B : "Ok c'est corrigé."

Décision : ditchez le produit ("poubellisez" n'ayant pas encore été validé par l'Académie Française). L'éditeur a probablement utilisé un hack sordide pour corriger la ligne de code qui pose problème, afin de passer le test. La faille sera réintroduite dans la prochaine version du produit.

  • Réponse C : "Ok merci. Qu'est-ce que vous recommandez comme librairie de filtrage ? Est-ce que OWASP ESAPI est efficace contre cette attaque ?"

Décision : gardez le produit. Il y aura probablement d'autres failles, mais l'éditeur connaît son métier.

  • Réponse D : "désolé l'outil d'analyse statique que nous utilisons en intégration continue avait détecté le problème, mais le développeur a fermé le ticket sans corriger. Il sera durement châtié."

Décision : appelez moi. Vous êtes probablement en communication avec des entités extraterrestres chargées d'asservir les humains par la technologie.

La clé du problème

Le fond du problème, c'est que les audits de sécurité ne servent à rien. D'ailleurs en ce qui me concerne, j'ai arrêté le pentest. Désormais les tâcherons de l'informatique (souvent appelés "chef de projet Java" Sourire), frappés de cyber-superstition savamment entretenue par les technomanciens et autres cyber-charlatans, déposent leurs enfants accouchés dans la douleur (certains projets informatiques prennent largement plus de 9 mois) devant l'antre de la Sybille. Je questionne la pureté de leur cœur, et prononce (parfois) la sentence fatidique: "il vivra".

Mais quel est le secret de la clairvoyance ? Comment auditer un logiciel par des méthodes plus proches de la thérapie analytique que du reverse engineering ?

L'édition logicielle c'est la vie: tous les projets naissent égaux, mais certains sont plus égaux que d'autres. Car un CMS peut être né en Erlang, ou en PHP. Et born in PHP, born dead.

Pour juger de la qualité d'un produit, il est inutile de se focaliser sur les failles d'implémentation. Certes je ne nie pas l'élégance d'une exploitation de faille particulièrement ardue, mais les bonnes questions à se poser sont d'abord les suivantes :

  • Quelle est l'origine du projet ? S'agit-il du travail d'un stagiaire hâtivement rebaptisé "produit" ? Quel est l'historique de l'entreprise ?
  • Quels sont les choix technologiques opérés ? Sont-ils subis (ex. PHP c'est gratuit, Java tout le monde connait) ou choisis ?
  • Quels sont l'environnement et les méthodes de développement mises en œuvre ? Quelles sont les options de compilation utilisées ?
  • Quelle est la liste du code tierce partie et/ou Open Source intégré au produit ? L'éditeur est-il seulement capable d'en fournir la liste ?
  • Y a-t-il une équipe sécurité côté vendeur ? Y a-t-il eu des bulletins de sécurité publiés ? La liste des alertes de sécurité est-elle claire et facilement accessible ?

Mes plus grand succès en pentest ne sont pas d'avoir réussi à pénétrer un OpenVMS depuis un accès FTP anonyme, ou d'avoir analysé un firmware inconnu over the night dans une chambre d'hôtel. Mes plus grands succès sur le long terme sont d'avoir réussi à convaincre un éditeur d'effectuer une montée de version sur Visual Studio, ou d'appliquer le template SiteLock sur un contrôle ActiveX. Car indépendamment des failles d'implémentation qui restent à découvrir, cela démontre une maturité de l'éditeur sur le sujet, et procure des bénéfices beaucoup plus larges que la correction d'une faille unitaire.

A contrario, j'ai du mal à imaginer comment on peut certifier sans réserve un produit qui expose d'emblée une interface Web en PHP à des utilisateurs non authentifiés. Rien que la lecture du changelog PHP donne une idée du nombre de failles qui affecteront la version "certifiée" d'un tel produit. Sans parler des mécanismes "annexes" tels que la mise à jour, la vérification de licence, le reporting ou l'administration distante – presque toujours exclus du périmètre – et pourtant risques majeurs pesant sur la sécurité du système.

Pour avoir une certification qui fonctionne, il faut juger l'esprit d'un produit plus que son implémentation.

Des propositions concrètes

Maintenant que tous les biais du système ont été identifiés, voici des propositions concrètes qui permettraient de rendre la certification plus efficace à mon sens.

Mettre la pression sur les éditeurs

Le choix d'entrer en CSPN doit être une décision lourde de conséquences. L'une des mesures "phare", toujours réclamée, mais jamais obtenue, serait de publier la liste des produits "recalés" (assortie des motifs). Sous cette hypothèse, aucun éditeur ne s'amuserait à soumettre un produit dans lequel il n'a qu'une confiance limitée.

L'un des problèmes de fond est la valeur de la CSPN dans le temps. Certes un produit peut être conforme à un instant T selon l'avis d'un expert X, mais l'état de l'art évolue et tous les logiciels ont (et auront) des bogues. Comment faire en sorte que le travail réalisé sur une CSPN donnée puisse encore signifier quelque chose 6 mois après ? Un produit certifié CSPN il y a 10 ans, à base de DES et MD5, figurerait-il encore en bonne place sur le site de l'ANSSI ? (Notons que c'est le cas pour certains produits certifiés Critères Communs qui ne sont pourtant plus du tout à l'état de l'art).

La valeur d'une évaluation s'effrite avec le temps. Dans un autre domaine, CVSS définit un facteur "temporel" sur la criticité des failles. Voici quelques idées pour transposer le concept à la CSPN :

  • Borner dans le temps la validité d'une évaluation, par exemple à 3 ans. Au-delà, le produit devrait passer par une phase de re-certification, ou bien perdre son "tampon".
  • Obliger les éditeurs à commercialiser la version certifiée pendant toute la durée de validité du certificat, avec support technique et maintien en condition de sécurité (MCS). Après tout, on oblige bien les boulangers à fabriquer un quota de baguettes au prix réglementé.

Car la plupart des produits figurant sur le site de l'ANSSI ne sont tout simplement plus disponibles dans la version certifiée ; il existe même parfois plusieurs versions majeures d'écart. Ce qui conduit à des incompréhensions entre l'auditeur (qui découvre que la version qu'il audite est une passoire) et l'administration (qui confirme que la version "tamponnée" était bien meilleure).

Au final, comme il faut bien annoncer au client que la sécurité de son réseau est affaiblie par l'utilisation d'un produit CSPN, alors que n'importe quel produit standard de l'industrie aurait fait l'affaire, c'est un coup fatal qui est porté à tout le processus de création de confiance.

  • Suspendre ou révoquer la certification en cas de faille identifiée a posteriori, ou d'évolution majeure du produit (ex. montée de version obligatoire pour les clients).

(Accessoirement, on peut déplorer le fait que les versions auditées ne soient pas archivées par l'ANSSI dans une démarche d'investigation a posteriori, pouvant éventuellement conduire à la révocation d'un certificat.)

  • Publier le rapport d'audit technique complet. Ceci permettrait à chacun de se faire une idée ce qui a été réellement testé, ce qui a été laissé de côté, ainsi que les choix d'implémentation de l'éditeur.

Car personnellement, savoir si la couche cryptographique repose sur OpenSSL ou sur GnuTLS me donne une bonne idée sur la sécurité future d'un produit. Plus qu'un "avis d'expert : le produit est conforme à la cible de sécurité" en tous cas …

  • Ne pas accepter les certifications en "boite noire".

Il faut arrêter de se retrancher derrière la propriété intellectuelle et autres arguments juridiques, donc fallacieux : tout ça c'est du pipo pour les attaquants. Tous les consultants en sécurité sérieux pratiquent le reverse engineering, y compris dans des pays où la législation applicable est pourtant contraignante. Quant aux attaquants, ils vont plus loin et n'hésitent pas à pirater les éditeurs s'ils ont besoin d'accéder au code source.

Toute évaluation doit être effectuée par démontage total du matériel et du logiciel, facilité par l'éditeur si besoin. Bienvenue dans la "vraie vie".

(Note : je ne sais pas comment se passe réellement le processus de certification, mais on a parfois l'impression que le test a été réalisé en pure boite noire. exec.php FTW !)

Personne ne lit les cibles de sécurité

C'est un fait : personne ne lit les cibles de sécurité. Heureusement d'ailleurs, car on y trouve des énormités du style "notre produit protège le système, mais seulement s'il n'est pas compromis". Seriously.

Il est totalement indispensable pour la crédibilité de la CSPN que les cibles de sécurité n'aient pas besoin d'être lues par les utilisateurs. Que le produit soit "raisonnablement sûr" dans le cas d'usage le plus courant (principe de moindre surprise), pas dans une configuration obscure potentiellement non supportée par l'éditeur.

Les cibles de sécurité ne devraient pas être rédigées par les éditeurs, mais par les utilisateurs. Pour aller plus loin, on pourrait même imaginer que les certifications ne puissent pas être réalisées à la demande d'un éditeur, mais nécessairement d'un client final (qui peut être l'ANSSI elle-même) …

De l'importance de l'écosystème

Un produit logiciel n'existe pas ex nihilo. Il vient avec tout un écosystème : matériel, système d'exploitation, mises à jour, télémaintenance, etc. Or les failles les plus triviales (ou les plus efficaces) à exploiter sont parfois à chercher dans les catégories suivantes :

  • Mises à jour : le produit supporte-t-il les mises à jour automatiques ? Sont-elles actives par défaut et/ou obligatoires ? Sont-elles sécurisées (ex. signature) ? Le serveur de mise à jour est-il chez OVH ? Le retour à une version antérieure (downgrade) notoirement boguée est-il possible ?
  • Télémaintenance : le produit a-t-il des fonctions de télécollecte (ex. statistiques d'utilisation), voire de prise en main à distance ? Le produit doit-il être connecté à un serveur de licences sur Internet ?
  • Secrets de l'éditeur : y a-t-il un seul mot de passe "root" pour accéder à tous les logiciels du même vendeur ? (Variante : un générateur de mots de passe reposant sur un algorithme trivial). Y a-t-il des "backdoors" - à des fins de support technique bien sûr ? Les clés cryptographiques servant à signer les mises à jour sont-elles bien protégées ?
  • Sécurité de l'éditeur : l'éditeur est-il en mesure d'assurer la sécurité de ses infrastructures de développement et de support ? Un éditeur de produit CSPN ne devient-il pas automatiquement OIV ? Faut-il révoquer la certification en cas de compromission de l'éditeur ?

Utiliser le crowdsourcing

Concevoir et implémenter des logiciels robustes est une tâche ardue dans laquelle presque tous ont échoué. Identifier de manière exhaustive les problèmes de sécurité dans un logiciel complexe en moins d'un mois est une tâche impossible.

C'est pourquoi il ne faut pas avoir la prétention d'y arriver seul, mais au contraire exploiter la horde grouillante et infatigable des auditeurs en sécurité, qui besognent à longueur de journée les mêmes produits chacun dans leur coin (mais pour des clients différents).

Aujourd'hui la meilleure tactique pour un consultant en sécurité qui empile les failles consiste à les vendre à des tiers (essentiellement américains) ou à les garder sous le coude pour réussir son prochain audit – du même produit mais chez un autre client.

Les auditeurs certifiés PASSI ont déjà l'obligation de remonter gracieusement les failles découvertes au CERTA – mais il est probable que le nombre de certifiés PASSI (qui est nul aujourd'hui, la phase expérimentale venant seulement de se conclure) ne va pas exploser pour des raisons que j'évoquerai à la rentrée dans un autre billet.

Il reste donc à affiner la deuxième approche : mettre en place un Bug Bounty au niveau de l'ANSSI Sourire

La solution ultime

Le lecteur qui a eu le courage et la patience d'arriver jusqu'ici découvrira enfin la solution ultime permettant de résoudre tous les maux évoqués ci-dessus : il s'agit tout simplement d'arrêter de délivrer des labels.

Il m'a été donné d'auditer un grand nombre de produits commerciaux, expérience qui s'est enrichie de la lecture des rapports de mes pairs. Et j'ai désormais acquis la certitude qu'il est impossible de réaliser une dichotomie manichéenne entre les "bons" et les "mauvais" produits.

Certes, il existe des produits que leurs tares congénitales vouent à la roche Tarpéienne. Il serait d'ailleurs d'utilité publique d'en informer le plus grand nombre.

Mais en ce qui concerne les autres, un bon rapport d'évaluation ne va pas dire : "ok, on a rien trouvé". Un bon rapport va identifier les forces du produits (par exemple un stockage sécurisé des mots de passe), énumérer des problèmes à remonter à l'éditeur (comme des failles d'implémentation à corriger), préciser les limites de mise en œuvre à l'intérieur desquelles le produit reste relativement sûr (en général : ne pas activer les options de rétrocompatibilité).

La seule valeur ajoutée que peut apporter l'ANSSI dans le processus, c'est de collecter tous les rapports d'audit rédigés en France, y ajouter ses travaux dans des domaines que je sais nombreux par les offres de stage qui apparaissent et qui disparaissent sur son site, et publier le tout sous licence ouverte. Ainsi le niveau de sécurité des produits serait en permanence réévalué par la communauté, qui profiterait des fichiers "IDB" et autres scripts Python de tous ceux qui ont travaillé sur le sujet auparavant.

Un exemple "neutre" auquel s'applique parfaitement cette réflexion est celui du logiciel TrueCrypt. Car la version certifiée par l'ANSSI est documentée comme étant vulnérable à l'extraction du mot de passe en mémoire, lorsque le logiciel est utilisé pour le chiffrement du volume de démarrage (ce qui limite la portée d'une assertion réductrice telle que : "TrueCrypt est CSPN"). Certaines failles ont été corrigées depuis, mais personne n'a pris soin de retravailler sur une version plus récente de TrueCrypt … qui n'apporte rien de moins que le support Windows 7 et Mac OS 10.6+, entre autres.

Conclusion

La sécurité informatique est le cancer de l'industrie logicielle. Il n'y a pas d'argent pour la prévention. Seuls les malades s'intéressent au sujet, mais il est en général trop tard. Et pourtant, tout le monde y sera confronté un jour ou l'autre.

Dans ces conditions, relever le niveau de l'édition logicielle peut sembler une gageure, même pour une administration aussi puissante que l'ANSSI.

Si la CSPN partait d'une bonne intention, la décrépitude des produits les plus anciennement certifiés, ainsi que la soudaine certification de produits hautement symboliques, fait courir un risque à tout le processus de création de confiance. Car le moindre pestiféré emportera tous les autres, surtout s'il existe des alternatives plus connues, plus sûres et pourtant non certifiées.

J'espère que la lecture de ce billet constructif aura été source d'inspiration pour les quelques personnes qui détiennent un réel pouvoir sur ce sujet, et source de divertissement pour les autres.

Sur ce, bonnes vacances et rendez-vous à la rentrée pour de nouvelles aventures !