245
Conclusion
ne manque pas de méthodes qui laissent croire que que la sécurité des systèmes
d’information pourrait être assurée par des routines administratives : nous avons
signalé et expliqué leur vanité à la fin du premier chapitre de ce livre. Nous dirons
que ces méthodes de sécurité sont procédurales, ou, plus crûment, qu’elles sont
bureaucratiques.
Nous avons donc le choix entre ces méthodes bureaucratiques et celles que nous
appellerons méthodes de sécurité négative, parce qu’elles proposent de colmater
les failles dès que celles-ci sont découvertes et d’interdire les malfaisances après
qu’elles se sont manifestées : ni celles-là ni celles-ci ne sont satisfaisantes, nous
l’avons vu. Nous préconiserons plutôt celles qui visent ce que nous appellerons la
sécurité positive, parce qu’elles posent a priori ce qui est sûr, et qu’elles établissent
la sécurité à la conception des systèmes, par la définition de ce qu’ils doivent faire
et l’interdiction du reste selon une règle que nous énoncerons ainsi : « n’est permis
que ce qui est explicitement permis, tout le reste est interdit ».
Par exempe, à l’heure où pratiquement toutes les applications informatiques sont
fondées sur les techniques du Web, nous pensons, en suivant Marcus J. Ranum,
qu’un outil de choix pour la sécurité positive est le mandataire applicatif (reverse
proxy) : il s’agit d’un serveur Web spécialisé, qui reçoit les messages du protocole
HTTP, les filtre, rejette ce qui n’est pas autorisé et réécrit les requêtes avant de les
transmettre au « vrai » serveur, ce qui élimine tout imprévu, et notamment toute
une famille d’attaques par injection de code. Cette méthode revient à écrire sa
propre version du protocole, adaptée exactement à ce que l’on veut faire.
De façon générale, l’évolution de l’informatique, de ses usages, et par conséquent
des systèmes d’information, est déterminée par l’offre de technologie plus que
par les demandes des utilisateurs, parce que celle-là évolue plus vite que celles-ci.
Pour des raisons évidentes, c’est encore plus vrai pour les questions de sécurité,
parce que les utilisateurs ne « demandent » rien, et que l’« offre » est par définition
destinée à surprendre ses « clients » par des attaques auxquelles ils ne s’attendent
pas. La lutte contre cette « offre » un peu spéciale ne peut donc reposer sur les
attentes du client, et la veille technologique « tous azimuts », si elle est nécessaire,
ne saurait prétendre à l’efficacité totale. Ce qui renforce l’argument pour la sécurité
positive.
Pour toutes les raisons qui viennent d’être énoncées, nous pouvons conclure en
disant avec Bruce Schneier [100] que la sécurité du système d’information n’est pas
Conclusion
ne manque pas de méthodes qui laissent croire que que la sécurité des systèmes
d’information pourrait être assurée par des routines administratives : nous avons
signalé et expliqué leur vanité à la fin du premier chapitre de ce livre. Nous dirons
que ces méthodes de sécurité sont procédurales, ou, plus crûment, qu’elles sont
bureaucratiques.
Nous avons donc le choix entre ces méthodes bureaucratiques et celles que nous
appellerons méthodes de sécurité négative, parce qu’elles proposent de colmater
les failles dès que celles-ci sont découvertes et d’interdire les malfaisances après
qu’elles se sont manifestées : ni celles-là ni celles-ci ne sont satisfaisantes, nous
l’avons vu. Nous préconiserons plutôt celles qui visent ce que nous appellerons la
sécurité positive, parce qu’elles posent a priori ce qui est sûr, et qu’elles établissent
la sécurité à la conception des systèmes, par la définition de ce qu’ils doivent faire
et l’interdiction du reste selon une règle que nous énoncerons ainsi : « n’est permis
que ce qui est explicitement permis, tout le reste est interdit ».
Par exempe, à l’heure où pratiquement toutes les applications informatiques sont
fondées sur les techniques du Web, nous pensons, en suivant Marcus J. Ranum,
qu’un outil de choix pour la sécurité positive est le mandataire applicatif (reverse
proxy) : il s’agit d’un serveur Web spécialisé, qui reçoit les messages du protocole
HTTP, les filtre, rejette ce qui n’est pas autorisé et réécrit les requêtes avant de les
transmettre au « vrai » serveur, ce qui élimine tout imprévu, et notamment toute
une famille d’attaques par injection de code. Cette méthode revient à écrire sa
propre version du protocole, adaptée exactement à ce que l’on veut faire.
De façon générale, l’évolution de l’informatique, de ses usages, et par conséquent
des systèmes d’information, est déterminée par l’offre de technologie plus que
par les demandes des utilisateurs, parce que celle-là évolue plus vite que celles-ci.
Pour des raisons évidentes, c’est encore plus vrai pour les questions de sécurité,
parce que les utilisateurs ne « demandent » rien, et que l’« offre » est par définition
destinée à surprendre ses « clients » par des attaques auxquelles ils ne s’attendent
pas. La lutte contre cette « offre » un peu spéciale ne peut donc reposer sur les
attentes du client, et la veille technologique « tous azimuts », si elle est nécessaire,
ne saurait prétendre à l’efficacité totale. Ce qui renforce l’argument pour la sécurité
positive.
Pour toutes les raisons qui viennent d’être énoncées, nous pouvons conclure en
disant avec Bruce Schneier [100] que la sécurité du système d’information n’est pas