Dette indlæg er alene udtryk for skribentens egen holdning.

NemID Nedbrud - 2/2

23. november kl. 10:4042

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.

Artiklen fortsætter efter annoncen

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  
 

42 kommentarer.  Hop til debatten
Denne artikel er gratis...

...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.

Debatten
Log ind eller opret en bruger for at deltage i debatten.
settingsDebatindstillinger
31
28. november kl. 10:10

Først fremragende gennemgang, og tak for det. Der er jo rootcause og så rootcause, jeg husker engang,hvor jeg var sat til, at sikre at en rootcause analyse faktisk kom frem til rootcausen. Og da Problem mgt. så kom med deres analyse og sagde, at rootcause var kombinationen af en Server og en storage server der ikke var patchet, og mente at så var den ged rundbarberet, var jeg fræk nok til at spørge, men direktøren var til stede, jo at det da var meget godt men, men hvorfor var de ikke patchede ? Ja, man kunne godt sige, at den manglende patching var en teknisk rootcause, men nu var det jo en service vi ydede, og en service består af mere end bare teknik, det er en fuld 360 graders leverance, der indeholde andre ITIL processer (nu practices i ITIL V4), så hvorfor fejlede disse processer der skulle sikre at ting blev patchet ? Det førte til en del tomult, for sådan virkede det jo ikke, men for at gøre en lang historie, kort viste det sig, at det var manglende træning og fejl ift. intern sourcing.

Og jeg synes at PHK stopper lidt for tidligt, for han er jo på rette spor når han siger:

Endelig er der alt det dokumenterne slet ikke kigger på

Og det er jo helt rigtigt, hvis man siger at en Rootcause analyse bliver ved, til den når rootcause, altså ikke nødvendigvis stopper ved en teknisk rootcause.

Så hvorfor stoppede man med at lave DR test ? Hvis man google lidt kan man finde de oprindelige planer for udrulning af MitID, og disse siger jo at MitID skulle være, startet Medio 2021 og afsluttet Ultimo 2021.

Så det kunne måske være grunden til at sidste DR test er:

2020-05-28 Nets tester deres Disaster recovery

Om det så er NETS eller kunden, kontrakten eller ... ja det er jo det som er spørgsmålet. Men det er nok der hunden ligger begravet.

Mht. en IT-Havarikommission. Det at lave en stand alone organisatorisk institution, vil næsten helt sikkert virke lige så dårlig som IT-projektrådet, som jo er ment som en up front konstruktion til, at forhindre at IT projekter går dårligt. Men lets be honest, det virker jo ikke, tingene er jo ikke blevet bedre i den virkelige verden.

Det betyder jo ikke, at kapabilitet (evnen til at gøre noget) ikke skal opbygges i det offentlige. MEN det her drejer sig om en professionalisering af IT i det offentlige. Og her er root cause analyser og Lessons learned i projekter, CSI (ITIL) etc. etc jo netop nogle af de mekanismer, der driver/tvinger forbedringer. Og hvis vi nu fik et IT-ministerium, så ville det jo være det rammesættende focal point for at drive en sådan professionalisering igennem.

Og vi har jo allerede en IT-Havarikommission, den hedder Rigsrevisionen. Og i den kontekst har de jo set lidt på det her:

https://rigsrevisionen.dk/revisionssager-arkiv/2022/nov/beretning-om-statens-it-beredskab

// Jesper

32
28. november kl. 12:31

"Mht. en IT-Havarikommission. Det at lave en stand alone organisatorisk institution, vil næsten helt sikkert virke lige så dårlig som IT-projektrådet, som jo er ment som en up front konstruktion til, at forhindre at IT projekter går dårligt."

Det argument holder simpelthen ikke, for havarikommissioner virker fint i alle mulige andre brancher, der til gengæld ikke har et "X-projektråd" der er fyldt med lobbyister fra de leverandører der i stort omfang producerer problemerne.

"Og vi har jo allerede en IT-Havarikommission, den hedder Rigsrevisionen. Og i den kontekst har de jo set lidt på det her:"

Nej, ikke engang tæt på.

Rigsrevisionen kigger udelukkende på IT-projekter fordi der forsvinder så mange penge ind i dem, uden at der kommer ret meget ud.

En ITHK har et helt andet og meget enklere formål: At undgå at den samme begivenhed gentager sig.

35
28. november kl. 15:44

Det argument holder simpelthen ikke, for havarikommissioner virker fint i alle mulige andre brancher, der til gengæld ikke har et "X-projektråd" der er fyldt med lobbyister fra de leverandører der i stort omfang producerer problemerne.

Nu vil jeg ikke kalde medlemmerne af statens IT-projektråd for lobbyister. Det er de langt fra. Man kan kalde dem meget og undrer sig over at de sidder der, når man tænker på deres egne organisationers trackrecord. Men lobbyister ? Desuden er de også dybt afhængige af det sekretariat, der laver rugbrødsarbejdet.

Men du prøver at løse et kapabilitets problem ved at lave en organisatorisk enhed, som du 'cut-n-paster' fra andre brancher. Det bliver nok ikke mere klassisk 1B, centraladministrations måden at forsøge at løse noget på. Og det virker ikke.

Rigsrevisionen kigger udelukkende på IT-projekter fordi der forsvinder så mange penge ind i dem, uden at der kommer ret meget ud.

Det er faktuelt forkert. Hvis du havde ulejliget dig med bare, at følge linket ville du se, at du tager fejl. Man kunne også have besøgt deres hjemmeside og set at de også laver juridisk-kritisk revision og forvaltningsrevision.

Og det at lave en revision af at alle offentlige IT organisationer, havde implementeret og praktiseret de 'feedback' mekanismer, der gør at organisationerne lærer af deres fejltagelser ville virke.

Om man så lavede et kontor hos rigsrevisionen, der hed IT-haverikontoret og som kunne gennemgå 'IT katastrofer', jeg kunne ikke være mere lige glad. Fint for mig.

Men det rigtige ryk, kommer altså ved, at man gør alt det kedelige som involverer People and Processes og at man tager IT seriøst. Altså laver en rigtig business case, arkitektur governance etc. etc. etc.

Tja ja.

// Jesper

37
28. november kl. 22:08

Men du prøver at løse et kapabilitets problem ved at lave en organisatorisk enhed, som du 'cut-n-paster' fra andre brancher. Det bliver nok ikke mere klassisk 1B, centraladministrations måden at forsøge at løse noget på. Og det virker ikke.

Er vi enige om at de andre havarikommissioner virker ?

Hvis ikke, må du først overbevise os om at de ikke gør.

Hvis vi er enige om at de virker, må du forklare os hvorfor du tror IT er så specielt, at den samme systematiske, fakta-drevne tilgang til at forhindre gentagelser, ikke også skulle virke med IT ?

For mig lyder det nærmest som om du tror at en havarikommission er politisk udpeget blandt de sædvanlige bengnavere ?

40
29. november kl. 21:14

Er vi enige om at de andre havarikommissioner virker ?

Ja selvfølgelig.

For mig lyder det nærmest som om du tror at en havarikommission er politisk udpeget blandt de sædvanlige bengnavere ?

Men hvordan skulle de blive anderledes ? Hvad utopi skulle pludselig materialisere sig således, at en ny prestige fyldt org. ikke skulle blive det ? Prøv at læse Jan Heisterberg observationer herover. Og for the record, så har jeg selv skrevet materiale, der skulle i Statens IT-projektråd. Og jeg har været en del af et evaluerings korpset til en anden 'lavere offentlige institutioners' egen versioner af IT-projektrådet. Og jeg har set mine evalueringer blive tromlet, pga. office politics, bare for at se at resultatet af manglende efterlevelse resultere i forsider i pressen. Så jeg er måske bare lidt mere ... brændt end du er.

Hvis vi er enige om at de virker, må du forklare os hvorfor du tror IT er så specielt, at den samme systematiske, fakta-drevne tilgang til at forhindre gentagelser, ikke også skulle virke med IT?

Fordi havarikommissioner typisk eksisterer i meget simplere domæner end IT domænet. Hvis du ser på sådan noget som Togdrift, så er det en meget meget simplere virkelighed end offentlig IT i Danmark. Togdrift implementere jo ikke regler for skat, offentlige ydelser, skoler, politi, you name it. Togdrift implementere togdrift. Og desuden så kører togene jo sådan nogenlunde, vi har kun haft 4 togulykker de sidste 25 år. Vi har formodentlig haft 4 IT ulykker i det offentlige siden du skrev det her blogindlæg. Så både kompleksiteten og frekvensen er meget meget anderledes end f.eks. luftfart og togdrift, for bare at tage to eksempler på hvor der er havarikommissioner.

Du skriver så:

systematiske, fakta-drevne tilgang til at forhindre gentagelser, ikke også skulle virke med IT?

Men så er vi jo helt 100% enige. Det drejer sig netop om systematiske, fakta-drevne faglige evalueringer af fejlede, initiativer (for ikke at begrænse os til projekter). Men for at dette skal virke, skal vi længere ind.. helt ind i sindet (for at citere Rytteriet), nej vi skal sørge for at al IT i det offentlige (også outsourced) praktiserer fakta-drevent feedback, således at organisationen lærer af sine fejltagelser, og at denne læring kan deles både horisontalt og vertikalt.

Og dette ligger f.eks. i Statens IT-projektmodel, det ligger i Agil Udvikling, det ligger i ITIL.. etc. etc. Stort set alle fag rammeværk har denne indbyggede lessons learned mekanisme. Problemet er bare, at den ikke bruges, i Danmark. Organisationerne lærer ikke af deres fejl, og det deles ikke.

I en virkelighed, hvor alle faktisk praktiserede disse best practices ift. feedback, jo så måske kunne en IT-haverikommision måske virke. Fordi fejlede projekter og katastrofer ville være en .. abnormitet.. der ville kræver ekspert kompetence for at udforske og finde ud af, hvad der gik galt, fordi normalen ville være, at kontroller, faglighed og kompetence ville betyde, at generelt så ville ting gå godt ift. IT.

Der er vi bare ikke nu. Reglen er jo ikke at projekterne lykkedes... reglen er, at de fejler. Og en Havarikommission ville jo skulle bestå af tusindvis af mennesker for at kunne behandle alle haverierne, og alt IT ville gå i står. Og ja...

Så vi er ikke uenige om faglighed og fakta. Mere af det tak.

// Jesper

41
29. november kl. 22:34

Fordi havarikommissioner typisk eksisterer i meget simplere domæner end IT domænet.

Men det der går galt indenfor IT idag er faktisk også simpelt, helt ned til ikke at teste sine nødplaner og reagere på advarsler fra skrivningen af sikkerhedskopier.

Selvfølgelig er en ITHK ikke en vidunderløsning der på ingen tid gør den bløde gane fast og fodsved til et ukendt problem, men det er en kendt, afprøvet og gennemdokumenteret måde at gøre en branche professionel på.

Og til og med er det billigt.

42
30. november kl. 09:02

Men det der går galt indenfor IT idag er faktisk også simpelt, helt ned til ikke at teste sine nødplaner og reagere på advarsler fra skrivningen af sikkerhedskopier.

Jo, men er det egentlig rootcause ? Du har jo selv stykket (og tak for det btw.) en tidslinje sammen, der viser at man gik fra en dagligdag, hvor der blev lavet DR øvelser, hvor det alt andet end lige ser ud som om, at tingene kørte sådan nogenlunde "by the book". Så i jagten på den egentlige rootcause, er at stille spørgsmålet Hvorfor endnu en gang. Altså hvorfor holdt man op med DR øvelser og slækkede på tingene ? Vi skal dybere ind. Rootcause er i 80%+ af de 'IT relaterede haverier' (for at holde jargon'en) noget der har med især People og sekundært Processes at gøre, det er i det mindste min erfaring.

Selvfølgelig er en ITHK ikke en vidunderløsning der på ingen tid gør den bløde gane fast og fodsved til et ukendt problem, men det er en kendt, afprøvet og gennemdokumenteret måde at gøre en branche professionel på.

Igen det er konsekvens, professionalisme og kold analyse der virker, jeg er igen enig i det du skriver:

systematiske, fakta-drevne tilgang til at forhindre gentagelser, ikke også skulle virke med IT?

Jeg tror bare ikke, at vi er der hvor implementeringen af en IT-Havarikommission vil afstedkomme dette. For når du skriver:

og gennemdokumenteret måde at gøre en branche professionel på.

Så viser det jo at du allerede har draget konklusionen, på hvad problemet er. Det er IT-branchen der er problemet. Og hvorom der i mine øjne ingen tvivl er, at de er 'medskyldige', så forklarer det jo ikke alle de offentlige IT-projekter og initiativer, der fejler hvor det er 100% interne projekter, eller hvor en leverandør faktisk har lavet sit arbejde ordentligt. Offentligheden ser kun toppen af isbjerget.

Så der, hvor jeg mener, vi ikke er er alignede, er at jeg mener ikke at IT-branchens professionalisme er rootcause til det vi ser.

Mit bud er simpelt hen mangel på IT-professionalisme i det offentlige, især i ledelse og politisk. Hovedparten af ledere og ikke IT-funktioner, anser stadig digitalisering, som sådan noget der svarer til at købe kuglepenne. Der er store dele i offentlig ledelse, der synes det er en fordel ikke at forstå IT. Forstået som IT virkeligheden. Med det mener jeg IT folk, IT rammeværk, IT metoder, IT processer og IT. Og IT er sådan en ting, der bider hovedet af folk, hvis man ikke gør det professionelt. Man mangler den fundamentale respekt for IT-fagligheden. Det tragiske er så at det gør man også for mange andre fagligheder, så som sundhedsområdet, børnepasning, skoler mv.

Det er så mit take. Og jeg er sådan rimelig sikker på, at jeg ikke rammer helt forbi.

Hvordan kommer vi så det her til livs...

Jeg mener man må tage tingene seriøst og nedsætte en analyse gruppe, som analysere tingene igennem og kommer med en handlingsplan, som så kan implementeres.

Og .. jeg mener.. som jeg også har sagt.. at en IT-Havarikommission, vil være et relevant punkt på en handlingsplan, altså skal implementeres når niveauet af professionalisme i det offentlige er tilstrækkelig højt. Hvilket IMHO betyder, at man er startet på faktisk at have implementeret og faktisk bruge de Feedback mekanismer, der er til at opsamle viden omkring fejl og derved organisatorisk learning, i stort set alle IT rammeværk. Hvis man starter med en IT-Havarikommission, så bliver den opgave den skal løse næsten umulig, fordi tingene simpelt hen står for galt til. Det kræver et vist niveau af professionalisme, før den kan gøre nytte.

// Jesper

33
28. november kl. 12:38

der til gengæld ikke har et "X-projektråd" der er fyldt med lobbyister fra de leverandører der i stort omfang producerer problemerne.

Mon ikke det er der, hunden ligger begravet? Lobbyistvældet i den danske digitalisering? Det er min frygt med et IT-ministerium: At det bare bliver tech-branchens ambassade i regeringen.

39
29. november kl. 17:37

For god ordens skyld: Rådet skiftede i november 2017 navn fra It-projektrådet til Statens It-råd som følge af 'Strategi for it-styring i staten'.

MEN jeg mener det er forkert formuleret: *fyldt med lobbyister fra de leverandører *

Den autonomi, som findes mellem ministerier og styrelser medfører, at der ikke er nogen form for kontrol eller påbud. Rapporter fra Statens It-råd indeholder "observationer og anbefalinger" og der er ingen magt bag ved - så modtagerne kan gøre hvad de vil - typisk ingen ting (for de ved måske ikke bedre ?).

Iøvrigt gælder samme for Rigsrevisionen - der sker kun måske noget. Og næste gang, 5 år senere, så er der ny minister, så .....

Der er noget galt med hele strukturen, herunder ansvar og konsekvens.

34
28. november kl. 13:49

Mon ikke det er der, hunden ligger begravet?

Der ligger bestemt mindst en hund begravet der.

Men det forandrer ikke på at Skidt Sker og at vi har brug for en ITHK for at få udredt hvorfor det fik de konsekvenser det fik og hvordan vi kan undgå det.

29
25. november kl. 10:28

Jeg kan ikke påstå at være ekspert på området, men det slår mig at du har lidt for mange rodårsager til at de faktisk kan være roden til problemet, hver især. Tværtimod virker de på mig til at være bidragende faktorer der forværrede det dybereliggende problem:

  • Single point of failure for en stor del af NemID.

Uden denne rodårsag havde der ikke været noget nedbrud, og det må vel være netop det der er kendetegnet? Man havde åbenbart antaget at dette system Aldrig™ ville gå ned, hårdt, men det gjorde det så. Hvis man derimod havde erkendt at systemet kunne gå ned ville man nok have indlagt redundans, eller som absolut minimum sørget for en plan som den du efterspørger.

Alt i alt virker det dybt amatøragtigt at have et kritisk system som det tager en uge at gendanne — for det er ret lang tid…

14
24. november kl. 09:40

Tak til PHK, for fin gennemgang og egentlig en nådig omtale af Nets, ift. hvor uansvarligt de driver vores kritiske infrastruktur.

De fleste digitale produkter bliver udviklet i hast og på markedsvilkår, hvor man tit tolererer et hack, for at komme i mål inden for tid og budget. Hvis ikke man ved og accepterer dette, så lever man i en drømmeverden.

Men sådan kan det selvfølgelig ikke være, med hverken rent rindende vand, broer eller kritisk digital infrastruktur.

Med den slags produkter er der krav om langt højere niveau for sikkerhed og driftsikkerhed, som en del opgaven. Både under udvikling og efterfølgende drift.

Da SOS International og Medical Nordic blevet taget I at sløse groft med persondata under Covid 19, var konsekvensen at SOS International mistede deres nyligt vundne milliardordre. Signalet var sendt. Groft sløs medfører propertionale konsekvenser.

Hvad bliver konsekvenserne for Nets? Kan de stadig udbetale udbytte til ejere og bonus til topchefer?

PHKs definition af drift-resilliens er fornuftig. Selvfølgelig kan selv de allerbedste udviklere og administratorer lave store fejl. Og NÅR det sker, så skal det faktuelle niveau af resilliens være således, at alle fejl kan rettes, og alle skader kan udbedres.

Worst case scenario er re-etablering, evt. med et beklageligt datatab fra et "tåleligt" point in time.

Nets fejlede på alle niveauer. Monitorering, Fejlretning, Reetablering.

Det vildeste er nok, at det tager dem så lang tid at "bygge en CRL server fra bunden".

Det betyder, at Nets driver kritisk infrastruktur med komponenter, de ikke selv kan supportere.

Ansvarsløshed i ren form.

25
24. november kl. 20:55

De fleste digitale produkter bliver udviklet i hast og på markedsvilkår, hvor man tit tolererer et hack, for at komme i mål inden for tid og budget. Hvis ikke man ved og accepterer dette, så lever man i en drømmeverden.

Voldsom anklage, som er baseret på dine egne erfaringer? Eller er det "noget, du har hørt?"

30
25. november kl. 11:23

Det er baseret på egne erfaringer.

Men jeg medgiver, at jeg ikke kan bringe evidens for, at det er "De fleste".

De fleste udviklingsforløb jeg har deltaget i eller kendt til, har undervejs afsøgt hvilke mulige løsninger, som opfylder vision, brief eller specs, eller løser en taktisk udfordring.

Derefter vurderes løsninger iforhold til andre elementer i leverancen og iforhold til budget.

Ofte vil en løsning vælges, på trods af en anden mere omfattende, eller på papiret mere korrekt løsning findes.

Nogle gange er sådan en løsning blot "basis" istedet for "luxus", andre gange vil man kalde det et hack.

Bemærk at hack ikke er ensbetydende med inkompetent eller usikkert.

Der er massere af hacks, som er forsvarlige og tilladelige løsninger.

Løsninger som en revision kan kritisere fra en lænestol. Løsninger som introducerer teknisk gæld. Løsninger som tilsidesætter bizarre randtilfælde.

Men forsvarlige hacks.

Og så er der hacks eller valg som ikke er forsvarlige. Som f.eks. tidligere offentlige websites, hvor man authentikerede via et heltal fra en URL parameter.

Hvis man udvikler et atomkraftværk, skal hack-tolerancen være nul eller lav.

Hvis man udvikler Netbank eller Nemid skal hack-tolerancen være lav.

Og endelig kan man tilføje, at der er folk, som på forhånd i tilbudssituationen i hovedet allerede ved på minuttet hvorlang tid den komplette kodebase tager at skrive, uden risiko for indsigter eller overraskelser undervejs i projektet. Og de behøver selvfølgelig aldrig, at forholde sig til, at implementere et hack:)

36
28. november kl. 21:27

tak for at bringe et nuanceret svar. Det tidligere var for bombastisk og lidt for meget selvsving, som til tider rammer kommentarsporene her på siden.

22
24. november kl. 16:24

Fin påmindelse om konsekvenser under Covid19 - helt i tråd med mit indlæg om ansvar og konsekvens.

Det KAN IKKE være et frit gode at fejle i sit professionelle virke !

20
24. november kl. 11:01

Det betyder, at Nets driver kritisk infrastruktur med komponenter, de ikke selv kan supportere.

Det fremgår af rapporten at der er flere dele af installationen som Nets ikke kan håndtere uden hjælp udefra, bla. nævnes restore af backups.

16
24. november kl. 09:58

for fin gennemgang og egentlig en nådig omtale af Nets, ift. hvor uansvarligt de driver vores kritiske infrastruktur.

Jeg vil heller kigge på kundens krav, hvis kunden ikke stiller krav om fx firewall der kan håndtere 10gbit, hvorfor så bruge egne penge på det. Kunden er nød til at stille relevante krav.

IT er ikke vand der kommer ud af vandhanen, IT er meget komplekst.

10
23. november kl. 18:18

Lidt svar på nogle af spørgsmålene fra interview i Politiken nu:

"Har I kigget på standarderne i forhold til MitID? »Ja, det har vi. Det fremgår af kontrakten, at der skal testes ’disaster recovery’ årligt, og det er selvfølgelig noget, vi vil sikre«, fortæller Søren Winge. Det fremgik ikke af kontrakten på NemID? »Overordnet set er der i kontrakten om NemID stillet krav til, at Nets skal efterleve god it-skik og gængse standarder i driften af NemID«. Søren Winge fortæller desuden, at der i kontrakten stilles krav til, at Nets skal efterleve sikkerhedsstandarden ISO27001, hvilket blandt andet indebærer back-up af data, beredskabsplanlægning og disaster recovery tests og flere steder står der, at der skal være beredskab for NemID."https://politiken.dk/forbrugogliv/forbrug/art9093439/Efter-nedbruddet-der-ikke-m%C3%A5tte-ske-Nets-lover-at-MitID-ikke-g%C3%A5r-i-sort

Fra samme:

"MitID adskiller sig fra NemID ved, at man benytter to aktive platforme, som er kopier af hinanden. På den måde vil man kunne skifte til den anden platform, hvis der skulle opstå problemer, forklarer Søren Winge."

(Spørgsmål fra mig: Er det det, der hedder "spejlede diske"? Det har man så åbenbart ikke haft til NemId.)

*"»Vi har igangsat tiltag for at sikre, at alle medarbejdere med systemadgang i forhold til NemID får den fornødne træning, og at der gennemføres kvartalsmæssig kontrol. Vi vil samtidig vurdere, om det også kan være relevant i forhold til eksempelvis MitID«.

Kan det virkeligt være noget, man åbenbart stadig bare tænker over nu 5 måneder efter? Kan der være nogen tvivl om, at det også vil være en god idé ift. MitId?

Så må man jo afgøre med sig selv, om man tror på, at der nu er styr på det. jeg gør ikke. den slendrian, som afspejles i rapporten, forsvinder ikke bare lige - der må skulle en langvarig og svær kulturændring til.

13
23. november kl. 18:49

»Overordnet set er der i kontrakten om NemID stillet krav til, at Nets skal efterleve god it-skik og gængse standarder i driften af NemID«.

Er der mon så ikke basis for et klækkeligt erstatningskrav for kontraktbrud?

15
24. november kl. 09:51

Næ, for hvad er "god it-skik og gængse standarder" ?

God skik er altid en smagssag og gængse standarder kunne være iso27001 som giver mulighed for, at man ingen sikkerhed har, blot at virksomhedens ledelse har været det der har besluttet alle forhold.

17
24. november kl. 10:23

Men er der nogen på denne jord, som - uden at skamrødme - vil kunne påstå, at Nets har overholdt "god it-skik og gængse standarder" ?

Hvem melder sig modigt som kanonføde for den påstand?

18
24. november kl. 10:43

Jeg er sikker på at det vil komme som en grim overraskelse for mange, hvis det bliver slået fast at man faktisk skal teste sin DR plan mindst to gange om

21
24. november kl. 12:48

Kræv at datoerne oplyst i god tid, og ret til at lade en kompetent person overvåge testen, samt ret til ikke at anmelde i forvejen om man deltager...

19
24. november kl. 11:01

Men ere det den eneste forsømmelse i din beretning om forløbet, PHK? Jeg læser det som en lang liste...

11
23. november kl. 18:33

Kan det virkeligt være noget, man åbenbart stadig bare tænker over nu 5 måneder efter?

Og hvorledes skal man tolke at Nets', stort set samme dag som Henrik Molkte fik dokumenterne udleveret, meldte ud at de ville sælge MitID/NemID fra ?

12
23. november kl. 18:39

Og hvorledes skal man tolke at Nets', stort set samme dag som Henrik Molkte fik dokumenterne udleveret, meldte ud at de ville sælge MitID/NemID fra ?

Ja, det er lidt foruroligende...

26
24. november kl. 23:43

Det passer nogenlunde med hvornår DigSt har indset at de ikke kunne afslå aktindsigt.

9
23. november kl. 17:51

Helt enig PHK! IT-Havarikommission nu!

#dkithavarikommission

8
23. november kl. 14:26

Hm ja, når man nu ser på sammensætningen af digitaliseringsstyrelsen, så vil en IT havari kommission vel bestå af direktøren for KPMG eller PwC som formand. Man er jo nødt til at have en vis rygdækning for det stakkels "revisionsfirma" der har lagt ryg til Nets ISAE3402. Som bla. skal afdække A.17 Informationssikkerhedsaspekter ved nød-, beredskabs- og reetableringsstyring.

38
29. november kl. 08:44

Ja man griner jo men det kan da ende sådan... Det er jo sørgeligt når man f.eks indenfor IT-sikkerhed i de "kritiske sektorer" prøve at samarbejde og udveksle erfaringer... men når det gælder det offentlige IT - så bliver der udarbejde x antal rapport af PwC & co. - lavet et udbuds materiale på x antal 1000 sider som formodentlig stritter ud til alle sider med krav og ønsker. Dem som byder ved godt at det ikke kan virke, men ekstra opgaven for at få det til at virke lidt - er attraktiv nok $$$$.... men sådan er det nok når det er "other peoples money". Helt enig med PHK! IT-Havarikommission nu!

6
23. november kl. 13:09

Du er nok for optimistisk at give det overskriften 2/2. 2/2++ er nok mere korrekt.

3
23. november kl. 12:28

Denne skræmmer mig mere end noget andet:

Den tilsyneladende udbredte antagelse at advarsler man ikke genkender ikke er vigtige

Specielt hvis det er advarsler der pludselig dukker op efter at nogen har gjort noget.

7
23. november kl. 13:29

Specielt hvis det er advarsler der pludselig dukker op efter at nogen har gjort noget.

Det skal retfærdigvis siges at mainframes plaprer løs.

Det positive ved det er så at det var muligt at gå et halvt år tilbage i konsolloggen og finde ud af at nogen havde flyttet en VM, der er ingen PC platforme der når en IBM mainframe til sandalerne når det handler om logning og traceability.

2
23. november kl. 12:24

Prøver igen:

Jeg ved jo ikke, om der er søgt aktindsigt i kontrakten, men min erfaring er, at den slags ofte afvises med "konkurrencehensyn", men hvad med udbudsmaterialet? Det kan vel ikke mørklægges? Bør diverse krav fra digst ikke fremgå der?

1
23. november kl. 12:21

Man sidder jo tilbage med et indtryk af, at "rapporten" nok mest henhører under "ikke-rapport".

" Hvad står der om DR test i konktrakten mellem DigSt og Nets ? .... Har "omkostningsbevidsthed" hos DigSt ført til slækkede krav ?"

Jeg ved jo ikke, om der er søgt aktindsigt i kontrakten, men min erfaring er, at den slags ofte afvises  med "konkurrencehensyn". Men hvad med udbudsmaterialet? Det kan vel ikke mørklægges? Bør det ikke fremgå der, hvilke krav digst har stillet til sikkerhed, testfrekvens o.l.?

	
	Beklager mærkelig formattering...
4
23. november kl. 12:30

Der kan stå meget i udbudsmaterialet, og det er i sagens natur offentligt.

Men mange kloge tanker finder ikke vej til det kontraherede produkt, og forklaringerne på det kan sagtens være højt klassificerede