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 Etienne Bagnoud . En réponse à la dépêche Threat modeling - Savez vous quelles sont les menaces qui guettent votre application ?. É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