Discussion :

[Stéphane le calme]

Microsoft : concevoir un logiciel invulnérable est impossible
le vice-président de Trustworthy Computing présente la stratégie de sécurité de la société

Pendant la Security Development Conference de Microsoft qui a eu lieu à San Francisco, Scott Charney, vice-président de Trustworthy Computing (informatique de confiance) de Microsoft, a raconté les épreuves que Microsoft a subi en essayant d'apporter des correctifs à ses processus SDL (Security Development Process).

Microsoft a institué ce processus de développement logiciel en janvier 2004 dans le but de réduire les coûts de la maintenance logicielle et d'augmenter sa fiabilité au niveau sécurité et bogues. La firme en a fait usage et l'a proposé aux entreprises.

Seulement, le processus SDL s'est heurté a des difficultés quand des équipes de production voulaient avancer avec leurs propres produits mais en étaient empêchées par les nouvelles exigences de sécurité de Microsoft. Charney se rappelle de la première fois que Microsoft a eu à dire à une équipe de production qu'elle ne pouvait pas faire usage de la solution qu'elle avait développée ; « ils étaient comme des cerfs dans un phare. »

Bien que SDL ait contribué à réduire considérablement les vulnérabilités, Charney affirme que Microsoft sait qu'elle n'atteindra jamais le seuil de la vulnérabilité zéro. « Ce n'est tout simplement pas possible. Les logiciels sont écrits par des êtres humains et ils commettent des erreurs. »

Et de continuer « La raison pour laquelle nous nous devons de faire du développement sécurité c'est qu'il y a un bon pourcentage de la population qui n'est bon à rien. »

Source : Microsoft Security Development Conference 2013

Et vous ?

Que pensez-vous de ces propos ?

[Squisqui]

La faille 32, ils ne l'auront pas

Si le seuil de vulnérabilité zéro est impossible pour OpenBSD, alors il l'est également pour tous les autres. Tout de même 2 failles découvertes depuis un sacré bout de temps.

[Voyvode]

L'invulnérabilité, l'invincibilité, l'intangibilité, la perfection… Tous ces termes n'ont de sens que dans un référentiel absolu qui n'existe pas réellement dans notre monde impermanent.

Une bonne pratique peut devenir une mauvaise pratique. Une méthode peut devenir deprecated. Un bug peut devenir une feature.

[CP / M]

Qu'ils prennent donc des leçons chez OpenBSD ^^

[jmnicolas]

Je reste sceptique sur "l'invincibilité" d'OpenBSD : vu qu'il n'y a rien d'activé à l'install de base c'est un peu comme construire un bunker sans porte et vanter son inviolabilité ...

J'imagine qu'un serveur OpenBSD en production, donc avec des services activés, est beaucoup moins invulnérable.

Et si on parle station de travail, il est livré avec FireFox par défaut et je doute que les p'tits gars d'OpenBSD aient le temps de sécuriser FireFox.
Il n'y a rien de plus vulnérable qu'un navigateur web.

Je suis donc de l'avis du Monsieur de chez Microsoft, aucun logiciel n'est invulnérable. Toutefois MS est quand même le mauvais élève de la classe, malgré leurs efforts qui datent de XP SP2.

[imikado]

Il est vrai qu'on ne peut jamais être exempt de faille à 100% c'est pour cela qu'existent des sociétés d'audit pour vérifier la sécurité de nos développements

Parcontre il est toujours plus facile d'avoir une solution plus sécurisé lorsqu'elle est opensource et ce pour plusieurs raisons:
1. on ouvre le code à la fois à un énorme groupe de développeurs soucieux d'améliorer la sécurité de l'application qu'ils utilisent. Ils font de la veille tous les jours, testent leur solution...
2. il est également ouvert aux hackers qui cherchent des failles, celles-ci sont donc plus facile à trouver pour eux, mais l'armée de développeurs "non hackeur" est plus important, donc il est plus simple pour un hackeur de découvrir une faille, mais vu le nombre de développeurs contrant, il est plus rapide pour la solution d'avoir un des développeurs trouvant une solution
3. une des premières recommandation de la cryptologie, est que le système ne repose pas sur le secret de la clé. Il en va de même pour du code: entre une application fermé où un stagiaire à écrit par erreur une faille, et la même application proposé en opensource:
Dans les deux applications, on a une faille, dans la première: l'application restera longtemps avec cette faille jusqu'à ce qu'un hackeur la trouve. il faudra du temps à l'équipe pour trouver le code de la faille
Dans le même cas en opensource, le/les hackeurs la trouveront très vite, mais peut être un developpeur "non hackeur" la verra également permettant de la corriger tres vite. Ou sinon, un hackeur l'exploitera mais une fois "connu" la masse de développeurs mettront peu de temps à trouver le code incriminé pour la corriger

En cryptologie, la sécurité par l'obscurité va à l'encontre du principe de Kerckhoffs qui veut que la sécurité de tout cryptosystème ne repose que sur le secret de la clé.

[s4mk1ng]

Il est impossible de faire un logiciel avec 100% de protection, la logique même veut que avec le temps il y aura toujours un jour où l'on réussira à craquer celui-ci

[fregolo52]

concevoir un logiciel invulnérable est impossible

Tout comme un logiciel avec zéro bug.

Qu'ils prennent donc des leçons chez OpenBSD ^^

Tant que les hackers ne s'y intéressent pas, OpenBSD peut être tranquille.

[transgohan]

Un logiciel invulnérable ? Mais si cela existe.
C'est le logiciel sur lequel on a pas encore trouvé de faille.
Mais cela n'implique pas qu'on n'en trouvera pas dans le futur, tout est question de temps.

Du coup il est toujours plus facile de sortir des versions tous les X temps que de chercher à faire une version invulnérable (bon sur le court terme, mais utopique sur le long terme).

[eomer212]

peut etre est-ce tout simplement leur methode qui est mauvaise. non.?
encore un truc fumeux, avec des exigeances absurdes et décalées de la réalité, l'utilisation de patterns limités, etc..
la meilleure securite, c'est de former les developpeurs à la securite, et que celle ci devienne une de leurs preoccupations majeures.

la securite, ca commence aussi par des developpeurs de qualité.
c'est pas en faisant faire par le moins disant au niveau du prix qu'on peut esperer quelque chose de qualité.
un developpeur est comme le vin, faut pas exiger de lui la perfection dés le depart, certains crus seront bons à jeter, mais on trouve aussi des pepites quelques fois..
mais ca, microsoft, qui n'a jamais corrigé le bug du lecteur de disquette, ils peuvent pas le comprendre..

[Invité]

Bonjour à tous,

@jmnicolas : OpenBSD n'est pas livré avec Firefox ??? Firefox fait parti des milliers d'applications qui peuvent être installés via le système des ports propres aux systèmes UNIX BSD.

La distribution part défaut fait à 250 Mo et elle n'intègre que l'essentiel pour la mise en place d'un serveur UNIX BSD (Ex : Kernel, gestionnaire de paquets, gcc modifié, perl, serveurs de messagerie sendmail modifié et smtpd depuis peu, shell : Ksh, apache modifié, le pare-feu PF, etc.) le tout en ligne de commande car OpenBSD n’est livré qu’avec l’un serveur X modifié sans aucun gadget du type (gnome 3 ou unity…).

OpenBSD n'a jamais eu la prétention d'être un OS pour desktop mais plutôt orienté serveurs.

Veuillez vous renseigner un minimum avant de dire n'importe quoi !!! Dire que je suis sur un site de développeurs "pro" !!!

@+

[germaino_0]

il y a un bon pourcentage de la population qui n'est bon à rien

Je n'aime pas critiquer les articles pour le plaisir, mais avez-vous lu ce que vous avez écrit ??

"there's always a percentage of the population up to no good." veut dire "il y a un pourcentage de la population habitée de mauvaises intentions".

De même,

"they were like deer in the headlights" est une expression qui signifie "ils étaient stupéfaits", pas

ils étaient comme des cerfs dans un phare.

2 erreurs de traduction affligeantes en 12 lignes de texte. Quelqu'un vérifie-t-il les articles ?

[chrtophe]

Pour répondre à germaino, probablement les mêmes qui relisent le code.

Pour être plus sérieux, je ne vois pas comment faire du code exempt de bugs quand les systèmes sur lequel s’exécute le dit code sont eux-mêmes bugués.

Par ailleurs on ne peut pas faire vite et bien, donc si on sors 1 nouvelle version tous les 6 mois ...

et puis l'erreur est humaine.

[MarieKisSlaJoue]

"they were like deer in the headlights" est une expression qui signifie "ils étaient stupéfaits", pas

ils étaient comme des cerfs dans les phares

2 erreurs de traduction affligeantes en 12 lignes de texte. Quelqu'un vérifie-t-il les articles ?

En même temps avec un cerf dans un phare y'a forcément une historie de stupéfiant quelque part.

Google trad c'est mal, l'enfoncement de porte ouverte aussi.

[talon]

Formellement, un logiciel est :
- soit trivial, on peut alors vérifier toutes les occurences de son fonctionnement, mais sa trivialité le rend inutile,
- soit complexe, alors le dispositif de test permettant de le qualifier dans l'absolu est encore plus complexe. Le dispositif de test doit être encore plus sûr que le logiciel à tester, ce qui est impossible du fait qu'il est lui-même plus complexe que le logiciel. Comme disaient les romains, qui seront les gardiens de nos guardiens.

Un logiciel possède un niveau de confiance (ou robustesse) plus ou moins élévé. Un logiciel complexe sans bugs, ça n'existe pas.
Par contre, il y a des logiciels qui ont plus de bugs que d'autres. On les connait.

[MRick]

Je pense que la seule manière de faire un logiciel invulnérable, c'est de faire un logiciel qui n'accepte absolument aucune entrée, et qui se contente d'effectuer toujours la même sortie, sans faire le moindre test. Et bien sûr aucune boucle.

En résumé, pas d'entrées, pas de test, pas de boucle = pas de possibilité de bug.

Donc ce genre de programme produit toujours exactement la même chose.

Le fameux programme "Hello World !" des débutants en est la parfait exemple.


Après, je suis bien conscient qu'un tel programme n'a pratiquement aucun intérêt, et quelque part, ça rejoint la conclusion de Scott Charney.

Je pense qu'il faudrait juste préciser sa citation :
Concevoir un logiciel utile et invulnérable est impossible.

[Neckara]

Le fameux programme "Hello World !" des débutants en est la parfait exemple.

Sauf qu'on peut parfois trouver des implémentation de la lib standard C bogguée par exemple et on peut aussi s'amuser avec LD_LIBRARY_PATH .

"Hello World !" utilise généralement printf en C ou std::cout en C++.
Or dans printf, on va avoir des tests .

Si jamais ton programme est lancé dans un programme père et que ce dernier ferme la sortie standard, je pense que ton "Hello World" va planter .

Donc il ne faut pas uniquement que ton programme n'aient pas de boucles, pas de tests et pas d'entrées, il faut aussi que les fonctions des bibliothèques que tu utilises en fasse autant et encore, c'est loin d'être suffisant .

[Pelote2012]

Déjà, faudrait blinder l'OS qui supporte le logiciel.
Sinon ça ressemblerait à une forteresse avec un trou plein de passages souterrains non gardés ...