Resumen

  • ARTEMIS es un sistema de código abierto gestionado por el operador que compara observaciones BGP en directo con la intención local de enrutamiento, aportando a las redes un contexto que los colectores públicos no pueden ofrecer por sí solos.
  • La investigación de FORTH y CAIDA de 2018 informó de detección en cuestión de segundos y neutralización en menos de un minuto bajo las condiciones probadas; el resultado no constituye una garantía universal para producción.
  • Su mitigación puede anunciar rutas más específicas o activar flujos de trabajo personalizados, pero los filtros, las políticas obsoletas, la visibilidad incompleta y unas credenciales demasiado amplias pueden convertir una respuesta rápida en un segundo incidente.
  • El proyecto depende ahora de publicaciones disciplinadas, pruebas creíbles de despliegue y una delimitación transparente con Code BGP, cuyo mantenimiento comercial puede sostener el software abierto sin sustituir su trayectoria investigadora.

Un cambio de ruta real demostró por qué los segundos son solo el principio

El informe anual de CAIDA de 2019 señala que ARTEMIS detectó en cuestión de segundos un secuestro real que afectaba a un /30 de Internet2. El suceso es importante porque lleva la evidencia más allá de los anuncios sintéticos diseñados por los investigadores. Una ruta en directo cambió en una red participante en el despliegue, y el sistema reconoció la desviación con rapidez suficiente para apoyar la investigación.

El informe no establece una distribución universal de los tiempos de detección. Un /30 es un prefijo concreto dentro de un contexto de enrutamiento específico, observado mediante las fuentes disponibles para ese despliegue. Otro suceso puede propagarse de manera distinta, durar menos tiempo o permanecer fuera de los colectores conectados. El informe tampoco demuestra por sí solo una intención maliciosa ni todos los efectos sobre el plano de datos. La conclusión prudente es que ARTEMIS detectó en segundos un suceso real notificado durante el programa de despliegue de CAIDA.

Los estudios de caso tienen valor precisamente cuando se conservan sus límites. Revelan cómo se comporta el software ante cambios reales, cómo reciben los operadores la alerta y qué evidencia queda disponible después. Más registros de incidentes, incluidos falsos positivos, sucesos no detectados y resultados de mitigación, contribuirían más a demostrar la madurez para producción que otra afirmación llamativa sobre tiempos.

Una alerta BGP puede llegar en segundos y aun así dejar sin respuesta las preguntas más importantes. Un colector de rutas puede mostrar que un sistema autónomo desconocido ha anunciado un prefijo o que ha aparecido una ruta más específica y ha comenzado a propagarse. Esa evidencia indica al operador que el plano de control ya no coincide con el patrón esperado. Por sí sola, no determina quién realizó el cambio, si fue accidental, si el tráfico siguió la nueva ruta, si los usuarios sufrieron daños ni qué respuesta restaurará el servicio sin crear otro problema.

ARTEMIS se diseñó en torno a esa brecha entre la detección y la acción. Su nombre corresponde a Automatic and Real-Time dEtection and MItigation System, pero el acrónimo en mayúsculas no debe distraer de su modelo operativo. No es un servicio central que vigile toda Internet y repare a distancia las redes de terceros. Una organización despliega el software en la infraestructura que controla, define el estado de enrutamiento que considera legítimo, conecta observaciones públicas y privadas y decide hasta dónde puede actuar el sistema cuando esas observaciones se apartan de la política.

La promesa del proyecto es velocidad con contexto; su limitación es que tanto el contexto como la autoridad son locales.

ARTEMIS se parece, por tanto, menos a una policía de Internet que a un instrumento de sala de control propiedad del operador. Puede organizar la evidencia, reducir el tiempo dedicado a buscar entre actualizaciones de rutas y preparar una respuesta previamente debatida. No puede eximir al operador de aplicar su criterio. La decisión final puede afectar al enrutamiento global, a las relaciones con proveedores y al tráfico de clientes, por lo que la calidad de la respuesta depende tanto de las personas, la configuración y una autoridad ensayada como del detector.

BGP puede transmitir alcance antes de poder demostrar autoridad

El Border Gateway Protocol permite que redes gestionadas de forma independiente intercambien información de alcance y apliquen políticas locales. Un sistema autónomo anuncia que puede alcanzar un conjunto de prefijos IP; las redes vecinas deciden si aceptan, prefieren y propagan esas rutas. Este modelo permitió que Internet escalara entre organizaciones que no comparten un único controlador, pero el protocolo original no incorpora una prueba criptográfica a cada afirmación sobre el origen o la ruta. Por ello, una exportación errónea, una configuración obsoleta o un anuncio deliberado pueden introducir una ruta que no debería existir.

La selección de rutas puede hacer atractivo un anuncio incorrecto. Cuando dos rutas cubren prefijos de la misma longitud, las redes aplican políticas y reglas de selección que varían según el operador. Cuando un atacante o una red equivocada anuncia un subprefijo más específico, la regla habitual de coincidencia con el prefijo más largo suele dirigir el tráfico hacia la ruta más estrecha allí donde se acepta. El mecanismo no es una función especial de ataque, sino la regla ordinaria que permite a los routers elegir el destino más preciso.

Por eso, un anuncio aparentemente pequeño puede redirigir tráfico con rapidez aunque el agregado legítimo siga siendo visible.

La palabra «secuestro» es una abreviatura útil, pero puede implicar una intención que los mensajes de enrutamiento no revelan. Un origen no autorizado puede ser malicioso, accidental o consecuencia de un cambio comercial legítimo que no se reflejó en la política de supervisión. Una ruta fabricada puede utilizarse para interceptar tráfico, pero una actualización del plano de control no demuestra que se haya producido una interceptación. ARTEMIS funciona mejor cuando trata la alerta como una divergencia entre el enrutamiento observado y el previsto, dejando la atribución y el impacto a un proceso de incidente más amplio.

Un suceso de prefijo exacto compite con la ruta legítima con la misma longitud de prefijo. Su alcance depende de las políticas y las elecciones de ruta de las redes que reciben ambos anuncios. Algunas partes de Internet pueden preferir la ruta inesperada, mientras otras continúan utilizando el origen legítimo. El resultado puede ser un alcance parcial, diferencias regionales y una mezcla confusa de éxitos y fallos, en lugar de una interrupción clara. La detección debe atender no solo a la existencia de una ruta, sino también a dónde y cómo se propaga.

Un suceso de subprefijo suele ejercer una atracción más directa porque la coincidencia con el prefijo más largo da prioridad a la ruta más estrecha. Si una red anuncia normalmente un /20 y otro origen anuncia un /24 dentro de él, los routers que acepten el /24 enviarán por lo general el tráfico destinado a esas direcciones hacia el subprefijo. La desagregación también es una defensa habitual: el operador legítimo anuncia rutas equivalentes o aún más específicas para recuperar la preferencia. Sin embargo, la defensa encuentra un límite estricto, porque muchas redes filtran rutas IPv4 más largas que /24 y rutas IPv6 más largas que /48.

Un operador que ya anuncie esas longitudes puede no disponer de una ruta más estrecha aceptada globalmente.

ARTEMIS también contempla la ocupación de espacio y determinadas infracciones de política, incluido un patrón de no-exportación descrito en el material del proyecto. Estas categorías importan porque los incidentes de enrutamiento no se limitan a que un desconocido origine el prefijo de una víctima. Una ruta puede tener un origen autorizado y aun así exportarse mediante una relación inesperada. Un sistema de supervisión necesita contexto de política suficiente para distinguir esos casos sin pretender que los datos BGP revelan todos los acuerdos privados entre redes.

ARTEMIS incorpora al detector la intención de enrutamiento del propio operador

Los servicios externos de supervisión tienen una ventaja evidente: pueden recopilar información desde muchas partes de Internet sin exigir que cada red ejecute un sistema completo. Su desventaja es igual de importante. Un tercero puede ver los prefijos y las rutas anunciados, pero quizá desconozca qué cambios de origen, proveedores de respaldo, rutas de ingeniería de tráfico o anuncios de emergencia considera legítimos el operador. Por ello, las reglas genéricas pueden pasar por alto infracciones sutiles de política o generar alarmas ante cambios planificados.

ARTEMIS invirtió el punto de vista. El detector lo gestiona la organización cuyo espacio de direcciones está en riesgo, y esa organización aporta la referencia válida. Los colectores públicos siguen proporcionando una amplia visibilidad externa, pero sus observaciones se interpretan mediante conocimiento privado sobre prefijos protegidos, AS de origen autorizados, vecinos aceptables y determinadas relaciones de ruta. Las fuentes de routers locales pueden añadir sucesos que los colectores públicos no ven.

La combinación constituye la idea definitoria del proyecto: una evidencia global incompleta resulta más útil cuando se compara con una intención local explícita.

Situar el detector dentro de la red defendida también desplaza la responsabilidad hacia el interior. Una red que mantiene ARTEMIS debe decidir quién es responsable del archivo de políticas, cómo se revisan los cambios, qué alertas llegan al centro de operaciones de red, qué puede inferir el equipo de seguridad y quién puede autorizar una nueva ruta. El software puede hacer visible esa responsabilidad. No puede lograr que la institución la ejerza correctamente.

ARTEMIS pide al operador que defina los prefijos protegidos, los AS de origen legítimos, las relaciones vecinales aceptables y determinadas reglas de enrutamiento. Esta referencia permite al detector plantear una pregunta más precisa que un servicio genérico de supervisión. En lugar de decidir si una ruta parece inusual frente al historial global, el sistema puede determinar si infringe la intención declarada de la red.

Esa ventaja solo es tan fiable como la declaración. Las redes cambian de proveedor, añaden ubicaciones anycast, trasladan AS de origen, establecen rutas temporales de respaldo y realizan anuncios de emergencia durante interrupciones. Una política correcta en enero puede ser errónea en junio. Si el cambio operativo llega a los routers pero no a ARTEMIS, el detector puede generar un falso positivo de alta gravedad. Si la política se amplía sin cuidado para reducir el ruido, una infracción real puede quedar autorizada sobre el papel.

El sistema convierte así una configuración técnica en un contrato institucional. La ingeniería de enrutamiento, las operaciones de seguridad y la gestión de cambios deben ponerse de acuerdo sobre qué significa el archivo, quién puede editarlo y con qué rapidez sigue a producción. El contexto local del proyecto no elimina los falsos positivos ni los falsos negativos; traslada su origen más importante a un lugar que el operador puede gobernar.

Una regla de seguridad del enrutamiento merece la misma disciplina que el software capaz de afectar al tráfico de clientes. Los cambios deben tener responsables identificados, revisión, historial de versiones, pruebas y una justificación vinculada a un cambio de red aprobado. El operador debería poder responder cuándo se añadió un prefijo, origen o vecino, quién lo autorizó y qué incidente o proyecto justificó la decisión. Un archivo de configuración sencillo puede respaldar ese proceso, pero solo si la organización lo trata como algo más que una tarea puntual de instalación.

Las pruebas deben incluir casos positivos y negativos. Una ruta legítima planificada debería pasar sin alerta. Un anuncio de prefijo exacto desde un origen no autorizado debería activar la clasificación esperada. Un suceso de subprefijo debería mostrar la gravedad correcta, y una infracción de no-exportación no debería confundirse con un secuestro de origen. La reproducción histórica puede respaldar estas comprobaciones, mientras que un entorno de preproducción puede verificar que las notificaciones y los envoltorios de mitigación reciban los datos previstos.

Esta disciplina también limita el peligro de la deriva organizativa. Cuando se marcha la persona que desplegó ARTEMIS por primera vez, la política debe seguir siendo comprensible para el siguiente operador. Un detector cuya lógica dependa de recuerdos no documentados no es una infraestructura fiable, aunque su código sea abierto y la latencia de sus fuentes sea baja.

FORTH y CAIDA convirtieron una pregunta de investigación en un flujo de trabajo para operadores

El proyecto surgió de la colaboración entre investigadores de la Foundation for Research and Technology-Hellas, dentro del ecosistema de la University of Crete, y CAIDA en la University of California San Diego. FORTH aportó trabajo sobre sistemas y seguridad del enrutamiento. CAIDA contribuyó con infraestructura de medición de Internet, experiencia en BGPStream y relaciones que ayudaron a trasladar el diseño a redes académicas y de investigación. Por tanto, el proyecto nunca fue solo un algoritmo de detección: combinó conocimiento de protocolos, sistemas de medición y acceso a operadores.

La financiación siguió el mismo patrón institucional mixto. En el historial del proyecto aparecen programas de investigación europeos y estadounidenses, apoyo del RIPE NCC Community Projects Fund, un proyecto de despliegue NSF EAGER, el US Department of Homeland Security y el Comcast Innovation Fund. El apoyo de RIPE en 2017 ayudó a convertir el prototipo en una herramienta orientada a operadores, mientras que una ayuda de 50.000 euros en 2019 financió trabajos de verificación del plano de datos mediante RIPE Atlas.

Esas subvenciones muestran cómo la investigación de interés público se convirtió en software desplegable, pero no revelan el coste actual de mantener instalaciones de producción.

La historia institucional importa para la atribución. ARTEMIS no es una fundación constituida de forma independiente, un servicio de CAIDA ni un detector global propiedad de FORTH. Es software de código abierto bajo la licencia BSD de 3 cláusulas, con una trayectoria investigadora y un mantenedor comercial actual. La evolución del proyecto se entiende mejor como una sucesión de colaboraciones que como propiedad de una sola organización.

El primer hito público fue una demostración en ACM SIGCOMM en 2016. En esa etapa, el paso importante consistió en conectar supervisión y mitigación en un solo ciclo. Muchos sistemas pueden identificar una ruta sospechosa después de recopilar suficiente evidencia. ARTEMIS planteó si un operador podía detectar el suceso con suficiente rapidez y disponer ya de una contramedida práctica, para evitar que el incidente pasara horas entre paneles, correos electrónicos y sesiones manuales con routers.

Una demostración no es un despliegue de producción maduro. Establece que los componentes pueden funcionar juntos con una configuración definida y que el problema de investigación es lo bastante concreto como para demostrarse. Aun así, el trabajo de 2016 marcó la dirección de todo lo posterior: observaciones en directo, una visión interna del enrutamiento legítimo, clasificación y un anuncio preparado. Esa secuencia convirtió el tiempo de respuesta, antes una consideración organizativa secundaria, en una propiedad del sistema.

El diseño se apoyó en evidencia de operadores según la cual responder a un secuestro podía llevar horas. El retraso no procedía solo de colectores lentos. Los equipos tenían que confirmar la titularidad, examinar la propagación, decidir si el suceso estaba planificado, localizar los contactos correctos de los proveedores y construir una mitigación segura. ARTEMIS podía reducir varios de esos pasos manteniendo la política y los flujos de trabajo cerca del sistema de supervisión, pero las relaciones humanas y comerciales alrededor de la ruta seguían fuera del código.

El artículo de 2018 en IEEE/ACM Transactions on Networking formuló la afirmación más recordada de ARTEMIS: neutralizar un secuestro BGP en menos de un minuto. Los investigadores evaluaron el enfoque mediante experimentos reales e informaron de detección en segundos y mitigación dentro del minuto bajo las condiciones probadas. El resultado fue significativo porque mostró que una red víctima no tenía necesariamente que esperar a un servicio externo, una cadena telefónica y un contraanuncio preparado manualmente.

La frase resulta engañosa cuando se separa del experimento. El tiempo de detección depende de si el suceso llega a un monitor conectado, de la rapidez con que la fuente entrega la actualización, de cómo coinciden las reglas del detector y de si el sistema funciona correctamente. El tiempo de mitigación depende de la longitud del prefijo de la víctima, su autoridad de enrutamiento, los filtros de proveedores, la propagación y el proceso de aprobación elegido. Una red que exija confirmación humana puede tomar una decisión más segura y tardar más. Una red que automatice de inmediato puede responder antes y asumir más riesgo.

La conclusión responsable tiene límites. ARTEMIS demostró que un sistema del lado del operador estrechamente integrado puede comprimir un proceso que a menudo tardaba mucho más. No demostró que todos los secuestros sean visibles, que todas las rutas de respuesta sean aceptadas ni que todos los equipos de producción deban permitir la desagregación autónoma. El resultado debe leerse como un objetivo de diseño respaldado por un experimento, no como una garantía universal.

Varias vistas incompletas construyen un registro de incidente utilizable

ARTEMIS puede recurrir a varias fuentes públicas porque ningún colector ve todas las rutas. RIPE RIS y el proyecto RouteViews de la University of Oregon reciben actualizaciones BGP de determinados pares en puntos de recopilación distribuidos. CAIDA BGPStream proporciona un marco para acceder a datos de enrutamiento de distintas fuentes y normalizarlos. Cada servicio amplía el campo de visión del operador, pero también refleja las redes que deciden emparejarse con sus colectores, la ubicación de esas sesiones y los tiempos de sus fuentes.

Esta visibilidad parcial tiene consecuencias prácticas. Un suceso puede propagarse a una región y no llegar nunca a los colectores usados por un despliegue. Un anuncio muy breve puede retirarse antes de que la fuente lo entregue. Una ruta puede afectar a los clientes de la víctima mediante una relación privada no representada en los datos públicos. Combinar colectores reduce algunos puntos ciegos, pero el resultado es una muestra mayor, no una copia omnisciente del plano de control global.

La pregunta operativa correcta no es, por tanto, «¿Vio ARTEMIS Internet?», sino «¿Qué observadores vieron este anuncio, con qué rapidez y qué parte del suceso puede quedar fuera de la muestra?». Esta formulación anima a los operadores a conservar la procedencia de cada alerta y a evitar que la ausencia en una fuente se interprete como prueba de que una ruta no existió.

RIPE NCC presentó en febrero de 2019 el prototipo público RIS Live para transmitir mensajes BGP con mucha menos demora que el procesamiento periódico de archivos. ARTEMIS se convirtió en uno de los ejemplos de por qué una fuente de este tipo importa. Un sistema de seguridad no puede responder en segundos si su principal observación llega muchos minutos después, y una transmisión en directo permite al detector evaluar las actualizaciones a medida que las reciben los colectores.

Una menor latencia no cambia lo que los colectores pueden observar. RIS Live sigue reflejando los pares conectados al RIPE Routing Information Service y las rutas que estos exportan. Si un secuestro permanece local, se filtra antes de llegar a un colector o afecta a una ruta oculta tras otra relación, es posible que la fuente nunca transporte la evidencia decisiva. La fiabilidad también importa: una interrupción de la transmisión o un cambio de formato puede parecer silencio si el servicio de supervisión no distingue entre «no hay rutas sospechosas» y «no hay datos».

Por eso, el estado de las fuentes forma parte del modelo de seguridad. El operador necesita saber si cada monitor está actualizado, retrasado, desconectado o genera un volumen inusual de actualizaciones. Un detector que presenta un único estado de confianza mientras sus entradas están degradadas puede crear una forma de ignorancia más peligrosa que una interrupción explícita.

La supervisión en tiempo real responde a lo que aparece ahora, mientras que las bases de información de enrutamiento y los archivos de actualizaciones proporcionan contexto. RIPE RIS y RouteViews publican datos históricos que pueden mostrar qué orígenes y rutas eran visibles antes de un incidente, cuándo comenzó un cambio y cuánto duró. CAIDA BGPStream facilita el procesamiento de esos registros mediante un marco común, lo que permite a ARTEMIS reproducir sucesos y probar reglas frente al comportamiento histórico del enrutamiento.

La reproducción resulta útil para la ingeniería y la revisión. Un equipo puede examinar si una política nueva habría detectado un suceso conocido, reproducir la secuencia que condujo a una alerta o formar a los responsables sin manipular una ruta de producción. La evidencia histórica también puede revelar anuncios recurrentes que parecen anómalos de forma aislada, pero representan una disposición de respaldo consolidada. La limitación es que un archivo conserva la vista de los colectores, no el suceso completo, y una topología pasada no puede reproducir todas las relaciones actuales.

Un despliegue maduro puede utilizar la reproducción como parte del control de cambios. Antes de que un nuevo origen, proveedor o regla de exportación entre en producción, el operador puede probar la referencia revisada frente a un historial representativo y confirmar que no convierte el enrutamiento ordinario en una alarma permanente. Esta práctica transforma la configuración del detector en un artefacto de seguridad auditable, en lugar de un archivo que solo se edita después de causar ruido.

Los datos públicos son solo una parte del diseño. ARTEMIS puede recibir actualizaciones locales mediante ExaBGP o sesiones privadas de BGP Monitoring Protocol. ExaBGP puede actuar como un altavoz BGP programable y enviar sucesos de rutas a otro software. BMP permite que los routers exporten información de enrutamiento a un sistema de supervisión sin convertirlo en parte de la decisión de reenvío. Estas fuentes pueden mostrar las adyacencias y el estado de rutas de la red protegida antes de que la información sea visible en un colector público.

Las fuentes locales mejoran la rapidez y el contexto, pero también introducen infraestructura sensible en la plataforma. Los datos BMP pueden ser voluminosos y revelar relaciones internas de enrutamiento. La integración con ExaBGP requiere un control cuidadoso porque la misma interfaz programable puede utilizarse tanto para anunciar rutas como para observarlas. Las credenciales, el alcance de red, la validación de mensajes y la separación entre supervisión y mitigación se convierten así en límites de seguridad.

Un despliegue bien diseñado utiliza las fuentes públicas y privadas con fines distintos. Los colectores públicos muestran cómo se propaga un anuncio más allá del entorno inmediato del operador. Las fuentes locales muestran lo que vieron directamente el operador y sus routers. Una discrepancia entre ambas no es necesariamente un error; puede ser la evidencia necesaria para entender dónde se detuvo la propagación o dónde surtió efecto una política.

La aplicación separa observación, detección y evidencia

La plataforma actual es una aplicación de microservicios con varios contenedores, no un único programa que lee una transmisión. Los servicios de supervisión se conectan a fuentes públicas y privadas, normalizan la información BGP entrante y publican sucesos. Los servicios de detección consumen esos sucesos y aplican las reglas del operador. El almacenamiento, las API, la interfaz web, las notificaciones y la supervisión rodean ese núcleo. La separación permite que los componentes escalen o fallen de forma independiente y facilita añadir una nueva fuente sin reescribir toda la aplicación.

La modularidad también multiplica las dependencias. Un monitor puede estar operativo mientras el detector está bloqueado. El bus de mensajes puede aceptar sucesos mientras la base de datos no está disponible. La interfaz web puede cargar un incidente antiguo mientras el flujo en directo está averiado. La orquestación de contenedores puede reiniciar un servicio y ocultar un fallo recurrente. Por ello, las operaciones requieren comprobaciones de estado que describan todo el recorrido desde la fuente hasta la alerta, en lugar de indicar únicamente que cada contenedor está en ejecución.

Docker Compose reduce la barrera para un despliegue controlado, mientras que la compatibilidad con Kubernetes encaja en organizaciones que ya gestionan plataformas de contenedores. Ningún método convierte el sistema en un servicio global gestionado. La red que lo despliega sigue siendo responsable de la capacidad, las actualizaciones, los secretos, el almacenamiento, las copias de seguridad y el acceso durante incidentes.

Un bus de mensajes permite que los servicios de supervisión, detección y notificación intercambien sucesos sin que un proceso controle directamente a los demás. El diseño puede absorber ráfagas de actualizaciones y permitir que los consumidores trabajen a ritmos distintos. También plantea preguntas sobre orden, duplicación y contrapresión. Un incidente de enrutamiento puede implicar miles de actualizaciones, retiradas y cambios de ruta, por lo que el sistema debe conservar suficiente secuencia y procedencia para que un operador reconstruya lo ocurrido.

El almacenamiento persistente ofrece a ARTEMIS una ventaja frente a una alarma transitoria. Las actualizaciones, alertas, estados de configuración y decisiones sobre incidentes pueden conservarse para su revisión. La arquitectura del proyecto ha utilizado componentes relacionados con PostgreSQL, almacenamiento de estilo Timescale y el ecosistema de API de Hasura. Estas elecciones facilitan consultas e integraciones, pero también crean un repositorio sensible de evidencia operativa y de enrutamiento que exige límites de conservación, control de acceso y copias de seguridad fiables.

La auditabilidad no equivale a certeza. Un registro completo de lo que recibió el sistema puede demostrar cómo llegó ARTEMIS a una alerta. No puede demostrar que el sistema recibiera todas las rutas relevantes ni que las reglas del operador fueran correctas. Por tanto, la base de datos debería conservar la fuente y el nivel de confianza, no solo una etiqueta final de incidente.

La interfaz web presenta los incidentes, el estado del sistema y las observaciones de enrutamiento en un formato útil para un equipo de operaciones de red o seguridad. Las notificaciones pueden enviar alertas por correo electrónico, canal móvil o integración personalizada, mientras que los paneles de Grafana pueden mostrar el estado de los servicios y las tendencias de sucesos. Estas funciones convierten un mecanismo de investigación en un producto operativo, porque el equipo de respuesta necesita prioridades, historial y una visión común, no actualizaciones BGP sin procesar.

La interfaz también puede generar una falsa confianza. Una tarjeta roja de incidente es una clasificación basada en observaciones y reglas, no una constatación independiente de intención maliciosa. Un mapa o una vista de rutas puede parecer completo aunque solo represente determinados colectores. Las notificaciones pueden convertirse en ruido cuando los cambios planificados no se reflejan en la política, y la fatiga de alertas puede provocar que se ignore el único suceso importante.

Una buena práctica operativa mantiene la interfaz conectada con la verificación. El responsable debería poder inspeccionar las actualizaciones originales, comparar fuentes públicas y locales, comprobar el estado actual de RPKI, realizar pruebas del plano de datos y registrar por qué el incidente se elevó, ignoró o resolvió. El panel es útil cuando acorta ese recorrido, no cuando lo sustituye.

Un patrón de rutas no puede demostrar el motivo ni el impacto

La investigación de ARTEMIS desarrolló una taxonomía que distingue los sucesos por la relación entre prefijos, la manipulación de la ruta AS, la política y el posible efecto sobre el plano de datos. La implementación admite un subconjunto definido de esos patrones a partir de evidencia del plano de control, incluidos casos de origen con prefijo exacto y subprefijo, ocupación de espacio y determinadas infracciones de exportación. Una taxonomía ofrece a los operadores un lenguaje coherente y ayuda al detector a aplicar reglas diferentes a distintos sucesos.

Las categorías deben permanecer vinculadas a lo que muestran los datos. Una ruta que comienza con un vecino inesperado puede indicar un segmento fabricado, una fuga de rutas o un cambio autorizado no registrado en la política. Un origen no autorizado puede ser un error y no un ataque. Incluso un anuncio deliberado puede estar diseñado para descartar tráfico, suplantar un servicio u observar tráfico en tránsito, y las actualizaciones BGP por sí solas no permiten distinguir esos resultados.

Un lenguaje cuidadoso protege tanto la precisión como la calidad de la respuesta. «Posible secuestro» o «infracción de política» suele ser más prudente en la fase de alerta que «ataque». El término más contundente puede utilizarse cuando la titularidad de la ruta, los contactos con operadores y la evidencia del plano de datos lo respalden. Esa cautela no debilita la seguridad; evita que el sistema de incidentes convierta la incertidumbre en una afirmación que otros equipos pueden repetir como un hecho.

Los mensajes BGP describen afirmaciones de alcance e información de rutas intercambiadas entre redes. No muestran todos los paquetes que siguen la ruta seleccionada. Tras un anuncio sospechoso, el tráfico podría quedar descartado, ser interceptado y reenviado, recibir respuesta de un servicio suplantado o no verse afectado porque la ruta no se propagó hasta las redes que transportaban a los usuarios relevantes. Distintas partes de Internet pueden experimentar resultados diferentes al mismo tiempo.

Este límite es fundamental para ARTEMIS. El detector puede mostrar que una ruta infringió la política del operador y apareció en puntos de observación identificados. No puede inferir el motivo a partir de la ruta AS ni garantizar que un traceroute siga la misma dirección que el tráfico de la aplicación. El cifrado, el comportamiento del DNS, las cachés, anycast y la conmutación por error de aplicaciones pueden alterar aún más lo que experimentan los usuarios. La alerta del plano de control es, por tanto, evidencia para un incidente, no el incidente completo.

Una respuesta útil reúne varios registros. La evidencia BGP demuestra el anuncio y su propagación. Las pruebas del plano de datos examinan el alcance y las rutas desde ubicaciones seleccionadas. La telemetría del servicio muestra errores, latencia e impacto sobre los clientes. Los contactos con proveedores determinan si la ruta estaba autorizada o era un error. Ninguno de esos registros es perfecto, pero juntos respaldan una decisión que una sola fuente no puede proporcionar.

La ayuda del RIPE Community Projects Fund de 2019 financió una ampliación de ARTEMIS que utilizaba mediciones traceroute de RIPE Atlas para examinar el efecto de los sucesos detectados. Este trabajo reconoció una limitación del ciclo original del plano de control. Una ruta puede parecer peligrosa en BGP y tener poco impacto observable, mientras que una propagación pequeña puede afectar a una población valiosa de clientes. Las sondas del plano de datos aportan evidencia sobre hacia dónde parece dirigirse el tráfico y si los extremos siguen siendo accesibles.

RIPE Atlas dispone de una red distribuida de sondas, pero su ubicación es desigual, y el destino elegido puede no responder de una manera que revele la ruta. Traceroute puede verse afectado por filtros, balanceo de carga, túneles y enrutamiento asimétrico. La ruta de ida desde una sonda hasta el destino no tiene por qué coincidir con la que sigue el tráfico de clientes en dirección opuesta. Una medición fallida puede indicar una interrupción, un salto que no responde o una limitación específica de la prueba.

La ganancia práctica no es la certeza, sino una mejor priorización. Si los colectores BGP muestran un subprefijo no autorizado y las sondas de varias regiones pierden alcance o cambian hacia el origen inesperado, el operador dispone de evidencia más sólida para elevar el incidente. Si el suceso del plano de control solo es visible en un colector y las pruebas del plano de datos permanecen estables, el equipo puede investigar antes de cambiar anuncios globales. La decisión sigue dependiendo del contexto, pero es menos ciega.

La desagregación solo puede recuperar tráfico cuando el sistema de enrutamiento lo permite

La respuesta más conocida de ARTEMIS es la desagregación. Una víctima que anuncia un prefijo amplio puede originar rutas más específicas para que la selección normal por prefijo más largo atraiga de nuevo el tráfico hacia la red legítima. El método utiliza el comportamiento existente de BGP y puede propagarse con rapidez, lo que lo hizo adecuado para el objetivo experimental de «menos de un minuto». También mantiene la autoridad en manos de la víctima, sin exigir que el origen inesperado coopere antes de que el servicio empiece a recuperarse.

La desagregación tiene límites estrictos. Muchas redes filtran rutas IPv4 más largas que /24 y rutas IPv6 más largas que /48 para contener el crecimiento de las tablas y los abusos operativos. Una víctima que ya anuncie un /24 o /48 puede ser incapaz de producir una ruta más específica que acepte el conjunto de Internet. Los proveedores también pueden restringir lo que un cliente puede anunciar, y quizá sea necesario que los objetos de ruta, filtros de prefijos o datos RPKI permitan la mitigación. La propagación no es instantánea ni uniforme, por lo que las rutas antiguas y nuevas pueden coexistir.

Un operador preparado debería conocer estos límites antes del incidente. ¿Qué prefijos pueden desagregarse? ¿Qué proveedores los aceptarán? ¿Qué filtros de ruta y autorizaciones de origen de rutas cubren ya el estado de emergencia? ¿Cómo se retirarán las rutas tras la recuperación? ARTEMIS puede activar un envoltorio, pero su éxito depende de acuerdos situados fuera de la aplicación.

El material del proyecto habla de mitigación automática, y la investigación incluye un ciclo cerrado en el que la detección puede activar un contraanuncio. Las descripciones operativas detalladas también muestran confirmación manual y envoltorios personalizados. Ambas cosas pueden ser ciertas porque cada despliegue elige un nivel distinto de autonomía. La formulación prudente es que ARTEMIS admite mitigación automatizada o autorizada por el operador mediante flujos de trabajo configurables.

El riesgo es asimétrico. Una respuesta retrasada puede prolongar una interrupción o interceptación. Una respuesta automática equivocada puede anunciar rutas más específicas innecesarias, infringir una política de proveedor, filtrar supuestos internos o crear inestabilidad mientras todavía se investiga el suceso original. Una regla obsoleta de referencia puede convertir un cambio de ruta planificado en una aparente emergencia. Si el envoltorio tiene credenciales amplias para routers, una vulneración de ARTEMIS puede convertirse por sí misma en un ataque de enrutamiento.

La automatización más segura se desarrolla por etapas. El sistema puede primero enriquecer la alerta, comprobar varias fuentes, verificar el estado de RPKI, ejecutar pruebas del plano de datos y preparar el cambio de ruta exacto. Una persona puede aprobar las acciones de gran impacto, mientras que los casos de menor riesgo pueden usar automatización basada en políticas. Los límites de frecuencia, las credenciales acotadas, la simulación, los registros de cambios y una reversión probada importan más que la etiqueta «automático».

No se trata de conservar trabajo manual por sí mismo, sino de garantizar que la rapidez no elimine la rendición de cuentas.

RPKI refuerza una parte de la cadena de evidencia

La Resource Public Key Infrastructure permite que los titulares de direcciones creen autorizaciones de origen de rutas que indican qué sistemas autónomos pueden originar determinados prefijos y longitudes máximas. Los routers o sistemas de políticas pueden realizar la validación del origen de rutas y clasificar una ruta como válida, no válida o no encontrada. Esto añade evidencia criptográfica a una parte de BGP que, de otro modo, depende de la confianza distribuida. Es un control preventivo porque otras redes pueden rechazar o reducir la preferencia de un origen no autorizado antes de que el tráfico lo siga.

ARTEMIS opera en otra capa del incidente. Puede utilizar el estado de validación RPKI como evidencia, pero también compara las rutas con reglas privadas del operador, registra el suceso, combina fuentes públicas y locales y conecta la detección con la respuesta. RPKI no valida toda la ruta AS, y las políticas de despliegue no son universales. Una ruta puede ser válida según RPKI y aun así infringir una relación vecinal prevista o filtrarse por una ruta no deseada por el operador. Una ruta puede ser no válida porque un cambio operativo legítimo no se reflejó en la ROA.

Por tanto, los sistemas son complementarios. RPKI puede reducir el número de rutas con origen no autorizado que acepta el conjunto de Internet. ARTEMIS puede mostrar a la víctima lo que se está observando, detectar determinados patrones más allá de la simple validez del origen y organizar la respuesta. Futuros mecanismos de autorización de rutas, como ASPA, pueden reforzar la evidencia sobre relaciones, pero no eliminarán la necesidad de supervisar qué anuncian realmente las redes y cómo afectan los incidentes a los servicios.

Los proyectos piloto llevaron ARTEMIS más allá del laboratorio sin demostrar una escala de mercado

CAIDA informó de un despliegue experimental de ARTEMIS financiado por NSF con Internet2, Great Plains Network y Merit durante 2018 y 2019. Estos proyectos piloto fueron importantes porque las redes académicas y de investigación tienen prefijos, proveedores, procesos de cambio y obligaciones de servicio reales. Los operadores pudieron probar si el software encajaba con la supervisión existente, si las reglas recogían su intención de enrutamiento y cómo entrarían las alertas en la respuesta a incidentes.

El registro es creíble, pero limitado. Un proyecto piloto puede demostrar instalación, comentarios de ingeniería y determinados usos operativos. No demuestra una cobertura continua en producción, el estado actual de las versiones ni el rendimiento en todos los tipos de red. El sitio web del proyecto también publica declaraciones de ingenieros asociados con AMS-IX, Internet2 y ESnet y muestra logotipos de organizaciones. Esas referencias indican pruebas o uso, pero no deben convertirse en la afirmación de que todas las organizaciones nombradas son actualmente clientes de pago o de que el proyecto tiene una cuota global conocida.

Esta distinción importa porque el software de seguridad del enrutamiento suele tener despliegues invisibles. Un operador puede ejecutar una bifurcación interna, utilizar la supervisión sin mitigación o abandonar el sistema después de una prueba. La ausencia de un censo completo no vuelve irrelevante al proyecto, pero impide afirmar con precisión su adopción. Los casos identificados son evidencia más sólida que una cifra elevada sin respaldo.

El control del operador conlleva una carga de integración y cadena de suministro de software

ARTEMIS se distribuye bajo la licencia BSD de 3 cláusulas. Un operador puede inspeccionar el código, ejecutarlo en infraestructura controlada, adaptar integraciones y evitar enviar políticas sensibles a un único proveedor central obligatorio. Este modelo encaja con la ventaja principal del proyecto, porque la referencia más valiosa pertenece al interior de la red. También permite el uso comercial y las bifurcaciones, de modo que Code BGP y otras partes pueden crear servicios sobre la base abierta.

El control implica trabajo. La plataforma incluye contenedores, un bus de mensajes, bases de datos, API, una aplicación web, sistemas de notificación e integraciones de fuentes. Cada componente necesita parches, credenciales, segmentación de red, copias de seguridad y supervisión. El sistema almacena políticas sensibles de enrutamiento y puede contener credenciales capaces de influir en los anuncios. Por ello, un despliegue de producción tiene una superficie de seguridad mucho mayor que el algoritmo original de detección.

La licencia abierta ofrece al operador una vía de salida respecto a un mantenedor, no una organización de soporte automática. Alguien debe seguir probando actualizaciones, revisando dependencias y entendiendo el código cuando cambia una fuente o interfaz de router. Para redes más pequeñas, una herramienta de alertas más sencilla o un servicio comercial gestionado puede ser más fácil de operar, aunque ofrezca menos control local.

Un servicio ARTEMIS de producción debe mantenerse disponible durante la misma inestabilidad de red que hace que los operadores lo necesiten. Las conexiones de fuentes, el bus de mensajes, la base de datos, la API, la interfaz, el canal de notificaciones y la capa de autenticación forman una única cadena de servicio. La redundancia en los contenedores solo ayuda cuando el estado, el almacenamiento y las dependencias externas también están diseñados para fallar. Un monitor reiniciado no puede recuperar actualizaciones que nunca se conservaron, y una interfaz replicada no puede mostrar un incidente que el sistema de detección no procesó.

El diseño operativo debería incluir modos degradados explícitos. Cuando desaparece una fuente pública, el sistema debe indicar que la cobertura se ha reducido, en lugar de seguir mostrando un estado saludable sin matices. Cuando la base de datos no está disponible, el detector quizá deba conservar sucesos localmente o detener la mitigación porque no puede escribir evidencia de auditoría. Cuando falla el proveedor de identidad, debe ser posible el acceso de emergencia sin dejar una cuenta permanente sin control.

Estas decisiones no aparecen en la taxonomía de secuestros, pero determinan si la idea investigadora se convierte en infraestructura fiable.

La plataforma también necesita su propio presupuesto de rendimiento. Una ráfaga de actualizaciones legítimas durante un gran cambio de enrutamiento puede someter a los monitores y al almacenamiento a más presión que un único secuestro. Las colas internas no deberían transformar una fuente casi en tiempo real en un incidente retrasado sin hacer visible la demora.

Las pruebas de capacidad, la conservación de la base de datos y la contrapresión del bus de mensajes forman parte de la planificación del despliegue por la misma razón que los filtros de rutas y las longitudes de prefijo: delimitan la respuesta que el sistema puede prometer con honestidad.

ARTEMIS reúne software web, imágenes de contenedores, una base de datos, componentes de mensajería, API, autenticación y bibliotecas de red. La arquitectura hace extensible el proyecto, pero cada dependencia es una posible vulnerabilidad o punto de fallo. Un defecto en la interfaz puede exponer políticas de enrutamiento. Una imagen comprometida puede alterar las alertas. Un token de API demasiado permisivo puede revelar incidentes, mientras que una credencial asociada a un envoltorio de mitigación puede permitir cambios de rutas. La seguridad del detector es inseparable de la seguridad del software utilizado para operarlo.

El código abierto ayuda porque los operadores pueden inspeccionar componentes, fijar versiones y construir sus propias imágenes. No garantiza que alguien haya revisado todas las dependencias transitivas ni que una vulnerabilidad pública vaya a corregirse dentro del plazo que necesita una red. Un equipo de producción requiere un inventario de imágenes y bibliotecas, un proceso para reconstruirlas, separación entre la supervisión de solo lectura y la mitigación con capacidad de escritura, y un método para probar actualizaciones de seguridad sin perder el historial de incidentes.

Este requisito cambia el modo de juzgar el mantenimiento del proyecto. Una nueva función de detección puede atraer más atención que una actualización de la base de datos o una corrección de autenticación, aunque estas últimas sean más importantes para la integridad del servicio. Los avisos de seguridad, las compilaciones reproducibles, las actualizaciones de dependencias y una rama de versiones con soporte son evidencia de madurez operativa incluso cuando no añaden ninguna opción visible al panel.

Las publicaciones y Code BGP definen la prueba de mantenimiento actual

La publicación formal etiquetada más reciente identificada en el conjunto de investigación es la versión 2.3.0, denominada Cadmus y fechada el 24 de noviembre de 2022. La demostración en directo, en la fecha límite del 5 de agosto de 2026, mostraba una compilación posterior basada en una confirmación de código, y el sitio web actual del proyecto seguía activo. Estos hechos respaldan la conclusión de que el trabajo continuó después de la última publicación formal, pero también plantean una pregunta legítima para producción: ¿qué versión está probada, recibe soporte y es adecuada para actualizar?

La actividad de desarrollo y una demostración funcional muestran continuidad. Una publicación semántica ofrece otra forma de garantía: una referencia con nombre, notas de publicación, expectativas sobre dependencias y un punto frente al cual los operadores pueden realizar pruebas. Un proyecto puede estar activo aunque su proceso formal de publicaciones vaya retrasado, y una demostración actual puede ejecutar código que ningún operador de producción debería adoptar sin revisión.

En infraestructura de seguridad del enrutamiento, la disciplina de publicaciones forma parte del modelo de seguridad. Los operadores necesitan saber qué ramas reciben correcciones, cómo se gestionan las migraciones y si las dependencias antiguas siguen expuestas. Una nueva etiqueta no demostraría fiabilidad universal, pero una política pública de soporte y seguridad reduciría más la incertidumbre que un sitio web actualizado por sí solo.

El sitio web del proyecto identifica a Code BGP como mantenedor actual de ARTEMIS y describe la empresa como una startup surgida del proyecto. La comercialización puede resolver un problema real del código abierto. El software de seguridad del enrutamiento necesita personas que mantengan integraciones, respondan a vulnerabilidades, apoyen los despliegues y conviertan las funciones de investigación en operaciones fiables una vez terminadas las subvenciones originales.

Sin embargo, Code BGP es una empresa comercial independiente con un contexto más amplio de productos y clientes. No debe utilizarse como alias de FORTH, CAIDA ni de todos los despliegues de código abierto. La evidencia pública disponible no revela los ingresos, la valoración o la lista de clientes de la empresa, ni el límite exacto entre las funciones comunitarias y las comerciales. Esa ausencia no es una crítica, sino un límite a lo que puede afirmar un perfil.

La relación crea dos incentivos que pueden coincidir o divergir. El proyecto abierto se beneficia cuando el personal comercial aporta código probado y documentación. La empresa se beneficia cuando el proyecto abierto genera confianza, adopción y una base técnica para servicios de pago. La prueba a largo plazo consiste en saber si las publicaciones, las correcciones de seguridad y las decisiones sobre la hoja de ruta siguen siendo suficientemente visibles para los operadores que no son clientes comerciales.

Una licencia permisiva garantiza que el código fuente pueda copiarse, modificarse y comercializarse. No garantiza que otro equipo pueda comprender la arquitectura, reproducir una publicación o asumir el mantenimiento cuando se marchen los expertos actuales. La continuidad a largo plazo depende de documentación, pruebas, historial de incidencias, conocimiento de las dependencias y una vía de contribución que se extienda más allá de quienes construyeron el sistema de investigación original.

La gestión de Code BGP puede reforzar esa continuidad manteniendo a ingenieros experimentados vinculados a la plataforma. También puede concentrar el conocimiento práctico dentro de una organización comercial aunque el repositorio siga siendo público. La diferencia puede observarse mediante las notas de publicación, el debate público sobre diseño, la respuesta a los informes de la comunidad y la posibilidad de que los despliegues de quienes no son clientes obtengan información suficiente para operar con seguridad.

El objetivo no es impedir el valor comercial. Una relación saludable de núcleo abierto puede alinear el soporte de pago con el mantenimiento público. El riesgo aparece cuando el proyecto abierto se convierte en una demostración histórica mientras el camino operativo se traslada a componentes privados no documentados. Por tanto, la portabilidad debe probarse en la práctica: ¿puede un operador independiente instalar, actualizar, auditar y recuperar el sistema mediante la información pública disponible en ese momento?

ARTEMIS ocupa un exigente punto intermedio en la seguridad del enrutamiento

El ámbito de la seguridad del enrutamiento incluye colectores públicos, sistemas de inferencia académicos, herramientas abiertas de alertas, validadores RPKI y plataformas comerciales de supervisión. RIPE RIS, RouteViews y BGPStream proporcionan datos, no un flujo de incidentes específico del operador. BGPalerter ofrece otro modelo abierto de supervisión. MANRS establece normas operativas, pero no detecta sucesos en directo. Los servicios comerciales pueden aportar supervisión amplia y apoyo de analistas, aunque pueden carecer de contexto local privado si el cliente no lo integra.

La posición distintiva de ARTEMIS es la combinación de control del operador, referencia explícita, varias fuentes públicas y locales, código abierto y mitigación opcional. Esa posición también es exigente. Una red debe disponer de experiencia en enrutamiento, mantener políticas y operar una plataforma con varios servicios. Por ello, el proyecto puede ser más adecuado para organizaciones que consideran la seguridad del enrutamiento una capacidad esencial y no una suscripción a un panel.

La comparación no debería reducirse a una tabla de funciones. Los diferentes modelos sitúan la confianza y el trabajo en lugares distintos. Un servicio gestionado centraliza la experiencia y la observación. Un sistema gestionado por el operador mantiene la política y la acción más cerca de la red. La pregunta relevante es qué parte puede ver lo suficiente, actuar de forma segura y seguir rindiendo cuentas cuando la evidencia está incompleta.

ARTEMIS Lite apareció en materiales de la comunidad RIPE en 2023 como un enfoque relacionado y más ligero, destinado a reducir parte de la carga del despliegue. La existencia de una variante Lite demuestra que la amplitud de la plataforma completa puede resultar difícil para equipos pequeños. Una arquitectura de varios contenedores con almacenamiento persistente, múltiples fuentes y mitigación personalizada puede ser apropiada para un gran operador y excesiva para una red que primero necesita visibilidad clara y alertas fiables.

Un sistema más ligero no debería describirse como equivalente solo porque comparte el nombre y el propósito. El conjunto de investigación caracteriza ARTEMIS Lite como una solución con funcionalidad reducida, y las afirmaciones de las presentaciones requieren confirmación independiente. La disyuntiva relevante se encuentra entre un menor coste operativo y el contexto, las integraciones, el historial o los mecanismos de respuesta que pueden faltar. Un despliegue más pequeño puede seguir siendo valioso si define esos límites con honestidad.

La adopción depende de la cantidad de mecanismos institucionales que exige la herramienta. Un proyecto puede ser técnicamente abierto y seguir siendo inaccesible para operadores sin especialistas en contenedores, bases de datos y seguridad del enrutamiento. El empaquetado, unos valores predeterminados razonables y una vía gradual desde la supervisión hasta la detección y la mitigación pueden determinar si la arquitectura se extiende más allá de otro artículo de investigación.

El producto real es un ciclo de retroalimentación gobernado

ARTEMIS no hace que BGP sea fiable de una sola vez. Crea un ciclo alrededor de un protocolo construido sin autorización completa. El operador declara el enrutamiento previsto. Las fuentes públicas y locales muestran parte del enrutamiento observado. El detector identifica la divergencia. El almacenamiento y las interfaces organizan la evidencia. Las personas o la automatización aprobada eligen una respuesta, y las fuentes muestran después si cambia la propagación. El incidente puede resolverse, ignorarse, retirarse, elevarse o quedar inactivo con un motivo registrado.

Ese ciclo es la contribución más duradera del proyecto. Reconoce que la seguridad del enrutamiento no es un certificado puntual ni una alarma distante. Es una práctica operativa en la que la política debe ser explícita, las observaciones deben conservar su procedencia y la autoridad de respuesta debe prepararse antes de una emergencia. El valor del sistema reside en reducir la incertidumbre con rapidez suficiente para que la red actúe, no en fingir que la incertidumbre ha desaparecido.

Los límites son igualmente instructivos. Los colectores de rutas son parciales. La referencia puede estar obsoleta. La evidencia del plano de control no demuestra el motivo ni todos los resultados sobre el tráfico. Una mitigación técnicamente válida puede ser filtrada o perjudicial. El código abierto sigue necesitando mantenimiento sostenido. ARTEMIS es más sólido cuando esos límites se integran en el flujo de trabajo en lugar de ocultarse tras el titular de una respuesta en un minuto.

Una anomalía BGP puede llegar a un centro de operaciones de red, a un centro de operaciones de seguridad o a ambos. El equipo de enrutamiento entiende los prefijos, las políticas de proveedores y los riesgos de cambiar anuncios. El equipo de seguridad puede estar mejor preparado para correlacionar identidades, telemetría de servicios y posibles actividades maliciosas. ARTEMIS cruza esos ámbitos, lo que solo resulta útil si la alerta lleva evidencia suficiente para que cada equipo trabaje a partir del mismo suceso, en vez de abrir investigaciones separadas con supuestos diferentes.

El traspaso debe distinguir entre observación, política e impacto. El sistema observó una ruta en fuentes identificadas. La ruta infringió una regla específica de referencia. Las comprobaciones del servicio o las sondas de RIPE Atlas mostraron un efecto definido, o todavía no se ha establecido ningún efecto. El operador contactó con un proveedor o con el origen de la ruta, y la respuesta sigue pendiente.

Esta estructura evita que el centro de operaciones de red descarte una preocupación de seguridad como enrutamiento ordinario y que el centro de operaciones de seguridad califique de ataque un anuncio no autorizado antes de conocer los hechos operativos.

Un lenguaje compartido también mejora el aprendizaje posterior al incidente. Un caso puede cerrarse como cambio planificado omitido en la política, fuga accidental de rutas, posible secuestro, suceso malicioso confirmado o anomalía sin resolver. Esos resultados deben incorporarse a las reglas, los procedimientos y los acuerdos con proveedores. Sin ese ciclo, el detector puede convertirse en una máquina de generar incidencias en lugar de un sistema para mejorar el control del enrutamiento.

La alerta más rápida no siempre es la más útil. Un detector puede activarse ante la primera actualización inesperada y dejar que el responsable descubra después que la fuente está obsoleta, que la ruta estaba planificada o que la supuesta víctima autorizó un nuevo origen. Por el contrario, esperar a todos los colectores y todas las pruebas del plano de datos puede sacrificar la ventaja de una respuesta temprana. ARTEMIS necesita una medida situada entre la latencia bruta de detección y el cierre final del incidente: el tiempo necesario para reunir suficiente evidencia fiable para que el operador autorizado tome una decisión defendible.

Esta medida puede descomponerse. ¿Con qué rapidez llegó la primera observación? ¿Cuántas fuentes independientes la confirmaron? ¿Estaba actualizada la política correspondiente? ¿Aportaron evidencia RPKI o el BMP local? ¿Cuánto tardaron las comprobaciones del servicio? ¿Cuándo recibió la alerta la persona responsable y cuándo se aprobó una respuesta? ¿Consiguió la mitigación la propagación prevista y se retiró limpiamente? Estas preguntas muestran dónde reside realmente el retraso, en lugar de atribuir todo el resultado al algoritmo de detección.

Una métrica de decisión creíble también desalienta una optimización peligrosa. No debe premiarse al sistema por actuar más rápido si lo hace con menos evidencia o crea cambios de enrutamiento innecesarios. El mejor despliegue es aquel que reduce al mismo tiempo la incertidumbre y el tiempo de respuesta, conservando un registro que pueda revisarse después del incidente.