Archivo de la categoría: Herramientas

Software y recursos para aprendizaje, auditoría, hacking y pentesting.

Vulnerabilidades, métricas y cálculos en en SCI

Posted on por
Anuncios

Allá por junio de 2015 comentamos las vulnerabilidades relacionadas con Sistemas de Control Industrial y, a día de hoy,  continuamente vemos cómo se notifican cada vez más sea cual sea esta si de índole Software o Hardware. Ningún fabricante está exento, más aún cuando todos ellos no han podido ser diseñados bajo la premisa de ser seguro. Hablo desde el punto de vista de “Security” no “Safety”.

En este sentido uno de los métodos de catalogación es el “Common Vulnerability Scoring System”. Un framework abierto y ampliamente utilizado para estimar el impacto cuantitativo de las vulnerabilidades identificadas. Para ello se establece un conjunto de métricas las cuales se dividen de 3 grandes grupos como son: Base, Temporal y de Entorno, donde cada una de ellas engloba distintas características a considerar, como son el Vector de Ataque, privilegios requeridos, interacción con el usuario, remediación, etc.

Luego una fórmula matemática se encarga de establecer en una franja de 0 a 10, la gravedad de la misma, siendo 10 la más alta.

Actualmente se cuenta con la versión 3.1 la cual introduce algunos cambios con respecto a la versión 3.0.

A continuación, os dejo algunos documentos donde podréis encontrar información detallada con respecto a estas dos últimas versiones.

Documento CVSS 3.0

Documento CVSS 3.1

Calculadora CVSS 3.1

Sin embargo, este estándar se ha hecho con el fin de ser aplicado, principalmente en entornos IT, no para entornos OT. Los cuales, como es sabido, son muy distintos. Las consecuencias e impacto de la explotación de una de ellas podrá tener una repercusión Física. Por tanto, una vez más, debemos de establecer unos criterios acordes a los escenarios a los que nos enfrentamos.

En este sentido nos encontramos con IVSS, Industrial Vulnerability Scoring System. Un método que nos ayudará a establecer un valor teniendo en cuenta aspectos concretos de estos entornos como son impacto en la actividad, daños colaterales, rendimiento y elementos Safety.

Elaborada por Clint Bodungen,  la herramienta está disponible es su sitio Web podéis así como la fórmula empleada que permiten obtener dicho índice.

Hay que tener en cuenta que las vulnerabilidades a la hora de descubrirse se llevan a cabo en entornos controlados de laboratorio, junto con la posible explotación asociada. Por tanto, debemos tener presenta que las consecuencias e impacto dependerá del contexto y actividad donde se lleven a cabo. Un laboratorio nunca nos dará el resultado del entorno real.

Además, por ejemplo, no es lo mismo una fábrica donde produzca bajo estrategias JIT/JIS (Just In Time, Just In Sequence) a otra que lo haga con plazos de entrega de días o semanas donde una parada de 24 horas pueda llegar a ser asumible y no suponga repercusión alguna por disponer de estocaje suficiente. O bien, si de lo que hablamos es afecta a la actividad o la seguridad de los empleados como puede ser dispositivos Safety, robots o PLC de control de proceso.

Descubierta la misma, aun cuando el fabricante libere el parche o la remediación, es muy posible que pase un tiempo “muy considerable” antes de ser aplicada. Todo proceso de cambio debe realizarse forma controlada siguiendo una etapa de test, prueba piloto y finalmente despliegue controlado. No podemos llevar a cabo ninguna acción si no estamos seguros al 110 % de que no existirá incompatibilidad o impacto alguno, que pueda penalizar total o parcialmente los procesos bajo su control. No podemos introducir un riesgo mayor del que pretendemos mitigar con la corrección de una vulnerabilidad.

Esto en el mejor de los casos, ya que no sería la primera vez que se detectan vulnerabilidades sobre componentes o sistemas que no puedan ser actualizados, debiéndose aplicar otras medidas compensatorias como el Virtual Patching o definición de arquitecturas de red con mayor o menor índice de segmentación.

Hasta aquí la entrada de hoy, escueta pero que da lugar a invertir tiempo en lectura y tener contacto con un recurso online que nuevamente, entre otros muchos motivos, nos muestra las diferencia de los entornos IT y OT.

Un saludo!

 

Monitorización redes industriales, SCADAGuardian

Posted on por
Anuncios

Cuando abordamos un proyecto para la protección de un entorno de control y automatización, una de las primeras tareas es elaborar un inventario de todos los activos. No podemos tratar de reducir los riesgos de que algo o alguien, de una manera intencionada o no, pueda llevar a cabo una acción que afecte a la actividad de planta, instalaciones o infraestructuras; si saber lo que tenemos.

Es cierto que muchos equipos podrán serán comunes en distintos escenarios, pero dada la heterogeneidad de las actividades industriales cada entorno deberá ser abordado de forma particular. Es cierto que PLC´s, HMI´s y SIS serán un común denominador; no si de lo que hablamos es de atornilladoras, AGVs, sistemas de almacenamiento automático, sistemas de metrología, y un largo etcétera.

Esta tarea puede no ser compleja, pero sí tediosa. Al fin y al cabo, estamos recolectando información. El problema es cómo lo hacemos de una manera lo más sencilla y efectiva posible. Además, por experiencia, se parte con un alto grado de desconocimiento en particular para los profesionales que tienen que liderar proyectos de Ciberseguridad Industrial. Provenientes de entornos IT, donde aparte de desconocer las tecnologías, componentes y tecnologías, comienzan a relacionarse más estrechamente con personal con distintas culturas, puntos de vista, necesidades y sobre todo, prioridades. Hablo de personal de Ingeniería o Mantenimiento.

Por tanto, la base de cualquier proyecto es tener un inventario completo y consolidado que nos permita desarrollar medidas eficientes para proteger nuestros entornos.

Sin embargo, el éste no debe estar ceñido exclusivamente a información sobre tipos de equipos, fabricantes, modelos o versiones de firmware. Debemos conocer las comunicaciones que mantienen con otros sistemas o dispositivos. Esto es, orígenes y destinos, protocolos empleados, direcciones IP y sobre todo qué consignas o valores se envían a través de ellos. Podemos estar autorizando una determinada comunicación, pero ¿qué ocurre si aprovechando una falta de medidas de seguridad nativas somos capaces de cambiar un valor que está fuera de tolerancia?

Por esta y otras razones que iremos descubriendo en sucesivos artículos es que debemos contar con herramientas que nos ayuden a identificar los activos en nuestra organización, sus características y conocer cómo y de qué manera se comunican. A partir de aquí, ya comenzaremos a localizar vulnerabilidades, calcular impactos, priorizar medidas para minimizar riesgos, definir topologías de re red, crear matrices de comunicaciones para configurar reglas en firewalls, etc. etc. etc.

Una de estas ellas es el producto de la firma NOZOMI Networks, SCADAGuardian. Se trata de una herramienta especializada para entornos y tecnologías OT. En formato físico o virtual, entre sus características están

  • Monitorización en tiempo real
  • Identificación de activos de forma automática
  • Detección de comportamiento, amenazas y vulnerabilidades
  • Deep Packet Inspection de protocolos industriales
  • Fácil despliegue
  • Integración con otros sistemas
  • Creación de informes

El modo de operación es por medio bien de un puerto espejo en algunos de los switches de nuestra infraestructura o por medio de dispositivos TAP por lo que no resulta intrusiva ni añade latencias en las comunicaciones establecidas.

Por supuesto, todas estas medidas van acompañadas de una interfaz gráfica a través de la cual podamos visualizar, analizar y explotar toda la información recolectada de una manera intuitiva a través de los menús de navegación.

Adicionalmente se cuenta con una herramienta de gestión centralizada denominada “Central Management Console” con la que podremos desde un único espacio tener visibilidad de todos nuestros SCADAGuardian desplegados en nuestras instalaciones geográficamente o localmente dispersas.

No obstante, esta herramienta no tiene porqué ser empleada exclusivamente por clientes finales. Empresas que provean de servicios de SOC pueden encontrar en CMC una solución para proporcionar otros nuevos sobre entornos industriales como veremos más adelante.

Con todo ello a continuación se muestra una imagen de un despliegue tipo:

Ahora bien, hasta ahora nos hemos ceñido a la identificación de activos y características asociadas, para poder así elaborar un inventario acorde a nuestras necesidades. La herramienta nos permitirá exportar la información generada en formatos como Excel o CSV para un tratamiento posterior. Entre ellas estará la relativa a los equipos, sus enlaces y sesiones de comunicaciones pudiendo tener documentado los valores identificados dentro de cada protocolo.

Hasta ahora hemos hablado de esa primera fase de recolección de información para tener una visión de cómo y por quién está compuesta nuestra red OT. Sin embargo, las capacidades de esta herramienta van más allá pudiendo ser capaz de detectar vulnerabilidades con mayor o menor precisión según sea el caso.

Adicionalmente a SCADAGuardian, disponemos de SCADAGuardian Advanced. Como hemos dicho, la solución recolecta información de forma pasiva no interfiriendo en el tráfico legítimo. Esto proporciona a SCADAGuardian la capacidad de identificar vulnerabilidades por medio del citado análisis. Sin embargo, SCADAGuardian Advanced incorpora una funcionalidad que permite confirmar dichas vulnerabilidades por medio de consultas inteligentes sin interferir en el correcto funcionamiento.

A continuación, se establece una comparativa entre ambas:

Como bien sabemos existe un creciente aumento de vulnerabilidades y amenazas que afectan a sistemas de control y entornos industriales. En este sentido NOZOMI Networks cuenta con un servicio de suscripción denominado “OT Threat Feed” para recibir las últimas descubiertas y que nuestros SCADAGuardian o SCADAGuadian Advanced tengan la capacidad de detectarlas. Detrás de ello, se encuentra con un equipo de investigadores propio que trabajan continuamente para la mejora del producto siendo un ejemplo de ello las publicadas en fuentes como el ICS-CERT.

Con todo ello hemos de tener presente una funcionalidad clave en este tipo de soluciones y es la de notificar de alertas cada vez que tenga lugar un evento o anomalía. Para ello podremos personalizar y establecer canales para su notificación que van desde productos comerciales hasta mensajes de correo electrónico, Syslog o Traps de SNMP. SCADAGuardian establece 4 tipos de alertas principales en función del motor (funcionalidad) que la origine, “Protocol Validation”, “Learned Behavior”, “Built-in Checks” y “Custom Checks”.

En el momento del despliegue, SCADAGuardian necesita de un proceso de aprendizaje acerca del comportamiento de la red y de los elementos que la componen. En función de ese aprendizaje, la herramienta generará una nueva alerta por cada anomalía detectada. Más tarde, debreemos indicar si se trata de un incidente o si por el contrario se trata de un cambio o evento controlado. Por ejemplo, imaginemos una tarea de mantenimiento programado en la que conectamos un nuevo equipo que hasta la fecha no había sido conectado a la red.

Hasta aquí la entrada del día de hoy donde hemos hecho un repaso a la herramienta de monitorización líder del mercado no sólo por el crecimiento que NOZOMI Networks sino por sus capacidades de integración como es el caso de los equipos SIEMENS RUGGEDCOM APE proporcionando así una solución embebida en productos de terceros evitando así el despliegue de nuevo equipamiento.

Sin embargo no es la única. A continuación os dejo un video con la que se puede obtener con equipamiento de la firma Fortinet, dela que ya hemos hablado en otras entradas como su integración con switches.

Un saludo, nos vemos en la próxima!

Edorta

 

Reproduciendo PCAPs, TCPreplay

Posted on por
Anuncios

El uso de protocolos de comunicaciones basados en Ethernet en entornos industriales aparte de ser clara, resulta necesaria para la integración de tecnologías y sistemas que ayudan a mejorar procesos. Aunque, también es cierto, que la existencia de buses de campo basados en comunicaciones serie seguirá estando presente hasta que puedan ser reemplazados por aquéllos. Ethernet ofrece una flexibilidad, escalabilidad y capacidades de integración evidentes.

Sin embargo, esas ventajas traen consigo nuevos riesgos. Los componentes, sistemas y equipos comienzan a estar más expuestos y por tanto con un mayor riesgo frente a amenazas de distinta índole.

Desde el punto de vista de la ciberseguridad en muchas ocasiones deberemos de analizar distintos patrones de tráfico con el fin de identificar activos, anomalías o extraer algún tipo de información que resulte de interés. Para ello deberemos recurrir a capturar tráfico de una manera pasiva o, no intrusiva, para no introducir latencias o variaciones de éstas que puedan afectar los procesos. Algo crítico, como ya sabemos.

Los recursos más empleados son los puertos espejo en switches o dispositivos TAP de los que ya hablaba en las siguientes entradas.

Puerto espejo, un aliado a veces olvidado

TAP devices, Siemens TAP 104

Sin embargo, no son los únicos. Cortafuegos también disponen de estas características como podemos observar en los del Fabricante Fortinet como se muestra en la imagen siguiente. Una funcionalidad a tener presente tanto en los encargados de «Separar y Segmentar» o de proteger una celda, célula o un conjunto menor de equipos siguiendo una estrategia de Virtual Patching

Las capturas que realizaremos están muy bien desde el punto de vista de recolección de información para su análisis posterior, tanto de forma manual o por medio de alguna herramienta que nos facilite la tarea.

Ahora bien, puede darse el caso en el que queramos por ejemplo reproducir ese tráfico en un entorno controlado tal y como se ha producido en nuestra red OT. Algo que como es lógico no podremos realizar en el original

Para esos casos podremos emplear herramientas como la que nos atañe en el día de hoy, tcpreplay. Con tcpreplay podremos reproducir las capturas previamente recogidas e inyectarlas de nuevo en la red y así ver efectos, comprobar configuración de cortafuegos, NIDS, entre otras. Para ello he generado el siguiente escenario:

Desde la estación con una distribución “Kali Linux” reproduciremos las capturas previamente recolectadas para poder visualizarlas en un equipo Windows 10 con el analizador Wireshark.

Para el caso más sencillo, deberemos indicar la interfaz por dónde se inyectará el tráfico y la captura en sí. En nuestro caso “eth0” y “omron.pcap” respectivamente.

Como podemos comprobar las direcciones IP de la captura son distintas a configuradas en los equipos ya que pertenecen al entorno original.

No obstante, dispondremos de otras opciones, dependiendo de nuestras necesidades y objetivos. Por ejemplo.

Establecer la frecuencia con la que emitiremos los paquetes, es este caso 1 segundo:

Como podremos comprobar en la columna “Time” vemos la sucesión de tiempos según lo indicado en el paso anterior.

En otros escenarios podrá interesarnos la opción de enviar los paquetes tan rápido como sea posible con el parámetro “-t”. En este caso podremos comparar los resultados con el ejemplo anterior y ver, una duración de 244 segundos frente a 0,012045. Algo que puede ser útil para comprobar comportamientos, respuestas, etc.

Otras opciones que tendremos será la de poder indicar la cantidad de paquetes a enviar. Por ejemplo, 1 paquete por segundo durante un tiempo de 15 segundos.

Mientras que con el siguiente la emisión de 15 paquetes pero sin la limitación de tiempo.

Hasta ahora hemos visto la posibilidad de definir una serie de parámetros y realizar los envíos. Sin embargo, podremos hacerlo de forma controlada interactuando con la herramienta. Esto puede ser interesante en momentos en lo que debamos analizar, por ejemplo, alguna acción y detectar los paquetes a través de los cuales se ha realizado. Por ejemplo, en un entorno de laboratorio si detectamos la parada de un PLC poder ir paquete a paquete hasta detectar el cambio de estado de la CPU del controlador.

Según la imagen siguiente habremos enviado un total de 100 paquetes. Primero habremos mandado 10, luego 20, luego 5, 50, 10, 3, y 1. En paralelo habremos observado el comportamiento en el entorno que hubiéramos deseado.

La tendencia hacia las comunicaciones Ethernet en entornos industriales en detrimento de las serie es clara, aunque éstas seguirán vigentes durante mucho tiempo ya que la migración requiere de recursos humanos, técnicos y económicos importantes. Algo que puede no ser asumible por las organizaciones.

Pero sobre aquellas que así lo sean, buses de campo como supervisión, es probable que tengamos la necesidad de capturar esas comunicaciones y realizar un análisis posterior en un entorno de laboratorio y con otro tipo de herramientas, como puede ser también Grassmarlin. En el caso de tener la necesidad de querer reproducir tales capturas para observar el comportamiento en un medio o entorno similar al original, tcpreplay es una herramienta a tener muy presente. Ahora queda explorar el resto de opciones.

Un saludo, ¡nos vemos en la siguiente!