Dans cet article rédigé par un fournisseur d’une solution de surveillance de la sécurité, l’argument principal (souvent repris dans d’autres publications et divers salons professionnels) était que le correctif des systèmes OT est difficile. L’auteur soutient que, comme c’est difficile, nous devrions nous tourner vers d’autres méthodes pour améliorer la sécurité. Sa théorie consiste à activer une technologie d’alerte comme la sienne et à associer les alarmes en attente à une équipe de réponse aux incidents de sécurité. En d’autres termes, il est difficile d’accepter les correctifs, d’abandonner et de consacrer plus d’argent à l’apprentissage plus tôt (peut-être?) et répondant plus vigoureusement.
Cependant, cette conclusion (le correctif est difficile, alors ne vous embêtez pas) est défectueuse pour plusieurs raisons. Sans oublier qu’il passe sous silence un facteur très important qui complique considérablement toute réponse ou remédiation à envisager.
La première raison pour laquelle ce conseil est dangereux est que vous ne pouvez tout simplement pas ignorer les correctifs. Vous devez faire ce que vous pouvez, quand vous le pouvez, et lorsque le correctif n’est pas une option, vous passez au plan B, C et D. Ne rien faire signifie que tous les incidents liés à la cyberincidence qui se frayent un chemin dans votre environnement produiront un maximum de dommages. Cela ressemble beaucoup à la défense M & M d’il y a 20 ans. C’est l’idée que votre solution de sécurité doit être dure et croquante à l’extérieur, mais douce et moelleuse à l’intérieur.
La deuxième raison pour laquelle ce conseil est défectueux est l’hypothèse que le personnel de sécurité OT (pour la réponse aux incidents ou les correctifs) est facile à trouver et à déployer! Ce n’est pas vrai – en fait, l’un des incidents de sécurité ICS référencés dans l’article souligne que même si un correctif était disponible et prêt à être installé, aucun expert ICS n’était disponible pour superviser l’installation du correctif ! Si nous ne pouvons pas libérer nos experts en sécurité pour déployer une protection pré-événement connue dans le cadre d’un programme de gestion proactive des correctifs, pourquoi pensons-nous pouvoir trouver le budget pour une équipe complète de réponse aux incidents après coup lorsqu’il est trop tard ?
Enfin, la pièce manquante de cet argument est que les défis de la gestion des correctifs OT / ICS sont encore exacerbés par la quantité et la complexité des actifs et de l’architecture dans un réseau OT. Pour être clair, lorsqu’un nouveau correctif ou une vulnérabilité est publié, la capacité de la plupart des organisations à comprendre combien d’actifs sont dans la portée et où ils se trouvent est un défi. Mais toute équipe d’intervention en cas d’incident aura besoin de ce même niveau de connaissances et de profils d’actifs pour être efficace. Même son conseil d’ignorer la pratique du patching ne peut pas vous éviter d’avoir à construire un inventaire robuste et contextuel (la base du patching!) comme fondement de votre programme de cybersécurité OT.
Alors, que devons-nous faire? Tout d’abord, nous devons essayer de corriger. Il y a trois choses qu’un programme de gestion des correctifs ICS mature doit inclure pour réussir:
- Inventaire contextuel en temps réel
- Automatisation de la correction (fichiers de correctifs et protections ad hoc)
- Identification et application de contrôles de compensation
Inventaire contextuel en temps réel pour la gestion des correctifs
La plupart des environnements OT utilisent des outils de correctifs basés sur l’analyse tels que WSUS/SCCM qui sont assez standard mais pas trop perspicace pour nous montrer quels actifs nous avons et comment ils sont configurés. Ce qui est vraiment nécessaire, ce sont des profils d’actifs robustes avec leur contexte opérationnel inclus. Qu’est-ce que je veux dire par là? IP de l’actif, modèle, système d’exploitation, etc. est une liste très sommaire de ce qui pourrait être dans la portée du dernier correctif. Ce qui est plus précieux, c’est le contexte opérationnel tel que la criticité des actifs pour des opérations sûres, l’emplacement des actifs, le propriétaire des actifs, etc. afin de contextualiser correctement notre risque émergent car tous les actifs OT ne sont pas créés égaux. Alors pourquoi ne pas d’abord protéger les systèmes critiques ou identifier les systèmes d’essai appropriés (qui reflètent les systèmes de terrain critiques) et réduire stratégiquement les risques?
Et pendant que nous construisons ces profils d’actifs, nous devons inclure autant d’informations que possible sur les actifs au-delà de l’adresse IP, de l’adresse Mac et de la version du système d’exploitation. Informations telles que les logiciels installés, les utilisateurs / comptes, les ports, les services, les paramètres de registre, les contrôles de privilèges minimaux, l’AUDIOVISUEL, la liste blanche et l’état de la sauvegarde, etc. Ces types de sources d’information augmentent considérablement notre capacité à établir des priorités et des stratégies précises lorsque de nouveaux risques apparaissent. Vous voulez une preuve? Jetez un coup d’œil au flux d’analyse habituel proposé ci-dessous. Où obtiendrez-vous les données pour répondre aux questions aux différentes étapes? Connaissance tribale ? Instinct ? Pourquoi pas des données ?
Automatiser la correction des correctifs logiciels
Un autre défi en matière de correctifs logiciels est le déploiement et la préparation du déploiement des correctifs (ou des contrôles de compensation) sur les points de terminaison. L’une des tâches les plus chronophages de la gestion des correctifs OT est le travail de préparation. Cela comprend généralement l’identification des systèmes cibles, la configuration du déploiement du correctif, le dépannage lorsqu’ils échouent ou l’analyse en premier, la poussée du correctif et la re-analyse pour déterminer le succès.
Mais que se passe-t-il si, par exemple, la prochaine fois qu’un risque comme BlueKeep apparaissait, vous pouviez précharger vos fichiers sur les systèmes cibles pour vous préparer aux prochaines étapes? Vous et votre équipe de sécurité OT plus petite et plus agile pouvez planifier de manière stratégique les systèmes industriels sur lesquels vous avez déployé des mises à jour de correctifs en premier, deuxième et troisième en fonction d’un certain nombre de facteurs dans vos profils d’actifs robustes, tels que l’emplacement ou la criticité des actifs.
Pour aller plus loin, imaginez si la technologie de gestion des correctifs ne nécessitait pas d’analyse au préalable, mais avait déjà cartographié le correctif sur des actifs dans la portée et que vous les installiez (à distance pour les risques faibles ou en personne pour les risques élevés), ces tâches vérifiaient leur succès et reflétaient ces progrès dans votre tableau de bord mondial ?
Pour tous vos actifs à haut risque que vous ne pouvez pas ou ne voulez pas corriger pour le moment, vous pouvez plutôt créer un port, un service ou un changement d’utilisateur / de compte en tant que contrôle compensateur ad hoc. Ainsi, pour une vulnérabilité telle que BlueKeep, vous pouvez désactiver le bureau distant ou le compte invité. Cette approche réduit immédiatement et de manière significative le risque actuel et laisse également plus de temps pour se préparer à l’éventuel patch. Cela m’amène aux actions de « repli » de ce qu’il faut faire lorsque le correctif n’est pas une option – les contrôles compensateurs.
Que sont les contrôles compensateurs?
Les contrôles de compensation sont simplement des actions et des paramètres de sécurité que vous pouvez et devez déployer au lieu de (ou plutôt aussi bien que) des correctifs. Ils sont généralement déployés de manière proactive (si possible), mais peuvent être déployés lors d’un événement ou en tant que mesures de protection temporaires telles que la désactivation du bureau à distance pendant que vous effectuez un correctif pour BlueKeep, ce que je développe dans l’étude de cas à la fin de ce blog.
Identifier et appliquer des contrôles de compensation dans OT security
Les contrôles de compensation prennent de nombreuses formes, notamment la liste blanche des applications et la mise à jour des antivirus. Mais dans ce cas, je veux me concentrer sur la gestion des points de terminaison ICS en tant que composant de support clé de la gestion des correctifs OT.
Les contrôles de compensation peuvent et doivent être utilisés à la fois de manière proactive et en situation. Il ne serait pas surprenant pour quiconque dans le domaine de la cybersécurité de découvrir des comptes d’administrateur dormants et des logiciels inutiles ou inutilisés installés sur les points de terminaison. Ce n’est pas un secret non plus que les principes de renforcement des systèmes de bonnes pratiques ne sont pas aussi universels que nous le souhaiterions.
Pour vraiment protéger nos systèmes OT, nous devons également durcir nos biens précieux. Un profil d’actifs robuste et en temps réel permet aux organisations industrielles d’éliminer avec précision et efficacité les fruits peu accrochés (c’est-à-dire les utilisateurs dormants, les logiciels inutiles et les paramètres de durcissement du système) afin de réduire considérablement la surface d’attaque.
Dans le cas malheureux, nous avons une menace émergente (comme BlueKeep) l’ajout de contrôles compensatoires temporaires est faisable. Une étude de cas rapide pour mettre en évidence mon point:
- La vulnérabilité BlueKeep est publiée.
- L’équipe centrale désactive immédiatement le bureau à distance sur toutes les ressources de terrain et les e-mails équipe de terrain nécessitant des demandes spécifiques système par système pour que le service bureau à distance soit activé pendant la période à risque.
- L’équipe centrale pré-charge les fichiers de correctifs sur tous les actifs dans la portée – aucune action, il suffit de les préparer.
- L’équipe centrale se réunit pour décider du plan d’action le plus raisonnable en fonction de la criticité des actifs, de l’emplacement, de la présence ou de l’absence de contrôles compensateurs (c’est-à-dire qu’un risque critique sur un actif à impact élevé qui n’a pas réussi sa dernière sauvegarde figure en tête de liste. Un actif à faible impact avec une liste blanche en vigueur et une bonne sauvegarde complète récente peut probablement attendre).
- Le déploiement des correctifs commence et les progrès sont mis à jour en direct dans les rapports globaux.
- Si nécessaire, des techniciens OT sont sur la console pour superviser le déploiement du correctif.
- Le calendrier et la communication de ce besoin sont entièrement planifiés et priorisés par les données utilisées par l’équipe centrale.
Voici comment la gestion des correctifs OT doit être gérée. Et de plus en plus d’organisations commencent à mettre en place ce type de programme.
Soyez proactif avec des contrôles de compensation
La gestion des correctifs ICS est difficile, oui, mais renoncer simplement à essayer n’est pas non plus une bonne réponse. Avec un peu de prévoyance, il est facile de fournir les trois outils les plus puissants pour des contrôles de correction et / ou de compensation plus faciles et plus efficaces. Insight vous montre ce que vous avez, comment il est configuré et à quel point il est important pour vous. Le contexte vous permet de hiérarchiser (la première tentative de correction vous permet de savoir comment et où appliquer les contrôles de compensation). L’action vous permet de corriger, protéger, dévier, etc. Ne compter que sur la surveillance, c’est admettre que vous vous attendez à un incendie et acheter plus de détecteurs de fumée pourrait minimiser les dommages. Selon vous, quelle approche préférerait votre organisation?