En la actualidad la Fuerza Aeroespacial Colombiana dirige ejercicios en cámaras hipobáricas o de altura, simulando las condiciones que se encontrarían en un vuelo y sometiendo a los tripulantes a pruebas de hipoxia. Esto con el objetivo de entrenar a los tripulantes y pilotos para que reconozcan los síntomas causados por la falta de oxígeno y prevengan posibles riesgos durante el vuelo.

Para facilitar el entrenamiento, los estudiantes de la Universidad de los Andes desarrollaron un sistema ciberfísico para la adquisición de signos vitales durante el entrenamiento de Cámara de altura, que ayuda a identificar cuando los tripulantes entran en estado de hipoxia en tiempo real, monitoreando los datos de pulsoximetría, enviando alarmas a través de un servicio web y almacenándolos en la nube para su posterior consumo. 

Este sistema se considera vulnerable a ataques de hombre en el medio, suplantación, exfiltración de datos, falta de autenticación y autorización en los módulos, careciendo de controles de seguridad necesarios para la confidencialidad y privacidad de la información de los tripulantes.

Teniendo en cuenta la Ley de Protección de Datos Personales 1581 de 2012, los datos relativos a la salud (como lo son los de pulsoximetría), son de carácter sensible y, por tanto, se debe garantizarse que sean tratados como tales cuando están siendo procesados, almacenados o cuando se encuentran en tránsito. Ya que el sistema no cuenta con las protecciones necesarias en sus diferentes componentes, se puede considerar que se están vulnerando los datos privados y semiprivados de los tripulantes.

Se propone diseñar e implementar la arquitectura de seguridad del sistema ciberfísico de medición de pulsoximetría para cámaras de altura, de modo que permita almacenar, trasmitir y procesar los datos sensados, manteniendo el nivel de seguridad y privacidad adecuados. Además de asegurar la adquisición, procesamiento y análisis de los datos médicos de los tripulantes que participan en los entrenamientos de cámara de altura. 

Considerando las necesidades y riesgos de seguridad del sistema ciberfísico, se propone una arquitectura de 3 módulos. Estos están diseñados de acuerdo con la interconexión entre sus principales componentes: las estaciones (compuestas por el tripulante y el dispositivo de sensado), el Gateway/servidor (centralizador de peticiones y datos), la red interna (LAN) y un servicio de almacenamiento en la nube.

Cada módulo contará con controles a nivel de sistema para mitigar los riesgos de seguridad identificados en el manejo de la información médica y personal de los tripulantes.

·         Módulo 1: Estación a Gateway

El primer módulo, ubicado en la cámara de altura, consta de cuatro estaciones para la tripulación y el sector del instructor con actuadores de alerta. Cada estación tiene un dispositivo de sensado “tipo guante” con un sensor de pulsoximetría y un módulo de wifi. En el sector del instructor, el Gateway cuenta con un sensor de presión atmosférica y actuadores de alerta (leds indicadores para señalar hipoxia en las estaciones). El Gateway inicia el entrenamiento indicando a los sensores a través de wifi, sincronizando los tiempos en cada estación y el sensor barométrico. Durante el entrenamiento, los dispositivos informan al Gateway cada 2 segundos sobre su estado. Además, el Gateway procesa y almacena los datos, y administra un actuador para notificar al supervisor sobre cualquier disminución brusca de la saturación de oxígeno por parte de la tripulación.
 
En este módulo, se busca asegurar la transmisión de datos y garantizar un mecanismo de autenticación e identificación para cada estación hacia el Gateway. Se pretende asegurar la autenticidad e integridad de los datos, además de implementar una forma para reconocer, mitigar y darle trazabilidad a acciones maliciosas, como suplantaciones de las estaciones, envío de datos no autorizados o modificaciones en los paquetes intercambiados o fugas. Al mismo tiempo, la estación debería gestionar su propio estado para evitar que, debido a errores de lectura, no responda correctamente y deje de obtener los datos. 

·         Módulo 2: Gateway/Servidor a LAN

En el segundo módulo, el Gateway asume un segundo rol como servidor web y procesa los datos obtenidos del módulo 1 para presentarlos a los usuarios de la red interna a través de una página web. Se propone la implementación de controles de acceso, autorización, consumo, edición y/o eliminación de datos en los diferentes componentes del sistema. Esto se realiza con el objetivo de cubrir posibles escenarios maliciosos en los que los usuarios, canales y plataformas puedan estar involucrados.

·         Módulo 3: Gateway a Cloud.

El último módulo es el que se encarga de la conexión del Gateway con un servicio en la nube. El Gateway envía el archivo .csv con todas las mediciones del ejercicio a un servidor remoto de Cloud, el cual actúa de almacenamiento permanente, permitiendo tener un histórico de los ejercicios.   Este módulo fue creado para garantizar la trazabilidad y backups de los datos en caso de pérdida o eliminación, sin embargo, necesita medidas de protección en cuanto al envío y acceso en la nube de los datos. Debe ajustarse las medidas de acceso en el servidor web que ayuden a mantener un control sobre los cambios de los datos y la lectura de estos, al igual que un ajuste sobre los permisos y privilegios sobre los archivos a subir. 

Se logró implementar los controles necesarios para el manejo de la información en cualquiera de sus estados en cada uno de los módulos definidos. De igual manera, se observó el impacto de cada una de las soluciones implementadas en el sistema en términos de confidencialidad, integridad y disponibilidad, de manera que protejan los datos personales y sensibles de los tripulantes.

Módulo 1: Estación a Gateway

En este módulo se implementó un mecanismo de cifrado para los datos en tránsito y almacenamiento. Teniendo en cuenta que era necesario utilizar un algoritmo de cifrado robusto, pero que pudiera ser soportado por el sistema ciberfísico propuesto y que contara con tiempo de respuesta bajos, se utilizó el algoritmo con esquema ASCON-128. Este cuenta con funcionalidades de cifrado ligero que luego de ser probados con la infraestructura del módulo, tiene la capacidad de cifrar un mensaje de 168 bytes en 0.345 milisegundos y descifrarlo en 0.860 milisegundos, teniendo en cuenta que él envió de datos al Gateway se efectúa entre 2 a 5 segundos, el tiempo de cifrado esta de acuerdo con los requerimientos.

Para la conexión y autenticación entre la estación y el Gateway se implementó un protocolo de autenticación con llaves pre compartidas, usando el tag de la función MAC (Message Autentication Code) de ASCON. El envío y recepción de mensajes en MQTT cifrados, se lograba luego de que se hiciera la verificación del cifrado y su llave de la siguiente forma:                     

                                                              

Con este método de autenticación, se establecían las llaves de cifrado, permitiendo el uso de ASCON para cifrar y descifrar mensajes directamente desde las estaciones y el Gateway. Por otro lado, cualquier error o fallo generado durante este proceso o la comunicación con los dispositivos se registra directamente en los logs de seguridad para ser posteriormente analizado y tomar las decisiones pertinentes.  En general, el módulo contaría con trazabilidad de eventos, integridad, confidencialidad y privacidad de los datos recopilados y la disponibilidad tanto del sistema como de la información 

Módulo 2: Gateway a LAN

Para este caso, el Gateway gestiona el servicio web mediante una herramienta Node-Red y otros dispositivos en la red interna pueden acceder a la página web con un dashboard para consumir los datos a través del navegador. Con esta herramienta, se abordó la seguridad de los datos recibidos desde las estaciones mediante MQTT. 

Uno de los retos en este módulo fue lograr la interacción entre los lenguajes de programación JavaScript y Python, considerando que Node-Red se centra en la programación en bloques con el empleo de JavaScript, mientras que en las estaciones, las placas de desarrollo utilizan Python y MicroPython.  Así se garantizó no solo la integración de los datos recibidos o enviados con estos lenguajes, sino también la validación, integridad y veracidad de los datos obtenidos del módulo anterior, los ingresados por usuarios desde la página web, la configuración del servicio, el manejo de las peticiones y las conexiones.

De igual forma, se configuró de forma exitosa el registro de eventos, manejos de sesiones, generación de formularios de autenticación, y cifrado de datos y comunicaciones mediante TLS y ASCON; todo para garantizar la confidencialidad e integridad de los datos.

Módulo 3: Gateway a Cloud

Este módulo se encarga de transportar el archivo con los datos de la estación a cloud de manera segura. Para esto se usó el gestor de almacenamiento en la nube Dropbox y su documentación, que incluía un script en Python para hacer la carga y descarga de archivos y carpetas a una aplicación de Dropbox, se generó el token de acceso que necesitará el script y se le asignaron los permisos más restringidos posibles. Como el consumo de los datos para la historia clínica está por fuera del alcance del presente proyecto y solo es necesario almacenarlos, se marcaron los permisos para ser solo de escritura a la nube y solo puede ser accedida por el usuario creador de la aplicación.

Para brindar confidencialidad, integridad y privacidad de los datos se utilizó la implementación del cifrado de ASCON en los módulos pasados, la data es almacenada cifrada al llegar a este módulo. Lo que se necesitaba para este segmento era verificar que las tareas o scripts que utilizaban el archivo de datos cifrado, no recibiera entradas de usuarios o se pudiera modificar de alguna forma por un usuario no autorizado.