Faut-il demander aux développeurs de faire du "secure coding" ?

La question peut effectivement sembler amusante....Le développeur est effectivement celui qui va pousser les "bugs", les failles et le reste au plus profond du code. Mais est-il la bonne personne pour résoudre l'équation :

• 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 ;)....

ANSSI, précis d'hygiène, discours du chef !

WARNING : Vous avez le droit de ne pas être d'accord avec moi, mais commentez alors :) je ne fais que vous faire part de mon opinion et mon expérience.....  CE POST N'ENGAGE QUE MOI


C'est la mode en ce moment, tout le monde veut parler de ce document....Je me permets donc de dire tout haut ma pensée sur ce dernier document et ma pensée vis a vis de l'ANSSI.


Sur le document : Ce document me parait comme la suite des autres documents ; une grosse communication au moment des assises...Le discours de PPailloux, n'est pas en phase avec le marché actuel.... Dans les ministères, c'est simple d'imposer ce qu'il dit, dans les collectivités locales et territoriales c'est quasi-impossible. Et je ne parle par des PME/PMI. Il est impossible de dire non(Bruno Kerouaton le résume bien dans son post). 


Ensuite sur la qualité du document; c'est une tres bonne compilation/résumé/traduction de ce que l'on trouve dans différentes normes(ISO) / documents (NIST entre autre). Mais je pense que si on a un RSSI, on a déja cela...C'est pas possible d'avoir un RSSI sans ce type de guide, les PME qui n'ont pas ce guide, n'ont pas de RSSI... Et les grands groupes qui ont un RSSI on déja plus... (ISO 27K ? ) 

Si le boulot de l'ANSSI se résume a cela et de nous pondre des docs comme le RGS, le document sur les prestataires d'audit, et des éléments crypto, on est pas avancé....C'est pas avec cela qu'on va gagner la "cyber-guerre" si elle éclate :) 



Sur l'ANSSI et les retours d'échanges avec eux : 

L'ANSSI est preneur de commentaires, si ils vont dans leur sens, IMHO.  (plusieurs discussions avec eux lors de "réunions"/rencontres/mails)

Je pense que l'ANSSI est actuellement plus un beau parleur, qu'un bel acteur (ca n'engage que moi : exemple : pour essayer de les impliquer dans différents dossier clients importants (opérateur régional ou ils refusent de venir car pas sur la liste des OIV....)) 

Actuellement, après plusieurs année a dire du bien de l'ANSSI, j'en viens a dire le contraire...On a bureaucratisé la SSI en France et on va avoir de chouettes rapports qui ne seront rien de plus qu'un document sur un bureau....


PS: il y a des gens tres bien à l'ANSSI, mais ils sont "bureaucratisés" et ne peuvent donc pas faire avancer des sujets de fonds intéressants (PME, ouverture au privé de certaines choses, commentaires dans les documents, ....) 
PS2: si vous avez des problèmes, pensez plus a voir la DCRI...Ils répondent présent, sont compétents, pas bureaucratisés, et ouverts d'esprit.....
PS3: ce post n'engage que moi ! 

J ai trouve des vieilleries

J ai retrouve un vieux truc....
Quand je vois ce que l on trimballe maintenant, je me dis qu il y a 5ans, on avait du courage....

OWASP Developement Guide reboot !

Le Guide de développement OWASP (qui date quand meme de 2005...), vient de se faire rattraper par notre ami @vanderaj.

Il a lancé un appel à la communauté pour dire ce dont vous avez besoin  !  Il faut savoir que notre ami Andrew a  un sérieux passé au sein de l'OWASP.

Donc, je vous encourage à :

• lui envoyer des commentaires
• me les donner pour compilation a sa destination 

Sur ce, bonne réflexion ! 

Microsoft SDL passe en version 5.2

Microsoft a annoncé la semaine dernière la mise a jour de son processus de développement sécurisé en version mineure 5.2.

Je me suis donc mis a jour et au passage, voici les points relevés.

Dans la phase de conception (Phase 2)

L'exigence concernant l'UAC est mise a jour (page 25) 

Initialement il n'était question de l'UAC que sous Windows Vista. Or cette fonctionnalité existe maintenant sous Windows 7 et Windows Server 2008. Gageons qu'elle sera encore présente dans Windows 8 et/ou Windows Server 2012..... D'ou l'exigence initialement seule.
Dans la version 5.2, l'exigence 5.1 sur l'UAC est abordée en deux exigences(je me demande d'ailleurs pourquoi car la première n'est qu'une explication de ce qu'est l'UAC, enfin....).
Initialement il était question de s'assurer que l'application tournait sans soucis avec des privilèges non administrateurs; maintenant il est plus correctement évoquer le "moins de privilèges possibles"

Ajout d'un exigence sur l'utilisation de TLS(Page 27)

Il est question de vérifier des bonnes pratiques TLS basiques comme, vérifier le common name, l'appel régulier aux listes de révocation (CRL), et qu'aucun avertissement de sécurité n'apparaisse dans le cas d'une application Web.

La recommandation concernant la surface d'attaque est mise a jour (Page 27)

Dans cette recommandation il est question de documenter, après la phase de conception, l'ensemble(celle par défaut, et celle maximum) des surfaces d'attaques de l'application pour les minimiser.
Dans la version 5.2, il est ajouté un lien vers deux outils :

• Attack Surface Analyzer (ASA) : cet outil permet d'effectuer des snapshots de vos systèmes, avant et après l'installation de produit, permettant de voir quels changements ont été effectués.
• Web Application Configuration Analyzer (WACA): c'est un outil permettant de parcourir un serveur Web pour vérifier que les bonnes pratiques sont appliquées correctement.

Une nouvelle recommandation concernant la sécurité à destination des utilisateurs(Page 35)

Dans cette recommandation est abordé le principe de savoir si les avertissements de sécurité sont bons pour l'utilisateur. Microsoft introduit 4 niveaux de questionnement a se poser pour le développeur avant d'afficher un avertissement :

• Necessaire : doit-on réellement présenter l'avertissement
• Expliqué : présente-t-on tout ce qu'il faut pour que l'utilisateur prenne la décision
• Nécessite une action : l'utilisateur doit-il suivre différentes étapes pour prendre une bonne décision
• Testé : est-ce que plusieurs ingénieurs ont revus l'avertissement pour s'assurer que l'utilisateur le comprendra

Dans la phase d'implémentation (Phase 3) : 

• La recommandation sur les cookies HTTPOnly devient une exigence (Page 38)
• La recommandation concernant le moins de lien possible avec le protocole NTLM devient une exigence. Il est recommandé de passer par Kerberos. Est-ce la la fin du protocole NTLM ?

Mise a jour du chapitre sur les applications métiers (SDL-LOB)

Dans l'implémentation il y a deux nouvelles exigences :

• Premièrement il est exiger d'utiliser le Distributed Key Manager(DKM) pour des serveurs multiples plutôt que RSA concernant les clefs de chiffrement des fichiers de configuration (Page 96)
• Il est expliqué la manière d'utiliser le chiffrement via la ligne de commande pour les fichiers de configuration dans le framework Privacy.NET 2.0 (Page 97).

Mise à jour de l'annexe N(Échelle des bogues de sécurité SDL)

Voila, rien de bien réellement nouveau, il faut dire aussi que nous sommes sur une version "Mineure". Néanmoins le point sur les cookies HTTPOnly, montre bien qu'une simple petite recommandation peut faire plus que du bien.

Intégration de la sécurité dans le développement d'applications web

Vous êtes un bon quart a venir régulièrement du Canada (sous réserve que les statistiques de Google Analytics soient justes...). C'est pourquoi je vous signale la possibilité de vous former à la sécurité des applications Web de manière concrète à la fin du mois.

En effet,

Antonio Fontes (OWASP Genève/Suisse), et moi même profitons d'une conférence ou nous nous rendons, pour mettre en place avec Philippe Gamache (OWASP Montréal) une formation autour de nos expériences et de l'intégration de la sécurité dans un projet d'application Web.


Le contenu : 

La formation aura lieu sur une journée décomposée en trois parties :

- Sécurité lors de l'analyse et la conception d'une application
- Techniques de codage sécurité et sécurisation de l'application
- Evaluation de la sécurité de l'application

Les pré-requis : 

- Le langage Java (de base, pas besoin d'être un expert)

- La base de SQL

- La base de HTML/Javascript

- Connaître les principes de bases de la sécurité Web.

Donc, n'hésitez pas à vous inscrire à cette formation sur Montreal :

Ou: Campus SUPINFO Montréal - 752 rue Sherbrooke Ouest - Montréal, Québec H3A 1G1 - Canada
Quand : 28 Février 2012

ou sur Ottawa

Ou : Arts Court ,   2 DALY AVE  Ottawa, Ontario
Quand: 27 Février 2012


Nous prévoyons d'effectuer la même formation sur la France courant du printemps..

A savoir que la fondation met a disposition une page regroupant tous les training a venir sur une page dédiée : Training Schedules

HTML5 et la Sécurité

Les slides de ma présentation aux TechDays 2012 Microsoft sont publiés sur mon slideShare (Eagle42), vous pouvez donc me faire toutes les remarques/flammes voulues.

Magazine fail

Je pense qu il aura une durée de vie très courte...

Mon voisin de déjeuner du jour.

C est quand même agréable de pouvoir déjeuner au calme!

Affichage failed....

Je me demande ce que l on déstocke...