Tú reportas, ellos actúan

La búsqueda y explotación de vulnerabilidades en dispositivos industriales es una estrategia destinada a evaluar la información y la seguridad de los sistemas afectados. Durante el desarrollo de algunos trabajos, tanto de investigación como de auditoría, puede darse el caso de que se detecten vulnerabilidades de día cero (habitualmente conocidos por el término 0-day) en algún dispositivo (PLC, RTU, HMI, etc.), aplicaciones o sistemas operativos usados en la industria. Estas vulnerabilidades no son conocidas públicamente, por lo que es crucial articular vías para la notificación, tratamiento y parcheado de las mismas. Dado que el parcheo en dispositivos industriales supone un gran reto,  se ha de tener en cuenta este hecho a la hora de reportar una vulnerabilidad para que sea solucionada.

Con el fin de realizar una buena gestión de las vulnerabilidades, se proponen diferentes fases que deberían seguirse a la hora de reportar una vulnerabilidad.

Antes de entrar en el desarrollo de las fases para una buena gestión de las vulnerabilidades, es importante destacar que las pruebas de investigación sobre las mismas en los entornos industriales han de hacerse en un entorno de desarrollo o pruebas. No se deberían realizar análisis en entornos de producción ya que, aunque las pruebas a realizar se hayan probado y revisado adecuadamente con anterioridad, es posible que el comportamiento sea diferente en producción.

Fases del tratamiento

Dentro de la fase 1 de identificación, toma gran importancia la forma de analizar dispositivos. Dentro de esta fase encontramos una parte de identificación de vulnerabilidades y otra que sirve para evidenciarlas, es importante tener en cuenta que no son lo mismo. En la fase de identificación, el auditor o investigador de seguridad aplicará las técnicas según su criterio o experiencia en ciertas tareas para lograr identificar una vulnerabilidad. Para evidenciar las vulnerabilidades, el investigador/auditor debe ser más riguroso, y, por ello, no podrá emplear gran parte de las acciones utilizadas en la identificación. Algunas de las acciones no permitidas para evidenciar vulnerabilidades pueden ser:

• Uso de algún tipo de malware.
• Utilizar la vulnerabilidad de cualquier forma más allá de demostrar su existencia. Para demostrar que la vulnerabilidad existe, se pueden usar métodos no agresivos, por ejemplo, listando un directorio del sistema.
• Uso de ingeniería social.
• Comprometer un sistema y mantener el acceso de forma persistente.
• Alteración de datos a los que se accede gracias a la explotación de la vulnerabilidad.
• Compartir la vulnerabilidad con terceros.
• Realizar ataques DoS o DDoS.

En la fase 2, a la que llamaremos fase de reporte, entran en juego los CERT o CSIRT, equipos de respuesta a incidentes de seguridad que, dependiendo del tipo, pueden, entre otros servicios, proporcionar ayuda tanto a los investigadores o auditores que reportan vulnerabilidades como al fabricante afectado. Algunas de las ayudas que proporcionan algunos CERT consisten en poner en contacto a los actores involucrados en la vulnerabilidad o facilitar la gestión y evaluación del fallo descubierto. Estas y otras ayudas, beneficiarían a todas las partes afectadas. El papel que juega un CERT o CSIRT es útil para que el fabricante sea informado y logre solventar la o las vulnerabilidades en el menor tiempo posible.

Los investigadores o auditores han de reportar las vulnerabilidades de forma segura, para ello, se recomienda el uso de firmas PGP que verifiquen la procedencia de la información y, además, el cifrado de la misma con el fin de salvaguardar la privacidad del fabricante afectado.

Además de informar, otra de las funciones que podría desempeñar un CERT o CSIRT es la de reproducir las vulnerabilidades reportadas. Esta reproducción se realiza con el fin de tener un mayor entendimiento de los problemas que puede originar la vulnerabilidad reportada y, en caso de que se requiera, ayudar de una manera más eficiente al fabricante afectado a nivel técnico en la resolución de problemas.

Esta tarea de análisis constituye la fase 3, en la que se reproduce la vulnerabilidad y, en el caso de ser necesario, se pediría más información al investigador o auditor que ha reportado la vulnerabilidad con el fin de reproducir de forma fiel el problema.

Cabe destacar el hecho de que actualmente existen fabricantes industriales que poseen su propio CERT para el tratamiento de vulnerabilidad de sus productos y, por lo tanto, juegan un papel doble: el de CERT que informa de la vulnerabilidad, verificando previamente que ésta existe, y el de fabricante, al que se le comunicará el problema.

La parte de tratamiento de la vulnerabilidad se enmarca en la fase 4. Esta fase se basa en la clasificación de la vulnerabilidad, definición de su impacto y mitigación o solución de la propia vulnerabilidad. El primer paso en esta fase será la reserva del código CVE siguiendo el estándar de nomenclatura de vulnerabilidades. Este estándar es utilizado con el fin de facilitar el intercambio de información entre diferentes bases de datos y herramientas. Junto con esta reserva, en ocasiones, se asigna a la vulnerabilidad un valor que definirá el nivel de criticidad que posee la misma, consensuado entre el investigador o auditor y el fabricante afectado, para ello, las métricas a utilizar son las marcadas por el framework CVSS (Common Vulnerability Scoring System). Este framework es totalmente abierto y universalmente aceptado para el establecimiento de métricas en vulnerabilidades, el problema de este estándar a la hora de evaluar una vulnerabilidad es que está pensado sobre todo para entornos TI, por lo que la valoración de las vulnerabilidades en entornos TO puede ser más complejo. En el caso de las métricas base, esto no supone un gran problema ya que incluye el siguiente grupo de métricas que pueden ser aplicadas a un entorno industrial:

• Vector de acceso
• Complejidad del ataque
• Privilegios requeridos
• Necesidad de interactuación por parte de un usuario
• Alcance
• Impacto en la Confidencialidad
• Impacto en la Integridad
• Impacto en la disponibilidad

En el caso de las métricas temporales y del entorno, es posible que se necesiten otro tipo de indicadores que evalúen de forma más correcta la vulnerabilidad reportada.

Una vez realizadas todas las gestiones ya comentadas, será necesario solventar la vulnerabilidad en el sistema afectado o, si no es posible, mitigarla de forma temporal hasta dar con la solución final. El propio investigador o auditor puede proponer un mecanismo o estrategia de mitigación.

Por su parte, el fabricante debe gestionar y desarrollar un parche. Este proceso puede que se prolongue en el tiempo ya que será necesaria la ejecución de diferentes pruebas de calidad en múltiples entornos.

Ya, por último, llega la fase 5. Esta fase se centra en la publicación responsable y difusión de la vulnerabilidad por un canal oficial, habitualmente en la sección de avisos de la página del CERT que la ha gestionado y en la sección adecuada dentro de la página del fabricante.  Sería recomendable gestionar y acordar una publicación responsable junto con el fabricante, para permitir a éste desarrollar, probar y publicar el parche. Posteriormente a esta publicación responsable, el auditor o investigador podrá difundir sus análisis de la vulnerabilidad. En estos casos es muy importante tener en cuenta siempre el respeto a la ley.

Excepciones

En este ciclo de fases existen algunas excepciones, en concreto podemos identificar claramente dos: cuando la vulnerabilidad no puede solucionarse y cuando el fabricante hace caso omiso a las comunicaciones del CERT.

En el primer caso, la publicación se hará de forma totalmente privada, en este caso la información solo estará disponible para los clientes, para que puedan aplicar otras contramedidas. En el segundo caso, tanto si la gestión de la vulnerabilidad es exitosa, como si no, cada CERT puede definir un plazo transcurrido el cual si la parte responsable de su gestión no ha tomado las medidas suficientes para solucionarla, el CERT emitirá un aviso notificando la vulnerabilidad juntamente con el investigador o auditor que la ha reportado, si éste lo desea.

Fuentes de interés

Algunas fuentes de interés donde pueden encontrarse publicaciones de vulnerabilidades en sistemas de control industrial:

• INCIBE-CERT – CERT de Seguridad e Industria
• ICS-CERT – CERT ICS estadounidense

Resumen de las fases

Conclusiones

Las vulnerabilidades detectadas en dispositivos industriales muchas veces son complejas de solucionar dadas las características que poseen los propios dispositivos desplegados, tanto hardware como software, pero ¿tendría este hecho que echar para atrás a un investigar o auditor a la hora de investigar una vulnerabilidad que afecta a este tipo de dispositivos? La respuesta lógica tras leer este artículo debería ser no.

El reporte de vulnerabilidades en los dispositivos presentes en Sistemas de Control Industrial proporciona grandes ventajas. Estas son algunas de ellas:

• Mejora de la ciberseguridad que poseen los dispositivos afectados.
• Confianza, por parte de los clientes, en los fabricantes que realizan modificaciones a nivel de seguridad en sus dispositivos.
• Cumplimiento de normativas de ciberseguridad que pueden afectar al sector industrial.
• Repositorio para investigaciones y auditores.

Finalmente, el reporte de vulnerabilidades en sistemas de control industrial supone un gran beneficio tanto para investigadores/auditores como para fabricantes, no sólo por las ventajas anteriormente comentadas, sino por el incremento global de la seguridad que supone para el sector industrial.