Kommunikasjonsnettverket er ikke ditt å designe

Produsentens nettverksingeniør ankommer det tidlige design-møtet med en topologi-tegning. Den viser turbinkontrollerne, SCADA-arbeidsstasjonen, historian-en, ingeniør-arbeidsstasjonen, og brannmuren til den ytre verden. IP-adressene er forhåndstildelt. VLAN-ene er merket. Den redundante oppstrøms-koblingen kobler til en svitsj merket «eier-nettverk», og ved den svitsjen stopper tegningen høflig.

Tegningen er, etter sine egne konvensjoner, fullstendig. Den viser alt fra sensoren i bladet til grensen av operatørens nettverk. Samtalen som følger forutsetter at tegningen er grunnlaget for nettverksdesignet — at produsenten spesifiserer, operatøren implementerer det produsenten spesifiserer, og grensen er der de to diagrammene møtes.

Den forutsetningen er kilden til mer friksjon i tidlige prosjektmøter enn noe annet enkelt arkitektonisk spørsmål.

Anleggets kommunikasjonsnettverk er ikke produsentens å designe. Lokalnett-ene inne i anlegget, segmenteringen mellom soner, brannmurene mellom lag, den industrielle demilitariserte sonen som formidler oppstrøms-konnektivitet, rutingen til transformatorstasjonen og til konsernet, IP-adresseplassen, VLAN-tildelingen, standard gateway-er, spanning-tree-topologien, tidssynkroniserings-hierarkiet — alt er operatørens ansvar. Produsenten spesifiserer hva utstyret deres trenger. Operatøren spesifiserer hvordan det behovet møtes.

Dette er ikke en høflighet. Det er en strukturell konsekvens av det regulatoriske og sikkerhetsmessige rammeverket prosjektet sitter inne i.

Hvorfor denne separasjonen eksisterer

Tre grunner gjør rolle-separasjonen ikke-forhandlingsbar.

Den første er styring. Under NIS2-direktivet er operatøren den vesentlige enheten. Operatøren er parten med lovpålagte forpliktelser på risikohåndtering, hendelseshåndtering, leverandørkjedesikkerhet og rapportering. Operatørens regulator aksepterer ikke «produsenten designet og driver nettverket» som svar når noe svikter. Et nettverk operatøren ikke kan beskrive, ikke kan overvåke, ikke kan revidere og ikke kan endre uten produsentens godkjenning, er en styringssvikt på operatørens side, uavhengig av hvor teknisk velutformet det måtte være.

Den andre er selve sikkerhetsarkitekturen. IEC 62443 organiserer et industrielt kontrollsystem i soner — grupperinger av aktiva som deler et felles sikkerhetsnivå — adskilt av kanaler, de kontrollerte kommunikasjonsstiene mellom dem. Anleggseieren er ansvarlig for sone- og kanaldesignet (62443-3-2) og system-nivå sikkerhetskravene (62443-3-3) . Produsenten, som leverandør og L0/L1-integrator, er ansvarlig for komponentene innenfor sin sone (62443-4-1 for utviklingsprosessen, 62443-4-2 for selve komponentene) . Arkitekturen er eksplisitt om hvor hver parts designautoritet begynner og slutter, og anleggets kommunikasjonsnettverk — særlig nettverket over produsentens prosess-sone — sitter fast på operatørens side av den linja.

Den tredje er multi-leverandør-virkeligheten i moderne fornybar energi-anlegg. Et typisk utility-scale-prosjekt inkluderer en turbin- eller solinverter-produsent, en batteri-lagrings-leverandør med sine egne kontroller, en SCADA-plattform-leverandør hvis programvare kan komme fra en tredjepart, en substasjons-automasjons-leverandør, en vernrele-leverandør, iblant en separat tilstandsovervåknings-leverandør, og en meteorologi-mast-leverandør. Hver kan ikke bringe sitt eget nettverk. Hver kobler seg til en delt infrastruktur designet og drevet av anleggseieren. En produsent som ankommer med forventning om å designe nettverket de skal sitte på, har enda ikke akseptert det faktum at de er én leietaker blant flere.

Hva god leverandør-spesifikasjon ser ut som

Det en produsent bør spesifisere er presist og kort. Utstyret, etter modell og antall. Kommunikasjonsprotokollene, etter standard. Transportkravene — TCP eller UDP, portnumre, forventede meldingsrater, latens-toleranse, pakke-tap-toleranse, jitter-følsomhet. Det fysiske laget — kobber eller fiber, single-mode eller multi-mode, port-antall per enhet, kontakttype, avstandsbegrensninger. Redundans-posituren — single-homed, dual-homed med applikasjonsnivå-failover, parallel redundancy protocol, high-availability seamless redundancy, rapid spanning tree med oppgitte konvergens-mål. Tidssynkroniseringskravet, i form av nøyaktighet og protokoll (NTP, PTP, IRIG-B).

Det er hele det produsenten trenger å si. Operatørens nettverksteam tar den spesifikasjonen og leverer et nettverk som møter den.

Det en produsent ikke bør spesifisere er implementeringen. De bør ikke angi at kontrolleren deres krever 192.168.10.0/24-subnettet. De bør ikke angi at det redundante LAN-et må bruke VLAN 200. De bør ikke angi at gateway-IP-en må være 192.168.10.1. De bør ikke angi at tidskilden må være en spesifikk NTP-server-adresse innebygd i firmwaren. De bør ikke anta at enheten deres vil være på samme broadcast-domene som noen annen enhet de kommuniserer med. De bør ikke anta at brannmurregelen mellom enheten deres og historian-en vil være åpen i begge retninger for et port-område; det vil den ikke. Den vil være åpen fra enheten til historian-en, for den spesifikke porten, med de spesifikke kilde- og destinasjonsadressene, og enhver avvik fra den spesifiserte adferden vil bli droppet.

En enhet som kommer av produksjonslinjen med hardkodede subnett, innebygde gateway-antakelser eller faste IP-adresser som ikke kan konfigureres ved utrulling, er en enhet med en leveringsdefekt. Den vil bli returnert. Produsenten vil bli bedt om å levere firmware som aksepterer IP-konfigurasjonsparametre fra operatørens utrullings-prosess. Hvis den firmwaren ikke finnes, overlever ikke produsentens bud den tekniske evalueringen.

Redundans og den antatte topologien

Redundans-spørsmålet fortjener sin egen behandling fordi det er der den antatte topologien stilleste kolliderer med operatørens design.

Et produsents redundans-krav, oppgitt korrekt, ser slik ut: «Kontroller A krever to uavhengige nettverksgrensesnitt med failover mellom dem, gjenopprettingstid under 200 millisekunder, ingen tap av transaksjoner under flyt ved enkelt link-feil.» Det er en ren spesifikasjon. Operatøren kan levere det gjennom Parallel Redundancy Protocol eller High-availability Seamless Redundancy under IEC 62439-3, gjennom Rapid Spanning Tree med passende timer-tuning, gjennom link-aggregering med LACP, gjennom Multiple Spanning Tree med konstruert konvergens, eller gjennom applikasjons-styrt failover der kontrolleren opprettholder parallelle tilkoblinger på begge grensesnitt. Det er mange implementeringer; produsenten bryr seg om at kravet er møtt, ikke hvordan.

Et produsents redundans-krav, oppgitt feil, ser slik ut: «Kontroller A krever LAN 1 på subnett 192.168.10.0/24 og LAN 2 på subnett 192.168.20.0/24, begge med samme standard gateway, failover utløst av tap av ICMP-respons fra gateway-en, retur til primær etter 30 sekunder med stabil respons.»

Det er ikke et krav. Det er en implementering, og det er en implementering som forutsetter at operatørens nettverk kan akkommodere produsentens mentale modell av redundans. De fleste anleggsnettverk kan ikke det, fordi de kjører protokollnivå-redundans på svitsj-stoffet snarere enn på enheten, eller de kjører applikasjonsnivå-redundans der enheten åpner tilkoblinger på begge grensesnitt og bruker den som svarer, eller de bruker adresseringsskjemaer — overlappende styrings-VLAN-er, ikke-rutbare vedlikeholdsnettverk, unique-local IPv6 — som produsentens statisk-IP-antakelse bare bryter.

Det arkitektoniske prinsippet er enkelt. Produsenten antar at enheten deres vil motta en IP-adresse. Fra hvilken CIDR-blokk, med hvilken subnett-maske, med hvilken standard gateway, på hvilket VLAN — ingen av disse er produsentens å spesifisere. Hvert grensesnitt konfigurerbart ved utrulling, hvert tolerant for adresseringsskjemaet operatøren velger, hvert fungerende korrekt uavhengig av om de to grensesnittene sitter på samme subnett, på forskjellige subnett, på forskjellige VLAN eller på forskjellige fysiske nettverk helt. Enhetens redundans-logikk må fungere i alle disse forholdene, fordi i forskjellige anlegg i forskjellige jurisdiksjoner designet av forskjellige nettverksteam, vil alle disse forholdene oppstå.

Synlighets-spørsmålet

Synlighets-spørsmålet er den vanskeligste delen av denne samtalen for produsenter å akseptere, fordi det føles som et informasjons-vakuum. Produsenten blir fortalt at utstyret deres vil bli utrullert i et nettverk hvis topologi, adresseringsskjema, segmentering og brannmur-regelbase de ikke vil se i noen meningsfull detalj.

Dette er ikke gjerdebygging. Det er sikkerhetsrammeverket som fungerer som tilsiktet.

Anleggsnettverkets topologi er en sensitiv ressurs. Den kartlegger angrepsflaten. Den identifiserer hvilke aktiva som er tilgjengelige fra hvilke andre aktiva, hvilken trafikkflyt brannmurene tillater, hvilke segmenter som er isolert av sikkerhetsmessige grunner, hvilke stier en sofistikert angriper måtte krysse for å nå de kritiske sonene. Hver ekstra part som holder topologien er en part hvis egen informasjonssikkerhets-positur blir en sti til anlegget. Prinsippet om minste privilegium, anvendt på design-informasjon snarere enn på tilgangslegitimasjon, sier at produsenten skal se bare det produsenten trenger å se.

Det produsenten trenger å se er det de faktisk mottar. IP-adressene enhetene deres vil bruke. Gateway-ene enhetene deres vil rute gjennom. Destinasjonsadressene og portnumrene enhetene deres vil nå. Protokollene de vil snakke på hvert grensesnitt. Legitimasjonen for tjeneste-kontoene deres. Diagnose-grensesnittet de kan spørre for helsen til sitt eget utstyr. De får ikke diagrammet over hvordan disse endepunktene nås internt. De får ikke listen over andre enheter på samme VLAN. De får ikke brannmur-regelbasen over kanalen mellom deres sone og den neste. Den informasjonen er ikke deres.

Det produsenten får i tillegg, ved kanal-grensa, er en spesifikasjon av hva utstyret deres må støtte: hvilke protokoller som er tillatt på tvers av kanalen, i hvilke retninger, med hvilken autentisering og hvilken logging. Kanal-spesifikasjonen er kontrakten. Alt utenfor kanalen er operatørens domene.

Hva dette betyr på forslagsstadiet

På forslagsstadiet betaler denne disiplinen seg raskt. Et bud som spesifiserer utstyret, protokollene, portnumrene, båndbredde-konvolutten, latens-budsjettet, redundans-posituren og tidssynkroniseringskravet — og stopper der — er et bud operatørens nettverks-arkitekter kan jobbe med. Et bud som spesifiserer utstyret pluss en full antatt topologi med hardkodede adresser, innebygde VLAN-identifikatorer og påkrevde subnett-masker er et bud som vil bli returnert med kommentarer som ber produsenten fjerne topologien og oppgi kravene på nytt.

Prinsippet er ikke nytt. Det er hvordan grensesnitt alltid har fungert mellom uavhengige ingeniørdisipliner. Produsenten som behandler nettverkspesifikasjonen som en grensesnittkontrakt — hva jeg trenger fra deg, hva du trenger fra meg, ikke mer — finner den arkitektoniske samtalen mye kortere enn produsenten som ankommer med en topologi-tegning.

Den dypere vanen å bryte er den importert fra markeder der produsenten også var integrator, operatør og nettverksdesigner. I et EU-finansiert prosjekt er disse rollene atskilt ved design. Anleggsnettverket er operatørens, og kun operatørens. Produsentens jobb er å spesifisere hva de trenger fra det, og å levere utstyr som fungerer inne i hva enn operatøren bygger.

Den neste artikkelen beveger seg ett steg utover, til grensen der anlegget slutter og transformatorstasjonen begynner — og til ingeniørdisiplinen på den andre siden av det gjerdet, som ikke er operatørens heller.

Denne artikkelen reflekterer det regulatoriske og standard-landskapet ved publisering. Referanser til IEC 62443 og IEC 62439 kan bli erstattet av revisjoner av disse standardene; NIS2-gjennomføringen fortsetter å utvikle seg på tvers av medlemsstatene. Hvis et sitat har råtnet eller en klausul har flyttet seg, er LinkedIn veien å flagge det på.