NemID Nedbrud -1/2
Som den opmærksomme læser muligvis har bemærket, har jeg leveret en sound-bite om NemID Nedbrudet til Henrik Molkte på DR-TV.
Henrik brugte fem måneder på at vriste nogle dokumenter ud af DigSt og Nets og han gav mig et par dage til at kigge på dem, så der ikke gik totalt Kaptajn Haddock i mig for åben skærm.
Det tilkommer ikke mig at offentliggøre dokumenterne, men jeg er ret sikker på at den danske IT-branche gerne vil have sænket ploven meget længere ned end det niveau den brede offentlighed kan kapere i en en TV-Avis, så her kommer to blogindlæg.
Dette første blogindlæg handler om selve nedbrudet, det andet kommer til at handle om udredningen, afrapporteringen og dens talrige mangler.
Der er tale om ialt seks dokumenter, to fra DigSt, to fra Nets og to fra et externt revisionsfirma, som Nets har købt og betalt til at udrede sagen.
De to fra DigSt handler udelukkende om hvilke anstrengelser de har gjort sig for at undgå at udlevere de andre fire dokumenter til Henrik og DR, dem ser vi bort fra i første runde.
Det første dokument (#1, 4 sider) er dateret 23 august 2022, og har titlen "Root Cause Analysis by Problem Management" med Nets logo. Dokumentets form er en udfyldt formular.
Det andet dokument (#2, 4 sider) er ligeledes dateret 23 august 2022, har titlen "Incident Description" og har form af et memo på officielt Nets brevpapir.
Det tredje dokument (#3, 6 slides) er dateret 18 august 2022 og har form af en "Tak fordi I hyrede os" PowerPoint fra revisionsfirmaet som indeholder en grafisk fremstilling hvor hændelsesforløbet er opdelt i fem spor.
Det fjerde dokument (#4, 37 slides), er dateret 16 september 2022 og har form af en PowerPoint hvor revisionsfirmaet afleverer resultatet.
Jeg vil i teksten henvise til disse fire dokumenter på formen (#x/y[/r]) dvs, dokument, side og evt. keyword, i håbet om at dokumenterne en dag får et bredere publikum, men indtil da må I tage mit ord for det.
Det relevante hændelsesforløb
2020-05-28 Nets tester deres Disaster recovery.
Det fremgår ikke om testen gik godt.
2020-11-28 Nets tester ikke deres Disaster recovery.
2021-05-28 Nets tester ikke deres Disaster recovery.
2021-Q3 Nets ledelse er via officiel "Risk Report" er klar over at DR ikke bliver testet. (#4/8)
2021-11-28 Nets tester ikke deres Disaster recovery
2022-05-28 Nets tester ikke deres Disaster recovery
2021-12-03 VM-migrering uden papirarbejde og uden test
På grund af kapacitetshensyn migreres en eller flere VM'er til en anden host.
Blandt andet flyttes en CRL server (Slå det selv op.) til NemID.
Boot-partitionen flyttes ikke med (eller havner på ramdisk?)
Systemet advarer om problemet, men det ignoreres. (#4/23/IAM11)
Der er ingen "change ticket" for denne ændring. (#4/12/DR1)
Der foretages ingen test efter denne ændring.
2022-06-21 11:58 Storage opgradering afsluttes med reboot
(#2/4) angiver 11:58, det er konsistent med andre informationer.
(#4/6) angiver 18:35, det giver ingen mening.
Opgradering af storage på VM-hosten afsluttes med reboot.
VM-hosten med CRL serveren kommer ikke op.
2022-06-21 17:23 Alarm om manglende adgang til CRL
Vurderes til at være en falsk alarm (#4/16/DR16)
2022-06-21 23:58 CRL expiry
Seneste CRL liste udløber og mindst ⅓ af brugerne kan ikke komme igennem.
2022-06-22 08:16 Akamai DoS blokerer trafik til MitID.
På grund af de mange brugere der henvises til at bruge MitID stiger trafikken nok til at Akamai's automatiske systemer tror det er et DoS angreb og de lukker for trafik til MitID fra (???)
Akamai sender email til "IBSS NETS NETWORK INTERNAL", de modtager den kl. 08:22 og ignorerer den. (#4/26/MA2)
2022-06-22 10:05 - 11:00 Hotpatching tager NemID 100% ned.
(#2/4)
2022-06-22 11:16 Backup forsøges indlæst
(#2/4)
2022-06-22 15:49 Nets bliver opmærksom på Akamais email
Nets kontakter Akamai og får fjernet IP-blokeringen.
2022-06-23 01:07 Disaster Recovery initieres
(#2/4)
2022-06-23 16:25 Disaster Recovery fejler
(#2/4)
2022-06-23 20:27 Restore fra Backup opgives
Alle backups opgives, da de mangler en bestemt fil.
(#4/6)
2022-06-24 Nets begynder at bygger en ny CRL server fra grunden
2022-06-25 17:52 NemID stort set oppe
(#2/4)
2022-07-01 01:07 NemID helt oppe
(#2/4)
Useriøs Disaster Recovery
Skidt sker. Både indenfor IT og andre steder og derfor er DR den absolut vigtigste ting hvis noget skal virke.
Vi lukker f.eks Storebæltsforbindelse én gang hvert år, for at checke og træne hvordan man hiver et brændende tog op af røret.
Nets har derimod "en ambition om at teste DR to gange om året" (#4/6)
…og det får de så ikke lige gjort i et par år - fire gange i træk.
Der omtales faktisk en DR-test den 2022-06-21 i "pre-prod" miljøet, og at den fejler klokken 17:15. (#4/8)
Det er ikke klart hvorfor den omtales om en "test":
Havde de bare helt tilfældigvis endelig taget sig sammen til at teste DR ?
Begyndte de at "teste" fordi NemID var på spanden ?
Bliver det udelukkende kaldt "test" fordi det ikke foregår i produktionsmiljøet ?
Useriøs Sikkerhedskopiering
Da revisionsfirmaet giver sig til at grave i det, afsløres en dybt useriøs sikkerhedskopiering.
Ud over at man aldrig testindlæser sikkerhedskopierne, reagerer Nets ikke på fejl og alamer fra fra backup-kørslerne.
Ydermere, og her er dokumentet ret kraftigt udstreget, er der stor tvivl om Nets selv evner at indlæse sikkerhedskopierne og hvor mange andre systemer det ville påvirke.
Den tvivl ville ikke existere hvis man regelmæssigt afprøvede sine sikkerhedskopier.
God, Root, What Difference?
Over fire hele sider (#4/20-23), med hyppige udstregninger, gør revisionsfirmaet rede for at NemIDs operative personales arbejde har meget lidt at gøre med hvad ledelsen måtte tro der foregår.
Præcis hvilken vej denne afkobling vender er ikke indlysende, men det lyder som om det operative personale kører deres eget løb med en højere standard end Nets ledelse lægger op til.
Bla. afviser de at bruge forskellige officielle Nets tiltag (#4/21/IAM4) fordi de ikke er gode nok.
De afviser (DuH!) også et krav i Nets' officielle dokumenter om at bruger NemID som adgangskontrol (#4/22/IAM9)
Det fremgår også at der ikke er omhyggelig kontrol med brugen af Administrator Privileges i Nets, f.eks foretages storage opgraderingen af en extern person og den omtalte VM migrering var både uden risikoanalyse og udokumenteret.
Revisionsfirmaet konkluderer at der dog, trods alt, ikke er nogen indlysende åbninger for udefrakommende fjendtlig aktivitet.
Men hvordan var det nu med Se&Hør's "Tys-Tys Kilde"... ?
For systemer så kritiske som NemID, bør der være en 100% konsekvent "To-mands-regel" på enhver anvendelse af Administrator Privilegier og fysisk adgang og der skal føres logbog over alle aktiviteter.
Har branchen virkelig intet lært af, at Edward Snowden kunne rende med NSA's kronjuveler, uden de kunne finde ud af hvad han faktisk tog?!
Useriøs drift og overvågning
Alarmer om alt muligt, fra backup fejl over manglende CRL'er og til DoS-blokeringer, bliver bare ignoreret eller kigget på senere.
Uanset hvilke forklaring Nets måtte have, er den ikke god nok.
Ingen brugbar genopbygningsprocess
Da Nets skal til at konstruere CRL serveren fra bunden, må de nærmest prøve sig frem og det tager dem en hel uge.
Denne del graver Revisionfirmaet overhovedet ikke i.
Uintegrerede Externe Services
Revisionsfirmaet noterer sig, ret spydigt, at selv 3 måneder senere har de stadig ikke set skyggen af dokumentation for hvorledes Akamai og deres anti-DoS services passer ind i arkitekturen.
Der er tilsyneladende heller ingen overvågning der spotter IP-Blokeringen.
Advarsels-emailen om blokeringen sidder ignoreret i en mailbox hele dagen.
Abekast
I TV-Avisen stod Nets' talsmand og kaldte det "En menneskelig fejl"
Revisionrapportens tilgang til forløbet er tydeligvis også at alle de involverede medarbejdere har svigtet den heroiske og ambitiøse ledelse i Nets.
Not!
En så tilbundsgående og omfattende slendrian og useriøsitet som dokumenterne afslører, kan ikke implementeres af medarbejder uden ledelsens medvirken og som sagt dokumenteres det at ledelsen var informeret om de manglende DR-tests.
Hvad er DigSt's rolle ?
Når alt dette er sagt, skal det retfærdigvis siges, at bortset hvorledes deres ihærdige forsøg på at hemmeligholde disse dokumenter skriger til himlen, ved vi intet om DigSt's rolle.
NemID drives på forlænget overtid fordi MitID blev forsinket og vi kender ikke indholdet af den kontrakt.
DigSt har næsten med sikkerhed været meget omkostningsbevidste.
Når den himmelråbende slendrian der her er dokumenteret ingen virkelige konsekvenser har fået for Nets, kan det skyldes det at de oprigtig kunne svare DigSt med: I får præcis hvad i betaler for.
Det heller ikke utænkeligt at vi er ude i IC4-land, hvor DigSt har koncenteret sig om pantone-farver, fontstørrelser og logo-design, mens "alt det der tekniske" blev overladt 100% til leverandøren.
Det kunne f.eks forklare hvorledes DigSt ikke har sørget for at test af DR-planen var mere end "en ambition".
Det er også her vi bliver nødt til at parkere spørgsmålet om hvorfor og hvordan, en så central enhed som en CRL server for ⅓ af NemID certifikaterne, ikke havde to redundante implementeringer til at begynde med?
Der sker ingen fejl på en IBM Mainframe
Jeg har tidligere kommenteret hvorledes IBM Mainframe-folket lider af en objektivt ubegrundet tillid til at der ikke sker fejl på IBM Mainframes og det er også en mulig indgangsvinkel til at forstå hændelsesforløbet og tilgangen til fejl og advarsler.
Mønsteret med at DR planen er en ren skrivebordsøvelse der kun testes, ofte endda kun delvist, én enkelt gang, er meget symptomatisk for IBM mainframe installationer.
En del af årsagen er at man traditionelt har foretaget testen på en til formålet af IBM lejet mainframe, noget IBM tager sig godt og vel betalt for (og hertil rejseudgifter.)
Nogle steder består ikke alene testen af, men selve DR planen simpelthen af: "Vi giver IBM backup-båndene og en stak penge."
Der er også mange detaljer i Revisionsfirmaets afrapportering der lugter af impedansforskellen mellem NemID driftspersonalet og Nets' ledelse, simpelthen er mainframe vs. PC-server.
/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.