protecciÓn de infraestructuras crÍticas...seguridad. su objeti vo es garanti zar los procesos y...

PROTECCIÓN DE INFRAESTRUCTURAS CRÍTICAS4º I N FO R M E T ÉC N I CO

4º INFORME DE PROTECCIÓN DE INFRAESTRUCTURAS CRÍTICAS

3

S2 Grupo es una empresa especializada en el desarrollo y prestación de productos y servicios relacionados con la ciber-seguridad. Su objeti vo es garanti zar los procesos y proteger el acti vo más valioso de empresas y organismos públicos: la información.Desde su creación en 1999, S2 Grupo se ha converti do en una compañía referente en el entorno de la seguridad a nivel

SOBRE S2 GRUPO

Óscar NavarroServilio AlonsoArmand PascualGonzalo ChePedro Isaac ColladoYajaira VillamizarJoan Balbastre

Este informe puede descargarse de la página web deS2 Grupo, htt p://www.s2grupo.es

internacional. Entre sus clientes pueden encontrarse compa-ñías líderes de los sectores de Distribución, Energía, Banca y Seguros, Sanidad, Industria y organismos de la Administración Pública.La compañía ti ene su sede en Madrid y su Centro de Servicios 24x7 se encuentra en Valencia. Además cuenta con ofi cinas en Barcelona, Bogotá y México DF.

AUTORES


4

1 Introducción

2 Antecedentes

3 ¿Qué es una vulnerabilidad?

4 Metodología

CVSS Base Score Equati on

NVD CVSS Overall Score Decision Tree

5 Resultados

5.1 Cuota de mercado y vulnerabilidades publicadas por fabricante

5.2 Vulnerabilidades por componente

5.3 Tipo de descubridor de la vulnerabilidad

5.4 Tipo de vulnerabilidad

5.5 Vulnerabilidades con solución propuesta

5.6 Tipo de miti gación recomendada por el fabricante

5.7 Abuso remoto de la vulnerabilidad

5.8 Vulnerabilidades con “Exploits” publicados

ÍNDICE

6

10

11

13

17

20

21

21

21

22

22

23

25

25

26


5

5.9 “Exploits” publicados vs parches desarrollados

5.10 Nivel de habilidad requerido del atacante

5.11 Nivel de riesgo de las vulnerabilidades

6 Análisis

6.1 Número de vulnerabilidades publicadas

6.2 Análisis de la cuota de mercado

6.3 ¿Dónde se descubren las vulnerabilidades?

6.4 ¿Quién descubre las vulnerabilidades?

6.5 ¿Qué ti po de vulnerabilidades se descubren?

6.6 Soluciones

6.7 Posibilidad de abuso remoto

6.8 Existencia de Exploits

6.9 Habilidad requerida

6.10 Nivel de riesgo

7 Conclusiones

8 Referencias

ÍNDICE

27

27

28

29

29

29

29

29

30

30

31

31

32

33

34

37


6

El presente documento conti núa con la línea de trabajo inicia-da en 2011, año en el que el equipo de S2 Grupo publicaba el primer informe sobre Protección de Infraestructuras Críti cas, en el que se analizaba la situación internacional y nacional en la materia (principalmente normati va). Este primer informe tuvo su conti nuación en 2012 con un segundo informe sobre la PIC en España, mucho más prácti co y con el objeti vo concre-to de determinar si las infraestructuras críti cas pueden consi-derarse “inseguras” en España (y si es posible, cuántas y de qué sectores) desde un punto de vista operati vo.

En 2014, conti nuando con ese enfoque prácti co, se realizó un tercer informe que se centraba en la disponibilidad de infor-mación detallada sobre las infraestructuras críti cas en España libremente accesible a través de Internet, especialmente en lo referente a sus instalaciones, procesos, sistemas de control, procedimientos de operación y, por últi mo, organización y gesti ón de la seguridad.

En esta ocasión, nos hemos centrado en una serie de dispositi -vos de los que actualmente depende gran parte de la infraes-tructura industrial española y son muy suscepti bles de recibir ciberataques: Los sistemas de automati zación de procesos industriales ICS (“Industrial Control System” por sus siglas en inglés).

Los sistemas de control industrial controlan, supervisan y ges-ti onan la infraestructura esencial (críti ca) de sectores relacio-nados con el suministro de energía eléctrica, el abastecimien-to de agua y la gesti ón de aguas residuales, el petróleo y el gas natural, el transporte y otras acti vidades industriales. Incluyen componentes como sistemas de supervisión, control y adqui-sición de datos (SCADA), controladores lógicos programables (PLC) o sistemas de control distribuido (DCS).

Los sistemas de control industrial (ICS) se han vuelto un blanco muy apetecible para los ciberatacantes. Los ataques dirigidos ya no son intentos de intrusión realizados por curiosos, sino ciberdelincuencia o ciberguerra. Tanto la seguridad nacional como los benefi cios corporati vos dependen del funciona-miento fi able y seguro de estos sistemas de control industrial.

En vista de estos riesgos muchos países, entre ellos España, están dándose cuenta de la necesidad de proteger mejor los sistemas ICS con la inversión y las medidas adecuadas.

Últi mamente, los ataques a sistemas ICS se han vuelto más frecuentes. Según sus objeti vos, que van desde el ciberespio-naje hasta la inuti lización del sistema, las repercusiones so-ciales y económicas pueden ser graves. Sin embargo, muchos incidentes no llegan a hacerse públicos para que no peligre la

INTRODUCCIÓN


7

reputación de la vícti ma, lo que lleva a subesti mar la gravedad del problema.

En 2010, salió a la luz Stuxnet [1], un malware diseñado para atacar determinados sistemas SCADA y las instalaciones del programa nuclear iraní. Desde entonces, todos los años han surgido nuevos ti pos de malware de ataque, y 2014 no ha sido una excepción. Los responsables de Dragonfl y [2] consiguie-ron espiar los datos de centrales energéti cas de 84 países, en-tre ellos España. Aunque no llegaron a realizar operaciones de sabotaje, hubieran podido hacerlo, lo cual habría alterado el suministro eléctrico de los países afectados. Más reciente-mente, Sandworm [3] atacó la interfaz hombre máquina (HMI) de varios fabricantes conocidos con una campaña de malware de gran complejidad. Como estas interfaces están conectadas a Internet, los atacantes se sirvieron de ellas para explotar las vulnerabilidades del soft ware ICS y, quizá, para reconocer el terreno y preparar otros ataques.

El últi mo incidente de 2014 fue el ataque a una fábrica de ace-ro alemana [4] cuyos altos hornos sufrieron graves daños a raíz de un ataque cibernéti co. Los ataques a sistemas ICS han evolucionado y se han vuelto más frecuentes, por lo que urge mejorar las medidas de protección.

Una vez instalados, estos dispositi vos ti enden a uti lizarse du-rante años y se aíslan o se confí a su seguridad a protocolos y hardware especializado cuya verdadera seguridad se des-conoce. Muchos de estos sistemas se crearon antes de que las empresas usaran tecnologías basadas en ethernet, y en su diseño se tuvieron en cuenta aspectos como la fi abilidad, el

mantenimiento y la disponibilidad, pero no tanto la seguridad. Sin embargo, hoy en día es necesario que estén conectados a redes y que, en muchos casos, sean accesibles de forma remo-ta, lo que deja al descubierto sus vulnerabilidades y cambia radicalmente la superfi cie de ataque.

Algunos ataques a sistemas ICS se producen porque en la in-fraestructura hay dispositi vos clave con acceso a Internet que no están bien protegidos. Para permiti r el acceso remoto, al-gunos elementos de los sistemas SCADA (con los que se su-pervisan plantas y equipos) uti lizan la red empresarial para co-nectarse a Internet. Esto deja al descubierto la red de control y aumenta los riesgos de que alguien sin autorización acceda a los dispositi vos o realice inspecciones, análisis o ataques de fuerza bruta.

Algunos atacantes se sirven de las interfaces HMI para hacer-se con el control de los dispositi vos (en algunos casos acce-sibles desde la red empresarial). Alguien que aproveche una vulnerabilidad de día cero para atacar los hosts de una empre-sa podrá averiguar cuáles ti enen acceso a la red de control y uti lizar esta información para infi ltrarse en los sistemas ICS.

Otra opción es buscar una interfaz HMI con conexión directa a Internet. Una vez localizados los dispositi vos de control, bas-tará con que estén mal confi gurados o presenten vulnerabili-dades para lanzar un ataque.

Además de los puntos de entrada mencionados, los sistemas ICS y el soft ware que uti lizan ti enen vulnerabilidades que de-jan la puerta abierta a quien pueda aprovecharlas.


8

Muchas aplicaciones web comercializadas presentan proble-mas de seguridad que permiten realizar ataques de desbor-damiento de búfer (Buff er Overfl ow [5]), inyección SQL o se-cuencias de comandos entre siti os. Además, si los métodos de autenti cación y autorización son poco elaborados, el agresor podrá acceder a las funciones más importantes del sistema ICS. Por ejemplo, una autenti cación descuidada en los pro-tocolos ICS podría permiti r realizar ataques de interposición “Man in the Middle” como el reenvío o la suplantación de pa-quetes. También cabe la posibilidad de que el atacante envíe comandos no autorizados a controladores lógicos programa-bles o información de estado falsa a las interfaces HMI.

Resumiendo, la seguridad en estos sistemas se ha converti do en estos últi mos años en un tema de excepcional relevancia desde que aparecieron una serie de incidentes en los cuales estaban implicados Stuxnet, Dragonfl y y Sandworm, como ya se ha citado anteriormente. Estos ataques mostraban que es posible para los ciberterroristas, empresas competi doras y servicios secretos de otros países, sacar provecho cuando no se le da alta prioridad a la seguridad de la información de los ICS.

Conocer el modo en que los atacantes pueden aprovechar las vulnerabilidades descubiertas en los ICS de infraestructuras críti cas consti tuye una parte esencial de cara a esti mar ten-dencias futuras. Por eso, es importante saber qué nivel de habilidad necesita un atacante para explotar la vulnerabilidad con éxito, qué método uti liza, quién descubre las vulnerabili-dades en los ICS, qué solución para eliminar o reducir la ame-naza adoptan las empresas, corporaciones, organizaciones...


9

Si las vulnerabilidades detectadas se pueden explotar de for-ma remota, si existen “Exploits” publicados que puedan pro-porcionar métodos de ataque ya implementados, la miti ga-ción recomendada por el fabricante, incluso qué ti po de ICS es más vulnerable. Para responder a estas preguntas, el equi-po de S2 Grupo ha llevado a cabo un análisis tomando como fuente de información para una serie de fabricantes seleccio-nados, todas las CVE (vulnerabilidades publicadas) de la web del ICS-CERT desde Enero de 2014 hasta Julio de 2015. En el

presente documento se muestran los hallazgos realizados, las conclusiones obtenidas y sus implicaciones en la protección de los ICS. Otros parámetros interesantes a analizar serían el ti empo entre que se descubre la vulnerabilidad hasta que se publica, el ti empo entre la detección de la vulnerabilidad y la generación de un parche así como la fecha de lanzamiento de los productos, pero desafortunadamente no se ha dispuesto de esta información y no se ha podido incluir en el presente estudio.


10

ANTECEDENTES

En 2014, la empresa Positi ve Technologies publicó el estudio “SCADA SAFETY IN NUMBERS” [6] donde analiza las vulnerabi-lidades de los sistemas ICS. En resumen, las conclusiones más signifi cati vas de este estudio son:

El número de vulnerabilidades detectadas ha aumentado en 20 veces (desde 2010).

Una de cada cinco vulnerabilidades no se arregla en un es-pacio de ti empo de un mes desde su detección.

El 50% de las vulnerabilidades permite a un hacker ejecu-tar código.

Se conocen “Exploits” para un 35% de las vulnerabilidades.

El 41% de las vulnerabilidades se clasifi can como “críti cas”.

Los hackers afi cionados pueden acceder a más del 40% de los sistemas ICS disponibles en Internet.

Un tercio de todos los sistemas disponibles a través de In-ternet se encuentra en los EE.UU.

Una cuarta parte de todas las vulnerabilidades se deben a la carencia de instalación de las actualizaciones de seguri-dad necesarias.

El 54% de los sistemas disponibles en Internet en Europa son vulnerables. En América del Norte la cifra es de 39%.

•

•

•

•

•

•

•

•

•


11

En ciberseguridad, la palabra vulnerabilidad hace referencia a una debilidad en un sistema permiti endo a un atacante violar la confi dencialidad, integridad, disponibilidad, control de ac-ceso y consistencia del sistema o de sus datos y aplicaciones. Las vulnerabilidades son el resultado de bugs o de fallos en el sistema. (Un bug es un error o fallo en un programa de com-putador o sistema de soft ware que desencadena un resultado indeseado).

Aunque, en un senti do más amplio, también pueden ser el resultado de las propias limitaciones tecnológicas, porque, en principio, no existe sistema 100% seguro.

Por lo tanto existen vulnerabilidades teóricas y vulnerabili-dades reales. Las vulnerabilidades en las aplicaciones suelen corregirse con parches, “hotf ixs” o con cambios de versión. Algunas otras requieren el cambio fí sico de un componente.

Las vulnerabilidades se descubren muy a menudo en grandes sistemas, y el hecho de que se publiquen rápidamente por todo Internet (mucho antes de que exista una solución al pro-blema), es moti vo de debate.

Cuanto más conocida se haga una vulnerabilidad, más proba-bilidades hay de que existan individuos u organizaciones mali-ciosas que puedan aprovecharse de ella.

Algunas vulnerabilidades tí picas suelen ser:

• Buff er Overfl ow• Ejecución de código remoto• Escalada de privilegios• DoS (denegación de servicio)• Vulnerabilidades en el servidor Web• Autenti fi cación y Gesti ón de contraseñas

Existe una lista de información registrada sobre conocidas vul-nerabilidades de seguridad. Dicha lista recibe el nombre de CVE (“Common Vulnerabiliti es and Exposures” por sus siglas en inglés). Cada referencia ti ene un número de identi fi cación único.

De esta forma provee una nomenclatura común para el co-nocimiento público de este ti po de problemas y así facilitar la comparti ción de datos sobre dichas vulnerabilidades.

La lista fue defi nida y es mantenida por The MITRE Corpora-ti on (por eso a veces a la lista se la conoce por el nombre MI-TRE CVE List) con fondos de la Nati onal Cyber Security Division del gobierno de los Estados Unidos de América. Forma parte del llamado Security Content Automati on Protocol.

¿QUÉ ES VULNERABILIDAD?


12

La información y nomenclatura de esta lista es usada en la Nati onal Vulnerability Database, el repositorio de los Estados Unidos de América de información sobre vulnerabilidades.

Una vulnerabilidad recién descubierta, para que sea incorpo-rada totalmente al listado, ti ene que seguir un proceso que consta de tres etapas:

• Etapa de presentación inicial• Etapa de candidatura• Etapa de ingreso en la lista (si es que la candidatura es aceptada)

Por esta razón, la lista CVE no ti ene vulnerabilidades de día cero (recién descubiertas).


13

METODOLOGÍAComo se ha indicado, el objeti vo de este informe es obtener un panorama general de las característi cas de las vulnerabi-lidades de los ICS. Para ello, primero se ha hecho una selec-ción de principales fabricantes con el objeto de obtener una muestra razonablemente aceptable de aquellos con un mayor grado de implantación en nuestro país.

Los fabricantes seleccionados han sido los siguientes:

El ICS-CERT (“The Industrial Control Systems Cyber Emergency Response Team”) trabaja para reducir los riesgos dentro y a través de todos los sectores de infraestructuras críti cas me-diante la asociación entre los organismos policiales y servicios de inteligencia, y coordinando esfuerzos entre las autoridades estatales y propietarios, operadores y proveedores de siste-mas de control industrial. Además, el ICS-CERT colabora con el sector internacional y privado “Computer Emergency Res-

ponse Teams (CERTs)” para comparti r incidentes de seguridad relacionados con los sistemas de control industrial y medidas de miti gación. El ICS-CERT opera dentro del Nati onal Cyberse-curity and Integrati on Center (NCCIC) que es una división del Departamento de Seguridad Nacional de los EEUU.

A conti nuación, para cada uno de los fabricantes anteriores, se ha tomado como fuente de información todas las CVE de la web del ICS-CERT publicadas desde Enero de 2014 hasta Julio de 2015. Este organismo se encarga de, entre otras cosas, ges-ti onar la publicación de vulnerabilidades y de recopilar las so-luciones que los fabricantes dan para las mismas pero, en este caso, en el área de los sistemas de control industrial. Como los ataques a infraestructuras de carácter industrial empiezan a generar cierta preocupación, los investi gadores se encargan de avisar al fabricante en caso de encontrarse vulnerabilida-des y éste, a su vez, de publicar una solución que resuelva el problema a sus clientes.

Dada la importancia y relevancia del ICS-CERT dentro del mun-do de la ciberseguridad industrial, ha sido seleccionado como fuente de la información necesaria para la realización del pre-sente estudio [9].

Los parámetros de información que se han extraído de cada vulnerabilidad publicada en la web del ICS-CERT se pueden observar en la tabla siguiente:

ABB

GE (GENERAL ELECTRIC)

HONEYWELL

OMRON

ROCKWELL AUTOMATION

SCHNEIDER ELECTRIC

SIEMENS

YOKOGAWA


15

A conti nuación, se ha sacado de esta lista aquellos fabricantes que no fi guran en la muestra de estudio, quedando:

Luego, aplicando la fórmula:

%Cuota normalizada = 100 x Cuota (%) / 42,5

Se ha obtenido la siguiente esti mación normalizada:

Para tener un orden de magnitud de la cuota de mercado que poseen los principales fabricantes de sistemas de control in-dustrial seleccionados, se ha uti lizado una esti mación que se hizo en el año 2008 y que fue publicada por el “Business Wire (a Berkshire Hathaway Company)” [10]. La esti mación que ha servido de base conti ene otras muchas empresas que forman parte del mercado.

Como en el presente estudio solo se hace referencia a los fa-bricantes anteriormente enunciados, se ha normalizado dicha esti mación solo para ellos y el resto se ha sacado fuera del estudio.

Para realizar la normalización se ha parti do de los siguientes datos:

ABBGEHoneywellOmronRockwell Automati onSchneider ElectricSiemens

19943

131438

Fabricante Cuota Normalizada(%)

SiemensABBSchneider ElectricRockwell Automati onEmersonGEMitsubishi ElectricEaton ElectricHoneywellOmronOtros

16,08,06,05,55,04,03,52,01,51,5

47,0

Fabricante Cuota (%)

SiemensABBSchneider ElectricRockwell Automati onGEHoneywellOmron

16,08,06,05,54,01,51,5

42,5

Fabricante Cuota (%)


16

No se ha mostrado cuota de mercado para la empresa Yoko-gawa debido a que no se dispone de datos.Para realizar una clasifi cación por ti po de componente en el que aparece la vulnerabilidad se han uti lizado los parámetros mostrados en la tabla anterior: SCADA/HMI, Protocolo, PLC, Otro hardware y Otro soft ware. Debido a su importancia en la industria, aunque SCADA/HMI es también soft ware y PLC es también hardware, se han considerado de forma indepen-diente, por lo que todo lo que no sea PLC o SCADA/HMI, se ha considerado como ”Otro hardware” u “Otro soft ware”. Al-gunos ejemplos de “Otro soft ware” serían: uti lidades y herra-mientas de ingeniería diseñadas para programar y confi gurar procesos, máquinas y aplicaciones de control general; pro-ductos para PC para programar y simular sistemas; soft ware de desarrollo para probar, depurar y gesti onar aplicaciones; soft ware para desarrollar, confi gurar y comisionar maquina-ria automati zada; soft ware de instalación para dispositi vos de control de motores; servidores que proveen información de contenido industrial que incluye gráfi cos del proceso, tenden-cias e informes en una página web; soft ware de sistemas de gesti ón de alarmas, etc. Por otra parte, algunos ejemplos de “Otro hardware” serían: todo ti po de “Switches”, “Control pa-nels”, “Media Converters”, “Serial Device Servers”, toda clase de “Modems”, “Power over Ethernet Injectors”, etc.

Para analizar qué ti po de vulnerabilidades se suelen dar en los ICS se han uti lizado los siguientes términos:

• BUFFER OVERFLOW: Consiste en una anomalía en un programa que desborda los límites del búfer al escribir datos. Este defecto de seguridad permite que el atacante no sólo pueda poner fi n al programa

prematuramente, sino que también pueda ejecutar código ar-bitrario en el sistema de desti no, con las graves consecuencias que ello podría ocasionar en el sistema de control de cual-quier instalación.

• EJECUCIÓN DE CÓDIGO REMOTO:La ejecución de código remoto se usa para describir la capa-cidad de un atacante para ejecutar cualquier comando que quiera en otro equipo. Luego la vulnerabilidad de ejecución de código remoto se uti liza para describir un error de soft ware que le proporciona al atacante una manera de ejecutar código arbitrario en otra máquina generalmente a través de Internet.

• WEB (SERVIDOR): Un servidor no es más que un dispositi vo que responde a soli-citudes de un cliente, normalmente es un ordenador que con-ti ene información para ser comparti da con muchos sistemas de clientes. También suele llamarse servidor al soft ware que se encarga de escuchar y responder a las llamadas de los clien-tes. Un ejemplo sería un soft ware que se encarga de gesti onar las peti ciones de acceso a una página Web, es decir, un ser-vidor Web. Estos servidores cuentan con una lista central de cuentas de usuarios y autorizaciones, o permisos (para reali-zar operaciones y de acceso a datos) otorgados a cada usuario que pueden ser violadas (vulnerabilidad).

• ESCALADA DE PRIVILEGIOS: Es la acción de explotación de un error, defecto de diseño o la supervisión de confi guración en un sistema operati vo o apli-cación de soft ware para obtener acceso elevado a los recur-sos que normalmente están protegidos desde una aplicación o usuario. El resultado se traduce en que una aplicación con


17

más privilegios que el desarrollador de la misma o el admi-nistrador del sistema puede realizar acciones no autorizadas.

• DoS (DENEGACIÓN DE SERVICIO): Causa que un servicio o recurso sea inaccesible a los usuarios legíti mos. Normalmente provoca la pérdida de la conecti vidad de la red por el consumo del ancho de banda de la red de la vícti ma o sobrecarga de los recursos computacionales del sistema de la vícti ma. Se genera mediante la saturación de los puertos con fl ujo de información, haciendo que el servidor se sobrecargue y no pueda seguir prestando servicios; por eso se le denomina “denegación”, pues hace que el servidor no dé abasto a la canti dad de solicitudes.

• AUTENTIFICACIÓN/GESTIÓN DECONTRASEÑAS (APARENTEMENTE, NO PARECE LÓGICO UNIR CATEGORÍAS, PERO EL ICS-CERT LO HACE ASÍ): Defi ciencias en el mecanismo principal de autenti cación que con mayor frecuencia se presentan a través de las funciones auxiliares de autenti cación como el cierre de sesión, gesti ón de contraseñas, expiración de sesión, recuérdame, pregun-ta secreta y actualización de cuenta. Estos defectos pueden conducir a un robo de usuarios o cuentas de administración, sabotaje de los controles de autorización y registro, causando violaciones a la privacidad.Para estudiar qué nivel de riesgo presentan las vulnerabilida-des publicadas por los principales fabricantes, hemos realiza-do un estudio tomando como referencia la puntuación CVE (CVSS v2 Base Score) extraída de la web del “Nati onal Vulne-rability Database” (NVD) [11].El NVD es una base de datos del gobierno de Estados Unidos sobre normati va de gesti ón de datos de vulnerabilidades.

Estos datos permiten la automati zación de la gesti ón de las vulnerabilidades, medidas de seguridad y cumplimiento.La caracterización del nivel de riesgo se ha hecho en base al siguiente criterio de puntuación:

Para obtener la puntuación y con ello, según en qué intervalo se encuentre, saber el nivel de riesgo de la correspondiente vulnerabilidad, el NVD uti liza las siguientes ecuaciones y cri-terios:

CVSS Base Score Equati on

BaseScore = (.6*Impact +.4*Exploitability-1.5)*f (Impact) Impact = 10.41 * (1 - (1 - ConfImpact) * (1 - IntegImpact) * (1 - AvailImpact))

Exploitability = 20 * AccessComplexity * Authenti cati on * AccessVector

f(Impact) = 0 if Impact=0; 1.176 otherwise

Nivel de riesgo de la vulnerabilidad Intervalo CVSS Base Score

0 - 44 - 7

7,1 - 10

bajomedio

alto


18

AccessComplexity = case AccessComplexity ofhigh: 0.35medium: 0.61low: 0.71

Authenti cati on = case Authenti cati on ofRequires no authenti cati on: 0.704Requires single instance of authenti cati on: 0.56Requires multi ple instances of authenti cati on: 0.45 AccessVector = case AccessVector of

Requires local access: 0.395Local Network accessible: 0.646

Network accessible: 1

ConfImpact = case Confi denti alityImpact ofnone: 0parti al: 0.275complete: 0.660

IntegImpact = case IntegrityImpact of

none: 0parti al: 0.275

complete: 0.660

AvailImpact = case AvailabilityImpact of none: 0 parti al: 0.275 complete: 0.660

CVSS Temporal Equati on

TemporalScore = BaseScore * Exploitability * Remediati onLevel * ReportConfi dence Exploitability = case Exploitability of unproven: 0.85 proof-of-concept: 0.9 functi onal: 0.95 high: 1.00 not defi ned 1.00 Remediati onLevel = case Remediati onLevel of offi cial-fi x: 0.87 temporary-fi x: 0.90 workaround: 0.95 unavailable: 1.00 not defi ned 1.00


19

ReportConfi dence = case ReportConfi dence of unconfi rmed: 0.90 uncorroborated: 0.95 confi rmed: 1.00 not defi ned 1.00

CVSS Environmental Equati on

EnvironmentalScore = (AdjustedTemporal + (10 – Adjusted-Temporal * CollateralDamagePotenti al) * TargetDistribu-ti on AdjustedTemporal = TemporalScore recomputed with the Impact sub-equati on replaced with the following AdjustedImpact equati on. AdjustedImpact = Min(10, 10.41 * (1 - (1 - ConfImpact * ConfReq) * (1 - IntegImpact * IntegReq) * (1 - AvailImpact * AvailReq))) CollateralDamagePotenti al = case CollateralDamagePoten-ti al of none: 0 low: 0.1 low-medium: 0.3 medium-high: 0.4 high: 0.5

not defi ned: 0

TargetDistributi on = case TargetDistributi on of none: 0 low: 0.25 medium: 0.75 high: 1.00 not defi ned: 1.00

ConfReq = case Confi denti alityImpact of Low: 0.5 Medium: 1 High: 1.51 Not defi ned 1

IntegReq = case IntegrityImpact of Low: 0.5 Medium: 1 High: 1.51 Not defi ned 1 AvailReq = case AvailabilityImpact of

Low: 0.5 Medium: 1 High: 1.51

Not defi ned 1


20


The CVSS Overall Score is part of the NVD and is not part of the CVSS standard.

En el CVSS v2 Base Score se toman como elementos de juicio parámetros como la mayor o menor facilidad de acceso al ICS, la existencia de parches o soluciones que reduzcan la vulnera-bilidad y el perfi l informáti co del atacante entre otros. Así por ejemplo, si la vulnerabilidad no presenta solución alguna, se puede acceder fácilmente al ICS y el perfi l de conocimiento in-formáti co del atacante para explotar la vulnerabilidad es bajo, se puede considerar que el nivel de riesgo de la vulnerabilidad es alto. A conti nuación, con todos los datos recopilados se ha procedido a elaborar un estudio estadísti co con la fi nalidad

de obtener conclusiones que den una respuesta aproximada a las cuesti ones siguientes: saber qué nivel de habilidad ne-cesita un atacante para explotar la vulnerabilidad con éxito, qué método uti liza, quién descubre las vulnerabilidades en los ICS, qué solución para eliminar o reducir la amenaza adoptan las empresas, corporaciones, organizaciones…, si las vulnera-bilidades detectadas se pueden explotar de forma remota, si existen “Exploits” publicados que puedan proporcionar méto-dos de ataque ya implementados, la miti gación recomendada por el fabricante o, incluso, qué ti po de ICS es más vulnerable.


Calculate OverallScore

=

OverallScore =

OverallScore

BaseScore

=

Return OverallScore

OverallScore

Enviro-mentalScore

TemporalScore

NO

YES

NO

NO

YES

YES


21

RESULTADOS5.1 / CUOTA DE MERCADO Y VULNERABILIDADES PUBLICADAS POR FABRICANTE

5.2 / VULNERABILIDADES POR COMPONENTE


22

5.3 / TIPO DE DESCUBRIDOR DE LA VULNERABILIDAD

5.4 / TIPO DE VULNERABILIDAD

ABB

GE

Honeywell

Omron

RockwellAutomati on

Schneider Electric

Siemens

Yokogawa

1

1

0

0

1

10

0

2

1

2

1

0

0

13

6

0

0

1

3

2

0

1

4

1

0

0

0

0

1

3

14

0

0

2

1

0

2

2

21

9

1

0

0

0

2

3

22

0

3

6

5

2

6

34

67

12

Bufferoverfl ow

Ejecución de código

remotoWeb

(servidor)Escala

deprivilegios

DoS(denegación de servido)

Autentifi cación gestión de

contraseñas Total

Figura 8. Número de vulnerabilidades según ti po y fabricante


23

5.5 / VULNERABILIDADES CON SOLUCIÓN PROPUESTA

ABBGEHonneywellOmronRockwell Automati onSchneider ElectricSiemensYokogawa

05525

356611

Soft ware o Firmwareactualizado

Canti dad de CVE publicadas

31001011

Sin soluciónpropuesta

Figura 12. CVE publicadas con y sin solución propuesta, por fabricante.


24


25

5.6 / TIPO DE MITIGACIÓN RECOMENDADA POR EL FABRICANTE

5.7 / ABUSO REMOTO DE LA VULNERABILIDAD


26

5.8 / VULNERABILIDADES CON “EXPLOITS” PUBLICADOS


27

5.9 / “EXPLOITS” PUBLICADOS VS PARCHES DESARROLLADOS

5.10 / NIVEL DE HABILIDAD REQUERIDO DEL ATACANTE


28

5.11 / NIVEL DE RIESGO DE LAS VULNERABILIDADES


29

ANÁLISIS

6.1 / NÚMERO DE VULNERABILIDADES PUBLICADAS

Siguiendo la metodología descrita, se han contabilizado 136 CVE desde Enero de 2014 hasta Julio de 2015 para la muestra de fabricantes tomada del ICS-CERT [9]. Dicho número con-trasta con las 10.000 CVE publicadas en el mismo periodo de ti empo en el ámbito TI [12].

6.2 / ANÁLISIS DE LA CUOTA DE MERCADO

Siemens ti ene un peso muy importante en este mercado, se-guido del fabricante suizo ABB y Schneider Electric (véase la fi gura 1). Por otra parte, cabe destacar que el mayor porcen-taje de vulnerabilidades publicadas corresponde al fabricante alemán Siemens, seguido de Schneider Electric.

El 76% de las vulnerabilidades publicadas pertenece a estas dos grandes empresas (véase la fi gura 2), mientras que su cuota de mercado combinada es del 52%. Posiblemente, las marcas conocidas atraen más la atención de los investi gado-res. Comparando las fi guras 1 y 2, se puede observar que se publican muchas vulnerabilidades del fabricante Schneider Electric comparado con la cuota de mercado que posee (14%). Por el contrario, el fabricante suizo ABB posee una alta cuota de mercado (19%), en cambio, se publican muy pocas vulne-rabilidades sobre sus productos (2%).

6.3 / ¿DÓNDE SE DESCUBREN LAS VULNERABILIDADES?

Si analizamos ahora la proporción de vulnerabilidades publi-cadas por ti po de componente ICS, el 40% de las vulnerabili-dades se encuentra en soft ware desarrollado para mejorar sis-temas de control industrial (“Otro soft ware”) (véase la fi gura 3). Tal vez se encuentre mayor número de vulnerabilidades en los elementos ti po soft ware que en hardware debido a que se necesitan menos recursos para encontrar en ellos defi ciencias y debilidades de seguridad (Es más fácil tener acceso a soft -ware que a hardware). Un 24% del total de las vulnerabilida-des estudiadas aparecen en equipos SCADA (en su respecti vo soft ware y aplicaciones) y en sistemas HMI.

6.4 / ¿QUIÉN DESCUBRE LAS VULNERABILIDADES?

La gran mayoría de las vulnerabilidades (61%) son descubier-tas y reportadas por empresas externas de seguridad, seguida en menor medida por investi gadores independientes con un 20%. Por el contrario, tan solo un 14% de las vulnerabilidades publicadas son descubiertas por los propios fabricantes (véa-se la fi gura 5).


30

6.5 / ¿QUÉ TIPO DE VULNERABILIDADES SE DESCUBREN?

El ti po de vulnerabilidad que más se da en los sistemas de con-trol industrial en general es la denegación de servicio (DoS) con un 29% del total de las vulnerabilidades estudiadas se-guido por Autenti fi cación/Gesti ón de contraseñas con un 21% (véase la fi gura 7).

Cabe destacar que el 71% de las vulnerabilidades que apare-cen en PLC corresponden a DoS y que, de forma combinada (DoS + Autenti fi cación/Gesti ón de contraseñas) consti tuyen más del 80% de las vulnerabilidades aparecidas en otro hard-ware.

El 60% de las vulnerabilidades aparecidas en Protocolo corres-ponden a Buff er Overfl ow y el 53% de las vulnerabilidades en Otro hardware corresponde a la Autenti fi cación/Gesti ón de contraseñas.

6.6 / SOLUCIONES

Si se estudia ahora si las empresas buscan y desarrollan solu-ciones para poner remedio a las vulnerabilidades de sus ICS, vemos que para el 95% de los casos estudiados existe un par-che que elimina o reduce la vulnerabilidad (véase la fi gura 11). Un parche consta de cambios que se aplican a un programa para corregir errores, agregarle funcionalidad, actualizarlo, etc. Este signifi cati vo 95% denota un interés por parte de las empresas en dedicar recursos para desarrollar soluciones que eviten que los productos que lanzan al mercado se vean com-prometi dos por ciberataques. Siemens y Schneider Electric

son los dos fabricantes que mayor número de parches desa-rrollan (véase la fi gura 12), pero también hay que tener en cuenta que son los que más vulnerabilidades en sus sistemas de control industrial presentan. El 99% de las vulnerabilidades detectadas en estos fabrican-tes posee un parche. Por otra parte, ABB no presenta ningún ti po de parche para solucionar o al menos reducir el efecto de las vulnerabilidades publicadas sobre sus sistemas de control industrial (véase las fi guras 12 y 13), aunque ti ene un % bajo comparado con su cuota de mercado. Si se observa ahora para cada ti po de sistema de control industrial, a qué proporción de sus vulnerabilidades se les desarrolla algun ti po de parche y a qué proporción no se les da ninguna solución, llama la aten-ción que para el 60% de las vulnerabilidades detectadas en Protocolo no se desarrolle ningún ti po de parche. Yendo más allá, si se analiza las vulnerabilidades sin solución propuesta, se puede observar que el 86% pertenecen a la combinación Hardware + Protocolo, siendo Hardware = PLC + Otro hard-ware. El 14% restante corresponde a Soft ware = SCADA + Otro soft ware. Dichos datos denotan la difi cultad para parchear “Hardware que posea vulnerabilidades”, debido posiblemen-te a la larga vida de los equipos y la interdependencia espe-cialmente en protocolos. Por ejemplo, si se ti ene que cambiar de Protocolo implica cambiar Hardware, y viceversa (véase la fi gura 16).

Aparte de las soluciones propuestas, los fabricantes dan re-comendaciones para reducir o eliminar por completo las vul-nerabilidades de sus sistemas de control industrial. Para ello, estos uti lizan mayoritariamente tres estrategias:

• Completo aislamiento del ICS vulnerable


31

• Actualización de las versiones nuevas del componente y aislamiento completo de las viejas y desfasadas para las cuales el parche no se puede instalar por problemas de compati bilidad

• Actualización del componente con el parche desarrollado y aislamiento de refuerzo (opcional recomendado) como doble medida de seguridad

Para resolver el 91% de las vulnerabilidades presentadas en los sistemas de control industrial se recurre a la actualización de soft ware y a la adopción de estrategias de defensa comple-mentarias. Por el contrario, se recurre a completo aislamiento para el 5% de los casos, que coincide con el 5% del total de las vulnerabilidades para las cuales no existe parche (véase la fi gura 17).

Si observamos para cada componente qué clase de miti gación recomienda el fabricante, resulta interesante ver como en el 60% de los casos de vulnerabilidades en Protocolo correspon-den a total aislamiento (véase la fi gura 19), ya que los fabri-cantes no desarrollan parches para eliminar el 100% de las vulnerabilidades y la única solución que le queda al cliente es aislar por completo este ti po de componente para que no pueda ser atacado.

6.7 / POSIBILIDAD DE ABUSO REMOTO

Otro punto interesante sería analizar si toda esta serie de vul-nerabilidades publicadas se pueden explotar de forma remo-ta. Para sacar parti do de una vulnerabilidad remotamente el atacante debe uti lizar una red de comunicaciones para entrar en contacto con el sistema vícti ma. Por ejemplo, puede usar

otro equipo dentro de la misma red interna o tener acceso desde la propia Internet. Si las vulnerabilidades que presentan los ICS se pueden explotar de forma remota, los ciberatacan-tes podrían ejecutar una serie de comandos remotos que, de ser usados de forma maliciosa, podrían comprometer la segu-ridad de los dispositi vos y de la información que almacenan, e incluso podrían suponer el control total de los mismos.

El 84% de las vulnerabilidades de los ICS estudiadas se pueden explotar de forma remota (véase la fi gura 20). Dicha cifra es muy elevada y resulta preocupante, ya que supone que la ma-yor parte de estos dispositi vos se pueden atacar a distancia, sin tener el atacante que estar presente fí sicamente o estar cerca de la industria donde pueden estar instalados. 6.8 / EXISTENCIA DE EXPLOITS

Otro tema importante a abordar sería si las vulnerabilidades estudiadas poseen “Exploits” que son publicados y pueden proporcionar al ciberatacante métodos ya implementados para tener éxito en su ataque.

Exploit (del inglés to exploit, “explotar” o “aprovechar”) es un fragmento de soft ware, fragmento de datos o secuencia de comandos y/o acciones, uti lizada con el fi n de aprovechar una vulnerabilidad de seguridad de un sistema de información para conseguir un comportamiento no deseado del mismo [13]. Algunos ejemplos: acceso de forma no autorizada, toma de control de un sistema de cómputo, consecución privilegios no concedidos lícitamente, consecución de ataques de dene-gación de servicio, etc. Los Exploits pueden tomar forma en disti ntos ti pos de soft ware, como por ejemplo scripts, virus informáti cos o gusanos informáti cos.


32

Según el estudio realizado, el 18% de las vulnerabilidades en los ICS publicadas cuentan con “Exploits” públicos (véase la fi gura 22). En cambio, en el ámbito TI, el 38,4% de las vul-nerabilidades reportadas cuentan con “Exploits” publicados, (véase la web “Exploit Database” [14]).

No se publica ningún “Exploit” para vulnerabilidades detecta-das en PLC a pesar de suponer el 18% de las vulnerabilidades analizadas (véase la fi gura 24), lo cual es una buena noti cia y facilita mucho las cosas desde el punto de vista de la ciberse-guridad tanto para los fabricantes como para los clientes, ya que se trata de un dispositi vo muy extendido en la industria. Quizá esto se deba a la necesidad de conocimientos muy es-pecífi cos.

Si ahora relacionamos la existencia de “Exploits” publicados con la canti dad de parches desarrollados por las empresas para corregir una vulnerabilidad, se obti ene que el 77% de las vulnerabilidades de los ICS que ti enen un parche desarrollado no poseen “Exploits” publicados que puedan ser usados por los atacantes (véase la fi gura 25), lo cual es positi vo para las empresas fabricantes.

Situaciones de riesgo: (No parche + Exploit) y (No par-che + No Exploit), las cuales sumadas tan solo consti tu-yen el 5% de los casos.

Situaciones de riesgo inminente: (Parche + Exploit) y (No parche + Exploit), las cuales sumadas consti tuyen

el 19% de los casos. Esto denota la importancia de mantener actualizados estos sistemas.

Caso de riesgo extremo: (No parche + Exploit). Tan solo consti tuye un 1%.

El 18% de los casos poseen parche pero ningún Exploit publi-cado. Puede que para estos casos sí haya Exploits pero que no sean conocidos, o puede que se desarrollen en un futuro.

Si se analiza las vulnerabilidades de los ICS con Exploits pu-blicados contra la existencia de parche por componente, se puede observar que “el caso de riesgo extremo” (No parche + Exploit) se da solo en vulnerabilidades aparecidas en Protoco-lo. Parece ser que el riesgo se concentra en este ti po de com-ponente debido a problemas de actualización (compati bilidad con hardware). (Véase la fi gura 26).

6.9 / HABILIDAD REQUERIDA

Otro factor muy importante de cara a poder visionar un mo-delo de posibles amenazas sería el nivel de habilidad que debe poseer el atacante para explotar con éxito la vulnerabi-lidad. Según los resultados obtenidos, un 47% de las vulnera-bilidades analizadas requieren un perfi l de atacante bajo en conocimientos de hacking (véase la fi gura 27).

Por familias de productos, en la fi gura 29 se observa que Pro-tocolos y PLC destacan por requerir un nivel de conocimientos superior al resto de productos. Las característi cas propias de


33

estos componentes de los ICS hacen que, a la vez que sea di-fí cil parchear sus vulnerabilidades (combinadas suman el 72% de las vulnerabilidades sin parche), sea difí cil explotarlas.

6.10 / NIVEL DE RIESGO

Según la información extraída del NVD y posteriormente pro-cesada, la mayor parte de las vulnerabilidades detectadas en los principales fabricantes de sistemas de control industrial poseen un riesgo medio (véase la fi gura 30). Destacar que el nivel de riesgo de las vulnerabilidades que presentan los PLC

es mayoritariamente alto, con un 54%, seguido de un 46% de riesgo medio y un 0% de riesgo bajo (véase la fi gura 31).

En la categoría de Otro hardware tampoco hay vulnerabilida-des con riesgo bajo. Estos equipos se encuentran en la inter-faz con los procesos y el mundo fí sico. Por otra parte, el 43% de las vulnerabilidades de los ICS sin solución propuesta pre-sentan un riesgo alto (véase la fi gura 32). Dicho factor resulta preocupante y hace que el total aislamiento del ICS sea la úni-ca solución facti ble o no para evitar ciberataques, como ya se ha comentado previamente en el punto 5.6.


34

El análisis realizado muestra en primer lugar, lo incipiente de la investi gación de vulnerabilidades en componentes de ICS a nivel mundial. Y esa es la primera conclusión. La compara-ción entre el número de vulnerabilidades publicadas por el ICS-CERT durante el periodo analizado con su equivalente TI no deja lugar a dudas: 136 frente a aproximadamente 10.000. Eso quiere decir, básicamente, que la mayor parte de las vul-nerabilidades potenciales existentes en ICS están esperando todavía a ser descubiertas y consti tuyen, por tanto, una ame-naza latente para los usuarios de estos sistemas y las organi-zaciones que dependen de ellos. A pesar de todo, la muestra adquirida permite obtener importantes pistas acerca de cómo afrontar la seguridad de estos sistemas y las infraestructuras críti cas en los que integran.

Como se ha visto, tan sólo el 14% son descubiertas por los propios fabricantes. Es importante tener esto en mente en un sector en el que, en muchos casos, los operadores de las infraestructuras temen las implicaciones de la intervención de terceros especialistas en ciberseguridad en las garantí as y contratos de mantenimiento suscritos con los fabricantes. A la vista de los resultados, parece evidente que no cabe es-perar que la solución provenga, exclusivamente, de los que diseñaron, implementaron y, en muchos casos, manti ene los sistemas como contrata externa.

La mayor parte de las vulnerabilidades se descubre en soft -ware asociado al soft ware SCADA, incluyendo su diseño,

explotación y mantenimiento. En nuestra opinión hay que ser prudentes, ya que puede existi r un sesgo difí cil de cuanti fi car. Como se ha dicho, la mayor parte de las vulnerabilidades no son descubiertas por los fabricantes que son los que ti enen acceso fácil a su propia gama de productos. Parece evidente que para un tercero es más sencillo evaluar un soft ware que tener acceso para investi gación a equipamiento fí sico muy costoso.

Más interesante es ver cómo la mayor parte de las vulnerabili-dades se clasifi can como de denegación de servicio o autenti -cación: un 40% que asciende a un 80% en el caso de hardware y protocolos. Esto puede tener su origen en que el sector no ha adoptado, todavía, las prácti cas de desarrollo seguro que ya consti tuyen estándares en el sector TI. Esta situación es es-pecialmente grave si se combina con el hecho de que, mien-tras que el 95% de las vulnerabilidades posee un parche, el 86% de las que no lo ti enen se han hallado precisamente en las categorías de hardware o protocolo. Esto es lógico ya que, en principio, el soft ware es más fácil de parchear que el propio hardware. Por un lado existen interdependencias: en general no es posible susti tuir un protocolo por una versión segura del mismo si los equipos que se comunican haciendo uso de ese protocolo no pueden recibir la actualización correspondiente de hardware. En segundo lugar, las largas vidas úti les de los equipos en el ámbito industrial hacen que muchos dispositi -vos, diseñados hace incluso décadas, no dispongan de medios para actualizar el fi rmware.

CONCLUSIONES


35

Es más, especialmente en sistemas actuales pueden existi r multi tud de equipos muy específi cos (por ejemplo, sondas o instrumentación) procedentes de disti ntos fabricantes y basta con que uno de ellos no disponga de la opción para que sea imposible modifi car el sistema. Como conclusión: en un siste-ma ICS no existen soluciones sencillas ni generalizables y, en muchos casos, se debe recurrir a medidas complementarias, tanto técnicas como procedimentales y organizati vas.

Existe una correlación entre la difi cultad de parchear compo-nentes de hardware y protocolos y la existencia de exploits públicos: A pesar de suponer el objeto de un 18% de las vul-nerabilidades, no existe un solo exploit público dirigido contra PLC. Probablemente la razón sea el grado de conocimiento técnico especializado requerido para atacar estos sistemas: las mismas razones que hacen difí cil parchear el hardware de los componentes de los ICS hacen difí cil crear exploits. En ge-neral, el 82% de las vulnerabilidades publicadas no poseen, en el momento de redactar este informe, exploits públicos. No obstante, confi ar la protección de las infraestructuras críti cas a este hecho no es más que perseverar en el desa-creditado paradigma de la seguridad por oscuridad: que se requiera conocimiento especializado no quiere decir que no sea posible adquirirlo, especialmente para individuos que han fi jado como objeti vo un sistema en parti cular (ya se vio en el III Informe de Protección de Infraestructuras Críti cas la gran canti dad de información pública de valor libremente accesible a través de Internet).

Y es que la famosa convergencia IT/OT ha hecho que un sor-prendente 47% de las vulnerabilidades publicadas requieren

de un nivel de conocimiento especializado bajo, según los cri-terios del ICS-CERT. Este hecho, combinado con que 87% están califi cadas como de riesgo alto nos ponen ante la verdadera magnitud del reto a que nos enfrentamos: sin ser alarmistas, la situación actual podría compararse con la de estar sentados sobre un barril de pólvora, especialmente al recordar que es-tos equipos se encuentran directamente en la interfase entre los sistemas de información y el mundo fí sico.

Y es que hay muchas cosas que hacer. La más obvia es actuar en aquello que está en nuestra mano. El análisis ha puesto de manifi esto la importancia del parcheo. A pesar de las difi -cultades que entraña y las entendibles renuencias basadas en las posibles incompati bilidades de las actualizaciones con los sistemas en explotación, para el 95% de las vulnerabilidades existen actualizaciones proporcionadas por los fabricantes. El hecho de que exista un 19% de vulnerabilidades para las que hay simultáneamente un parche y un exploit pone de mani-fi esto el riesgo a que se enfrenta una organización que decida no instalarlos o que, directamente, desconozca que tales so-luciones existan (algo muy común en organizaciones que ca-recen de una estructura de seguridad de los ICS que permita estar al corriente de estas noti cias). La buena noti cia en este caso es que tan sólo en 1% de los casos existen exploits sin una actualización ofi cial.

Por últi mo, el análisis también arroja pistas acerca de la im-portancia de la monitorización: el 84% de las vulnerabilidades analizadas son explotables de forma remota. Dado que los sistemas de nuestras infraestructuras críti cas ya no pueden prescindir de sus accesos remotos y la integración en redes,


36

la segmentación y la vigilancia en busca de anomalías (que no el aislamiento, otra noción de seguridad errónea) son par-te fundamental de la protección. A este respecto, no está de más recordar la creciente exposición de los ICS desde la apari-ción de herramientas como SHODAN, algo que ya se puso de manifi esto en el II informe de Protección de Infraestructuras Críti cas.

En defi niti va, el resultado del análisis nos lleva a considerar como esenciales las siguientes premisas para conseguir un ni-vel adecuado de protección de los ICS de las infraestructuras críti cas:

1. Llevar a cabo una búsqueda independiente de las vulne-rabilidades potenciales de los ICS. Esto se debe hacer, nece-sariamente, de forma coordinada con los proveedores de los sistemas, pero sin esperar a que se nos ofrezca la solución. Las vulnerabilidades ya están ahí, no ti ene senti do esperar.

2. Disponer de una estructura dedicada a la gesti ón de la se-guridad de los ICS que permita gesti onar la instalación de los parches existentes de forma segura y que establezca y super-vise medidas complementarias de protección en los casos en los que no existan aquellos.

3. Incorporar la seguridad al proceso proyecto-construcción, de forma que la existencia de vulnerabilidades, parches o la posibilidad de actualización (o el compromiso del fabricante) consti tuya un factor en la adquisición de un sistema. Lo mis-mo es de aplicación en la compra de soft ware específi co o, incluso, en el desarrollo de soft ware a medida.

4. Monitorizar la seguridad de los ICS para detectar de forma precoz cualquier anomalía tan pronto como se presente. La singularidad de estos sistemas recomienda que el dispositi vo de monitorización y el personal encargado del mismo conoz-ca los procesos y sistemas de la infraestructura con el fi n de poder caracterizar adecuadamente las situaciones de riesgo.


37

[1]”To kill a centrifugate” (Noviembre 2013).htt p://www.langner.com/en/wp-content/uploads/2013/11/To-kill-a-centrifuge.pdf[Accedido el 14/01/2016]

[2] Información sobre Dragonfl y:htt ps://ics-cert.us-cert.gov/alerts/ICS-ALERT-14-176-02ª[Accedido el 3/11/2015]htt p://www.symantec.com/connect/blogs/emerging-threat-dragonfl y-energeti c-bear-apt-group [Accedido el 3/11/2015]

[3] Información sobre Sandworm:[htt ps://nakedsecurity.sophos.com/es/2014/10/15/the-sandworm-malware-what-you-need-to-know/][Accedido el 13/01/2016]

[4] Más información sobre el ataque a la fábrica de acero alemana:htt ps://ics.sans.org/media/ICS-CPPE-case-Study-2-German-Steelworks_Facility.pdf [Accedido el 3/11/2015]

[5] Más información sobre “Buff er Overfl ow”:[htt p://wiki.elhacker.net/bugs-y-exploits/overfl ows-y-shellco-des/buff eroverfl ow][Accedido el 13/01/2016]

[6] Estudio previo publicado por “Positi ve Technologies” el 29 de diciembre de 2014:[htt p://www.ptsecurity.com/upload/ptcom/SCADA_WP_A4.ENG.0018.01.DEC.29.pdf][Accedido el 13/01/2016]

[7] Más información sobre vulnerabilidad en ciberseguridad:[htt ps://www.codejobs.biz/es/blog/2012/09/07/seguridad-informati ca-que-es-una-vulnerabilidad-una-amenaza-y-un-riesgo][Accedido el 13/01/2016]

REFERENCIAS


38

[8] Más información sobre vulnerabilidades tí picas en “Anexo IV Vulnerabilidades más críti cas de los sistemas informáti cos” por Álvaro Gómez Vieites:[htt p://www.um.edu.ar/catedras/claroline/backends/down-load.php?url=L1Z1bG5lcmFiaWxpZGFkZXNfb eFzX2Ny7XRpY2FzX2RlX2xvc19zaXN0ZW1hc19pbmZvcm3hdGljb3MucGRm&cidReset=true&cidReq=SIIISR][Accedido el 13/01/2016]

[9] Web del ICS-CERT:[htt ps://ics-cert.us-cert.gov/advisories-by-vendor][Accedido el 14/01/2016]

[10] Esti mación de la cuota de mercado:[htt p://www.businesswire.com/news/home/20100514005709/en#.VYgXXnIViUk][Accedido el 22/06/2015]

[11] Esti mación del CVSS Base v2 Score (Nati onal Vulnerability Database):[htt ps://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-5430][Accedido el 18/09/2015]

[12] Número de vulnerabilidades publicadas en el ámbito TI: [htt ps://nvd.nist.gov/home.cfm][Accedido el 11/01/2016]

[13] Más información sobre “Exploit”:[htt ps://es.wikipedia.org/wiki/Exploit][Accedido el 14/01/2016]

[14] Información sobre Exploits publicados en el ámbito TI:[htt ps://es.wikipedia.org/wiki/Exploit][Accedido el 12/01/2016]

www.s2grupo.es

46022 V

BogotáT (571) 745 74 39

Carrera 11, Nº93A-53,

MéxicoT (52) 55 2128 0681

Praga 44-7, México D.F.06600

BarcelonaT (34) 933 030 060

Llull, 321 08019 Barcelona

MadridT (34) 902 882 992

Velázquez 150, 2ª planta28002 Madrid

ValenciaT (34) 963 110 300F (34) 963 106 086

alencia

protecciÓn de infraestructuras crÍticas...seguridad. su objeti vo es garanti zar los procesos y...

Documents