Los cinco vectores de ataque más importantes en un sistema UAS

Hornero Cyber · Ciberseguridad aplicada a sistemas UAS · Artículo 2 de 12

Cuando una empresa pregunta cómo proteger sus drones, suele empezar por el enlace de radio. Es una preocupación razonable, aunque incompleta. Una misión también puede quedar expuesta por una cuenta administrativa, un equipo de mantenimiento, una fuente de navegación o un servicio externo. La protección requiere reconocer por dónde entra una amenaza y qué funciones puede alcanzar desde ese punto.

Presentamos cinco familias de vectores útiles para ordenar una revisión operacional. El título no representa un ranking estadístico ni una lista exhaustiva de JARUS: es una selección editorial de Hornero. La prioridad real depende del CONOPS, las interfaces existentes y las consecuencias posibles. Un sistema sin conexión cloud tendrá una exposición diferente de una instalación remota que comparte red con proveedores y herramientas corporativas.

1. Identidades, cuentas y permisos

Una cuenta comprometida puede permitir consultar información, modificar misiones o administrar el sistema, según los privilegios que tenga. La contraseña es solamente una parte del problema. También importan las sesiones abiertas, las cuentas compartidas, las credenciales de integraciones y los accesos que siguen activos cuando una persona deja el equipo. El inventario debe incluir identidades humanas y cuentas utilizadas por software.

La pregunta operacional es qué puede hacer cada identidad. Separar consulta, edición y aprobación reduce la posibilidad de que un único acceso concentre todas las decisiones. Cuando la plataforma lo permite, una cuenta de trabajo cotidiano debería tener los permisos necesarios para esa tarea. Las capacidades administrativas requieren un tratamiento diferente. La autenticación verifica quién accede; la autorización define qué acciones están permitidas. Fuente documental: Cyber Safety Extension 2.5, §§1.1.5–1.1.7 y 1.2.5, pp. 10–12.

En un ejemplo hipotético, un colaborador conserva permisos para cambiar rutas después de terminar un contrato. La falla organizacional existe aun cuando nunca ocurra un ataque. Como buena práctica, el proceso de altas, cambios y bajas debe vincular cada acceso con un responsable y una necesidad vigente. Conviene comprobar también cómo se revocan sesiones y credenciales de integración: borrar un nombre de una lista puede no cubrir todas las formas de acceso.

2. Comunicaciones y enlaces

Las comunicaciones pueden sufrir pérdida de disponibilidad, interceptación o alteración. Es necesario distinguir el enlace que sostiene el mando de un flujo utilizado únicamente para entregar resultados. También hay que identificar conexiones intermedias: red local, acceso a Internet o servicios de telecomunicaciones, cuando forman parte de la arquitectura. Llamar a todo ello “el enlace” puede ocultar puntos de falla diferentes.

JARUS describe jamming y secuestro de comunicaciones y presenta métodos criptográficos para reducir amenazas sobre integridad y autenticidad. Esas medidas no son intercambiables. Cifrar información no impide que una señal sea interferida; disponer de otro acceso de red no demuestra que ambos caminos sean independientes. La evaluación debe separar confidencialidad, integridad, autenticación y continuidad. Fuente documental: Cyber Safety Extension 2.5, §§1.3.1–1.3.3 y 2.2, pp. 12 y 14–15.

Para una operación BVLOS, la revisión debería producir una respuesta concreta: qué condición se detecta, cuánto tiempo puede tolerarse y qué comportamiento fue validado para la configuración utilizada. La revisión documental puede identificar vacíos, pero no reemplaza ensayos pertinentes ni evidencia del fabricante. Las comprobaciones deben realizarse con autorización y en entornos controlados; provocar interferencias en el lugar de operación no constituye una prueba segura.

3. Navegación, sensores y datos de misión

El sistema puede tomar decisiones peligrosas sobre datos incorrectos aunque mantenga conectividad. Posición, terreno, obstáculos y puntos de paso son ejemplos de información cuyo uso importa tanto como su origen. El análisis debe identificar qué datos se aceptan automáticamente, qué validaciones existen y si hay referencias independientes para detectar inconsistencias. Una pantalla sin alertas no prueba que todas sus fuentes sean confiables.

La Cyber Safety Extension trata el spoofing de sensores y la manipulación de bases de datos de guiado. Incluye GNSS entre las fuentes susceptibles de interferencia o información falsa. Como interpretación técnica, revisar una misión exige conocer la procedencia y versión de los archivos, proteger su transferencia y comprobar su correspondencia con la planificación aprobada. Fuente documental: Cyber Safety Extension 2.5, §§2.3 y 2.5, pp. 15–16.

Un ejemplo: la ruta correcta se aprueba, pero se carga una versión anterior con otro punto de recuperación. La consecuencia puede parecer similar a la de una alteración deliberada. Mantener controles de configuración atiende ambas posibilidades sin confundir error con ataque. La evidencia útil incluye quién modificó la misión, qué revisión fue aprobada y cuál recibió efectivamente la aeronave. La etiqueta del archivo, por sí sola, no resuelve esa trazabilidad.

4. Mantenimiento, firmware y cadena de suministro

Un portátil de mantenimiento tiene una relación especial con el UAS: puede introducir cambios que persisten después de desconectarlo. Los medios removibles, las herramientas de diagnóstico y los componentes de reemplazo también merecen atención. La amenaza no se limita al archivo descargado; incluye el equipo que lo manipula y el procedimiento que lo incorpora a la configuración operacional.

JARUS enumera como vías de introducción de malware las descargas desde fuentes no verificadas, los medios removibles infectados y la conexión de equipos comprometidos. La extensión relaciona estas situaciones con protección contra malware, control de acceso y gestión de proveedores. La autenticidad de la fuente y la integridad del archivo responden preguntas distintas, y ambas pueden necesitar evidencia. Fuente documental: Cyber Safety Extension 2.5, capítulo 3, OSO #03, pp. 23–29.

Como práctica propuesta, cada actualización debería dejar un registro de procedencia, aplicabilidad, equipos afectados, comprobaciones realizadas y autorización de puesta en servicio. Si una actualización cambia el comportamiento de contingencia, no alcanza con confirmar que instaló correctamente. Hay que revisar las premisas de la operación. Tampoco corresponde mantener una versión vulnerable indefinidamente por temor al cambio: se necesita una decisión documentada sobre ambos riesgos.

5. Servicios externos e integraciones

Una operación puede utilizar servicios para planificar, coordinar, supervisar o almacenar información. La dependencia debe describirse por función. ¿El servicio es necesario durante el vuelo? ¿Su pérdida afecta solamente la entrega de imágenes? ¿Una integración puede escribir datos que luego consume el sistema de control? Estas diferencias determinan el alcance del análisis y las responsabilidades que deben acordarse.

La extensión indica que OSO #13 comprende servicios externos necesarios para la seguridad del vuelo y destaca la definición de roles y responsabilidades. No todos los servicios comerciales son automáticamente críticos para safety. Como interpretación técnica, una interfaz con permisos de escritura puede crear una conexión relevante incluso si originalmente se instaló para un fin administrativo. Fuente documental: Cyber Safety Extension 2.5, capítulo 3, OSO #13, pp. 37–38.

Cómo transformar la lista en una evaluación

Para cada familia, registrá un escenario completo: activo, punto de acceso, función alcanzable, condición peligrosa, controles y evidencia. Después revisá dependencias comunes. Dos barreras que utilizan la misma cuenta o el mismo equipo pueden perder efectividad juntas. La defensa en profundidad busca varias capas, pero su utilidad depende de cómo interactúan y de qué ocurre cuando alguna falla. Fuente documental: Cyber Safety Extension 2.5, §1.2.4, p. 11.

La prioridad debería reflejar exposición, capacidad de producir una condición peligrosa y calidad de las barreras existentes. Asignar números sin datos puede dar una falsa sensación de precisión. Conviene declarar la incertidumbre y decidir qué verificación falta. El resultado útil es una lista de acciones con responsables y criterios de cierre, no una colección de términos amenazantes. El próximo artículo profundizará en GNSS y la diferencia entre perder una posición y confiar en una posición falsa.

Para organizar una revisión de amenazas de tu operación, contactá a Hornero.

Bibliografía verificada

• JARUS, Cyber Safety Extension, JAR-DEL-SRM-SORA-Cyb-2.5, edición 2.5, 13/05/2024, Release: §§1.1–1.3 y 2.2–2.5; capítulo 3, OSO #03 y #13. Citas y páginas junto a las afirmaciones.

Ejemplos hipotéticos y recomendaciones de Hornero. La selección de cinco familias no sustituye una evaluación específica ni demuestra cumplimiento SORA.