NemID Nedbrud - 2/2
Mine faste læsere har allerede gættet på at dette blogindlæg vil ende med at konkludere at vi skal have en uafhængig IT havarikommission,
Vi får se...
I første blogindlæg handlede det om hvad der var sket og hvorfor det gik galt. Dette blogindlæg handler om rapporteringen, om de dokumenter som Henrik Molkte efter fem måneder fik DigSt til at slippe, som dokumenter beset og som læringsmateriale, for DigSt, for Nets og for resten af IT branchen.
Partsindlæg
Alle de seks dokumenter er partsindlæg.
Dokument nummer 1 er fra "NETS Problem Management", en eller anden afdeling der endelig fik chancen for at vise hvor dygtige de var til deres job osv.
Dokument nummer 2 er usigneret, men på officielt Nets brevpapir, formodentlig den redegørelse man initielt har tilsendt DigSt.
Dokument nummer 3 er ligegyldigt, det er bare Revisionfirmaet der viser at de er færdige med det grafiske design til det endelige PowerPoint set.
Dokument nummer 4 er bestilt af Nets ledelse og det siger næsten sig selv at et stort velrenomeret Revisionsfirma ikke bider den hånd der fodrer.
De to breve om agtindsigten er DigSt tvunget til at skrive, men allerede de krumspring de gør sig for undslå sig, gør også disse dokumenter til (inderligt ligegyldige) partsindlæg.
Overstregningerne
Brevene fra DigSt gør også meget ud af hvor nødvendige overstregningerne er for NemIDs sikkerhed.
Det siger sig selv at man ikke lige frem behøver lægge totalt detaljerede tekniske oplysninger om alt muligt ud offentligt, men at overstrege tabelsøjlernes overskifter (#2/4) som viser de forskellige anvendelsesmetoder for NemID certifikaterne er decideret latterligt.
Vi ved ikke hvem der har udført overstregningerne, men enten har vedkommende intet begreb om hvilke informationer der har betydning for NemIDs sikkerhed og derfor systematisk har overstreget alle forkortelser vedkommende ikke selv genkendte.
Alternativt har vedkommende bevidst forsøgt at overstrege så meget som muligt, i den hensigt at gøre rapporten ubrugelig til journalistiske formål.
Ingen af delene er acceptabelt i et åbent samfund.
Det siger også sig selv, at både hemmeligholdelsen og overstregningerne, da dette mislykkes, ikke ligefrem opfordrer til at IT-folk udenfor Nets at lære noget af dette nedbrud.
Form
Man skal ikke angribe på form, hvis man kan angribe på substans, men jeg bliver nødt til at få det her af vejen først:
En af de allervigtigste ting vi lærte fra Challenger-rumfærgens forlis, var at PowerPoint ikke er et rapportformat og ikke må bruges som et rapportformat.
Det er der tilsyneladende ikke nogen hos Det Store Verdensberømte RevisionsFirma der har lært noget af.
"Rapporten" er lavet som et slideshow, med tilhørende amputerede sætningskonstruktioner, manglende detaljering og hvor forskellige ting blændes ind og ud fra slide til slide.
Det er simpelthen ikke acceptabelt.
Substans
Men substansen er altså ikke meget bedre.
Der er ikke noget så fundamentalt som en definitiv tidsline.
Den tidslinie jeg bragte i det første blogindlæg måtte jeg selv stykke sammen ved at sidde og bladre i de forskellige dokumenter, der som forventeligt ikke er enige om hvornår visse kritiske begivenheder indtræder.
Dokument 2 har f.eks et event:
11:58 "(???)storage for (???)unavailable"
Det passer fint med alarmen klokken 17:23 om at CRL'en ikke kunne hentes og derfor ville udløbe nogle timer senere.
Dokument 4, fra Revisionsfirmaet har:
18:35 "An upgrade of storage on the machines was completed […]
Det passer overhovedet ikke med at CRL'en var utilgængelig (mindst!) en time tidligere og "18:35" kan jeg ikke finde noget andet sted i dokumenterne.
Ingen af dokumenterne forklarer hvad det var for en "DR test" der blev foretaget (og fejlede) den dag det hele exploderer og de er heller ikke helt enige om præcis hvad den gik ud på, I (#4/8) står der f.eks:
"Error in DR testing performed the day before the indicident [...]"
Blev testen faktisk startet dagen før ?
Kørte den hele natten og den næste dag ?
Eller har nogen fra Revisionsfirmaet ikke styr på dato og tid ?
Og nu vi er ved at klokke i timestamps:
Akamai blokerer klokken 08:16, men alle dokumenterne bruger 08:22, modtage-timestamp på den email Akamai sender Nets om det.
Nets eget dokument 2 indeholder:
10.05-11:00 "(???)patching at (???)causing outage on (???)"
Hvilket tager NemID helt ned, men finder Revisionsfirmaet ikke grund til at gå nærmere ind på.
Mangler
Ingen af dokumenterne forholder sig til at Nets skal bruge en hel uge på at reinstallere CRL serveren og hvorfor opskriften på dette ikke er en del af deres DR plan.
Ingen af dokumenterne forholder sig til indholdet af DR planen,
Var den bare et figenblad ?
Var den tilstrækkelig ?
Var den realistisk ?
Ingen af dokumenterne forholder sig til det med "ambitionen" om at test DR planen:
Hvem har besluttet at det kun er "en ambition" ?
Står det i kontrakten mellem DigSt og Nets ?
Er det i modstrid med hvordan Nets' driver andre funktioner ?
Hvem har lagt det konkrete ambitionsniveau, der gør at man bare kan springe over fire gange ?
Hvorfor sprang man over fire gange ?
Hvem besluttede det ?
Hvem blev informeret om det ?
Havde man forstået konsekvenserne af det ?
Ingen af dokumenterne forholder sig til at Nets egen overvågning ikke opdagede Akamai's blokering.
Ingen af dokumenterne forholder sig til at Nets egen overvågning tilsyneladende heller ikke testede om CRL serveren overhovedet svarer. (Den advarsel der kommer kl. 17:23 er om at den ikke har svaret i så lang tid at CRL'en vil udløbe om nogle timer)
Ingen af dokumenterne forholder sig til hvorfor der ikke var redundante CRL servere til at begynde med.
Root Cause og Rodbehandlinger
Når man taler om "root cause" er der groft sagt to opfattelser af begrebet.
Den første forstår root cause som kun den eller de begivenheder der ved deres indtræden var årsag til balladen.
Den anden forstår root cause som en "men hvis ikke" betingelse, således at det ikke alene omfatter det der umiddelbart var årsagen, men også de begivenheder der ved deres indtræden eller fravær, ikke
forhindrede den.
Den første forståelse bruges blandt folk med den fundamentale opfattelse af problemerne kan forhindres og som derfor fokuserer på at placere et ansvar når de sker (Aka: "nulfejlskultur".)
Den anden forståelse bruges blandt folk som accepterer at Skidt Sker og Folk Dummer Sig og som derfor fokuserer på at undgå eller afbøde konsekvenserne af de uundgålige problemer og hændelser.
Jeg synes det er en ufatteligt vigtig forskel, men jeg indrømmer at jeg først selv blev opmærksom på den, i forbindelse med mit arbejde i lufthavnsbranchen.
Det var så grænseoverskridende for mig at skulle designe og implementere et touch-panel, som flyvelederne skulle bruge til bane-informationer i Kastrup Lufthavn, at jeg takkede nej til opgaven.
Men de var lidt i tidsnød og derfor brugte en venlig flyveleder på projektet en eftermiddag på at sætte mig ind i, hvor meget andet der skulle gå galt, jeg husker mindst fem eller seks andre led i kæden, før en fejlfunktion i mit system på nogen måde kunne bringe liv og lemmer i fare.
Det fik mig naturligvis ikke til at slække på kvaliteten, men det at mit display aldrig ville kunne blive den eneste root-cause, gjorde at jeg turde påtage mig opgaven.
Her bruger alle fire dokumenter meget klart første forståelse og udpeger derfor VM-migreringen som root cause og fokuserer ret skarpt på at nogen ikke har gjort som ledelsen havde dikteret.
Men Skidt Sker!
Der er hver dag folk der har fået benet ud af den forkerte seng, drukket kvædethe i stedet for kaffe, skændtes med partneren, bulet bilen og skal til møde i banken...
Uanset om man prøver at holde et fly i luften eller NemID kørende, skal systemet, med stor margin, kunne holde til den slags under-performance.
Hvis jeg bruger den anden forstålse af "root cause" på NemID nedbrudet, finder jeg mindst følgende Root Cause:
- VM migrering med hovedet under armen
- Manglende to-mands-regel for sysadm arbejde
- DR plan der ikke virker
- DR plan der kun har et lag
- DR plan der ikke bliver testet
- Sikkerhedskopier der ikke indeholder hvad de skal
- Sikkerhedskopier der ikke bliver testet
- Den tilsyneladenden udbredte antagelse at advarsler man ikke genkender ikke er vigtige
- Talrige impedansproblemer mellem teori og praksis i driften af NemID
og hvis ikke for overstregningerne, er jeg ret sikker på at den liste ville være længere.
Nogle af disse ting omtaler dokumenterne som "contributing factor", men det mener jeg er en fejlforståelse af også dette begreb.
En "contributing factor" er noget der gør en hændelse mere sandsynlig eller forstørrer konsekvenserne af den: Et gulv uden skridsikker overflade, et forvirrende skilt, opbevaring af gift og vitaminpiller i samme type beholder osv.
Når noget direkte og explicit, som f.eks DR planen og sikkerhedskopierne, har til opgave at forhindre præcis den slags nedetid som NemID blev ramt af, men ikke gør det, er det ikke en "contributing factor", så er det i sig selv en "root cause" til nedetiden.
Endelig er der alt det dokumenterne slet ikke kigger på:
- Hvad står der om DR test i konktrakten mellem DigSt og Nets ?
- Har Nets rapportering givet DigSt en retvisende opfattelse af driftsituationen ?
- Har "omkostningsbevidsthed" hos DigSt ført til slækkede krav ?
- Hvorfor har ingen styr på indplaceringen af Akamai imellem NemID og MitID ?
- Var der en procedure for håndtering af kommunikation fra Akamai ?
osv.
Konklusion
Det er præcis den forskel jeg ville forvente at se, hvis en uafhængig IT-Havarikommission havde gennemgået NemID nedbrudet:
De dokumenter Henrik har skaffet os adgang til, forhindrer at Nets ledelse bliver draget til (økonomisk) ansvar og tillader dem at offentligt at garantere at præcis dette nedbrud ikke kan ske igen.
En rapport fra en officiel IT-Havarikommission ville gøre det muligt for alle aktører i IT branchen at bliver klogere af nedbrudet, således at hverken dettee specifikke eller en stor klasse af andre lignende nedbrud sker igen, hverken i NemID, MitID, andre offentlige IT systemer eller private IT systemer.
Så ja, I gættede rigtigt:
Vi skal have en IT-Havarikommission nu!
/phk
...men det er dyrt at lave god journalistik. Derfor beder vi dig overveje at tegne abonnement på Version2.
Digitaliseringen buldrer derudaf, og it-folkene tegner fremtidens Danmark. Derfor er det vigtigere end nogensinde med et kvalificeret bud på, hvordan it bedst kan være med til at udvikle det danske samfund og erhvervsliv.
Og der har aldrig været mere akut brug for en kritisk vagthund, der råber op, når der tages forkerte it-beslutninger.
Den rolle har Version2 indtaget siden 2006 - og det bliver vi ved med.