lundi 16 mai 2011

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 …