225
Tendances des pratiques de sécurisation des SI
Chapitre 11
Nous serons d’accord avec M. Ranum pour dire que la véritable bonne idée, c’est
« par défaut, tout est interdit ».
Idée stupide n
o 2 : prétendre dresser la liste des menaces
Cette idée stupide numéro 2, en fait assez voisine de sa sœur la numéro 1, pourrait
aussi s’incarner dans une configuration de pare-feu établie en fonction de la liste
des menaces recensées. Elle est stupide car en 2006 la liste des menaces est très
longue, et surtout elle s’accroît chaque jour : les recenser pour mettre son pare-feu
à jour s’apparente au remplissage du tonneau des Danaïdes. Les listes auxquelles
je suis abonné publient une dizaine de nouvelles vulnérabilités par semaine, et on
estime entre 200 et 700 par mois le nombre de nouvelles menaces.
Le délai qui s’écoule entre la découverte d’une vulnérabilité et son exploitation
par un logiciel menaçant est passé en quelques années de quelques mois à une
quinzaine de jours dans certains cas. C’est-à-dire que le logiciel nuisible peut apparaître avant la correction de la vulnérabilité, et que même si ce n’est pas le cas il
peut suffire d’un retard de quelques heures dans l’application de la correction pour
être exposé sans défense à la menace. Et n’oublions pas que les pirates, présents
dans tous les fuseaux horaires, agissent durant nos nuits et nos jours fériés. Bref,
en 2006 il est effectivement stupide d’espérer assurer la sécurité de son SI en se
prémunissant contre des menaces qui seraient connues d’avance.
Il faut au contraire dresser la liste de tous les logiciels utiles, d’usage légitime dans
le SI de l’entreprise, et interdire tous les autres en vertu de la règle précédente.
Ainsi, considérons un projet de sécurité informatique destiné à évaluer et à améliorer la disponibilité d’un système d’information. Si le responsable du projet s’inspire
de la méthode EBIOS élaborée en France par la Direction centrale de la sécurité
des systèmes d’information (DCSSI), il dressera une liste des risques, associera
chacun de ces risques à des vulnérabilités, et envisagera les contre-mesures qu’il
peut élaborer pour s’en prémunir, selon une formule pleine de bon sens et d’utilité 4 :
risque =
menace × vulnérabilité × sensibilité
contre-mesure
4 Nous avons donné à la page 7 une autre formule pour le risque, qui complète utilement celle qui
va suivre.
Tendances des pratiques de sécurisation des SI
Chapitre 11
Nous serons d’accord avec M. Ranum pour dire que la véritable bonne idée, c’est
« par défaut, tout est interdit ».
Idée stupide n
o 2 : prétendre dresser la liste des menaces
Cette idée stupide numéro 2, en fait assez voisine de sa sœur la numéro 1, pourrait
aussi s’incarner dans une configuration de pare-feu établie en fonction de la liste
des menaces recensées. Elle est stupide car en 2006 la liste des menaces est très
longue, et surtout elle s’accroît chaque jour : les recenser pour mettre son pare-feu
à jour s’apparente au remplissage du tonneau des Danaïdes. Les listes auxquelles
je suis abonné publient une dizaine de nouvelles vulnérabilités par semaine, et on
estime entre 200 et 700 par mois le nombre de nouvelles menaces.
Le délai qui s’écoule entre la découverte d’une vulnérabilité et son exploitation
par un logiciel menaçant est passé en quelques années de quelques mois à une
quinzaine de jours dans certains cas. C’est-à-dire que le logiciel nuisible peut apparaître avant la correction de la vulnérabilité, et que même si ce n’est pas le cas il
peut suffire d’un retard de quelques heures dans l’application de la correction pour
être exposé sans défense à la menace. Et n’oublions pas que les pirates, présents
dans tous les fuseaux horaires, agissent durant nos nuits et nos jours fériés. Bref,
en 2006 il est effectivement stupide d’espérer assurer la sécurité de son SI en se
prémunissant contre des menaces qui seraient connues d’avance.
Il faut au contraire dresser la liste de tous les logiciels utiles, d’usage légitime dans
le SI de l’entreprise, et interdire tous les autres en vertu de la règle précédente.
Ainsi, considérons un projet de sécurité informatique destiné à évaluer et à améliorer la disponibilité d’un système d’information. Si le responsable du projet s’inspire
de la méthode EBIOS élaborée en France par la Direction centrale de la sécurité
des systèmes d’information (DCSSI), il dressera une liste des risques, associera
chacun de ces risques à des vulnérabilités, et envisagera les contre-mesures qu’il
peut élaborer pour s’en prémunir, selon une formule pleine de bon sens et d’utilité 4 :
risque =
menace × vulnérabilité × sensibilité
contre-mesure
4 Nous avons donné à la page 7 une autre formule pour le risque, qui complète utilement celle qui
va suivre.