¿Está KL desarrollando su propio Sistema Operativo? ¡Rumores confirmados y fin de las especulaciones!

¡Hola a todos!

Hoy quiero hablaros sobre el futuro: un futuro no muy alentador con ciberataques masivos a plantas nucleares, centrales energéticas, centros de transporte, sistemas financieros y de telecomunicaciones, a lo que llamamos, a grandes rasgos, instalaciones críticas. Para haceros una idea, recordad la película La Jungla 4: Ultimátum, donde un ataque a infraestructuras sumergió el mundo entero en un caos total.

Pero, esta vez, no está John McClane para solucionar el problema de vulnerabilidad de los sistemas industriales. Incluso si éste fuera el caso, sus métodos no funcionarían. Sin embargo, estamos trabajando en el desarrollo tecnológico de un sistema operativo seguro con el cual proteger a esos sistemas TI tan críticos, (sistemas de control industrial (ICS)). Ya han circulado en Internet algunos rumores al respecto, así que me imagino que ya es hora de correr (un poquito) la cortina sobre nuestro proyecto secreto y compartir con vosotros qué nos traemos entre manos.

Pero, primero, quiero hablar un poco sobre los vulnerables sistemas industriales y por qué el mundo necesita, realmente,  nuestro nuevo y diferente enfoque.

Los Sistemas Industriales, totalmente indefensos

Aunque los sistemas industriales informáticos – las típicas redes de oficina – pueden parecer muy similares en algunos aspectos; en realidad las diferencias son importantes – especialmente en términos de prioridades entre seguridad y usabilidad. En una compañía normal, lo más importante es la confidencialidad de datos. Por ejemplo, si el servidor de la compañía detecta un troyano, lo más sencillo es desconectar el sistema infectado de la red y, posteriormente, empezar a solucionar el problema.

Esto no se puede hacer en un sistema industrial, ya que la principal prioridad para ellos es mantener las operaciones contra viento y marea. Mantener la producción de manera ininterrumpida es de vital importancia así como el objetivo de la industria mundial. Por este motivo, la seguridad siempre ha sido relegada a un segundo plano.

Esto conlleva que el software de una instalación industrial o de infraestructura solo se actualice después de una exhaustiva comprobación de la tolerancia a fallos, asegurándose de  no interrumpir la cadena de trabajo. Y como esta comprobación necesita muchísimo esfuerzo (aún no asegurando totalmente que no haya fallos), muchas compañías simplemente no se preocupan, en absoluto, por actualizar los ICS (dejándolos así durante décadas). Hace poco leí un buen artículo sobre este tema, el cual mostraba un listado de las 11 reglas de seguridad ICS. Regla nº 1: “No tocar. Nunca” ¿Qué más os puedo decir?

La actualización del software puede estar prohibida, expresamente, en las políticas de seguridad de organizaciones industriales o de infraestructuras. Incluso, si existiera la posibilidad de actualizar el software y cubrir los “agujeros”, esto no ayudaría mucho. Los fabricantes de software especializado no están interesados en el constante análisis de códigos de fuente así como en cubrir agujeros. Y como nos ha demostrado la experiencia, se reducen los gastos en este tipo de actividades y solo se ponen parches si se descubre algún exploit y se publica en Internet. De hecho, esto no solo sucede con software especializado, sino es más común de lo que parece. No obstante, el tema que hoy nos compete es el software específico para industria.

El problema es el siguiente: los puntos vulnerables del software de control, de los controladores programados y de las redes de comunicación industrial conllevan que los operadores de sistemas industriales e de infraestructuras no puedan recibir información fiable sobre toda la operación del sistema. Teóricamente, podría suceder lo siguiente: si se ataca un sistema de distribución eléctrica, como resultado, puede pararse una instalación en la otra punta del país. En cambio, el centro de control no sabe nada al respecto: los atacantes han enviado a sus ordenadores datos falsos.

Ejemplos

No es necesario buscar demasiado lejos ejemplos al repecto ya que ya está sucediendo en la vida real. El primer método utilizado –un ejemplo de cibersabotaje y peligros potenciales- fue un ataque en los sistemas SCADA allá en el año 2000 en Australia. Un empleado de una subcontrata, trabajando en el sistema de control del municipio de Maroochy Shire, pudo, en 46 ataques (¡!), hacer que las bombas de agua dejaran de funcionar o no lo hicieran correctamente. Nadie entendía qué estaba ocurriendo – había una brecha dentro de las comunicaciones del sistema. Solo después de meses, las compañías y las autoridades llegaron a saber qué había pasado: el empleado quería trabajar en la empresa de aguas y al no conseguirlo, decidió inundar el sistema de alcantarillado de toda el área de Queensland.

Existen multitud de ejemplos; simplemente los medios no se hacen eco de ellos. Después de todo, las compañías víctimas de estos ataques no quieren que todo el mundo sepa que sus sistemas son vulnerables (el tema de intereses públicos, los dejaré para otro día y otro post…). En muchos incidentes, incluso las víctimas desconocen que han sido atacadas. No hace mucho se encontró en los routers industriales Ruggedcom un agujero que permitía al usuario de a pie aumentar su acceso hasta el nivel de administrador y tomar el control del dispositivo. Además, no se supo saber con certeza quién, cuándo, cómo y dónde se aprovechó de dicho agujero. De este modo, existen otros muchos agujeros similares que se están aprovechando… pero esto son solo conjeturas.

Para saber un poco más sobre el tema, os recomiendo que leáis sobre ataques en ICS que alcanzaron su objetivo (más info aquí).

¿Quién puede, aparte de blackmailers o candidatos a un trabajo enfadados, acceder al código fuente del software ICS, a los controladores, a los sistemas operativos y similares? Por supuesto, las autoridades oficiales. Concretamente, aquellos departamentos que certifican el software para sistemas críticamente importantes. Pero, además, otros departamentos – como aquellos que desarrollan (en los últimos años) armas cibernéticas contra los sistemas diseñados por  atacantes (que son, normalmente, otros países).

¡Eso es! Me refiero a cosas como Stuxnet y los subsiguientes Duqu, Flame y Gauss – malware tan complejo que deja totalmente claro que han sido desarrollados por alguna nación. No nos interesa realmente quién es el objetivo; sino si estas armas cibernéticas se han desarrollado y se han utilizado. Una vez se ha abierto la caja de Pandora, no hay manera de cerrarla de nuevo. La construcción de armamento para ataques a sistemas industriales y de infraestructura, procedentes de enemigos, nos afectará antes o después. Así que la mayor amenaza del planeta, hoy en día, no proviene de la “gentuza” normal y corriente, incluso tampoco de cibercriminales organizados, sino de creadores de armas cibernéticas con apoyo estatal.

La Protección actual no es efectiva 

Al mismo tiempo que se proveen de armas, tanto las compañías de infraestructuras como las autoridades no se han olvidado de protegerse. De hecho, se han empezado a proteger hace ya tiempo. Pero ¿cómo lo hacen?

Existen solo dos métodos. El primero es aislar los objetos críticos importantes: desconectarlos de Internet o aislarlos físicamente del mundo exterior de alguna otra forma. No obstante, como nos ha demostrado la experiencia, si un técnico, durante el turno de noche, quiere ver películas en los ordenadores de control desde un USB infectado por un virus – no hay forma de pararle (existen métodos para bloquear esto, pero no hablaremos de esto en este momento).

El Segundo método: mantener el secreto. Los desarrolladores de ICS mantienen el código de fuente en secreto. Los dueños de fábricas e industrias ponen el sello “SECRETO” en los esquemas de los sistemas de información y control, se mantienen en secreto los tipos de software utilizado, etc. Sin embargo, al mismo tiempo, la información sobre los puntos vulnerables de la mayoría de los sistemas SCADA está disponible en Internet. Si indagamos más, encontramos que, durante años, el motor de búsqueda abierto SHODAN  ha estado funcionando – diseñado, entre otras cosas, para buscar sistemas industriales vulnerables (incluyendo SCADA) cuyos dueños deciden conectarlos – o se han olvidado de desconectarlos- a Internet.

Paralelamente, los especialistas en organizaciones industriales y de infraestructura también utilizan métodos tradicionales de protección de software vulnerable y sistemas operativos controlando el uso de programas y las acciones de los usuarios. No obstante, no se puede garantizar una protección al 100%, debido a los puntos vulnerables por defecto en el software cuando hacemos un control. Así que, necesitamos encontrar una garantía para las infraestructuras críticas.

¿Cómo debería ser la Protección?

Se debería reescribir todo el software ICS, incorporando las tecnologías de seguridad existentes y teniendo en cuenta la realidad actual sobre los ataques cibernéticos. Lamentablemente, este esfuerzo tan grande, el cual requeriría una gran inversión para su testeo y ajuste, no sería garantía suficiente para el correcto funcionamiento de los sistemas.
En cambio, sí existe una alternativa alcanzable: un sistema operativo seguro, uno que se pueda instalar en los ICS y el cual se pudiera introducir en la infraestructura existente – controlando los sistemas “sanos” actuales y garantizando informes de datos fiables en las operaciones de los sistemas.

Antes de nada, voy a responder a la pregunta más obvia: ¿cómo es posible que KL pueda crear un sistema operativo seguro si ni Microsoft o Apple han sido capaces? ¡Es realmente sencillo!

Primero: nuestro sistema está específicamente diseñado y desarrollado para resolver tareas específicas y no para jugar al videojuego Half-life, editar vídeos de nuestras vacaciones o charlar en redes sociales.

Segundo: estamos trabajando en métodos de escritura de software, las cuales, por diseño, no llevan a cabo actividades ocultas. Ésta es la parte más importante: en nuestro sistema operativo no es posible ejecutar un código de terceros, irrumpir en el sistema o instalar aplicaciones no autorizadas. Y esto se puede comprobar y demostrar.
Si quieres conocer  más detalles sobre el sistema, sus requisitos, background y desarrollo, puedes encontrar más información aquí.

Concluyendo y anticipándome a la multitud de preguntas de mis colegas, socios, medios y curiosos: nuestro proyecto se está desarrollando en un entorno realmente seguro. Es un proyecto sofisticado, que sería posible sin la colaboración de operadores y proveedores ICS. No os podemos revelar demasiados detalles del proyecto en este momento por motivos de confidencialidad con nuestros colaboradores. Además, no quiero dar más pistas a nuestros competidores sobre nuestro buen saber-hacer. Y sumado a esto, existen detalles que siempre se mantendrán alejados de los ojos de ciertos clientes para evitar los abusos de los ciberterroristas. No obstante, tan pronto como pueda, os seguiré dando detalles del proyecto.

¡Hasta la próxima!