Sobre la certificación de la seguridad en una Industria Digitalizada

Una de las consecuencias más directas del Cibersecurity Act europeo de 2019 es dotar a la Unión de un sistema ágil, eficiente y confiable de certificación de productos, sistemas y procedimientos en al ámbito de la Industria 4.0. La certificación no es algo nuevo, lleva entre nosotros desde el mismo principio de la industrialización y sin embargo eso no ha impedido múltiples desastres industriales de importantes consecuencias. Ahora le toca a la Industria Digitalizada que todos desean y promueven, pero no está claro que, en esta ocasión, las certificaciones y las normalizaciones puedan aportar algo tan volátil como la seguridad en los sistemas digitales y de información. Queramos o no el proceso está en marcha, y es tiempo de prestarle atención.

El esquema Common Criteria (CC) nace en 1990 como un intento de fusión de esquemas de certificación anteriores: el ITSEC europeo desarrollado por Francia, Alemania, Holanda y Reino Unido, el CTCPEC canadiense inspirado en su homólogo del Departamento de Defensa norteamericano y, por último, el TCSEC norteamericano del citado Departamento de Defensa llamado “the Orange Book” dentro de lo que se conoció como las “Rainbow Series”.

La ventaja esencial de ese esquema de certificación es su vocación global plasmada en el Acuerdo de Reconocimiento Mutuo 1 que obliga a sus 31 miembros 2. Por ese acuerdo, todos los firmantes deciden reconocer la validez de los certificados emitidos por los demás. En cada país firmante existe un responsable frente a los demás miembros y en el caso de España, ese cometido lo desempeña el Organismo de Certificación de la Seguridad de las Tecnologías de la Información 3, que es parte del Centro Criptológico Nacional (CNI) actualmente adscrito al Ministerio de Defensa. Para obtener alguna de las certificaciones, el cliente debe dirigirse a un Laboratorio de Certificación que, siguiendo una metodología común y aprobada por todos, se encargará de aplicar el procedimiento de evaluación que establece en cada nivel el esquema de los Common Criteria. En el mundo hay reconocidos 80 laboratorios de evaluación distintos operando bajo el esquema de Common Criteria 4, y sólo seis de ellos son españoles y forman parte del conjunto de 33 laboratorios europeos.

En estos 30 años de funcionamiento el esquema de los Common Criteria ha demostrado muchas cosas, entre ellas, lo largas y costosas que se pueden hacer las certificaciones de productos. Aunque aumenta según la calidad de la certificación, incluso en sus formas más básicas, la certificación de productos ha supuesto duraciones, costes y dedicaciones de recursos por parte del solicitante, que sin duda desmotivaban la adopción de esos estándares, sobre todo cuando no está del todo claro qué es lo que realmente se consigue con ello. En el año 2020, se certificaron Common Criteria 388 productos 6, mientras que en 2019 fueron 368. En concreto, en ese año, 187 (40%) de esas certificaciones correspondían a evaluaciones de alto nivel (de EAL4 a EAL7), de las cuales 72 eran EAL4, 84 fueron EAL5, 30 en el nivel EAL6 y solo 1 de nivel EAL7. En el otro extremo, 82 productos (21,1%) siguieron evaluaciones más livianas (de EAL1 a EAL3), mientras que la evaluación más popular entre las de menor profundidad fue EAL2, con 57 productos certificados.

En cuanto a países solicitantes de certificación, los tres más activos en 2020 fueron los EEUU (81 certificados), Francia (77) y Holanda (59). Detrás vinieron Alemania (49), Canadá (24) y Suecia (19). Nuestro país sólo representa un 4% de la actividad certificadora total con sólo 17 productos. Los laboratorios de evaluación más activos en 2020 fueron Brightsight (45 productos), SERMA (37), Acumen (29), Gossamer (25), TÜV y Thales (20). En cuanto a las compañías que solicitaban la certificación tenemos a Idemia con 31 productos certificados, NXP Semiconductors en segundo lugar con 28 productos, y en tercer lugar STMicroelectronics con 18 certificaciones, todas ellas seguidas de Infineon (16) y Samsung (15). Entre los clientes de la certificación Common Criteria no resaltan las empresas de titularidad española.

En ese mismo año 2020, 265 productos (68%) de los 388 certificados, lo fueron a través de la modalidad conocida como Protection Profile 7, tanto si tiene EAL asignado como si no lo tiene. La opción de evaluación armonizada conocida como Collaborative Protection Profile 8 fue muy popular ese año y representó un 21% de todos los que optaron por la modalidad de certificación mediante evaluación del Protection Profile. El 83% de todos los productos con estas modalidades fueron dispositivos de red 9.

Aunque el gremio de la certificación Common Criteria no pone en duda su necesaria existencia, sí ha sido consciente de que su implantación está siendo muy limitada. Por ello algunos países han lanzado esquemas de certificación más ligeros, que intenten resolver el problema de costes y duraciones en el caso de los productos de garantías bajas (low assurance products). Francia fue uno de los primeros países en crear una metodología ligera (CSPN 10) en 2008. Posteriormente, otros países han seguido esa misma senda, y en el caso de nuestro país, esa metodología se llama LINCE 11. Esta ha sido diseñada para productos TI que requieran certificaciones y garantías medias o bajas en cuanto a su seguridad. El objetivo de una evaluación LINCE es que un laboratorio autorizado pueda comprobar que un producto tiene un determinado nivel de efectividad con las funcionalidades de seguridad implementadas en él. Cabe subrayar que la evaluación se hace siempre basándose en la información que aporta el fabricante y la que se pueda obtener de fuentes abiertas.

Se pretende que, con esas certificaciones, los productos de menor seguridad dispongan de un esquema de costes asumibles y de duraciones acotadas en el tiempo. Todas esas iniciativas son similares aunque utilizan metodologías con ligeras diferencias, pero no es impensable que con ellas se pueda crear una metodología común y única que sea aceptada por todos (o por muchos) dentro de Europa. En general, esas metodologías ligeras consisten en varias fases: 1) revisión de la documentación técnica del producto, 2) evaluación funcional de su seguridad, 3) búsqueda de vulnerabilidades conocidas, y 4) ensayos de penetración.

Tanto si la metodología es ligera como si es extremadamente farragosa, además de la pertinencia de ambas, también hay que prestar atención a las capacidades reales y procedimientos utilizados por los Laboratorios de Evaluación. Aunque haya normas y certificaciones que pretendan homogeneizar las capacidades de las personas y metodologías que terminan haciendo el trabajo, eso no quiere decir que los objetivos marcados por esas normas sean siempre los adecuados para aportar la seguridad necesaria en un sector, sistema o proceso en función del tiempo. La homogenización normativa implica rigidez, y la rigidez se adapta mal a la evolución de los riesgos y a las estrategias de ataque por parte de seres inteligentes. La experiencia cuantitativa y cualitativa de tres décadas de certificación industrial bajo el esquema de los Common Criteria pone de manifiesto que no ha sido capaz de popularizar la certificación en ningún ámbito de la actividad industrial o de servicios a nivel planetario, ni europeo. El nacimiento de las metodologías ligeras apunta a que las causas supuestas de ese raquitismo certificador pueden estar en los excesivos costes y tiempos de ejecución que siempre han tenido asociados la certificación en general, y la de Common Criteria en particular.

Todavía está por ver si este enfoque más ligero y local consigue algo significativamente distinto a lo anterior, pero es preciso dejar claro que estas nuevas aproximaciones no ponen en duda o riesgo el amplio territorio y estatus quo que se sigue reservando la evaluación Common Criteria.

Tecnologías TIC, normalización y certificación

Quizás esta evolución hacia las metodologías ligeras sea un intento evolutivo que persigue impedir una verdadera revolución en lo que a la evaluación de seguridades reales se refiere. En todos los foros a favor de la normalización y la certificación, el mantra esencial es un canto a la uniformidad y a la caracterización/ evaluación independiente de los productos en el mercado. En muy pocas ocasiones tales certificaciones son obligatorias, y donde más éxito tiene la normalización es en sectores productivos industriales clásicos como el del automóvil, la aeronáutica y el transporte en general, donde esa obligación es de facto.

En el sector de las tecnologías de la información u otros derivados de ellas, la normalización brilla por su ausencia. Es verdad que el sector del automóvil y la aeronáutica tiene más de cien años de antigüedad, pero el sector TIC lleva unas décadas en boga con unos crecimientos nunca antes vistos y, sobre todo, teniendo un impacto histórico sobre, no sólo la productividad, sino también sobre el individuo y la sociedad misma. Está por ver que la agilidad de las tecnologías TIC permita algún tipo de normalización o certificación. En este gremio los productos son volátiles, efímeros, insustanciales, sobre todo si ponemos nuestra atención en que los más populares son servicios o gadgets que evolucionan, se consolidan y/o mueren en el propio uso de sus consumidores finales.

Es cuando ese tipo de tecnologías quiere entrar en el sector industrial cuando la consolidada tropa de la certificación y normalización quiere ponerle sus yugos. Está por ver que realmente lo consiga. Hasta ahora lo único que hemos visto es el surgir de una Internet de las Cosas (IoT) montándose sobre los mismos sillares que el comercio electrónico, las redes sociales, y el streaming de casi todo. No tengo muy claro que este fenómeno esté dispuesto a someterse al arbitraje de nadie y menos aún de los Señores de la Certificación.

Dos nuevos ámbitos: la Internet de las Cosas (IoT) y la Tecnología Operativa (OT)

La Internet de las Cosas 12 (IoT) y la Tecnología Operativa 13 (OT) son dos nuevos ámbitos, dos nuevas fronteras donde la digitalización da la batalla a procedimientos previos netamente analógicos, continuos y derivables. Aunque ya llevan años en marcha, las seguimos viendo como nuevas porque es ahora cuando saltan al ágora en el que todos somos (in)formados. La IoT ya estaba en marcha en 1992 con la primera máquina expendedora de Coca Cola de la Universidad de Carnegie Mellon, que informaba a través de Internet de su estado interno. Por su parte, la OT no es más que el apodo reciente de lo que mucho antes eran los Sistemas de Control Industrial 14 (ICS).

Hace veintiocho años, en 1993, se publicaba IEC-1131, que posteriormente sería IEC-61131 15, en el que la industria se mueve hacia una mayor estandarización del software de control para hacerlo independiente del hardware. Es el tiempo de entrada de la programación orientada a objetos en el software de control y del desarrollo de controladores lógicos programables 16 (PLC) y los PCs industriales (IPC).

Escenarios industriales: vicios, debilidades, desastres…

Lo que es novedad es que todas esas tecnologías industriales, desarrolladas ad initio en escenarios netamente industriales, poco a poco han ido abrazando la idea de utilizar para sus fines productos y redes esencialmente desarrollados en el entorno TI. Esta tendencia se ve acompañada por una reducción de costes ya que van a comprar en un mercado TI donde el factor de enorme escala es esencial, pero también inoculan con ello los vicios y debilidades de las tecnologías de la Información en los escenarios industriales. Puede que un fallo de un software pueda dejar expuestos los datos personales de millones de ciudadanos y no pase nada (aunque algo serio debería suceder), pero no está claro que se pueda aceptar que un software de control se vuelva loco (espontáneamente o con ayuda externa de alguien) y libere una nube tóxica de isocianato de metilo 17 por ejemplo, tal y como ocurrió una noche de diciembre de 1984 en Bhopal 18 (India) causando 25.000 muertos y medio millón de lisiados.

La lista de desastres industriales 19 es larga y muy luctuosa, y debe ser consultada por todos y también enseñada en las escuelas para percatarnos de que éste es un asunto muy grave. La Historia nos ha llevado a un punto en el que deberíamos, ahora sí, tomarnos muy en serio la seguridad de los sistemas IoT, OT o cualesquiera que tengan que ver con la monitorización y el control automático de algo, ya sean humanos o procesos industriales. La solución propuesta por Europa y el resto del planeta es más de lo mismo, recurrir a la certificación de los productos, y de los sistemas y procedimientos. Con todo, no podemos olvidar que esta solución normativa sólo lo es frente a los fallos fortuitos, a los accidentes, a los imprevistos nacidos del capricho del azar y, sin embargo, no hay nada en Ciberseguridad que sea culpa de la fortuna.

No hay más que echar un vistazo a los incidentes más interesantes de la Ciberseguridad para concluir que ninguno de ellos podría haberse evitado mediante normalización o certificación de procesos y productos. Excluyo de esa lista de eventos “ciber-interesantes” las múltiples meteduras de pata de administradores y/o usuarios (80% de los casos), las configuraciones y cuentas por defecto, las no actualizaciones del software y del hardware, y los pésimos (o nulos) mantenimientos de los sistemas y productos, que han ayudado a que alguien se meta en los pagos20 de otros y cause desastres varios.

“Ciber-inseguridades ontológicas”

Prefiero centrarme en aquellos escenarios en los que todo el sistema hizo lo que tenía que hacer (DigiNotar21, 2011), y el fallo era la misma existencia de cuentas de administrador verificadas con contraseñas fijas. Puestos a darle un nombre a estos casos de real interés, podríamos hablar de las “ciber-inseguridades ontológicas” de productos y sistemas. En estos casos la certificación de productos no sirve para nada. Pongamos por ejemplo un proceso de cifrado de ficheros que autónomamente decide cifrarlo todo y encomendar la custodia de esas claves simétricas a una identidad RSA ajena al sistema. Para ello, utiliza los recursos (librerías, proceso, herramientas) que le ofrece el sistema operativo, ni siquiera tiene que llevarlo él como una pesada alforja (AKA “payload”). Si esto ocurre por la voluntad de un administrador, se le denomina cifrado de ficheros, si se hace de forma no autorizada y descontrolada, se llama ransomware. Ambas cosas son lo mismo, y permitida una se permite la otra. Otro ejemplo puede ser mandar un fichero adjunto por correo electrónico; si se hace con la voluntad legítima del titular del fichero, se habla de mandar un correo-e, si se hace sin ella, hablamos de “exfiltración de datos”. Ningún proceso de certificación puede distinguir entre estas posibilidades duales.

Otros ejemplos de ciber-inseguridades ontológicas o esenciales los podemos encontrar en las conexiones remotas 22, en el acceso a través de redes virtuales privadas 23, en la migración de procesos 24 entre máquinas, en el arranque no autenticado de los equipos 25, en el uso de cachés de datos 26, 27, en la misma existencia de cuentas privilegiadas 28, en la no autenticación de procesos que se están ejecutando 29 en cada equipo, etc. Hoy en día, después de la entrada triunfal de China en la economía capitalista global, todos los países del mundo son partidarios de la certificación de productos en general, siempre y cuando beneficien a sus productos nacionales en particular. Los estilos certificadores y normativos franceses no suelen coincidir suficientemente con los estilos alemanes (sólo son dos ejemplos) como para que la construcción de cualquier esquema europeo de certificación sea un paseo idílico por la playa.

Después de todo, la certificación 1) impone costes (muchas veces muy importantes y no siempre estrictamente necesarios), a la vez que 2) excluye a otros (los no certificados), por lo que la batalla por ser el emisor de normas de certificación está servida. Hasta la fecha, la parte Occidental de las potencias económicas ha disfrutado de ese monopolio normativo, pero desde hace tiempo, la parte oriental también tiene cosas que decir 30.

La propuesta europea de esquema de certificación

En Europa se ha propuesto implementar un esquema de certificación de la ciberseguridad de componentes industriales (Industrial Automation & Control Systems Components, ICCS) como parte del desarrollo del EU Cyber Security Act 31. En principio, este esquema serviría como base de un futuro esquema europeo de certificación para los componentes de automatización y control industrial. El Cybersecurity Act (CSA) fue publicado el 17 de abril de 2019 e introduce por primera vez la necesidad de una red paneuropea de certificación de la ciberseguridad para los productos, servicio y procesos industriales. Esos componentes son: los dispositivos de automatización, los controladores lógicos programables (PLC), las unidades terminales remotas (RTU), los servidores distribuidos que monitorizan y controlan los PLCs, las estaciones de trabajo desde las que operan los técnicos las RTUs y los PLCs, las redes telemáticas que lo conectan todo, sistemas supervisores de control y adquisición de datos (SCADA), y los registros históricos (logs) de la actividad SCADA.

El esquema ICCS 32 no pretende certificar todo el sistema industrial (IACS 33) o sus sub-sistemas, ya que considera que esos son parte de un proceso de ingeniería más global y complejo que habrán de realizar los dueños del sistema o sus operadores/integradores. Por el contrario, se centra en la certificación de los componentes que después van a ser utilizados en el diseño y realización de los sistemas de control y operación industrial. Teniendo en cuenta que la seguridad es la del eslabón más débil, está claro que la certificación de los componentes sólo viene a reforzar las puertas, olvidándose de las murallas en las que están encastradas.

La granularidad del esquema ICCS no es muy fina, ya que sólo considera tres niveles de seguridad: Básico, Sustancial y Alto. Sólo en el caso del nivel Alto se evalúa realmente la robustez del componente, y ello se hace en aras de poder preservar la soberanía nacional, y proteger al ciudadano y a la industria de los ataques de organizaciones criminales u otros estados. Sin embargo, la evaluación consiste, básicamente, en pruebas de penetración y la aplicación de ataques conocidos. En el caso del nivel Sustancial, lo que se persigue prevenir es que los componentes puedan formar parte de ataques escalables con dispositivos de coste medio/alto. En este caso lo que se evalúa es la ausencia de vulnerabilidades conocidas. Por último, el nivel Básico persigue evitar la participación del componente en ataques masivos en dispositivos de bajo coste. En este último caso, la evaluación se hace mediante la autoevaluación/ revisión de la documentación técnica del componente por parte de su fabricante.

Esta fuerte asimetría en dos de los tres niveles de certificación quizás nazca de pensar que en cualquier sistema hay componentes menos críticos que otros, por lo que pueden ser evaluados de forma más liviana y rápida. Sin embargo, la realidad es que la importancia de un componente nace del análisis de riesgos de la instalación de la que forma parte, y esa importancia no es inherente al componente. Es más fácil para los reguladores y normalizadores centrarse en los componentes, pero la “Seguridad” seguirá estando difusa en todo el sistema. Parece como si, con los niveles Sustancial y Bajo, lo único que preocupase a la comunidad certificadora fuera no alimentar las legiones de los futuros atacantes por denegación de servicio al estilo de la red Mirai 34 de septiembre de 2016 35. Preparar ahora esquemas de certificación para ataques de hace casi un quinquenio, quizás indique lo por detrás que vamos en la carrera hacia la ciberseguridad de nuestras vidas.

Aprender a tratar el todo

Desde hace tiempo se utilizan los sistemas IACS (Industrial Automation & Control Systems) y ahora quieren actualizarlos hacia un nuevo “el dorado” 36 que se llama Industria 4.0, que se estima supondría 150 billones de dólares americanos de negocio en el año 2025. Sin embargo, esa peregrinación global puede terminar exponiendo aún más a los sistemas industriales. Las vulnerabilidades de esa nueva industria podrán ser explotadas por adversarios y sus consecuencias tener un alto impacto en las infraestructuras de cualquier tipo y pronto afectar gravemente a la economía y de ahí al día a día de los ciudadanos.

Es curioso que, gracias al Covid-19, hayamos podido ver lo que pasa cuando, por algún motivo exógeno, la economía capitalista (la única disponible por el momento) se pone al ralentí durante bastante tiempo. Una gestión incorrecta o inmadura de la seguridad de los sistemas industriales sentaría las bases para futuras pandemias tecnológicas. La certificación y la normalización de componentes es necesaria, pero también lo es la de los sistemas y los procesos, tanto si son industriales como si son de cualquier otra índole. La normalización y la certificación son necesarias, pero no son suficientes para asegurar los sistemas, procesos y servicios sobre los que vivimos. ¿Estaban certificados los sistemas que Stuxnet 37 logró penetrar y engañar? Probablemente estaban tan certificados como su usuario iraní podía certificar y, sin embargo, el ataque fue un éxito para sus promotores y un pequeño desastre para sus usuarios.

No creo que debamos perdernos en los detalles de los esfuerzos normativos y certificadores de las autoridades de siempre hasta que aprendan a tratar el todo y no sólo alguna de sus partes. A fin de cuentas, lo que sigue estando en juego es la seguridad, la felicidad y el futuro de los habitantes de este peculiar planeta, de esa “pálida mota azul” 38 de la que hablaba el entrañable 39 Carl Sagan 40.

1 Ver http://www.commoncriteriaportal.org/files/CCRA - July 2, 2014- Ratified September 8 2014.pdf
2 Ver https://www.commoncriteriaportal.org/ccra/members/
3 e-mail: organismo.certificacion@ccn.cni.es URL: https://oc.ccn.cni.es
4 Ver https://en.wikipedia.org/wiki/Common_Criteria
5 Los laboratorios son Applus Laboratories, Brightsight Barcelona S.L., Instituto Nacional de Técnica Aeroespacial (INTA), Clover Technologies, DEKRA Testing and Certification, S.A.U., Layakk Seguridad Informática, S.L. Ver https:// oc.ccn.cni.es/acreditacion-de-laboratorios/laboratorios-acreditados
6 Ver https://www.jtsec.es/files/2020 CC Statistics Report.pdf
7 Ver https://en.wikipedia.org/wiki/Protection_Profile
8 Un Collective Protection Profile (cPP) define los requisitos de seguridad IT que debe cumplir un TOE (Target of Evaluación) genérico y especifica las medidas que deberá asegurar el dispositivo a evaluar para conseguir la certificación.
9 Ver https://www.commoncriteriaportal.org/files/ppfiles/CPP_ND_V2.1.pdf
10 Ver https://www.ssi.gouv.fr/administration/produits-certifies/cspn/
11 LINCE Certificación Nacional
12 Ver https://en.wikipedia.org/wiki/Internet_of_things
13 Ver https://en.wikipedia.org/wiki/Operational_technology
14 Ver https://en.wikipedia.org/wiki/Industrial_control_system
15 Ver https://en.wikipedia.org/wiki/IEC_61131
16 Ver https://en.wikipedia.org/wiki/Programmable_logic_controller
17 Ver https://en.wikipedia.org/wiki/Methyl_isocyanate
18 Ver https://en.wikipedia.org/wiki/Bhopal_disaster
19 Ver https://en.wikipedia.org/wiki/List_of_industrial_disasters
20 Pago (segunda acepción) Del lat. Pagus: 1. Distrito determinado de tierras o heredades, especialmente de viñas u olivares. 2. Pueblo pequeño o aldea. 3. Lugar o región. 4. m. (en Arg., Bol. y Ur.) Lugar en el que ha nacido o está arraigada una persona.
21 Ver https://en.wikipedia.org/wiki/DigiNotar
22 Ver https://en.wikipedia.org/wiki/Remote_desktop_software
23 Ver https://en.wikipedia.org/wiki/Virtual_private_network
24 Ver https://en.wikipedia.org/wiki/Process_migration
25 Ver https://en.wikipedia.org/wiki/Unified_Extensible_Firmware_Interface#Secure_boot
26 Ver https://en.wikipedia.org/wiki/Meltdown_(security_vulnerability)
27 Ver https://en.wikipedia.org/wiki/Spectre_(security_vulnerability)
28 Ver https://en.wikipedia.org/wiki/Privilege_escalation
29 Ver https://en.wikipedia.org/wiki/Trusted_execution_environment
31 Ver https://ec.europa.eu/digital-single-market/en/eu-cybersecurity-act
32 ICCS = IACS components Cybersecurity Certification Scheme Ver https://op.europa.eu/s/oROt
33 IACS = Industrial Automation and Control System. Ver https://en.wikipedia.org/wiki/Control_system_security
34 Ver https://en.wikipedia.org/wiki/Mirai_(malware)
35 Ver https://en.wikipedia.org/wiki/2016_Dyn_cyberattack
36 Ver https://en.wikipedia.org/wiki/El_Dorado
37 Ver https://en.wikipedia.org/wiki/Stuxnet
38 Ver https://youtu.be/GO5FwsblpT8
39 Ver https://youtu.be/StRLkw7ZFVc
40 Ver https://en.wikipedia.org/wiki/Carl_Sagan

Your browser is out-of-date!

Update your browser to view this website correctly.Update my browser now

×