¡Estrenamos cuenta en Twitter!

Con el objetivo cumplido para este 2017 y con ánimo de seguir llegando a más y más público, a partir de hoy está disponible bajo @enredandoconred nuestra cuenta en Twitter.

Diariamente se producen una buena cantidad de noticias, artículos, eventos, informes,  o textos relacionados con la Ciberseguridad en sistemas ICS/SCADA, Infraestructuras Críticas y demás Tecnologías de Operación. Por ello hemos visto que una buena iniciativa es redistribuir de forma rápida cualquier contenido interesante.

Así pues, os animamos a que nos sigáis y comencéis a recibir los tweets que vayamos publicando.

¡Un abrazo!

Edorta

¡Objetivo cumplido, muchas gracias!

No pensaba que a esta altura del año iba a escribir una entrada como la de hoy, pero para mi alegría así es. Y es que estoy de celebración.

Allá por el mes de diciembre del 2016 os contaba cómo, no sólo había superado las 30.000 visitas, sino que se había alcanzado la cifra de 32.378. A partir de ahí, el deseo de superar esa cifra para 2017.  Y con esa idea arrancamos el año.

Pues bien, hoy a punto de comenzar setiembre… ¡ya la hemos alcanzado!

Estadísiticas agosto 2017_01

Esto supone una gran alegría y estímulo ya que revela cómo año tras año este número crece, poniendo de manifiesto la cantidad de internautas, profesionales, investigadores y demás público, buscan, requieren o interesa el contenido relacionado con la Ciberseguridad Industrial.

Y como no podía ser de otra manera, me gustaría dar las gracias. Gracias a todos aquellos contactos y miembros de redes sociales como LinkedIn o Twitter por haber “recomendado”, “compartido” o “retuiteado” alguno de los artículos que por esas vías he ido anunciando. Por supuesto, también a los visitantes que a través de sus búsquedas han dado con el blog parándose a leer lo que allí había. A todos aquellos que de una manera u otra lo han hecho posible, ¡GRACIAS!

Representación 2017_01

Por otro lado también quisiera, además de agradecer, reconocer. Por un lado al Centro de Ciberseguridad Industrial por contribuir a la difusión de artículos haciendo referencias en su Boletín Semanal de todos los lunes. A José Valiente y Miguel García-Menéndez, muchas gracias.  Por otro, al blog Fortixpert, por incluir en su web posts donde se hablaba de funcionalidades de equipos Fortinet para cubrir las necesidades de protección en entornos industriales.  A Jose Luis Laguna, muchas gracias. A mi compañero Antonio Navarrete por abrirme las puertas a eventos y profesionales que han contribuido la difusión del blog. Como no, a Jon Bueno por las oportunidad de trabajar y aprender con él y de él, en el desarrollo del proyecto de Ciberseguridad Industrial en la fábrica de Mercedes-Benz sita en Vitoria-Gasteiz. Por último a Unai Gómez, quien con sus comentarios y aportes me han hecho ver algunos aspectos del blog en los que no había parado. A todos, ¡MUCHAS GRACIAS!

Con esta meta alcanzada, ahora queda ir pensado en los objetivos para el 2018. Quizás sea un poco pronto, pero ya estamos poniendo a echar a andar la maquinaria de cómo introducir novedades y otros apartados de interés.

Un saludo a todos, nos vemos en la siguiente y no te olvides que puedes seguirnos tambieén en @enredandoconred .

¡Un abrazo!

Edorta

Controlando nuestros Proveedores, Parte II.

Hola de nuevo. Siguiendo con la entrada anterior “Controlando nuestros Proveedores, Parte I” en el día de hoy vamos a ver la manera en cómo trabaja el binomio FortiGate + FortiClient.

Si bien la protección es en tiempo real, al hacer un análisis antivirus vemos la forma en la que detecta malware según la base de firmas del fabricante. Para ver su funcionamiento he dejado en el escritorio un fichero de EICAR.

Escritorio Proveedor_01

No obstante, para que no fuese un típico ejemplo, también tenía una carpeta con el software incluido en el repositorio Pengowin y que desde aquí, dicho sea de paso, recomiendo dicho proyecto.

Aviso de virus_01

Viendo los logs:

Logs de Virus_01

en total fueron 55 detecciones:

Registro de Virus_02

Para terminar la desinfección es posible que se solicite un reinicio del sistema.

Captura_02_Tras Finalizar AV

Como se puede ver, también en el escritorio tenía el simulador del protocolo S7 de SIEMENS, Snap7 del que hablaba en la entrada “Snap7 suite de PLCs y comunicaciones Siemens”. Al ejecutar el cliente para hacer una lectura del supuesto PLC, esto es “clientdemo.exe”, como el protocolo “ICMP” y “S7 Protocol” no están permitidos vemos su bloqueo, al igual que otros relacionados con el sistema operativo.

Aplicaciones Bloqueadas_02

Si actualizásemos el perfil del control de aplicación correspondiente, ya podríamos acceder al mismo, en la IP 192.168.0.1.

Cliente SNAP7_01

También disponemos de un “Filtro Web”, funcionalidad que no he utilizado pero también útil si necesitamos tener acceso a una interfaz Web. ¡Ojo! Hablo de equipos locales, no accesos a Internet.

Como decía en el post anterior es compatible con los “Security Profiles” configurables en cada una de las reglas del Firewall, con lo que a nivel de red también podríamos ejercer un control adicional. Configurar los perfiles de qué se puede ejecutar, o no, en un PC puede llegar a ser complejo y laborioso en función de cada proveedor. Con lo que llegado el momento, podríamos llegar a ser más permisivos en este sentido en cuanto a consentir toda la categoría “Industrial” o “Servicios de RED” y denegar “Botnet”, “Game”, “P2P”, etc. y luego apoyarnos en reglas y “Security Profiles” como indicaba en las entradas:

También destacar la visibilidad que podemos tener desde el Fortigate a la hora de monitorizar los FortiClients conectados y de si cumplen, o no, con las políticas establecidas. Para ello deberemos ir a “Monitor – FortiClient Monitor”.

Forticlient Monitor_01

Ya por último comentar que en este caso hemos hecho uso de un Firewall Fortigate para la gestión de los endpoint. Sin embargo, Fortinet dispone de un producto específico para la gestión de este software denominada FortiClientEMS (Enterprise Management Server) con lo que podremos realizar un control centralizado y una gestión más pormenorizada de todos ellos.  Aquí os dejo un video presentación y enlaces con información al respecto.

Integración de Fortigate y FortiClientEMS.

Como hemos visto nuestros proveedores pueden ser no sólo un punto de entrada sino también el origen de un problema mucho mayor. Los habrá que sean estrictos con el uso de sus equipos sin embargo, esto no es razón para pensar que nada malo pueda suceder. Los entornos industriales no son para nada similares a los de Oficina o IT tradicionales. Los ciclos de vida son mayores con lo que la posibilidad de encontrarnos con Sistemas Operativos y Hardware viejo u obsoleto, es bastante común. Con ello, falta de soporte del fabricante y vulnerabilidades incapaces de corregir, y aun existiendo parches, según actividad de la compañía, desarrollos de software propios, o cierre, hacen que muchas veces sea inviable. A esto hay que sumar la existencia de empresas proveedoras de servicios que necesitan conectarse a nuestras instalaciones para llevar a cabo las tareas para las cuales han sido contratadas, y que no hace posible desplegar su software sobre otro equipo de la organización en el que sí tenemos control y conocimiento de su estado.

Con esta entrega hemos visto cómo con los NGFW FortiGate y endpoint FortiClient podemos llevar a cabo un control y permitir qué equipos de terceros puedan conectarse a nuestra red. De esta manera reducimos los riesgos  de que algo, o alguien, pueda comprometer la disponibilidad de nuestras instalaciones. No pretende ser un manual, ni mucho menos, sino una visión sobre de qué manera podemos ejercer dicho control y supervisión.

Obviamente existen en el mercado otros fabricantes, con otras soluciones que de igual manera puedan satisfacer nuestras necesidades, pero resulta interesante ver esta en concreto por su integración junto con el hardware de red. Como hemos visto, desde hace relativamente poco tiempo, los fabricantes de equipos de control y automatización tipo SIEMENS, Phoenix Contact, entre otros, incluyen ya características relacionadas con la Ciberseguridad, cosa con los equipos más antiguos o bien, o no disponen o son débiles. Por tanto, delegar en la electrónica de red y seguridad perimetral aspectos de la seguridad sigue siendo un hecho que durará por mucho tiempo ya que la renovación de PLCs, Robots, o cualquier otro por motivos puramente de seguridad, no es una razón de peso o prioridad.

Un saludo a todos, nos vemos en la siguiente y no te olvides que puedes seguirnos también en @enredandoconred .

Edorta

 

Controlando nuestros Proveedores, Parte I.

Hace unos días hablaba acerca de la necesidad de gestionar los proveedores externos e incluirlos en nuestras políticas de seguridad, claro está, orientadas a su actividad. Muy particularmente en grandes corporaciones, éstas se ven obligadas adquirir a terceros equipos, productos y servicios especializados para la actividad de la misma. Luego, cara a garantizar una respuesta o asesoramiento, firman contratos de soporte con el fin de obtener ayuda en caso de ser necesario. Como veíamos en la entrada “Proveedores Externos, posible punto de entrada…” ha de establecerse un procedimiento tanto administrativo como técnico que regule cómo han de conectarse y qué requisitos deben reunir sus equipos antes, durante y después de conectarse a nuestra red de control.

A diferencia del post que citaba anteriormente, hoy hablaré sobre cómo podemos controlar técnicamente dichos equipos. Es un ejemplo, obviamente no dará respuesta a todas las necesidades ni a todas las casuísticas que sin duda serán muy particulares dependiendo de tecnologías, industrias, equipos, actividad, o cualquier otro factor.

El objetivo será llevar a cabo un control sobre el PC de un proveedor que necesariamente ha de conectarse, sí o sí, a nuestra red OT para llevar a cabo tareas de soporte o mantenimiento. Estos PC contendrán el software necesario sin embargo, no tendremos ni su control, ni conocimiento alguno del estado de actualización de sistema operativo, aplicaciones; firmas antivirus (si las hubiera); vulnerabilidades; etc. etc. Habrá quien piense que una alternativa pueda ser instalar las herramientas en PCs de la propia organización sobre los que sí tendríamos aquello que ahora nos falta. No le quito razón, sin embargo, la realidad nos muestra una serie de inconvenientes:

  1. Coste de licenciamiento de Software. ¿Nueva instalación, nueva licencia? ¿reasignación de licencias?
  2. Necesidad de probar aplicaciones en PCs de la organización para garantizar pleno funcionamiento.
  3. Dada el ciclo de vida mayor, probabilidad de uso en Sistemas Operativos con distintas versiones.
  4. Desarrollo de herramientas a medida y bajo condiciones concretas, diferentes a los empleados en la organización.

Por tanto, con todo en contra, lo que sí podríamos hacer es obligar a nuestros proveedores a cumplir nuestras normativas y marcarles las vías de cómo hacerlo. De hecho, es algo que las políticas de seguridad deben contemplar. Me refiero a que una vez implementadas todas las herramientas y medidas, todo nueva sistema, instalación o equipo debe cumplir con aquello especificado para el nuevo “ciberseguro” escenario. Para algo lo hemos hecho, ¿no?

Para ello emplearemos la aplicación endpoint FortiClient de Fortinet con el que podremos identificar y remediar equipos vulnerables, o comprometidos, reduciendo así la superficie de ataque. Luego podremos integrarlo en otras soluciones del mismo fabricante, aspecto que no abordaremos en este post.

Para la Prueba de Concepto he creado el siguiente ejemplo:

Como vemos en la figura, un proveedor ha de conectarse a la red Control para llevar a cabo determinadas tareas. Tiene dedicada una VLAN con un direccionamiento 192.168.254.0/24 a la que deberán conectarse todos los equipos de proveedores. Así pues, todas las comunicaciones deberán pasar por el Firewall (NGFW) que bien podría ser el de Separación o de Segmentación dependiendo de cómo tenga definida la arquitectura la organización. Luego, en función de cómo configuremos el mismo, dejaremos pasar el tráfico necesario hacia la red 192.168.0.0/24, esto es, la de Control.

Para ello emplearé la versión 5.4.4 de FortiClient y un equipo FortiGate 61E con FortiOS 5.4.5.

Lo primero que deberemos hacer será definir una subred, VLAN para nuestros proveedores y que el Gateway, por ejemplo, sea el Fortigate.

En ella deberemos habilitar por un lado la detección de Dispositivos y el control de acceso basado en Forticlient. Ni qué decir que desde la red de proveedores no puede existir la posibilidad de acceso a los Firewalls….

El siguiente paso será definir qué Aplicaciones vamos a dejar permitir ejecutar a los proveedores en sus equipos. Para ello deberemos ir a “Security Profiles – Application Control” y definir uno con los parámetros que creamos convenientes. Os dejo dos entradas que os pueden orientar en las que hablaba de esto mismo:

Con ello listo, iremos a “Security Profiles – FortiClient Profiles” y crearemos el que a posteriori será el que se aplicará sobre los endpoints.

Allí deberemos especificar algunos parámetros como: la red sobre la que se aplicará, en nuestro caso la 192.168.254.0/24, “LAB_RED PROVEEDORES”; acción en caso de no cumplimiento, “Block – Warning – Auto-update”; el tipo de dispositivo, “ALL”; Versión mínima del software FortiClient, “5.4.1”; comportamiento del motor Antivirus, “Realtime Protection, Up-to-date signatures”; y por último el perfil de Firewall de Aplicación, el que hemos definido anteriormente, “LAB_APP-CONTROL_S7”.

Aquí quizás puede llevarnos a confusión el concepto de Control de Aplicación, pero que en este caso se aplica de dos maneras distintas. Una cosa es el Control de Aplicación que se  ejecuta sobre las aplicaciones del PC y que lo regula en el endpoint FortiClient; y otro distinto el que podemos aplicar sobre el tráfico de red en cada una de las reglas configuradas y definidas dentro de la columna “Security Profiles”.

Si en estos instantes alguien quisiera acceder a algún recursos de la red no podría ya que no cumple con los requisitos. Si por ejemplo abriésemos un navegador y pretenderíamos navegar aparecería el siguiente mensaje:

La instalación del endpoint es sencilla. Lo único que tendremos que tener en cuenta es realizar una instalación completa, en lugar de sólo la funcionalidad de VPN. Una vez finalizada se comenzará a descargar los distintos componentes.

Si abrimos el cliente veremos una pantalla con los distintos apartados del endpoint.  Si nos fijamos a “Firewall de Aplicación” veremos los “Overrides” autorizados relacionados con el protocolo S7.

Hasta aquí hemos visto la manera en la que configuramos, de forma resumida, todo lo necesario para comenzar a ejercer el control del que hablábamos. Con todo listo, será en la próxima entrada, cuando comprobemos los resultados y por tanto su eficiencia.

Un saludo a todos, nos vemos en la siguiente y no te olvides que puedes seguirnos también en @enredandoconred .

Edorta

 

Proveedores Externos, posible punto de entrada… 

Como bien sabemos la seguridad no es algo que se acaba con la implementación de un conjunto de medidas técnicas y la definición de unas políticas que prevengan que algo o alguien cause un daño en nuestra organización. En el caso concreto de los entornos industriales, esto además puede repercutir no sólo en un punto de vista lógico sino además afectar en los elementos físicos de las instalaciones.

A la hora de llevar a cabo un proyecto se ha de realizar un análisis de riesgos que evalúe y cuantifique el nivel en el que una organización está expuesta a sufrir un incidente de seguridad considerando, entre otros, las amenazas, vectores de ataque y vulnerabilidades. Sin embargo, estos aspectos pueden cambiar con el paso del tiempo, en particular las vulnerabilidades ya que, como podemos comprobar, la aparición de nuevas es algo continuo. Por tanto, los niveles que resultan satisfactorios a día de, un año después pueden no serlo, siendo la ciberseguridad  un proceso vivo que debe revisarse y ajustarse.

Una de las circunstancias a las que nos vamos a enfrentar, y que muchas veces nos olvidamos, es la existencia de gran cantidad de proveedores dentro de las organizaciones industriales. Las mismas recurren a productos y servicios especializados de terceros que luego deben ser soportados durante su ciclo de vida y garantizar así un respaldo en caso de incidencias.

Para poder llevar a cabo las respectivas tareas, los técnicos de estos proveedores deberán en algún momento, conectarse a la red de operación. Y esto presenta un problema, ya que:

  1. En muchas ocasiones contarán con un software propietario con licencias asignadas a ese equipo dificultando, o no siendo posible, reasignarlas a otro de la propia organización.
  1. Por supuesto al ser un equipo de un tercero no sabemos el estado de actualización del sistema operativo.
  1. Como no, desconocimiento del uso responsable, o no, que se le ha dado por parte de su propietario o usuario.
  1. Puesto que se tratarán de equipos portátiles para disponer de movilidad para llevarlos a tal o cual cliente, vaya uno a saber a qué otras redes han estado conectados.
  1. Y ya para rematar, como no puede ser de otra manera, usuario con permisos de administración y contraseñas de dominio público para que sea quien sea el que lo utilice, lo pueda hacer con total libertad.

Con todo lo dicho, ¿vamos a dejar conectarse a nuestra red equipos sobre el que no tenemos control o bien desconocemos el estado de actualización, limpieza, software instalado, etc? ¿Cómo encaja esta situación dentro de nuestras políticas? Y por si fuera poco, ¿si encima estos técnicos vienen del extranjero? ¿qué hacemos?

Indudablemente esto es una situación a la que deberemos hacer frente y necesariamente contemplarla dentro de nuestras políticas. Esto es, la gestión de los proveedores.

A este respecto deberemos tener en cuenta dos aspectos. Por un el administrativo y por otro, la solución técnica.

Desde el punto administrativo la organización deberá establecer un proceso donde se regule qué hay que hacer cuando un proveedor deba conectarse a nuestra red OT.

La primera de ellas es realizar un análisis de riesgos de este proveedor con lo que habrá que identificar:

  1. Necesidad justificada de la acción.
  2. Alcance de trabajos.
  3. Activos sobre los cuales se va a actuar.
  4. Información técnica sobre las intervenciones.
  5. Duración estimada.
  6. Recursos empleados.
  7. Manera en la que afecta a la organización.
  8. Análisis del impacto que tiene para la organización en caso de producirse un error y cómo afecta a aspectos tales como financiero, operativo, clientes y trabajadores.
  9. Representación gráfica tanto del riesgo existente como del residual si el primero no puede ser reducido o mitigado.

Otra de la información que tenemos que recoger son las necesidades de comunicación que van a tener. Esto es, direcciones IP, servicios, protocolos, etc. Esto mismo puede ser reflejado en un documento para que los administradores de los firewalls deban configurar los permisos correspondientes. Aquí dependerá de cada cual, pero importante valorar funcionalidades de los mismos en materia de:

  1. Portal Cautivo.
  2. Validación de reglas según validación de usuarios.
  3. Limitación temporal de permisos.
  4. Perfiles de seguridad concretos según labores a realizar.
  5. Otros.

Ya por último es importante considerar los acuerdos de confidencialidad y muy especialmente de responsabilidad. En cada intervención, por mucho que se planifique y se reduzcan las posibilidades de sufrir un incidente, el riesgo está. Por tanto, conviene acordar si fruto de esa intervención se deriva un error que afecte a la actividad de la instalación, y a su vez, un perjuicio económico a la empresa en cuestión.  ¿Quién las asume?

Una de las acciones que también debe  contemplarse, o deben realizarse, es hacer  un escáner de vulnerabilidades para conocer qué o cuáles pueden estar afectando al equipo de nuestro proveedor. Esto nos va a permitir exigir que antes de llevar a cabo cualquier trabajo deba actualizar los equipos o corregir las desviaciones antes de efectuar la conexión a nuestra red.

En el artículo de hoy hemos hecho una aproximación desde el punto de vista de que exista una VLAN dedicada a empresas externas donde toda comunicación contra otra red debe pasar por un Firewall (NGFW, Next Generation Firewall). Sin embargo, puede ocurrir que esta estrategia no sea efectiva dependiendo de la arquitectura y equipos que componen nuestras redes. Puede haber situaciones que sea necesario que los proveedores deban conectarse físicamente a la red control. Veamos la imagen siguiente:

El PLC tiene por un lado una tarjeta de comunicaciones que conecta con la red 192.168.1.0/24, y luego la propia de su CPU con el 192.168.10.0/24. Según el esquema inicial donde nuestro proveedor lo hace desde el entorno de oficinas debiendo pasar por los firewalls  de “Separación” y por el de “Segmentación”, no podría llegar a las interfaces de la red 192.168.10.0/24 ya que el PLC puede no tener la capacidad de llevar cabo el enrutamiento entre ambas. Sí que podríamos llegar a él por la red 192.168.1.0/24 y a través del software de configuración poder ver el resto de interfaces, pero si lo que queremos es llegar directamente a los sensores o actuadores de la periferia 192.168.10.0/24 que controla, por ejemplo por HTTP, S7, ModbusTCP, FTP, o cualquier otro (sea seguro, o no) seguramente no podamos hacerlo por esa falta de capacidad.

Por tanto, he aquí un problema añadido y es que, ¿Dejamos conectar a ese proveedor su PC y que se efectúen las comunicaciones en Capa 2? ¿Cuáles son los riesgos a los que nos enfrentamos si no tenemos ningún cortafuegos que filtre las comunicaciones? ¿Cómo hacemos frente a estas situaciones?

Bueno pues estas y otras cuestiones trataremos de ir resolviéndolas poco a poco en nuevas entradas.

Un saludo a todos, nos vemos en la siguiente y no te olvides que puedes seguirnos también en @enredandoconred .

Edorta

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.

 

Un breve repaso a definiciones de malware

Como hemos dicho en otras entradas, la proliferación de equipamiento industrial en redes basadas en tecnología Ethernet ha ido en aumento al igual que el grado de exposición frente a actividades maliciosas. Tal es el caso del malware algo que, si bien ya estábamos acostumbrados en entornos IT, su presencia en entornos industriales no sólo está haciéndose mayor sino que su desarrollo está siendo dirigido hacia este tipo de dispositivos. Además, cobra especial importancia cuando los equipos con Sistemas Operativos Windows no sólo no están parcheados sino que además no cuentan con herramientas protección. Aquí podemos entrar en un debate donde encontraremos detractores y defensores sobre la seguridad que ofrecen este tipo de productos, los anitvirus. En cualquier caso convendría realizarse algunas preguntas y que para nada son todas las que podrían ser.

  1. ¿Ofrecen los antivirus del mercado firmas para malware dirigido a Sistemas de Control Industrial?

IRONGATE

  1. Considerando el ciclo de vida mayor de los equipos en comparación con entornos IT, ¿Ofrecen soporte a Sistemas Operativos como Windows 2000 y XP presentes aún en entornos OT?
  1. Todo equipo tiene una parte software y otra hardware. Teniendo en cuenta que estos Sistemas Operativos poseen recursos como CPU, memoria, etc. mucho menor de lo actual. ¿qué impacto tiene la carga computacional cuando se lleva a cabo un análisis de equipo?
  1. Según lo anterior, ¿podrían verse afectadas en un momento dado las aplicaciones que interactúan con los equipos de campo y que cuyo funcionamiento debe garantizarse?
  1. A diferencia de entornos de oficinas donde, como norma general, diariamente existe una ventana de tiempo para poder llevar cabo ciertas acciones, ¿qué ocurre en los casos de 24 X 7 X 365?

Crashoverride portada

Cuestiones aparte, lo que si es cierto es que muchas veces los técnicos, ingenieros de procesos o de mantenimiento, que interactúan en última instancia con el equipamiento potencialmente infectable, no sólo no son conscientes de los riesgos sino además de las diferencias que existen entre los tipos demalware. Por tanto, si una entidad emite una información sobre tal o cual campaña o bien se emite un boletín con las características del “bicho” es más que probable que estas personas entiendan poco, o nada, de todo cuanto ahí se documenta. ¿Porqué? Porque hasta ahora no había esa necesidad. Estos profesionales deben de saber de automatismos, sensores, actuadores, relés, motores, neumática, hidráulica, robots, etc. etc. La ciberseguridad no era una prioridad, hasta ahora. Por tanto, al hablar de Troyanos, Rootkits, Gusanos, o cualquier otro, estamos hablando de algo que pueden no saber interpretar, ni en su particularidad ni en su contexto pero que afecta a los equipos que sí son de su responsabilidad.

Así pues, veía necesario hacer un pequeño resumen de los principales tipos para hacernos una idea de una manera sencilla y sin entrar en muchos detalles, de lo que dicha documentación trata de contarnos. Vamos pues.

Droppers

Es software que permite la instalación de malware sobre un objetivo determinado. Esta acción puede hacerse bien en una sola fase, por ejemplo, el malware viene embebido dentro de un fichero; o bien en dos fases. Esto es, el “dropper” descarga una pieza de software desde un servidor y a continuación se produce la infección.

Rootkits

Estas “herramientas” tratarán de encubrir procesos o servicios que están llevando algún tipo de actividad maliciosa, como puede ser permitir acceso remoto a un atacante. Esto se puede conseguir ofreciendo información falsa sobre las tareas que se están ejecutando y pretender hacer ver que todo está correcto cuando en realidad el equipo está comprometido.

Adware y Spyware

El “Adware” se trata de software publicitario que genelaralmente se presenta en los navegadores web como añadidos con una funcionalidad concreta siendo muy comunes en aplicaciones gratuitas. En algunas ocasiones pueden contener algún tipo de software tipo “Spyware” con el fin de recolectar cierto tipo de información del usuario o del equipo sobre el cual se instala.

Gusanos

La función principal de los gusanos es la de replicarse a sí mismo y conseguir extenderse. Las dos vías más comunes es hacerlo por la red o bien por otro medio como las memorias USB. Pueden operar de forma independiente, aunque a menudo son usados conjuntamente con algún otro módulo. Por ejemplo, el gusano se propaga y dicho módulo infecta al equipo vulnerable. Un ejemplo lo tenemos con el malware Wannacry que tanto oímos hablar no hace mucho tiempo.

Troyanos

Se trata de malware cuyo principal propósito es dar acceso remoto a un sistema para actuar en él en un momento dado. Aparte de abrir una puerta trasera, podrán  incorporar otras funcionalidades como captura de pulsaciones de teclas para posteriormente enviarlos a un host remoto, o incluso un rootkit para pasar desapercibido.

Ransomware

¿Qué se puede decir de este tipo de malware con todo lo que ha acontecido con “Wannacry”?  En cualquiera de los casos debemos de decir que el objetivo de este tipo de malware es impedir el acceso a ficheros y solicitar un rescate para permitir su acceso de nuevo. La principal vía es el cifrado de los mismos, y posterior aviso de que la operación se ha llevado a cabo. Una vez efectuado el pago, el atacante envía la clave para proceder a su descifrado y así recuperar la información.

wannacry_05-1024x774

Hasta qui he querido dar una definición muy muy breve de los principales tipos de malware y que a menudo podremos encontrar en aquellos informes que puedan aparecer relativos a incidentes en entornos industriales. La entrada de hoy puede parecer muy “light” para aquellos que provengan del mundo IT, pero en este caso ha he pretendido dirigirla a personas relacionadas más con las Tecnologías de Operación que, generalmente, no están relacionadas con este tipo de términos.

Dicho lo cual, hasta aquí la entrada de hoy que, aunque descafeinada para algunos, espero sea el punto de partida para otros, que seguro deberán familiarizarse cada vez más con estos u otros tecnicismos.

Un saludo a todos, nos vemos en la siguiente y no te olvides que puedes seguirnos también en @enredandoconred .

Edorta.