¿Puede un ciberataque provocar un accidente con un dron?
Hornero Cyber · Ciberseguridad aplicada a sistemas UAS · Artículo 1 de 12
Una operación de inspección parece transcurrir normalmente. La aeronave mantiene altura, la pantalla muestra una trayectoria estable y el equipo recibe imágenes. Sin embargo, un dato utilizado para navegar fue alterado. El sistema sigue funcionando, pero toma decisiones sobre una representación incorrecta de su entorno. Esa diferencia entre funcionamiento aparente y comportamiento seguro explica por qué la ciberseguridad forma parte del análisis operacional de los drones.
La respuesta a la pregunta del título es sí: un evento de ciberseguridad puede contribuir a un accidente. No significa que cualquier vulnerabilidad termine en una caída ni que un comportamiento anómalo demuestre un ataque. Para entender el riesgo hay que reconstruir una cadena: acceso o interferencia, función afectada, respuesta del sistema, barreras disponibles y exposición de terceros. La seguridad depende de esa cadena completa.
El dron es una parte del sistema
Un UAS comprende más que una aeronave. La operación utiliza estación de control, comunicaciones, navegación, software, personas y procedimientos. Puede depender también de redes corporativas, servicios externos y equipos de mantenimiento. Una debilidad en tierra puede alcanzar una función que parece exclusivamente aérea. Por eso, analizar solamente el vehículo deja fuera una parte relevante de la superficie de exposición.
La Cyber Safety Extension de JARUS vincula la protección de las tecnologías operacionales con la prevención de efectos sobre la seguridad de la aviación. También pide considerar las dependencias de esas tecnologías respecto de recursos informáticos corporativos. Su foco incluye sistemas de control de aeronaves y sistemas de control en tierra. Esta perspectiva permite formular una pregunta útil: ¿qué recursos deben ser confiables para que la misión siga siendo segura? Fuente documental: Cyber Safety Extension 2.5, introducción, pp. 8–9.
De la vulnerabilidad al peligro
Una vulnerabilidad es una debilidad que puede ser aprovechada. Una amenaza describe una posible causa de daño. El peligro operacional aparece cuando el sistema puede llegar a una condición capaz de causar consecuencias adversas. Conviene distinguir estos conceptos porque instalar una actualización, bloquear una cuenta o detectar una interferencia atienden problemas diferentes. Ninguna de esas acciones, por sí sola, demuestra que la operación completa está protegida.
Imaginemos una misión cuyo archivo de puntos de paso cambia antes del despacho. El peligro no es solamente que alguien haya accedido al archivo: la aeronave podría recibir una trayectoria incompatible con el volumen previsto. Una revisión independiente de la misión podría detener la cadena antes del despegue. Si la revisión utiliza la misma copia alterada y no existe una referencia confiable, la aparente doble comprobación puede conservar el error.
Este es un ejemplo hipotético de análisis técnico, no un incidente atribuido a un fabricante. JARUS describe precisamente la manipulación de bases de datos de terreno y puntos de paso como una amenaza para los sistemas de guiado. Señala verificaciones de integridad y autenticidad y extiende la atención a los equipos terrestres utilizados para cargar información. Fuente documental: Cyber Safety Extension 2.5, §§2.5.1–2.5.2, p. 16.
Tres efectos que cambian la operación
La confidencialidad protege la información frente a divulgación no autorizada. La integridad protege su exactitud y evita modificaciones indebidas. La disponibilidad permite utilizarla cuando se necesita. En un UAS, perder imágenes comerciales puede afectar el negocio; perder disponibilidad del mando o integridad de los datos de navegación puede afectar el vuelo. La consecuencia depende de la función concreta que usa cada dato, no solamente de su valor económico.
También importa la autenticidad: conocer si una fuente es realmente quien aparenta ser. Una pantalla puede mostrar información consistente pero proveniente de una fuente equivocada. La autenticación verifica identidades; la autorización limita lo que pueden hacer. Separar ambas evita asumir que una persona habilitada para consultar vuelos debería poder modificar misiones, administrar usuarios y cambiar parámetros críticos. JARUS presenta estos atributos y conceptos como base del análisis. Fuente documental: Cyber Safety Extension 2.5, §§1.1.1–1.1.7, pp. 10–11.
El ataque puede parecer una falla
Un enlace que deja de responder puede presentar el mismo síntoma frente a una interferencia intencional, una falla de equipo o un problema de cobertura. Una posición falsa puede parecer una avería de navegación. Durante el vuelo, la tripulación necesita actuar sobre la condición operacional observada; investigar la causa exige evidencia adicional. Esperar una atribución definitiva antes de ejecutar una contingencia puede consumir el tiempo disponible para controlar el riesgo.
La extensión de JARUS advierte que un episodio de spoofing GPS podría presentarse como un mal funcionamiento y que el jamming del enlace C2 puede manifestarse como pérdida de enlace. Propone coordinar el análisis de cyber safety con el análisis de seguridad del sistema. La aplicación práctica consiste en incluir causas intencionales entre las hipótesis que pueden producir fallas funcionales, conservando la incertidumbre cuando la evidencia no permite distinguirlas. Fuente documental: Cyber Safety Extension 2.5, capítulo 3, apartado OSO #05, p. 30.
Un ejemplo de operación BVLOS
Consideremos una inspección BVLOS de una instalación industrial. El operador recibe una alerta de navegación y observa discrepancias entre posición, trayectoria y otras referencias disponibles. El procedimiento debe indicar quién decide la interrupción, qué opciones de recuperación fueron validadas y qué limitaciones tienen. Ordenar un retorno automático sin revisar sus dependencias podría ser inadecuado si ese retorno necesita justamente la navegación cuya confiabilidad está en duda.
La solución tampoco es recomendar una maniobra universal. La respuesta depende del modelo, configuración, entorno y procedimientos autorizados. El equipo necesita conocer qué ocurre al perder cada servicio y qué evidencia respalda ese comportamiento. El escenario debe ensayarse de forma controlada, sin emitir interferencias ni comprometer sistemas reales. Un ejercicio de mesa permite revisar decisiones, tiempos, responsabilidades y comunicaciones antes de una validación técnica específica.
Qué aporta SORA 2.5
El Main Body incorpora la Cyber Safety Extension como suplemento para los anexos B y E y ubica los OSO en el paso 9. El paso 10 reúne argumentos y evidencias en el Comprehensive Safety Portfolio. Por lo tanto, documentar una medida digital cobra sentido cuando se explica qué función protege y cómo sostiene una afirmación de seguridad. No corresponde asignar un SAIL ni otorgar crédito a una mitigación por mencionar ciberseguridad. Fuente documental: Main Body 2.5, §§1.3(f), 4.9 y 4.10, pp. 19 y 53–57.
SORA también delimita su alcance. Los aspectos de privacidad, ambientales y financieros quedan fuera de la aplicabilidad indicada en el Main Body. Esto no les resta importancia para la empresa: significa que requieren una gestión complementaria. Una filtración de datos puede ser grave sin alterar el vuelo. Si además permite modificar misiones o comprometer un servicio crítico, el análisis debe seguir esa conexión concreta hasta la seguridad operacional. Fuente documental: Main Body 2.5, §1.3(g), p. 19.
Por dónde empezar
Como buenas prácticas propuestas por Hornero, conviene inventariar los activos que sostienen la misión; asignar responsables; separar permisos de consulta, planificación y administración; controlar la procedencia de software y archivos; y definir condiciones de interrupción. Cada medida necesita un alcance verificable. Una cuenta individual mejora la trazabilidad, pero no resuelve una interferencia radioeléctrica. Una copia de respaldo facilita recuperar información, pero no garantiza que la misión cargada sea correcta.
El registro mínimo debería conectar amenaza, función, consecuencia, control y evidencia. Para una misión alterada: quién puede editarla, cómo se aprueba, qué versión se carga y cómo se verifica antes del despacho. Para pérdida de enlace: qué detecta la condición, qué hace la aeronave y cómo responde la tripulación. Para un equipo de mantenimiento comprometido: qué accesos se bloquean y cómo se confirma una configuración confiable antes de liberar la aeronave.
La ciberseguridad aplicada a drones empieza cuando dejamos de mirar solamente contraseñas y comenzamos a mirar decisiones de vuelo. Un sistema conectado puede transformar una debilidad digital en un problema físico; una organización preparada puede cortar esa cadena. En el siguiente artículo analizaremos cinco familias de vectores para ordenar esa revisión sin confundir una lista de amenazas con una evaluación completa.
Para revisar las dependencias tecnológicas de tu operación UAS y su documentación de riesgo, 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: introducción; §§1.1 y 2.5; capítulo 3, OSO #05. Enlaces y páginas junto a las afirmaciones.
JARUS, Main Body, JAR-DEL-SRM-SORA-MB-2.5, edición 2.5, 13/05/2024, Release: §§1.3, 4.9 y 4.10.
Los ejemplos son hipotéticos. Las recomendaciones de Hornero son interpretación técnica y buenas prácticas; su aplicabilidad debe verificarse para cada operación.
