Ma vie rêvée

Le journal en ligne Newsforge a publié hier l'interview d'un consultant en sécurité (Dan Razzell) sur le thème des mythes de la sécurité et des réalités de l'architecture des logiciels (désolé pour la traduction imparfaite). L'article, bien qu'en anglais est d'un niveau très abordable et très bon. Je ne vais pas vous le traduire en entier mais je ne peux résister à l'envie de vous faire partager quelques passages que j'ai trouvé particulièrement intéressant.

A une question qui demande quel est son avis sur la sécurité que l'on obtient en ajoutant des logiciels (pare feu, antivirux etc)

if you can see a way to improve security by removing a feature, that's always better than to get the same effect by adding a feature.

Ce qui peut se traduire par : Si vous trouvez un moyen d'améliorer la sécurité en éliminant une fonction, ce sera toujours meilleurs qu'obtenir le même effet en rajoutant une fonction.

Un peu plus bas dans le même paragraphe, il explique que considérer la moindre suite de bits comme du code éxécutable (NDM : par exemple, tout fichier avec l'extension .exe est éxécutable) est une erreur manifeste et que batir un système complet autour de ce principe revient à avoir un système vulnérable quelquesoit les éxpédients que l'on peut ajouter pour limiter les risques. Il conclut par :

But security isn't about symptoms. The essential design vulnerability never really goes away. It just becomes disguised.

Mais la sécurité n'est pas une question de symptômes. Une vulnérabilité essentielle liée au design [du logiciel] n'est jamais comblée. Elle est juste masquée.

NDM : ceci me semble être une explication plausible à la présence de failles gravissime sur windows malgré le SP2.

Il explique ensuite que travailler en root (ou tout compte administrateur) régulièrement revient à chercher les ennuis ; même si on est derrière un parefeu :

Nobody plans to have an accident, but they happen anyway. It has nothing to do with firewalls. Someone who offers that argument is really not thinking very hard. The system provides a separation of privilege so that accidental damage can be contained in one part of the system. It seems only sensible to use it. I say this as someone who has done his share of massive damage to production systems while running as root. Sometimes you have to run as root, but if you do it casually, you're just asking for trouble.

Personne ne prévoit d'avoir un accident, mais ce sont des choses qui arrivent. Cela n'a rien à voir avec les parefeu. Quelqu'un utilisant cet argument [NDM : le parefeu protège de tout] ne voit pas plus loin que le bout de son nez. La séparation des privilèges permit par le système fait qu'en cas d'accidents, les dommages ne s'étendront que sur une partie du système. Il semble alors judicieux de l'utiliser.
Je vous dis ça comme quelqu'un qui a causé des dommages importants à une système en production alors qu'il travaillait avec un compte administrateur. Bien sur, quelquefois vous devez travillez en tant qu'administrateur, mais si vous le faites constamment, vous cherchez les ennuis.

L'interview continue sur les avantages de l'ouverture du code et des algorithmes au niveau de la sécurité :

if your key is captured, you can always tear it up and make another one. (...) But if the secret of the mechanism ever gets out, too bad. So don't make it a secret in the first place!

Si votre clé [secrète] est découverte, vous pouvez toujours en refaire une autre. (...) Mais si votre système secret est dévoilé, tout est perdu. Donc, dès le début ne le rendez pas secret !

L'interview se termine par quelques conseils aux architectes logiciels et aux programmeurs puis par une métaphore assez amusante sur le besoin de faire connaitre les principes généraux de la sécurité au plus grand nombre.

Bref, un article que j'ai apprécié par sa clarté, son pragmatisme et sa portée assez générale. A lire et à ressortir à l'occasion.