Sauf que pendant ce temps là, t'es à pwal.
Honnêtement, c'est un choix.
Pour les systèmes les plus exposés, la priorité doit aller à la sécurité au détriment, le cas échéant, de la disponibilité (puisque de toutes façons, une fois compromis la disponibilité n'est plus assurée non plus, et c'est toujours plus compliqué pour s'en débarrasser). Donc la pratique saine est de déployer le correctif de sécurité, en parallèle des tests pour sa validation qui fournira peut-être un deuxième patch dans la foulée, de fonctionnalités cette fois là. Ou alors c'est un choix assumé de laisser une faille ouverte sur un système exposé. On ne peut pas tout avoir !
En pratique, ça veut aussi dire que quand si le système est très exposé et critique, il faut faire des tests élaborés supplémentaires avant de déployer pour réduire encore plus la probabilité de découverte de failles (OpenBSD n'a connu que 2 exploits distants en 10 ans, c'est donc possible !), et ajouter de la variabilité dans le code déployé pour limiter la portée d'un exploit développé en vitesse.
Au final, déployer des programmes (削除) bourrés de failles (削除ここまで) peu testés d'un point de vue sécurité sur des systèmes très exposés et critiques est un choix qui coûte moins cher au déploiement, mais qui a des conséquences.
[^] # Re: Noyau
Posté par khivapia . En réponse au journal Sécurité de l'open source Vs closed source: MS14-066. Évalué à 6. Dernière modification le 18 novembre 2014 à 11:04.
Sauf que pendant ce temps là, t'es à pwal.
Honnêtement, c'est un choix.
Pour les systèmes les plus exposés, la priorité doit aller à la sécurité au détriment, le cas échéant, de la disponibilité (puisque de toutes façons, une fois compromis la disponibilité n'est plus assurée non plus, et c'est toujours plus compliqué pour s'en débarrasser). Donc la pratique saine est de déployer le correctif de sécurité, en parallèle des tests pour sa validation qui fournira peut-être un deuxième patch dans la foulée, de fonctionnalités cette fois là. Ou alors c'est un choix assumé de laisser une faille ouverte sur un système exposé. On ne peut pas tout avoir !
En pratique, ça veut aussi dire que quand si le système est très exposé et critique, il faut faire des tests élaborés supplémentaires avant de déployer pour réduire encore plus la probabilité de découverte de failles (OpenBSD n'a connu que 2 exploits distants en 10 ans, c'est donc possible !), et ajouter de la variabilité dans le code déployé pour limiter la portée d'un exploit développé en vitesse.
Au final, déployer des programmes
(削除) bourrés de failles (削除ここまで)peu testés d'un point de vue sécurité sur des systèmes très exposés et critiques est un choix qui coûte moins cher au déploiement, mais qui a des conséquences.