- risque = vulnérabilité * menace
Personnellement, j'ai formé plusieurs centaines de personnes(développeurs, architectes, ...) sur le sujet du "secure coding"; ce que demande le PCI-DSS par exemple. Et a force, je pense que le développeur n'est pas la bonne personne pour résoudre l'équation précédente....
En ce sens je rejoins en partie la vision de Dinis Cruz (Security must be invisible to developers).
Néanmoins, je suis un peu moins 'intégriste' que lui sur le sujet... Je ne dis pas que l'architecte ne doit pas être impliquer, pour moi c'est lui qui le doit....
Il est clair qu'aujourd'hui former des développeurs au secure coding est important. Néanmoins il convient que ces développeurs n'ai qu'une approche simple du problème.
Je m'explique par un exemple : injection SQL.
Toutes les formations le disent : il faut utiliser des requêtes paramétrées => OUI ! Mais pas seulement !
Depuis que je fais des revues de code (près de 3 ans...), j'ai pu apprécié l'approche "développeur" de cette dernière pratique....Et trouver des tonnes d'injections SQL dans les codes, car oui, on utilise des requêtes paramétrées mais on fait des concaténations dedans....(cf example 2 ici ).
Et la c'est le mal !
Bien sur, le développeur lors de la présentation du rapport ne vous crois pas jusqu'à la démonstration...
Alors que si on lui avait donner une simple interface d'appel aux fonctions sous-jacentes, et bien notre ami n'aurait pas eu de soucis et son code aurait été "safe". Il ne faut pas lui en vouloir a notre ami le développeur, il suit les consignes. Il faut en vouloir plutôt à l'architecte qui aurait du fournir une API/framework permettant d'effectuer ces appels.
Donc pour être clair : Il faut former les développeurs au secure coding, mais il faut surtout demander aux architectes logiciels de mettre à disposition des frameworks sécurisé et à eux de faire du "secure-coding"!
votre avis ?
PS: oui le rôle d'architecte nécessite de coder !
PS2: une idée à rechercher se trouve dans ce que fait Microsoft sur le framework .NET 4 (cf par exemple Entity Framework....). Attention quand même a faire attention pour ne pas faire des trucs "horribles"...L'abstraction parfois.....
PS3: comme d'habitude ce post n'engage que moi....
PS4: je remercie d'avance les quelques personnes qui reprennent mes idées chez leur client de faire référence à l'auteur ;)....
Salut Seb, tu connais déjà mon avis mais c'est toujours bien d'en rajouter une couche là où l'opportunité se présente. Et là, elle se présente!
RépondreSupprimerDonc, "mon avis":
1) La formation des développeurs au codage sécurisé est nécessaire.
2) La formation des développeurs à des sujets du type 'OWASP Top 10' est une erreur (voir élément #3). Elle révèle généralement l'absence d'une vision de long terme sur la sécurité des développements. Le lecteur veillera toutefois ici à bien faire attention au mot choisi: formation ne veut pas dire sensibilisation. La sensibilisation, elle, reste cruciale!!
3) Dans la mesure où l'architecture ne collabore que trop rarement avec les développeurs, en particulier, en ne leur fournissant ni l'outillage performant, ni la documentation cohérente, ni un support rapide, la formation des développeurs à des sujets du type 'OWASP Top 10' devient une nécessité pour les entreprises. Ce n'est absolument pas l'approche intelligente mais c'est la seule méthode pour contourner ce grave manquement. Donc, oublions le #1 pour quelques années encore!
4) Pour revenir au point #1, la formation au codage sécurisé concerne des sujets globalement absents des référentiels les plus "appréciés". Des sujets tels que la manipulation de numériques, l'utilisation correcte des types de données proposés par la technologie de développement et leurs comportements lors de situations d'exception, la relation du code avec les différents mécanismes de persistance mis à disposition, le rôle et la responsabilité du développeur au sein de l'entreprise, la notion de prestation de service à laquelle l'équipe d'architecture doit se conformer, l'utilisation d'outils automatisant les analyses les plus élémentaires, etc. sont bien plus importants (à mon humble avis) à enseigner aux développeurs.
5) Je ne pense pas qu'un architecte doit nécessairement coder. Le cas échéant, il doit disposer de son équipe de développement spécifiquement dédiée à la mise en œuvre des librairies d'architecture, utilisées par les équipes de développement orientées 'produit'.
6) Je vois plusieurs problèmes dans ton raisonnement:
a) Il redistribue la responsabilité aux architectes. Pourtant, les architectes incarnent la science infuse et le savoir divin, en particulier chez les éditeurs d'applications. Ils ne peuvent avoir tort.
b) Il constitue une menace pour les bonnes affaires de nombreuses sociétés. Tu sous-entends qu'il faut concentrer plus d'efforts sur les architectes que sur les développeurs. Or, il y a beaucoup plus de développeurs que d'architectes dans les entreprises. Cet argument strictement quantitatif est une menace directe pour le potentiel d'affaires des sociétés proposant des services de formation aux développeurs (dans la mesure où leur CA est proportionnel au nombre de stagaires).
Sinon à part ça, je suis entièrement du même avis que toi :)
Je crois qu'une partie manque à la formule initiale :
RépondreSupprimerrisque = menaces * vulnérabilités * impact
Dans les faits, une évaluation de risques contient toujours l'impact.
Dans le cas nommé ci-haut, les développeurs ont de la difficultés à comprendre la vulnérabilité et refusent ainsi l'application de l'impact.
Il est certain qu'il y aura toujours place à l'erreur et aux failles, mais on se doit de faire en sorte que la sécurité est respecté dans les critères de qualités.
Donc, il faut au départ une volonté de sécurité. Ça peut être de la direction, de l'équipe de travail ou du développeur lui-même. Cette volonté va créer une motivation qui va inciter les gens à agir.
Une fois obtenue, il faut savoir où agir.. oui ça peut être au niveau du framework, mais comme nous avons dit, les erreurs ou fautes peuvent quand même être impossible dans la majorité des frameworks.
Si on veut que la sécurité soit le plus régulière possible, on doit, en fonction de la nature de l'équipe disponible appliquer un effort :
Si c'est un développeur unique : il est le héro, le héro doit tout savoir, incluant ce qu'il faut faire pour la sécurité.
Si c'est une équipe, on doit avoir du contrôle de qualité et des architectes qui pousse les développeurs à aller vers la sécurité.
Si c'est une entreprise, on doit avoir un département de sécurité qui fait le travail.
Dans les deux premiers cas, on peut supplémenter tout équipe par un membre qui est "expert sécurité" ou encore utiliser un consultant pour pallier à certains manques.
Bref, même si on montre le "secure coding" à des développeurs, il faudra toujours une motivation et un mécanisme de renforcement en place, juste instruire va faire une partie du travail, probablement la partie la plus importante, mais on doit aussi travailler sur le reste pour obtenir un logiciel qui est le plus sécuritaire possible.
The best place I ever reviewed had a ton of SQL injection about three years before I started coding, and then they moved onto an enterprise wide SOA enterprise bus that took data access away from most developers, and gave it to a very small team who understood how to code optimized and secure SQL interfaces.
RépondreSupprimerThis eliminated SQL injection, and applications became faster because they could use the fastest possible transaction for their needs. It also reduced code due to the DRY principle - the best code was the only code.