Publicaciones CERTSI e INCIBE sobre Ciberseguridad Industrial, actualizado 29/10/17.

Tanto INCIBE (Instituto Nacional de Ciberseguridad de España) como CERTSI (CERT de Seguridad e Industria) publican a menudo en sus respectivas Webs noticias, guías y artículos sobre distintas temáticas teniendo como telón de fondo la seguridad. Para esta ocasión he ordenado las referentes a Ciberseguriad Industrial, que recopilan un buen número de investigaciones, incidentes, análisis, e informes, sobre distintas temáticas.  Sin duda constituye un conjunto de referencias para el aprendizaje de todo profesional que esté o quiera desempeñarse en securización de estos entornos. Espero que os guste y sobre todo os resulte útil.

Un saludo!

Guías:

  1. Despliegue de un IDS/IPS y gestión centralizada de alertas.
  2. Protocolos y Seguridad en SCI.
  3. Identificación y reporte de incidentes de seguridad para operadores estratégicos: Guía básica de protección de Infraestructuras Críticas.
  4. El Puesto del Operador: Guía básica de protección de Infraestructuras Críticas.
  5. Guía de Seguridad de Protocolos Industriales – Smart Grid

 Artículos:

  1. Los conocimientos del personal de seguridad industrial.
  2. Ciberseguridad en las comunicaciones inalámbricas en Entornos Industriales
  3. SNMP, ¿es tan simple como el nombre indica?
  4. Cortafuegos transparentes, ladrillos de cristal.
  5. PRP y HSR: Protocolos redundantes.
  6. Robots y drones en la Industria 4.0.
  7. Hardware Hacking en Sistemas de Control Industrial.
  8. CrashOverride: El malware para SCI ataca de nuevo.
  9. Analizando la seguridad sin riesgos: laboratorios de pruebas.
  10. Asegurando la virtualización de tus sistema de control.
  11. Gestión de credenciales en sistemas de control.
  12. Prevención de intrusos y gestión de eventos para sistemas de control.
  13. Insider, las dos caras del empleado.
  14. Amenazas emergentes en entornos industriales.
  15. Honeypots Industriales.
  16. Gestionar el riesgo de los proveedores como propio.
  17. Seguridad en protocolos industriales – Smart Grid
  18. Criptografía para reforzar la ciberseguridad en entornos industriales.
  19. Características y seguridad en PROFINET.
  20. Analizadores de red en Sistemas de Control.
  21. Seguridad Industrial 2016 en cifras.
  22. ¿Nuevo ciberataque a la red eléctrica de Ucrania?
  23. Inventario de activos y gestión de la seguridad SCI.
  24. Líneas de actuación del Esquema Nacional de Seguridad Industrial.
  25. Protocolos Industriales: Herramientas de Seguridad.
  26. ¿Tu empresa es segura? Medir es el primer paso para conseguirlo.
  27. Atrapando sombras en la industria.
  28. Cyber Kill Chain en Sistemas de Control Industrial.
  29. DDOS de actualidad: IoT y los DNS de Dyn.
  30. Seguridad en BlueTooth: Fortalezas y debilidades.
  31. ZigBee en el laboratorio.
  32. Thinking in Big (Data) y la seguridad industrial.
  33. Seguridad desde abajo: dispositivos finales a escena.
  34. Familia de malware en la industria.
  35. Protegiéndose de BlackEnergy: Detectando anomalías.
  36. Seguridad en Comunicaciones ZigBee.
  37. BlackEnergy y los Sistemas Críticos.
  38. Desmontando Modbus.
  39. Safety y security: juntos pero no revueltos.
  40. BMS: Edificios inteligentes, ¿y seguros?
  41. Seguridad industrial 2015 en cifras.
  42. Un SCADA en la ciudad.
  43. Aplicando seguridad en WirelessHart.
  44. Sistemas de control de software libre.
  45. Arquitecturas de seguridad en la nube para la industria.
  46. Las aplicaciones de control se hacen mayores.
  47. Mi SCADA en las nubes.
  48. Evolucionando la comunicación en la industria.
  49. La Ciberseguridad en la Industria 4.0.
  50. Divide y vencerás: Segmentación al rescate.
  51. Monitorización de amenazas en SCADA.
  52. Evolucionando la infraestructura de red en SCI.
  53. Bug Bounties en SCI: Vulnerabilidades en busca y captura.
  54. El consumo eléctrico bajo control.
  55. Buenas prácticas de configuración en la red inteligente.
  56. Disciplina militar en Control Industrial: OPSEC.
  57. Auditorias en sistemas de control.
  58. Amenazas en los Sistemas de Control Industrial.
  59. Certificaciones de seguridad en sistemas de control.
  60. La evolución de los dispositivos en los sistemas de control industrial.
  61. Estándares de ciberseguridad en las redes inteligentes.
  62. BYOD en entornos industriales.
  63. IEC 62443: Evolución de la ISA 99.
  64. La seguridad de los coches inteligentes a examen.
  65. La ciberseguridad en las subestaciones y el estándar IEC 61850.
  66. Herramientas TI que evolucionan para TO.
  67. La evolución del software en los sistemas de control industrial.
  68. Diferencias entre TI y TO.
  69. Normativas de seguridad en sistemas de control.
  70. Identificación de sistemas de control industrial.
  71. Problemática de los antivirus en entornos industriales.
  72. Seguridad en Protocolos de Sistemas de Control Industrial.
  73. Del Air Gap a la Segmentación en ICS.
  74. Guía de seguridad de Sistemas de Control Industrial.
  75. La problemática de la ciberseguridad para los profesionales de los sistemas de control industrial.
  76. Protegiendo Infraestructuras Críticas: no es suficiente con medidas IT.
  77. Hacia una evaluación eficaz de la seguridad en ICS.

Otras Guías de interés:

  1. Guía de Pentest: Recolección de información (Information Gathering).
  2. Guía sobre análisis de tráfico con Wireshark.
  3. Guia de Seguridad en servicios DNS
  4. Ciber-Resiliencia: Aproximación a un marco de medición.
  5. Detección de APTs.

 

Publicaciones CERTSI e INCIBE sobre Ciberseguridad Industrial, actualizado 03/08/17.

Tanto INCIBE (Instituto Nacional de Ciberseguridad de España) como CERTSI (CERT de Seguridad e Industria) publican a menudo en sus respectivas Webs noticias, guías y artículos sobre distintas temáticas teniendo como telón de fondo la seguridad. Para esta ocasión he ordenado las referentes a Ciberseguriad Industrial, que recopilan un buen número de investigaciones, incidentes, análisis, e informes, sobre distintas temáticas.  Sin duda constituye un conjunto de referencias para el aprendizaje de todo profesional que esté o quiera desempeñarse en securización de estos entornos. Espero que os guste y sobre todo os resulte útil.

Un saludo!

Guías:

  1. Despliegue de un IDS/IPS y gestión centralizada de alertas.
  2. Protocolos y Seguridad en SCI.
  3. Identificación y reporte de incidentes de seguridad para operadores estratégicos: Guía básica de protección de Infraestructuras Críticas.
  4. El Puesto del Operador: Guía básica de protección de Infraestructuras Críticas.
  5. Guía de Seguridad de Protocolos Industriales – Smart Grid

 Artículos:

  1. PRP y HSR: Protocolos redundantes.
  2. Robots y drones en la Industria 4.0.
  3. Hardware Hacking en Sistemas de Control Industrial.
  4. CrashOverride: El malware para SCI ataca de nuevo.
  5. Analizando la seguridad sin riesgos: laboratorios de pruebas.
  6. Asegurando la virtualización de tus sistema de control.
  7. Gestión de credenciales en sistemas de control.
  8. Prevención de intrusos y gestión de eventos para sistemas de control.
  9. Insider, las dos caras del empleado.
  10. Amenazas emergentes en entornos industriales.
  11. Honeypots Industriales.
  12. Gestionar el riesgo de los proveedores como propio.
  13. Seguridad en protocolos industriales – Smart Grid
  14. Criptografía para reforzar la ciberseguridad en entornos industriales.
  15. Características y seguridad en PROFINET.
  16. Analizadores de red en Sistemas de Control.
  17. Seguridad Industrial 2016 en cifras.
  18. ¿Nuevo ciberataque a la red eléctrica de Ucrania?
  19. Inventario de activos y gestión de la seguridad SCI.
  20. Líneas de actuación del Esquema Nacional de Seguridad Industrial.
  21. Protocolos Industriales: Herramientas de Seguridad.
  22. ¿Tu empresa es segura? Medir es el primer paso para conseguirlo.
  23. Atrapando sombras en la industria.
  24. Cyber Kill Chain en Sistemas de Control Industrial.
  25. DDOS de actualidad: IoT y los DNS de Dyn.
  26. Seguridad en BlueTooth: Fortalezas y debilidades.
  27. ZigBee en el laboratorio.
  28. Thinking in Big (Data) y la seguridad industrial.
  29. Seguridad desde abajo: dispositivos finales a escena.
  30. Familia de malware en la industria.
  31. Protegiéndose de BlackEnergy: Detectando anomalías.
  32. Seguridad en Comunicaciones ZigBee.
  33. BlackEnergy y los Sistemas Críticos.
  34. Desmontando Modbus.
  35. Safety y security: juntos pero no revueltos.
  36. BMS: Edificios inteligentes, ¿y seguros?
  37. Seguridad industrial 2015 en cifras.
  38. Un SCADA en la ciudad.
  39. Aplicando seguridad en WirelessHart.
  40. Sistemas de control de software libre.
  41. Arquitecturas de seguridad en la nube para la industria.
  42. Las aplicaciones de control se hacen mayores.
  43. Mi SCADA en las nubes.
  44. Evolucionando la comunicación en la industria.
  45. La Ciberseguridad en la Industria 4.0.
  46. Divide y vencerás: Segmentación al rescate.
  47. Monitorización de amenazas en SCADA.
  48. Evolucionando la infraestructura de red en SCI.
  49. Bug Bounties en SCI: Vulnerabilidades en busca y captura.
  50. El consumo eléctrico bajo control.
  51. Buenas prácticas de configuración en la red inteligente.
  52. Disciplina militar en Control Industrial: OPSEC.
  53. Auditorias en sistemas de control.
  54. Amenazas en los Sistemas de Control Industrial.
  55. Certificaciones de seguridad en sistemas de control.
  56. La evolución de los dispositivos en los sistemas de control industrial.
  57. Estándares de ciberseguridad en las redes inteligentes.
  58. BYOD en entornos industriales.
  59. IEC 62443: Evolución de la ISA 99.
  60. La seguridad de los coches inteligentes a examen.
  61. La ciberseguridad en las subestaciones y el estándar IEC 61850.
  62. Herramientas TI que evolucionan para TO.
  63. La evolución del software en los sistemas de control industrial.
  64. Diferencias entre TI y TO.
  65. Normativas de seguridad en sistemas de control.
  66. Identificación de sistemas de control industrial.
  67. Problemática de los antivirus en entornos industriales.
  68. Seguridad en Protocolos de Sistemas de Control Industrial.
  69. Del Air Gap a la Segmentación en ICS.
  70. Guía de seguridad de Sistemas de Control Industrial.
  71. La problemática de la ciberseguridad para los profesionales de los sistemas de control industrial.
  72. Protegiendo Infraestructuras Críticas: no es suficiente con medidas IT.
  73. Hacia una evaluación eficaz de la seguridad en ICS.

Otras Guías de interés:

  1. Guía de Pentest: Recolección de información (Information Gathering).
  2. Guía sobre análisis de tráfico con Wireshark.
  3. Guia de Seguridad en servicios DNS
  4. Ciber-Resiliencia: Aproximación a un marco de medición.
  5. Detección de APTs.

 

Publicaciones CERTSI e INCIBE sobre Ciberseguridad Industrial, actualizado 18/04/17.

Tanto INCIBE (Instituto Nacional de Ciberseguridad de España) como CERTSI (CERT de Seguridad e Industria) publican a menudo en sus respectivas Webs noticias, guías y artículos sobre distintas temáticas teniendo como telón de fondo la seguridad. Para esta ocasión he ordenado las referentes a Ciberseguriad Industrial, que recopilan un buen número de investigaciones, incidentes, análisis, e informes, sobre distintas temáticas.  Sin duda constituye un conjunto de referencias para el aprendizaje de todo profesional que esté o quiera desempeñarse en securización de estos entornos. Espero que os guste y sobre todo os resulte útil.

Un saludo!

Guías:

  1. Protocolos y Seguridad en SCI.
  2. Identificación y reporte de incidentes de seguridad para operadores estratégicos: Guía básica de protección de Infraestructuras Críticas.
  3. El Puesto del Operador: Guía básica de protección de Infraestructuras Críticas.
  4. Guía de Seguridad de Protocolos Industriales – Smart Grid

 Artículos:

  1. Insider, las dos caras del empleado.
  2. Amenazas emergentes en entornos industriales.
  3. Honeypots Industriales.
  4. Gestionar el riesgo de los proveedores como propio.
  5. Seguridad en protocolos industriales – Smart Grid
  6. Criptografía para reforzar la ciberseguridad en entornos industriales.
  7. Características y seguridad en PROFINET.
  8. Analizadores de red en Sistemas de Control.
  9. Seguridad Industrial 2016 en cifras.
  10. ¿Nuevo ciberataque a la red eléctrica de Ucrania?
  11. Inventario de activos y gestión de la seguridad SCI.
  12. Líneas de actuación del Esquema Nacional de Seguridad Industrial.
  13. Protocolos Industriales: Herramientas de Seguridad.
  14. ¿Tu empresa es segura? Medir es el primer paso para conseguirlo.
  15. Atrapando sombras en la industria.
  16. Cyber Kill Chain en Sistemas de Control Industrial.
  17. DDOS de actualidad: IoT y los DNS de Dyn.
  18. Seguridad en BlueTooth: Fortalezas y debilidades.
  19. ZigBee en el laboratorio.
  20. Thinking in Big (Data) y la seguridad industrial.
  21. Seguridad desde abajo: dispositivos finales a escena.
  22. Familia de malware en la industria.
  23. Protegiéndose de BlackEnergy: Detectando anomalías.
  24. Seguridad en Comunicaciones ZigBee.
  25. BlackEnergy y los Sistemas Críticos.
  26. Desmontando Modbus.
  27. Safety y security: juntos pero no revueltos.
  28. BMS: Edificios inteligentes, ¿y seguros?
  29. Seguridad industrial 2015 en cifras.
  30. Un SCADA en la ciudad.
  31. Aplicando seguridad en WirelessHart.
  32. Sistemas de control de software libre.
  33. Arquitecturas de seguridad en la nube para la industria.
  34. Las aplicaciones de control se hacen mayores.
  35. Mi SCADA en las nubes.
  36. Evolucionando la comunicación en la industria.
  37. La Ciberseguridad en la Industria 4.0.
  38. Divide y vencerás: Segmentación al rescate.
  39. Monitorización de amenazas en SCADA.
  40. Evolucionando la infraestructura de red en SCI.
  41. Bug Bounties en SCI: Vulnerabilidades en busca y captura.
  42. El consumo eléctrico bajo control.
  43. Buenas prácticas de configuración en la red inteligente.
  44. Disciplina militar en Control Industrial: OPSEC.
  45. Auditorias en sistemas de control.
  46. Amenazas en los Sistemas de Control Industrial.
  47. Certificaciones de seguridad en sistemas de control.
  48. La evolución de los dispositivos en los sistemas de control industrial.
  49. Estándares de ciberseguridad en las redes inteligentes.
  50. BYOD en entornos industriales.
  51. IEC 62443: Evolución de la ISA 99.
  52. La seguridad de los coches inteligentes a examen.
  53. La ciberseguridad en las subestaciones y el estándar IEC 61850.
  54. Herramientas TI que evolucionan para TO.
  55. La evolución del software en los sistemas de control industrial.
  56. Diferencias entre TI y TO.
  57. Normativas de seguridad en sistemas de control.
  58. Identificación de sistemas de control industrial.
  59. Problemática de los antivirus en entornos industriales.
  60. Seguridad en Protocolos de Sistemas de Control Industrial.
  61. Del Air Gap a la Segmentación en ICS.
  62. Guía de seguridad de Sistemas de Control Industrial.
  63. La problemática de la ciberseguridad para los profesionales de los sistemas de control industrial.
  64. Protegiendo Infraestructuras Críticas: no es suficiente con medidas IT.
  65. Hacia una evaluación eficaz de la seguridad en ICS.

Otras Guías de interés:

  1. Guía de Pentest: Recolección de información (Information Gathering).
  2. Guía sobre análisis de tráfico con Wireshark.
  3. Guia de Seguridad en servicios DNS
  4. Ciber-Resiliencia: Aproximación a un marco de medición.
  5. Detección de APTs.

 

LogicLocker, un ransomware para ICS

Coincidiendo con la celebración de la RSA Security Conference en San Francisco, el pasado 14 de febrero los investigadores Raheem Beyah y David Fromby del Instituto de Tecnología de Georgia (GIT, Georgia Institute of Technology) anunciaron los resultados de una Prueba de Concepto (PoC, Proof of Concept) con la que demostraban cómo se podría llegar a actuar sobre un autómata de la misma manera que lo hace un ransomware tradicional. O dicho de otra manera, podríamos estar ante la primera señal de vida de ransomware para ICS.

captura_02

Las conclusiones de su investigación han quedado reflejadas en un documento que puede ser accedido públicamente desde aquí. Tras su lectura, en el día de hoy voy a hacer un repaso del mismo, haciendo un resumen de aquellos puntos e ideas más significativas con algún que otro aporte propio. Aunque, como veréis en algunos aspectos se repite “la misma canción”.

Los autores comienzan hablando de cómo los ICS (ICS, Industrial Control Systems) están presentes en aquellas infraestructuras que regulan nuestra vida diaria como puede ser el agua, la luz o la maquinaria en empresas manufactureras. Desde la aparición de Stuxnet o la caída de suministro eléctrico en Ucrania, los ataques contra este tipo de instalaciones estaban relacionadas con el sabotaje. No han sido objetivo de organizaciones criminales con una actividad orientada al chantaje o beneficio económico ilícito. ¿Por qué? No porque los Sistemas de Control Industrial sean más seguros, sino que no se había encontrado la manera de rentabilizar de modo alguno este tipo de actividades. En un entorno corporativo (IT) el mayor valor que tiene la organización es la información. La información se convierte en el objetivo. Sin embargo, esto no es así en entornos OT. El mayor valor que tiene los sistemas ICS no es la información que tienen de la compañía. El verdadero valor radica en garantizar la disponibilidad y seguridad (safety) de las instalaciones. Los programas de los autómatas, en sí mismos, no almacenan información tan relevante para la organización como lo pueden ser las Bases de Datos, Correos Electrónicos, ficheros con planes estratégicos de la compañía, etc. Sin embargo, si se compromete, bien por cifrado o alteración el programa del PLC, la instalación no funcionará tal y como ha sido diseñada afectando claramente a la actividad de la empresa. Y esto sí tiene un impacto económico. Sin olvidarnos además de que dicha modificación puede menoscabar la seguridad de las personas (Safety) y, dependiendo de la actividad, incluso daños ecológicos.

sick-safety-switches-800x500-2-770x450

Dispositivos y mecanismo Safety. Imagen extraída de: http://www.advantageind.com/portfolio/safety-switches-controllers-and-protection/

Según esto último, por su impacto en la economía de cualquier organización, las redes industriales serán, probablemente, el próximo objetivo de este tipo de malware. Mediante este documento, los autores afirman haber desarrollado el primer ransomware conocido para PLCs, el cual ha recibido el nombre de LogicLocker. En la PoC, LogicLocker emplea las comunicaciones nativas de la API de un equipo Schneider Modicom M241 para escanear los objetivos vulnerables, en este caso PLCs Allen Bradley Micrologix 1400 y Schneider Modicom M221. Pasada esta fase, los infecta saltando los débiles mecanismos de autenticación, impidiendo a usuarios legítimos la recuperación del dispositivo. Finalmente, se plantea reemplazar el programa original con una “bomba lógica” que provoque acciones sobre los equipos físicos, daños a personas, modificación de las salidas de los autómatas, o cualquier otra si no se realiza el pago en tiempo y forma.

Aquí, conviene resaltar el perfil del atacante. Se concluye que la sofisticación de un ataque es inversamente proporcional a la frecuencia de los ataques. Esto es, los ataques de personas sin conocimientos o perfiles técnicos que reutilizan un exploit conocido, superará a los llevados a cabo por criminales profesionales con unos niveles de preparación mucho mayor y con más probabilidades de éxito, daño y alcance.

Como es sabido, el ransomware busca una rentabilidad económica de la acción, siendo el rescate mayor cuanto mayor sea la indisposición de la información o,  en el caso que nos ocupa, el impacto económico que tiene la pérdida de disponibilidad de las instalaciones.

Beneficio  = Alcance * Valor – Coste de desarrollo

Por tanto, para que un ataque dirigido a ICS sea rentable y dado que un PLC en sí mismo no almacena una información relevante, la meta es  provocar el mayor impacto sobre la operativa de las instalaciones. En esta línea, el ransomware para ICS busca afectar sobre:

Inactividad

Dependiendo de la actividad empresarial de la víctima una caída de sus sistemas de control puede tener un mayor o menor impacto. Imaginemos un fábrica de automóviles donde cada 2 – 3 minutos puede estar finalizado uno o incluso la elaboración de productos de alimenticios donde la materia prima es perecedera y que pueda darse el caso que los sistemas de refrigeración o mezcla de compuestos dejen de funcionar.

Equipamiento

Una de las características de las redes de control es la interacción con elementos físicos, con lo que cualquier manipulación o daño, como norma general, será claramente visible. Cobra especial importancia que la sustitución de estos equipos puede llegar a ser muy complicada, tanto por el reemplazo en sí como por el suministro. Pensemos en un grupo electrógeno para dar servicio en caso de caída de una línea eléctrica, y pasar a  generarla mediante combustible. Pueden pasar meses hasta que se reciba uno si el fabricante no tiene uno en stock.

Personas

En este caso el objetivo son las personas y no los dispositivos. Cuando lo que está en juego son vidas humanas, el interés y la cuantía a pagar siempre será mucho mayor. Esta es una de las lecciones aprendidas de las campañas de ransomware tradicional dirigido sobre Hospitales y Centros de salud.

portada_estudio_01

Para poder ver el efecto de LogicLocker, en cuanto a equipos se refiere, se establecieron dos líneas de trabajo. Por un lado se realizaron búsquedas con Shodan para localizar equipos vulnerables (miles según afirman) y por otro los equipos sobre los cuales se hizo la prueba de concepto. Los equipos en cuestión fueron un Schneider Modicom M221, un Allen Bradley Micrologix 1400 and Schneider Modicom M241. Para tener una idea del beneficio que pudiera darse, mediante Shodan se localizaron un total de 1400 unidades del equipo Micrologix 1400. Si éstas estuvieran en entornos donde se vieran afectadas vidas humanas (siendo más que asegurado el pago), y se solicitaría un rescate de 15.000 € por unidad, el atacante podría obtener un beneficio de 21 millones de euros en un sola operación.

En lo que se refiere a la simluación y anatomía del ataque, el mismo estaría comprendido en 4 fases:

  1. Infección inicial
  2. Movimiento lateral (opcional)
  3. Bloqueo
  4. Cifrado
  5. Negociación del rescate.

La infección inicial puede llevarse a cabo mediante el acceso remoto si el equipo está expuesto en internet o bien mediante el compromiso de otro sistema dentro de la organización y una vez dentro, lanzar el ataque contra alguno de los PLCs. Para comprometerlos, es ampliamente conocido que muchos de éstos no proporcionan medios de autenticación robusto para la carga de nuevos programas. En el mejor de los casos puede deshabilitarse la administración remota, en ese aspecto.

En lo referente al movimiento lateral, el objetivo es comprometer tantos equipos como sea posible. De esta manera el atacante aseguraría un mayor éxito no sólo por la cuantía sino por la certeza del pago. Si solamente se comprometiese uno, sería fácil su sustitución siempre y cuando se tenga el programa correspondiente. Si el compromiso es de varios, ya la posibilidad se ve reducida con lo que al estudiar el impacto que pudiera tener, se optaría por el pago y restaurar la disponibilidad tan pronto como sea posible.

En cuanto al bloqueo del PLC, existen varias opciones. La más sencilla, si dispone de ella, es la configuración de una contraseña de acceso lo más compleja posible. Sin embargo la contraseña de autenticación de muchos PLCs solamente es comprobada en el software del entorno de programación, no en el PLC. Así pues, este mecanismo destinado a la protección el PLC “victima” en realidad impide la recuperación por usuario legítimo no siendo una verdadera protección contra el atacante una vez haya sido comprometido. Sin embargo, como decíamos al principio, si la autenticación se produce del lado del PLC (es éste quién la solicita y no el software al abrir el proyecto) y quisiéramos encontrarla mediante un proceso de autenticación online por fuerza bruta, resultaría inviable debido a la gran cantidad de tiempo necesario aun cuando posea una longitud, de tan sólo, 6 dígitos. Ya por último, se plantea la idea del bloqueo mediante el número de conexiones TCP activas. Algunos PLC tienen un número máximo de ellas, por tanto, el atacante podría hacer uso de todas ellas según el medio elegido.

Incluso si la víctima pudiera recuperar el acceso para reprogramar el PLC, saltandose así las técnicas de bloqueo llevadas a cabo por el atacante, éste podría llevar a cabo otras teniendo en cuenta el cifrado el programa. La más sencilla es cifrar el original por parte del atacante y enviárselo al usuario legítimo. Una vez efectuado el pago, el atacante le facilitaría la herramienta con la que descifrar el programa y poderlo carga de nuevo sobre el PLC. Una segunda que se plantea es, nuevamente el cifrado del programa, pero esta vez almacenarlo en una zona de memoria del PLC. Sin embargo, esto puede no ser viable debido a que algunos PLCs no poseen cantidad suficiente como para ser guardado allí. Finalmente se plantea el tercero de los casos, en lo que estudia la posibilidad de codificar el propio programa en el PLC estableciendo una llave secreta de tal manera que de forma aleatoria se fuera cambiando el contenido del programa. La idea es llevar a cabo una serie de acciones sobre el programa original teniendo como variable dicha “llave secreta” para luego, una vez efectuado el pago, poder revertir el proceso en sentido contrario. No obstante, se corre el riesgo de poder desencadenar un funcionamiento impredecible, así como la nula capacidad para recuperar el programa original.

Como último paso nos quedaría la negociación para el pago del rescate. La forma más sencilla es el envío de un correo electrónico solicitando a la víctima el pago correspondiente aunque, también puede hacerse uso de los clientes de correo electrónico que tienen algunos dispositivos para el envío de alertas a los operadores, dando así una sensación de fortaleza y control mayor. Para reforzar esta idea, pueden verterse amenazas de destrucción del equipamiento conectado mediante la alteración de las instrucciones, a partir de una identificación previa.

Dicho lo cual, llega la hora de explicar cómo se ha llevado a cabo dicha prueba de concepto. Se parte de la idea en la que un atacante ha sido capaz de obtener la contraseña de acceso del equipo Modicon M241, bien por fuerza bruta o por el robo de las credenciales. Con ellas, LogicLocker procede a escanear la red para localizar más equipos vulnerables e infectarlos más adelante. En esa acción procede al bloqueo de Modicom M221 y Micrologix 1400 reprogramándolos con nuevas contraseñas impidiendo el acceso a usuarios legítimos con el software de programación. Para la fase de cifrado se procede a cifrar el programa original y notificar a la víctima mediante el envío de un correo electrónico. Una vez realizado el pago, el atacante enviará un software con el que podrá obtener el programa original, pero en caso contrario, modificará el comportamiento de los PLC para verter cantidad excesivas de cloro dentro del suministro de agua.

Ya en la parte final se establecen las medidas para defenderse y prevenir este tipo de ataques. Obviamente una estrategia “Air-gap” ya no es sinónimo de seguridad sino que se debe apostar por una basada en “Defensa en Profundidad”. Aquí es donde me refería con mi apunte que se repite “la misma canción”.

En el documento se cita a 3 líneas:

  1. Seguridad de Endpoint
  2. Seguridad de red
  3. Políticas

En cuanto a la primera de ellas se habla de medidas tales como cambiar contraseñas por defecto, deshabilitar servicios que no están en uso, emplear ACLs, y otras tantas a las que ya estamos acostumbrados. Pero sobre todo considerar característica de seguridad en lo nuevos productos que se adquieran. Algunos artículos escritos al respecto:

La seguridad en la red resulta indispensable. Se hace hincapié en la separación de los entornos tanto IT como OT realizando un control de los protocolos en el firewall que los separa. Puesto que cualquier cambio en entornos de control ha de realizarse de forma programada y son poco habituales, dicha monitorización facilitará la detección de anomalías en la red. Al margen de ello resulta indispensable disponer de un sistema de backups para restaurar las configuraciones y no tener pagar rescate alguno.

Por último, llegamos a las Políticas. Aquí el objetivo son los usuarios finales, quienes deben estar formados sobre los riesgos que pueden acarrear sus acciones. Además, los entornos de control y automatización no sólo deben disponer de un plan de contingencia ante posibles incidentes sino llevar a cabo también tareas de recuperación en un entorno controlado. Ni qué hablar sobre la implicación de la directiva, equipos de trabajo multidisciplinares y creación de nuevos Roles dentro de la organización.

Así llegamos a un apartado donde se detallan las conclusiones finales. Las redes industriales no han sido objeto de ataques de ransomware ya que los cibercriminales no han encontrado el modelo para obtener un beneficio económico de sus acciones. Con la llegada de este malware que afecta, no a equipos con una arquitectura basada en PC sino a dispositivos de control, se abre una nueva línea; la extorsión. Los recientes ataques a hospitales demuestran lo rentable que puede llegar a ser este malware cuando lo que está en juego son vidas o consecuencias sobre personas. A esto hay que sumar lo débiles, o poco prácticas, que pueden llegar a ser las medidas de autenticación existentes frente a este tipo de ataques. Por tanto resulta inevitable el despliegue de una estrategia de “Defensa en Profundidad” que contemple a la seguridad desde el inicio, y en aquellas ya existentes la toma de medidas que prevengan cualquier actuación hostil que ponga en peligro la disponibilidad de las instalaciones y las vidas humanas.

En cualquier caso, para ataques o accidentes, la creación de un sistema de copias de respaldo tanto de configuraciones, software o firmware debe ocupar un lugar indispensable dentro de las políticas de seguridad de la empresa. Y es que: “Garantizar la disponibilidad no sólo es reducir los riesgos de sufrir un ataque, sino que si lo tenemos poder recuperarnos en el menor tiempo posible”. Y si es gratis, mejor.

Un saludo.

Nos vemos en la próxima!

Publicaciones CERTSI e INCIBE sobre Ciberseguridad Industrial, actualizado 16/02/17.

Tanto INCIBE (Instituto Nacional de Ciberseguridad de España) como CERTSI (CERT de Seguridad e Industria) publican a menudo en sus respectivas Webs noticias, guías y artículos sobre distintas temáticas teniendo como telón de fondo la seguridad. Para esta ocasión he ordenado las referentes a Ciberseguriad Industrial, que recopilan un buen número de investigaciones, incidentes, análisis, e informes, sobre distintas temáticas.  Sin duda constituye un conjunto de referencias para el aprendizaje de todo profesional que esté o quiera desempeñarse en securización de estos entornos. Espero que os guste y sobre todo os resulte útil.

Un saludo!

Guías:

  1. Protocolos y Seguridad en SCI.
  2. Identificación y reporte de incidentes de seguridad para operadores estratégicos: Guía básica de protección de Infraestructuras Críticas.
  3. El Puesto del Operador: Guía básica de protección de Infraestructuras Críticas.

 Artículos:

  1. Características y seguridad en PROFINET.
  2. Analizadores de red en Sistemas de Control.
  3. Seguridad Industrial 2016 en cifras.
  4. ¿Nuevo ciberataque a la red eléctrica de Ucrania?
  5. Inventario de activos y gestión de la seguridad SCI.
  6. Líneas de actuación del Esquema Nacional de Seguridad Industrial.
  7. Protocolos Industriales: Herramientas de Seguridad.
  8. ¿Tu empresa es segura? Medir es el primer paso para conseguirlo.
  9. Atrapando sombras en la industria.
  10. Cyber Kill Chain en Sistemas de Control Industrial.
  11. DDOS de actualidad: IoT y los DNS de Dyn.
  12. Seguridad en BlueTooth: Fortalezas y debilidades.
  13. ZigBee en el laboratorio.
  14. Thinking in Big (Data) y la seguridad industrial.
  15. Seguridad desde abajo: dispositivos finales a escena.
  16. Familia de malware en la industria.
  17. Protegiéndose de BlackEnergy: Detectando anomalías.
  18. Seguridad en Comunicaciones ZigBee.
  19. BlackEnergy y los Sistemas Críticos.
  20. Desmontando Modbus.
  21. Safety y security: juntos pero no revueltos.
  22. BMS: Edificios inteligentes, ¿y seguros?
  23. Seguridad industrial 2015 en cifras.
  24. Un SCADA en la ciudad.
  25. Aplicando seguridad en WirelessHart.
  26. Sistemas de control de software libre.
  27. Arquitecturas de seguridad en la nube para la industria.
  28. Las aplicaciones de control se hacen mayores.
  29. Mi SCADA en las nubes.
  30. Evolucionando la comunicación en la industria.
  31. La Ciberseguridad en la Industria 4.0.
  32. Divide y vencerás: Segmentación al rescate.
  33. Monitorización de amenazas en SCADA.
  34. Evolucionando la infraestructura de red en SCI.
  35. Bug Bounties en SCI: Vulnerabilidades en busca y captura.
  36. El consumo eléctrico bajo control.
  37. Buenas prácticas de configuración en la red inteligente.
  38. Disciplina militar en Control Industrial: OPSEC.
  39. Auditorias en sistemas de control.
  40. Amenazas en los Sistemas de Control Industrial.
  41. Certificaciones de seguridad en sistemas de control.
  42. La evolución de los dispositivos en los sistemas de control industrial.
  43. Estándares de ciberseguridad en las redes inteligentes.
  44. BYOD en entornos industriales.
  45. IEC 62443: Evolución de la ISA 99.
  46. La seguridad de los coches inteligentes a examen.
  47. La ciberseguridad en las subestaciones y el estándar IEC 61850.
  48. Herramientas TI que evolucionan para TO.
  49. La evolución del software en los sistemas de control industrial.
  50. Diferencias entre TI y TO.
  51. Normativas de seguridad en sistemas de control.
  52. Identificación de sistemas de control industrial.
  53. Problemática de los antivirus en entornos industriales.
  54. Seguridad en Protocolos de Sistemas de Control Industrial.
  55. Del Air Gap a la Segmentación en ICS.
  56. Guía de seguridad de Sistemas de Control Industrial.
  57. La problemática de la ciberseguridad para los profesionales de los sistemas de control industrial.
  58. Protegiendo Infraestructuras Críticas: no es suficiente con medidas IT.
  59. Hacia una evaluación eficaz de la seguridad en ICS.

Otras Guías de interés:

  1. Guía de Pentest: Recolección de información (Information Gathering).
  2. Guía sobre análisis de tráfico con Wireshark.
  3. Guia de Seguridad en servicios DNS
  4. Ciber-Resiliencia: Aproximación a un marco de medición.
  5. Detección de APTs.

 

Prácticas recomendadas para estrategias DiD por ICS-CERT

El pasado mes de setiembre el ICS-CERT  publicó un documento sobre un conjunto prácticas recomendadas para mejorar la seguridad en Sistemas de Control Industrial basándose una estrategia de Defensa en Profundidad (DiD, Defense in Depth). Se trata de una guía práctica para desarrollo de estrategias especificas que mitiguen las amenazas que acechan a dichos sistemas.

portada-documento-01

Dicho documento se puede descargar desde el siguiente enlace. No obstante si se quiere hacer podéis acudir la página web:

unnamed

El documento comienza haciendo una exposición de las características de los Sistemas de control Industrial, para luego introducirse en la evolución de las comunicaciones dentro de las Tecnologías de Operación, OT.

Aclarados estos dos puntos, se continúa con el concepto de Defensa en Profundidad, DiD (Defense in Depth), sus orígenes, razón de ser y planificar su desarrollo.

Aquí encontramos una tabla muy interesante donde se hace una comparativa entre las distintas medidas aplicables a entornos IT, OT y lo que ello conlleva. Cuando vemos la necesidad de proteger es porque entendemos que existe un riesgo y una amenaza. Para entender mejor lo que más adelante se explica, os dejo un par de artículos donde hablo de las Amenazas sobre ICS que espero os sean de ayuda.

Amenazas sobre ICS, Parte I

Amenazas sobre ICS, Parte II

Metido de lleno en lo que a DiD se refiere, nos ofrecen un resumen donde se detallan todos los apartados y subapartados de los que se compone como son y que más tarde irá abordando de una manera más concreta.

1.- Risk Management Program
a) Identify Threats
b) Characterize Risk
c) Maintain Asset Inventory

2.- Cybersecurity Architecture
a) Standards/ Recommendations
b) Policy
c)Procedures

3.- Physical Security
a) Field Electronics Locked Down
b)Control Center Access Controls
c)Remote Site Video, Access Controls, Barriers

4.- ICS Network Architecture
a) Common Architectural Zones
b)Demilitarized Zones (DMZ)
c)Virtual LANs

5.- ICS Network Perimeter Security
a) Firewalls/ One-Way Diodes
b)Remote Access & Authentication
c)Jump Servers/ Hosts

6.- Host Security
a) Patch and Vulnerability Management
b)Field Devices
c)Virtual Machines

7.- Security Monitoring
a) Intrusion Detection Systems
b)Security Audit Logging
c)Security Incident and Event Monitoring

8.-Vendor Management
a) Supply Chain Management
b)Managed Services/ Outsourcing
c)Leveraging Cloud Services

9.- The Human Element
a) Policies
b)Procedures
c)Training and Awareness

Como decía, luego hace un repaso y análisis por cada uno de ellos acompañándose de gráficos y tablas que muchas veces represetan de una manera más fácil y sencilla lo dicho con palabras. No obstante, a muchos os suenen ya que son concepto ya tratados en otros estándares y buenas prácticas, como NIST 800-82, IEC 62443 y modelos como ISA-95.

A continuación tendremos un tercer apartado sobre ataques sobre ICS, algo que no cambia demasiado con lo que ya sabemos del mundo IT, Reconocimiento, Ataque e Intrusión. A lo que añadiría, “mantener el acceso”. Ahora bien, otra cosa muy distinta son los objetivos que se pretenden, por ejemplo, el robo de información (IT)  o el sabotaje (OT). Hace unos meses escribí una entrada sobre “Vectores de Ataque”, os la dejo por si queréis echarle un vistazo:

Vectores de Ataque en ICS.

Para concluir, se hacen unas recomendaciones como establecer un modelo de seguridad proactivo; implementación de modelos específicos según sector; revisión periódica de arquitectura y diseño del plan; evaluación de riesgos; etc.

proactive-security-model-01

Como vemos es un documento práctico, sencillo que recoge los conceptos clave que luego habrá que desarrollar de una manera más específica sobre el tipo de sector y organización, pero que narra muy bien desde un punto de vista genérico las bases sobre las que deben apoyase. Aquí conviene referirse en otros estándares y buenas prácticas existentes que citaba en párrafos anteriores.

Lo dicho, nada de “Air Gap” y a seguir con “Defensa en Profundidad”. Es lo que toca.

Un saludo, nos vemos en la próxima!

Irongate, al descubierto un nuevo malware para ICS.

El pasado 2 de junio, desde FireEye nos anunciaban los resultados del informe elaborado por  su “FireEye Labs Advanced Reverse Engineering (FLARE)”.

FireEye 01

Según nos cuentan, este grupo de trabajo a finales de 2015 identificó varias versiones de un malware dirigido a Sistemas de Control Industrial, ICS; con la capacidad de manipular procesos específicos dentro de un entorno simulado con dispositivos del fabricante Siemens. Decidieron llamarlos, IRONGATE.

La gente de FLARE encontró las muestras en Virustotal mientras investigaban ejemplares compilados con PyInstaller, algo empleado en otras ocasiones. Éstas destacaban por sus referencias a los sistemas SCADA y funcionalidades asociadas. Dos de ellas, contenían un payload subido desde distintos orígenes en 2014 pero ninguno de los antivirus lo detectó como malicioso.

Por otro lado, el CERT de productos de Siemens (Siemens Product Computer Emergency Readiness Team, ProductCERT), confirmó que IRONGATE no es viable contra sistemas, de control de Siemens, ni tampoco explotar ninguna vulnerabilidad en productos de este fabricante. No se puede hablar entonces de que exista una campaña de infección ni que suponga una amenaza, por lo que la conclusión más probable es que se trate de una prueba de concepto o una investigación sobre técnicas de ataque contra ICS.

El análisis concluye que IRONGATE aplica conceptos ya vistos en Stuxnet pero en un entorno simulado. Así pues, dado que la información sobre malware dirigido a sistemas ICS y SCADA es menor en comparación con otros ámbitos, es que han decidido compartir los detalles con la comunidad.

Vayamos con los aspectos técnicos.

Una de las características de IRONGATE es la de llevar a cabo un MiTM contra los procesos de entrada y salida I/O del PLC y el software del equipo que interactúa con el ICS dentro del proceso simulado. El malware reemplaza una DLL (Dynamic Link Library) con otra maliciosa convirtiéndose en intermediario entre la estación de monitorización y el PLC. Esta DLL registra cinco segundos de tráfico “normal” desde el PLC a la interfaz de usuario para reproducirla mientras manda de vuelta tráfico distinto al PLC. Esto podría permitir a un atacante alterar un proceso sin que el operador lo sepa.

La segunda característica a destacar es la capacidad para la evasión de Sandboxes. Algunas muestras del malware no se ejecutaban si se corrían sobre entornos VMWare o Cuckoo Sandbox. El malware usas estas técnicas para evitar la detección y resistir al análisis. La implementación de estas técnicas denota que el autor quería evitar su detección y por tanto estamos ante una aplicación maliciosa en contra de una aplicación legítima.

Cuckoo Sandbox

Finalmente, se averiguó que las distintas muestras estaban compiladas con PyInstaller, algo similar a lo empleado en otras ocasiones. Además se localizaron strings que contenían el término “payload”, también bastante común y asociado a otras piezas de malware.

IRONGATE no es comparable con Stuxnet en términos de complejidad, capacidad de propagación o implicaciones geopolíticas, sin embargo sí que comparten ciertas características y técnicas empleadas por éste como pueden ser:

  1. Ambos buscan un propósito específico.
  2. Ambos reemplazan DLLs para alcanzar manipulación de los procesos.
  3. IRONGATE detecta la observación/detección de malware mediante Sandoboxes o entornos virtuales, mientras que Stuxnet buscó la presencia de software Antivirus.
  4. IRONGATE graba y devuelve datos de proceso con el fin de ocultar las manipulaciones que introduce, mientras que Stuxnet si bien no intentaba esconderse de igual forma, si afectaba al funcionamiento de los autómatas S7-315 si ciertos valores representados en el HMI eran de carácter estático.

Por otro lado, no se ha identificado la forma de propagación, y probablemente no exista ya que se considera dicho malware aparenta ser parte de un proyecto de investigación, herramienta de pentesting o un desarrollo para testear un producto de Sistemas de Control Industrial. Esto puede interpretarse que estamos ante un suceso aislado, lo cual no significa que en un futuro pueda sofisticarse y representar una amenaza.

SANS 01

La parte principal de código ha sido escrito en Python e identificado en VirusTotal. Al parecer se hizo llegar a la citada plataforma de forma manual por medio de la interfaz Web. Esto, junto con la idea de que está dirigido a un entorno simulado, subido a un recurso público y que el malware no haya sido liberado, afirma la idea que se trate efectivamente de una prueba de concepto o una demo para algún producto concreto. Es difícil creer que alguien quiera llevar a cabo una APT contra ICS suba de forma manual a la citada Web algo tan sofisticado y más con los antecedentes de Stuxnet.

Aunque no suponga una amenaza, no podemos quitar importancia al hallazgo. Este hecho pone de relevancia que atacantes o personas con conocimientos específicos, están cada vez más preparados y con mayores capacidades para desarrollar código más elaborado, inteligente y posiblemente más destructivo de lo que fueron Stuxnet, HAVEX o BlackEnergy2. Lo cierto es que según afirman varias fuentes, las muestras de IRONGATE no fueron detectadas por ninguno de los motores antivirus, con lo que pone en evidencia la capacidad de éstos para detectar malware dirigido contra Sistemas de Control Industrial. En parte, claro está, porque se trata de una novedad frente a los ya conocidos.

SANS 02

Muchos responsables se estarán preguntando cómo protegerse de algo que muchas herramientas no han sido capaces de hacerlo por nosotros. Esto pone de relevancia que no podemos delegar en nuestras herramientas toda la responsabilidad de la protección. Obviamente debemos contar con ellas para securizar nuestras instalaciones, aparte de tener implementar unas políticas y estrategias debidamente establecidas, asentadas y sobre todo que se cumplan a rajatabla, pero no depositar confianza ciega. Las organizaciones deben contar con profesionales especializados en la materia, que entiendan las características de la Industria y la protección de Infraestructuras Críticas, muy distinto al tradicional mundo IT. Expertos que entiendan las nuevas necesidades, tiempos, tendencias, vectores y amenazas que están por llegar y que según indican las estadísticas van al alza.

En cualquiera de los casos todos debemos estar atentos con lo que está por venir, que como ya sabemos, va a seguir dando de qué hablar.

Un saludo!

Mas Información:

Enlace 1

Enlace 2

Enlace 3

Enlace 4

Enlace 5