Lfch-Interview d Herve Schauer

Interview d'Hervé Schauer

La sécurité avant tout !

par Albert, Erwan , Jepiho , Julien , Théodore

Note : Cet article a été publié initialement le 30 janvier 2003 sur LinuxFrench à l'adresse suivante : http://www.linuxfrench.net/article.php?id_article=1049. Aucune modification, autre qu'orthographique, n'a été apportée depuis quant à son contenu.

--

HSC est une société de consulting dans la sécurité informatique, et a le bon goût d’être une fervente adepte du Logiciel Libre et des solutions que celui-ci propose. Hervé Schauer, son PDG, a bien voulu répondre à quelques-unes de nos questions sur sa vision du net, et de la sécurité informatique en général.

Séquence Interview.

- Hervé Schauer, pouvez-vous vous présenter et présenter la société HSC pour ceux qui ne vous connaissent pas encore ?

HSC est un cabinet de conseil et d’expertise en sécurité depuis 14 ans, qui traite tous les aspects de la sécurité dans les domaines techniques qui touchent aux systèmes Windows et Unix, aux réseaux TCP/IP de manière très large et aux applications. Nous réalisons des études, des mises en oeuvre, des audits, des tests d’intrusion et des formations.

- Certains affirment que les failles de sécurité sont plus difficilement exploitables dans le logiciel propriétaire que dans le logiciel libre, parce que "dissimulées" par l’absence de code source. Qu’en pensez-vous ?

La recherche d’erreurs de programmation ou de conception avec d’un coté l’application en fonctionnement et de l’autre le source à disposition est la manière la plus efficace d’auditer la sécurité. Ce même travail sans le source est à mettre en regard avec les moyens : si peu de moyens sont consacrés à un audit avec le source et beaucoup à un audit sans le source, il n’y aura plus de grande différence. La diffusion du code source est utile pour la correction des failles, et l’absence de diffusion n’empêchera jamais de rechercher les failles ni de les exploiter. C’est la motivation et les moyens qui font la différence.

- Microsoft fait actuellement beaucoup de lobbying autour d’une nouvelle architecture de sécurité. Que pensez-vous de cette architecture, apporte-t-elle réellement plus de sécurité ou bien a-t-elle pour but de rendre le logiciel libre incompatible avec tout le hardware ?

Durant de nombreuses années, la politique des éditeurs de logiciels était de ne pas faire de sécurité et de ne pas en parler. Les principes économiques des logiciels commerciaux imposent de sortir régulièrement de nouvelles versions qui génèrent du chiffre d’affaire, sans s’occuper de la correction des failles de sécurité qui ne rapporte rien des versions existantes.

Maintenant la politique des éditeurs est de parler beaucoup de sécurité, dans les séminaires et conférences, sans avoir encore changé leurs logiciels. Si les éditeurs s’orientent vers l’intégration d’un système de contrôle d’usage des logiciels, il s’agit d’un nouveau mode de location des contenus qui ne me semble pas avoir de lien avec la sécurité. Les utilisateurs ont besoin de contrôle d’accès à leur ordinateur, de logiciels de lutte contre les codes et messages malveillants, avec des applications qui ne sont pas conçues pour les rendre victimes.

- Pour le grand public, la sécurité consiste à se protéger contre de « vilains hackers », souvent présentés comme des adolescents, génies de l’informatique, adeptes de Hard Rock ou de rap, cherchant à mettre la société toute entière en péril. De votre côté, sur le terrain, que constatez-vous, et quel est le profil type de la menace informatique ?

Il n’y a pas de profil type de menace, tout dépend de son métier et de son environnement. Si nous comparons la quantité d’erreurs dans les logiciels visibles sur Internet et le nombre d’attaques, il y a une faible utilisation des failles par des personnes malveillantes. Les problèmes surviennent d’une part lorsque qu’il existe un logiciel automatisant une attaque accessible à tout un chacun, et d’autre part lorsque quelqu’un est décidé à attaquer, quitte à prendre le temps d’exploiter une faille. Cela arrivera alors le plus souvent de la part d’employés ou plus généralement d’une personne qui connaît déjà sa cible en ayant travaillé sur place par exemple. La disparition du "full-disclosure" et la démocratisation de la vente d’exploitation des failles est une aubaine pour les personnes malveillantes.

- En matière de sécurité réseau, on parle souvent de firewalling (pare-feu) ou d’IDS (Détection d’Intrusion Système) celui-ci étant d’ailleurs divisé en deux grandes familles "Network" et "System", ainsi que de "chrootage"(mise en cage de l’application) Sont-elles les solutions miracles ou pensez-vous qu’il y ait encore d’autres choses à ajouter à cette liste ?

Pour protéger son système d’information, quelques solutions simples sont toujours à considérer :

- Sauvegarder toutes les informations ou serveurs sensibles ; - Contrôler les flux entre le réseau dont vous avez la responsabilité et le reste du monde ; - Sécuriser ses postes de travail.

Cela implique d’utiliser un système de sécurité Internet avec un pare-feu entre son réseau et l’Internet, et un logiciel d’anti-virus à la fois sur le système de sécurité Internet et les postes de travail.

L’utilisation de la détection d’intrusion implique un personnel spécialisé qui n’est pas à la portée de tous. Ce qu’il faut envisager si vous n’avez pas les compétences nécessaires à l’exploitation de sa sécurité est de l’infogérer. C’est ce que j’ajouterais à la liste.

Ensuite, il faut se rappeler que les failles de sécurité sont avant tout applicatives. Il est souhaitable de choisir un système d’exploitation offrant de bonnes possibilités de sécurisation comme Linux, et pour celui-ci, l’utilisation des cages est une bonne sécurisation. Il faut comme pour toute fonction de sécurité en connaître les limites. Il ne faut pas oublier que les applications, y compris celles qui ne sont pas sur les machines frontales, doivent être conçues et développées comme des applications sensibles qui doivent intégrer une grande sécurité.

C’est dans les applications et dans leur exploitation au quotidien que doivent être portés les efforts pour obtenir une bonne sécurité.

- La nouvelle distraction à la mode semble être d’après beaucoup de nos confrères le "social engeniering", même s’il a son importance ne croyez-vous pas que l’on se focalise un peu trop sur cette manière d’obtenir l’information ?

Pour nuire à autrui, il existe une grande quantité de moyens hors des intrusions informatiques. Si son système d’information n’apporte pas de vulnérabilités supplémentaires par rapport aux malveillances classiques dont toute organisation peut être victime, alors la sécurité informatique est réussie.

- Le Hurd, et plus généralement les micronoyaux utilisant de multiples serveurs satellites, en permettant de placer une plus grande partie du code tournant habituellement dans l’espace noyau dans l’espace utilisateur (par exemple la pile TCP/IP), constitue-t-il un progrès majeur et/ou une piste intéressante dans l’amélioration de la sécurité des systèmes d’exploitation ? Les professionnels de la sécurité songent-ils, à moyen terme, à bénéficier de ces concepts novateurs et à les utiliser spécifiquement pour mettre en place dessolutions sécurisées ?

Personnellement je n’ai pas étudié la sécurité comparée entre ces différentes architectures, mais a priori cela ne me semble pas changer fondamentalement. Par exemple une faille dans la pile IP restera toujours une faille dans la pile IP.

- À ce propos que pensez-vous de la dernière version d’OpenBSD et de son choix de faire disparaître de plus en plus l’utilisateur "root" dans son système ?

Dans de nombreux systèmes d’exploitation les privilèges peuvent être accordés un par un à un utilisateur. Dans Unix, il avait été fait le choix de la simplicité, notamment par rapport à Multics développé de 1968 à 1972. Ainsi Unix ne proposait que deux types d’utilisateurs dont un avec tous les privilèges. Avec la meilleure compréhension des systèmes d’exploitation et sans aller vers un excès de complexité, le retour vers de telles fonctionnalités est une bonne évolution. Celle-ci a été initiée dans les années 1990 avec les normes POSIX, qui ont proposé un découpage des privilèges de root en privilèges élémentaires.

Cependant, un système Unix qui tourne à base de privilèges modifie la philosophie du système et donc la base de confiance d’Unix est modifiée. Pour maintenir le même niveau de sécurité, certaines situations deviennent complexes.

Par exemple, bind ou apache seront lancés sous l’identité d’un utilisateur auquel il aura été accordé le privilège d’ouvrir un port privilégié. Les fichiers named.pid et http.pid ne peuvent plus être considérés comme des fichiers de confiance car ils sont en écriture pour cet utilisateur qui exécute le démon, donc l’identité sous laquelle l’éventualité d’un code malveillant s’exécutera. Ces fichiers ne peuvent alors plus être utilisés par root dans les scripts de démarrage/arrêt/relance des démons. Dans le cas Unixien classique, ces fichiers sont utilisables de façon aveugle car ceux-ci sont créés lorsque les applications sont root, dans leur phase d’initialisation, la fermeture de ces fichiers faisant partie de la perte des privilèges.

La restriction des appels systèmes par application (cf systrace) nous semble une bonne chose utilisable par tous les administrateurs Unix. L’escalade des privilèges (qui ont été ajoutés à systrace) est plus dangereuse : dans le cas où l’administrateur se trompe il offre alors le contrôle de sa machine à une application potentiellement vulnérable. L’escalade des privilèges n’est à réserver qu’aux administrateurs ayant de grandes compétences, cette fonction ayant les mêmes défauts que les privilèges, une partie du domaine de confiance du système disparaissant.

Une bonne sécurité provient d’une bonne conception des applications, qui doit elle-même faire en sorte que les conséquences d’une vulnérabilité soient minimales, en mettant en oeuvre de la séparation des privilèges. L’application d’une politique par application permet de compléter cela au niveau du système d’exploitation. La philosophie des privilèges et de l’escalade des privilèges est trop différente de celle d’Unix pour être applicable telle quelle à un système Unix. Cette sécurité au niveau système doit être secondée par une sécurité au niveau réseau via une architecture conçue elle aussi dans le but de minimiser les conséquences d’une vulnérabilité.

- Ne pensez-vous pas que le cadre législatif en France, en matière de sécurité soit trop restrictif ?

Durant 10 ans HSC a soutenu la libéralisation du chiffrement. Il appartient désormais aux jeunes générations de citoyens de se doter du cadre législatif qu’ils souhaitent.

- Que pensez-vous de la Loi sur la Sécurité Quotidienne (LSQ), ne va-t-elle pas à l’encontre de la sécurité en informatique pour les particuliers et les entreprises ?

HSC développe une expertise technique, nous n’avons pas d’expertise dans le domaine législatif. Nous travaillons de concert avec les huissiers et les avocats dans le cas d’enquêtes après un incident grave.

- Que pensez-vous des brevets logiciels ? nuisibles ou nécessaires sous certaines conditions ?

Dans notre domaine en sécurité informatique, nous n’avons que rarement étés confrontés aux brevets logiciels. Dans les contrats avec les clients, un expert doit faire attention à bien conserver sa propriété intellectuelle, afin que son client ne puisse pas breveter à son insu les idées qu’il a imaginé pour répondre aux problèmes du client. Ce dernier est propriétaire de ce que l’expert à construit et écrit pour lui, mais pas de ses idées. Si nous pensons qu’il y a un risque de détournement, il faut alors suivant son objectif soit breveter de son coté, soit publier son idée. Idéalement la publication peut être faite dans un cadre normatif comme à l’IETF, ou bien en publiant sous forme de logiciel libre. HSC n’a encore pas déposé de brevet.

- La vente liée est interdite en france pour le particulier (la vente par lot étant autorisée auprès des sociétés), cette loi est bafouée tous les jours par de nombreux constructeurs et revendeurs, qu’en pensez-vous ?

HSC respecte cette loi qui ne semble pas liée à la sécurité.

@ Retour à la rubrique Interviews

(c) 2003 Albert Bruc, Erwan Loisant, Jepiho , Julien Delange, Théodore