Ca fait un bout de temps que je voulais faire une entrée de blog avec ce concept, que j’ai affiné au fur et à mesure des différents audits de sécurité de code menés en interne, ainsi qu’en en parlant avec plusieurs personnes confrontés au même problème. Et ce encore récemment au BreizhCamp où j’ai eu le plaisir de présenter deux conférences : comparaison Java / .NET (dans un repaire de Javamen, il fallait l’oser 
) et Prévalence Objet dans une architecture DDD.
Le problème
Le problème est le suivant : comment s’assurer qu’un audit de sécurité est équitable ? En effet, s’il s’agit de retourner une application dans tous les sens, avec en plus un accès au code, et de déclarer non-conforme le logiciel dès qu’on trouve une faille, je ne connais aucun cas qui résisterait et l’actualité nous montre encore que personne n’est à l’abri. Pourtant, il faut bien s’assurer que les logiciels fournis ne sont pas des passoires. Comment faire pour positionner le curseur de façon à être sévère mais juste ?
Je propose de suivre ce que j’appelle la règle des trois “con”. Pas des trois cons, des trois “con…”, à savoir Confidentialité, Conformité et Complétude. Pour moi, un audit de code doit se plier à ces trois règles :
Confidentialité
Ca parait peut-être évident, mais la première chose à vérifier chez un auditeur de code pour la sécurité est qu’il applique les bons principes de confidentialité. Si vous livrez votre code pour inspection, comment s’assure-t-il qu’un stagiaire chez lui ne va pas l’embarquer sur une clé USB pour le regarder chez lui ? Si un ordinateur est volé, le code est-il sur une partition cryptée ? Etc.
Pour le résultat de l’audit, la confidentialité est également de mise : non seulement le demandeur de l’audit doit être informé de manière confidentielle, c’est-à-dire en minimisant au maximum les résultats de fuite, mais en plus, il faut respecter une éthique de diffusion à l’éditeur : hors de question de prévenir un utilisateur d’une faille et de ne pas avoir prévenu au préalable, ou au minimum en même temps, l’éditeur.
Conformité
L’application auditée doit être conforme à son utilisation réelle et effective. L’idée est de dire qu’une application ne peut pas être auditée en dehors de son environnement de déploiement en production. Le fait de monter un environnement d’analyse est dès le départ biaisé, car les sécurités ne seront pas les mêmes.
Exemple typique : tester un serveur de services web en dehors de son environnement de déploiement. Si les appels sont réalisés par une DMZ avec échanges HTTPS, il n’y a aucun sens, par exemple, à noter comme une faille de sécurité une authentification automatique. De nombreux mécanismes de SSO consiste en une authentification accordée par confiance complète à l’appelant, en mitigeant ce risque par la mise en place de sécurités additionnelles sur l’identité de cet appelant : pare-feu, résolution de challenge cryptographique, validation de certificat, etc. Si on teste le serveur en dehors de cet environnement sécurisé, l’authentification automatique est évidemment une faille.
Complétude
C’est le dernier des critères, et le moins évident. Il pourrait sembler proche du précédent, mais il est en fait son pendant dans un sens inverse de généralisation. Il s’agit de rendre obligatoire le test de la totalité de la chaine applicative. En effet, de la même manière qu’il serait injuste de tester une application ou un code en dehors de son environnement conforme de production, il est illogique de les tester de manière restreinte à cet environnement d’appelants.
Il apparait donc important de valider la ligne complète d’exploitation, sans parler uniquement de logiciel. Le cas typique est une application très bien sécurisée, mais sur des serveurs ouverts à l’extérieur avec un mot de passe faible, une cryptographie défaillante, des ports ouverts sans discernements, etc. Voire dans certains cas une sécurité physique défaillante. Je ne citerai pas de nom, mais les exemples sont nombreux d’entreprises dans lesquelles une simple visite physique permet d’accéder aux salles de serveurs. Il est évident que la solution applicative ne saurait être prise en défaut si l’accès physique n’est pas interdit.
Bref, il est essentiel de faire porter l’audit sur la chaine d’exploitation non seulement conforme, mais aussi complète.
Proposition
Voilà pour mon humble contribution à la définition des audits de sécurité sur le code. Je suis plus habitué à la technique qu’aux procédures, donc tous les commentaires sont, encore plus que d’habitude, les bienvenus.
