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.
Aucun commentaire:
Enregistrer un commentaire