The Hawaii Missile Alert Culprit: Dårligt valgte filnavne

Lørdag morgen, den 13. januar 2018, klokken 08:09 på Hawaii-tid, gennemgik en medarbejder i Hawaii Emergency Management Agency (HIEMA) State Warning Point-kontoret deres rutinemæssige tjekliste for skiftændring. De gennemgik den samme tjekliste, hver gang de startede deres skift. Det var rutine. Det var ikke interessant.

På et tidspunkt åbnede de deres IPAWS-alarmsoftware, hentede en liste med gemte “skabeloner” og valgte en fra en liste med 9. Det, de valgte, blev navngivet PACOM (CDW) - KUN STAT.

Kun dette var ikke skabelonfilen, de mente at åbne. Skabelonen, de mente at åbne, blev navngivet DRILL - PACOM (CDW) - ONLY STATE. Bortset fra ordet DRILL i filnavnet, var de to filer næsten identiske. Jeg siger næsten, fordi der var en anden forskel: Boreversionen sendte kun en meddelelse til testenheder, mens ikke-boreversionen sendte nøjagtig den samme meddelelse til hver mobiltelefon på Hawaii.

Beskeden var ildevarslende. BALLISTISK MISSIELT TRÅD INDBUNDET TIL HAWAII. SØG UMIDLIGT læ. DETTE ER IKKE EN BOR.

Beskeden, der dukkede op på hver mobiltelefon på Hawaii.

Medarbejderne i State Warning Point var ikke umiddelbart klar over, at de havde valgt den forkerte fil. Intet i systemet ville fortælle dem, at de havde. Klik og bekræftelser var nøjagtigt de samme for begge filer. De kunne ikke indse deres fejl, før et øjeblik senere, hvor deres personlige telefon brød med alarmen, ligesom alle andre i State Warning Point Emergency Operations Center. Ups.

At sende en besked til millioner af telefoner om et indgående ballistisk missil, skulle man tro, have en bekræftelsesmeddelelse. Det gjorde. Men det gjorde testmeddelelsen. Det krævede også brugertypen en speciel adgangskode for at sikre, at de havde til hensigt at sende beskeden til enhver modtager, men testmeddelelsen gjorde det også.

Roden af ​​fejlen var at vælge den forkerte fil fra en liste, der lignede denne:

Denne liste, leveret af HIEMA, er skabeloner til meddelelser.

Det er ikke svært at se, hvordan den forkerte fil blev valgt. Disse ser ud til at være opført i kronologisk rækkefølge, nyest til sidst. (Den første fil BMD False Alarm blev tilføjet lige efter, at den falske alarm var slukket, og guvernøren udsendte en erklæring. Den indeholder meddelelsen, der blev brugt til at fortælle alle, at NOT A DRILL-meddelelsen faktisk var en DRILL.)

Der er en alternativ skabelonliste, der svæver rundt: (Det ser ud til, at staten ikke er sikker på, hvilket statligt advarselspunkt bruger.)

I begge tilfælde ser du tydeligt, at DRILL-filnavnet næsten er identisk med det faktiske filnavn. (CDW er Civil Defense Warning.) Denne liste er alfabetisk, som ikke er meget bedre end bestilt dato.

Planlægning af, at denne fejl skal ske

Dette var ikke en gennemtænkt designet menu, mere end nogen tilfældig samling af brugernavne objekter er. Alligevel, for at komme hertil, måtte en masse omhyggelig planlægning ske.

Systemet, der bruges til at sende alarmerne, kaldes IPAWS - det integrerede offentlige alarmsystem og advarselssystem - administreret af den amerikanske regerings føderale nødadministrationsagentur (FEMA) i samarbejde med Federal Communications Commission (FCC). Mobiltelefondelen af ​​IPAWS er ​​kendt som Wireless Emergency Alert (WEA) -systemet.

Stater og amter kan få adgang til IPAWS-systemet til at sende beredskabsmeddelelser, alt fra vejafslutninger til AMBER-advarsler (advarsler om bortførelse af børn).

Hawaii har haft deres system på plads i et stykke tid, som de brugte til vejrrelaterede problemer, ligesom jordskred, der lukker veje og tsunamivarsler. I november var HIEMA bekymret for stigende spændinger med Nordkorea og udarbejdede en ny beredskabsplan, som omfattede WEA-meddelelser i tilfælde af en ballistisk missil-opsætning.

Her er et dias fra HIEMAs beredskabsrutschebane med angivelse af deres reaktion på en missil-opsætning:

Her er de meddelelser, HEIMA anbefaler:

Du kan se, at den faktiske meddelelse, der gik ud, var meget tæt på de meddelelser, der blev anbefalet i HIEMAs plan. (WEA har en grænse på 90 tegn, så den anbefalede meddelelse på 138 tegn skal afkortes.)

Jeg gætter, med disse nye retningslinjer på plads, opdaterede State Warning Point deres gemte meddelelser, først inkluderet drillen som en almindelig praksis og derefter tilføjet den aktuelle meddelelse. (Det ser ud til, at de besluttede at tilføje en skabelon til tsunamivarsler på samme punkt, da det falder i mellem til de to PACOM-meddelelser. PACOM står for United States Pacific Command, det militære fælles koordinationskontor, der overvåger Stillehavsregionen.)

FEMA viser 23 godkendte leverandører af IPAWS-software til originering af alarmer. De fleste af disse er enten Software som en tjeneste eller iOS-apps. (Ja, nogen kan advare hele deres tilstand fra din telefon.)

HIEMA har ikke afsløret, hvilken leverandør de i øjeblikket bruger. (Det er blevet fortalt mig, at FOIA-anmodninger allerede er indgivet for at lære mere om de systemer, der bruges i Hawaii og andre stater.) Det er usandsynligt, at HIEMA-implementeringen blev tilpasset på nogen måde. Det kræver en hel del arbejde at få FEMA-certificeret. Overlad det arbejde til leverandørerne.

Hvis du besøger webstederne for de forskellige godkendte leverandører, ser du nogle pænt designet systemer. Her er en fra et firma kaldet Alertsense:

Det ser ud til at være et rent designet system. Dog har den en forgænger, og det er muligt, at HIEMA bruger noget, der ligner mere her:

Regeringer, som ofte handler om at spare deres skatteydere penge, betaler ikke for opgraderinger. Især til systemer, der ikke er ødelagte. Forhåbentlig lærer vi snart mere om det specifikke system, Hawaii bruger.

Denne fejl er sandsynligvis sket før

Min reaktion, da jeg så systemet involveret, var hvorfor har dette ikke sket før? Når alt kommer til alt er det at vælge en forkert fil en almindelig fejl. Hvis den måde, du sender en IPAWS-besked på er at vælge en foruddefineret skabelon, er det sandsynligvis, at nogen har valgt den forkerte tidligere.

Det ville dog ikke gøre nyheden. De fleste IPAWS-advarsler er til AMBER-advarsler og lokale vejrproblemer. Hvis den forkerte meddelelse blev sendt ud, sig for en vej, der er lukket af oversvømmelser, ville de fleste ikke vide, at der var et problem. Hvis de ikke var tæt på den bestemt vej, ville de sandsynligvis ikke overveje beskeden overhovedet, selvom det var en fejltagelse.

IPAWS-meddelelser er normalt lokale. En statsomspændende meddelelse er sjælden. Det var det, der gjorde denne hændelse så offentlig.

Nyhedsværdien af ​​hændelsen blev forstærket på grund af vores lands nylige spændinger med Nordkorea. Det ser ud til, at vi altid bare er et meget stabilt geniets tweet væk fra at have et missil, der er opsat i vores retning. Havde denne ulykke sket for to år siden, ville alle have haft en anden reaktion. (Skønt det ikke ville være sket for to år siden, fordi der ikke var behov for at tænke på indgående ballistiske missiler dengang.)

Filnavne er den skyldige

Har du alle kendt nogen, der indlæste en gammel version af en fil, da de mente at bruge den seneste, og derefter ved en fejltagelse gemte de gamle data over den nye? Det er i det væsentlige det problem, vi så her.

Dette er et klassisk problem med brugeroplevelsen, der involverer filnavnskonventioner. Brugere vælger ofte ikke filnavne og tænker, vil jeg lave en fejl i fremtiden og vælge den forkerte fil? Vi laver fejl med vores filer hele tiden og griber den forkerte version, når to filer er på samme måde navngivet.

Hvis vi vil spørge os selv, hvordan ville vi forhindre, at dette sker igen, er vi nødt til at se på, hvordan IPAWS-meddelelserne gemmes til fremtidig brug. Systemet, som det fungerer i dag, er afhængig af brugere til at gemme beskedskabeloner med et meningsfuldt navn. Hvis de ikke gør det. Hvis de vælger et navn, der ligner et andet, vil denne fejl ske igen.

Der er intet system, der håndhæver navnekonvention, ligesom der ikke benævnes konventioner for andre filer i noget andet filsystem. Vores systemer tvinger ikke et specifikt filnavnsregime til brugerne for at sikre, at hvert navn er klart og tydeligt, så de forhindrer navneforvirring i fremtiden.

En mulig løsning - Slip af filnavne

På mange måder er filnavne en anakronisme fra gamle dage, da læsning af data var langsom og plads var dyr. Vi kunne eliminere dem i mange tilfælde, og dette er en af ​​dem.

For en IPAWS WEA-meddelelse er der to forskellige identifikatorer, som vi kunne bruge i stedet for et filnavn: selve meddelelsen, og hvem den sendes til. Meddelelsen (BALLISTIC MISSILE THREAT INBOUND) er den vigtigste ting og adskiller den fra andre meddelelser. Designet kan bruge beskeden som en primær indikator.

Designet kunne også adskille øvelser fra de faktiske nødalarmer. Der kan være separate lister til borne, som tydeligt adskilles efter placering og anden distinkt visuel kodning (som farveskyggning).

Brug af meddelelsen som identifikator og adskillelse af borerne ville gøre meget for at forhindre, at dette problem opstår igen. Helt ærligt er dette et klassisk problem med mikrointeraktioner. Godt design kan gå langt for at sikre, at vi aldrig har dette problem igen.

Dette ville naturligvis være op til leverandøren af ​​softwaren. Og der er 23 leverandører i dette tilfælde. Er det FEMAs ansvar at give mandat til denne type UX-ændring? Eller ville leverandørerne gøre det bare for at undgå forlegenhed?

Vi ønsker sandsynligvis ikke, at vores lovgivere opretter sikkerhedsstandarder for metodologier for filnavne. Eller gør vi det?

Hvordan ville vi have forudsagt dette problem?

Det er let nu, med 20-20 bagspejlet, at se dette problem tydeligt. Men kunne vi have forudsagt det ugen før?

Vi gør ikke nok arbejde for at stresstest vores egne design. Vi spørger ikke, om folk vil forveksle navne, de oprettede selv, fordi disse navne er for ens. Vi spørger ikke, hvordan vi forhindrer panik i befolkningen i en hel stat, tilstopper 911-alarmcentre, eventuelt sætter alle, der har en reel nødsituation, i fare.

I beredskabsoperationer er bor en regelmæssig praksis. FEMA, statslige nødoperationer og lokale første respondenter afholder regelmæssigt øvelser. I disse øvelser forsøger de at forudse, hvad der kan gå galt. De skaber scenarier, der skubber mod yderpunkterne (hvad hvis et terrorangreb skete under opsving af jordskælv?), Og holder derefter retrospektiver for at adskille hvad der skete, og hvor systemet ikke holdt op.

I disse øvelser opfordres leverandører af produkter og tjenester til at deltage. De observerer, hvordan deres produkter og tjenester holdes under stress med simulerede situationer. Smarte leverandører kører også deres egne øvelser og simuleringer, og skubber deres egne produkter og tjenester til ekstremer. Disse stresstest deres produkter, hvilket giver dem en chance for at gøre dem mere robuste og effektive.

Disse typer procedurer er ikke almindelige i digitale produkter, undtagen i informationssikkerhedsområdet, hvor regelmæssige hackinghændelser er blevet almindelige. (Sidste år opfordrede Department of Defense U.S. Digital Service offentligheden til at bryde ind i D.O.D.-systemer og tilbyde en dusør for alle, der kunne få succes, til at stresstest deres systemsikkerhed.)

Hvad ville en simuleret missilforsendelse have afsløret om driften af ​​systemet? Ville vi have stødt på det modsatte af det problem, der skete den 13. januar? Ville vi se en operatør, der bruger DRILL-skabelonen, når de ville bruge den officielle advarsel? I HIEMAs nødhandlingsplan skal WEA-meddelelsen gå ud 5 minutter efter detektion, fordi påvirkningen sker 15 minutter senere. Hvor mange liv kan gå tabt, hvis der skete en forsinkelse, fordi det tog 5 minutter at indse, at der ikke var nogen advarsel?

Vi har brug for flere af disse typer læringserfaringer, hvor leverandører og operatører arbejder for at understrege vores systemer. Vi er nødt til at nedbryde organisationernes barrierer og arbejde direkte med brugerne, da de har meget perspektiv at tilbyde os. Så er vi nødt til at designe noget bedre, noget mere sikkert for denne befolkning.

OPDATERING: Verge offentliggjorde, at leverandøren af ​​HIEMA var AlertSense, da vi havde mistanke om og bekræftet, at emnet faktisk var et skabelon-navnsproblem.