Archivo de la categoría: Riesgos

Proveedores Externos, otro punto de entrada… 

Posted on por

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

CSET, Herramienta para evaluación de riesgos. Parte II.

Posted on por

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.

CSET, Herramienta para evaluación de riesgos. Parte I.

Posted on por

Desde que me incorporé al ámbito de la Ciberseguridad Industrial he visto cómo a la hora de hablar sobre cómo proteger nuestras instalaciones lo hacemos principalmente refiriéndonos a las medidas tecnológicas que corrigen, o mitigan, amenazas, vulnerabilidades y vectores de ataque. Para ello basamos nuestros argumentos en base a las medidas Técnicas y Operacionales que puede marcar una estrategia de “Defensa en Profundidad”  y a la que hacen referencia las principales guías y buenas prácticas.

Sabemos que la seguridad al 100 % no existe, y lo que puede considerase como “seguro” hoy, mañana, ya no lo es. Por tanto, puesto que el nivel de seguridad puede ser variable o incluso subjetivo, el objetivo a alcanzar debe ser mitigar o reducir los riesgos a los que estamos expuestos hasta un punto que consideremos aceptable.  O bien, que los riesgos residuales sean asumibles.

Es por ello que en ese afán por concienciar sobre la necesidad de tomar medidas y centrarnos en el cómo y de qué manera, muchas veces dejamos pasar por alto una fase previa con una importancia mayor si cabe. Me refiero a la realización de un Análisis de Riesgos y GAP. Con ellos determinamos el estado en el que nos encpntramos y a partir de ahí buscar las mejores medidas para corregir las deficiencias existentes. Por tanto, deberemos por un lado, identificar todos nuestros activos, tecnologías y tráficos en nuestra red; y por otro, analizar los riesgos a que nos enfrentamos según su estado. Por ejemplo, no es lo mismo disponer de equipos HMI con sistema operativo Windows 7 aún con soporte por parte del fabricante, a tener Windows XP ya sin él. Es decir, no podemos tratar de securizar algo si no sabemos ni el número, cómo funciona, contra qué se comunica; y mucho menos encontrar la mejor solución técnico-económica para hacerlo.

Ahora bien, ¿cómo se lleva a cabo esto? ¿Qué preguntas debemos hacernos para calificar si un riesgo es más o menos grande? ¿Son los criterios iguales para una empresa manufacturera que para una de distribución de energía? ¿Cuáles son las medidas que debo considerar? Estas son algunas de las muchas preguntas que llegado el caso, podremos hacernos.

Sin embargo, contamos, con una aplicación pensada en concreto para los Sistemas de Control Industrial. Se trata de CSET, Cyber Security Evaluation Tool elaborada por el ICS-CERT.

 

Esta herramienta, hecha por el Departamento de Seguridad de la Patria del gobierno de Estados Unidos,  pretende ayudar a los usuarios a evaluar el estado de la seguridad de sus sistemas y redes mediante la realización de una serie de preguntas relacionadas tanto con los sistemas de control industrial como de las tecnologías de la información. El resultado es una lista de recomendaciones para mejorar el nivel de ciberseguridad de las organizaciones a partir de la base de datos de los estándares,  guías y buenas prácticas actuales. Cada recomendación cuenta con un enlace a una serie de acciones que deben de ser consideradas y aplicadas para mejorar los controles de seguridad.

La herramienta ha sido diseñada para instalarse fácilmente en un equipo de escritorio. Los estándares de los que hablábamos anteriormente proceden de organizaciones como el NIST, NERC, TSA, DoD entre otros. La operativa es sencilla, al seleccionar alguno de los estándares se realizan una serie de preguntas. Las respuestas son comparadas contra un nivel de seguridad elegido, generándose un informe que refleje las posibles mejoras potenciales. Esto proporciona una serie de beneficios como: 

  1. Ayudar a las distintas organizaciones en la Gestión de Riesgos y procesos.
  2. Incrementar el conocimiento y facilitar la toma de decisiones en materia de ciberseguridad.
  3. Revelar la presencia de vulnerabilidades y proporcionar recomendaciones para mitigarlas.
  4. Identificar áreas de mejora y recomendación de buenas prácticas.
  5. Proporcionar un método para comparar y monitorizar las mejoras en los sistemas.

CSET está disponible para su descarga desde el siguiente enlace. En este otro podremos encontrar los distintos métodos para utilizarla, recursos hardware, e incluso un canal con video tutoriales como el que sigue:

Hechas las presentaciones en la siguiente entrega iremos viendo paso por paso, las distintas opciones con las que cuenta. Por ahora toca descargarla e instalarla.

Nos vemos en la próxima!

Un saludo!