El culpable de alerta de misiles de Hawái: nombres de archivo mal elegidos

El sábado por la mañana, 13 de enero de 2018 a las 8:09 a.m., hora de Hawái, un miembro del personal de la oficina del Punto de Advertencia Estatal de la Agencia de Manejo de Emergencias de Hawái (HIEMA) estaba revisando su lista de verificación de cambio de turno de rutina. Revisaron la misma lista de verificación cada vez que comenzaron su turno. Fue de rutina. No fue interesante.

En un momento, abrieron su software de alerta IPAWS, recuperaron una lista de "plantillas" guardadas y eligieron una de una lista de 9. Lo que eligieron se llamaba PACOM (CDW) - SOLO ESTADO.

Solo que este no era el archivo de plantilla que querían abrir. La plantilla que querían abrir se llamaba DRILL - PACOM (CDW) - STATE ONLY. Aparte de la palabra TALADRO en el nombre del archivo, los dos archivos eran casi idénticos. Digo casi, porque había otra diferencia: la versión de exploración envió un mensaje solo a los dispositivos de prueba, mientras que la versión sin exploración envió exactamente el mismo mensaje a todos los teléfonos móviles en Hawai.

El mensaje fue siniestro. AMENAZA MISILERA BALÍSTICA ENTRADA A HAWAII. BUSQUE REFUGIO INMEDIATO. ESTO NO ES UN TALADRO.

El mensaje que apareció en cada teléfono celular en Hawai.

El miembro del personal del Punto de Advertencia del Estado no se dio cuenta de inmediato de que había elegido el archivo incorrecto. Nada en el sistema les diría que sí. Los clics y las confirmaciones fueron exactamente iguales para cualquier archivo. No se darían cuenta de su error hasta unos momentos después, cuando su teléfono personal sonó con la alerta, al igual que todos los demás en el Centro de Operaciones de Emergencia del Punto de Advertencia del Estado. Ups

Enviar un mensaje a millones de teléfonos sobre un misil balístico entrante debería, uno pensaría, tener un mensaje de confirmación. Lo hizo. Pero también lo hizo el mensaje de prueba. También requirió que el usuario ingrese una contraseña especial para asegurarse de que tenía la intención de enviar el mensaje a cada destinatario, pero también lo hizo el mensaje de prueba.

El quid del error fue elegir el archivo incorrecto, de una lista que se parecía a esto:

Esta lista, suministrada por HIEMA, son las plantillas para mensajes.

No es difícil ver cómo se eligió el archivo incorrecto. Estos parecen estar enumerados en orden cronológico, los más nuevos al último. (El primer archivo BMD False Alarm se agregó justo después de que se emitió la alerta falsa y el Gobernador emitió una declaración. Contiene el mensaje utilizado para decirles a todos que el mensaje NO UN TALADRO fue un TALADRO)

Hay una lista de plantillas alternativas flotando: (Parece que el estado no está seguro de qué Punto de advertencia de estado usa).

En cualquier caso, verá claramente que el nombre del archivo DRILL es casi idéntico al nombre real del archivo. (CDW es Advertencia de Defensa Civil). Esta lista es alfabética, que no es mucho mejor que la fecha ordenada.

Planificación para que ocurra este error

Este no era un menú cuidadosamente diseñado, como tampoco lo es cualquier colección aleatoria de objetos con nombre de usuario. Sin embargo, para llegar aquí, tuvo que ocurrir mucha planificación cuidadosa.

El sistema utilizado para enviar las alertas se llama IPAWS, el Sistema Integrado de Alerta y Advertencia Pública, administrado por la Agencia Federal para el Manejo de Emergencias (FEMA) del gobierno de los EE. UU. En asociación con la Comisión Federal de Comunicaciones (FCC). La parte del teléfono celular de IPAWS se conoce como sistema de alerta de emergencia inalámbrica (WEA).

Los estados y condados pueden obtener acceso al sistema IPAWS para publicar avisos de emergencia, desde cierres de carreteras hasta alertas AMBER (alertas de secuestro de niños).

Hawaii ha tenido su sistema en funcionamiento por un tiempo, que utilizaron para problemas relacionados con el clima, como deslizamientos de tierra que cierran carreteras y advertencias de tsunami. En noviembre, HIEMA, preocupado por las crecientes tensiones con Corea del Norte, presentó un nuevo plan de preparación para emergencias, que incluía mensajes de WEA en caso de lanzamiento de un misil balístico.

Aquí hay una diapositiva de la plataforma de diapositivas de preparación para emergencias de HIEMA, que indica su reacción al lanzamiento de un misil:

Aquí están los mensajes que HEIMA recomendó:

Puede ver que el mensaje que salió fue muy cercano a los mensajes recomendados en el plan de HIEMA. (WEA tiene un límite de 90 caracteres, por lo que se debe acortar el mensaje de 138 caracteres recomendado).

Supongo que, con estas nuevas pautas establecidas, el punto de advertencia estatal actualizó sus mensajes guardados, primero incluyendo el simulacro como una práctica habitual y luego agregando el mensaje real. (Parece que decidieron agregar una plantilla para las alertas de tsunami en el mismo punto, ya que se encuentran entre los dos mensajes de PACOM. PACOM representa el Comando del Pacífico de los Estados Unidos, la oficina de coordinación militar conjunta que monitorea la región del Pacífico).

FEMA enumera 23 proveedores aprobados de software de origen de alertas IPAWS. La mayoría de estos son aplicaciones de software como servicio o iOS. (Sí, alguien puede alertar a todo su estado desde su teléfono).

HIEMA no ha revelado qué proveedor están utilizando actualmente. (Me han dicho que ya se han presentado solicitudes de FOIA para obtener más información sobre los sistemas utilizados en Hawai y otros estados). Es poco probable que la implementación de HIEMA se haya personalizado de alguna manera. Se necesita bastante trabajo para obtener la certificación de FEMA. Deja ese trabajo a los vendedores.

Si visita los sitios web de los distintos proveedores aprobados, verá algunos sistemas bien diseñados. Aquí hay uno de una compañía llamada Alertsense:

Parece ser un sistema de diseño limpio. Sin embargo, tiene un predecesor y es posible que HIEMA esté usando algo que se parece más a esto:

Los gobiernos, que a menudo tratan de ahorrar dinero a sus contribuyentes, no pagan por las actualizaciones. Especialmente para sistemas que no están rotos. Con suerte, aprenderemos más pronto sobre el sistema específico que Hawaii está utilizando.

Es probable que este error haya sucedido antes

Mi reacción, al ver el sistema involucrado, fue ¿por qué no ha sucedido esto antes? Después de todo, elegir un archivo incorrecto es un error común. Si la forma de enviar un mensaje de IPAWS es seleccionando una plantilla predefinida, entonces es probable que alguien haya elegido la incorrecta en el pasado.

Sin embargo, no sería noticia. La mayoría de las alertas de IPAWS son para alertas AMBER y problemas climáticos locales. Si se envió un mensaje incorrecto, por ejemplo, para un camino cerrado por inundaciones, la mayoría de la gente no sabría que hay un problema. Si no estuvieran cerca de ese camino en particular, probablemente no prestarían atención al mensaje, incluso si fue un error.

Los mensajes de IPAWS suelen ser locales. Un mensaje estatal es raro. Eso es lo que hizo que este incidente fuera tan público.

El interés periodístico del incidente se amplificó debido a las recientes tensiones de nuestra nación con Corea del Norte. Parece que siempre estamos a solo un tweet de un genio muy estable, lejos de tener un misil lanzado en nuestra dirección. Si este accidente hubiera sucedido hace dos años, todos hubieran tenido una reacción diferente. (Sin embargo, no habría sucedido hace dos años porque no había necesidad de pensar en misiles balísticos entrantes en ese momento).

Los nombres de archivo son los culpables

¿Has conocido a alguien que cargó una versión anterior de un archivo, cuando pretendía usar el más reciente, y luego guardó accidentalmente los datos antiguos sobre los nuevos? Ese es, en esencia, el problema que vimos aquí.

Este es un problema clásico de experiencia de usuario que involucra convenciones de nombre de archivo. Los usuarios a menudo no eligen los nombres de archivo pensando que ¿cometeré un error en el futuro y elegiré el archivo incorrecto? Cometemos errores con nuestros archivos todo el tiempo, tomando la versión incorrecta cuando dos archivos tienen un nombre similar.

Si queremos preguntarnos cómo evitaríamos que esto vuelva a ocurrir, tenemos que ver cómo se almacenan los mensajes de IPAWS para su uso futuro. El sistema, tal como funciona hoy, depende de los usuarios para guardar las plantillas de mensajes con un nombre significativo. Si no lo logran. Si eligen un nombre que es bastante similar a otro, este error volverá a ocurrir.

No existe una convención de nomenclatura obligatoria del sistema, al igual que no hay convenciones de nomenclatura para ningún otro archivo en ningún otro sistema de archivos. Nuestros sistemas no fuerzan un régimen específico de nombres de archivos a los usuarios, para garantizar que cada nombre sea claro y distinto, por lo que evitarán la confusión de nombres en el futuro.

Una posible solución: deshacerse de los nombres de archivo

En muchos sentidos, los nombres de archivos son un anacronismo de antaño, cuando la lectura de datos era lenta y el espacio era costoso. Podríamos eliminarlos en muchos casos, y este es uno de ellos.

Para un mensaje IPAWS WEA, hay dos identificadores distintos que podríamos usar en lugar de un nombre de archivo: el mensaje en sí y a quién se lo transmitió. El mensaje (ENTRADA DE AMENAZA MISIL BALÍSTICA) es lo más importante y lo distinguiría de otros mensajes. El diseño podría usar el mensaje como indicador principal.

El diseño también podría separar los simulacros de las alertas de emergencia reales. Podría haber listas separadas para los simulacros, que se distinguen claramente por la ubicación y otra codificación visual distinta (como sombreado de color).

Usar el mensaje como identificador y separar los ejercicios haría mucho para evitar que este problema vuelva a ocurrir. Francamente, este es un problema clásico de micro interacciones. Un buen diseño podría hacer mucho para asegurarse de que nunca más volvamos a tener este problema.

Por supuesto, esto dependería del proveedor del software. Y hay 23 vendedores en este caso. ¿Es responsabilidad de FEMA ordenar este tipo de cambio de UX? ¿O los vendedores lo harían solo para evitar la vergüenza?

Probablemente no queremos que nuestros legisladores creen estándares de seguridad para las metodologías de nombres de archivos. O nosotros?

¿Cómo habríamos predicho este problema?

Ahora es fácil, con 20–20 en retrospectiva, ver este problema con claridad. ¿Pero podríamos haberlo predicho la semana anterior?

No hacemos suficiente trabajo para probar nuestros propios diseños. No preguntamos si las personas confundirán los nombres que crearon ellos mismos porque esos nombres son demasiado similares. No preguntamos cómo evitamos entrar en pánico a la población de todo un estado, obstruyendo los centros de llamadas de emergencia al 911, posiblemente poniendo en riesgo a cualquier persona que tenga una emergencia real.

En las operaciones de preparación para emergencias, los simulacros son una práctica habitual. FEMA, las operaciones de emergencia estatales y los socorristas locales realizan simulacros regularmente. En estos ejercicios, intentan anticipar lo que podría salir mal. Crean escenarios que empujan a los extremos (¿qué pasaría si ocurriera un ataque terrorista durante la recuperación del terremoto?), Luego sostienen retrospectivas para desarmar lo que sucedió y dónde el sistema no se mantuvo.

En estos simulacros, los proveedores de productos y servicios están invitados a participar. Observan cómo sus productos y servicios se mantienen bajo el estrés de situaciones simuladas. Los vendedores inteligentes también ejecutan sus propios simulacros y simulacros, llevando sus propios productos y servicios a los extremos. Estos esfuerzos prueban sus productos, dándoles la oportunidad de hacerlos más robustos y efectivos.

Estos tipos de procedimientos no son comunes en los productos digitales, excepto en el espacio de seguridad de la información, donde los eventos de piratería se han vuelto comunes. (El año pasado, el Servicio Digital de EE. UU. Del Departamento de Defensa invitó al público a entrar en los sistemas de D.O.D., ofreciendo una recompensa para cualquiera que pudiera tener éxito, para poner a prueba la seguridad de su sistema).

¿Qué habría revelado un lanzamiento simulado de misiles sobre el funcionamiento del sistema? ¿Habríamos encontrado exactamente lo contrario del problema que ocurrió el 13 de enero? ¿Veríamos a un operador usando la plantilla DRILL cuando pretenden usar la advertencia oficial? En el plan de acción de emergencia de HIEMA, el mensaje WEA debe salir 5 minutos después de la detección porque el impacto ocurre 15 minutos después. ¿Cuántas vidas podrían perderse si ocurriera un retraso porque tomó 5 minutos darse cuenta de que no se emitió ninguna advertencia?

Necesitamos más de estos tipos de experiencias de aprendizaje, donde los proveedores y operadores trabajan para estresar nuestros sistemas. Necesitamos romper las barreras de las organizaciones y trabajar directamente con los usuarios, ya que tienen mucha perspectiva para ofrecernos. Entonces necesitamos diseñar algo mejor, algo más seguro para esa población.

ACTUALIZACIÓN: The Verge publicó que el proveedor de HIEMA era AlertSense, ya que sospechábamos y corroboramos que el problema era realmente un problema de denominación de plantillas.