Microsoft veut aider les développeurs à écrire des codes plus sûrs
Et publie un modèle pour Visual Studio et un paper

Le , par Gordon Fowler, Expert éminent sénior
Microsoft vient de publier son traditionnel rapport de sécurité, le Microsoft’s Security Intelligence Report.

Il en ressort que sur les 6 premiers mois de 2009, 19% des vulnérabilités se trouvent dans les navigateurs. Parmi les autres (soit 81%), au total 5 % seulement concerneraient des produits de Microsoft.

David Ladd, un des principaux responsables en charge des problèmes de sécurité à Redmond, note que pour ses autres confrères développeurs d'applications "jusqu'ici, la sécurité n'a pas été une priorité" par rapport au développement de nouvelles fonctionnalités de l'amélioration des ergonomies. "Ce n'est pas une critique, c'est juste un impératif commercial".

Mais les clients, de plus en plus conscients de ces impératifs, commencent à donner une place importante à la sécurité dans leurs cahiers des charges. Avec Windows, l'OS le plus populaire au monde, Microsoft a toujours été une cible privilégiée pour les hackers et entend faire partager son expertise.

Depuis les années 90, la société a créé un groupe de réflexion, le Microsoft’s Trustworthy Computing (TwC). Une des premières missions du TwC a été de publier un process de développement pour minimiser le nombre de vulnérabilités dans les applications : ce Security Development Lifecycle (SDL)

Depuis 2004, ce SDL est appliqué dans la conception de tous les produits Microsoft.

En 2008, Redmond a décidé de rendre public son "guide de bonnes pratiques pour l'industrie logiciel" en proposant quatre outils de développement : un outil de modélisation des menaces, le Minifuzz file fuzzer, l'analyseur de binaires Binscope, et le SDL Process Template du Visual Studio Team System. "En partageant ce que nous avons appris notre but est d'accélérer le processus d'apprentissage de tous les développeurs".

Continuant sur sa lancée, Microsoft vient de présenter de nouveaux outils lors du Black Hat de Washington.

L'objectif, cette fois-ci, est de rendre les outils SDL plus simples d'utilisation pour aussi bien pour les groupes internationaux que pour les PME de quelques développeurs. Pour ce faire, un document de 18 pages, intitulé “Simplified Implementation of the Microsoft SDL", est disponible au téléchargement sur le Microsoft Download Center.

Microsoft souligne que ce processus, spécialement imaginé pour s'intégrer dans les méthodes Agiles, n'est pas cantonné à Windows ou à ses produits maisons.

Mais Redmond ne s'arrête pas là. La beta d'un Template pour VisualStudio 2008 vient également d'être mis à la disposition des développeurs. La version pour VisualStudio 2010 est également prévue dès que ce dernier sera finalisé.

Depuis hier, le paper de 18 pages est disponible ici, tout comme le Template pour VS2008.

Source : le site officiel du SDL

Lire aussi

Les Rubriques (news, tutos, forums) de Developpez.com :

Windows
.NET
Conception
Sécurité

Et vous ?

Que pensez-vous des méthodes et des outils SDL proposés par Microsoft : efficaces ou inadaptés ?
Êtes-vous d'accord avec David Ladd quand il dit que jusqu'ici la sécurité n'a pas été une priorité pour les développeurs d'applications par rapport à la création de nouvelles fonctionnalités ou l'amélioration des ergonomies ?


Vous avez aimé cette actualité ? Alors partagez-la avec vos amis en cliquant sur les boutons ci-dessous :


 Poster une réponse

Avatar de smyley smyley - Expert éminent https://www.developpez.com
le 03/02/2010 à 17:12
Citation Envoyé par Gordon Fowler  Voir le message
Êtes-vous d'accord avec David Ladd quand il dit que jusqu'ici la sécurité n'a pas été une priorité pour les développeurs d'applications par rapport à la création de nouvelles fonctionnalités ou l'amélioration des ergonomies ?

Personnellement oui. Autant dans les beaux cours magistraux on fait de belles théories sur les "bonnes pratiques" et on a des jolis papiers sur la sécurité "en général", autant en pratique, j'ai souvent vu des codes à bidouillage actif et fonctionnement étrange.

Le but premier c'est "ça compile". Le deuxième c'est "ça fait ce qu'on attend de lui si tout va bien". Et après, bizarrement, ça livre ...
Avatar de pseudocode pseudocode - Rédacteur https://www.developpez.com
le 03/02/2010 à 17:28
Il en ressort que sur les 6 premiers mois de 2009, 19% des vulnérabilités se trouvent dans les navigateurs. Parmi les autres (soit 81%), au total 5 % seulement concerneraient des produits de Microsoft.

?

De quelles vulnérabilités ils parlent. Non parce que, pour moi, pouvoir prendre le contrôle d'un PC a distance c'est une vulnérabilité de l'OS... quand bien même l'attaque se fait via une application tierce qui tourne dessus.

A moins de faire une application explicitement concue pour prendre le contrôle (comme un "bureau distant"), je ne vois aucune raison pour que l'OS soit compromis. non ?
Avatar de Skyounet Skyounet - Expert éminent sénior https://www.developpez.com
le 03/02/2010 à 18:35
Citation Envoyé par pseudocode  Voir le message
?

De quelles vulnérabilités ils parlent. Non parce que, pour moi, pouvoir prendre le contrôle d'un PC a distance c'est une vulnérabilité de l'OS... quand bien même l'attaque se fait via une application tierce qui tourne dessus.

Il y a des OS qui savent se protéger des buffer overflows ? (c'est une vraie question).
Avatar de pseudocode pseudocode - Rédacteur https://www.developpez.com
le 03/02/2010 à 18:51
Citation Envoyé par Skyounet  Voir le message
Il y a des OS qui savent se protéger des buffer overflows ? (c'est une vraie question).

Les buffer overflows, c'est toujours possible avec des langages comme le C.

Mais empecher que des octets injectés par buffer-overflow se transforment en code valide, que ce code soit exécuté, et qu'il permette d'outrepasser les droits de l'application originale, et par là prendre le contrôle de l'OS... Désolé, mais pour moi c'est de la responsabilité de l'OS de ne pas permettre que tout cela arrive.

Tout comme il y a l'isolation des zones mémoire entre les processus, il devrait aussi y avoir une isolation des fonctionnalités accessibles. Un peu ce que fait SE-Linux.

Ou dans un autre esprit, Singularity.
Avatar de atha2 atha2 - Membre éprouvé https://www.developpez.com
le 03/02/2010 à 18:54
Citation Envoyé par Skyounet  Voir le message
Il y a des OS qui savent se protéger des buffer overflows ? (c'est une vraie question).

oui :
http://www.developpez.net/forums/d79...ipe-recherche/

après peut-on vraiment parler d'OS, c'est une autre question...
Avatar de smyley smyley - Expert éminent https://www.developpez.com
le 03/02/2010 à 19:59
Citation Envoyé par pseudocode  Voir le message
Mais empecher que des octets injectés par buffer-overflow se transforment en code valide, que ce code soit exécuté, et qu'il permette d'outrepasser les droits de l'application originale, et par là prendre le contrôle de l'OS... Désolé, mais pour moi c'est de la responsabilité de l'OS de ne pas permettre que tout cela arrive.

C'est pas le rôle du DEP justement ?
Avatar de pseudocode pseudocode - Rédacteur https://www.developpez.com
le 03/02/2010 à 23:36
Citation Envoyé par smyley  Voir le message
C'est pas le rôle du DEP justement ?

Oui, le DEP permet d'empêcher que du code injecté dans une page marquée "data" soit exécuté par le processeur. Mais ca signifie que si on ecrit dans une page qui n'est pas marquée, ou que si on supprime la marque, alors ca sera exécuté.

Mais surtout, ce que je veux dire c'est que le problème est pris à l'envers.

Limiter les buffer-overflow ou se protéger de l'execution de code en zone data, c'est bien. Mais, malgré tout, l'OS ne devrait pas tolérer qu'une application "anodine" (genre lecteur flash) puisse accéder a des fonctions systèmes permettant une prise de contrôle.

Ms a fait cet effort en créant une sandbox autour de son navigateur internet. Mais ca devrait être généralisé a toutes les applications et donc, pour plus de simplicité, géré directement par l'OS.
Avatar de smyley smyley - Expert éminent https://www.developpez.com
le 03/02/2010 à 23:50
Citation Envoyé par pseudocode  Voir le message
Ms a fait cet effort en créant une sandbox autour de son navigateur internet. Mais ca devrait être généralisé a toutes les applications et donc, pour plus de simplicité, géré directement par l'OS.

Mais par défaut sur Vista/Seven, une application est lancée à travers l'UAC et elle n'a pas la possibilités de faire des changements sur le système, à moins d'être lancée avec le jeton d'administrateur complet.

En théorie ça limite la casse, si casse il y a ... non ?
Avatar de pseudocode pseudocode - Rédacteur https://www.developpez.com
le 04/02/2010 à 0:00
Citation Envoyé par smyley  Voir le message
Mais par défaut sur Vista/Seven, une application est lancée à travers l'UAC et elle n'a pas la possibilités de faire des changements sur le système, à moins d'être lancée avec le jeton d'administrateur complet.

En théorie ça limite la casse, si casse il y a ... non ?

Oui ca limite. Mais ca me donne tout de même l'impression que le système de sécurité est a l'envers. Par défaut tout est autorisé, et on rajoute des verrous par-ci par-là pour "limiter la casse". C'est tout de même curieux.
Avatar de Franck SORIANO Franck SORIANO - Membre expert https://www.developpez.com
le 04/02/2010 à 7:38
Citation Envoyé par pseudocode  Voir le message
Oui ca limite. Mais ca me donne tout de même l'impression que le système de sécurité est a l'envers. Par défaut tout est autorisé, et on rajoute des verrous par-ci par-là pour "limiter la casse". C'est tout de même curieux.

Il ne faut pas oublier que l'UAC ne concerne que les comptes administrateur. Microsoft a été obligé d'introduire l'UAC parce que bon nombre d'applications sont males écrites, que les administrateurs gèrent mal les sécurités... et qu'au final les utilisateurs lambda travaillent en étant administrateur !
Donc oui, ils ont tous les droits. Mais non, ce n'est pas le comportement par défaut, c'est eux qui se les sont données.
L'UAC a été introduite pour pouvoir sécuriser un peu l'OS malgré cette mauvaise pratique chez les utilisateurs.

Sinon je trouve ça bien comme approche, mais c'est une peu déplacer le faute sur les développeurs, je trouve...

Et bien cette réflexion illustre bien la raison des plus gros problèmes de sécurité.
La sécurité est l'affaire de tous, pas seulement de l'OS, du réseau ou du système :
- Supposons que l'OS et les navigateurs soient complètement blindés et invulnérables
- Les admins ont parfaitement bien fait leur boulot, les serveurs sont dans des DMZ, avec des firewall partout...
- Un hackeur n'a aucune possibilité pour s'introduire sur le réseau, et même s'il y parvenait il ne pourrait rien faire.

=> Et bien même dans ce cas là, ta forteresse partirait en miettes si par exemple, les développeurs ont pondus un site web sensible aux injections SQL et que l'intru s'en sert pour se connecter avec un compte super-utilisateur sur le site, accéder aux données de ses concurents et voler tout ce qu'il veut...

Or l'immense majorité des attaques ne portent pas sur le système, mais sont issues de clients ou d'utilisateurs qui disposent déjà d'un point d'entrée (au pire ils ont volés un login et un mot passe par un moyen X ou Y) et qui contournent les sécurités applicatives pour faire des choses et accéder à des données confidentielles qui leur sont interdites...

Un des gros problèmes c'est justement que les développeurs s'imaginent que la sécurité n'est qu'un problème système et ne les concerne pas.
Ils n'ont même pas conscience des vulnérabilités du code qu'ils écrivent.

Donc les problématiques de sécurité ne sont pas prises en compte lors des développements.

Le but premier c'est "ça compile". Le deuxième c'est "ça fait ce qu'on attend de lui si tout va bien". Et après, bizarrement, ça livre ...

Oui, et très souvent, il n'y a pas que la sécurité qui est sacrifiée dans ce processus ("tout ce qui compte c'est que ça marche, je me fiche de savoir comment").
Avatar de pseudocode pseudocode - Rédacteur https://www.developpez.com
le 04/02/2010 à 10:08
Citation Envoyé par Franck SORIANO  Voir le message
Il ne faut pas oublier que l'UAC ne concerne que les comptes administrateur. Microsoft a été obligé d'introduire l'UAC parce que bon nombre d'applications sont males écrites, que les administrateurs gèrent mal les sécurités... et qu'au final les utilisateurs lambda travaillent en étant administrateur !
Donc oui, ils ont tous les droits. Mais non, ce n'est pas le comportement par défaut, c'est eux qui se les sont données.
L'UAC a été introduite pour pouvoir sécuriser un peu l'OS malgré cette mauvaise pratique chez les utilisateurs.

Comme tu le montres, l'approche actuelle de la sécurité est orientée "utilisateur".
C'est à dire que ce que PEUT faire un processus sur le système dépend de QUI est entrain de l'exécuter.

Déjà, pour moi, c'est pas normal. C'est pas parce que je regarde une video flash en etant Administrateur que le player flash à le droit d'aller ecrire en base de registre.

Les fonctions systèmes accessibles par un processus ne devrait dépendre que de :
1. ce qui a été déclaré dans le processus, définies par le développeur (=manifest)
2. ce qui a été autorisé pour ce processus, définies par l'utilisateur (=profil)

Bref, une approche de la sécurité orientée processus, et pas utilisateur.
L'approche utilisateur impliquerait de créer des utilisateurs differents a chaque fois qu'on veut des autorisation différentes. C'est sans doute la raison pour laquelle on a des utilisateurs spéciaux sous windows ("local", "system", "service", "authority")

Enfin voila. Tout ca pour dire que si je code un "démineur" en C++, je ne devrais pas avoir a me poser des questions de sécurité relatives au système d'exploitation. Relatives à mon application : ok. Mais pas plus.
Offres d'emploi IT
Ingénieur conception en électronique de puissance H/F
Safran - Ile de France - Moissy-Cramayel (77550)
Ingénieur analyste programmeur (H/F)
Safran - Auvergne - Montluçon (03100)
Expert décisionnel business intelligence H/F
Safran - Ile de France - Évry (91090)

Voir plus d'offres Voir la carte des offres IT
Contacter le responsable de la rubrique Accueil