Amenazas sobre ICS (Parte I)

Como hemos podido comprobar en estos últimos años el número de ataques a Infraestructuras Críticas e Instalaciones Industriales ha ido en aumento. Aquellos buses de campo que hace tiempo atrás quedaban aislados de las redes empresariales poco a poco han ido incorporándose a ellas gracias a la implementación de protocolos de basados en TCP/IP. Si bien las funcionalidades y posibilidades han crecido esto ha generado a su vez que queden expuestas a actividades hostiles por parte de personas físicas o malware concreto para IACS. Así pues, esta visibilidad hace que debamos tomar más precauciones.

Inicialmente se hablaba del “air-gap” como medida de protección. Si bien puede resultar efectiva en algunos entornos, la implementación de ciertos servicios como monitorización y recolección de datos de los equipos de Automatización y Control obliga que éstos estén accesibles desde los sistemas SCADA y a su vez por los agentes y personal encargado de visualizar los datos en ellos representados. De esta manera, ha habido que adaptarse e implementar el concepto de “Defensa en Profundidad” como medida que más puede reducir los riesgos de que un ataque pueda ser satisfactorio.

En cualquier caso al margen de la estrategia de protección empleada cuanto más, expuestos estén nuestros sistemas de control, la amenza es mayor. Entendiendo por amenaza la posibilidad de que un evento o una acción determinada ocurra produciendo un daño material o inmaterial sobre los componentes de un sistema o un conjunto de ellos. Esto es, daños a nivel físico como lógico.

A modo general podríamos catalogar a estas amenazas en dos grandes grupos, intencionadas y no intencionadas. Si bien la mayor parte de ellas son de carácter no intencionado, aunque existe una claro aumento de las intencionadas.

Amenazas no intencionadas.

Las amenazas no intencionadas, podemos decir son todas aquellas que no son dirigidas deliberadamente contra el  sistema de control y automatización, pero que, por una u otra causa aún y así pueden ser un peligro para éstos. Normalmente, las amenazas no intencionadas están relacionadas con fenómenos que están fuera de nuestra capacidad de gestión.

Así pues es posible marcar una división entre aquellas que tienen un origen humano y las que no, estableciéndose entre todas, cuatro grandes grupos:

  1. Safety
  2. Fallos de equipamiento
  3. Desastres Naturales
  4. Humanos

FALLOS DE “SAFETY”

Por “safety” entendemos todas aquellas medidas que ayudan a evitar de un accidente, relacionándolo con términos como prevención, seguridad en el proceso, figuras de ingenieros industriales. Al tratarse de instrumentación mecánica y/o electrónica debido al uso, fatiga o deterioro de materiales, pueden provocarse daños en los sistema de control y automatización y por tanto, en el propio proceso industrial.

Estos fallos de los sistemas de “safety” no sólo incluyen los problemas que pueden tener los sistemas de protección tanto del equipamiento físico controlado (por ejemplo: interruptores,  dispositivos de emergencia, detectores de posición, etc.) sino también el personal que lo manipula (por ejemplo: técnicos de mantenimiento, retenes, etc.). Aquí os dejo un artículo publicado por INCIBE donde lo explica muy bien, picha aquí.

FALLOS DE EQUIPAMIENTO

Al igual que sucede con los sistemas de safety, los dispositivos de automatización y control son elementos hardware con muchos componentes electrónicos. Si bien se caracterizan por una gran robustez y durabilidad no están exentos de sufrir fallos como pueden ser avería de la fuente de alimentación, módulos de comunicaciones, agotamiento de recursos de memoria, etc. Sea cual sea la causa, la operatividad y disponibilidad de las instalaciones puede verse afectada hasta el punto de quedar inutilizable total o parcialmente.

DESASTRES NATURALES

Aquí quedan recogidos todos aquellos sucesos medioambientales con consecuencias graves o incluso fatales y cuyo origen difícilmente se puede predecir. Por citar alguno podríamos hablar de inundaciones, terremotos, incendios, o condiciones climatológicas fuera de lo habitual. Todos recordaremos el tsunami que azotó la costa oriental de Japón en el año 2011 en la que la central nuclear Fukushima se vio dañada con las consecuencias que aparejó. También en esa ocasión un gran número de servicios de Telecomunicaciones, presas hidroeléctricas, aeropuertos, y demás Infraestructuras Críticas se vieron gravemente afectadas o destruidas.

ERROR HUMANO

Suelen decir que la fortaleza de una cadena radica en el eslabón más débil.  Dentro de la estrategia de protección el ser humano juega un papel determinante y muchas veces con nuestras confianzas, descuidos o desidia, podemos comprometer toda la seguridad de nuestra protección. Ese USB que nos pasan y lo pinchamos sin haberlo pasado primero un antivirus o ese software descargado que viene con el “crack” y aparte de la licencia nos trae otro “regalito”. Así pues, dentro de este grupo hemos de considerar los fallos producidos por descuidos o negligencias. Hablamos de memorias, pero no nos olvidemos de la existencia de otro tipo de dispositivos como los teléfonos móviles… Ya el error no es esa nota autoadhesiva con el usuario y contraseña debajo del teclado. Pero todo no son imprudencias, también puede ocurrir que sin, quererlo, nos podamos equivocar en la parametrización de un elemento  o en la carga de un fichero que no corresponde con el dispositivo en cuestión, y como es de esperar no funcione como se espere.

Como hemos podido ver, no siempre las amenazas vienen de la mano de personas o sistemas con ánimo de provocar un daño sobre nuestra organización. Muchas veces sin desearlo podemos sufrir accidentes, que cuyas consecuencias pueden ser mayores que un ataque dirigido y estudiado durante meses.

Como era de esperar próximamente hablaré de esas otras amenazas, las intencionadas, donde hablaremos esas sí que sí están hechas con premeditación, alevosía y “nocturnidad”.

Un saludo nos vemos en la próxima!

Virtual Patching en funcionamiento (Parte II)

Siguiendo la entrada anterior Virtual Patching en funcionamiento (Parte I) vamos a seguir viendo los efectos del Virtual Patching pero en el caso frente a un escáner de vulnerabilidades.

Lo que vamos a hacer es lanzar uno desde una máquina virtual con Kali Linux hacia un Windows XP vulnerable. ¿Por qué un XP? Porque este sistema operativo está aún muy presente en muchos equipos en entornos industriales y debido al largo ciclo de vida de las estaciones o instalaciones que gobiernan, siguen funcionando a pleno rendimiento. Sin embargo, como sabemos ya no hay soporte y muchos de ellos no están parcheados, lo cual les convierte en un objetivo muy apetecible a malware y usuarios malintencionados. Ni qué hablar de Windows 2000 que también los he visto… Buenos, el esquema era el siguiente:

Esquema 01

Como decía, en el post anterior trataba los resultados tras hacer un escaneo con Nmap. Ahora toca pasar a la siguiente etapa dentro de una supuesta intrusión, o auditoría. Encontrar vulnerabilidades para ser explotadas. Para ello se utiliza un escáner que en nuestro será “Nessus”, pudiendo encontrarse otros como OpenVAS y Nexpose.

Kali Linux no lo trae por defecto, así que lo hemos descargado de la página del producto, obtenido el código correspondiente, instalado y actualizado los plugins. Luego creamos el proyecto y definimos los perfiles que queremos utilizar. En mi caso he dejado sólo los relacionados con plataformas Windows para que sea algo más rápido. No obstante os dejo otro de mis post donde hablaba de la metodología del Pentesting. Lo podéis encontrar aquí.

Nessus 01

Por otro lado la configuración de reglas en el Fortinet Fortigate Rugged 60D quedaría como sigue:

Nessus 02

Como se puede ver se permite todo el tráfico entre las interfaces “Wan1” y “Wan2”, pero se someterá a los motores Antivirus, Control de Aplicación e IDS/IPS. Lo sé, lo sé, habría que restringir el tráfico sólo al imprescindible pero para la prueba lo dejaré así. En la vida real, ni se os ocurra hacer esto. En el caso de este último, el IDS, se ha configurado para que bloquee “Block” todo aquél tráfico que coincida con alguna de las reglas en él definidas.

Tras lanzar el escáner vemos que el resultado es el siguiente. El Fortigate ha bloqueado los paquetes desde el escáner:Nessus 03

Si a continuación hacemos un reporte de las vulnerabilidades encontradas vemos que sólo se han encontrado un total de 8 de nivel informativo.

Nessus 04

Así pues el supuesto atacante apenas podría haber obtenido información del objetivo, con lo que tendría más complicado a la hora de lanzar un exploit concreto cara a aprovechar una vulnerabilidad. Aunque no se aprecie en la imagen, los datos ofrecidos no son relevantes cara a este fin, la intrusión. En cambio, si deshabilitamos dicha protección, esto es:

Nessus 05

Y lanzamos de nuevo el escáner, el resultado sería bien distinto:

Nessus 06

Aquí veremos que sí se obtienen datos sobre el equipo con Windows XP y por tanto sería exitoso el ataque como el que se podría llevar a cabo en el punto siguiente. Entre ellas hay un total de 3 vulnerabilidades “Critical”, 2 “Medium”, y 20 “Info” destacando entre ellas la que figura a continuación.

34477 (1) – MS08-067: Microsoft Windows Server Service Crafted RPC Request Handling Remote 

Code Execution (958644) (uncredentialed check) 

Synopsis

Arbitrary code can be executed on the remote host due to a flaw in the ‘Server’ service.

Description

The remote host is vulnerable to a buffer overrun in the ‘Server’

service that may allow an attacker to execute arbitrary code on the remote host with the ‘System’ privileges.

See Also

http://technet.microsoft.com/en-us/security/bulletin/ms08-067

Solution

Microsoft has released a set of patches for Windows 2000, XP, 2003, Vista and 2008.

Risk Factor

Critical

CVSS Base Score

10.0 (CVSS2#AV:N/AC:L/Au:N/C:C/I:C/A:C)

CVSS Temporal Score

8.7 (CVSS2#E:H/RL:OF/RC:C)

STIG SeverityI

References 

BID 31874

CVE CVE-2008-4250

XREF OSVDB:49243

XREF MSFT:MS08-067

XREF IAVA:2008-A-0081

XREF CWE:94

Exploitable with

CANVAS (true)Core Impact (true)Metasploit (true)

Plugin Information:

Publication date: 2008/10/23, Modification date: 2015/06/18

Hosts

XX.XX.XX.17 (tcp/445)

Queda bastante claro la funcionalidad de estos motores. A pesar de no restringir el tráfico mediante reglas de firewall tradicionales y dejar pasar todo, algo que obviamente NO DEBE HACERSE BAJO NINGÚN CONCEPTO, nos proporcionan un grado de protección evidente.

En este ejemplo lo hemos hecho sobre un Windows XP vulnerable, pero esto también podríamos emplearlo como elemento de seguridad perimetral sobre Sistemas de Control y Automatización Industrial u otros dispositivos con capacidades limitadas para la implementación de medidas de seguridad. Su protección en este caso radicaría en el Fortigate Rugged 60.

Así hemos terminado por hoy. En la próxima entrada veremos cómo comprometer el Windows XP mediante Metaesploit gracias a la vulnerabilidad anterior.

Como en otras ocasiones os animo a que dejéis vuestro comentario, tanto si es positivo como si no lo es. Todo sirve para mejorar.

Lo dicho, un saludo, nos vemos en la próxima!!

Virtual Patching en funcionamiento (Parte I)

Siguiendo con el tema de Virtual Patching ahora toca ver cómo funciona y los beneficios que puede aportarnos.

Para ello he creado un entorno con dos PCs interconectados por medio de un Fortinet Fortigate Rugged 60D configurándolo con motores Antivirus, IDS/IPS y Control de Aplicación. La parte de firewall la he dejado con un “permit any any any” (IP origen, destino y puerto, respectivamente) Hay que recordar que cada una de ellos lo podemos configurar en dos modos, “Monitor” o “Block”. Con el primero, en caso de que se detecte algún patrón que puda quedar recogido dentro de las reglas y firmas, no se tomará ninguna acción, sólo se registrará el evento y se dejará pasar. En cambio con “Block”, valga la redundancia se bloqueará y la amenaza será paralizada.

Luego, estas características han de aplicarse, o no, a las reglas de Firewall en él configuradas.

En cada uno de estos PCs he virtualizado un total de 3 máquinas.

Una con Kali Linux desde la cual simularemos la actividad de un atacante. Lanzaremos un escaneo de puertos con Nmap, escáner de vulnerabilidades con Nessus, intento de intrusión con Metaesploit y Armitage y por último copiar en un recurso de red el fichero EICAR.

Otra con un Windows XP vulnerable, el objetivo. Se ha elegido este ya que posee vulnerabilidades que para un ejemplo pueden ser fácilmente explotables. Aparte porque su uso en entornos industriales y o vida prolongada es aún bastante común.

Por último un Fortinet FotiManager con funciones FortiAnalyzer desde donde gestionaremos el equipo Fortigate Rugged 60D. Lo he querido utilizar ya que con un despliegue de varios equipos resulta aconsejable no sólo por la gestión centralizada sino porque nos permite almacenar los logs, analizar tráfico, sacar informes, ver registros, etc.

Todo queda resumido de la siguiente manera:

 

Esquema 01

En la imagen siguiente se muestra cómo el equipo Fortigate bloquea un total de 9965 amenazas catalogadas en un total de 1993 incidentes, provenientes de la IP XX.XX.XX.15 de la máquina Kali Linux. Esto es debido a que la aplicación Nmap envía sucesivamente paquetes para que en función de las respuestas obtenidas se pueda determinar si un equipo está activo, o no, puertos abiertos; versiones de aplicaciones, servicios; etc.

Para conocer un poco más recomiendo la siguiente lectura, pincha aquí.

Imagen 01

En esta otra se puede ver que el equipo destino tiene la IP XX.XX.XX.17.

Imagen 02

En la siguiente imagen se muestra las “sondas” enviadas desde el equipo Kali Linux identificando alguna aplicación que otra:

Imagen 03

Como se puede apreciar éstas han sido bloqueadas no pudiéndose obtener datos sobre el equipo objetivo, el XP. Esto mitigaría la etapa inicial de recolección de información que un atacante llevaría a cabo y poder, a partir de ahí, realizar otro tipo de acciones sobre nuestros sistemas.

Obviamente habría que configurar las reglas del firewall del modo más restrictivo posible y sobre el tráfico que dejamos pasar aplicar el análisis de los motores Antivirus, IPS y Control de Aplicación. Sin embargo para este ejemplo se ha querido dejar así para ver el comportamiento de la aplicación Nmap y qué es lo que sucede si no empleamos un cortafuego. Pero como como digo, siempre, siempre, siempre, ha de restringirse el tráfico sólo al estrictamente permitido por medio de estos firewalls.

Esto es todo por hoy, pero os debo las siguientes entradas sobre escáner de Vulnerabilidades, Metaesploit y EICAR Test File.

No s vemos en la próxima, y como siempre digo, se agradece cualquier comentario al respecto.

Muchas gracias!

Parches y Virtual Patching

A estas alturas todos tenemos claro que una de las medidas a aplicar dentro de nuestras políticas de seguridad es tener actualizados los sistemas y equipos de red. Esto lo podemos conseguir instalando parches para sistemas operativos, actualización de aplicaciones y versiones de firmware. Esto creo, que a nadie nos pilla por sorpresa.

Quizás uno de los puntos más críticos de las opciones planteadas es aplicar los últimos parches emitidos por el fabricante o los desarrolladores. La instalación de los mismos no debería provocar que nada dejase de funcionar, sin embargo este riesgo no es cero y puede suceder.

En entornos industriales, se emplean PCs para la interacción, configuración y gobierno de la maquinaria, robots y demás sistemas de control y automatización. Como he hablado en otras ocasiones aquí la premisa es la disponibilidad de las instalaciones, y por tanto, las posibles causas que puedan provocar una interrupción del servicio deben quedar reducidas al máximo. Para ello es necesario, o al menos conveniente, tener un entorno de laboratorio para el testeo de parches, ver su comportamiento y una vez comprobada la ausencia de anomalías, proceder a su despliegue siempre de forma progresiva.

Así pues se nos plantean 3 posibles casuísticas:

Hasta ahora hemos contemplado que el parcheo se puede llevar a cabo, sin embargo esto no siempre es así. Imaginemos que adquirimos un equipamiento a un proveedor. Éste garantizará su funcionamiento en esas condiciones, no en cambio, si sobre ella se realiza algún tipo de instalación de parches o software adicional. Seguramente será posible la contratación de un soporte de mantenimiento pero a cambio, posiblemente, de una muy considerable cantidad económica. Así pues el escenario, muy probablemente, será no parchear. Con lo que ello conlleva, claro.

Como segundo caso, debemos recordar que una de las características de los equipos industriales es su ciclo de vida prolongado. Éste es muy superior a los dispositivos IT convencionales, sin embargo no dejan de pertenecer a este ámbito por muy PCs industriales que sean. Llevan en sus entrañas Windows 2000, XP, 7, etc. Eso por no citar a NT que aún los sigo viendo. Estas versiones hasta XP, están fuera de soporte, aunque su uso sigue y seguirá vigente por varios años más. Y en estos casos, ¿cómo parcheamos si no tenemos soporte?

Finalmente podría darse que bien por su criticidad o por su delicadeza, no nos atrevamos a “meter mano” a este equipo que lleva sin tocarse 3, 4, 5 o más años. No nos podemos arriesgar a que surja algún inconveniente y no sepamos resolverlo. Y claro, ¿qué hacemos entonces? ¿Asumimos los riesgos? ¿O no?

En cualquier caso, la no actualización de nuestros equipos conlleva un riesgo. Quedan expuestos a una mayor probabilidad que un ataque, intrusión o actividad de malware, tenga éxito. Los entornos industriales, hasta hace relativamente poco, eran redes que permanecían aisladas del resto y su acceso era muy limitado. Con la integración en redes Ethernet, funcionalidades basadas en TCP/IP y la aparición del IIoT, esta exposición está siendo mayor y por tanto a los riesgos han aumentado.

Claro y ¿qué hacer entonces? Buena pregunta.

Pues bien, una de las opciones viene de la mano del Parcheo Virtual o Virtual Patching.

¿Qué esto de Virtual Patching? Podríamos definirlo como la política de seguridad destinada a prevenir la explotación de una vulnerabilidad mediante el análisis del tráfico, sometiéndolo a distintas capas de seguridad con el fin de evitar que código malicioso alcance la aplicación o sistema vulnerable. Esto es, el “ataque” se bloquea antes de que llegue al objetivo. Dichas capas vienen dadas por motores Cortafuegos, Antivirus, IDS/IPS, Control de Aplicaciones y Filtrado de Tráfico Web.

Como viene siendo habitual no voy a referirme a los entornos IT, sino a los industriales. Ya en la entrada anterior “Convertidores de medios” hablaba de la necesidad de utilizar dispositivos diseñados y pensados para ese fin, y la de hoy no es para menos.

Un ejemplo lo encontramos en el Fortinet Fortigate Rugged 60D, cuyas especificaciones las podéis encontrar aqui. Y su Quick Start Guide aquiForti

Este equipo es lo que podemos denominar UTM (Unified Threat Management) pero orientado a entornos industriales.

Como podemos ver, ya con su aspecto, las diferencias con los dispositivos tradicionales IT son bastante evidentes, el diseño ruguerizado lo delata. Otra de ellas es la implementación de protocolos industriales como Modbus, Profinet, OPC, DNP3, etc. Luego sobre ellos podemos aplicar las firmas de Control de Aplicación e IPS.

Por otra parte tendremos la posibilidad de instalación sobre carriles DIN, un modo de instalación de equipos industriales en armarios destinados a tal fin. Igual modo la alimentación eléctrica, por medio de borneros pudiendo emplear además la fuente de alimentación convencional que trae consigo.

En adición a lo anterior, podremos ver que la temperatura operacional va de -20 a 70 º C. ¿os imagináis las temperaturas más bajas y altas en un entorno IT convencional? Ufff qué frío y que calor…

Para su configuración inicial, nos descargaremos el software Fortiexplorer. Luego con el cable USB que viene de serie, conectaremos nuestro PC con el dispositivo.

Allí podremos acceder al Dashboard donde asignaremos algunos parámetros básicos y visualización de cierta información.

Luego dentro del apartado “Config -> Features”, definiremos aquellas características que queramos activar.

Imagen 01

Imagen 02

Imagen 03

A destacar su modo de funcionamiento denominado “Transparente”. Es modo convierte al dispostivo como un Firewall pero a nivel de Capa 2. No es necesario realizar ningún cambio en el direccionamiento IP del equipo a proteger. Sólo bastaría asignar una IP de gestión del mismo rango que éste.

Imagen 04

En “Security Profiles” definiremos los perfiles de configuración para los motores Antivirus, Filtrado Web, Control de Aplicación e IPS, en base a firmas y reglas.

Imagen 05

Imagen 06

En cada uno de ellos podremos definir si en caso de detectar comportamientos coincidentes con cada motor, entre “Block” y “Monitor”. Esto es, tomar una medida y bloquearla; o bien dejarla pasar, monitorizarla, registrando el evento como un log. Para ello deberemos indicar el servidor dónde enviar los datos. Fortinet tiene las herramientas propietarias FotiManager para una administración centralizada de dispositivos y FortiAnalyzer, para el análisis del tráfico y logs.

Imagen 07

El dispositivo tiene otras muchos parámetros y funcionalidades a las que podríamos dedicar horas y horas. No obstante en el futuro, espero poder subir alguna más. Todo depende del tiempo disponible.

Por ahora ya hemos terminado con esta, y como siempre, os pido que dejéis vuestra opinión a modo de comentario de lo que os ha parecido, tanto si os ha resultado, o no, interesante, o cualquier otro crítica constructiva.

Lo dicho, muchas gracias, nos vemos en la siguiente!!

 

Ciberseguridad Industrial, breve introducción…

Cuando hablamos de Ciberseguridad, generalmente lo hacemos desde el punto de vista tradicional de los entornos IT. Esto es, proteger de ciberamenazas, ciberdelincuentes, y demás términos de similar índole; la información contenida dentro de los sistemas información interconectados por medio de redes de comunicaciones de mayor o menor alcance. El objeto principal de custodia aquí es la información. Ésta puede venir de muy diversas maneras y formatos, desde un documento, hasta los registros en una Base de Datos, pasando por comprometedores correos electrónicos que por una razón u otra no interesa que salgan a luz.

Como decía, esto es el mundo IT. Ahora bien, ¿qué ocurre con los entornos OT? Aquí el principal activo no es la información sino la disponibilidad de las infraestructuras y la continuidad operacional de las instalaciones. Aquí los equipos a proteger no serán los servidores de ficheros, Bases de Datos, correo electrónico; sino los sistemas de Control y Automatización (IACS); Supervisión, Control y Adquisición de Datos (SCADA); Sensores, Actuadores, Autómatas Programables, etc. Aquí ya no es si se pierde o se compromete un dato; es qué pasa si las instalaciones dejan de funcionar por tal o cual motivo.

Así pues las “Operational Technologies”, o Tecnologías de Operación son los términos con los que nos referimos al conjunto de dispositivos, funcionalidades y procesos que participan en el desarrollo de la actividad de un determinado sector. Su indisponibilidad puede provocar no sólo un impacto significativo a la empresa que las posee y al entorno donde ésta pueda estar ubicada.

¿Por qué esto es así? Los Sistemas de Control y Automatización Industrial están presentes no sólo en fábricas de producción en serie de un determinado producto sino también en lo que conocemos como Infraestructuras Críticas. Entendiendo por estas últimas:

“Las infraestructuras estratégicas (es decir, aquellas que proporcionan servicios esenciales) cuyo funcionamiento es indispensable y no permite soluciones alternativas, por lo que su perturbación o destrucción tendría un grave impacto sobre los servicios esenciales”. 

Dentro de la Legislación española se han definido 12 sectores estratégicos, los cuales son:

  1. Administración.
  2. Agua.
  3. Alimentación.
  4. Energía.
  5. Espacio.
  6. Industria Química.
  7. Industria Nuclear.
  8. Instalaciones de Investigación.
  9. Salud.
  10. Sistema Financiero y Tributario.
  11. Tecnologías de la Información y las Comunicaciones (TIC).
  12. Transporte.

Una indisponibilidad de una cadena de montaje como la que puede ser la del sector de la Automoción puede generar una pérdida económica de equis miles o millones de euros; sin embargo si esto sucede en una central nuclear las consecuencias pueden ser bien distintas. No sólo por la pérdida de servicio eléctrico sino por el impacto que puede tener sobre la población civil y medioambiental.

Así pues podríamos definir algunas posibles consecuencias:

  1. Reducción o pérdida de la producción.
  2. Daños en el equipamiento.
  3. Lesiones de personas.
  4. Liberación, desvío o robo de materiales peligrosos (tóxicos, combustibles, etc.)
  5. Daños ambientales.
  6. Violación de normativa y legislación vigente.
  7. Contaminación de productos y entornos.
  8. Responsabilidades legales, penales o civiles.
  9. Pérdida de información confidencial o de propiedad intelectual.
  10. Pérdida de imagen o de la confianza.

Estas consecuencias tendrán su origen en algún tipo de incidencia. Éstas podrán ser catalogadas como no intencionadas, esto es, fallo o anomalía natural en los dispositivos; o bien, de carácter intencionado, es decir por la acción hostil de un software o actividad humana sobre los equipos. A continuación se citan alguna de ellas:

  1. Denegación de Servicio en los servicios activos en las redes de control o causando cuellos de botella a la hora de transferir información.
  1. Cambios no autorizados realizados en instrucciones de programas en PLCs, RTUs, DCS o controladores SCADA, parámetros de alarmas, ejecución de comandos no autorizados en equipos de control que lleguen a dañar el propio equipo, paradas no contempladas en procesos o incluso deshabilitar el equipo de control.
  1. Falsificación de información y visualización incorrecta a los operadores encargados de controlar el sistema.
  1. Modificación de software, configuración y parámetros de sistemas.
  1. Introducción en el sistema de malware (por ejemplo virus, gusanos, troyanos).

 

Así pues urge la necesidad de proteger los procesos, dispositivos y elementos que intervienen en todos procesos de automatización y control, de esos riesgos y amenazas de las que pueden ser objeto.

Como todo elemento tecnológico pueden disponer de errores en su diseño, programación o instalación; poseyendo vulnerabilidades y “bugs” que faciliten enormemente el éxito de las operaciones.

El gusano Stuxnet hizo abrir los ojos a muchas Naciones y empresas en los distintos sector de los riesgos que corrían si no tomaban las precauciones necesarias y sin duda supuso un antes y un después:

Stuxnet

Pero no ha sido el único, tiene otros hermanos con igual mala leche como Duqu, DragonFly, Havex, Black Energy, etc. y seguirán apareciendo más en los próximos meses. Esto va en aumento…

¿Quién puede tener interés en atacar esto tipo de entornos? Las respuestas pueden ser muy distintas, desde empleados descontentos, empresas de la competencia, grupos Hacktivistas, terroristas y delincuencia organizada, Agencias de Inteligencia, Gobiernos, etc. Obviamente hay un móvil y una razón por la cual llevar a cabo dichos propósitos.

Como contramedida a estos riesgos en materia de Infraestructuras Críticas existe por un lado el CNPIC (Centro Nacional de Protección de Infraestructuras Críticas), cuyo objetivo es  impulsar, coordinar y supervisar todas las actividades que tiene encomendadas la Secretaría de Estado de Seguridad del Ministerio del Interior en relación con la protección de las infraestructuras críticas españolas según la Ley 8/2011 y Real Decreto 704/2011

Además de ello existen otros organismos de carácter público y privado encargados de llevar a cabo distintas acciones sobre este ámbito. Algunos de ellos son:

España:

INCIBE, Instituto de Ciberseguridad de España.

CCI, Centro de Ciberseguridad Industrial

A nivel Europeo:

ENISA, European Union Agency for Network and Information Security

EE.UU:

ICS-CERT, Industrial Control System Cyber Emergency Response Team.

Así pues ya tenemos na primera aproximación a lo que conocemos como “Ciberseguridad Industrial” e iremos desarrollando en artículos sucesivos. Todo es empezar…

Un saludo.