Le threat modeling s'est imposé chez Microsoft après une période que l'on peut qualifier de "noire" au début des années 2000 et a grandement aidé à améliorer la sécurité de ses logiciels depuis. Toutefois, elle n'est pas forcément des plus faciles à implémenter.
Quelles sont vos expériences sur le sujet ? Est-ce que ce processus est utilisé dans vos développements informatiques ? Si oui, quels sont vos retours d'expérience ? Si non, pourquoi ? Le threat modeling consiste à modéliser les interactions entre les différents composants de l'application, les flux de données, les séparations de privilèges entre composants et les éléments de stockage afin de :
- Localiser les informations à protéger et savoir quels composants y ont accès ;
- Définir les points d'autorisation et authentification ;
- Définir les interfaces d'entrée de données externes et localiser le code où ces données devront être validées, ce qui permettra de définir l'étendue des tests à effectuer, notamment par fuzzing ;
- Définir les attaques possibles ;
- Définir les risques en cas de faille (élévation de privilège, déni de service, exposition d'informations privilégiées, ...) et quelles défenses peuvent être utilisées pour les contrer (par exemple, un envoi de requêtes en masse --> avoir une queue de requêtes en attente limitée, potentiellement divisée en groupe selon la tranche IP, etc.) ;
- Définir le risque d'une attaque selon la difficulté, le gain potentiel, ...
- Quelles parties du code doivent être auditées ;
- Quelles interfaces doivent être soumises au fuzzing ;
- Quels composants doivent valider les données qu'ils reçoivent avant de les traiter ;
- ...
Aller plus loin
- threat model sur Wikipédia (49 clics)
- Threat modeling en pratique chez OWASP (70 clics)
- Une liste d'outils libres pour la gestion des risques (OWASP) (54 clics)
- Fusil (16 clics)
# Pratiques d'une ère (dé)passée
Posté par Édouard Siha . Évalué à -10.
Ça, c'est débile : tu ne peux pas définir une liste des attaques possibles pour la simple et bonne raison qu'il en apparaît tous les jours.
Définir les risques en cas de faille (élévation de privilège, déni de service, exposition d'informations privilégiées, ...) et quelles défenses peuvent être utilisées pour les contrer (par exemple, un envoi de requêtes en masse --> avoir une queue de requêtes en attente limitée, potentiellement divisée en groupe selon la tranche IP, etc.) ;
Même tonneau pour celle-là : tu ne peux pas prévoir l'ensemble des risques donc ta liste va être obsolète aussitôt éditée. Pour faire un parallèle, c'est comme si tu décidais de te faire vacciner contre toutes les maladies que tu connais (ensemble donc très probablement inclus dans l'ensemble des maladies existantes, qui lui augmente de cardinal chaque jour) et que tu considérais être tranquille pour la fin de tes jours.
Définir le risque d'une attaque selon la difficulté, le gain potentiel, ...
Youpi, maintenant que tu as défini ce que tu appelles un "risque", tu es content d'avoir un outil pour classer les combinaisons entre attaque, cible et coût. L'ennui c'est que cette classification va te faire mettre en place des mesures préventives dédiées aux attaques les "plus risquées" tout en laissant de côté celles que tu vas considérer comme négligeables.
Quelles parties du code doivent être auditées ;
Toutes. La sécurité se conçoit comme un élément initial du développement du projet, pas comme une surcouche.
Quelles interfaces doivent être soumises au fuzzing ;
Ib idem, et pas que pour des raisons de sécurité, pour des raisons de stabilité aussi.
Quels composants doivent valider les données qu'ils reçoivent avant de les traiter ;
Tous. Sinon on en arrive à un désastre du même acabit que celui que Microsoft a su mettre en place lorsqu'ils ont autorisé leurs programmeurs à ne pas vérifier les valeur de retour des fonctions appelées.
[^] # Re: Pratiques d'une ère (dé)passée
Posté par Dring . Évalué à 10.
La plupart des attaques correspondent à des "types" déjà connu. L'article en énumère pas mal, il y en a d'autres, mais c'est grosso modo un terrain déjà bien déblayé.
Donc je ne vois pas en quoi c'est débile de se baser sur cette liste. Optimiste, à la rigueur, et encore.
Sous prétexte que de nouvelles attaques, voire de nouveaux types d'attaques, sont régulièrement créés, on ne peut pas avoir une approche qui consiste à se protéger de tout ce qui est connu ?
Ca ne veut pas dire qu'en plus il ne faut pas se remettre en cause, mais pour moi c'est un minimum syndical de se protéger des dangers connus.
[^] # Re: Pratiques d'une ère (dé)passée
Posté par Thomas Douillard . Évalué à 4.
Parce que concevoir la sécurité comme un tout, tout tester, certe, ça a l'air joli comme ça. Mais comment tu te protèges d'attaques inconnues, concrètement ?
[^] # Re: Pratiques d'une ère (dé)passée
Posté par Kerro . Évalué à 6.
Les humains le font depuis toujours: prévoir un minimum d'échappatoires, réfléchir et réagir vite.
Nous nous en sommes toujours bien tirés avec des choses horriblement plus complexes que l'informatique (et mortelles aussi, ce n'est pas un détail). Lorsque ça arrive avec l'informatique, c'est souvent bien vite résolu.
Je repense par exemple à l'attaque SYN flood. Lorsque les premières machines ont été attaquées, personne n'avait envisagé cette attaque (sauf l'attaquant forcément). La réaction a été très rapide. Les dégâts ont été très limités: internet n'est pas tombé par terre.
[^] # Re: Pratiques d'une ère (dé)passée
Posté par Thomas Douillard . Évalué à 2.
D'ailleurs ça devrait être une priorité, laisser une porte ouverte dont tout le monde connait la possibilité d'ouverture, ça laisse une place très importante pour les possibilités d'attaques de ce type.
[^] # Re: Pratiques d'une ère (dé)passée
Posté par Kerro . Évalué à 2.
C'est comme inventer un médicament contre tous les problèmes de santé inconnus jusqu'alors. Si tu y arrives, tu es riche.
[^] # Re: Pratiques d'une ère (dé)passée
Posté par Nicolas Boulay (site web personnel) . Évalué à 4.
Pourquoi activer -fstack-protector si tu es sûr de ne pas avoir de buffer overflow dans ton code ? Pourquoi activer "-pie" alors que tu es sûr de tes entrées ?
L'idée est d'avoir des "couches" de protection qui théoriquement se suffisent à elle-même, mais si elles sont passées, il reste la suivante.
Bien sûr, cela doit être fait correctement, il doit y avoir une réelle indépendance entre couche, sinon, il est possible d'affaiblir la sécurité.
"La première sécurité est la liberté"
[^] # Re: Pratiques d'une ère (dé)passée
Posté par Thomas Douillard . Évalué à 2.
[^] # Re: Pratiques d'une ère (dé)passée
Posté par Nicolas Boulay (site web personnel) . Évalué à 4.
"La première sécurité est la liberté"
[^] # Re: Pratiques d'une ère (dé)passée
Posté par Axioplase ıɥs∀ (site web personnel) . Évalué à 2.
Ben, suffit d'arrêter de coder en C/C++/ASM.
Je suis d'accord, ça devrait être une priorité…
[^] # Re: Pratiques d'une ère (dé)passée
Posté par lasher . Évalué à 3.
Cela dit, vouloir faire du C absolument (ou de l'ASM à ce niveau), pour une application complète, je trouve ça dommage, car chronophage. Je le dis d'autant plus librement que mon activité fait que je fais du C et de l'ASM tous les jours. :) Pas besoin d'invoquer l'argument (pertinent) de la sécurité à mon sens. Utiliser n'importe quel langage de plus haut niveau est bien souvent un gain de temps de développement tellement grand que ça devrait être suffisant pour convaincre n'importe qui de changer de langage la plupart du temps. Après il reste l'embarqué et le calcul haute-performance où le C reste intéressant.
[^] # Re: Pratiques d'une ère (dé)passée
Posté par Maclag . Évalué à 7.
Hors je pense qu'il parle plutôt de l'évolution d'applisi connues pour avoir des problèmes de sécurité à répétition:
Le source est plutôt gros, la base de clients importante.
On te charge de sécuriser l'appli, tu fais quoi:
- Tu dis que tu vas tout auditer et le résultat sera là quand il sera prêt?
- Tu dis que tu réécris tout depuis 0 et pareil: zut à la base utilisateur de la version actuelle, faudra patiente?
- Ou tu définis une liste de priorité afin de parer au plus urgent dans les mise-à-jour?
Je crois que l'approche décrit ce qu'il y a à faire dans le 3ème cas de figure, et que l'idée et de ne pas foncer tête baissée.
Cette approche me rappelle les approches qualité en production (production de composants): le but est d'améliorer constamment la fiabilité du processus/composant:
- On commence par des tableaux avec tous les problèmes connus pouvant arriver.
- On pondère avec la gravité du problème et sa fréquence estimée.
- On traite dans l'ordre de la pondération, sauf si un problème inconnu avec plus d'impact intervient.
Si tu penses que ce n'est pas la meilleure approche pour quelque chose qui existe déjà avec ses problèmes, que proposes-tu?
On rappelle qu'il ne s'agit pas ici de partir de 0, mais d'améliorer l'existant.
[^] # Re: Pratiques d'une ère (dé)passée
Posté par pasBill pasGates . Évalué à 1.
[^] # Re: Pratiques d'une ère (dé)passée
Posté par ~ lilliput (site web personnel) . Évalué à 4.
Soyons réaliste, la plupart des vulnérabilités que ce soit les projets WEB ou autres applications sont des vecteurs connus et très bien documentés. La communication entre communautés de la sécurité et des programmeurs était certes pauvre mais ce n'est plus le cas [1].
Si les règles de base étaient appliquées, on verrait une diminution notable de vulnérabilités présentes dans les logiciels. On va prendre le cas *simple* et récurrent des XSS/SQL injections dans les applications web, les filtrages sont souvent soit inexistants et reposent sur le framework parent (ASP/IIS mod_security etc), soit souvent basés sur des blacklists. Prenons l'exemple suivant:
http://host/script?id=1
Il est facile de vérifier que "id" est un entier strict compris entre 0-65535 (whitelist). Pourquoi la plupart des programmateurs n'enlèvent juste que les ' " < > sur un *string* (blacklist) ?
On est d'accord c'est la partie la moins plaisante de la programmation avec la documentation, on reçoit beaucoup moins d'échos quand l'application est simple mais sécurisée que bugguée avec plein de fonctions.
Côté protocoles, il faut essayer de prendre un peu de recul et regarder les vulnérabilités des autres protocoles similaires [2]. Il est vrai que la fonctionnalité gagne souvent sur la stabilité. Certains protocoles comme les URL souffrent d'une RFC trop laxiste tel que le double encodage pour le HTTP toujours autorisé ou bien la fragmentation IP [3].
Ne JAMAIS supposer qu'une variable d'entrée est sécurisée (trusted) qu'elle vienne de la base de données, ou d'un DNS [4] ou voire même d'un whois [5].
En appliquant ces règles simples, le temps passé à la correction des bugs est souvent nettement inférieur (j'ai lu un article récemment sur ce point mais je ne retrouve plus le lien)
[1]: http://www.owasp.org/index.php/Category:OWASP_Top_Ten_Projec(...)
[2]: (pub !) http://linuxfr.org/comments/1118391.html#1118391
[3]: http://www.symantec.com/connect/articles/evading-nids-revisi(...)
[4]: http://archives.neohapsis.com/archives/bugtraq/2001-10/0223.(...) , http://seclists.org/fulldisclosure/2004/Jun/438
[5]: http://ha.ckers.org/blog/20071230/xss-on-whois/
http://www.theatre-eibel.fr http://www.isc2chapter-yorkshire.co.uk
[^] # Re: Pratiques d'une ère (dé)passée
Posté par Ronan BARZIC . Évalué à 4.
Tu ne fais pas de tests ? Si ? Alors comment tu définis la suite de tests à effectuer, leur couverture, etc... ?
Les règles de base, c'est bien mais sans une stratégie de verification derrière ca ne te sert à rien. Vu la complexité croissante des projets, tu ne peux pas garantir à un cout raisonnable que tous tes développeurs ont suivis toutes les règles lors du design. Il te faut des stratégies de vérification qui dépasse la simple revue de code et les simples tests. D'ou l'apparition de stratégie comme décrit pBpG, pour aider à orienter les efforts, en commencant par définir ou sont les risques
[^] # Re: Pratiques d'une ère (dé)passée
Posté par pasBill pasGates . Évalué à 6.
...
Même tonneau pour celle-là : tu ne peux pas prévoir l'ensemble des risques donc ta liste va être obsolète aussitôt éditée.
Tout a fait, mais donc tu proposes quoi ? De ne rien faire parce qu'il est impossible de tout prevoir ?
Youpi, maintenant que tu as défini ce que tu appelles un "risque", tu es content d'avoir un outil pour classer les combinaisons entre attaque, cible et coût. L'ennui c'est que cette classification va te faire mettre en place des mesures préventives dédiées aux attaques les "plus risquées" tout en laissant de côté celles que tu vas considérer comme négligeables.
C'est possible, mais pas forcement, ca te permet aussi d'approcher la liste en odre de priorite tout simplement, savoir par quoi commencer.
Parce que soyons realiste, si tu ne l'as pas, tu risques a l'inverse de commencer par le risque le plus negligeable sans regler le risque le plus gros.
Toutes. La sécurité se conçoit comme un élément initial du développement du projet, pas comme une surcouche.
Oui ca c'est la belle theorie des gens qui n'ont jamais eu a s'occuper de la securite d'un gros projet.
La realite c'est que si tu as des composants qui sont utilises uniquement par l'interface d'administration par exemple, et que celle-ci est uniquement accessible a root, ben les auditer d'un point de vue securite ne sert pas a grand-chose, le gars il est deja root, une faille la dedans ne lui servira a rien, il n'en tirera rien d'utile, donc ca tombe en bas de la liste des priorites.
Ib idem, et pas que pour des raisons de sécurité, pour des raisons de stabilité aussi.
De nouveau, tu vas faire quoi avec ca ? Tu vas fuzzer la fonction memcpy(...) et lui passer des pointeurs illegaux dans ton espace d'addresse ? Pas tres utile vu que memcpy considere ses entrees comme sur par definition.
Tous. Sinon on en arrive à un désastre du même acabit que celui que Microsoft a su mettre en place lorsqu'ils ont autorisé leurs programmeurs à ne pas vérifier les valeur de retour des fonctions appelées.
Du tout, cf. l'exemple de memcpy
# OWASP, Ô DÉSESPOIR
Posté par j (site web personnel) . Évalué à 4.
[^] # Re: OWASP, Ô DÉSESPOIR
Posté par El Titi . Évalué à 3.
# Et ne pas avoir à protéger ces informations ?
Posté par Etienne Bagnoud (site web personnel) . Évalué à 7.
Combien d'applications demandent des informations super-sensibles pour, au final, ne nécessité que d'un nom d'utilisateur et d'un mot de passe pour fonctionner ?
Je penses qu'avant de se demander "comment protéger ces informations privilégiées ?" il faut se demander "quelles informations privilégiées sont _réellement_ nécessaires ?". En se tenant au besoin fonctionnel, on devrait diminuer nettement les risques.
Et finalement je suis pour qu'on responsabilise les dirigeants d'entreprises ayant perdues ce genre de données si le service ne nécessite pas, de manière fonctionnelle, ces données et si ces données sont obligatoires (si l'utilisateur à librement choisi de donner ces informations, c'est son problème) ou récoltées sans que l'utilisateur soit conscient.
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: Et ne pas avoir à protéger ces informations ?
Posté par pasBill pasGates . Évalué à 2.
Dans le monde du web oui je peux le comprendre, dans le monde de l'entreprise par exemple c'est pas le cas. Les informations ici elles sont d'un tout autre ordre : code source, informations financieres, details techniques de produits a venir, etc...
[^] # Re: Et ne pas avoir à protéger ces informations ?
Posté par Etienne Bagnoud (site web personnel) . Évalué à 4.
Mais au final, en entreprise, je crois pas qu'il ait grand chose à faire. Celui qui s'attaque en frontal au système informatique, il a rien compris. Regardes la cas de HBC et du vol d'informations : tu veux des données informatiques, tu passes par les êtres humaines, c'est sûre, fiable, de qualité et moins chère.
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: Et ne pas avoir à protéger ces informations ?
Posté par pasBill pasGates . Évalué à 2.
[^] # Re: Et ne pas avoir à protéger ces informations ?
Posté par Etienne Bagnoud (site web personnel) . Évalué à 3.
Mais je trouve que dans ce domaine on en fait beaucoup trop dans un sens et pas assez dans l'autre. En fait on commence à créer de plus en plus de logiciel où l'on rajoute des couches de confirmations pour l'utilisateur (prends les navigateurs web et le SSL, c'est bientôt 3'000 cliques pour se connecter à un site avec self-signed certificate). C'est le résultat de "Threat modeling", à mon avis.
Un logiciel sécurisé, c'est un logiciel où l'utilisateur peut directement accéder à l'information dont il a le droit, où l'administrateur peut contrôler pleinement toutes les couches de sécurités (et les désactiver s'il juge nécessaire) et où le développeur a pris toutes les précautions nécessaires et connues. Et pour que cela existe, il faut pas créer des nouveaux concepts, il faut commencer par apporter des garanties.
Une information est perdue parce que j'utilise le logiciel X "closed-source", je perds ma place de travail.
Une information est perdue parce que j'utilise le logiciel Y "open-source", je perds ma place de travail.
Donc si j'utilises des systèmes Microsoft (c'est pas du troll) je n'ai aucune garantie de la part de Microsoft et je mets en jeu ma place de travail autant qu'avec des logiciels open-source, sauf que dans un cas j'ai accès au code.
La première menace informatique c'est l'obscurité. Si je ne peux pas voir tous les rouages du système que j'utilise, comment je peux les montrer aux utilisateurs et les éduquer à utiliser correctement le logiciel ?
Si, d'un autre côté, l'entreprise, qui me cache le fonctionnement du logiciel, prend ses responsabilités et me donne la garantie que cela fonctionne et que je ne risque pas mon travail en utilisant le logiciel, je veux bien être aveugle. Mais prendre l'option "j'assume les responsabilités d'un truc que je ne peux pas voir", c'est exclu.
Alors pour faire du "threat modeling", il faut mettre les _bons_ problèmes de sécurités en avant. La sécurité par l'obscurité est le premier problème. Résolvons cette menace en premier, donnez nous le code ou des garanties formelles !
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: Et ne pas avoir à protéger ces informations ?
Posté par pasBill pasGates . Évalué à 3.
La première menace informatique c'est l'obscurité. Si je ne peux pas voir tous les rouages du système que j'utilise, comment je peux les montrer aux utilisateurs et les éduquer à utiliser correctement le logiciel ?
Tu m'excuseras, mais ca c'est une raison a la con.
Tu n'as certainement jamais audite le code de Linux ou de Firefox du point de vue securite, tu n'en as pas les competences (pas une critique, tres peu de gens l'ont), tu n'as pas la connaissance du code pour comprendre ce qu'il fait et ce qu'il est sense faire, ...
Tout ce que tu fais c'est te raccrocher a l'espoir que quelqu'un d'autre le fera, et le truc le plus fantastique est que cet "espoir" est absolument inutile. Quasiment aucun bug de securite n'est trouve par audit de code, quasiment tous sont trouves par fuzzing, y compris dans les logiciels open-source, car c'est une methode beaucoup plus efficace que revoir des millions de lignes de code. Et le fuzzing, ca ne depend pas de l'acces au code source.
[^] # Re: Et ne pas avoir à protéger ces informations ?
Posté par Etienne Bagnoud (site web personnel) . Évalué à 4.
D'avoir le code source me permet de réparer un dysfonctionnement quand je le détecte et ensuite j'aurais des risques en moins sur mon système. Personnellement je ne peux _pas_ tester un code pour trouver un problème futur, mais je peux réagir très vite quand je trouve un problème.
J'ai corrigé un bug dans un outil (web) qu'on utilisait pour accéder à notre annuaire LDAP. La session n'était pas détruite lorsque l'utilisateur se déconnectait, cela permettait à un méchant de faire du vol de session, mais si l'utilisateur se déconnectait correctement.
J'ai corrigé un bug sur OpenLDAP qui permettait, sans authentification aucune, de faire tomber le serveur LDAP !
Parce que j'ai rencontré ces problèmes et que j'ai eu les informations à disposition, j'ai pu les résoudre, envoyer ça en upstream et aujourd'hui certains logiciels sont un poil plus sécurisé.
Quand le firewall checkpoint plantait, à part envoyer un 32ème mail d'insulte que ça fait trois mois qu'on attend, je pouvais rien faire.
C'est certain, je n'ai pas les capacités techniques de faire de la sécurité pro-active, mais, travaillant tous les jours avec des logiciels serveurs, je rencontre des bugs que personnes n'a rencontré et des fois je peux les corriger, sinon je les signale juste.
La responsabilité finale, peu importe la solution open ou closed source, c'est sur moi. Donc si je choisis du closed source et qu'il y a un problème, je prends dans les dents autant qu'avec l'open source, par contre avec l'open source j'arrive à corriger les bugs avant que les utilisateurs s'en rende compte car je testes l'utilisation du logiciel dans "mes" conditions avant de le donner à l'utilisateur.
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: Et ne pas avoir à protéger ces informations ?
Posté par pasBill pasGates . Évalué à 2.
D'avoir le code source me permet de réparer un dysfonctionnement quand je le détecte et ensuite j'aurais des risques en moins sur mon système
Ca c'est la theorie. Ca marche quelque fois. Mais tu sais si ton correctif ne va pas casser quelque chose d'autre ? Tu as une batterie de tests pour le valider ? Tu sais si ton correctif ne va pas creer une faille ailleurs ? Non, verifier ces choses la demande d'avoir une connaissance approfondie du soft et de pouvoir le tester de maniere approfondie.
Parce que j'ai rencontré ces problèmes et que j'ai eu les informations à disposition, j'ai pu les résoudre, envoyer ça en upstream et aujourd'hui certains logiciels sont un poil plus sécurisé.
Quand le firewall checkpoint plantait, à part envoyer un 32ème mail d'insulte que ça fait trois mois qu'on attend, je pouvais rien faire.
Ca c'est un autre probleme, le fait que certains editeurs ne donnent pas de reponse est un probleme, mais un probleme different.
[^] # Re: Et ne pas avoir à protéger ces informations ?
Posté par Etienne Bagnoud (site web personnel) . Évalué à 3.
Ensuite la remontée du correctif plus haut permet aussi que les gens qui maîtrisent le logiciel mieux que moi l'intègre ou non.
Je ne te parle pas de faire un logiciel qui marche pour le monde entier, je n'administre pas le monde entier, mais pour moi. Si après d'autres ne veulent pas ma manière de faire, ils peuvent prendre autre chose, je suis pas triste.
Mais pour moi, le point essentiel, c'est des garanties sérieuses de la part des entreprises de logiciel. Qu'on me dise : "Voilà dans les conditions X, le logiciel fonctionne correctement. Voici la garantie du fonctionnement Y.". Si un problème arrive, pouvoir prouver que j'avais les conditions X et qu'on m'a garanti le fonctionnement Y, c'est pour moi le stricte nécessaire. Si Microsoft me fourni ces garanties là, je passes tout de suite sur du Microsoft. Mais un logiciel où je n'ai _aucun_ contrôle et qui commence par un texte disant que je l'utilise "à mes risques et périls", je vois, finalement, pas quel business j'ai à faire avec Microsoft.
En gros si on me vend du logiciel closed-source, j'attends des garanties. Sinon je vois pas vraiment ce qu'on me vend, vu que pour moins chère j'ai exactement la même chose (en terme de garanties et de fonctionnalités), mais où je peux plus facilement engager _ma_ responsabilité.
Parce qu'il faut pas rêver, mais au final la question de sécurité, c'est surtout "qui paie ?" dans une entreprise.
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: Et ne pas avoir à protéger ces informations ?
Posté par pasBill pasGates . Évalué à 1.
Ben ca on le fait plus ou moins hein : une faille reportee on la corrige, mais je pense pas que ca te contenterait, visiblement tu preferes avoir l'option de plonger dans le code, creer un patch toi-meme et le deployer le jour suivant.
Windows ne te contentera pas de ce point de vue, c'est clair et net.
[^] # Re: Et ne pas avoir à protéger ces informations ?
Posté par Etienne Bagnoud (site web personnel) . Évalué à 2.
Il faut pas rêver, le fric c'est le nerf de la guerre.
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: Et ne pas avoir à protéger ces informations ?
Posté par lasher . Évalué à 2.
[^] # Re: Et ne pas avoir à protéger ces informations ?
Posté par pasBill pasGates . Évalué à 2.
Autant il est possible d'assurer une tres tres haute qualite pour du code de petite taille dans les ordinateurs embarques sur avions et autre, autant c'est impossible a faire dans un soft de la complexite d'un browser web, alors imagine un OS.
[^] # Re: Et ne pas avoir à protéger ces informations ?
Posté par Etienne Bagnoud (site web personnel) . Évalué à 4.
C'est claire que les guerres à la "fonctionnalité qui tue", ça va pas aider à produire du logiciel de qualité et c'est bien plus rentable. Le jour où on oblige une garantie sur les logiciels aussi (parce qu'il y en a sur le matériel), et bien tu verras qu'il y aurait bien moins de technos inutiles (ou vaguement utile) et un poil plus de logiciel de qualité (et moins de réécriture complète de systèmes).
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: Et ne pas avoir à protéger ces informations ?
Posté par pasBill pasGates . Évalué à 1.
Mais ca n'a pas grand-chose a voir.
Tu prends un browser web basique qui ne supporte que HTTP et HTML 4 avec javascript, rien que ca c'est extremement complexe de garantir que ca fonctionnera correctement. Je te parles meme pas de rajouter des plugins, une UI skinnable, SSL, etc...
[^] # Re: Et ne pas avoir à protéger ces informations ?
Posté par Etienne Bagnoud (site web personnel) . Évalué à 3.
Mais on peut prendre un navigateur. Javascript, est-ce vraiment utile ? N'aurait pas eu meilleure temps de s'arranger que le support CSS et HTML soit de qualité et identique partout ?
Ça fait quoi bientôt vingt ans qu'on développe des navigateurs Web, la seule chose que tu es certain que ça fonctionne, c'est le HTTP.
C'est vrai c'est complexe à garantir, mais étrangement il y a des logiciels qui donnent des garanties. Pas sur tout, mais sur des points importants. Prends djbdns, il offre 1000$ à celui qui trouve une faille de sécurité. Ça c'est une garantie.
Alors on peut faire de le "threat modeling" qu'on veut, si à la fin y'a un bug et pis ... ben on le corrigera dans une mise à jour, je vois pas à quoi ça sert. Et je ne vois aucun argument qui me donne envie de faire confiance en cette manière de faire.
La sécurité commence là où les gens prennent leur responsabilité, sans responsabilité pas de sécurité.
Et finalement ces garanties existent et sont données. Au travail je dois donner des garanties de fonctionnement et tout et tout. Se faisant on devient un peu plus terre-à-terre et c'est exit toutes les solutions où tu as pas un contrôle totale dessus. L'option serait des garanties, mais c'est juste pas assez rentable pour Microsoft.
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: Et ne pas avoir à protéger ces informations ?
Posté par pasBill pasGates . Évalué à 1.
Mais meme du cote serveur, ca ne change rien. Prends rien que Kerberos, ce protocole est extremement complexe. On peut aussi parler des bugs qui se trouvent dans le protocole lui-meme, c'est qui le responsable la ? L'IETF ou l'editeur ? Parce que l'editeur il n'a fait que suivre le protocole.
C'est vrai c'est complexe à garantir, mais étrangement il y a des logiciels qui donnent des garanties. Pas sur tout, mais sur des points importants. Prends djbdns, il offre 1000$ à celui qui trouve une faille de sécurité. Ça c'est une garantie.
C'est pas une garantie ca, il dit pas qu'il va payer 1000$ a toute personne affectee par le bug, simplement a celui qui en trouve un, ca n'a absolument rien a voir. Un bug de securite chez MS, ca nous coute largement plus de 1000$ a trouver, ce genre de trucs est ridicule pour nous.
Et finalement ces garanties existent et sont données. Au travail je dois donner des garanties de fonctionnement et tout et tout. Se faisant on devient un peu plus terre-à-terre et c'est exit toutes les solutions où tu as pas un contrôle totale dessus. L'option serait des garanties, mais c'est juste pas assez rentable pour Microsoft.
Dans le monde du soft grand public(et ca inclut les serveurs), personne ne donne ce genre de garantie, *personne*.
C'est pas une histoire de rentabilite, c'est une histoire d'impossibilite technique.
[^] # Re: Et ne pas avoir à protéger ces informations ?
Posté par Etienne Bagnoud (site web personnel) . Évalué à 2.
La question que je me poses c'est qu'est-ce qui différencie un logiciel Libre d'un logiciel propriétaire ?
Bon ok, une entreprise comme Microsoft a en place certains processus qui, je penses, me seront expliqués si je le demande (dans la manière de gérer les problèmes, d'appréhender des attaques, ...), dans une distribution comme Debian, je retrouve ça. La grande différence c'est que Microsoft aura des certifications qui attestent que c'est bien le cas (mais pour avoir vécu le passage d'une entreprise en ISO, je suis de moins en moins convaincu, mais ça n'engage que moi) ou, pour rester dans le thème, le "threat modeling" sera appliqué avec, vu les moyens, les meilleures experts du domaine.
Au-delà de ça, il n'a rien de bien différent. Et apporter des garanties, même limitées, serait un élément qui changerait beaucoup de choses pour moi.
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: Et ne pas avoir à protéger ces informations ?
Posté par pasBill pasGates . Évalué à 2.
Mais garanties de quoi ?
Garantir que le soft n'a pas de bug, c'est impossible.
Garantir que le soft a ete teste de maniere X ou Y, ca peut se faire j'imagines, mais je vois mal ce que ca changerait par rapport a aujourd'hui, au final t'es dans le meme petrin et tu recois rien.
La grande différence c'est que Microsoft aura des certifications qui attestent que c'est bien le cas (mais pour avoir vécu le passage d'une entreprise en ISO, je suis de moins en moins convaincu, mais ça n'engage que moi) ou, pour rester dans le thème, le "threat modeling" sera appliqué avec, vu les moyens, les meilleures experts du domaine.
C'est deja le cas, il y a un document, ce qu'on appelle SDL chez nous, qui decrit le processus a suivre d'un point de vue securite dans le developpement de soft, il est publique et c'est ce qui est applique en interne, on le dit tres clairement. Quand aux meilleurs experts, c'est deja le cas depuis longtemps, Dan Kaminsky par exemple a passe une bonne partie de son temps chez nous lors du developpement de Vista et c'etait pas le seul, sans parler de nos teams internes qui regorgent de gars extremement competents.
Mais j'appelle pas ca une garantie.
[^] # Re: Et ne pas avoir à protéger ces informations ?
Posté par Etienne Bagnoud (site web personnel) . Évalué à 3.
- Garantie sur l'intégrité des données. Si, en cas d'utilisation normal, les données venaient à se corrompre, Microsoft assume la responsabilité.
- Garantie sur les corrections de bug. Si un bug apparaît, la garantie que la correction est effectuée dans un temps X
- Garantie sur les fonctionnalités. Si j'ai X fonctionnalités à l'achat, j'ai toujours X fonctionnalités après Y mises à jour.
- Garantie sur le choix matériel/logiciel. Si je prends le matériel Y (spécifié par Microsoft), j'ai une garantie de fonctionnement (donc je peux installer le système dessus depuis un CD/DVD officiel, ça va marcher (pas passer des heures sur le net à trouver une solution)).
- Garantie sur la sécurité. Les X attaques connues ont été testées en profondeur et si mon serveur meurt d'une de ces X attaques, Microsoft assume.
Et ce n'est rien d'exceptionnel là, puisque Microsoft fait déjà se travail mais ne fournis pas de garanties contractuelles sur ces sujets (ou en partie). Je n'ai jamais eu le cas d'un NTFS se corrompre en utilisation normal, faites le pas, garantissez maintenant.
Donc sans ce genre de choses, je ne vois aucun avantage d'une solution serveur Microsoft face à une solution serveur Debian, réellement. Aucune des solutions m'apportent des garanties.
Fais passer le mot au service marketing ;-)
PS: je cite Microsoft ici, mais c'est parce que je parle avec toi, mais c'est valable pour les autres aussi.
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: Et ne pas avoir à protéger ces informations ?
Posté par pasBill pasGates . Évalué à 3.
Impossible a garantir techniquement. Remarque deja aujourd'hui dans ce genre de cas on essaierait de creer un outil pour extraire les donnees car on est pas des peaux de vache, mais prendre une responsabilite dessus, alors que c'est un truc impossible a garantir techniquement, c'est une tout autre histoire.
Garantie sur les corrections de bug. Si un bug apparaît, la garantie que la correction est effectuée dans un temps X
Et si le bug requiert des changements massifs on fait quoi ? On sort le truc non teste et ont met tout le monde dans la merde ?
Garantie sur le choix matériel/logiciel. Si je prends le matériel Y (spécifié par Microsoft), j'ai une garantie de fonctionnement (donc je peux installer le système dessus depuis un CD/DVD officiel, ça va marcher (pas passer des heures sur le net à trouver une solution)).
MS ne controle pas le matos et les drivers, resultat il ne peut pas garantir cela, et meme si il le controlait, les bugs hardware ca existe et ca ne manque pas car c'est devenu extremement complexe, demande a NVidia et ATI...
Garantie sur la sécurité. Les X attaques connues ont été testées en profondeur et si mon serveur meurt d'une de ces X attaques, Microsoft assume.
T'entends quoi par "attaque connue" ? Si c'est une attaque precise sur un composant precis, possible. Si c'est un type d'attaque general, impossible.
Et ce n'est rien d'exceptionnel là, puisque Microsoft fait déjà se travail mais ne fournis pas de garanties contractuelles sur ces sujets (ou en partie). Je n'ai jamais eu le cas d'un NTFS se corrompre en utilisation normal, faites le pas, garantissez maintenant.
De nouveau, c'est pas possible techniquement de le garantire. La jouer sur les probabilities ? Si on se loupe et ne serait-ce que 1% des machines sont touchees, c'est un million de machines dont on parle...
C'est _TECHNIQUEMENT_ impossible, pas qu'on veuille pas ou que ca coute trop cher, c'est pas possible de garantir qu'un bug ne se produira pas dans un composant donne tout simplement.
[^] # Re: Et ne pas avoir à protéger ces informations ?
Posté par Etienne Bagnoud (site web personnel) . Évalué à 1.
Finalement c'est juste un truc pour se démarquer de la concurrence et actuellement la concurrence fourni les mêmes garanties (c'est à dire aucune) avec plus de contrôle sur ce qui se passe (donc plus de possibilités de fournir des garanties au big boss qui en veut).
Je choisis quoi selon toi (remarque j'ai déjà choisi) ?
Sérieux, dans ma liste de sélection d'une solution, les garanties c'est un truc qui me ferait retourner sur NT4 si j'en avais. Je cherches pas des fonctionnalités top-cool, je cherches un fonctionnement garanti. Comme l'industrie matériel en donne (pourtant c'est pas plus possible d'en donne).
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: Et ne pas avoir à protéger ces informations ?
Posté par Krunch (site web personnel) . Évalué à 1.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: Et ne pas avoir à protéger ces informations ?
Posté par Etienne Bagnoud (site web personnel) . Évalué à 1.
- http://www.schneier.com/crypto-gram-1004.html#7
Comme quoi ...
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: Et ne pas avoir à protéger ces informations ?
Posté par lasher . Évalué à 2.
[^] # Re: Et ne pas avoir à protéger ces informations ?
Posté par Guillaume Knispel . Évalué à 1.
Même chose pour les codes touchant pourtant directement à la sécurité en tant que sujet principal. AMHA écrire une bibliothèque SSL en C ou C++ est une vaste fumisterie.
[^] # Re: Et ne pas avoir à protéger ces informations ?
Posté par Guillaume Knispel . Évalué à 1.
[^] # Re: Et ne pas avoir à protéger ces informations ?
Posté par Krunch (site web personnel) . Évalué à 1.
Le fuzzing de base, non. Mais si on a les sources, on peut fuzzer encore plus efficacement (non pas qu'il y ait grand monde qui le fasse en pratique).
http://code.google.com/p/bunny-the-fuzzer/
http://research.microsoft.com/en-us/um/people/pg/public_psfi(...)
OK, strictement parlant ya sans doute pas besoin des sources pour ça, mais ça rend l'instrumentation quand même vachement plus pratique.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: Et ne pas avoir à protéger ces informations ?
Posté par pasBill pasGates . Évalué à 1.
Le 2eme lien que tu donnes, c'est un outil qui n'utilise absolument pas les sources, il travaille sur les binaires uniquement en analysant le comportement de l'application lorsque elle processe les donnees, et c'est de tres loin le fuzzer le plus efficace que je connaisse, d'ailleurs je ne le considere meme pas comme un fuzzer, car il est beaucoup, beaucoup, plus intelligent qu'un fuzzer normal.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.