Er Bane NOR hacket av en fremmed stat?

[obygda]

Femtekolonne skrev (49 minutter siden):

Jeg skylder på Kim, Putin og Trump. I den rekkefølgen.

Putin,Xi og Trump...Kim får ikke til noe

Men jeg tror egentlig feilen er inkompetanse i egen organisasjon...

[flamethower1234]

[arne22]

8 hours ago, Jalla21 said:

Dette er hva de selv sier:

– Vi har lokalisert hvor feilen ligger i vår egen landsdekkende IT-infrastruktur, og vi jobber nå med en løsning for å utbedre feilen.  Vi har ennå ikke utbedret rotårsaken, men gjort tiltak slik at den delen av nettverket hvor feilen lå, er isolert fra resten av infrastrukturen, sier Arild Nybrodahl. 

 Vi mener rotårsaken er knyttet til feil på brannmur som sikrer den digitale infrastrukturen. Dette jobber vi nå sammen med leverandør for å løse. Det er ingen indikasjoner på at feilen som har oppstått, skyldes sabotasje eller ytre påvirkning.

https://www.banenor.no/nyheter-og-aktuelt/nyheter/2024/togene-kjorer-igjen-etter-kommunikasjonsfeil/

 

Det gir på nåværende tidspunkt ingen mening å snakke om sabotasje eller ytre påvirkning.

De fleste av oss har vel opplevd togforsinkelser mange ganger tidligere på grunn av at "togenes signalanlegg er nede" eller "systemet for kommunikasjon med togsettene virker ikke". Hvor mange ganger har man ikke hørt dette?

Vanligvis så blir det jo rapportert innenfor de miljøene som jobber med IT sikkerhet, når samfunnskritisk struktur går ned som følge av hackerangrep, og jeg kan i alle fall ikke huske å ha lest noen rapport om at de mange feilene hos Bane Nord har hatt en slik årsak. Hvis man tidligere har hatt et forholdsvis stort antall "selvforskyldte feil" på grunn av at man ikke har tilstrekkelig god nok kontroll på den tekniske driften, så må det vel i utgangspunktet være mest sannsynlig at hendelsen føyer seg pent inn i rekken av selvforskyldte hendelser.  ("Selvforskyldt" i den betydning at man ikke har valgt tekniske løsninger som er tilstrekkelig robuste og pålitelige nok.)

Et argument for at denne hendelsen ikke skyldes et målrettet hacker angrep, det er jo graden av dybde i angrepet og ødeleggelse. Skadene blir jo beskrevet som minimale og nærmest som litt "sand i maskineriet", slik at man for sikkerhets skyld valgte å stenge ned anlegget. Når hackergruppene går til angrep, og jobber slik som de "normalt" pleier å gjøre det, så ser man jo langt mer omfattende ødeleggelser, enn det som finnes i dette tilfellet hos Bane Nord. Eksempel.

En annen mulig årsak er jo at man har fått et varsel i fra et integrert Intrusion Detection System, på at et angrep kan være i sin tidlige fase og under mulig utvikling, slik at man da ut i fra egen vurdering og som et sikkerhetstiltak velger å stenge ned. 

Hvis man kobler en brannmur eller en server opp mot Internett, så vil jo det normale være at man alltid vil bli angrepet, ettersom Internett inneholder mange automatiske systemer for utførelse av slike angrep. Det tar noen minutter, og så er angrepene i gang, og etter et lite døgn, så har man gjerne loggført tusenvis av angrep, hvis man har logg. At et IDS kan reagere på noe av "den normale angrepstrafikken" slik at man av den grunn velger å stenge ned, det er jo også en mulighet. Det kan man jo også betrakte som en slags "teknisk feil" eller "mangel på robusthet". 

Endret 28. desember 2024 av arne22

[freedomseeker]

trn100 skrev (9 timer siden):

Det åpenbare problemet her er jo at norsk jernbane er privatisert og alt ansvar er pulverisert av markedskrefter som i første omgang FrP og Høyre ser på som fremtiden. Det samme gjelder EL til tross for at FrP nå har ombestemt seg og forandret mening som de også gjorde etter at Volvo heldigvis takket nei til tilbudet om å overta norsk oljeproduksjon for 50% av aksjene i Volvo...

I 1978 inngikk daværende Volvo-sjef Pehr G. Gyllenhammar og Norges daværende statsminister Odvar Nordli(AP) en intensjonsavtale om at Norge skulle kjøpe 40 prosent av Volvo-konsernet for 750 millioner kroner, mot at Volvo skulle få andeler (lisenser) til oljefelt på norsk sokkel.

Olof Palme, Thorbjörn Fälldin, Gro Harlem Brundtland og Reiulf Steen stilte seg positive til prosjektet, men i Norge var den borgerlige motstanden stor. At Volvo-avtalen ikke ble noe av, var et hardt slag for statsminister Nordli og hans regjering, og for Ap som helhet.

Endret 28. desember 2024 av freedomseeker

[arne22]

10 hours ago, trn100 said:

Det åpenbare problemet her er jo at norsk jernbane er privatisert og alt ansvar er pulverisert av markedskrefter som i første omgang FrP og Høyre ser på som fremtiden.

Det spørs om det i dette tilfellet forholder seg akkurat motsatt, for Bane Nord som er et statlig foretak. Man har å gjøre med et offentlig byråkrati, der alle har ansvaret for alt, ingen har oversikt, og ingen har fullmakt til å ta ansvaret. Så løser man problemet med å gjennomføre flekkvise løsninger basert på outsourcing til private, slik at det sikkerhetsmessige helhetsbildet forsvinner ut i en tåkeheim av byråkrati og kontraktsbaserte løsninger. Så blir det til sist en normaltilstand at kommunikasjonssystemene for togene er nede. 

Endret 28. desember 2024 av arne22

[flamethower1234]

https://www.vg.no/nyheter/i/63KjeL/togstans-paa-bergensbanen-tog-med-rundt-100-passasjerer-uten-stroem

[arne22]

Samferdsministeren sier vel at han har full tillit til at BaneNord ledes på en god og forsvarlig måte, samtidig så sier han jo da også at han har full tillitt til egen evne til å bedømme hvor feilene sannsynligvis ligger.

Det som er typisk for de "rødgrønne" det er jo at de plasserer personer helt uten relevant fagkompetanse i ledelsen av tunge krevende departementer, slik at de politikerne man har satt til oppgaven for ens stor del ikke har en kombinasjon og utdanning og yrkespraksis som medfører at de har en relevant fagbakgrunn for å kunne klare oppgaven på en forsvarlig måte.

Denne samferdsministeren ser jo ikke ut til å ha noen som helst bakgrunn innenfor teknologi, IKT, eller samferdsel. Til tross for det, så skal han ikke ha noe problemer med å bedømme driftsproblemene innenfor BaneNord.

Når det gjelder en annen kjent rødgrønn luring, finansministeren, så har jo vedkommende ingen som helt utdanning eller yrkespraksis innenfor økonomi, men han skal allikevel være landets øverste økonomiske leder. Hvordan skulle dette ha muligheten til å gå bra?

Men finansministeren har i hvert fall lagt ut sin CV:

https://www.regjeringen.no/no/dep/fin/org/finansminister-trygve-magnus-slagsvold-vedum/id2877301/

Når det gjelder samferdsministeren, så kan det se ut som at han ikke har lagt ut noen CV hos regjeringen.no

Ingen relevant bakgrunn kan det se ut som, men når man har gått gradene fra AUF og over i Arbeiderpartiet og fått mange gode venner så kan man bli tildelt en ministerpost av sine gode kamerater i Arbeiderpartiet. 

https://www.regjeringen.no/no/dep/sd/org/samferdselsminister-jon-ivar-nygard/id2877331/

https://www.arbeiderpartiet.no/politikere/jon-ivar-nygard/   

Hvis man setter inn personer, ikke basert på kompetanse, men på den type kameraderi som kjennetegner de offentlige ansatte akademikernes parti, det såkalte "Arbeiderpartiet", hvordan skulle man da kunne få noe annet enn et stort offentlig byråkrati det problemene kan saktens kan diskuteres, men kanskje ikke så lett bli løst.

Enten man kaller seg offentlig eller privat, høyre eller venstre, og tilhenger av den ene eller den annen politiske ideologi, må ikke det viktigste uansett være at man faktisk har den fagkompetansen som er nødvendig for å forstå og løse de problemene man skal løse?    

Endret 2. januar av arne22

[arne22]

Der var det visst slått fast at det bare dreide seg om et ganske vanlig teknisk driftsproblem, som har oppstått uten hjelp i fra fremmede stater eller andre.

https://www.vg.no/nyheter/i/lwbL69/bane-nor-sjefen-om-julekaoset-en-hardwarefeil-foerte-til-kommunikasjonssvikten

Det man jo har fortalt til de fremmede statene, det er jo at man har et system uten nødvendige bacupfunksjoner og der et enkelt "single point of failure" kan sette togtrafikken i hele landet ut av spill. Samtidig så er det ingen som er ansvarlig for en slik designfeil.

Alternativet ville jo være å bygge opp et robust system, som tåler flere samtidige feil, uten at systemet som helhet faller ut av den grunn. - Hva er grunnen til at man ikke skal ha det? 

[Salvesen.]

arne22 skrev (10 minutter siden):

Der var det visst slått fast at det bare dreide seg om et ganske vanlig teknisk driftsproblem, som har oppstått uten hjelp i fra fremmede stater eller andre.

https://www.vg.no/nyheter/i/lwbL69/bane-nor-sjefen-om-julekaoset-en-hardwarefeil-foerte-til-kommunikasjonssvikten

Det man jo har fortalt til de fremmede statene, det er jo at man har et system uten nødvendige bacupfunksjoner og der et enkelt "single point of failure" kan sette togtrafikken i hele landet ut av spill. Samtidig så er det ingen som er ansvarlig for en slik designfeil.

Alternativet ville jo være å bygge opp et robust system, som tåler flere samtidige feil, uten at systemet som helhet faller ut av den grunn. - Hva er grunnen til at man ikke skal ha det? 

At det oppstår hardware feil er jo helt normalt, opplever det daglig i mitt arbeid. 

Men at det tar "døgn" å finne ut av samt å fikse/erstatte er enormt kritikkverdig. Iallefall for så kritisk infrastruktur. Helst skal det skje automagisk.

At det fortsatt ser ut til å fortsette som normalt uten store endringer i staben er enda mer kritikkverdig spør du meg.

[Jalla21]

Det virker som flere av ekspertene her bør kontakte Bane Nor med sine overlegne kunnskaper rundt feil, feilhåndtering og  redundans osv i nettverk og brannmurer.

Noen ganger så er ikke det å finne årsaken så enkel, og det virker som dette var et slikt tilfelle.

Fra Digi.no.

– På det tidspunktet da feilen oppsto, var det ingen indikasjoner på hvor feilen lå i infrastrukturen, og brannmurløsningen hadde ingen indikasjon på problemer, forteller Kirkhusmo.

– Brannmuren selv oppfattet at den prosesserte og behandlet trafikk, men den trafikken kom ikke ut av brannmurens fysiske nettverksporter. Dette tydet på at feilen var oppstått i maskinvaren på den ene brannmurnoden.

For å løse problemet, ble noden isolert/slått av, og normal tjenestekvalitet ble gjenopprettet, dog uten fullverdig redundans, får Digi oppgitt.

Bane Nor tok i bruk en annen brannmur enn den som hadde sviktet fra 2. juledag.

Gjennom hele julehøytiden har de hatt folk på jobb, som sammen med leverandøren analyserte rotårsaken, for å finne ut hvordan de kan hindre at en slik hendelse kan skje igjen. 

– De har også rettet feilen og byttet en komponent i vår maskinvare, lyder et av flere svar til Digi via pressevakten til Bane Nor.

Ny maskinvare ble installert i infrastrukturen i løpet av natten den 30. desember.

– Det vil bli foretatt videre analyser av den feilede enheten sammen med produsent for endelig konklusjon omkring rotårsaken til problemet, skriver Anne Kirkshusmo i en e-post til Digi tirsdag 7. januar.

https://www.digi.no/artikler/togkaoset-har-pavist-utstyrsfeil-i-indre-brannmurlosning/554454

[arne22]

5 hours ago, Jalla21 said:

Det virker som flere av ekspertene her bør kontakte Bane Nor med sine overlegne kunnskaper rundt feil, feilhåndtering og  redundans osv i nettverk og brannmurer.

Tviler på at det fungerer helt slik med hensyn til tideling og kontrakter i forhold til den offentlige forvaltningen, at det bare er å melde seg på med bedre løsninger. De som sitter i stillingene og på kontraktene vil nok holde godt på sitt, og det er nok der problemet ligger. 

Endret i går, 02:14 av arne22

[uname -i]

Jalla21 skrev (11 timer siden):

Det virker som flere av ekspertene her bør kontakte Bane Nor med sine overlegne kunnskaper rundt feil, feilhåndtering og  redundans osv i nettverk og brannmurer.

Hvordan kunne det ta Bane Nors "eksperter" mange timer å finne ut at trafikken stoppet opp i en brannmur?

 

Sitat

For å løse problemet, ble noden isolert/slått av, og normal tjenestekvalitet ble gjenopprettet, dog uten fullverdig redundans, får Digi oppgitt.

Bane Nor tok i bruk en annen brannmur enn den som hadde sviktet fra 2. juledag.

Så de hadde altså en HA-løsning og det tok 13 timer å aktivere den?

Ser at Bane NORs forsvarere sarkastisk snakker om "eksperter" her, men man trenger ikke være ekspert for å observere at Bane NORs tjenestekvalitet er begredelig og at det går i feil retning(2024 med ny bunnrekord).

[Kahuna]

uname -i skrev (8 minutter siden):

Så de hadde altså en HA-løsning og det tok 13 timer å aktivere den?

Redundans er vanskelig å få til riktig og nesten umulig å teste 100%. Det er fullt mulig å gjøre alt 'riktig' på forhånd og likevel gå skikkelig på trynet. Det kanskje mest typiske er at reserveløsningen aldri tar over fordi hovedløsningen feiler på en måte som ikke trigger failover.

Hva denne saken angår har jeg ikke sett eller hørt noe ennå som kan si om Banenor har gjort en dårlig jobb eller om de bare har vært veldig uheldige.

[uname -i]

Kahuna skrev (5 minutter siden):

Redundans er vanskelig å få til riktig og nesten umulig å teste 100%. Det er fullt mulig å gjøre alt 'riktig' på forhånd og likevel gå skikkelig på trynet. Det kanskje mest typiske er at reserveløsningen aldri tar over fordi hovedløsningen feiler på en måte som ikke trigger failover.

Teste at redundansen virker er enkelt(om de gidder da) . Men hvis det er en auto-failover så kan det jo være som du sier at det er i en halvveis tilstand slik at det ikke skjer automatisk. Men det stod at samtlige nettverksporter ikke klarte å sende trafikk pga hw-feil. Skulle tro at det var nok til en failover eller hvertfall at en eller annen form for monitorering fant ut at den brannmuren ikke lenger virket og at de slapp å bruke halve dagen på å finne ut at det var den det var noe galt med.

 

Kahuna skrev (8 minutter siden):

Hva denne saken angår har jeg ikke sett eller hørt noe ennå som kan si om Banenor har gjort en dårlig jobb eller om de bare har vært veldig uheldige.

De kan selvfølgelig ha vært veldig uheldige i dette tilfellet, men de omtrent daglige utfallene av Bane NORs infrastruktur tyder på at det generelt er noe annet enn uflaks. For eksempel en ræva kultur.

[The Avatar]

Her hadde vel einaste quick-fixen vært å ha dobbelt opp med all hardware liggande ferdig oppsatt? Å finne ein hardwarefeil når all softwaren indikerer at alt fungerer som det skal er ingen lett oppgåve.

Som alt mogleg anna så koker det nok ned til økonomi. Både kostnaden ved å ha dobbel eller trippelt opp av alt teknisk utstyr, men også kostnaden ved å kalle inn meir folk til å jobbe på 1 juledag.
At dette skjedde 1 juledag var nok både heldig og uheldig. Uheldig fordi det nok ikkje var fleire på jobb enn absolutt nødvendig men samtidig heldig fordi det var eit relativt lite antall passasjerar som vart akutt råka. 
Eg vil nok gjette på at ein her håpa på at problemet skulle løyse seg raskt utan behov for stor arbeidsinnsats, og at ein derfor ikkje kalla inn alle tilgjengelege ressursar for å løyse problemet så raskt som råd. Om det hadde hasta nok så kunne ein nok ha kalla folk tilbake frå juleferiane sine med dei kostnadane det medfører. Det var nok sikkert vurdert og konkludert at det var billegare å tilby passasjerane buss/taxi.

 

Ser i artikkelen i TU at det der står at det vistnok var tre grunnar til at all togtransport vart stoppa og at ein ikkje tok i bruk reservesystemet.
1. Sidan dette var ein ukjent feil, så kunne ein ikkje utelukke datangrep eller at det kunne oppstå nye følgefeil.
2. At ved å la toga gå som normalt så var det også høg risiko for at togsett kunne bli ståande fast på ugunstige plassar 1 juledag.
3. At med vanleg trafikk langs togskinnene så ville det ta lengre tid å identifisere feilen.

Dette er forsåvidt ei plausibel forklaring på kvifor ein var så overforsiktige og stoppa all trafikk til tross for reservesystem.

[Kahuna]

uname -i skrev (5 minutter siden):

Teste at redundansen virker er enkelt(om de gidder da) . Men hvis det er en auto-failover så kan det jo være som du sier at det er i en halvveis tilstand slik at det ikke skjer automatisk. Men det stod at samtlige nettverksporter ikke klarte å sende trafikk pga hw-feil. Skulle tro at det var nok til en failover eller hvertfall at en eller annen form for monitorering fant ut at den brannmuren ikke lenger virket og at de slapp å bruke halve dagen på å finne ut at det var den det var noe galt med.

Disse halvveis-tilstandene kan være vanskelig å detektere og kanskje enda vanskeligere å simulere i en test.

Det virker her som komponenten med feil mente selv alt var ok og da øker du vanskelighetsgrad(og tidsbruk) for å finne feilen.

[Kahuna]

The Avatar skrev (6 minutter siden):

Her hadde vel einaste quick-fixen vært å ha dobbelt opp med all hardware liggande ferdig oppsatt?

Hvilken versjon av software vil du ha på reserveløsningen som ligger i skapet?

 

[Salvesen.]

Kahuna skrev (10 minutter siden):

Hvilken versjon av software vil du ha på reserveløsningen som ligger i skapet?

 

Med rett prosesser er dette problemfritt. Når en oppdaterer main så oppdaterer en spare. Helt normalt.

Å ha ekstra hardware er minimum, å ha automagiske løsninger for changeover er fint å ha, men dekke ikke nødvendigvis alle tilstander. Så da går en over til feilsøking og manuelle prosesser. 

[uname -i]

Kahuna skrev (16 minutter siden):

Disse halvveis-tilstandene kan være vanskelig å detektere og kanskje enda vanskeligere å simulere i en test.

Det virker her som komponenten med feil mente selv alt var ok og da øker du vanskelighetsgrad(og tidsbruk) for å finne feilen.

I følge Digi så tok brannmuren i mot inngående trafikk, men klarte ikke å sende ut på noen av portene. Det bør ikke ta halve dagen å finne ut at problemet lå i brannmuren. 

Sitat

Det virker her som komponenten med feil mente selv alt var ok og da øker du vanskelighetsgrad(og tidsbruk) for å finne feilen.

Dette er jo enda mer merkelig. Hadde det vært en konfig-feil så ville det vært naturlig at brannmuren ikke reagerte på at noe var galt(jeg gjør bare som du ba meg om), men det er rart at en HW-feil bare rammer utgående trafikk og ikke inngående og enda mer snodig at ikke brannmuren selv reagerer på en katastrofal HW-feil, men melder at alt er grønt.

Får vi vite hvem som er leverandør av brannmuren?

Endret i går, 09:48 av uname -i

[sk0yern]

The Avatar skrev (29 minutter siden):

Her hadde vel einaste quick-fixen vært å ha dobbelt opp med all hardware liggande ferdig oppsatt? Å finne ein hardwarefeil når all softwaren indikerer at alt fungerer som det skal er ingen lett oppgåve.

Virker som de hadde et oppsett med en brannmurcluster som står i Active-Passive, noe som er en ganske standard løsning.
Hele problemet her var nok at det tok tid før de forstod de måtte gjøre a fail-over til passiv node.
Da hjelper det lite å ha dobbelt så mye hardware.