Protection des réseaux ICS et SCADA avec Pan-OS 8,0

Protection des réseaux ICS et SCADA avec Pan-OS 8,0

32610
Created On 09/26/18 19:10 PM - Last Modified 06/01/23 03:06 AM


Resolution


Ce document examinera trois cas d'utilisation liés à l'utilisation du pare-feu de la prochaine génération de Palo Alto Networks dans un environnement de système de contrôle industriel (ICS). L'objectif principal des trois cas d'utilisation consiste à fournir des mesures de sécurité supplémentaires pour protéger le réseau ICS. Il est également important que ces mesures permettent l'automatisation dans la mesure du possible pour réduire les coûts opérationnels et la fatigue de la réponse aux incidents.

 

Les trois cas d'utilisation:

  • Introduire l'authentification multi-facteurs (2FA) pour l'accès aux réseaux et applications de la technologie opérationnelle (OT)
  • Paramètres de quarantaine automatique lors d'une défaillance d'authentification et d'événements de sécurité critiques
  • Fournir des conduits cryptés des emplacements ICS à divers datacenters et maillage dynamique de ces tunnels

Exigences en matière

Élément requis

Notes

Panos 8

8.0.5 au moment du présent document

Authentification à facteurs multiples

Okta dans cet exemple

Système de billetterie

ServiceNow dans cet exemple

GlobalProtect Cloud service

 

 

Diagramme de haut niveau décrivant la limite d'IT/OT où les cas d'utilisation de la sécurité multifactorielle seraient appliqués:

Picture1.png

 

Diagramme de flux pour les cas d'utilisation multi-facteurs

Le flux général est représenté dans le tableau ci-dessous. Dans cet exemple, une attention administrative est requise afin de supprimer un point de terminaison du groupe de quarantaine. Cependant, il est possible dans Panos version 8. x de supprimer dynamiquement, ainsi que d'ajouter une balise au trafic source incriminé. Cela permettrait potentiellement une automatisation complète dans le déplacement des points de terminaison entre la quarantaine et d'autres groupes d'adresses dynamiques.

 

Picture2.png

 

Configuration pour cas d'utilisation multi-facteurs

Traditionnellement, l'authentification à plusieurs facteurs exigeait que l'application soit capable de fournir une interaction 2FA. Cependant, il existe de nombreuses applications qui n'ont tout simplement pas cette fonctionnalité (en particulier les applications héritées dans l'environnement OT). Il est maintenant possible d'appliquer l'authentification multi-facteurs pour ces applications et toutes les autres en lançant le processus au niveau du réseau. Plus précisément, la version 8 de Panos fournit cette capacité et ne dépend pas de l'application étant 2FA consciente. Il est maintenant possible de lancer le processus AMF lorsque des critères spécifiques sont satisfaits au sein du RuleSet (c'est-à-dire lorsque les utilisateurs du réseau informatique tentent d'atteindre les applications sur le réseau OT). Si l'un des processus d'authentification échoue, l'accès est refusé.

 

Le premier cas d'utilisation est d'introduire l'authentification multi-facteurs lorsque les utilisateurs tentent d'accéder aux applications qui résident dans le réseau OT. Les utilisateurs sont invités à entrer leurs informations d'identification sur un formulaire Web (première authentification), suivi par Confrmation (deuxième authentification) pour s'assurer que le propriétaire d'informations d'identification a effectivement initié le processus.

La première passe est à travers un portail captif login:

 

Picture3.png

La deuxième passe est validée hors-bande:

 

Picture4.png

 

Ajoutez le profil de serveur multi-facteurs sous profils de périphériques/serveurs/authentification multi-facteurs. Actuellement, il existe quatre modèles intégrés pour l'AMF providors (Okta Adaptive, PingID et duo v2). Voir capture d'écran par exemple. Pour une configuration d'authentification multi-facteurs détaillée, consultez le guide Panos 8,0 Administrators: https://www.paloaltonetworks.com/documentation/80/Pan-OS/Pan-OS/Authentication/configure-Multi-Factor-Authentication

 

Picture5.png

 

Activer des facteurs d'authentification supplémentaires dans un profil d'authentification (sélectionnez le profil de serveur AMF qui vient d'être créé): profil de périphérique/d'authentification:

 

Picture6.png

 

Créez un objet d'application d'authentification et sélectionnez le profil d'authentification qui vient d'être créé. Ceci est sous objets/authentification. Créer un message personnalisé les utilisateurs verront lorsqu'ils seront invités à obtenir le premier niveau d'authentification via le portail captif.

 

Picture7.png

 

Configurez une règle d'authentification pour déclencher le processus d'authentification multi-facteurs. Dans cet exemple, nous souhaitons lancer le processus multi-facteurs lorsque le trafic initié par le réseau informatique est destiné au réseau OT. Cela pourrait être affinée en ajoutant des groupes d'annonces ou des utilisateurs spécifiques.

 

Stratégies/authentification

 

Picture8.png

 

Créez une règle de stratégie de sécurité qui permet aux utilisateurs d'accéder aux services et aux applications nécessitant une authentification. Cette amélioration pourrait être affinée en ajoutant des groupes d'annonces ou des utilisateurs et des applications spécifiques (c.-à-d. Modbus, DNP3, Cygnet-SCADA, etc.).

 

Politiques/sécurité

 

Picture9.png

 

Ajout de l'Automation – groupes d'adresses dynamiques

Après avoir introduit l'authentification multi-facteurs, l'étape suivante consiste à prendre des mesures sur une tentative d'authentification défaillante ou un événement de sécurité critique. Pour ce faire, il existe deux fonctionnalités à déployer: les groupes d'adresses dynamiques et les profils de transfert de journal.

 

Les groupes d'adresses dynamiques (DAG) permettent des stratégies flexibles qui s'adaptent aux changements. Par exemple, un hôte peut commencer par une balise qui la place dans un groupe d'adresses qui correspond à une règle Allow mais dont la balise a été modifiée de façon dynamique (et par la suite, en la déplaçant vers un autre groupe d'adresses) afin qu'elle corresponde à une règle de refus. Cela élimine la nécessité d'ajouter/supprimer continuellement des règles de la stratégie de sécurité. Consultez le Guide de l'administrateur Panos 8 pour des informations détaillées sur les groupes d'adresses dynamiques:

https://www.paloaltonetworks.com/documentation/80/Pan-OS/Pan-OS/Policy/Use-Dynamic-Address-Groups-in-Policy

 

Pour créer un groupe d'adresses dynamique, accédez à objets/groupes d'adresses. Ce groupe sera vide car il correspondra en fonction d'une balise de quarantaine pour laquelle aucun trafic ne sera étiqueté initialement.

 

Picture10.png

 

Ensuite, créez les paramètres requis à surveiller dans les journaux. Pour chaque, créez une action intégrée qui marque dynamiquement la source avec une balise de quarantaine.

 

Accédez à objets/transfert de journal et créez une nouvelle entrée.

 

Picture11. pngPicture12. pngPicture13. pngPicture14. png

 

Ajout de l'automatisation – profils de transfert de journal

Pour chaque tentative d'AMF défaillante, définissez l'action intégrée pour le balisage dynamique.

 

Picture15. png

 

Maintenant, ajoutez l'automatisation de la génération du ticket de service. Dans la méthode Forward, ajoutez vos informations de serveur http prédéfinies pour ServiceNow. Le serveur http prédéfini serait entré dans les profils Device/Server/http.

 

Définissez le profil de serveur http pour ServiceNow.

 

Picture16. png

 

Cliquez sur l'onglet format de la charge utile pour utiliser le format de journalisation intégré pour ServiceNow.

 

Cliquez sur authentification et sélectionnez ServiceNow Security incident dans la liste déroulante. Les informations d'échec d'authentification pertinentes seront envoyées à ServiceNow dans un format facilement consommable par l'API http ServiceNow.

 

Picture17. png

 

Retournez à objets/transfert de journal pour ajouter l'Automation au profil pour les tentatives d'AMF échouées et ajoutez le serveur http créé pour ServiceNow.

 

Picture18a. jpg

 

Lorsque vous avez terminé avec le premier cas d'utilisation (échecs AMF), ajoutez le deuxième cas d'utilisation (hôtes de quarantaine OT avec des événements de sécurité critiques).

 

Picture19. pngPicture20. pngPicture21. png

 

Ajoutez le profil de serveur http pour ServiceNow.

 

Picture22. png

 

Le profil final de transfert de journal se ressemblera à ceci:

 

Picture23. pngPicture24. png

 

Ajoutez le profil de transfert de journal nouvellement créé à la règle de sécurité qui permet le trafic it-to-OT.

 

Picture25. pngPicture26. png

 

Les cas d'utilisation énumérés ici nécessitent une intervention manuelle pour déplacer les hôtes isolés de la quarantaine vers la production. Pour d'autres zones moins sensibles du réseau, cela pourrait être dynamique car les actions intégrées dans le transfert de journal peuvent également supprimer des balises (c'est-à-dire supprimer une balise de quarantaine). Pour afficher les adresses IP source qui ont été placées dans le DAG de quarantaine, accédez à stratégies, recherchez la règle qui contient le DAG et survolez le DAG pour voir une liste déroulante. Sélectionnez le menu déroulant, la valeur et plus pour voir la liste et de prendre des mesures sur les sources individuelles.

 

Picture27. png

 

Reportez-vous à la page suivante pour le nombre maximal d'adresses IP enregistrées dynamiquement disponibles par plaform: https://www.paloaltonetworks.com/documentation/80/Pan-OS/Pan-OS/Policy/Use-Dynamic-Address-Groups-in-Policy

 

Maillage dynamique des tunnels IPSec

Lorsqu'il existe de nombreux sites ICS/SCADA à distance nécessitant une connectivité IPSec à plusieurs centres de données (MPLS ou Internet), il peut être lourd sur le plan administratif de les configurer et de les maintenir. Cela est particulièrement vrai lorsque les sites entièrement maillés sont une exigence. Plutôt que d'implémenter un autre appareil devant le pare-feu pour gérer le routage et les tunnels dynamiques, il existe une solution élégante utilisant les pare-feu de réseaux Palo Alto existants ou les périphériques Edge existants capables de construire des tunnels IPSec.

 

GlobalProtect Cloud service offre un service géré et évolutif pour mailler dynamiquement les sites ICS/SCADA distants avec IPSec/SSL. Cela supprime la complexité du déploiement en nuage (pare-feu, portails et passerelles) tout en permettant la gestion de la stratégie de sécurité centrale via panorama. Le service auto-Scales que la demande augmente et diminue afin que les équipes peuvent se concentrer sur la gestion des politiques/incidents plutôt que les aspects du déploiement en nuage.

 

Picture28. png

 

Cela simplifie grandement l'architecture du datacenter. Le routage de site à site et de site à succursale est géré dans le service Cloud GlobalProtect. Le service peut être intégré à une stratégie globale d'entreprise lorsqu'IPsec et l'accès à distance sont requis. Les sites distants pourraient être considérés comme des emplacements ICS/SCADA, des bureaux distants, des travailleurs mobiles ou même d'autres services de cloud public tels qu'Amazon, Azure, Google, etc.

 

Picture29. png

 

Composants du service Cloud GlobalProtect

Ce service est configuré via un plug-in panorama et contient les composants suivants:

 

Picture30. png

 

Notez que le service Cloud GlobalProtect inclut également un service de journalisation basé sur un nuage. L'activité enregistrée dans les pare-feu, les portails et les passerelles est consignée dans ce service. Panorama simplement'points'à ce service comme n'importe quel collecteur de journaux à distance pour les requêtes et les rapports.

 

Il existe quelques licences à récupérer pour le service: GlobalProtect Cloud service pour les réseaux distants et les utilisateurs mobiles ainsi que le service de journalisation.

 

Picture31. png

 

À l'aide de la nouvelle fonctionnalité de plug-in panorama de la version 8. x, installez le dernier plug-in GlobalProtect Cloud service (disponible sur le portail du support client).

 

Picture32. png

 

Installez le service Cloud et connectez le centre de données HQ principal au service. Notez que les groupes et modèles de périphériques existants peuvent être utilisés, ce qui inclurait des environnements ICS/OT.

 

Picture33. png

 

Configurez les sites distants (ICS/SCADA) pour vous connecter via les conduites IPSec/SSL.

 

Picture34a. jpg

 

Dernière étape serait de configurer les stratégies de sécurité comme d'habitude.

 

Un ajout naturel à ces scénarios serait la mise en œuvre des dispositifs anti-hameçonnage et de vol d'informations d'identification de Panos V8. Pour ceux qui souhaitent avoir une posture de sécurité encore plus serrée, il est possible de contrôler l'accès OT au niveau de l'application ainsi que l'ID utilisateur. Par exemple, tous ceux qui n'ont pas accès aux applications OT devront écrire dans les registres/bobines. Cela peut être contrôlé en créant une stratégie de sécurité pour autoriser strictement l'activité de lecture Modbus pour un groupe d'utilisateurs OT et Modbus écrire uniquement pour ceux qui en ont besoin.

 

Picture35. png

 

Résumé

Il existe de nombreux autres cas d'utilisation pour l'utilisation de divers composants de la plate-forme de Palo Alto réseaux dans la sécurisation des environnements ICS/SCADA. Les trois énumérés ici couvrent des exigences spécifiques recueillies auprès des entreprises du secteur pétrolier et gazier.

 

Ce document a simplement montré trois cas d'utilisation liés au déploiement du pare-feu de la prochaine génération de Palo Alto Networks dans un environnement de système de contrôle industriel (ICS). Le premier scénario examine l'utilisation du pare-feu pour appliquer l'authentification multi-facteurs pour les utilisateurs qui accèdent au réseau OT. Ces utilisateurs seront mis en quarantaine lors des échecs d'authentification du second facteur.

 

Le second scénario examine l'activité d'un utilisateur déjà authentifié qui accède au réseau OT. Cet utilisateur peut être mis en quarantaine lors d'un événement de sécurité «critique» et pourrait même être mis en quarantaine lors d'un événement de sécurité «élevé» selon la politique. De tels événements comprendront une large gamme de déclencheurs (par exemple, l'activité de commande et de contrôle, l'accès à des domaines mal connus/IPS/URLs, des événements de vulnérabilité tels que des débordements de mémoire tampon de tas etc.). Lorsque l'utilisateur source déclenche de tels événements, ils sont immédiatement coupés (mis en quarantaine) du réseau OT. Dans chacun des deux premiers scénarios, l'utilisateur source est mis en quarantaine jusqu'à ce qu'un administrateur les supprime du groupe de quarantaine (c'est-à-dire supprime la balise).

 

Le troisième cas d'utilisation se concentre sur les effeciencies opérationnels en construisant des conduites IPSec/SSL maillées dynamiquement depuis les emplacements ICS/SCADA distants vers les centres de données primaires et/ou secondaires (ou plus). Les complexités de la mise à l'échelle sont gérées par le service Cloud GlobalProtecl. Cela inclut le déploiement automatique des pare-feu, des portails, des passerelles et de la journalisation, tous en toute sécurité dans le nuage. Les stratégies de sécurité, les rapports et les requêtes continuent d'être exécutés de manière centralisée par panorama.

 

L'objectif principal des trois cas d'utilisation consiste à fournir des mesures de sécurité supplémentaires pour protéger le réseau ICS. Ces mesures permettent l'automatisation pour réduire les coûts opérationnels et la fatigue de la réponse aux incidents.



Actions
  • Print
  • Copy Link

    https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g000000Cm2hCAC&lang=fr&refURL=http%3A%2F%2Fknowledgebase.paloaltonetworks.com%2FKCSArticleDetail

Choose Language