Qui n’a jamais entendu la phrase « Il faut prendre la compte la sécurité dès le développement » ? Elle est probablement devenu l’un des principaux lieux communs de la sécurité.

Microsoft en a même fait son cheval de bataille dès 2004, en créant une méthodologie spécifique (SDL) et en publiant la bible du développement sécurisé, « Writing Secure Code » . De son côté, l’OWASP n’est pas en reste avec son guide gratuit du développement de projets. Et ils sont loin d’être les seuls à militer pour cette cause (perdue ?)

Il faut hélas reconnaître que ces efforts n’empêchent toujours pas de trouver des injections SQL les plus simplistes dans les codes les improbables, mais c’est là un autre problème…

L’association ISSA France a ajouté sa modeste contribution à l’édifice du développement sécurisé en invitant lors du dernier Security Tuesday parisien Michel Ghanem, un spécialiste du développement agile. Et si à première vue l’apport d’Agile pour la sécurité ne saute pas aux yeux, il n’est pourtant pas bien loin.

Dans un cycle de développement agile ce sont les scénarios utilisateurs (« User stories » ) qui dictent les développements : le client-utilisateur raconte ce qu’il souhaite faire – de son point de vue extérieur – et le développeur livre un code qui répond à ces exigences plutôt qu’à des spécifications conventionnelles.

Evidemment l’utilisateur ne mentionnera probablement jamais la sécurité dans son scénario : il se contente d’imaginer les fonctionnalités de ses rêves en fonction de ses besoins métiers. Mais l’on voit déjà ici un premier point d’entrée de la sécurité : le développeur peut demander au client, dans chaque scénario, quelles sont les informations ou les traitements réellement importants à ses yeux. Ceux sans lesquels son métier s’arrête. Cela lui donne déjà au une indication des processus à soigner plus particulièrement. Et il se constitue également progressivement une cartographie sécurité détaillée de l’application, qui pourra s’avérer fort utile par la suite.

Mais l’on peut aller plus loin en ajoutant un autre créateur de scénario (une autre « persona » dans le jargon Agile). Ce sera le pirate, celui qui va tenter de compromettre l’application, et qui est incarné par l’expert sécurité. A chaque étape, sur la seule base de la user story remise par le client, le pirate va tenter d’abuser les éléments présents dans le scénario. L’utilisateur souhaite entrer tel type d’information dans un champ de saisie ? Le pirate va y voir une injection potentielle et va tenter d’y entrer tout autre chose. L’utilisateur souhaite enchaîner telle et telle opération sans s’authentifier à nouveau ? Le pirate va regarder comment sont gérées les sessions. A chaque étape, derrière chaque souhait fonctionnel du client, le « pirate » verra l’opportunité d’abus. Et le développeur pourra alors, derrière la scène de l’interface, tenir compte des indications de l’expert sécurité afin de livrer un code qui réponde aux souhaits du client tout en étant sûr…

L’on peut évidemment craindre, comme le faisait remarquer l’un des participants à ce Security Tuesday, que cette approche soit une forme de « pointillisme » , et qu’elle ne permette pas d’obtenir une vue globale de la sécurité de l’application puisqu’elle se focalisera sur le front-end défini par le client. C’est vrai, mais c’est aussi son atout : elle permet de mener un pentest continuel, durant tout le développement, sur les éléments les plus visibles, les plus utilisés et les plus accessibles.

Rien n’empêche par la suite de mener un audit du code plus traditionnel…