Morten Fordsmand

Netcompany: Mit.dk-nedbrud skyldtes menneskelig fejl

Menneskelige fejl findes de overhovedet.

Jeg arbejdede en gang i en større IT-drift virksomhed hvor chefen for den danske afdeling fremført at der ikke fandtes menneskelige fejl, men derimod utilstrækkelige processer.

Lidt lang ude måske, men jo bedre en virksomhed har styr på sine processer jo færre menneskelige fejl når frem til at brugerne opdager dem.

24. marts kl. 11:10
Microsoft forsikrer om lovlige produkter, efter Stockholm dropper 365

Er jo at det det er afhængigt af at blive driftet helt eller delvist i Azure skyen.

Og der er Microsoft leverandør og underlagt de USAnske lovgivning, der som bekendt gælder for alt virksomhedens aktiviteter overalt i verden.

26. januar kl. 12:42
It-kriminalitet stikker af fra politiet: Justitsministeren overvejer yderligere tiltag

Måske ville det forøge læsbarheden af denne artikel, hvis der var indsigt i hvordan en anmeldelse Klacificeres som IT-kriminaltitet?

Omfatter det f.eks.

  • deling af ulovligt indhold?
  • priatkopiering af indhold?
  • bondefangeri på dba.dk?
  • misbrug af IT-systemer til personlig berigelse (Britta Nielsen)
  • misbrug af nem-id
  • Nigeria-mails
  • overtrædelse af racismelovgivning på facebook

eller hvad?

10. januar kl. 11:55
Hverken Digitaliseringsstyrelsen eller CfCS har et samlet billede af it-sikkerheden i kommuner og regioner

Men Datatilsynet har i det mindste en idé om det - de har bare ikke ressoucer til at gøre noget ved det hele.

Joe men datatilsynet har jo kun fokus på persondataforordningen og ikke hele risikobilledet.

Men som der bliver gjort opmærksom på så ligger ansvaret jo hos kommunerne selv, så man bnurde nok nærmere have spurgt indenrigsministeren, der jo er ansvarlig for tilsynet med kommuner (og regioner?)

Og her er det nok mere interessant at måle modenheden i de enkelte kommuner (altså er der en organisatorisk forandring, politik, awareness, risikovurdering, trusselkatatalog og og) I stedet for at kigge på antallet af indberetninger.

3. januar kl. 11:08
Sluk for pokker!

Sejt. Det vidste jeg ikke at man kunne :)

Vent du bare til de besiddelsesløse overtager produktionsmidlerne

6. oktober 2021 kl. 15:51
Sluk for pokker!

Der vil stadig være problemer der rammer i rigtig drift og så må man løbende forsøge at inkorporere tests og procedurer der giver værdi ifht. at imødegå at fejl gentager sig, uden at de bliver så tunge så ingen faktisk anvender dem :)

Enig, man skal bare sørge for at være klar over hvad begrænsningerne i ens testprogram er, og huske at fortælle det til sine kunder.

Minder mig i øvrigt om nogen, der havde et HACMP/AIX cluster kørende hen over to datacentre. Når de skulle patche lukkede de applikation og database ned på den ene side og verificerede at det flyttede pænt over på B-siden og at applikationen kørte, så pathced de A-siden med nødvendige boots. Flyttede applikation og database tilbage til A-siden og patchede B-siden. Problemet var selvfølgelig bare at der var forskel på etc\services mellem A og B, så da man en dag afprøvede det virkede applikationen ikke helt som man havde forestillet sig :(

6. oktober 2021 kl. 12:37
Sluk for pokker!

Er nettogevinsten på makroskala positiv, ved at skulle sørge for hænder nok til t_crash og gennemføre det store årlige reboot?

Problemet er her at markedskræfterne er sat ud af spil.

Vi taler (endnu) om ganske lave sandsynligheder for katastrofale udfald, kombineret med potentielt altødelæggende konsekvenser for forretningen, og det er noget som ikke håndteres godt af normal risk management.

Derudover er det nok ikke alle organisationer, der har tid til at rette vedkommende melder sig på "markedet"

6. oktober 2021 kl. 12:19
Sluk for pokker!

er efter min mening super vigtigt og bedst at lave som en "recovery test som almindelig drift".

Det er da en udemærket test men den er bestemt ikke fyldestgørende på alle dimmensioner:

  1. I afprøver planlagt failover, hvilket ikke er det samme som at strømmen går i datacentret, da det vil påvirke diverse "cluster services" til at agere anderledes.
  2. I afprøver ikke hele datacentrets infrastruktur altså slukker switche fjerner infrastruktur services (DNS, AD,......)?

Men jeres test beviser dog at den enkelte service kan køre fra begge centre, hvilket er en god start.

6. oktober 2021 kl. 12:08
Sluk for pokker!

For lidt over 6 år siden var noget dansk kritisk infrastruktur ramt af et relativt langt nedbrud.

Nu er det at finde en root cause jo altid en lidt filosofisk diskusion, men et væsentligt led på kæden var at noget netværksudstyr efter nogle års drift ikke kunne tåle at blive slukket og tændt igen, og i dette tilfælde gjaldt det så for alle fire interfacekort.

6. oktober 2021 kl. 08:32
Sluk for pokker!

Det er lidt kostbart, det vil være ideelt hvis man kunne skaffe et identisk sæt hardware, servere, diske, switche der er ukonfigueret. Og så starte alt op fra backupen fra igår.

Problemet er så hvordan du vil teste over for resten af verden herunder dine brugere?

Problemet er at for at lave en perfekt afprøvning skal du bruge et parallelt univers.

(måske kan man klare sig med en jord version 2, som man vel kan bestille på Magrathea)

6. oktober 2021 kl. 07:15
Sluk for pokker!

Hvis man vil være sikker på at det hele hænger sammen er det en god ide at lukke sine datacentre.

Det er væsentligt nemmere at teste de enkelte dele , men jeg tror faktisk at dyrere hvis man vil hele raden rundt. Lige som at man ofte ikke finder afhængigheder mellem flere systemer, der forventes at arbejde sammen,

Jeg har deltaget i et par testprogrammer, hvor man har arbejdet frem i mod at kunne lave den slags tests med fokus på datacentrene (jeg er trods alt en D/R mand) Men da de samlede øvelser kan blive ret omfangsrige (100 + personer på arbejde midt om natten) er det ofte svært at få backing og funding - surt men sandt.

Der hvor jeg ser problemet er at identificere hvilke scenarier man vil afprøve fordi de vil følge vidt forskellige opretningsprocedurer, hvorfor en afprøvning skla designes forskelligt, nogen af de scenarier jeg kunne forestille mig er:

  1. kold opstart af et eller flere forbundne systemer (som PHKs eksempler)
  2. Tab af datacenter, hva enten det skyldes strømfejl, oversvømmelse, brand eller ildspårudlende drager.
  3. Massiv data korrumpering på tværs af systemer

Bemærk at jeg ikke nævner noget om specifikke risici men fokuserer på konsekvensen.

5. oktober 2021 kl. 12:55
2021: Spættens År

I udvalgte brancher (finans, energi, etc.) omkring kontrollen med vores IT systemers robusthed.
Lige som revisorer har arbejdet med systemrevision næsten så længe som jeg husker.

Om det så virker godt nok er nok et helt andet spørgsmål, i hvert fald er de utallige synlige brud på it-sikkerhed ikke beroligende.

Om der er brug for en autorisation er derimod nok ikke en god ide, da der allerede findes utrolig mange akronymer, der skulle underbygge at folk kan holde styr på tingene.

4. oktober 2021 kl. 11:11
Datamuseum: Habemus Papam!

Fået Michael Ø som formand, det tror jeg vil blive godt. (jeg har kendt ham rigtigt mange år)

30. september 2021 kl. 11:17
Én gang til: Statsrevisorerne med sønderlemmende kritik af it-beredskabet i skattevæsenet

ikke så sikker på at det her kun halter hos SKAT.

Et grundvilkår for IT-beredskab er at det nemt bliver glemt, overset eller fortrængt i den daglige kamp om resourcer

Jeg skal ikke gøre mig til dommer over om hvorvidt det er rigtigt eller forkert, men sådan er det almindeligvis.

Det er selvfølgeligt heller ikke blevet nemmere med store destruktive malware attacks, der stiller helt andre krav til de tekniske løsninger i forhold til det trusselbillede man tidligere så. (tab af infrastruktur pga. force majeur etc.)

Men hvis SKAT vil rydde op i det her taler vi nemt om et coreteam på 2-4 mand, og et træk ude i organisationen på mellem 4 og 10 FTE spredt ud over de enkelte systemer. Hvad der deudover skal bruges på investeringer i spejling, backup etc tør jeg ikke gætte på.

18. september 2021 kl. 09:24
Forsinket EFI-afløser trækker nu 40.000 borgere i løn

En meget velskreven artikel om manglende ITberedskab men den har jo ikke så meget med denne artiklels emne at gøre, ud ovewr at begge dele foregår i skats mørke

øvrigt kan det også læses her https://rigsrevisionen.dk/revisionssager-arkiv/2021/sep/beretning-om-skatteministeriets-it-beredskab

17. september 2021 kl. 14:44
Medie: To ud af tre Microsoft-datacentre opføres i Faxe og Slagelse

man skal lede efter det 3. center i holbæk/roskilde området.

8. september 2021 kl. 11:33
Fyret medarbejder i amerikansk kreditforening ødelægger 21 gigabyte data som hævn

De burde selvfølgelig have lukket for adgang, men de har vel en backup hvis det er så vigtig data, det burde da ikke tage mange minutter at genskabe.

Hvornår har du prøvet at restore 20.000 filer?

Det er ikke noget man lægger mærke til i hverdagen, men de fleste filsystemer tager sig et pænt stykke tid til at lave en ny fil, så alene det at lave filerne kan tage adskillige timer.

Derudover skal vil lige læse data fra hvor mange bånd, der alle skal mountes og spoles og ...

Så bare et øjeblik er nok alligevel ret optimistisk.

8. september 2021 kl. 11:08
Seks timer langt AWS-nedbrud ramte banker og betalingssystemer

Der havde et multiregions setup?

Det skyldtes 'the loss of several core networking devices that are used to connect Direct Connect network traffic to all Availability Zones in the AP-NORTHEAST-1 Region,' som AWS efterfølgende skrev i en pressemeddelelse, da problemet var løst og servicen igen i funktion.

Det viser bare igen-igen-igen at det ikke bare bliver ved med at køre bare fordi det er i skyen

3. september 2021 kl. 14:25
Skiftet fra NemID til MitID er nu i fuld gang

Det ser ud til at løsningen med donglen bliver videreført:

Og der kommer vist også noget for mere for dem med funktionsnedsættelser

Man kan se løsningerne her https://www.mitid.dk/kom-i-gang-med-mitid/mitid-identifikationsmidler/

18. august 2021 kl. 14:22