Windows 7.pdf

50 Chapitre 2 - L’héritage de Windows 7
La révision finale de sécurité est menée de deux à six mois avant l’achèvement du
logiciel, selon son étendue. L’état du logiciel doit être stable avant d’entreprendre la
révision finale de sécurité, quelques changements non relatifs à la sécurité pouvant
intervenir avant sa diffusion.
La révision finale de sécurité ne se limite pas à un exercice de type réussite ou échec,
pas plus que l’objectif de la révision finale de sécurité n’est de détecter toutes les
failles de sécurité qui resteraient dans le logiciel ; ceci sera sans conteste infaisable. La
révision finale de sécurité donne plutôt à l’équipe produit une image globale de l’état
de la sécurité du logiciel et de la probabilité selon laquelle il pourra résister aux
attaques lorsqu’il aura été diffusé auprès des utilisateurs. Si la révision finale de
sécurité détecte un modèle de failles restantes, la réponse correcte ne consiste pas
simplement à corriger les failles détectées, mais à reprendre les phases précédentes et
à prendre d’autres mesures ciblées pour en corriger les causes (en améliorant la
formation ou les outils, par exemple).
Phase de support et de dépannage
Malgré l’application du cycle de développement sécurisé au cours du développement,
les pratiques de développement avancées ne permettent pas encore de livrer des
logiciels totalement exempts de failles, et l’on peut raisonnablement penser que cette
situation perdurera. Même si le processus de développement pouvait éliminer toutes
les failles d’un logiciel tel qu’il est lors de la diffusion, de nouvelles attaques verraient
le jour et ce logiciel qui avait été sécurisé deviendrait vulnérable. Aussi les
développeurs doivent se préparer à répondre à des nouvelles failles dans les logiciels
livrés aux clients.
Une partie du processus de réponse suppose de se préparer à évaluer des rapports de
faille et à diffuser des conseils de sécurité et des mises à jour lorsque cela s’avère
nécessaire. L’autre composante du processus de réponse consiste à pratiquer une
analyse post-mortem des failles signalées et à prendre les éventuelles mesures
nécessaires. Les mesures destinées à répondre à une faille vont de la diffusion d’une
mise à jour en réponse à une erreur isolée à la mise à jour d’outils d’analyse de code et
à la réalisation de révisions de code des principaux sous-systèmes. L’objectif lors de la
phase de réponse est d’apprendre des erreurs et d’utiliser les informations des
rapports sur les failles pour détecter et éliminer les failles ultérieures avant qu’elles ne
soient découvertes et ne mettent en péril les utilisateurs. Le processus de réponse aide
également les développeurs à adapter les processus afin d’éviter des erreurs
semblables à l’avenir.