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 …
14 commentaires:
Très intéressant message surtout lorsque on se passionne pour cela en apprenant chaque jour.
Une question en fait : ne crains-tu pas que la réglementation de la profession ne conduise à une forme de "léthargie" ?
Après tout, il est difficile de quantifier la capacité d'apprentissage rapide du candidat, sa passion et sa volonté d'apprendre au quotidien...
Petit problème de liens ;-) :
file:///C:/temp/#_ftn1_1423
@cidris: il y a effectivement un risque que le marché soit verrouillé par quelques prestataires bien installés dans la place, si le ticket d'entrée est trop important. Espérons que l'autorité en charge de délivrer le futur "agrément" veille au grain :)
@blah: c'est corrigé. Le problème vient de Windows Live Writer 2011 ...
On semble s'inspirer d'un système de certification qui pour moi n'a pas fait ses preuves. Trop de certifications permettent au quidam de l'IT d'ajouter quatre acronymes à leur nom sans que pour autant l'expertise soit systématiquement réelle, diminuant du coup la valeur globale des certifications, notamment celles qui sont plus sérieuses. Mais l'offre ne fais certainement que répondre à la demande.
Adage qui dans le domaine de la formation ne fonctionne pas, favorisant ainsi l'apparition des "pentesters" qui ont une expertise reconnue par certains de leur clients dans le "next, next, generate report".
En ce qui concerne la dernière proposition, j'ai le sentiment qu'un tel recueil d'observations serait redondant avec des bases de données publiques telle CVE non?
L'activité d'expertise judiciaire, qui n'est certes pas une profession, est réglementée, avec les résultats qu'on sait. Aussi, je ne sais pas s'il s'agit d'une bonne idée.
D'autant que la réglementation ne changera rien au fait qu'il existe une demande conséquente pour des pentests à deux balles qui ne trouvent rien à redire à ce qu'ils testent. Réglementée ou pas, la "profession" y répondra... Exactement comme il y a des gens pour qualifier des logiciels dont rien que les qualités fonctionnelles piquent les yeux...
Très bon article Nicolas, mettant en lumière certaines failles et énonçant des propositions de bon sens reposant sur ta propre expérience.
Il est cependant surprenant que l'ANSSI, composée de personnes compétentes et pour certaines brillantes, n'ait pas vu venir l'écueil lié aux petites structures (majoritaires me semble-t-il) et n'ait pas discuté de ce catalogue (de compétences) à la Prévert ?!
Mon interrogation porte donc sur : est-ce une volonté pour restructurer le marché afin qu'il ne reste que 4 ou 5 acteurs majeurs (dans ce cas : pourquoi ?) ou peut-on considérer que cette version n'est qu'un draft lancé "in the wild" afin d'en évaluer le "buzz" (ou pas) ?
Ton analyse est intéressante, mais j'ai quelques remarques :
Dans le chapitre 4, il ne s'agit que de "recommandations", et non d'obligations, donc il ne s'agit, pour moi, que de fixer une sorte de ligne de conduite.
Tu parles de code d'exploitation (dans le paradoxe francais, 2eme acte), comme étant uniquement du développement d'exploits visant une exploitation type "en mémoire", mais je pense que le texte visait plutôt des choses plus larges, comme le développement de script automatisant un brute force ou une injection SQL par exemple.
Le choix des couleurs (ou plutôt la classification associée :-) ) est, de mon point de vue essentiel : si effectivement on pourrait donner du PWN/pas PWN, il faut garder à l'esprit qu'un test d'intrusion est effectué sur un temps limité, et qu'il n'est pas toujours possible d'aller jusqu'au PWN. Dans ces cas la, il est important d'avoir plus de granularité dans la classification. Même si effectivement, cela provoque souvent les conséquences que tu décris.
Vu ton expérience et ton expertise dans le domaine, comptes-tu publier cet excellent avis sur l'appel à commentaires de l'ANSSI (http://www.ssi.gouv.fr/site_article328.html) ?
Je suppose que cela pourra influencer dans le bon sens ce document...
Merci pour vos commentaires !
@Anonyme: la base des CVE est sans intérêt, car elle ne couvre que les failles reconnues par les éditeurs, et généralement sans aucun détail technique. Or ce qui est intéressant dans un produit, c'est plus son architecture globale que les failles particulières affectant une version X. Disposer des analyses antérieures fait toujours gagner un temps précieux.
@Sid: il me semble que l'expertise judiciaire est basée sur la cooptation, qui est un mécanisme différent et potentiellement générateur d'effets pervers effectivement. Mais je peux me tromper.
@Sportet: l'administration a probablement très bien identifié tous les problèmes potentiels, mais elle veut toujours faire les choses en grand. Il suffit de comparer un certificat qualifié (au sens RGS) avec un certificat StartSSL (gratuit). Dans la pratique, on rencontre beaucoup plus souvent les deuxièmes ... Mais pour être honnête, je n'ai aucune idée des intentions cachées derrière ce document. D'ailleurs je n'ai pas eu la chance de faire partie des privés qui ont été invités à le relire avant publication.
@iv: en ce qui concerne l'exploitation de failles, on est d'accord qu'une bonne injection de commandes est beaucoup plus redoutable qu'une faille "binaire". Mais qui n'a jamais adapté un exploit Metasploit à une version française de Windows ?
@Pascal: en général, le message finit par trouver son chemin tout seul jusqu'au destinataire, sans qu'il me soit nécessaire de me fendre d'un email :)
Post très intéressant, mais la conclusion me surprend.
Certifier les personnes sur leurs compétences (un gynécologue n'est pas un urologue), en organisant de réelles sessions d'examens.
Mais d'un autre côté il est dit que la volonté d'apprendre est une caractéristique essentielle du pentester: "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". Si on forme un stagiaire "buffer overflow" et que toute sa vie il cherche du buffer overflow par la suite, ça va vite le lasser je pense.
Et ensuite on lit:
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
Alors que: "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)."
Si l'ensemble de la documentation des failles et des outils est "closed source", cela risque de scléroser complètement la profession. Quelques très grosses boites qui auront accès à ce catalogue pourront former en interne quelques prestas triés sur le volet; quelques grands éditeurs pourront prendre les contremesures (audit de code, SDL, etc) et tous les autres qui feront du code à la petite semaine incapables d'investir suffisemment pour passer cette barrière: d'une part la marche est trop haute, d'autre part, puisque rien n'est public, c'est qu'il n'y a pas de problèmes... (on retombe sur le débat full disclosure / responsible disclosure). Faut il documenter les failles ou les méthodes?
@Kevin: on est d'accord que l'évaluation objective des compétences est un problème épineux (qui n'est pas réglé par le document, d'ailleurs).
Il me semble qu'un auditeur doit avoir deux compétences majeures:
* avoir entendu parler de tout ;
* pouvoir rapidement approfondir un domaine.
A partir de là on peut imaginer des sessions d'examens dans tous les domaines majeurs (système, réseau, bases de données, etc.) avec une note éliminatoire, complétés par une épreuve pratique "surprise" (ex. VxWorks, OS/2, SQLite, ...) pour vérifier la capacité d'adptation du candidat. Toute la difficulté consiste à se placer dans des conditions relativement réalistes (accès Internet) sans pour autant que le candidat ne puisse se faire aider par des humains (le problème des CTF).
En ce qui concerne le problème de la règlementation vs. le bootstrapping, ça n'en est pas un. Les internes, les clercs de notaire ou les préparateurs en pharmacie font le boulot sans avoir le titre officiel. Appelons ça un stage de longue durée :)
Enfin l'aspect "closed source" des rapports ... est la règle unique actuellement. J'encourage au contraire un partage de l'information ! Effectivement, pour avoir accès aux rapports concernant la sécurité d'un produit, il faudra passer par un prestataire agréé (qui va aussi être capable d'adapter le document au contexte d'utilisation du produit chez le client). Mais toute comme il faut passer chez le médecin pour obtenir une ordonnance, même pour un médicament qu'on connait très bien et qu'on prend depuis des années.
@newsoft:
"Les internes, les clercs de notaire ou les préparateurs en pharmacie font le boulot sans avoir le titre officiel. Appelons ça un stage de longue durée :)"
La différence avec l'interne, c'est qu'au bout de 10 ans ton interne devient médecin et peut s'installer à son compte et espérer pour un upside en termes de revenu.
Cet "encadrement" l'empêchera de faire ça (et tant pis pour l'expert SCADA/Siemens qui ne pourra pas offrir des services à son compte).
De plus, je ne sais pas si un période probatoire de 10 ans est vraiment un futur enviable.
@rd: rien n'indique que la période probatoire ne doivent être de 10 ans ... et puis si la "cyber sécurité" est aussi importante que la santé, pourquoi ne pas y mettre autant de moyens, au lieu de reléguer les praticiens au rang d'exécutants serviles et sous-payés ?
On ne peut pas dépenser un milliard pour une grippe qui n'est pas venue, et attendre le premier accident de SCADA sans rien faire (me semble-t-il).
@newsoft: un chenillard en assembleur 6809 ça compte ou pas ? sinon je crois que je fais partie des rookies... tain !
Enregistrer un commentaire