SlideShare une entreprise Scribd logo
1  sur  6
Télécharger pour lire hors ligne
REPUBLIQUE ET CANTON DE GENEVE
Département des constructions et des technologies de l'information
Centre des technologies de l'information
Logiciel libre et sécurité
Auteurs Patrick GENOUD, Observatoire technologique
Version / Date d’enregistrement V1.0 / 2007-04-05
Pour aller à l'essentiel
Observatoire technologique
Téléphone +41 (22) 388 13 50 • Fax +41 (22) 388 13 57 • www.geneve.ch
Le logiciel libre a le potentiel pour être plus sûr que le logiciel propriétaire. Les
projets open source peuvent en effet réaliser tout ce dont sont capables les projets
réalisés en mode fermé, tout en bénéficiant des avantages liés à l'ouverture du code
et au mode de développement communautaire. De nombreux projets open source
de qualité supérieure sont là pour le prouver.
Mais il faut bien distinguer les potentialités indiscutables offertes par le modèle open
source de leur réelle mise en oeuvre au sein des projets. Pour que ce modèle soit
réellement efficace dans le domaine de la sécurité, il faut ainsi que le projet réunisse
une communauté suffisamment importante, dispose de développeurs sensibilisés et
motivés par les questions de sécurité, revoie et corrige effectivement le code en
terme de sécurité et dispose si possible de spécialistes en la matière.
Cela doit passer par une sensibilisation à la sécurité des communautés et de leur
direction ainsi que par une industrialisation des processus de développement, en y
intégrant étroitement la sécurité.
Logiciel libre et sécurité
Contexte
Dans le premier plan de mesures publié en novembre 2006 par le conseil d'État du canton
de Genève, la promotion de l'utilisation de logiciels libres figure en bonne place (mesure n°
28). Le Centre des technologies de l'information (CTI) s'est engagé dans cette démarche
avec une approche éloignée de tout dogmatisme.
Comme nous l'avons détaillé dans un précédent rapport1
, l’intérêt du secteur public pour le
logiciel libre est aujourd’hui indéniable, en particulier parce qu’il met très souvent en œuvre
des standards ouverts, qu’il brise les positions de lock-in et qu’il permet une plus grand
adaptabilité aux besoins particuliers. Les motivations essentielles avancées par les
gouvernements sont une meilleure maîtrise et une pérennité accrue de leurs propres
systèmes d’information, une plus grande neutralité dans le choix de vendeurs de solutions
ainsi qu’une ouverture vers les entreprises et les citoyens désirant ou devant interagir avec
les administrations.
Au delà de ces apports stratégiques indéniables, un nombre croissant de solutions open
source gagnent en popularité en raison de leur excellentes performances, de leur fiabilité et
de leur coût d'achat faible ou nul. La sécurité est également un domaine souvent mis en
avant lorsque l'on évoque les avantages associés au logiciel libre. Cet aspect suscite de
nombreuses controverses et les études qui y sont consacrées ne permettent pas d'apporter
un point de vue définitif sur la question.
Le but de ce document est de porter un regard nuancé sur le lien entre sécurité et logiciel
libre en se référant à l'avis de quelques experts dans le domaine.
Mais en préambule à toute considération relative aux aspects spécifiques liés à la sécurité, il
n'est pas inutile de rappeler que le choix d'une solution informatique de devrait pas être
conditionné par un seul critère particulier (comme la sécurité dans le cas qui nous intéresse),
mais plutôt être envisagé de manière globale comme le suggère par exemple le référentiel
NPT2
.
La sécurité informatique est un vaste domaine et nous limiterons notre argumentaire aux
aspects liés au développement d'applications en mode open source ou en mode fermé (par
opposition au mode open source).
Dans ce document nous utiliserons de manière indifférente les termes de logiciel libre et de
logiciel open source dont nous avons déjà précisé la définition ailleurs1
.
Points de vue d'experts
L'expert en sécurité informatique David Wheeler3
propose dans un excellent document
accessible en ligne un chapitre consacré à la relation entre open source et sécurité. Il y
rappelle notamment le point de vue de plusieurs experts dans le domaine dont plusieurs sont
cités ici. Cette revue n'a pas la prétention d'être exhaustive; elle illustre les principaux
arguments énoncés lorsque l'on évoque le sujet.
Bruce Schneier4
, expert en sécurité et en cryptographie, prétend que tout développeur
devrait exiger de bâtir des solutions de sécurité sur des composants open source. La
1
Standards ouverts et logiciel libre Clarification des notions, P. Genoud et G. Pauletto, Observatoire
Technologique, Centre des technologies de l’information du canton de Genève, 2005, http://ot.geneve.ch
2
Référentiel Nouvelles Plateformes Technologiques, P. Genoud et G. Pauletto, Observatoire Technologique,
Centre des technologies de l’information du canton de Genève, 2003, http://ot.geneve.ch
3
Secure Programming for Linux and Unix HOWTO : Creating secure software, D. A. Wheeler, 2003,
http://www.dwheeler.com/secure-programs
4
Open Source and Security, B. Schneier, 1999, Crypto-Gram. Counterpane Internet Security, Inc.,
http://www.counterpane.com/crypto-gram-9909.html
- 2 -
Logiciel libre et sécurité
meilleure manière d'augmenter le niveau de qualité d'une solution est selon lui de permettre
son examen par le plus grand nombre d'experts possible. Pour répondre à l'argument du
secret souvent avancé par les défenseurs des logiciel fermés, Bruce Schneier insiste sur le
fait que les composants open source sont conçus pour être sûrs malgré le fait qu'ils soient
publics; c'est dans leur essence même.
Dans un article consacré au sujet Whitfield Diffie5
, le co-inventeur de la cryptographie à clé
publique, conclut en réponse aux arguments des adversaires de l'ouverture du code dans le
domaine de la sécurité: « Il est simplement irréaliste de dépendre du secret en matière de
sécurité des programmes informatiques. On peut prévenir la divulgation du mode de
fonctionnement d'un programme, mais empêchera-t-on le code d'être désassemblé par des
adversaires sérieux ? Probablement pas. ».
Vincent Rijmen6
, l'un des développeurs de l'algorithme d'encryption AES (Advanced
Encryption Standard) pense que la nature même du système d'exploitation open source
Linux permet de mieux détecter et réparer les vulnérabilités de sécurité, non seulement
parce que les gens ont accès au code, mais aussi et surtout parce que le modèle force les
développeurs à adhérer à des standards et à produire du code plus clair, ce qui à son tour
facilite la revue du code.
Mais Hissam et al7
relèvent le fait que l'accessibilité au code ne signifie pas nécessairement
que celui-ci a été revu, notamment au niveau de la sécurité. Mais ils soulignent dans le
même temps que c'est également le cas pour du code propriétaire.
Mais certains comme Fred Schneider8
ne croient pas que le logiciel libre contribue à la
sécurité. Il n'y a selon lui pas de raison de penser que de nombreuses personnes inspectant
un code ouvert soient forcément efficaces dans la détection de bugs liés à la sécurité.
D'autre part, les bugs présents dans le code ne sont selon lui pas la cause majeure des
attaques.
John Viega9
tempère ce point de vue en affirmant: « Les projets open source peuvent être
plus sûrs que les projets dont le code est fermé. Cependant les aspects qui peuvent rendre
un programme plus sûr – la disponibilité du code source et le fait qu'un grand nombre de
personnes peuvent rechercher et réparer des trous de sécurité – peut aussi bercer les gens
dans un faux sentiment de sécurité. ». Dans un article plus récent10
, il considère que le
logiciel libre a, sur le long terme, le potentiel pour être plus sûr que le logiciel propriétaire. Il
se base sur le fait que les projets open source peuvent faire tout ce dont sont capables les
projets commerciaux, tout en bénéficiant des avantages liés à l'ouverture du code. Mais cela
doit passer par une sensibilisation à la sécurité des communautés et de leur direction ainsi
que par une industrialisation des processus de développement, en y intégrant étroitement la
sécurité. Les communautés open source devraient en outre reconnaître l'importance
d'organismes d'audit indépendants.
David Wheeler11
insiste sur le fait qu'il n'est pas nécessaire d'avoir accès au code source
d'un programme pour en découvrir les vulnérabilités, surtout lorsqu'on a uniquement
l'intention de nuire. Il rappelle en outre que garder le secret au sujet d'une vulnérabilité ne la
fera jamais disparaître et compare cette pratique à une bombe à retardement. La conclusion
5
Risky Business: Keeping Security a Secret, W. Diffie, 2003, ZDNet, http://news.zdnet.com/2100-9595_22-
980938.html
6
LinuxSecurity.com Speaks With AES Winner, V. Rijmen, 2000,
http://www.linuxsecurity.com/content/view/117552/49/
7
Trust and Vulnerability in Open Source Software, S. A. Hissam, D. Plakosh et C. Weinstock, 2002, Software
IEE-Proceedings,, Vol 149-1, p 47-51, http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?arnumber=999090
8
Open Source in Security: Visting the Bizarre, F. B. Schneider, 2000, Proceedings of the 2000 IEEE Symposium
on Security and Privacy, May 14-17, 2000, Berkeley, CA. Los Alamitos, CA: IEEE Computer Society. pp.126-127.
9
The Myth of Open Source Security, J. Viega, 2002, http://www.developer.com/tech/article.php/621851
10
Open source security: still a myth, J. Viega, 2004, O'Reilly publisher (http://www.oreilly.com),
http://www.onlamp.com/pub/a/security/2004/09/16/open_source_security_myths.html
11
Secure Programming for Linux and Unix HOWTO : Creating secure software, D. A. Wheeler, 2003,
http://www.dwheeler.com/secure-programs
- 3 -
Logiciel libre et sécurité
de son argumentaire rejoint celle de John Viega: le fait de rendre un programme open
source ne garantit pas une meilleure sécurité. Un processus de revue effective de code
devrait être mis en place avec un regard particulier sur les questions relatives à la sécurité.
De plus le projet devrait inclure des spécialistes qui savent comment concevoir, développer
et examiner des programmes sûrs. Enfin un processus de correction des vulnérabilités et de
distribution des patches de corrections devrait être mis en place.
Pour compléter ce tableau, mentionnons l'article de Alain Boulanger12
dans lequel l'auteur
compare les modèles libre et propriétaire au niveau de la sécurité. Il y discute des aspects
liés à la sécurité et à la fiabilité de ces modèles en examinant deux points clés: l'ouverture du
code et le taux d'erreurs du logiciel. Boulanger réfute les arguments développés dans le livre
blanc publié en 2002 par l'organisation Alexis de Tocqueville Institution13
(fondée en partie
par Microsoft) et qui présente l'usage du logiciel libre dans les organismes gouvernementaux
comme un risque de sécurité majeur en raison de la visibilité du code pour les pirates
informatiques.
Outre les arguments déjà énoncés plus haut, Boulanger constate que les études recensant
le nombre et la fréquence des rapports de vulnérabilités dans les logiciels parlent plutôt en
faveur des logiciels libres que de leurs équivalents propriétaires, spécialement dans le cas
de projets d'envergure comme GNU/Linux, Apache (serveurs Web) ou MySQL (bases de
données). Comme plusieurs autres auteurs Boulanger conclut son article sans déclarer de
vainqueur: les arguments analytiques favorisant l'une ou l'autre approche ne sont en effet
pas concluants. Il est convaincu que les projets open source ayant atteint une masse critique
suffisante produiront des résultats supérieurs à leurs équivalents propriétaires, et ceci à un
moindre coût.
Pour résumer un sentiment largement partagé concernant le lien entre logiciel libre et
sécurité nous terminerons avec la citation de Elias Levy, ancien modérateur de Bugtraq (l'un
des forums de discussion majeurs consacrés à la sécurité), qui résume son point de vue sur
la question ainsi: « Cela signifie-t-il que le logiciel libre n'est pas meilleur que le logiciel
propriétaire en terme de sécurité ? La réponse est non. Le logiciel libre a certainement le
potentiel d'être plus sûr que son son équivalent propriétaire. Mais ne vous y trompez pas, le
simple fait d'être ouvert ne constitue pas une garantie de sécurité ».
Principaux arguments
Comme le propose un récent rapport du Gartner Group14
sur la question, on peut
sommairement regrouper les bénéfices et les risques associés à l'ouverture du code source
selon les quatre thèmes (très liés) développés ci-dessous. Chacun de ces thèmes fait
référence à bon nombre d'arguments développés au chapitre précédent.
Une multitude de réviseurs
L'opinion selon laquelle le logiciel libre est fondamentalement plus sûr que son équivalent
propriétaire s'appuie principalement sur l'une de ses qualités intrinsèques qu'est l'ouverture
du code source à une large communauté. Cette dernière, qui peut compter plusieurs milliers
de personnes dans certains projets, est capable de détecter et de corriger rapidement des
problèmes éventuels, au niveau de la sécurité notamment. Mais ce n'est pas seulement la
mutilitude des réviseurs qui fait la force du modèle open source; c'est surtout le mode de
12
Open-source versus proprietary software Is one more reliable and secure than the other?, A. Boulanger, 2005,
IBM Systems Journal, http://findarticles.com/p/articles/mi_m0ISJ/is_2_44/ai_n14707716
13
Opening the Open Source Debate: A White Paper, Alexis de Tocqueville Institution, 2002,
http://www.adti.net/ip/opensource.pdf
14
Open-Source and Closed-Source AD Security: Combining the Benefits of Both Paradigms, J. Feiman, Gartner
Group 2006, http://www.gartner.com
- 4 -
Logiciel libre et sécurité
travail des communautés qui collaborent en réseau en incluant de manière active
développeurs et utilisateurs de la solution.
Cet argument n'est cependant réellement valable que dans le cas où la communauté est
nombreuse et qu'elle peut compter sur des développeurs expérimentés, sensibilisés et
motivés par les questions relatives à la sécurité. Le fait de pouvoir s'appuyer sur des
spécialistes dans le domaine de la sécurité est également essentiel, ne serait-ce que pour
initier un projet sur de bonnes bases (architecture, méthodologie, etc.).
Comme le soulignent de nombreux spécialistes, il faut bien distinguer les potentialités
indiscutables offertes par le modèle open source de leur réelle mise en oeuvre au sein des
projets. Pour que ce modèle soit effectivement efficace dans le domaine de la sécurité, il faut
ainsi que le projet réponde à un minimum de critères:
réunir une communauté suffisamment importante
disposer de développeurs sensibilisés et motivés par les questions de sécurité
revoir et corriger effectivement le code en terme de sécurité
disposer si possible de spécialistes en la matière
Ouverture du code source
Les éditeurs de logiciels propriétaires prétendent souvent que le fait de cacher le code
source empêche les pirates potentiels d'exploiter les vulnérabilités d'un programme. Mais il
n'est pas nécessaire d'avoir accès au code source pour cela. Il existe des outils permettant
de désassembler les programmes ou de mettre en évidence des modèles de comportement
lors de leur utilisation comme les programmes de type Web application security vulnerability
scanners (WASVS) qui sont conçus pour détecter des vulnérabilités sans devoir accéder au
code source. Certains d'entre eux sont d'ailleurs des logiciels libres.
De nombreux experts réfutent l'argument de la sécurité par l'obsucrité qui a notamment pour
défaut de bercer les propriétaires d'une solution fermée dans l'illusion d'une fausse sécurité.
Si le fait de cacher le code source peut avoir un sens lorsque l'on désire préserver un
avantage concurrentiel, cela en a cependant peu, voir pas du tout en terme de sécurité.
L'ouverture du code source est à mettre directement en regard du point précédent. Elle ne
porte ses fruits au niveau de la sécurité que si le projet est correctement engagé dans une
démarche de révision prenant en compte la sécurité.
Certains experts affirment également que l'ouverture du code a un impact indirect sur la
sécurité car elle pousse les développeurs à écrire du code plus lisible, ce qui contribue à
améliorer la qualité du code, à facilite sa révision et à diminuer le nombre d'erreurs.
Détection précoce des problèmes
Dans le cas du logciel libre, lorsqu'un problème de sécurité est détecté, la communauté des
développeurs et des utilisateurs en est très vite informée. Cela augmente les chances de
résoudre rapidement le problème. Ce point est naturellement directement lié à l'ouverture du
code, mais également au mode de fonctionnement des communautés du libre. La rapidité de
réaction de la communauté dépend entre autres de la popularité et de la vitalité du projet.
Cet argument est très théorique. Il dépend d'une part de la taille de la communauté, de la
popularité du projet, de la sensibilité des utilisateurs et des développeurs à la sécurité ainsi
que de leur motivation à résoudre le problème soulevé. Mais il se trouve que dans de
nombreux projets, c'est effectivement le cas, comme le détaille Alain Boulanger13
.
- 5 -
Logiciel libre et sécurité
Méthodologies de développement
L'un des arguments avancés lorsque l'on parle de sécurité logicielle est celui de la
méthodologie de développement utilisée, que celle-ci soit générale (comme CMMI15
ou
TST/PSP16
) ou plus spécifique à la sécurité (comme SSE-CMM17
ou TST/PSP-secure18
).
Selon le Gartner Group, l'usage de ces méthodologies influe directement sur le niveau de
sécurité des solutions. Leur faible adoption par les projets open source peut être compensée
par les compétences de la communauté, pour autant que cette dernière soit suffisamment
importante, expérimentée et motivée à prendre en compte les aspects liés à la sécurité.
La sensibilisation des développeurs à de telles méthodologies ne peut qu'augmenter la
qualité des projets open source de moindre envergure.
Conclusion
Le logiciel libre a le potentiel pour être plus sûr que le logiciel propriétaire. Les projets open
source peuvent en effet réaliser tout ce dont sont capables les projets réalisés en mode
fermé, tout en bénéficiant des avantages liés à l'ouverture du code et au mode de
développement communautaire. De nombreux projets open source de qualité supérieure
sont là pour le prouver.
Mais il faut bien distinguer les potentialités indiscutables offertes par le modèle open source
de leur réelle mise en oeuvre au sein des projets. Pour que ce modèle soit réellement
efficace dans le domaine de la sécurité, il faut ainsi que le projet:
réunisse une communauté suffisamment importante,
dispose de développeurs sensibilisés et motivés par les questions de sécurité,
revoie et corrige effectivement le code en terme de sécurité et
dispose si possible de spécialistes en la matière.
Cela doit passer par une sensibilisation à la sécurité des communautés et de leur direction
ainsi que par une industrialisation des processus de développement, en y intégrant
étroitement la sécurité.
15
Capability Maturity Model Integration : http://www.sei.cmu.edu/cmmi
16
Team Software Process (TSP) and the Personal Software Process (PSP) : http://www.sei.cmu.edu/tsp
17
Systems Security Engineering Capability Maturity Model : http://www.sse-cmm.org/index.html
18
TST/PSP-secure : http://www.sei.cmu.edu/tsp/tsp-security.html
- 6 -

Contenu connexe

En vedette

Montréal Métropole Numérique - Atelier 4 - Ville de Montréal - Citoyen numérique
Montréal Métropole Numérique - Atelier 4 - Ville de Montréal - Citoyen numériqueMontréal Métropole Numérique - Atelier 4 - Ville de Montréal - Citoyen numérique
Montréal Métropole Numérique - Atelier 4 - Ville de Montréal - Citoyen numérique
TechnoMontréal
 

En vedette (6)

Montréal Métropole Numérique - Atelier 4 - Ville de Montréal - Citoyen numérique
Montréal Métropole Numérique - Atelier 4 - Ville de Montréal - Citoyen numériqueMontréal Métropole Numérique - Atelier 4 - Ville de Montréal - Citoyen numérique
Montréal Métropole Numérique - Atelier 4 - Ville de Montréal - Citoyen numérique
 
Montréal Métropole Numérique - Atelier 4 - 8 mars - Living Lab de Montréal -...
Montréal Métropole Numérique - Atelier 4 - 8 mars -  Living Lab de Montréal -...Montréal Métropole Numérique - Atelier 4 - 8 mars -  Living Lab de Montréal -...
Montréal Métropole Numérique - Atelier 4 - 8 mars - Living Lab de Montréal -...
 
Gestion des contenus d'entreprise: clarification des notions
Gestion des contenus d'entreprise: clarification des notionsGestion des contenus d'entreprise: clarification des notions
Gestion des contenus d'entreprise: clarification des notions
 
50 rules of innovation
50 rules of innovation50 rules of innovation
50 rules of innovation
 
How to Make Awesome SlideShares: Tips & Tricks
How to Make Awesome SlideShares: Tips & TricksHow to Make Awesome SlideShares: Tips & Tricks
How to Make Awesome SlideShares: Tips & Tricks
 
Getting Started With SlideShare
Getting Started With SlideShareGetting Started With SlideShare
Getting Started With SlideShare
 

Similaire à Logiciel libre et sécurité

Livret bleu qualitelogicielle_gt-logiciellibre_systematic
Livret bleu qualitelogicielle_gt-logiciellibre_systematicLivret bleu qualitelogicielle_gt-logiciellibre_systematic
Livret bleu qualitelogicielle_gt-logiciellibre_systematic
Pascal Flamand
 
Rational France - Livre blanc - Choisir le bon outil pour outils pour faire d...
Rational France - Livre blanc - Choisir le bon outil pour outils pour faire d...Rational France - Livre blanc - Choisir le bon outil pour outils pour faire d...
Rational France - Livre blanc - Choisir le bon outil pour outils pour faire d...
Rational_France
 

Similaire à Logiciel libre et sécurité (20)

No code low code
No code low codeNo code low code
No code low code
 
Un écosystème collaboratif open source et zerotrust dans le cloud public, est...
Un écosystème collaboratif open source et zerotrust dans le cloud public, est...Un écosystème collaboratif open source et zerotrust dans le cloud public, est...
Un écosystème collaboratif open source et zerotrust dans le cloud public, est...
 
Développement sécurisé
Développement sécuriséDéveloppement sécurisé
Développement sécurisé
 
Livret bleu qualitelogicielle_gt-logiciellibre_systematic
Livret bleu qualitelogicielle_gt-logiciellibre_systematicLivret bleu qualitelogicielle_gt-logiciellibre_systematic
Livret bleu qualitelogicielle_gt-logiciellibre_systematic
 
DevFest Abidjan 2022 - Les développeurs & IT au cœur de la sécurité de l'info...
DevFest Abidjan 2022 - Les développeurs & IT au cœur de la sécurité de l'info...DevFest Abidjan 2022 - Les développeurs & IT au cœur de la sécurité de l'info...
DevFest Abidjan 2022 - Les développeurs & IT au cœur de la sécurité de l'info...
 
Sogeti : cybersécurité - conserver l’avantage dans la partie
Sogeti : cybersécurité - conserver l’avantage dans la partieSogeti : cybersécurité - conserver l’avantage dans la partie
Sogeti : cybersécurité - conserver l’avantage dans la partie
 
Sogeti cybersecurity
Sogeti cybersecuritySogeti cybersecurity
Sogeti cybersecurity
 
docTrackr Inc. - This Year's Les Assises Innovation Prize Recipient.
docTrackr Inc. - This Year's Les Assises Innovation Prize Recipient. docTrackr Inc. - This Year's Les Assises Innovation Prize Recipient.
docTrackr Inc. - This Year's Les Assises Innovation Prize Recipient.
 
Introduction à Linux et aux logiciels libres
Introduction à Linux et aux logiciels libresIntroduction à Linux et aux logiciels libres
Introduction à Linux et aux logiciels libres
 
Webinaire Civic Tech : Pourquoi l'open source devient-il la norme pour les dé...
Webinaire Civic Tech : Pourquoi l'open source devient-il la norme pour les dé...Webinaire Civic Tech : Pourquoi l'open source devient-il la norme pour les dé...
Webinaire Civic Tech : Pourquoi l'open source devient-il la norme pour les dé...
 
Réussir facilement sa migration antivirus
Réussir facilement sa migration antivirusRéussir facilement sa migration antivirus
Réussir facilement sa migration antivirus
 
Open source-si
Open source-siOpen source-si
Open source-si
 
Introduction au test_logiciel-fr
Introduction au test_logiciel-frIntroduction au test_logiciel-fr
Introduction au test_logiciel-fr
 
Rational France - Livre blanc - Choisir le bon outil pour outils pour faire d...
Rational France - Livre blanc - Choisir le bon outil pour outils pour faire d...Rational France - Livre blanc - Choisir le bon outil pour outils pour faire d...
Rational France - Livre blanc - Choisir le bon outil pour outils pour faire d...
 
Rational France livre blanc - choisir le bon outil pour faire du bon travail
Rational France   livre blanc - choisir le bon outil pour faire du bon travailRational France   livre blanc - choisir le bon outil pour faire du bon travail
Rational France livre blanc - choisir le bon outil pour faire du bon travail
 
La sécurité endpoint : efficace, mais pas efficient
La sécurité endpoint : efficace, mais pas efficientLa sécurité endpoint : efficace, mais pas efficient
La sécurité endpoint : efficace, mais pas efficient
 
resume-theorique-m206-v1-0-630dcd4c22d1d (1).pdf
resume-theorique-m206-v1-0-630dcd4c22d1d (1).pdfresume-theorique-m206-v1-0-630dcd4c22d1d (1).pdf
resume-theorique-m206-v1-0-630dcd4c22d1d (1).pdf
 
Ch_1 - Généralités sur la sécurité informatique.pdf
Ch_1 - Généralités sur la sécurité informatique.pdfCh_1 - Généralités sur la sécurité informatique.pdf
Ch_1 - Généralités sur la sécurité informatique.pdf
 
Baudoin karle-ids-ips
Baudoin karle-ids-ipsBaudoin karle-ids-ips
Baudoin karle-ids-ips
 
Cyberun #12
Cyberun #12Cyberun #12
Cyberun #12
 

Plus de Patrick Genoud

Plus de Patrick Genoud (10)

Rebooting public administration
Rebooting public administrationRebooting public administration
Rebooting public administration
 
Open data - Comité de direction de l'OCSTAT
Open data - Comité de direction de l'OCSTATOpen data - Comité de direction de l'OCSTAT
Open data - Comité de direction de l'OCSTAT
 
Open Data - CFU SITG 24/11/2011
Open Data - CFU SITG 24/11/2011Open Data - CFU SITG 24/11/2011
Open Data - CFU SITG 24/11/2011
 
Ouverture des données publiques: une opportunité pour Genève
Ouverture des données publiques: une opportunité pour GenèveOuverture des données publiques: une opportunité pour Genève
Ouverture des données publiques: une opportunité pour Genève
 
Ouverture des données publiques: une opportunité pour Genève
Ouverture des données publiques: une opportunité pour GenèveOuverture des données publiques: une opportunité pour Genève
Ouverture des données publiques: une opportunité pour Genève
 
Vers une participation citoyenne augmentée
Vers une participation citoyenne augmentéeVers une participation citoyenne augmentée
Vers une participation citoyenne augmentée
 
Living Lab e-Inclusion - Rapport de pré-étude
Living Lab e-Inclusion - Rapport de pré-étudeLiving Lab e-Inclusion - Rapport de pré-étude
Living Lab e-Inclusion - Rapport de pré-étude
 
Les tiers lieux, espaces d'émergence et de créativité res2010
Les tiers lieux, espaces d'émergence et de créativité res2010Les tiers lieux, espaces d'émergence et de créativité res2010
Les tiers lieux, espaces d'émergence et de créativité res2010
 
Ouverture vers les citoyens - Exercice de style sur la mobilité
Ouverture vers les citoyens - Exercice de style sur la mobilitéOuverture vers les citoyens - Exercice de style sur la mobilité
Ouverture vers les citoyens - Exercice de style sur la mobilité
 
Pistes enseignement Informatique et Internet
Pistes enseignement Informatique et InternetPistes enseignement Informatique et Internet
Pistes enseignement Informatique et Internet
 

Logiciel libre et sécurité

  • 1. REPUBLIQUE ET CANTON DE GENEVE Département des constructions et des technologies de l'information Centre des technologies de l'information Logiciel libre et sécurité Auteurs Patrick GENOUD, Observatoire technologique Version / Date d’enregistrement V1.0 / 2007-04-05 Pour aller à l'essentiel Observatoire technologique Téléphone +41 (22) 388 13 50 • Fax +41 (22) 388 13 57 • www.geneve.ch Le logiciel libre a le potentiel pour être plus sûr que le logiciel propriétaire. Les projets open source peuvent en effet réaliser tout ce dont sont capables les projets réalisés en mode fermé, tout en bénéficiant des avantages liés à l'ouverture du code et au mode de développement communautaire. De nombreux projets open source de qualité supérieure sont là pour le prouver. Mais il faut bien distinguer les potentialités indiscutables offertes par le modèle open source de leur réelle mise en oeuvre au sein des projets. Pour que ce modèle soit réellement efficace dans le domaine de la sécurité, il faut ainsi que le projet réunisse une communauté suffisamment importante, dispose de développeurs sensibilisés et motivés par les questions de sécurité, revoie et corrige effectivement le code en terme de sécurité et dispose si possible de spécialistes en la matière. Cela doit passer par une sensibilisation à la sécurité des communautés et de leur direction ainsi que par une industrialisation des processus de développement, en y intégrant étroitement la sécurité.
  • 2. Logiciel libre et sécurité Contexte Dans le premier plan de mesures publié en novembre 2006 par le conseil d'État du canton de Genève, la promotion de l'utilisation de logiciels libres figure en bonne place (mesure n° 28). Le Centre des technologies de l'information (CTI) s'est engagé dans cette démarche avec une approche éloignée de tout dogmatisme. Comme nous l'avons détaillé dans un précédent rapport1 , l’intérêt du secteur public pour le logiciel libre est aujourd’hui indéniable, en particulier parce qu’il met très souvent en œuvre des standards ouverts, qu’il brise les positions de lock-in et qu’il permet une plus grand adaptabilité aux besoins particuliers. Les motivations essentielles avancées par les gouvernements sont une meilleure maîtrise et une pérennité accrue de leurs propres systèmes d’information, une plus grande neutralité dans le choix de vendeurs de solutions ainsi qu’une ouverture vers les entreprises et les citoyens désirant ou devant interagir avec les administrations. Au delà de ces apports stratégiques indéniables, un nombre croissant de solutions open source gagnent en popularité en raison de leur excellentes performances, de leur fiabilité et de leur coût d'achat faible ou nul. La sécurité est également un domaine souvent mis en avant lorsque l'on évoque les avantages associés au logiciel libre. Cet aspect suscite de nombreuses controverses et les études qui y sont consacrées ne permettent pas d'apporter un point de vue définitif sur la question. Le but de ce document est de porter un regard nuancé sur le lien entre sécurité et logiciel libre en se référant à l'avis de quelques experts dans le domaine. Mais en préambule à toute considération relative aux aspects spécifiques liés à la sécurité, il n'est pas inutile de rappeler que le choix d'une solution informatique de devrait pas être conditionné par un seul critère particulier (comme la sécurité dans le cas qui nous intéresse), mais plutôt être envisagé de manière globale comme le suggère par exemple le référentiel NPT2 . La sécurité informatique est un vaste domaine et nous limiterons notre argumentaire aux aspects liés au développement d'applications en mode open source ou en mode fermé (par opposition au mode open source). Dans ce document nous utiliserons de manière indifférente les termes de logiciel libre et de logiciel open source dont nous avons déjà précisé la définition ailleurs1 . Points de vue d'experts L'expert en sécurité informatique David Wheeler3 propose dans un excellent document accessible en ligne un chapitre consacré à la relation entre open source et sécurité. Il y rappelle notamment le point de vue de plusieurs experts dans le domaine dont plusieurs sont cités ici. Cette revue n'a pas la prétention d'être exhaustive; elle illustre les principaux arguments énoncés lorsque l'on évoque le sujet. Bruce Schneier4 , expert en sécurité et en cryptographie, prétend que tout développeur devrait exiger de bâtir des solutions de sécurité sur des composants open source. La 1 Standards ouverts et logiciel libre Clarification des notions, P. Genoud et G. Pauletto, Observatoire Technologique, Centre des technologies de l’information du canton de Genève, 2005, http://ot.geneve.ch 2 Référentiel Nouvelles Plateformes Technologiques, P. Genoud et G. Pauletto, Observatoire Technologique, Centre des technologies de l’information du canton de Genève, 2003, http://ot.geneve.ch 3 Secure Programming for Linux and Unix HOWTO : Creating secure software, D. A. Wheeler, 2003, http://www.dwheeler.com/secure-programs 4 Open Source and Security, B. Schneier, 1999, Crypto-Gram. Counterpane Internet Security, Inc., http://www.counterpane.com/crypto-gram-9909.html - 2 -
  • 3. Logiciel libre et sécurité meilleure manière d'augmenter le niveau de qualité d'une solution est selon lui de permettre son examen par le plus grand nombre d'experts possible. Pour répondre à l'argument du secret souvent avancé par les défenseurs des logiciel fermés, Bruce Schneier insiste sur le fait que les composants open source sont conçus pour être sûrs malgré le fait qu'ils soient publics; c'est dans leur essence même. Dans un article consacré au sujet Whitfield Diffie5 , le co-inventeur de la cryptographie à clé publique, conclut en réponse aux arguments des adversaires de l'ouverture du code dans le domaine de la sécurité: « Il est simplement irréaliste de dépendre du secret en matière de sécurité des programmes informatiques. On peut prévenir la divulgation du mode de fonctionnement d'un programme, mais empêchera-t-on le code d'être désassemblé par des adversaires sérieux ? Probablement pas. ». Vincent Rijmen6 , l'un des développeurs de l'algorithme d'encryption AES (Advanced Encryption Standard) pense que la nature même du système d'exploitation open source Linux permet de mieux détecter et réparer les vulnérabilités de sécurité, non seulement parce que les gens ont accès au code, mais aussi et surtout parce que le modèle force les développeurs à adhérer à des standards et à produire du code plus clair, ce qui à son tour facilite la revue du code. Mais Hissam et al7 relèvent le fait que l'accessibilité au code ne signifie pas nécessairement que celui-ci a été revu, notamment au niveau de la sécurité. Mais ils soulignent dans le même temps que c'est également le cas pour du code propriétaire. Mais certains comme Fred Schneider8 ne croient pas que le logiciel libre contribue à la sécurité. Il n'y a selon lui pas de raison de penser que de nombreuses personnes inspectant un code ouvert soient forcément efficaces dans la détection de bugs liés à la sécurité. D'autre part, les bugs présents dans le code ne sont selon lui pas la cause majeure des attaques. John Viega9 tempère ce point de vue en affirmant: « Les projets open source peuvent être plus sûrs que les projets dont le code est fermé. Cependant les aspects qui peuvent rendre un programme plus sûr – la disponibilité du code source et le fait qu'un grand nombre de personnes peuvent rechercher et réparer des trous de sécurité – peut aussi bercer les gens dans un faux sentiment de sécurité. ». Dans un article plus récent10 , il considère que le logiciel libre a, sur le long terme, le potentiel pour être plus sûr que le logiciel propriétaire. Il se base sur le fait que les projets open source peuvent faire tout ce dont sont capables les projets commerciaux, tout en bénéficiant des avantages liés à l'ouverture du code. Mais cela doit passer par une sensibilisation à la sécurité des communautés et de leur direction ainsi que par une industrialisation des processus de développement, en y intégrant étroitement la sécurité. Les communautés open source devraient en outre reconnaître l'importance d'organismes d'audit indépendants. David Wheeler11 insiste sur le fait qu'il n'est pas nécessaire d'avoir accès au code source d'un programme pour en découvrir les vulnérabilités, surtout lorsqu'on a uniquement l'intention de nuire. Il rappelle en outre que garder le secret au sujet d'une vulnérabilité ne la fera jamais disparaître et compare cette pratique à une bombe à retardement. La conclusion 5 Risky Business: Keeping Security a Secret, W. Diffie, 2003, ZDNet, http://news.zdnet.com/2100-9595_22- 980938.html 6 LinuxSecurity.com Speaks With AES Winner, V. Rijmen, 2000, http://www.linuxsecurity.com/content/view/117552/49/ 7 Trust and Vulnerability in Open Source Software, S. A. Hissam, D. Plakosh et C. Weinstock, 2002, Software IEE-Proceedings,, Vol 149-1, p 47-51, http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?arnumber=999090 8 Open Source in Security: Visting the Bizarre, F. B. Schneider, 2000, Proceedings of the 2000 IEEE Symposium on Security and Privacy, May 14-17, 2000, Berkeley, CA. Los Alamitos, CA: IEEE Computer Society. pp.126-127. 9 The Myth of Open Source Security, J. Viega, 2002, http://www.developer.com/tech/article.php/621851 10 Open source security: still a myth, J. Viega, 2004, O'Reilly publisher (http://www.oreilly.com), http://www.onlamp.com/pub/a/security/2004/09/16/open_source_security_myths.html 11 Secure Programming for Linux and Unix HOWTO : Creating secure software, D. A. Wheeler, 2003, http://www.dwheeler.com/secure-programs - 3 -
  • 4. Logiciel libre et sécurité de son argumentaire rejoint celle de John Viega: le fait de rendre un programme open source ne garantit pas une meilleure sécurité. Un processus de revue effective de code devrait être mis en place avec un regard particulier sur les questions relatives à la sécurité. De plus le projet devrait inclure des spécialistes qui savent comment concevoir, développer et examiner des programmes sûrs. Enfin un processus de correction des vulnérabilités et de distribution des patches de corrections devrait être mis en place. Pour compléter ce tableau, mentionnons l'article de Alain Boulanger12 dans lequel l'auteur compare les modèles libre et propriétaire au niveau de la sécurité. Il y discute des aspects liés à la sécurité et à la fiabilité de ces modèles en examinant deux points clés: l'ouverture du code et le taux d'erreurs du logiciel. Boulanger réfute les arguments développés dans le livre blanc publié en 2002 par l'organisation Alexis de Tocqueville Institution13 (fondée en partie par Microsoft) et qui présente l'usage du logiciel libre dans les organismes gouvernementaux comme un risque de sécurité majeur en raison de la visibilité du code pour les pirates informatiques. Outre les arguments déjà énoncés plus haut, Boulanger constate que les études recensant le nombre et la fréquence des rapports de vulnérabilités dans les logiciels parlent plutôt en faveur des logiciels libres que de leurs équivalents propriétaires, spécialement dans le cas de projets d'envergure comme GNU/Linux, Apache (serveurs Web) ou MySQL (bases de données). Comme plusieurs autres auteurs Boulanger conclut son article sans déclarer de vainqueur: les arguments analytiques favorisant l'une ou l'autre approche ne sont en effet pas concluants. Il est convaincu que les projets open source ayant atteint une masse critique suffisante produiront des résultats supérieurs à leurs équivalents propriétaires, et ceci à un moindre coût. Pour résumer un sentiment largement partagé concernant le lien entre logiciel libre et sécurité nous terminerons avec la citation de Elias Levy, ancien modérateur de Bugtraq (l'un des forums de discussion majeurs consacrés à la sécurité), qui résume son point de vue sur la question ainsi: « Cela signifie-t-il que le logiciel libre n'est pas meilleur que le logiciel propriétaire en terme de sécurité ? La réponse est non. Le logiciel libre a certainement le potentiel d'être plus sûr que son son équivalent propriétaire. Mais ne vous y trompez pas, le simple fait d'être ouvert ne constitue pas une garantie de sécurité ». Principaux arguments Comme le propose un récent rapport du Gartner Group14 sur la question, on peut sommairement regrouper les bénéfices et les risques associés à l'ouverture du code source selon les quatre thèmes (très liés) développés ci-dessous. Chacun de ces thèmes fait référence à bon nombre d'arguments développés au chapitre précédent. Une multitude de réviseurs L'opinion selon laquelle le logiciel libre est fondamentalement plus sûr que son équivalent propriétaire s'appuie principalement sur l'une de ses qualités intrinsèques qu'est l'ouverture du code source à une large communauté. Cette dernière, qui peut compter plusieurs milliers de personnes dans certains projets, est capable de détecter et de corriger rapidement des problèmes éventuels, au niveau de la sécurité notamment. Mais ce n'est pas seulement la mutilitude des réviseurs qui fait la force du modèle open source; c'est surtout le mode de 12 Open-source versus proprietary software Is one more reliable and secure than the other?, A. Boulanger, 2005, IBM Systems Journal, http://findarticles.com/p/articles/mi_m0ISJ/is_2_44/ai_n14707716 13 Opening the Open Source Debate: A White Paper, Alexis de Tocqueville Institution, 2002, http://www.adti.net/ip/opensource.pdf 14 Open-Source and Closed-Source AD Security: Combining the Benefits of Both Paradigms, J. Feiman, Gartner Group 2006, http://www.gartner.com - 4 -
  • 5. Logiciel libre et sécurité travail des communautés qui collaborent en réseau en incluant de manière active développeurs et utilisateurs de la solution. Cet argument n'est cependant réellement valable que dans le cas où la communauté est nombreuse et qu'elle peut compter sur des développeurs expérimentés, sensibilisés et motivés par les questions relatives à la sécurité. Le fait de pouvoir s'appuyer sur des spécialistes dans le domaine de la sécurité est également essentiel, ne serait-ce que pour initier un projet sur de bonnes bases (architecture, méthodologie, etc.). Comme le soulignent de nombreux spécialistes, il faut bien distinguer les potentialités indiscutables offertes par le modèle open source de leur réelle mise en oeuvre au sein des projets. Pour que ce modèle soit effectivement efficace dans le domaine de la sécurité, il faut ainsi que le projet réponde à un minimum de critères: réunir une communauté suffisamment importante disposer de développeurs sensibilisés et motivés par les questions de sécurité revoir et corriger effectivement le code en terme de sécurité disposer si possible de spécialistes en la matière Ouverture du code source Les éditeurs de logiciels propriétaires prétendent souvent que le fait de cacher le code source empêche les pirates potentiels d'exploiter les vulnérabilités d'un programme. Mais il n'est pas nécessaire d'avoir accès au code source pour cela. Il existe des outils permettant de désassembler les programmes ou de mettre en évidence des modèles de comportement lors de leur utilisation comme les programmes de type Web application security vulnerability scanners (WASVS) qui sont conçus pour détecter des vulnérabilités sans devoir accéder au code source. Certains d'entre eux sont d'ailleurs des logiciels libres. De nombreux experts réfutent l'argument de la sécurité par l'obsucrité qui a notamment pour défaut de bercer les propriétaires d'une solution fermée dans l'illusion d'une fausse sécurité. Si le fait de cacher le code source peut avoir un sens lorsque l'on désire préserver un avantage concurrentiel, cela en a cependant peu, voir pas du tout en terme de sécurité. L'ouverture du code source est à mettre directement en regard du point précédent. Elle ne porte ses fruits au niveau de la sécurité que si le projet est correctement engagé dans une démarche de révision prenant en compte la sécurité. Certains experts affirment également que l'ouverture du code a un impact indirect sur la sécurité car elle pousse les développeurs à écrire du code plus lisible, ce qui contribue à améliorer la qualité du code, à facilite sa révision et à diminuer le nombre d'erreurs. Détection précoce des problèmes Dans le cas du logciel libre, lorsqu'un problème de sécurité est détecté, la communauté des développeurs et des utilisateurs en est très vite informée. Cela augmente les chances de résoudre rapidement le problème. Ce point est naturellement directement lié à l'ouverture du code, mais également au mode de fonctionnement des communautés du libre. La rapidité de réaction de la communauté dépend entre autres de la popularité et de la vitalité du projet. Cet argument est très théorique. Il dépend d'une part de la taille de la communauté, de la popularité du projet, de la sensibilité des utilisateurs et des développeurs à la sécurité ainsi que de leur motivation à résoudre le problème soulevé. Mais il se trouve que dans de nombreux projets, c'est effectivement le cas, comme le détaille Alain Boulanger13 . - 5 -
  • 6. Logiciel libre et sécurité Méthodologies de développement L'un des arguments avancés lorsque l'on parle de sécurité logicielle est celui de la méthodologie de développement utilisée, que celle-ci soit générale (comme CMMI15 ou TST/PSP16 ) ou plus spécifique à la sécurité (comme SSE-CMM17 ou TST/PSP-secure18 ). Selon le Gartner Group, l'usage de ces méthodologies influe directement sur le niveau de sécurité des solutions. Leur faible adoption par les projets open source peut être compensée par les compétences de la communauté, pour autant que cette dernière soit suffisamment importante, expérimentée et motivée à prendre en compte les aspects liés à la sécurité. La sensibilisation des développeurs à de telles méthodologies ne peut qu'augmenter la qualité des projets open source de moindre envergure. Conclusion Le logiciel libre a le potentiel pour être plus sûr que le logiciel propriétaire. Les projets open source peuvent en effet réaliser tout ce dont sont capables les projets réalisés en mode fermé, tout en bénéficiant des avantages liés à l'ouverture du code et au mode de développement communautaire. De nombreux projets open source de qualité supérieure sont là pour le prouver. Mais il faut bien distinguer les potentialités indiscutables offertes par le modèle open source de leur réelle mise en oeuvre au sein des projets. Pour que ce modèle soit réellement efficace dans le domaine de la sécurité, il faut ainsi que le projet: réunisse une communauté suffisamment importante, dispose de développeurs sensibilisés et motivés par les questions de sécurité, revoie et corrige effectivement le code en terme de sécurité et dispose si possible de spécialistes en la matière. Cela doit passer par une sensibilisation à la sécurité des communautés et de leur direction ainsi que par une industrialisation des processus de développement, en y intégrant étroitement la sécurité. 15 Capability Maturity Model Integration : http://www.sei.cmu.edu/cmmi 16 Team Software Process (TSP) and the Personal Software Process (PSP) : http://www.sei.cmu.edu/tsp 17 Systems Security Engineering Capability Maturity Model : http://www.sse-cmm.org/index.html 18 TST/PSP-secure : http://www.sei.cmu.edu/tsp/tsp-security.html - 6 -