Ç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.
...
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.
[^] # Re: Pratiques d'une ère (dé)passée
Posté par pasBill pasGates . En réponse à la dépêche Threat modeling - Savez vous quelles sont les menaces qui guettent votre application ?. É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