Patching : Équilibrer les exigences techniques avec les considérations commerciales

Logiciel en tant que service

Patching a maintenant été encore compliqué avec le logiciel-comme-un-service (SaaS) modèle. Plutôt que d’acheter une licence pour utiliser ce logiciel purement et simplement, il est maintenant courant de payer un abonnement annuel pour l’utilisation continue de ce logiciel. Toutefois, si un patch a été publié pour un logiciel pour lequel une organisation n’a pas réussi à maintenir son abonnement, un fournisseur – selon le point de vue mercenaire qu’il ressent – est bien dans ses droits de retenir le patch jusqu’à ce que l’abonnement soit renouvelé.

Patcher un système, en particulier face au client, a toujours été un bras de fer entre les nécessités de l’informatique et l’entreprise qui veut être toujours disponible. La planification des mises à jour du système devient un cas de négociation interne minutieuse. C’est là que les évaluations des risques entrent en jeu, car celles-ci communiquent les dangers potentiels de retarder certaines mises à jour logicielles.

« Depuis que je suis impliqué dans l’informatique, il y a eu une tension entre les responsables de la sécurité qui veulent patcher et entretenir les systèmes, et le côté business qui veut que les systèmes sont opérationnels 24 heures sur 24, 7 jours sur 7 », explique Gillespie. « La vérité est, dans la plupart des cas, il ne sera jamais possible d’avoir une pleine capacité 24/7 dans chaque système. Les entreprises doivent mieux reconnaître, puis prendre en compte, les fenêtres des temps d’arrêt.

Dans les cas où un système doit toujours être en place, par exemple lorsqu’il fait partie d’une infrastructure essentielle, plusieurs systèmes peuvent être exécutés en parallèle. Ceux-ci peuvent également agir comme une mesure de redondance.

L’essai d’un patch, en particulier pour les systèmes de base, est crucial pour maintenir la continuité de l’entreprise. Les tests sont généralement effectués sur une réplique des systèmes d’une organisation dans un environnement bac à sable. Cela permet à l’équipe de développement d’effectuer une course sèche du processus de patchage et de tester soigneusement le système pour s’assurer qu’il reste stable.

« Vous n’aurez jamais votre système de test exactement comme votre système en direct. Il y aura toujours ces différences clés, car on est fermé et non connecté à l’extérieur », explique Lear. « Ce que vous pouvez faire est de mettre des systèmes factices sur la fin et dire « C’est censé être une connexion Internet », il est censé être en mesure de parler au serveur. Vous mettez un serveur factice au bout d’une chaîne ethernet et le configurez pour répondre comme on s’y attend dans le scénario du monde réel.

Naturellement, cela peut venir avec une dépense importante de temps et de ressources. Non seulement des ressources doivent être mises de côté pour couvrir les dépenses liées à l’exécution d’un tel test, mais le personnel ayant l’expérience appropriée doit également être disponible. Le défaut de le faire peut exposer une organisation à des risques importants, tels que des correctifs potentiellement à l’origine de défaillances du système.

Une partie des coûts associés au patching peut être atténuée par des outils tiers et l’automatisation.  Toutefois, il faut veiller à ce que le processus soit optimal et que les mauvaises habitudes ne soient pas prises en charge par inadvertance.

« Si vous achetez des logiciels tiers de gestion de patchs, pour automatiser ce que vous faites déjà, alors vous automatisez les déchets », explique Gillespie. « Si votre stratégie n’est pas saine, n’est pas bien pensée et n’est pas bien documentée, alors tout ce que vous faites est de dépenser de l’argent pour le rendre plus facile de faire la même erreur que vous faisiez avant. »

Il est peu probable que l’automatisation d’un processus de patchage existant sans examen et optimisation du processus entraîne le maximum d’efficacité que l’automatisation permet.

Un examen attentif du processus de correction existant, depuis l’annonce initiale jusqu’au patch téléchargé, permettra de s’assurer que le processus de patchage automatisé devient une utilisation efficace du temps et des ressources et qu’aucune étape redondante n’est reporté.

En outre, bien que les outils tiers soient utiles, ils ne doivent pas être totalement utilisés. Il existe un risque d’angles morts, si ces outils ne détectent pas des failles ou des vulnérabilités spécifiques.

« Beaucoup d’outils tiers, en particulier les outils de surveillance et les tests de niveau de gestion des correctifs, sont meilleurs parce qu’ils sont écrits spécifiquement pour faire ce travail », dit M. Lear. « Ils mettent en évidence non seulement où sont vos vulnérabilités, mais le plus souvent ils vous donneront un lien vers d’autres correctifs afin que vous puissiez instantanément saisir cela et se déplacer vers le patching du système à nouveau. »

Test

La mise à jour d’un système est toujours un risque, mais qui peut être considérablement atténué par un processus de test rigoureux. Toutefois, des erreurs peuvent encore se produire. Ceux-ci peuvent varier d’un système de retour à ses paramètres par défaut ou de perdre la connectivité réseau, à travers un système complètement défaillant.

« D’après notre expérience personnelle, c’est arrivé deux fois où nous avons vraiment dû faire un certain contrôle des dégâts. C’est toujours un risque, et toujours dans votre esprit, que cela ne fonctionne pas », se souvient Lear. « Ce n’est pas parce qu’il a travaillé sur le « système A » qu’il fonctionnera nécessairement sur le « système B ». C’est la même chose quand vous avez vos systèmes de défaillance à double redondance, vous avez rafistolé un côté de celui-ci, et cela fonctionne, puis vous avez patché le deuxième côté de celui-ci et il tombe pour une raison inexplicable.

C’est à ce moment que le temps consacré à documenter et à mettre à jour la continuité des activités et les plans de rétablissement après sinistre procure un retour sur investissement. Dans le cadre de l’examen annuel du plan de rétablissement après sinistre, la section des détails du système devrait être mise à jour, y compris non seulement ce dont les systèmes sont composés, mais aussi les versions. « Lorsque vous écrivez « C’est l’état actuel du système », il faudra toujours le mettre à jour parce qu’il n’est jamais le même qu’il y a douze mois », dit Lear.

Avec un catalogue approprié d’instantanés système, il peut s’agir d’un simple cas de retour du réseau à la dernière « bonne » configuration connue du système si et quand un problème se produit.

En raison des risques potentiels de menaces qui sont intégrées, mais non actives, dans un système, il peut avoir besoin d’être ramené par plusieurs itérations pour être sûr que le système est stable. « Le rollback n’est pas aussi simple que de le désinstaller vers la dernière configuration connue », explique Gillespie. « Si votre dernière bonne configuration connue est d’il ya trois ans, alors vous avez perdu trois ans de travail. »

Lorsque la gestion du cycle de vie est intégrée dans les pratiques commerciales de base d’une organisation, les équipes informatiques sont en mesure de s’assurer que le temps et les ressources appropriés sont disponibles pour maintenir les systèmes. Cela réduit les temps d’arrêt inattendus et réserve le budget de mise à niveau pour la mise à niveau de cinq ans.

« La gestion des correctifs n’est pas seulement un problème d’IT; c’est une question d’affaires qui doit être gérée dans le cadre d’un programme de communication d’entreprise et de changement d’entreprise », conclut Gillespie.