Preguntas y respuestas sobre Kaspersky OS

Hemos lanzado oficialmente nuestro sistema operativo seguro para dispositivos de red, sistemas de control industrial e IdC (Internet de las Cosas).

El SO se concibió inicialmente un 11 de noviembre, por eso nos referimos a él con el nombre en clave 11-11. Ha sido un ciclo de desarrollo muy largo: llevamos 14 años trabajando en el proyecto y hemos llevado a cabo una prueba en el mundo real. Ahora, el SO pueden usarlo las partes interesadas en diversas situaciones.

Os contaré los detalles nerd, pero si queréis conocer la información técnica, aquí la tenéis: Preferiría centrarme en lo que no mencionamos en ese texto, así que responderé las preguntas más frecuentes y acabaré con algunos mitos sobre nuestro nuevo SO.

¿Por qué necesitaríamos otro Linux?

Esta es una de las preguntas más frecuentes. La respuesta es muy fácil y directa: Esto no es Linux. Literalmente no es Linux; no hay ni un solo código de Linux en él. Hemos diseñado el SO desde cero, para aplicaciones y fines diferentes.

Lo que más importa en Linux, Windows, macOS y los demás SO es la compatibilidad y la universalidad. Los desarrolladores se esfuerzan al máximo por popularizar sus soluciones simplificando demasiado el desarrollo y las herramientas de las aplicaciones. Pero, cuando se trata de nuestro público objetivo (desarrolladores de hardware, sistemas SCADA, IdC, etc.), esta idea es imposible: lo más importante es la seguridad.

Para crear un entorno seguro, hay que activar la denegación por defecto en el proceso e introducirlo en un microkernel. En otras palabras, es un sistema que hace lo que se le ha enseñado y es incapaz de nada más. Con los sistemas operativos tradicionales, eso es imposible.

Sin embargo, es posible crear mecanismos de seguridad en un sistema que ya es funcional. Básicamente, es nuestra actividad principal. Lo que hacemos tiene muchas aplicaciones. Pero, con algunas, hasta el riesgo más pequeño de un ciberataque representa un desastre. Cuando se debe garantizar la seguridad, debemos crear algo nuevo. Algo que sea seguro por su diseño.

Venga ya, ¡un SO seguro no es noticia! ¿Y qué?

Bueno, no estamos diciendo que hayamos creado algo del todo nuevo. Por supuesto, ha habido otros intentos de crear un SO seguro. A veces, algunos proyectos tuvieron éxito, pero su precio se acercaba al de un avión (curiosamente, dichos sistemas se usaron en aviones), por lo que dichos proyectos no llegaron a ser a gran escala.

Otros proyectos se limitaban a la investigación académica. En otras palabras, algunas mentes brillantes crearon un microkernel y lo celebraron con champán y discursos, pero eso fue todo. Ningún proyecto se llegó a desplegar o a comercializar. Pero un vehículo funcional no solo necesita un motor; no puede funcionar sin ruedas, ni suspensión ni otras cuantas cosas.

Decidimos diseñar el sistema para que fuera relevante a diferentes niveles, permitiendo la personalización a un nivel granular basado en aplicación. Básicamente, hemos creado tres productos. Son: SO (KOS), un hipervisor seguro y autónomo (KSH) y un sistema dedicado para una interacción de seguridad entre los componentes del SO (KSS). Pueden llevar a cabo varios retos por su cuenta, según la aplicación.

Por ejemplo, SYSGO, una empresa alemana, obtuvo autorización para usar de KSS en su propio sistema operativo, PikeOS. Algunos vendedores se interesan solo en el hipervisor (KSH), lo que les permite ejecutar de forma segura aplicaciones existentes sin modificarlas. Pero para el switch de Kraftway, este nivel de integración no era suficiente, por lo que decidieron desplegar el sistema operativo al completo.

En otras palabras, la ventaja de nuestro sistema operativo es su naturaleza práctica y accesible; está creado con un fin en lugar de estar diseñado para situaciones hipotéticas.

¿Cómo demostrarías que el SO solo permite que se ejecuten operaciones de una lista blanca?

Naturalmente, en cuanto afirmamos que nuestro sistema es seguro por diseño, algunos lo refutaron y no se lo creyeron. Eso está muy bien: en el mundo de la ciberseguridad no se debería dar nada por sentado.

La arquitectura de nuestro sistema operativo se basa en el principio de dividir objetos en un número máximo de entidades aisladas. Los clientes podrán examinar el código fuente para asegurarse de que no hay funcionalidades irregulares en el sistema. El resto se configura junto al cliente mediante varias políticas de seguridad diseñadas para controlarlo todo.

El sistema hará solo lo que tú quieras que haga. Así, los delincuentes no podrán aprovecharse de ningún error que pueda contener una aplicación que hayas creado para este SO. Por supuesto, puedes escribir código con errores, pero, para que el código funcione, tiene que cumplir con las políticas que definen lo que el código puede o no puede hacer.

¿De verdad crees que funcionará algo en este sistema operativo?

Claro, ¡porque nuestro sistema es extremadamente flexible! En general, se podría modificar con el fin de convertirlo en un producto para el mercado general, pero para ello se necesita mucho tiempo y recursos. Por ahora, no lo hemos planeado a largo plazo y lo consideramos para un segmento reducido.

Además, recuerda que es posible añadir código de terceros al SO. Nuestra solución incluye un hipervisor seguro que permite ejecutar virtualmente cualquier sistema operativo como SO invitado y personalizar las aplicaciones (como en el servidor Linux de Apache).

Sí, si pudiéramos acceder a este servidor y dividirlo en varias partes y escribir políticas sobre cómo deben interactuar las unas con las otras, obtendríamos un nivel más alto de seguridad. Pero es mucho trabajo. Aunque, todo es posible si tienes las agallas y recursos suficientes. 🙂

Por eso hemos activado las aplicaciones personalizadas en el hipervisor. Sí, al principio tendremos un SO seguro con una personalización insegura. Cualquier cosa que suceda dentro de esta personalización será confusa. Pero podremos controlar sus interacciones con hardware, otras personalizaciones y el mundo exterior. Eso ya es algo. Con dicha configuración, escapar del aislamiento de procesos es poco probable.

Venga ya, recopilará datos de todas formas

El kernel no transmite nada a ninguna parte (lo que se puede comprobar revisando el código fuente). El microkernel no tiene prácticamente nada en él. Todos los drivers están aislados, por lo que para pasar cualquier información, se debe escribir otra parte de código. Se verá muy claro, no tendrás ni que mirar el código fuente para verlo. Todo ello está escrito en las políticas de seguridad. Y el cliente siempre podrá cambiar esas políticas, a pesar del código. Si las políticas no contienen ninguna instrucción para enviar datos, el sistema no lo hará.

Bueno, vale, pero costará un ojo de la cara

Francamente, no recuerdo haber comprado nunca ojos, por lo que no estoy al tanto de su precio en el mercado. Pero, de hecho, esta comparación es dudosa. Nuestro SO no es un producto que esté listo para usar, es una oferta de proyecto. No se trata una solución empaquetada para todos. En su lugar, colaboramos con los vendedores y desarrolladores que proveen de equipos de red, sistemas de automatización industrial, soluciones automáticas, hasta neveras inteligentes. Aportamos el código y ayudamos a configurar el sistema basado en sus requisitos. Por consiguiente, el coste de la producción depende de la aplicación y del trabajo que se debe invertir en el producto final.

¡Todo se puede hackear y vuestro SO no es ninguna excepción!

Estoy de acuerdo, ninguna respuesta es perfecta, excepto la del número 42 :). Puede suceder cualquier cosa. Sin embargo, ¡no hay razón para darse por vencido! La esencia de la ciberseguridad es complicarles la vida a los malos y hacer que los ciberataques cuesten tanto que no les resulte un negocio rentable. En este sentido, nuestro SO va a la cabeza de la competencia.

.@Kaspersky anuncia un SO seguro para #IdC. @E_Kaspersky responde preguntas frecuentesTweet

Eso es todo por ahora. Por favor, enviad vuestras preguntas a través de las redes sociales y entrad en nuestra página web para saber más.