Vil IPv6 være egnet for bruk i Industrielle Kontrollnettverk?

[arne22]

On 6/16/2023 at 4:22 AM, nightowl said:

Tviler på at @arne22 klarer å noensinne konkret beskrive problemet han mener eksisterer ..

Det spørs om det er god bruk av tid å diskutere problemer som er løst. Første trinn i en saksutredning er jo å poste saken på diskusjon.no og etter hvert så går det videre på andre fora.

Eksempel: Man etterlyser synspunkter på regelverk. Så kommer det fram uike synspunkter på diskusjon.no Etter en innledende diskujson så tar man saken opp med relevante tilsynsmyndigheter og får en tolkning i regi av tilsynsmyndighetens jurist av hvordan man anvender og tolker regelverket. Så poster man svaret på diskusjon.nå og så får man beskjed om at tilsynsmyndighetens tolkning er helt feil og at man skal forsvare tilsynsmyndighetens lovtolkning. Det er jo ikke en effektiv bruk av tid. En tolkning i regi av tilsynsmyndighetene vil i min verden være en tolkning som kan brukes.

Tilsvarende så legger man fram svarene fra de ulike faginstanser i forhold IT sikkerhet, og så får man beskjed om at de svarene også er feil, og at man skal forsvare de vurderingene også. Avhengig av hvilke faginstanser dette er, så kan det jo være OK å ikke bruke mer tid på problemstillingen. Man diskuterer jo ikke for å diskutere, det synes jeg at man bør unngå, i alle fall hvis man har bruk for en fungerende løsning.

Jeg synes at det er en helt grei måte å jobbe på at man først forhører seg med venner og bekjente og diskusjon.no, og så er det fornuftig å videreføre diskusjonen i forhold til fagmyndigheter og andre relevante fagmiljøer, og så er saken løst.

For meg så er det egentlig en god nok løsning når alle de leverandørene jeg har vært i kontakt med melder at de bere benytter IPv4 i sine produkter. Resten kan jo være en spekulasjon om hva som eventuelt kommer i framtiden, men jeg synes nok at det er en god nok konklusjon i forhold til den problesmtillingen også.

 

 

 

Endret 18. juni 2023 av arne22

[barfoo]

41 minutes ago, arne22 said:

Det spørs om det er god bruk av tid å diskutere problemer som er løst. Første trinn i en saksutredning er jo å poste saken på diskusjon.no og etter hvert så går det videre på andre fora.

Saka er jo ikkje løst. Tvert imot kjem du med aparte påstander, og når du får spørsmål om det så nekter du å svare.

La meg prøve ein gong til:

On 6/15/2023 at 3:59 PM, arne22 said:

On 6/9/2023 at 10:15 PM, barfoo said:

Kva forskjeller er det du ser, og kva tiltak og teknisk gjennomføring ser du for deg?

Kommer kanskje tilbake til problemstillingen litt senere 🙂

Kan du svare på det spørsmålet mitt? Er det urimeleg å be deg underbygge det du sjølv skriv?

 

[arne22]

Nei, diskusjon.no er bare til bruk i den innledende fase i en slik saksutredning. Gjennom alle de årene jeg har jobbert med slike tekniske sakutredninger så har jeg  alltid fulgt denne framgangsmåten. Først undersøke og tenke litt selv, diskutere med kolleger og venner, og så ta opp saken med relevante fagmyndigheter og faginstanser. Når svar foreligger så er saken løst.

Man kan for eksempel ikke skive en samsvarserklæring, eller annen formell dokumentasjon, med utgangspunkt i diskusjon.no Men det kan fungere helt ok med dokumentasjon fra relevante myndigheter og faginstanser.

Du har eller hatt et par interessante synspunkter, og rettet meg for feil, slik at jeg oppdaget feilen. Kreditt for det. Vi kan sikkert ta en diskusjon senere, på et annet tema.

Endret 18. juni 2023 av arne22

[barfoo]

Du har ikkje utreda et komma. Du har repetert påstander, og når du får spørsmål om påstandane har du posta høgtsvevande babling og nekta å konkretisere ting.

Det er fullstendig åpenbart at du inkompetent på feltet. Det har du brukt eit drøyt halvår på å demonstrere. Merk deg at det er ikkje min påstand - det er unisontilbakemelding fra omtrent alle som har svart deg om IPv6. Det er påpeikt banale feil i forståelsen din av NAT. Det er påpeikt banale feil i forståelsen din av IPv4. Det er påpeikt grunnleggande misforståelser om sikkerhet. Det er påpeikt fullstendig mangel på kjennskap til relevante standarder - også viare også viare.

Det faktum at du antar at myndighetskrav er relevant for IPv4 vs. IPv6 formidler at du er på bærtur.

Endret 18. juni 2023 av barfoo

[kpolberg]

@arne22 er det du som står bak cyberskole.no og cyberkurs.no ? Endel av linkene ser ihvertfall ut til å gå igjen.

Hvordan skal du kunne holde kurs innen IT, OT, IoT etc, når du ikke klarer å svare på enkle spørsmål rundt IPv4 og IPv6?

[arne22]

Nei jeg holder ikke noen kurs innen IT og jeg driver heller ikke med noe annet innenfor IT. IPv4 og IPv6 står ikke lengre på listen over spørsmål som står uten svar nå. Da ønsker jeg jo å bruke tiden på noe annet.

Endret 19. juni 2023 av arne22

[process]

Jeg ønsker å forsøke å nyansere litt.  

Jeg skal være helt enig i at liten-til-mediumskala automatsjonsnettverk ikke trenger ipv6.  Om de er egnet er og blir et separat spørsmål.  Automasjonsnettverk er helt regulære IP-nettverk, og kan driftes på ulike måter.

Det er for meg helt klart at de kan driftes godt og sikkert med dual-stack, men jeg er ikke overbevist om at det er et mål som tilfredstiller hverken, IT-, personal- eller bedriftshensyn for mindre bedrifter med automasjonsbehov.  Et godt drevet nettverk får man igjennom den compliance man vil. 

Det er sannsynlig at denne samtalen har tatt et sidesprang. @arne22 er i en silo som ikke vurderer IPv6,  men kun ut ifra sitt eget perspektiv (og det er ingenting galt ved det).

Resten, som @barfoo @germanwhip @Serpentbane @tommyb (and anyone I forgot) - dere vet hva dere snakker om, men har også et bias

 

Endret 19. juni 2023 av process

[barfoo]

53 minutes ago, process said:

Det er sannsynlig at denne samtalen har tatt et sidesprang. @arne22 er i en silo som ikke vurderer IPv6,  men kun ut ifra sitt eget perspektiv (og det er ingenting galt ved det).

Det er åpenbart uproblematisk, og det er legitime grunner til å holde seg til f.eks. IPv4. Kompetanse kan vere slik grunn.

Men då bør en ikkje ha behov for å finne på grunner og nekte å underbygge dei når ein får spørsmål.

[arne22]

11 hours ago, process said:

Automasjonsnettverk er helt regulære IP-nettverk, og kan driftes på ulike måter.

Nå er jeg vel ferdig med denne "utredningen" og jeg bruker tiden på noe annet, men jeg synes i grunnen at dette webinaret har en ganske god oppsummering av det som kom fram i diskusjonen med fagmiljøene utenfor diskusjon.no Linker opp for den som måtte være interessert i denne problemstillingen.

https://www.kiwa.com/no/no/tjeneste/kurs/cybersikkerhet-for-ot/

Opptaket av webinaret tar ca 1 time å kikke gjennom og jeg synes det er "representativt og bra".

Ser at det er mye diskusjon om "kompetanse" over. Synes rent personlig at det er et lite poeng å ha tilstrekkelig liten kompetanse til at man kan koble seg opp mot de fagmiljøene som arbeider med problemstillingene, og så hente inn den informasjon der i fra, inklusive også fra fagmiljøet på diskusjon.no.

Endret 20. juni 2023 av arne22

[RamGuy]

Man gjør seg selv en bjørnetjeneste ved å fornekte IPv6 i 2023. Nå som Norge på statlignivå krever at alle offentligetjenester skal være tilgjengelig på IPv6 så er det jo bare å gjøre seg kjent med IPv6 først som sist.

Nå er ikke IPv6 særlig vanskelig. Det er jo mer eller mindre likt IPv4. Men ettersom IPv6 gir oss tilgang å latterlig mange IP-adresser så er tanken at vi går tilbake til sånn ting var for 15-20 år siden på IPv4. Altså alt utstyr får rutbare IP-adresser så det ikke er behov for NAT.

Men om du på død og liv vil tulle med NAT så kan du jo det også. Det er Globale, Private og Link-Local adresser på IPv6, akkurat som på IPv4. Så om du vil sitte å distribuere Private IPv6 scopes lokalt, så du må sitte med NAT6 inn og ut på Internett så kan du jo gjør det om du på død og liv vil.

Men tanken, og litt av poenget er at vi med IPv6 har nok offentlige IP-adresser sånn at vi kan slippe NAT. NAT ble jo til fordi vi hadde mangel på offentlig IPv4 adresser og har jo skapt en hel masse problemstillinger. Så det å ta med NAT inn i IPv6 er temmelig dust.

 

Mye av grunnen til at folk er redd for IPv6 og føler det er mindre sikkert er fordi folk har fått for seg at NAT = sikkerhet. Og en bieffekt av NAT er jo forsåvidt at det blir mer sikkert. For sitter endepunktet med en privat IP-adresse så er den jo per definisjon ikke rutbar fra Internett. Men dette er jo bare en bieffekt av NAT, NAT var aldri tiltenkt som noen sikkerhetsfunksjon. Så med mindre går veien med Private IPv6 scoeps og NAT6 så vil endepunktet sitte med en Global/offentlig IP adresser og er direkte rutbar fra Internett. Det betyr jo naturligvis at man må være mer påpasselig med brannmur på nettverkslaget og på endepunktet. Du har ikke noe NAT som vil redde deg inn, så om noen plutselig sitter på brannmuren og klarer å knote inn en regel som sier at alt til endepunktet fra Internett er tillatt så er det tut og kjør.

[process]

14 hours ago, RamGuy said:

NAT ble jo til fordi vi hadde mangel på offentlig IPv4 adresser og har jo skapt en hel masse problemstillinger. Så det å ta med NAT inn i IPv6 er temmelig dust.

NAT er dust og skaper en mengde problemer. Det har ingenting med brannmur eller trafikkflyt å gjøre.

[arne22]

Etter å ha kommet meg litt rundt i diskusjonen med fagmiljøene utenfor diskusjon.no, så lurer jeg på om jeg skal driste meg til et lite innlegg.

On 6/20/2023 at 12:00 PM, RamGuy said:

Mye av grunnen til at folk er redd for IPv6 og føler det er mindre sikkert er fordi folk har fått for seg at NAT = sikkerhet. Og en bieffekt av NAT er jo forsåvidt at det blir mer sikkert.

Hvis dette hadde vært en diskusjon som handlet om IT-faget og IT-nettverk, så hadde jo disse betraktningene hatt noe for seg, men påenget er jo at det dreier seg om et helt annet fagområde, med helt andre forutsetninger og helt andre grunneggende tekniske problemstillinger. 

Tråden handler jo ikke om informasjonsteknologi - IT, men om operasjonell teknologi OT. Det er nok en liten overlapp mellom IT og OT, en det er nok bare en forholdvis liten prosentandel.

Det som tråden jo i forholdvis større grad handler om, det er: Hvilke praktiske konsekvenser vil bruken av IPv6 ha for de problemstillingene som ligger innenfor den operasjonelle teknologien, og hvordan løser man så disse problemstillingene rent praktisk?

Foreløpig er jo konklusjonen den at det stort sett ikke finnes kompomenter, for prosessanlegg, basert på IPv6, slik at så godt som 100% av alle prosessnettverk kjører IPv4. Med andre ord, så er det ikke teknisk mulig å basere prosessnettverk på IPv6, hvis man bruker og baserer seg på standard komponenter fra de store leverandørene.

Man kunne jo tenke seg at slike kompoenter blir laget i framtiden og så kunne man som et lite framtidsstudie se på hvilke forutsetninger som må være på plass for å kunne bruke IPv6 i forhold til operasjonell teknologi.

• Risikovurderingen vil være helt annerledes for OT i forhold til IT. For OT anlegg så vil risiko for eksempel kunne være brann, eksplosjon, oversvømmelse, klemskade eller tap av menneskeliv. Det dreier seg ikke om "tap av data".
• Alle lovgitte krav til sikkerhet, kvalitetsstyring og sluttkontroll må være oppfylt. Det må finnes verifiserte arbeidsrutiner for alle sikkerhetsrelaterte arbeidsoppgaver inklusive sluttkontroll.
• Purduemodellen brukes i dag som en referansemodell for sikkerhet i prosessnettverk. Den såkalte cyber kill chain brukes som referansemodell for PEN-Testing. Det vil være nødvendig å bygge opp nye nettverk og PEN-teste ut i fra bransjestandard for OT-nettverk. (Det er selvfølgelig godt mulig, men først så må man produsere de komponentene som behøves.)
• Alle komponentene i OT anlegget må konfigureres og verifiseres med IPv6, ut i fra de bransjekrav som gjelder for sikkerhet.

Grunnen til at dagens prosessnettverk kjører IPv4, det er vel ikke akkurat det at de som installerer og drifter dem er redde for IPv6, men at det dreier seg om en helt annen bransje med helt andre krav enn det som gjelder i IT bransjen. Alle de kravene som er nevnt over er jo oppfylt nå i dag, basert på bruken av  IPv4 (og andre protokoller men stort sett ikke Pv6)

Hvis det kommer komponenter basert på IPv6 da er vel ikke probemstillingen NAT eller ikke NAT, eller ende til ende kommuniasjon, som er de viktige, men hvilke praktiske konsekvenser dette vil få for den operasjonelle teknologien og hvilke kostnader som vil påløpe, fordeler, ulemper, osv.

Innenfor den gruppen av fag som man kan gi en samlebetegnelse "operasjonell teknologi", så finnes det jo mange undergrupper. For noen av disse så er det vel overveiende sannsynlig at det vil bli tatt i bruk IPv6. Det er vel sånn sett ikke et spørsmål om å være "for eller mot" men å følge utviklingen og ha et realistisk helhetsbilde i forhold til de ulike variantene av IT og OT teknologi, og hvordan man eventuelt kan kombinere disse.

Endret 1. juli 2023 av arne22

[barfoo]

Gratulerer med så mange avsnitt utan faktisk innhald.

Det er brødtekst som er totalt blotta for faktisk meining du produserer.

[arne22]

Det kan vel kanskje tenkes at det finens en del IT folk som tror at IT og OT er noenlunde de samme fagene og at man kan bruke prinsippene fra IT fagene til å forstå OT fagene. Slik er det kansje i praksis ikke.

Endret 4. juli 2023 av arne22

[barfoo]

15 hours ago, arne22 said:

Det kan vel kanskje tenkes at det finens en del IT folk som tror at IT og OT er noenlunde de samme fagene og at man kan bruke prinsippene fra IT fagene til å forstå OT fagene. Slik er det kansje i praksis ikke.

Er det konkrete ting i denne tråden du sikter til?

[arne22]

IT og OT utgjør jo på mange måter i utgangspunktet to forsjellige verdener. 

OT var jo tidligere ikke koblet opp mot Internett i det hele tatt, og i forbindelse med systemer der det er høye krav til sikkerhet, så er det vel fortsatt en del eksempler på at det ikke er noen direkte oppkobling mot Internett.

For et OT nettverk, så er jo de sikkerhetsmessige og praktiske løsningene og risikovurderingene helt forskjellig fra IT, og det gjelder også hvordan man anvender og forholder seg til regelverk, og kanskje også det meste av det som går på planlegging og prosjektering og eventuell ombygging av det tekniske anlegget.

I forhold til regelverket så dreier det seg vel hovedsaklig om tre-fire typer regelverk med krav til sikkerhet:

• Krav til el-sikkerhet. (Brann og farlige berøringssenninger)
• Krav til maskinsikkerhet. (Brann, eksplosjon, klemskade, lekasje av gass, forurensning av miljø, osv.)
• Bransjespesifikke krav til sikkehet, for eksempel for petroleumsindustrien.
• Informasjonssikkerhet ifbm tilkobling til lokalt nettverk eller internett.

I de praktiske implementeringene av Purduemodellen som jeg har kikket litt på, hos de bedriftene som utarbeider slike, så har det ikke eksistert noen direkte tilkobling mellom prosessnettverket og Internett, heller ikke for oppdatering av programvare. Det brukes "ende til ende kommunikasjon" basert på IPv4, uten bruk av NAT.

Når NAT ikke er i bruk, da blir jo ikke problemstillingen rundt NAT så veldig sentral.

Hvis man skal implementere en variant av Purdue modellen basert på IPv6, så er dette jo teknisk mulig, hvis det tekninske utstyret hadde eksistert, men i dag så gjør det jo ikke det. Hvis man skulle omarbeide implementeringen av Purduemodellen fra IPv4 til IPv6, så vil dette få betydning for den sikkerhetsmessige statusen for det tekniske anlegget som helhet. Alt sammen fra risikovurdering til verifisering av systemsikkerhet for det tekniske anlegget vil måtte gjøres på nytt.

For tekniske anlegg innenfor OT, så utgjør "IT problematikken" bare en liten del av en samlet sikkerhetsproblematikk, slik at det er nødvendig å vurdere alle sider ved denne problematikken ut i fra helhet og å se tingene i sammenheng.

Når man jobber med OT så jobber man vel også normalt noe tettere opp mot fag og tilsynsmyndigheter og også leverandører og andre fagmiljøerandre, enn det som kanskje er nødvendig for IT faget. (??!! - Har aldri jobber innenfor IT, men det skulle man jo tro.) Innenfor OT-fagene, så er det vel egentig ikke så mye man finner på selv, man dokumenterer at man er innenfor regelverk, normer og anbefalinger fra leverandører.

Jeg fant en video som gir et ganske interessant bildet av sammenhengen mellom IT og OT. Her kobler man faktisk OT anlegget opp mot Internett, men man bruker en "unidirectional gateway" eller en "data-diode", slik at datastrømmen fra prosessanlegget bare kan strømme en vei, ut fra prosessnettverket og ut på Internett og "cloud", men ikke motsatt. På denne måten så får man laget en digital tvilling av OT systemet. Den digitale tvillingen vil jo sånn sett være en IT-løsning. Mye interessant diskusjon mot slutten av videoen.
 

 

Endret 7. juli 2023 av arne22

[barfoo]

9 hours ago, arne22 said:

I de praktiske implementeringene av Purduemodellen som jeg har kikket litt på, hos de bedriftene som utarbeider slike, så har det ikke eksistert noen direkte tilkobling mellom prosessnettverket og Internett, heller ikke for oppdatering av programvare. Det brukes "ende til ende kommunikasjon" basert på IPv4, uten bruk av NAT.

I så fall kan du umulig ha studert eit stort utval. Eg jobber som sagt med sikkerhet, og å designe et nettverk for airgap i dag er idiotisk. Stuxnet avliva alle forestillinger om airgap som effektivt sikkerhetstiltak; militære som vokta statshemmeligheter rota til airgap for pokker!

 

9 hours ago, arne22 said:

Hvis man skal implementere en variant av Purdue modellen basert på IPv6, så er dette jo teknisk mulig, hvis det tekninske utstyret hadde eksistert, men i dag så gjør det jo ikke det. Hvis man skulle omarbeide implementeringen av Purduemodellen fra IPv4 til IPv6, så vil dette få betydning for den sikkerhetsmessige statusen for det tekniske anlegget som helhet. Alt sammen fra risikovurdering til verifisering av systemsikkerhet for det tekniske anlegget vil måtte gjøres på nytt.

Purduemodellen er ein modell. Som alle modeller er den feil, men i ein del tilfelle er den nyttig. Den er imidlertid konseptuell, og det er revnande likegyldig for purduemodellen om du køyrer IPX, IPv4, IPV6 eller Profibus. Den er konseptuell, og uavhengig av implementasjon.

Jobber du faktisk med sikkerhet på automasjonssystemer? Om ikkje: kva jobber du med?

[sk0yern]

barfoo skrev (50 minutter siden):

Eg jobber som sagt med sikkerhet, og å designe et nettverk for airgap i dag er idiotisk. Stuxnet avliva alle forestillinger om airgap som effektivt sikkerhetstiltak; militære som vokta statshemmeligheter rota til airgap for pokker!

Nuvel.
Det er sikkert mange gode grunner til å ikke benytte airgap i dag.
Airgap er definitivt et effektivt sikkerhetstiltak, men når en angriper er tålmodig, har svært dyktige folk, samt "uendelig" med ressurser, da er du stort sett fucked uansett
De færreste av oss har Mossad/CIA på lista over trusselaktører.

 

[barfoo]

2 minutes ago, sk0yern said:

Airgap er definitivt et effektivt sikkerhetstiltak, men når en angriper er tålmodig, har svært dyktige folk, samt "uendelig" med ressurser, da er du stort sett fucked uansett

Beg to disagree.

Airgap garanterer at du utdaterte systemer som mangler sikkerhetspatcher. Det er ikkje behov for aktiv angriper; minnepinne med malware er nok til at du får problemer.

I tillegg er det å planlegge med airgap urealistisk. Digitalisering og uthenting av data er stortsett del av moderne automasjonsnettverk. Det er bedre å ta høgde for at ting blir kopla mot internett, og innføre tiltak mot det. Ellers risikerer du jo at kabelen blir kobla til uten sikkerhetsmekanismer.

[sk0yern]

barfoo skrev (1 time siden):

Beg to disagree.

Airgap garanterer at du utdaterte systemer som mangler sikkerhetspatcher. Det er ikkje behov for aktiv angriper; minnepinne med malware er nok til at du får problemer.

I tillegg er det å planlegge med airgap urealistisk. Digitalisering og uthenting av data er stortsett del av moderne automasjonsnettverk. Det er bedre å ta høgde for at ting blir kopla mot internett, og innføre tiltak mot det. Ellers risikerer du jo at kabelen blir kobla til uten sikkerhetsmekanismer.

Det er selvfølgelig ikke noe enkelt fasitsvar på dette.
Det man uansett kan være helt enig om, er at truslene man har ved et airgapped nettverk, er annerledes enn hvis man ikke har det.
Så blir det en risikovurdering hva som er mest hensiktsmessig i hvert enkelt tilfelle.
Nå er det vel også slik at noen av systemene det er snakk om ikke nødvendigvis så lette/mulig å patche heller?