Con relativa frecuencia podemos ver en medios digitales incidentes de ciberseguridad que afectan a empresas. Aunque se dediquen a actividades muy distintas y tengan diversas consecuencias, todos tiene un factor común denominador. Para reducir las consecuencias debemos de tomar medidas, entre ellas aplicar dos conceptos básicos en materia de ciberseguridad pero con aplicabilidad a las diferentes tecnologías y dispositivos que nos encontramos en tipo de entornos. ¡En este video te lo cuento!
¡Espero que te guste!
Si quieres aprender más sobre ciberseguridad industrial no te olvides que siempre puedes hacerlo en mi «Curso Avanzado de Ciberseguridad Industrial«
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:
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.
Por supuesto al ser un equipo de un tercero no sabemos el estado de actualización del sistema operativo.
Como no, desconocimiento del uso responsable, o no, que se le ha dado por parte de su propietario o usuario.
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.
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:
Necesidad justificada de la acción.
Alcance de trabajos.
Activos sobre los cuales se va a actuar.
Información técnica sobre las intervenciones.
Duración estimada.
Recursos empleados.
Manera en la que afecta a la organización.
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.
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:
Portal Cautivo.
Validación de reglas según validación de usuarios.
Limitación temporal de permisos.
Perfiles de seguridad concretos según labores a realizar.
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 .
Siguiendo con la primera parte donde os presentaba CSET vamos a recorrer ahora los distintos pasos en su utilización.
Tras la instalación, al iniciar la herramienta accederemos a la pestaña “Home”. Allí nos encontraremos con una pantalla donde tendremos las opciones de crear un proyecto, dónde guardarlo, etc.
Para lleva a cabo nuestro análisis deberemos crear un fichero donde se recogerá toda la información referente a nuestro análisis, añadiendo información complementaria en la pestaña “Information”. Para ello deberemos completar algunos campos como nombre, contacto, nombre de las instalaciones, entre otros.
Listo el punto anterior, el siguiente será definir los “Standards” que utilizaremos como referencia.
Tendremos tres opciones “Questions”, para el usuario medio con un conjunto de preguntas generales; “Requirements”, dirigido a técnicos con conocimiento de los estándares disponibles para cada uno de los ámbitos; y finalmente “CyberSecurity Framework”, orientado a la protección de infraestructuras Críticas.
En mi caso he seleccionado “Requirements”, apareciendo las distintas opciones que siguen. Tomaré como ejemplo “Process Control and SCADA – NIST Special Publication 800-82″.
Aquí llegamos a un punto clave, el “Security Assurance Level”, es decir el grado de seguridad al que queremos llegar con nuestro análisis.
A modo general podremos elegir entre 4 tipos de niveles, “Very high”, “High”, “Moderate” o “Low”; pudiendo hacerlo a su vez en los tres pilares de la ciberseguridad, “Confidentiality”, “Integrity” y “Availavility”. Luego, en la parte izquierda, existen otros parámetros más específicos acerca del potencial impacto para la economía de la organización o la población civil.
En el siguiente paso podremos realizar una ilustración sobre cómo están interconectados nuestros sistemas. Esto nos proporciona tener una visión gráfica de los elementos involucrados en el análisis ayudando a interpretar otros apartados. Bien editado por nosotros mismos o importándolo desde un fichero Microsoft Visio este será su sitio. Como podemos observar, disponemos de una variedad de equipos como PLC, RTU, HMI, entre las distintas temáticas como IT, Medical, Radio, General, Zone, etc.
De nuestra selección en el paso “Standard”, a continuación llega el momento de empezar a responder las preguntas en el apartado “Requirements”. Puede ser algo aburrido, pero crucial para poder identificar las deficiencias y diseñar soluciones. Puesto que hemos elegido el SP 800-82 del NIST, las preguntas irán dirigidas en esa dirección. Como muestra la imagen, comenzaremos con “Policy Vulnerabilities” y finalizaremos con “Technical Controls” no sin antes pasar por un conjunto de ellos. En la parte derecha tendremos información complementaria, además de la inclusión de ficheros adjuntos que pudieran ser necesarios o interesantes.
Respondidas las preguntas, el siguiente paso será analizar los resultados. Tras todo cumplimentado, tendremos los mismos en la pestaña “Analysis”. Estarán organizados bajo distintas categorías, teniendo varias opciones para su visualización tal y como aparece en la parte izquierda de la pantalla, bajo “Dashboard”, “Assessment”, “Ranked Questions”, etc.
Finalmente, con todo lo anterior es la hora de generar el reporte definitivo. Dependiendo a quién vaya dirigido tendremos varias opciones en lo que a contenido se refiere. Para ello en “Report selection” elegiremos entre las opciones disponibles. La herramienta también nos ofrece la posibilidad de presentarlo en dos formatos, PDF o DOCX.
Así pues tendremos en nuestro caso un resultado como el que sigue.
Esta tarea que hemos visto, además de cómo realizarla, debe considerarse de vital importancia. No podemos llevar a cabo un plan y una estrategia de seguridad si no sabemos cómo, ni de qué manera, evaluar nuestras debilidades. Una vez detectadas entonces, y sólo entonces, podremos plantearnos la manera de cómo corregirlas. Sin embargo para poder solucionar un problema no solo debemos realizarnos las preguntas correctas sino adaptadas a cada entorno. Esto es, no es lo mismo una fábrica de coches, que una farmacéutica, que una de distribución de agua potable o una central nuclear. Las consecuencias de que se produzca una brecha en la seguridad podrán llegar a ser más o menos graves y con un posible impacto sobre población civil. Así pues, debemos contar con algo que nos oriente en esta labor, especialmente cuando la solución pasa por involucrar a profesionales de entornos tan distintos como son IT y OT. CSET es una excelente herramienta que nos facilitará y cubrirá nuestras necesidades en este ámbito por lo que resulta obligado contar con ella para securizar nuestras instalaciones.
