No hay sistemas operativos sin vulnerabilidades: la única pregunta es qué tan efectivamente los desarrolladores los identifican y los cierran. Nuestro sistema operativo Astra Linux Special Edition no es una excepción: constantemente verificamos y probamos el código en busca de errores, violaciones lógicas, otros errores y los solucionamos rápidamente. De lo contrario, el FSTEC de Rusia difícilmente habría certificado a Astra Linux para procesar datos que constituyen secretos de estado. Pero hablaremos sobre la certificación con más detalle en otra publicación. Y en esto hablaremos sobre cómo se organizan las vulnerabilidades de Astra Linux y cómo interactúan las amenazas de seguridad de la información con el banco de datos nacional.
Foto: Leonhard Foeger / ReutersEl primer acercamiento, arquitectónico
Para mejorar la seguridad del sistema operativo, utilizamos dos enfoques. El primero,
arquitectónico , es que desarrollamos e implementamos varias herramientas de protección de información en la etapa de diseño. Estas herramientas forman un
complejo de equipos de protección (KSZ) , que implementa funciones de seguridad. Con la ayuda de KSZ, estamos tratando de garantizar que el sistema ya minimice el riesgo de posibles amenazas de forma predeterminada.
Arquitectura de la suite de seguridad Astra LInux Special EditionUn elemento clave de KSZ es
el monitor de llamadas , diseñado para evitar el acceso no autorizado y la alteración de los componentes protegidos del sistema. El monitor proporciona control de acceso discrecional, basado en roles y obligatorio, así como un monitoreo de integridad obligatorio.
¿Qué es
el monitoreo obligatorio de integridad ? Vamos a ilustrar con un ejemplo. Un componente clave del sistema operativo es el núcleo. En consecuencia, estamos obligados a proporcionarle el tiempo de ejecución más seguro en el propio sistema operativo para reducir la cantidad de métodos posibles para atacar el núcleo.
Para hacer esto, implementamos monitoreo de integridad obligatorio en el sistema operativo, debido a lo cual segmentamos el sistema operativo por varios subsistemas para que romper un subsistema no afecte el rendimiento de otros. Si un usuario sin privilegios del sistema operativo (nivel de integridad 0) o un subsistema de red (nivel de integridad 1), un sistema de virtualización (nivel de integridad 2), una interfaz gráfica (nivel de integridad 8) u otro componente es pirateado, esto no implicará desacreditar todo el KSZ (nivel de integridad) 63)
Cabe señalar que estos niveles no son jerárquicos, es decir, no están ubicados uno encima del otro y están completamente aislados entre sí en términos de la posibilidad de derechos de escritura. El monitor de acceso determina el accesorio de un objeto a uno u otro nivel de integridad por la máscara de bits.
Para que los niveles de integridad no se perciban como jerárquicos, es decir, "el nivel 8 tiene más derechos que el nivel 2", lo cual es incorrecto, cada uno de los niveles recibe su nombre. Entonces, por ejemplo, el octavo nivel de integridad se llama "Servidor gráfico", el nivel máximo posible de integridad del administrador en el sistema es "Alto" y el nivel cero de integridad (usuario) es "Bajo".
El monitor de llamadas, que se describió en nuestro
artículo anterior, controla y elimina la posibilidad de influenciarse mutuamente en los procesos con etiquetas de diferentes niveles de integridad.
Por lo tanto, el sistema operativo recibe un conjunto de reglas sobre cómo aislar los procesos del sistema entre sí, y ahora comprende qué procesos, incluso aquellos iniciados por un usuario con altos privilegios, no tienen derecho a escribir en otros procesos o archivos.
Por lo tanto, si como resultado de la explotación de una vulnerabilidad (incluido el día cero), un atacante obtiene el control sobre un proceso en el sistema y aumenta su autoridad para un usuario privilegiado (por ejemplo, root), su marca de integridad seguirá siendo la misma y, en consecuencia, no recibirá la capacidad de influir en los procesos del sistema, cambiar la configuración u ocultar su presencia en el sistema.
Principio de funcionamiento de niveles de integridad aislados.Por lo tanto, no todo el sistema operativo se convierte en un objetivo importante para un atacante, sino solo el núcleo endurecido y el monitor de acceso más compacto, que ya reduce significativamente la superficie de ataque.
Además de lo obligatorio, también existe un control de integridad dinámico y regulatorio. Se utilizan para excluir el lanzamiento y el uso de software no confiable o de terceros, así como las comprobaciones periódicas de la integridad del sistema.
El control dinámico calcula y verifica la firma digital electrónica de los archivos ejecutables en el momento de su lanzamiento. Si no hay EDS o si es incorrecto, se denegará el inicio de los programas. Hasta cierto punto, esta es una implementación del concepto de listas blancas, pero a través del uso de una jerarquía de claves emitidas para desarrolladores de software.
Trabaja con control de integridad dinámicoEl control de rutina verifica la integridad e inmutabilidad de los archivos clave para un sistema comparando sus sumas de verificación con valores de referencia. Puede ser archivos de configuración o cualquier otro.
Por lo tanto, el sistema operativo utiliza protección en capas contra las vulnerabilidades en las aplicaciones y su sustitución, minimizando así el daño de las amenazas de seguridad, incluidas las que utilizan vulnerabilidades de día cero.
El segundo, enfoque de proceso
Junto con la arquitectura, utilizamos simultáneamente el enfoque de
proceso : identificamos y recopilamos constantemente información sobre vulnerabilidades, trabajamos con esta información y transferimos los resultados al banco de datos de vulnerabilidad FSTEC Rusia. Así que preparamos y lanzamos actualizaciones del sistema operativo programadas y operativas. Estamos buscando vulnerabilidades tanto en código abierto como de forma independiente, especialmente en aquellas partes del software que desarrollamos completamente nosotros mismos. Obtenemos mucha información de socios que participan en investigaciones similares: probar y estudiar la seguridad de los sistemas operativos.
Gestión de vulnerabilidadesLos estudios de seguridad se realizan principalmente en relación con los componentes que forman parte de Astra Linux Special Edition (Smolensk). Al mismo tiempo, las vulnerabilidades también están cerradas para Astra Linux Common Edition, como parte de las actualizaciones de seguridad y como parte de una actualización programada de los componentes del sistema.
Tan pronto como recibamos información sobre la vulnerabilidad, verificamos cuán relevante es para nuestros usuarios.
Si la vulnerabilidad no es crítica, la describimos en el próximo número del boletín de seguridad en el sitio web oficial. Las notificaciones sobre el tema de las papeletas se envían al usuario por correo electrónico, cuya dirección se indica necesariamente en el acuerdo de licencia.
Para vulnerabilidades críticas, se emiten pautas durante varios días : ¿cómo puede solucionarlo usted mismo sin esperar una actualización de seguridad acumulativa? En la
lista de boletines
de seguridad, están marcados con las letras MD (dirección metódica).
Una vulnerabilidad es un buen ejemplo aquí, cuya información se
publicó aquí en Habré. Por cierto, el autor de este artículo no se contactó con nosotros por adelantado y no notificó preliminarmente que había identificado esta vulnerabilidad y estaba preparando material. Como ilustración, decidimos citar el momento del trabajo sobre la vulnerabilidad desde el momento en que se publicó el texto en el recurso.
Entonces, por la noche, a las 4 a.m., el 9 de julio de 2019, se publicó el artículo en sí, que al manipular el tamaño de la pantalla de una máquina virtual, puede ver las ventanas debajo del bloqueo de pantalla.
Vale la pena señalar que para aprovechar la vulnerabilidad demostrada en video, debe realizar una serie de pasos adicionales: primero debe instalar paquetes adicionales en la máquina virtual Astra Linux y luego en la máquina invitada, que son responsables de cambiar la resolución de la máquina virtual sobre la marcha, pero no son parte de un sistema operativo certificado.
El 10 de julio de 2019, se
publicó información de vulnerabilidad en la BDU FSTEC. La gravedad de la vulnerabilidad se definió como media (la puntuación base para la métrica CVSS 2.0 fue 4.9, para la métrica CVSS 3.0 - 4).
El 12 de julio,
publicamos el boletín de seguridad No.
20190712SE16MD para Astra Linux Special Edition versión 1.6 y el boletín de seguridad No.
20190712SE15MD para Astra Linux Special Edition versión 1.5. Astra Linux Common Edition recibió una actualización de seguridad similar.
Por lo tanto, han transcurrido menos de 4 días desde la publicación de información sobre la vulnerabilidad de nivel medio al lanzamiento del parche para todas las versiones de Astra Linux (donde es posible la virtualización).
Esquema de actualizaciones en vivo para Astra LinuxAl menos una vez al trimestre, lanzamos actualizaciones de seguridad: actualizaciones
operativas que eliminan vulnerabilidades desconocidas anteriormente, incluido el software de aplicación, las bibliotecas y las funciones del sistema operativo que no implementan requisitos de seguridad. Si las amenazas de seguridad implementadas con la vulnerabilidad no se pueden descartar con medidas compensatorias, se está trabajando para finalizar el sistema operativo. Después de completar el desarrollo y las pruebas de la actualización de seguridad, el sitio web también publica el boletín y la actualización en sí. En los primeros seis meses de 2019, se lanzaron dos actualizaciones acumulativas para Astra Linux Special Edition versión 1.6, que cubren cientos de vulnerabilidades diferentes. Ahora el tercero se está preparando para su lanzamiento.
Finalmente, estamos interactuando activamente con la comunidad de desarrolladores:
- En el proyecto, informamos a los rastreadores de errores sobre los errores autodetectados;
- transferimos a los proyectos correcciones de deficiencias ya hechas, cerradas por nosotros;
- Hacemos un llamado a la comunidad para que ayude a eliminar las deficiencias: el conocimiento de la lógica del programa le permite obtener una corrección de un orden de magnitud más rápida que la ingeniería inversa realizada por su cuenta;
- Usamos e incluimos en nuestras actualizaciones todas las correcciones emitidas por la comunidad. Entendemos que mejorando así la calidad del producto. Al mismo tiempo, aplicamos los métodos de control y fomento de la confianza, que se describieron en el artículo anterior .
La apertura es importante
Dado que nuestro sistema operativo está certificado por el FSTEC de Rusia, en primer lugar agregamos información sobre las vulnerabilidades encontradas en el Banco de datos de amenazas de seguridad de la información (DBU) de FSTEC para su publicación oficial: si va al
DBU , encontrará información sobre más de 350 vulnerabilidades fijas en diferentes versiones de Astra Linux así como información detallada sobre ellos.
Por lo tanto, aseguramos la apertura en el trabajo. Gracias a esto, los usuarios, incluido el regulador, pueden confiar en cierta medida en que la seguridad está bajo control. No es suficiente obtener una actualización, debe comprender qué vulnerabilidades específicas cerró.
Hasta ahora, nuestro enfoque arquitectónico y de proceso para mantener la seguridad del sistema operativo está totalmente justificado: mantenemos con éxito un alto nivel de seguridad para los sistemas de información con el sistema operativo Astra Linux Special Edition. Y el acceso abierto a la información sobre vulnerabilidades a través del panel de control FSTEC aumenta el nivel de confianza en nuestro producto.
Estaremos encantados de responder preguntas sobre la seguridad de nuestro sistema en los comentarios. Además, si está interesado en aprender algo nuevo sobre el sistema, deje sus deseos: los tendremos en cuenta cuando trabajemos más con el blog.