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