Mettre à jour ou ne pas mettre à jour?

Depuis que j'ai commencé à travailler là où je travaille maintenant, j'ai eu une lutte sans fin avec mon patron et mes collègues en ce qui concerne la mise à jour des systèmes.

Je suis bien sûr tout à fait d'accord pour que toute mise à jour (que ce soit un firmware, un système d'exploitation ou une application) ne soit pas appliquée négligemment dès sa sortie, mais je crois également fermement qu'il devrait y avoir au moins une raison quelconque si le fournisseur la publiait; et la raison la plus courante consiste généralement à corriger un bogue ... que vous ne rencontrez peut-être pas maintenant, mais que vous pourriez rencontrer bientôt si vous ne suivez pas.

Cela est particulièrement vrai pour les correctifs de sécurité; à titre d'exemple, si quelqu'un avait simplement appliqué un patch qui était déjà disponible depuis des mois , le SQL Slammerver infâme aurait été inoffensif.

Je suis tout pour tester et évaluer les mises à jour avant de les déployer; mais je suis fortement en désaccord avec l'approche "si ce n'est pas le cas, ne le touchez pas" à la gestion des systèmes, et cela me fait vraiment mal quand je trouve des systèmes de production Windows 2003 SP1 ou ESX 3.5 Update 2, et la seule réponse que je peux obtenir est "ça marche, on ne veut pas le casser".

Que penses-tu de cela?
Quelle est votre politique?
Et quelle est la politique de votre entreprise si elle ne correspond pas à la vôtre?

Qu'en est-il des mises à jour du firmware (BIOS, stockage, etc.)?
Qu'en est-il des principales mises à jour du système d'exploitation (service packs)?
Qu'en est-il des mises à jour mineures du système d'exploitation?
Qu'en est-il des mises à jour d'application?

Mon intérêt principal est bien sûr la mise à jour des serveurs, car la gestion des correctifs client est généralement plus simple et il existe des outils bien connus et les meilleures pratiques pour le gérer.

La sécurité et l'agilité doivent être mises en balance avec la stabilité et la disponibilité lors de la détermination de votre stratégie de correction. Votre approche de refoulement pour cela devrait être du type `` D'accord, mais vous devez savoir que nous courons maintenant le risque que ces serveurs soient compromis et que nos données soient volées ou que les serveurs soient rendus non fonctionnels '' et «D'accord, mais vous devez savoir que cela a un impact sur la prise en charge par nos fournisseurs de ce système et sur la capacité future de ce système à interagir avec de nouveaux systèmes».

Contre la mentalité à long terme «pas de rupture, ne pas mettre à jour», vous devez préciser que:

• La migration d'un système hérité non corrigé qui a pris du retard sur un système moderne est un processus beaucoup plus coûteux et douloureux que la mise à jour progressive de ce système au fil du temps.
• Le personnel informatique expérimenté et qualifié recherche activement de nouvelles technologies et des entreprises qui font constamment évoluer leurs systèmes informatiques. Il y a un coût très réel en termes de chiffre d'affaires, de perte d'opportunité et de perte de connaissances lorsqu'une entreprise perd son personnel informatique très engagé et créatif en raison de la stagnation de ses systèmes et de son manque d'appétit. Il ne vous reste alors que les «condamnés à perpétuité».

J'espère que cela vous donnera un certain effet de levier et bonne chance pour convaincre les personnes ci-dessus de prendre les choses au sérieux. Comme toujours, établissez une trace papier qui prouve que vous avez bien compris la gestion des risques qu'ils prennent.

C'est un débat sans fin et les gens raisonnables seront en désaccord. Si vous parlez de PC utilisateur, je suis d'accord qu'ils doivent être mis à jour. Si vous parlez de serveurs, envisagez une politique distincte pour les serveurs qui font face à Internet et ceux qui ne le font pas. Je ne connais pas vos serveurs mais dans mon environnement, peut-être 10% de nos serveurs ont des ports ouverts sur Internet. Ces serveurs accessibles sur Internet bénéficient de la plus haute priorité en matière de correctifs de sécurité. Les serveurs qui ne sont pas confrontés à Internet sont moins prioritaires.

Les gourous de la sécurité feront valoir que cette approche est problématique car si un pirate informatique s'introduit dans votre réseau, les serveurs non corrigés permettront aux exploits de gaspiller le réseau comme une traînée de poudre et c'est un argument raisonnable. Pourtant, si vous gardez ces serveurs Internet bien verrouillés et configurez correctement votre pare-feu pour n'ouvrir que les ports qui sont absolument nécessaires, je pense que cette approche fonctionne et peut souvent être utilisée pour apaiser les gestionnaires qui ont peur des correctifs.

Si vous ne comptez que sur Windows Update pour les correctifs (vous n'avez pas mentionné le système d'exploitation que vous utilisez, mais je suis surtout un gars Windows, c'est ma référence), jetez un œil aux correctifs qui sont publiés chaque mois. . J'ai certains serveurs que si j'exécute Windows Update sur eux, on me dira que j'ai besoin de plus de 50 correctifs, mais si je fais défiler ces correctifs et recherche chacun d'eux, je constaterai que 90% des éléments constituant des correctifs ne sont pas de sécurité liés mais corrigent des bogues qui affectent les services que je n'exécute pas sur cette boîte. Dans les environnements plus vastes où vous utilisez un système de gestion des correctifs, il est courant de revoir tout ce qui est publié et de ne se soucier que de ce qui est absolument nécessaire et qui représente généralement environ 10% de ce que Microsoft publie.

Mon argument est que ce débat sur "patcher ou ne pas patcher" suggère que vous devez être d'un côté ou de l'autre quand, vraiment, c'est une immense zone grise.

Je ne peux que parler de serveurs mais nous avons un régime de «mise à jour trimestrielle», à quatre dates prédéterminées et annoncées par an, nous regroupons les demandes de mise à jour, les appliquons à notre environnement de référence, les exécutons pendant un mois pour tester la stabilité et si bon déploiement pendant les n jours / semaines suivants. En plus de cela, nous appliquons une politique de mise à jour d'urgence où nous avons la possibilité de déployer en référence, de tester et de déployer des mises à jour urgentes dans un jour ou deux si la gravité est telle - bien que cela n'ait été utilisé que 2/3 fois au cours de la dernière 4 ans ou plus.

Cette double approche garantit que nos serveurs sont raisonnablement, mais pas bêtement, à jour, que les mises à jour sont pilotées par des experts en la matière (c.-à-d. Firmware, pilotes, OS, personnel d'application) et non par des fournisseurs, mais qu'elle permet également des corrections rapides si obligatoire. Oh, bien sûr, nous sommes chanceux d'avoir très peu de modèles matériels différents dans toute l'entreprise (<10 variantes de serveur) et des plates-formes de référence importantes et à jour pour tester.

J'ai travaillé dans différentes entreprises qui avaient des politiques dans tout le continuum de "appliquer les correctifs dès que possible, nous ne nous soucions pas s'ils cassent quelque chose que nous avons travaillé - nous les soutiendrons alors" à "rien n'est appliqué sans deux semaines des tests. " Les deux extrêmes (et les points intermédiaires) sont corrects tant que la société comprend les compromis .

C'est le point important: il n'y a pas de bonne ou de mauvaise réponse particulière à cette question; il s'agit d'équilibrer la stabilité par rapport à la sécurité ou aux fonctionnalités de votre environnement particulier . Si votre chaîne de gestion comprend que le report des correctifs pour les tests peut les rendre plus vulnérables aux logiciels malveillants, c'est très bien. De même, s'ils comprennent qu'appliquer des correctifs dès qu'ils sont disponibles peut ne pas fonctionner ou même casser votre configuration système particulière, c'est aussi bien. Des problèmes existent lorsque ces compromis ne sont pas compris.

À mon avis, le meilleur cours est à peu près au milieu de vos deux extrêmes. Par exemple, pourquoi voulez-vous si désespérément mettre à niveau ESX s'il n'y a aucune raison démontrable de le faire, ce qui pourrait éventuellement casser des systèmes en cours de fonctionnement? Bien sûr, il pourrait être vulnérable s'il était accessible au public, mais il ne devrait y avoir aucun moyen d'y accéder directement depuis l'extérieur de votre réseau, alors où est le risque? Y a-t-il des bogues ou un manque de fonctionnalités qui vous présentent une raison de mettre à niveau?

La mise à niveau pour le plaisir, qui est vraiment ce que vous proposez ("mais vous pourriez vivre bientôt"), même si vous prétendez que vous ne l'êtes pas, est une route absurde et dangereuse pour voyager. À moins que vous ne puissiez présenter une raison réelle , par opposition à une raison théoriquement possible, vous n'allez jamais convaincre les autres s'ils sont opposés à la mise à niveau.

Si vous pensez qu'il existe une raison réelle d'effectuer une mise à niveau, vous devez documenter les avantages et les inconvénients, et il y en a toujours, et les présenter à ceux qui se trouvent plus haut dans l'arborescence. Bien documenté, il devrait y avoir peu de résistance. Si vous ne pouvez pas fournir un argument convaincant, alors asseyez-vous et réfléchissez sérieusement à ce fait.

Éditer

J'ai pensé que je devrais préciser que je vois une grande différence entre l'application des correctifs de sécurité et de stabilité requis par rapport à la mise à niveau de logiciels ou de systèmes d'exploitation. Le premier que j'implémente après des tests appropriés. Ce dernier je ne fais que s'il y a un réel avantage.

Les mises à jour de sécurité sont envoyées à un serveur intermédiaire, puis en production après avoir montré qu'elles ne font pas exploser les choses. Sauf s'il y a une véritable urgence sonore (que j'ai frappée plusieurs fois :(), auquel cas PRODUCTION MAINTENANT. Autres mises à jour uniquement au besoin, après avoir passé du temps en mise en scène.

Je pense que la première chose à faire est de "classer" les mises à jour par gravité et d'avoir un calendrier de correctifs basé sur la classification. Il ne fait aucun doute que les correctifs de sécurité zero-day doivent être appliqués immédiatement; tandis que le Service Pack peut attendre après des évaluations minutieuses.