Protección de redes ICS y SCADA con pan-OS 8,0

Protección de redes ICS y SCADA con pan-OS 8,0

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


Resolution


Este documento examinará tres casos de uso relacionados con el uso del cortafuegos de la próxima generación de Palo Alto Networks dentro de un entorno de sistema de control industrial (ICS). El objetivo principal de los tres casos de uso es proporcionar medidas de seguridad adicionales para proteger la red ICS. También es importante que estas medidas permitan la automatización cuando sea posible para reducir los costos operacionales y la fatiga de respuesta a incidentes.

 

Los tres casos de uso:

  • Introducir autenticación de múltiples factores (2FA) para el acceso a las redes y aplicaciones de tecnología operacional (OT)
  • Puntos finales de cuarentena automática al fallar la autenticación y eventos de seguridad críticos
  • Proporcione los conductos cifrados de las localizaciones del ICS a los varios centros de datos y enmallan dinámicamente estos túneles

Requisitos

Elemento requerido

Notas

Panos 8

8.0.5 en el momento de este documento

Autenticación de varios factores

OKTA en este ejemplo

Sistema de ticketing

ServiceNow en este ejemplo

GlobalProtect Cloud Service

 

 

Diagrama de alto nivel que representa el límite de IT/OT donde se aplicarían los casos de uso de seguridad de varios factores:

Picture1.png

 

Diagrama de flujo para casos de uso de múltiples factores

El flujo general se representa en la tabla de abajo. En este ejemplo, se requiere atención administrativa para eliminar un punto final del grupo de cuarentena. Sin embargo, es posible dentro de Panos versión 8. x para eliminar dinámicamente, así como añadir una etiqueta al tráfico de origen ofensivo. Esto permitiría potencialmente la automatización completa en el movimiento de los puntos finales entre la cuarentena y otros grupos de direcciones dinámicas.

 

Picture2.png

 

Configuración para casos de uso de varios factores

Tradicionalmente, la autenticación de varios factores requiere que la aplicación sea capaz de proporcionar interacción 2FA. Sin embargo, hay muchas aplicaciones que simplemente no tienen esta característica (especialmente aplicaciones heredadas dentro del entorno OT). Ahora es posible hacer cumplir la autenticación de varios factores para estas y otras aplicaciones iniciando el proceso a nivel de red. En concreto, Panos versión 8 proporciona esta capacidad y no depende de que la aplicación sea 2FA consciente. Ahora es posible iniciar el proceso de la AMF cuando los criterios específicos se cumplen dentro del conjunto de reglas (es decir, cuando los usuarios de la red de ti intentan llegar a las aplicaciones de la red OT). Si alguno de los procesos de autenticación falla, se deniega el acceso.

 

El primer caso de uso es introducir la autenticación de varios factores cuando los usuarios intentan acceder a las aplicaciones que residen en la red OT. Se solicita a los usuarios que introduzcan sus credenciales en un formulario basado en Web (primera autenticación), seguido de confrmation (segunda autenticación) para asegurarse de que el propietario de la credencial realmente inició el proceso.

El primer pase es a través de un portal cautivo login:

 

Picture3.png

El segundo paso se valida fuera de banda:

 

Picture4.png

 

Agregue el perfil de servidor de varios factores en perfiles de dispositivos/servidores/autenticación de múltiples factores. En la actualidad, hay cuatro plantillas incorporadas para los providores AMF (Okta Adaptive, PingID, y Duo V2). Ver captura de pantalla, por ejemplo. Para obtener una configuración detallada de autenticación de varios factores, consulte la guía de administradores de Panos 8,0: https://www.paloaltonetworks.com/documentation/80/pan-os/pan-os/Authentication/configure-multi-factor-Authentication

 

Picture5.png

 

Habilitar factores de autenticación adicionales dentro de un perfil de autenticación (seleccione el perfil de servidor AMF recién creado): Perfil de dispositivo/autenticación:

 

Picture6.png

 

Cree un objeto de aplicación de autenticación y seleccione el perfil de autenticación que se acaba de crear. Esto se encuentra bajo objetos/autenticación. Crear un mensaje personalizado los usuarios verán cuando se les solicite el primer nivel de autenticación a través de portal cautivo.

 

Picture7.png

 

Configure una regla de autenticación para desencadenar el proceso de autenticación de múltiples factores. En este ejemplo queremos lanzar el proceso de multi factor cuando el tráfico iniciado desde la red de TI está destinado a la red OT. Esto podría refinarse añadiendo grupos de anuncios específicos o usuarios.

 

Políticas/autenticación

 

Picture8.png

 

Cree una regla de directiva de seguridad que permita a los usuarios acceder a los servicios y aplicaciones que requieren autenticación. Esto podría refinarse añadiendo grupos de anuncios específicos o usuarios y aplicaciones (es decir, Modbus, DNP3, Cygnet-SCADA, etc).

 

Políticas/seguridad

 

Picture9.png

 

Agregar los grupos de direcciones de automatización y dinámicas

Después de introducir la autenticación de varios factores, el siguiente paso es tomar medidas sobre un intento de autenticación fallido o un evento de seguridad crítico. Para lograr esto, hay dos características para implementar: grupos de direcciones dinámicos y perfiles de reenvío de logs.

 

Los grupos de direcciones dinámicas (DAGs) permiten políticas flexibles que se adaptan a los cambios. Por ejemplo, un host puede comenzar con una etiqueta que lo coloca en un grupo de direcciones que coincida con una regla de permitir pero que su etiqueta Cambie dinámicamente (y, posteriormente, la mueva a un grupo de direcciones diferente) para que coincida con una regla denegar. Esto elimina la necesidad de agregar/quitar reglas continuamente de la Directiva de seguridad. Consulte la guía del administrador de Panos 8 para obtener información detallada sobre grupos de direcciones dinámicas:

https://www.paloaltonetworks.com/documentation/80/pan-os/pan-os/Policy/use-Dynamic-Address-Groups-in-Policy

 

Para crear un grupo de direcciones dinámico, vaya a grupos de objetos/direcciones. Este grupo estará vacío, ya que coincidirá con una etiqueta de cuarentena para la que no se etiquetará el tráfico inicialmente.

 

Picture10.png

 

A continuación, cree los parámetros requeridos para vigilar dentro de los logs. Para cada uno, cree una acción integrada que etiquete dinámicamente el origen con una etiqueta de cuarentena.

 

Vaya a objetos/reenvío de registro y cree una entrada nueva.

 

Picture11. pngPicture12. pngPicture13. pngPicture14. png

 

Agregar los perfiles de automatización: reenvío de logs

Para cada intento de AMF fallido, defina la acción integrada para el etiquetado dinámico.

 

Picture15. png

 

Ahora, añada la automatización de generar el ticket de servicio. En el método forward, añada la información del servidor http predefinido para ServiceNow. El servidor http predefinido se introduciría en los perfiles de dispositivo/servidor/http.

 

Defina el perfil del servidor http para ServiceNow.

 

Picture16. png

 

Haga clic en la ficha formato de carga para utilizar el formato de registro incorporado para ServiceNow.

 

Haga clic en autenticación y seleccione ServiceNow seguridad incidente desde el menú desplegable. La información de error de autenticación pertinente se enviará a ServiceNow en un formato fácilmente consumible por la API basada en http de ServiceNow.

 

Picture17. png

 

Volver a objetos/reenvío de registro para agregar la automatización al perfil para intentos de AMF fallidos y agregar el servidor http creado para ServiceNow.

 

Picture18a. jpg

 

Cuando termine con el primer caso de uso (fallos del AMF), añada el segundo caso de uso (hosts de cuarentena de OT con eventos de seguridad críticos).

 

Picture19. pngPicture20. pngPicture21. png

 

Agregue el perfil de servidor http para ServiceNow.

 

Picture22. png

 

El perfil final de reenvío de registro se verá algo como esto:

 

Picture23. pngPicture24. png

 

Agregue el perfil de reenvío de registro recién creado a la regla de seguridad que permite el tráfico de ti a OT.

 

Picture25. pngPicture26. png

 

Los casos de uso enumerados aquí requieren la intervención manual para mover los anfitriones aislados de la cuarentena de nuevo a la producción. Para otras áreas menos sensibles de la red, esto podría ser dinámico, ya que las acciones integradas dentro del reenvío de logs también pueden eliminar etiquetas (es decir, quitar una etiqueta de cuarentena). Para ver las direcciones IP de origen que se han colocado en la cuarentena Dag, vaya a directivas, encuentre la regla que contiene el Dag y pase el cursor sobre el Dag para ver una desplegable. Seleccione el desplegable, el valor y más para ver la lista y tomar medidas en fuentes individuales.

 

Picture27. png

 

Consulte la página siguiente para obtener el número máximo de direcciones IP registradas dinámicamente disponibles por Plaform: https://www.paloaltonetworks.com/documentation/80/pan-os/pan-os/Policy/use-Dynamic-Address-Groups-in-Policy

 

Entrelazado dinámico de túneles IPSEC

Cuando hay muchos sitios remotos ICS/SCADA que requieren conectividad IPSec a múltiples Data Centers (MPLS o a través de Internet), puede ser administrativamente oneroso para configurar y mantener. Esto es especialmente cierto cuando los sitios completamente enmallados son un requisito. En lugar de implementar otro dispositivo frente al cortafuegos para manejar los túneles dinámicos y de enrutamiento, existe una solución elegante que utiliza los cortafuegos existentes de Palo Alto Networks o los dispositivos Edge existentes capaces de construir túneles IPSEC.

 

GlobalProtect Cloud Service ofrece un servicio gestionado y escalable para Enmallar dinámicamente sitios remotos ICS/SCADA con IPSec/SSL. Esto elimina la complejidad de la implementación en nube (firewalls, portales y gateways) al tiempo que permite la administración de políticas de seguridad central a través de panorama. El servicio se escala automáticamente a medida que la demanda aumenta y disminuye, de manera que los equipos pueden centrarse en la administración de incidentes y políticas en lugar de los aspectos de la implementación en nube.

 

Picture28. png

 

Esto simplifica enormemente la arquitectura del Data Center. El enrutamiento de sitio a sitio y de sitio a rama se controla en el servicio de nube de GlobalProtect. El servicio puede ser incorporado a una estrategia corporativa global cuando se requiere IPSec y acceso remoto. Los sitios remotos podrían ser pensados como ubicaciones ICS/SCADA, oficinas remotas, trabajadores móviles, o incluso otros servicios públicos de nube como Amazon, Azure, Google, etc.

 

Picture29. png

 

Componentes del servicio Cloud de GlobalProtect

Este servicio se configura a través de un plug-in panorámico y contiene los siguientes componentes:

 

Picture30. png

 

Tenga en cuenta que el servicio GlobalProtect Cloud también incluye un servicio de registro basado en la nube. La actividad registrada dentro de los cortafuegos, portales y gateways se registra en este servicio. Panorama simplemente ' señala ' a este servicio como cualquier colector de registro remoto para consultas y reporting.

 

Hay algunas licencias para recuperar para el servicio: GlobalProtect Cloud Service para redes remotas y usuarios móviles junto con el servicio de registro.

 

Picture31. png

 

Usando la nueva función de plug-in de panorama en la versión 8. x, instale el último plug-in de GlobalProtect Cloud Service (disponible en el portal de soporte al cliente).

 

Picture32. png

 

Configure el servicio Cloud y conecte el centro de datos HQ principal al servicio. Tenga en cuenta que se pueden utilizar grupos de dispositivos y plantillas existentes que incluirían entornos ICS/OT.

 

Picture33. png

 

Configure los sitios remotos (ICS/SCADA) para conectarse a través de conductos IPSec/SSL.

 

Picture34a. jpg

 

Paso final sería configurar las directivas de seguridad como de costumbre.

 

Una adición natural a estos escenarios sería la implementación de las características anti-phishing y robo de credenciales de Panos V8. Para aquellos que deseen tener una postura de seguridad aún más estricta, es posible controlar el acceso OT en el nivel de aplicación junto con User-ID. Por ejemplo, no todos los que accedan a las aplicaciones de OT necesitarían escribir en los registros/bobinas. Esto se puede controlar mediante la creación de una política de seguridad para permitir estrictamente la actividad de lectura Modbus para un grupo de usuarios de OT y Modbus escribir sólo para aquellos que lo necesitan.

 

Picture35. png

 

Resumen

Existen muchos otros casos de uso para el uso de varios componentes de la plataforma Palo Alto Networks en la seguridad de entornos ICS/SCADA. Los tres enumerados aquí cubren requisitos específicos recogidos de las compañías en el sector de petróleo y gas.

 

Este documento sólo ha mostrado tres casos de uso relacionados con la implementación de la nueva generación de cortafuegos de Palo Alto Networks dentro de un entorno de sistema de control industrial (ICS). El primer escenario examina el uso del cortafuegos para aplicar la autenticación de múltiples factores para los usuarios que accedan a la red OT. Estos usuarios se pondrán en cuarentena en los fallos de autenticación de segundo factor.

 

El segundo escenario examina la actividad de un usuario ya autenticado que accede a la red OT. Este usuario puede ser puesto en cuarentena en un evento de seguridad ' crítico ' e incluso podría estar en cuarentena en un evento de seguridad ' alto ' dependiendo de la política. Tales eventos incluirían una amplia gama de desencadenantes (es decir, actividad de comando y control, intento de acceso a dominios/IPS/URLs conocidos, eventos de vulnerabilidad como desbordamientos de búfer de montón, etc.). Cuando el usuario de origen está desencadenando tales eventos, se cortarán inmediatamente (se pondrán en cuarentena con la etiqueta) de la red OT. En cada uno de los dos primeros escenarios, el usuario de origen se pone en cuarentena hasta que un administrador los quita del grupo de cuarentena (es decir, quita la etiqueta).

 

El tercer caso de uso se centra en la effeciencies operativa mediante la creación de conductos IPSec/SSL con malla dinámica desde las ubicaciones remotas ICS/SCADA a las ubicaciones de los centros de datos primarios y/o secundarios (o más). Las complejidades de escalar arriba y abajo son manejadas por el servicio Cloud de GlobalProtecl. Esto incluye el despliegue automático de cortafuegos, portales, gateways y registro, todos seguros dentro de la nube. Las políticas de seguridad, los informes y las consultas continúan siendo realizadas centralmente por panorama.

 

El objetivo principal de los tres casos de uso es proporcionar medidas de seguridad adicionales para proteger la red ICS. Estas medidas permiten la automatización para reducir los costos operacionales y la fatiga de respuesta a incidentes.



Actions
  • Print
  • Copy Link

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

Choose Language