7.1.1 Risikoanalyse - skap overblikk

Sikkerhetsevalueringen starter med en risikoanalyse, noe som bør etableres som en del av utviklingsprosessen. På den måten vil sikkerhetsaspektet være integrert helt fra den første kravanalysen i utviklingen. Selv om en integrering av en risikoanalyse i utviklingsprosessen innebærer en ekstra innsats til å begynne med, kan dette reduseres til et håndterbart nivå gjennom en strukturert og repeterbar prosess. Tilpasning av metoder som allerede er etablert (som FMEA - Failure Mode and Effects Analysis) for risikoobservasjon har vist seg nyttig historisk sett. Fremfor alt vil den tidlige ekstrainnsatsen betale for seg selv i løpet av utviklingen, ettersom sikkerhetsfunksjoner kan betraktes som integrerte deler av maskinen, som ikke trenger å bli lagt til senere med større kostnader. 

Alle påfølgende trinn i risikoanalysen bør tas i betraktning under hele utviklingsprosessen og utføres regelmessig under drift med og uten produsentgaranti.

7.1.1.1 Identifisere eiendeler

Steg 1 er å skape enighet om hvilke komponenter i maskinen som er verdifulle og som trenger beskyttelse. Dette kan for eksempel omfatte maskinvare- og programvarekomponenter, men også data og programmer med høy immateriell verdi. Det anbefalte første trinnet er å bli klar over de materielle og immaterielle verdiene, som deretter gjenspeiles i identifikasjonen og listen over de respektive komponentene. 

7.1.1.2 Fastsette beskyttelsesmål

Hvis en bestemt komponent i maskinen ble tildelt en høy verdi (i løpet av det første trinnet), bør det opprettes et beskyttelsesmål for denne komponenten.

7.1.1.3. Identifisere trusler

Når maskinkomponentene som trenger beskyttelse har blitt identifisert, er neste trinn å vurdere de tilhørende truslene. En trusselanalyse gir innsikt i de praktiske truslene som kan forventes under maskindrift og hva du skal forberede deg på i når det gjelder de respektive skadene som kan påføres. 

7.1.1.4. Risikovurdering

Basert på trusselanalysen, kan risikoen tilordnet truslene evalueres. Risikoen for en gitt trussel er skaden påført vektet av sannsynlighet for forekomst. Vurderingen utføres basert på en angrepsmodell som skal opprettes på forhånd, som spesifiserer antatte evner til en potensiell angriper 

En fullstendig risikoanalyse fører direkte til valg av passende beskyttelsestiltak og danner dermed grunnlaget for optimal beskyttelse av maskinen eller anlegget. På den andre siden kan en komplett risikoanalyse være veldig omfattende og kan derfor ikke være gjennomførbar for en liten eller mellomstor bedrift. Derfor anbefales det å inkludere risikoanalyse i utviklingsprosessen. Minimumskravet for den slik analyse er ...

• ... å sørge for at en oversikt over eiendeler blir forseggjort.
• ... at tilknyttede beskyttelsesmål blir formulert
• ... at de ansvarlige partier i hvert tilfelle er kjent med truslene i planleggings- og utviklingsprosessen av eiendelen. 

7.1.2 Nettverkssegmentering - del og erobre!

Anlegget skal deles inn i soner basert på de enkelte systemdelers sikkerhetskrav. De tilkoblede maskinene og komponentene i en sone er preget av lignende sikkerhetskrav. Tekniske tiltak bør brukes for å splitte de enkelte segmentene. 

7.1.2.1 Definisjon av risikobasert sikkerhet

Krav tilordnet anlegg og komponenter: Sikkerhetskrav bør bestemmes basert på vanlige metoder for risikovurdering. En risikoanalyse gir informasjon om sikkerhetskravene til anlegget og komponentene. Tildeling av sikkerhetskravene som er bestemt på denne måten tillater definisjon av soner, dvs. nettverkssegmenter med komponenter med sammenlignbare krav. 

7.1.2.2 Regulering av tjenester

De forskjellige nettverksområdene i produksjonen (f.eks. ERP, MES eller SCADA-nettverk) er spesielt preget av tjenestene de tilbyr. Tanken bak er å sikre at nettverkssegmenter som er direkte koblet til maskinen, bare inneholder tjenester med sammenlignbare sikkerhetskrav. Ved regulering er det viktig å sikre at svikt i en sone påvirker så få andre soner som mulig. 

7.1.2.3 Bruk av isolasjonstiltak

Dette er ment å gjøre det vanskeligere å for en trussel å spre seg til hele systemet om den først har kompromittert en maskin. Potensielle tekniske tiltak for å skille de identifiserte segmentene inkluderer brannmurer eller datadioder. Deteksjon av skadevare (malware) eller protokollanomalier basert på nettverkskommunikasjon mellom de definerte nettverkssegmentene anbefales. For nettverkssegmenter i særlig fare, bør datodioder sikre at informasjon bare flyter i den forhåndsdefinerte retningen. Videre tillater VPN-løsninger nettverk på separate lokasjoner å bli samlet i et segment, slik at lignende eller identiske anlegg kan styres sammen til tross for avstanden mellom dem. 

7.1.2.4 Periodisk kontroll av isolasjonstiltak

For filterkomponenters effektivitet og med mulighet til korrigering: Det skal være mulig å sjekke effektiviteten til de tekniske isolasjonstiltakene regelmessig. I tilfelle brannmur eller andre filterteknologier, kan det også være nødvendig å sjekke filtreringsreglene regelmessig. Produktoverganger og konvertering / flytting kan også endre et anleggs behov for beskyttelse, noe som krever ytterligere justeringer av nettverket og IP-konfigurasjonen. 

7.1.2.5. DNS og andre tjenester per sone

Nettverkssegmentering bør kartlegges til DNS-infrastrukturen så langt det er mulig. De ofte veldig komplekse nettverkene og det store antall nettverkssegmenter, gjør det til en god ide å tilordne flere segmenter med lignende beskyttelsesbehov til en DNS-server.

7.1.3 Brukerkontoer, legitimasjon, autentisering og autorisasjon - Ikke alle bør ha lov til å gjøre alt

Produksjonssystemet skal sikre sikker styring av brukerkontoer og tilordnede tilgangsdata (legitimasjon, for eksempel passord, symboler, SSH-nøkler og biometrisk autentiseringsdata).

7.1.3.1 Individuelle brukerkontoer

Det skal være mulig å sette opp individuelle brukerkontoer for hver enhet. "Enheter" refererer både til personene som samhandler med maskinen og til andre maskiner og systemer som får tilgang til tjenestene som tilbys, både eksternt og lokalt.  Det er viktig å huske at operatøren bør få muligheten til å dokumentere alle brukerkontoer for maskiner og tilordne dem til en ansvarlig menneskelig part som vet opprinnelsen og virkemåten til den tekniske kontoen. Spesiell oppmerksomhet må her rettes mot det faktum at det ikke skal være noen kontoer for grupper av spillere: Brukerkontoer skal opprettes individuelt for hver bruker og ikke basert på tildelte roller.

7.1.3.2 Brukeradministrasjon

Antall brukere kan variere mye, avhengig av miljøet maskinen brukes i. Maskinen skal sikre effektiv håndtering av de enkelte brukerkontoer, spesielt med tanke på å legge til, aktivere, endre, deaktivere og fjerne kontoer. Dette kan ofte gjøres ved å administrere brukerkontoer sentralt. Som sådan anbefales det at en maskin støtter integrasjon i eksisterende identitetsstyringssystemer eller inkludering av brukerkontoer i katalogtjenester.

7.1.3.3. Distribusjon og styring av legitimasjon

Hver enkelt brukerkonto er koblet til tilgangsdata; den respektive brukeren skal være kjent med disse dataene for autentisering og autorisasjon. Behandlingen av disse legitimasjonene skal utformes slik at det er mulig å sikre en effektiv distribusjon. Rent praktisk betyr dette at selv om prosessen for nullstilling av legitimasjon i tilfelle av tap tilsvarer det respektive sikkerhetskravet, må det utformes fleksibelt slik at maskindrift alltid sikres. Dette er ment å forhindre driftsstans på grunn av komplekse innstillingsordninger. Når passord brukes, er det viktig å sikre at standardpassord også kan endres under nullstilling. Legitimasjon bør opprettes i tråd med de nyeste standardene og anbefalingene.  

Sikkerhetsmoduler som er beskyttet mot fysiske angrep (for eksempel TPM eller SmartCards), anbefales for lagring av legitimasjon. Hvis disse ikke er tilgjengelige, må det i det minste sikres at legitimasjon aldri blir lagret som ren tekst.  

7.1.3.4 Autentisere menneskelige brukere, programvareprosesser og komponenter

Alle menneskelige brukere, programvareprosesser og komponenter skal gjennomgå godkjenning basert på de definerte autentiseringsdataene hver gang de får tilgang til maskinen. Når maskinen har godkjent brukeren, skal tilgangen være begrenset til den økten.

7.1.3.5 Autentisering av offentlig nøkkel

Autentisering bør involvere så få offentlige nøkkelkrypteringsprosesser som mulig. Sikker og effektiv nøkkelhåndtering og et sikkert valg av kryptografisk materiale basert på alternativene til de innebygde systemene er viktig (se avsnitt 14), og å integrere maskinen i eksisterende offentlige nøkkelinfrastrukturer anbefales spesielt i dette tilfellet. Det er viktig å huske at en PKI (Public Key Infrastructure) vanligvis ikke har noen funksjoner for sertifiseringens livssyklusstyring, som bør leveres av operatøren for å unngå systemtidsavbrudd på grunn av utløpte sertifikater.

7.1.3.6 Opprette soner og tilgangskonsepter med tilsvarende godkjenning

Brukere skal være underlagt autentisering ikke bare på individuelle komponenter, men også når de krysser sonens grenser. I tillegg bør autentisering gjennomføres for hver tilgang via hvert grensesnitt på maskinen. Når det gjelder brukervennlighet, er det å bruke etablerte prosesser for automatisering både nyttig og effektivt (f.eks. enkelt pålogging ved å overføre tokens, fortrinnsvis SAML, Kerberos eller OAuth 2.0).

7.1.3.7 Maskinen skal sikre en autorisasjonssjekk av brukere/ tjenestene etter hver godkjenning

Når en bruker har blitt godkjent av maskinen, skal rettighetene som tildeles hans eller hennes individuelle konto sjekkes umiddelbart. Hvis rettighetene som er tildelt brukeren ikke samsvarer med de som kreves for tilgang, skal tilgang nektes og en passende oppføring genereres for hendelsesloggen. Det skal være mulig å justere tilgangsrettighetene til komponenter og tjenester selv etter at maskinen er tatt i bruk, da miljøkravene endres hele tiden. For å forenkle rettighetsstyringen for operatørene og for å avlaste komponentene, kan det være nyttig å administrere disse sentralt (f.eks. ved å bruke XACML). 

7.1.3.8 Sterk autentisering til eksterne grensesnitt

All tilgang til anleggets eksterne grensesnitt skal ivaretas gjennom sterk autentisering. Der kryptografiske autentiseringsmekanismer brukes, bør parameterne (f.eks. nøkkellengde) velges i henhold til de nyeste standardene. Det skal her bemerkes at maskinkomponenter fra fabrikkstatus ofte leveres med innledende standardkontoer (f.eks. administrator med et standardpassord). Sterk autentisering betyr også spesielt at denne typen standardkontoer bør justeres til de faktiske kontoene og de tiltenkte identitetene når maskinen tas i bruk. Hardkodet og dermed uforanderlig legitimasjon er ikke bare usikkert, men krever også et dyrt maskinvarebytte hvis tilgangsdataene er kompromittert. 

7.1.4 Bruke sikre protokoller

For angripere uten direkte tilgang til maskinen er det første angrepspunktet ofte kommunikasjonen med eksterne komponenter. Avanserte sikre protokoller skal alltid brukes for å sikre konfidensialitet, integritet og autentisitet av de sendte dataene. Protokoller som allerede er standardisert, bør brukes der det er mulig. 

7.1.4.1 Konfidensialitet av kommunikasjon med IP-baserte protokoller

Etablerte sikringstiltak kan sikre konfidensialitet og integritet til overførte data for IP-baserte protokoller for kommunikasjon mellom maskiner på forskjellige steder. Bruk av TLS 1.3 og protokoller basert på den (f.eks. HTTPS) anbefales spesielt for dette. Hvis behovet for nedoverkompatibilitet med gamle systemer gjør kryptering umulig, bør kommunikasjon gå utelukkende gjennom en sikker protokoll. 

7.1.4.2 Integritet av kommunikasjon

Integriteten til kommunikasjonsdataene bør sikres både i og utenfor maskinen. Åpne standarder og vanlige implementeringer basert på avansert teknologi, for eksempel TLS 1.3, er også nyttige her for praktisk implementering.

7.1.4.3 Type, styrke og kvalitet på krypteringsalgoritmer

Bruk av standardiserte krypteringsprosesser godkjent av offentlige instanser er sterkt anbefalt. Utvikling av egne krypteringsprosesser som ikke underlagt krypteringsanalyse av eksperter anbefales ikke under noen omstendigheter.

7.1.4.4 Spesiell vurdering av feltbuss

(Feltbuss: Et industrielt datamaskinnettverk for distribuert sanntidskontroll)

På feltbuss-nivå bør autentisiteten og integriteten i kommunikasjonen sikres som et minimum. Gitt sanntidskravene, bør en beslutning om det er nødvendig eller til og med mulig å kryptere dataene på feltbussnivå tas basert på hva anlegget brukes til.

7.1.5 Sikring av trådløse teknologier

Alle trådløse teknologier som støttes av maskinen, bør ivaretas i samsvar med de nyeste standardene.

7.1.5.1 Sikker konfigurasjon

Sikkerhetskravene til den trådløse teknologien som brukes må være oppfylt. Det første trinnet er den sikre konfigurasjonen av de trådløse teknologiene som brukes - innstilling av et lite sannsynlig område (ved å justere signalstyrken eller skjermingen) og høyest mulig interferensmotstand. Der hvor kompatibilitetsbehovet nedover betyr at komponentene ikke kan konfigureres forsvarlig, bør de usikre kommunikasjonskanalene bli utelukkende ført og ivaretatt gjennom sikre protokoller. 

7.1.5.2 Styring av trådløs tilgang

Ved tilgang via trådløse teknologier, skal anlegget utføre sterk autentisering (se avsnitt 3 og 6) og logge alle interaksjoner i økten. Det anbefales å aktivere tilgangsbegrensning etter den første tilkoblingen, så lenge dette ikke begrenser maskinens effektive drift i vesentlig grad.

7.1.5.3 Tidsavhengighet av sikkerhet for kryptografiske funksjoner

Ettersom trådløse nettverk er veldig eksponert og maskinen brukes i lengre perioder, bør sikkerhetskonfigurasjoner sjekkes regelmessig. Dette inkluderer spesielt kryptografiske funksjoner i det trådløse nettverket. Hvis chiffer-suitene, parameterne eller implementeringene som brukes blir påvirket av nåværende angrep, bør de erstattes med sikre versjoner umiddelbart.

7.1.6 Sikker fjerntjeneste

7.1.6.1 Kontroller konfigurasjon ved oppstart og avslutting av ekstern tilgang

Forskrift for åpning og avslutning av ekstern tilkobling danner grunnlaget for å etablere en sikker fjerntjenesteprosess, og bør definere når og under hvilke forhold en økt kan starte. Før hver ekstern tilkoblingssesjon er det viktig å sjekke om brukeren har de nødvendige rettighetene og om maskinens nåværende arbeidsmengde gir mulighet for et vedlikeholdsintervall. Økten skal blokkeres automatisk etter en spesifisert periode hvis brukeren ikke har utført noen handlinger i denne perioden. En blokkert økt kan bare gjenopptas etter gjentatt identifikasjon, godkjenning og autorisasjon. Både maskinen og brukeren av ekstern tilkobling skal kunne avbryte den eksterne økten. Maskinen kan trenge å avslutte økten hvis brukeren kaller opp uautoriserte funksjoner eller prøver å justere innstillingene. Alle data på en økt (inkludert tid, varighet og utførte handlinger) skal logges. I tillegg til de nevnte tiltakene, kan fjerntilgang begrenses gjennom ytterligere filtreringstiltak, f.eks. begrense det tilgjengelige IP-adresseområdet.

7.1.6.2 Sikring gjennom tekniske og organisatoriske tiltak

Når og under hvilke forhold fjerntjeneste kan finne sted, bør spesifiseres på et organisatorisk nivå. Overholdelse av disse spesifikasjonene bør teknisk sett ivaretas, for eksempel ved automatisk å sjekke en spesifisert retningslinje i forkant av alle eksterne tjenester.

7.1.6.3. Kryptering av tilkoblinger

Fjerntjeneste skal utføres via en kryptografisk sikret forbindelse. 

7.1.6.4 Etablere tilgangsprosesser

Handlingene en bruker har lov til å gjøre, bør være tydelig definert for hver tilkobling. Eventuelle avvik fra disse tilgangsprosessene bør føre til at økten avsluttes. Hvis tilkoblingen avsluttes gjentatte ganger i løpet av en forhåndsdefinert tidsperiode (f.eks. på grunn av feil innloggingsdata), bør ytterligere tilgang være forbudt og bare tillates igjen når administratoren med tilsvarende rettigheter har aktivert den på nytt. 

7.1.6.5. Sikre forbindelser til andre nettverk

Hvis en bruker ønsker å koble til ytterligere komponenter fra en eksisterende tilkobling til en maskinkomponent, bør alle prosessene som er nevnt for å sette opp og avslutte en ekstern tilkoblingssesjon og etablere tilgangsprosesser gjennomføres for hver videre tilkobling av denne typen. Spesielt bør autorisasjon gjennomføres hvis målkomponenten er i et annet nettverkssegment eller -sone.

7.1.7. Overvåking og gjenkjennelse av angrep

Det er urealistisk å anta at en maskin er helt sikker mot angrep, selv når den nyeste sikkerhetsteknologien brukes. Funksjoner for å gjenkjenne angrep og andre sikkerhetsrelaterte hendelser bør være tilgjengelige. Alle loggførte data skal lagres sentralt når det er mulig for å gjøre den påfølgende evalueringen enklere. 

7.1.7.1. Overvåk all tilgang til maskinkomponenter

Først skal all tilgang til maskinkomponenter logges og lagres for videre behandling. All tilgang fra upålitelige nettverk bør loggføres spesielt. Dette bør til og med omfatte tilgang fra komponenter til tjenester i maskinen. Identiteten til brukerne/ komponentene som er involvert og tid, varighet og type tilgang er minimumskravet for hva som bør bevares for senere evaluering. Overvåkningssystemet skal være adskilt fra det produktive systemet. Hvis operatøren allerede bruker et SIEM-system (sikkerhetsinformasjon og hendelsesovervåking), bør muligheten for tilkobling til anlegget undersøkes. 

7.1.7.2. Integrere overvåkningsfunksjoner i kontrollpanelet

Funksjonene for overvåking av tilgang og andre sikkerhetsrelaterte hendelser skal integreres direkte i maskinens kontrollstasjon. Dette betyr at kontrollstasjoner, og andre systemer som er direkte overordnede til maskinen, bør støtte muligheten for opptak, akkurat som maskinen selv gjør. Kontrollstasjonen blir dermed en sentral komponent for logging og prosessering av sikkerhetsrelaterte data, og det er grunnen til at den ekstra kommunikasjonsbelastningen på en slik komponent bør tas i betraktning under prosjekteringen og utviklingen av maskinen.

7.1.7.3 Virusskanner

Datamaskiner som er direkte koblet til maskinene er ofte en inngangsport for skadevare, så bruk av virusskanner på disse komponenter er anbefalt. For å sikre et rudimentært sikkerhetsnivå mot standard skadevare, må signaturene oppdateres jevnlig.

7.1.7.4. Nettverks-IDS og anomalipåvisning i komplekse maskiner

Inntrengingsdeteksjonssystemer (IDS) og inntrengningsforebyggende systemer (IPS) bør implementeres for nettverksovervåking av komplekse maskiner, eller bruken av disse aktiveres av operatøren. Spesielt sårbare komponenter skal være utstyrt med tilsvarende funksjonalitet slik at uønsket atferd kan oppdages basert på heuristikk.

7.1.8. Plan for gjenoppretting

Både anleggsprodusenten og integratoren bør definere en utvinningsplan som tilbakestiller anlegget til en pålitelig tilstand i tilfelle funksjonsfeil eller angrep. 

7.1.8.1. Opprette sikkerhetskopisystemer

Sikkerhetskopieringssystemer skal være fullt integrert i maskinens utviklingsprosess, og flere sikkerhetskopier anbefales for å sikre et passende nivå på datatilgjengelighet og pålitelighet. Hvis sentrale sikkerhetskopitjenere brukes, bør maskinen ha funksjoner for sikker datautveksling med disse serverne. 

7.1.8.2. Opprette vanlige sikkerhetskopier

Alle data som kreves for å betjene maskinen, bør lagres i sikkerhetskopisystemer med jevne mellomrom. Tidsintervallene og krypteringskravene for dette bør spesifiseres av integratoren eller operatøren basert på trusselsituasjonen og behovet for beskyttelse.

7.1.8.3. Kontrollerer sikkerhetskopier for utvinning

Alle sikkerhetskopier bør sjekkes for evnen til utvinning regelmessig. Redundans i sikkerhetskopisystemene skal garantere at hvis gjenoppretting med en sikkerhetskopi mislykkes, kan en annen sikkerhetskopi brukes. 

7.8.4 Gjenopprette en pålitelig tilstand etter en funksjonsfeil / angrep

Etter et angrep må maskinen gjenopprettes til en pålitelig tilstand.

7.1.8.5 Gjenopprette krypterte data

Når maskinen gjenopprettes til en pålitelig tilstand, vil noen data bare være tilgjengelig i kryptert form. Sikkerhetskopieringssystemene må tillate gjenoppretting av krypterte data.

7.1.9 Sikre produktets livssyklus

Anleggsprodusenten bør definere og sikre en sikker livssyklus for maskinen. 

7.1.9.1 Overvåking av sårbarheter

Maskinprodusenter, integratorer og operatører bør være i en posisjon til å klassifisere nyoppdagede angrepsvektorer etter sitt risikopotensial. 

7.1.9.2 Produsentovervåking av trusselsituasjonen

Produsenten skal være klar over den aktuelle trusselsituasjonen og innlemme dette i utviklingen av nye maskiner.

7.1.9.3 Respons på sårbarheter

En forhåndsdefinert prosedyre som skal følges når en sårbarhet blir oppdaget, er et minimumskrav for å reagere riktig. Det bør derfor defineres interne prosesser som kan startes når som helst når det er behov.

7.1.9.4 Bestemme kommunikasjonskanalene i anlegget

Personen som skal kontaktes når sårbarheter oppdages eksternt bør være tydelig definert, likedan prosedyren for videreformidling av denne informasjonen i selskapet (hvordan og til hvem). Når det gjelder kommunikasjon utenfor selskapet, anbefales det at produsenten/ integratoren informerer operatøren tidlig om eventuelle sårbarheter som er identifisert for den berørte maskinserien.

7.1.9.5 Vedlikeholdsstyring

Produsenten bør definere en sikker prosess for håndtering og integrering av «patcher». Dette inkluderer også planlegging av alle nødvendige ressurser på forhånd, samt definering av distribusjonsmekanismer for oppdateringen for å gi rask integrering. En infrastruktur for distribusjon av patcher til operatørene bør være tilgjengelig; operatørene bør vedlikeholde prosesser og infrastrukturer for å akseptere, teste og installere patcher. 

7.1.9.6 Valg av interne og eksterne ansvarlige parter

Personer som er ansvarlige for å vurdere en innkommende rapport om et svakt punkt og for utvikling og utrulling av patcher skal identifiseres. De ansvarlige parter bør gis myndighet til å handle og gis nødvendige midler for å samordne patch-håndtering effektivt. 

7.1.9.7 Håndtering av sluttstøtte (EoS)

Når støtte for en maskin tar slutt, bør en spesifisere definerte og tydelige prosesser. Hvis mulig, bør integratoren informere operatøren tidlig om at støtten, spesielt i form av patcher, er i ferd med å utløpe. 

7.1.9.8 Håndtering ved utfasing

Når en maskin skal fases ut, bør en sikker utfasingsprosess defineres. Dette skal spesielt sikre at uautoriserte tredjeparter ikke får tilgang til sensitive data. Det viktigste poenget her er destruksjon av maskinens masselagring. Ødeleggelse av spesielt kritiske komponenter kan også redusere risikoen for reverse engineering.

7.1.10 Tilpassing og testing av komponenter

Anleggets definerte sikkerhetsfunksjonalitet bør sjekkes regelmessig for å sikre at den er robust selv i et dynamisk miljø. 

7.1.10.1 Juster standardinnstillinger

Man må være oppmerksom på at standardinnstillingene blir endret både under den første installasjonen og etter hver gjenoppretting av en pålitelig tilstand. Standardpassord for administratorkontoer (se avsnitt 3) og deaktiverte sikkerhetsfunksjoner er vanlige innganger for angrep. Alle justeringer og innstillinger skal logges for påfølgende tester. Å justere standardinnstillingene bør sikre at den nye konfigurasjonen passer for trusselsituasjonen.

7.1.10.2 Tilpasse maskinvarekonfigurasjonen

Det er viktig å sjekke om den tiltenkte konfigurasjonen tilbyr passende sikkerhetsfunksjonalitet for trusselsituasjonen før integrering.

7.1.10.3 Internettilgang i ICS-nettverket

Det er viktig å sjekke om internettilgang er mulig i anleggsnettverket. I så fall er det også viktig å sjekke at denne internettilgangen ikke er i strid med den definerte sikkerhetsfunksjonaliteten til anlegget og at tilgangskomponentene er tilstrekkelig isolert fra kritiske deler av maskinen. 

7.1.10.4 Tester for bekreftelse og validering

Sikkerhetsfunksjonene til anlegget skal både verifiseres (sammenligning med spesifikasjoner) og valideres (dvs. kontrollere egnetheten til sikkerhetsfunksjonene).

7.1.10.5 Tester for programvare og informasjonsintegritet

Integriteten til alle maskinens programvarekomponenter og konfigurasjonsdata bør sikres. Et alternativ her er digitale signaturer, som sjekkes hver gang konfigurasjonsdataene importeres og hver gang et program kjøres.

7.1.10.6 Velge sikre komponenter

Leverandører integrerer ofte eksterne komponenter i maskinen. I slike tilfeller bør integratoren sjekke om de eksterne komponentene tilfredsstiller de identifiserte sikkerhetskravene.

7.1.11 Avstå unødvendige komponentfunksjoner

En maskin som helhet eller individuelle komponenter i anlegget har ofte tilgang til en rekke funksjoner som ikke brukes til drift i visse applikasjonsmiljøer. Denne typen overflødige produktfunksjoner kan øke det potensielle angrepsområdet betydelig og er ofte inngangsport for angripere. Funksjoner som er irrelevante for maskinens bruksområde, bør ikke inkluderes. 

7.1.11.1 Fjerne unødvendig programvare og tjenester

Det første trinnet er å fjerne alle tjenester og programvarekomponenter som ikke umiddelbart er nødvendige for å betjene maskinen. Hvis de ikke kan fjernes, er alternativet å deaktivere dem. Valget av programvaren som faktisk er aktivt skal være fleksibelt og implementeringen lett tilgjengelig for integratoren og operatøren. Spesielt funksjonsavhengigheter bør demonteres automatisk. Ideelt sett velger integratoren de funksjonene som er nødvendige for drift, og bare disse og funksjonene/ programvaredelene som er avhengige av dem, er integrert i maskinen. 

7.1.11.2 Fjerne/ deaktivere alle maskinvarekomponenter som ikke er i bruk

Tilsvarende bør ubrukte maskinvarekomponenter også fjernes i mulig grad. Spesifikk justering av maskinvarekonfigurasjonen kan være veldig kompleks i noen maskiner, så det bør i det minste være mulig å deaktivere alle maskinens maskinvarekomponenter (f.eks. unødvendige grensesnitt). På samme måte som fjerning av unødvendig programvare og tjenester, bør maskinen ideelt sett automatisk deaktivere alle maskinvarekomponenter som ikke er i bruk.

7.1.12 Komponentherding - En kjede er bare så sterk som dens svakeste ledd

Økende tilkoblingsmuligheter og mer intelligente funksjoner gjør at sikkerheten ikke lenger kan implementeres gjennom seksjon alene. Sikre, utprøvde komponenter vil spille en stadig viktigere rolle.

7.1.12.1 Komponenter kan bare utføre fast kode

Bare programmer der utviklingsprosessen tar et minimum av kvalitetskriterier, bør kjøres på maskinen. 

7.1.12.2 Sikkerhetstester som en integrert del av utvikling og systemintegrasjon

Sikkerhetstester skal være en integrert del av utvikling og systemintegrasjon. 

7.1.12.3 DoS-beskyttelse

Når starten av et DoS-angrep oppdages, bør blokkeringslister over avsenders IP-adresser legges inn automatisk i brannmuren. Om mulig skal tjenestene spres over flere virtuelle enheter gjennom distribusjon av serverbelastning, slik at belastningen kan spres effektivt til intakte enheter hvis den fysiske datamaskinen svikter. 

7.1.12.4 Hvit- og svartelisting av applikasjoner

Hvitlisting av applikasjoner reduserer anleggets potensielle angrepsområde ytterligere. En måte å gjøre dette på er bare å la programmer som er signert (av maskinens produsent) kjøres på maskinen. Hver gang et program åpnes, sjekker det om programsignaturen kan verifiseres riktig og om utstederen er på hvitelisten. Svartelisting kan også brukes på samme måte som hviteliste; den ekskluderer programmer som er kjent for å være ondsinnede og de som rett og slett ikke er tillatt (for eksempel Internet Explorer, Java, Flash). Svartelisting krever regelmessige oppdateringer og dermed en passende oppdateringsprosess i anlegget.

7.1.12.5 Redusere systemkompleksiteten

Når maskinen er utviklet, skal kompleksiteten til komponentene og systemet som helhet holdes så lavt som mulig. Funksjonsreduksjon er nøkkelpunktet her, og behandles separat i kapittel 11. I tillegg bør lignende grupper av funksjoner settes sammen i moduler og komponenter, noe som ofte gjør det mulig å kartlegge abstraksjonsnivåene til maskinens funksjoner til komponenter. Dette gjør det lettere å vedlikeholde, videreutvikle og endre maskiner og til slutt redusere det potensielle angrepsområdet. 

7.1.12.6 Beskyttelse av feltinnretninger som befinner seg utenfor anlegget mot fysiske angrep

Hvis maskinen implementeres som et distribuert system, er det viktig å sikre at eksterne feltanordninger utenfor anlegget er beskyttet. Sikkerhet mot fysiske angrep er spesielt viktig her.

7.1.12.7 Sikring av elektroniske eksterne grensesnitt

Maskinens digitale eksterne grensesnitt skal beskyttes mot tilgang som ikke er beregnet av produsenten. Denne typen beskyttelse utføres i utgangspunktet basert på fullstendig identifikasjon og dokumentasjon av alle implementerte grensesnitt. For å logge alle grensesnitt som er kalt opp av andre systemer, bør alle kommunikasjonsveier til eksterne programvaremoduler defineres spesielt og tydelig dokumenteres i et kontekstdiagram.

7.1.13 Isolasjonsteknikker inne i maskinen/ virtualiseringen

For å redusere effekten av en funksjonsfeil i en maskin så mye som mulig, bør de enkelte programvarekomponentene skilles fra hverandre ved bruk av passende isolasjonsteknikker. Dette kan gjøres ved å bruke virtualiseringsløsninger og Trusted Execution Environments.

7.1.13.1 Beskyttelse mot ondsinnet kode ved sandboksing og virtualisering

Skader fra ondsinnet kode kan ofte begrenses ved å kjøre maskinprogrammer i en sandkasse eller et virtuelt miljø. For det første, gjør dette det mulig å begrense rettighetene og funksjonene som er tilgjengelige for programmet, noe som ofte fører til et betydelig redusert potensielt angrepsområde. For det andre, er effektene av et vellykket angrep vanligvis begrenset til det lokale virtuelle miljøet.

7.1.13.2 Maskinen bør implementere begrensninger for flyttbar kode

Bare programmer fra pålitelige kilder skal kjøres. Som et svakere alternativt kan programmer av ukjent opprinnelse kjøres med sterkt reduserte rettigheter. Sandboksing og virtualisering lar programmer kjøres i miljøer med forhåndsdefinert og begrenset funksjonalitet.

7.1.13.3 Avgrense drifts- og konfigurasjonsdataene for applikasjonsprogrammer

Virtualiseringsteknikker muliggjør isolering av drifts- og konfigurasjonsdata fra applikasjons-programmer spesielt.

7.1.14 Kryptografi - Boken med standardisert forsegling

Bruken av sikre kryptografiske prosesser danner grunnlaget for bruk av sikre protokoller, for autentiseringstiltak og for å sikre trådløse teknologier. Alle kryptografiske algoritmer og parametere må være moderne.

7.1.14.1 Implementering av standardiserte algoritmer

Når det velges prosesser, bør produktets livssyklus konsulteres, slik at utviklingen av datakraft kan tas i betraktning for anlegg som brukes over lengre tid over mange år. Nøkkellengden bør velges i henhold til den planlagte bruksperioden. Prosesser for utskifting eller oppdatering av chiffer-suitene bør leveres når det er mulig.

7.1.14.2 Integrering i eksisterende offentlige nøkkelinfrastrukturer

Anleggsprodusenten skal sørge for at anlegget kan integreres i eksisterende PKI-er. Spesielt skal det være mulig å bruke gjeldende sertifikater for eksisterende PKI-er. En sikker prosess for generering, integrering og håndtering av tilsvarende kryptografisk materiale bør defineres for dette. For å tillate at sertifikater kan oppdateres under drift, bør sertifikatets livssyklusadministrasjon (CLM), eller muligheten til å bruke det, leveres til operatøren. Komponenter basert på Microsoft Windows kan bruke Simple Certificate Enrollment Protocol (SCEP) og Network Device Enrollment Service (NDES) som protokoller hvis en Microsoft CA brukes. Når sertifikater er bekreftet, må eier, utsteder og gyldighetsstatus kontrolleres. Videre bør sertifikatkjedene være sjekket fullstendig og så få rotsertifikater som mulig bør inkluderes i listen over pålitelige sertifikater.

7.1.15 Fastsette sikkerhetskrav for leverandører - Forklar og krev hva du vil

Hvis leverte komponenter er integrert i anlegg og ikke oppfyller de identifiserte sikkerhetskravene, kan dette undergrave maskinens sikkerhetskonsept. Som det svakeste leddet i kjeden er disse komponentene ofte inngangsporten for angripere. Egnede forskrifter for sikre tredjeparts-komponenter og sikker integrasjonsprosess for medfølgende komponenter må defineres.

7.1.15.1 Kontroller sikkerhetskravene for leverte komponenter

Sikkerhetskravene som er identifisert av produsenten/ integratoren av anlegget, skal oppfylles for hver komponent innenfor sitt funksjonsområde. Sikkerhetskravene kan sjekkes av integratoren eller leverandøren, eller av begge sammen.

7.1.15.2 Å identifisere sin egen rolle som leverandør

Hvis maskinen er integrert i et annet produkt som en underkomponent, bør produsenten gi kunden dokumentasjon på alle sikkerhetstiltak. Dokumentasjonen skal gjøre det mulig for vedkommende å sjekke om komponentene som skal leveres oppfyller beskyttelsesbehovene i målsystemet.

7.1.15.3 Outsourcet programvareutvikling

Der programvare eller deler derav leveres av tredjepart, bør det inkluderes i sikker utviklingsprosess. Dette gjelder spesielt biblioteker og kode fra åpne depoter.

7.1.16 Dokumentasjon

Sikkerhetstiltak kan bare implementeres jevnt hvis de er fullstendig dokumentert. 

7.1.16.1 Grensesnitt

Alle sikkerhetsrelaterte grensesnitt skal identifiseres og dokumenteres. Dette inkluderer spesielt feilsøkingsgrensesnitt i maskinvare og programvare. 

7.1.16.2 Etablerte prosesser

Alle organisatoriske og tekniske prosesser adressert i dette dokumentet skal identifiseres og dokumenteres. Organisasjonsprosedyren og de ansvarlige rollene bør stamme fra dokumentasjonen. Selv noen som ikke er kjent med prosessen, skal kunne kjenne igjen trinnene som skal tas i en gitt situasjon.

7.1.16.3 Dokumentasjon av risikoanalyse

Resultatene fra risikoanalysene (se avsnitt 1) skal dokumenteres og arkiveres for senere bruk. Dette gjelder spesielt dokumenterte trusselmodeller. Dokumentasjonen skal vise metodene som risikoanalysen var basert på og informasjon som ble brukt for å vurdere effekten og sannsynligheten for angrepene. Risikoanalysen skal kun dokumenteres internt.

7.1.16.4 Distribuerte rettigheter

Fordelingen av rettighetene til brukerne som er definert i avsnitt 3, skal dokumenteres. Det er spesielt viktig å logge endringer i rettighetsfordelingen, slik at de kan brukes til sikkerhetsanalyser på et senere tidspunkt.

7.1.16.5 Maskinbeholdning

Produsenten bør lage en maskinbeholdning som tar hensyn til alle relevante enhets-, kommunikasjons- og administrasjonsaspekter (inkludert maskinvare og programvare). Ideelt sett bør maskinen kunne generere en rapport om komponentene som for øyeblikket er installert, inkludert deres egenskaper. Et diagram over komponentene skal illustrere den funksjonelle forbindelsen mellom dem.

7.1.16.6 Dokumenthåndtering

Organisasjonsprosesser for å lage, distribuere og gi ut dokumenter bør defineres. De aktuelle dokumentene må sjekkes med jevne mellomrom for å sikre at de er oppdaterte.

7.1.16.7 Sikkerhetshendelser

Alle sikkerhetshendelser skal dokumenteres og arkiveres. 

7.1.16.8 Strategi og sikkerhetskontroller

Maskinens sikkerhetskonsept og alle sikkerhetstiltak skal dokumenteres, samt funksjonen til sikkerhetstiltakene. Dette inkluderer implementering og konfigurering, samt informasjon om vedlikehold. 

7.1.16.9 Organisasjonsprosesser og roller

Alle sikkerhetsrelaterte organisasjonsprosesser og de ansvarlige parter og kontakter i hvert tilfelle skal dokumenteres.

7.1.17 Opplæring i cybersikkerhet

Å øke ansattes kompetanse når det gjelder informasjonsteknologi generelt, og IT-sikkerhet, nettverkssikkerhet og funksjonene til IT i produksjonsanlegg spesielt, er et presserende og viktig tiltak for bærekraftig utvikling og forbedring av sikkerhetsmiljøet. Det krever at nye krav legges til etablerte stillingsprofiler (for eksempel gjennom avansert opplæring).

7.1.17.1 Bevissthet

Ethvert sikkerhetstiltak er bare så sterkt som det svakeste leddet; uoppmerksomhet, uvitenhet og uaktsomhet kan føre til kritiske hull. Hver ansatt må forstå at de er en del av noe større når det gjelder sikkerhet, og deres bidrag kan ha en avgjørende innflytelse på kvaliteten på anleggets sikkerhet. Alle linjeledere, ledelse, ansatte og midlertidig ansatte skal ha viktigheten av sine handlinger vektlagt og opplyst om etterlevende oppførsel. Generell instruksjon om grunnleggende IT-sikkerhetsemner beskytter ikke bare anlegget i seg selv - produktet - men også hele selskapet. Bare de som kjenner risikoen, kan sørge for tilstrekkelig sikkerhet!

7.1.17.2 (Programvare)utviklere og designere

Designere, utviklingsingeniører og programvareutviklere (som IT-spesialister i applikasjonsutvikling) bør få regelmessig opplæring i relevansen av kodesikkerhet. Å dekke generelle konsepter som sikker utviklingslivssyklus (SDL) og det grunnleggende om autentisering, autorisasjon og sesjonsstyring er avgjørende for å forhindre vanlige feil og forbedre kvaliteten på utviklingsprosessen. Kjernekrav for utviklere inkluderer følgende: 

• Introduksjon til SDL
• Gjennomføre kodevurderinger manuelt
• Bruke statiske verktøy for kodegjennomgang
• Gjennomføre sikkerhetstester
• Metoder for sikker programvareutvikling
• Klassifisering av data (tillatelse, tilgang)
• Forskjell mellom kontor IT og ICS
• Potensielle angrepsmål innen industriell IT systemer og komponenter (ICS / SCADA)
• Spesielle funksjoner i bussnettverk
• Sikkerhetskontroller for ICS / SCADA-enheter
• Nettverkssegmentering og brannmurkonsepter
• Integrering i sikkerhetsstyring 

7.1.17.3 Ansvarlig part for produktsikkerhet

Selv om flertallet av selskapene ennå ikke har en produktsikkerhetsansvarlig, er behovet for denne funksjonen udiskutabel. For å kunne utføre oppgavene sine, bør PSO ha god grunnleggende kunnskap om IT-infrastruktur og ICS/ SCADA-teknologi. I tillegg er det viktig at PSO tar opp temaet sikkerhetsstyring, slik at de kan definere og kommunisere sikkerhetsstrategien for selskapets egne produkter sammen med Chief (Information) Security Officer og produktlederne. For å gjøre dette, trenger PSO dypere innsikt i: 

• Sikkerhetsanalyse og risikostyring
• Risikoanalyse og vurdering
• Forskrifter og retningslinjer
• Svakt punkt og hendelseshåndtering
• Produktets livssyklus IT / anlegg
• Rapportering og rapporteringskanal for hendelser

Derfor er cybersikkerhet en av de største bekymringene ved IoT og dette må håndteres samtidig som kravet for sikkerhet, ettersom begge forhold er tett sammenkoblet med den fysiske verden. Et annet viktig aspekt er hvem som vil være ansvarlig for drift av IoT, spesielt med tanke på den iboende kompleksiteten og heterogeniteten til IoT-økosystemet og behovet for skalerbarhet. 

Denne studien har identifisert følgende problemer som hindrer etablering og konsolidering av sikre IoT-økosystemer.

En meget stor angrepsflate

Truslene og risikoene knyttet til IoT er mangfoldige og utvikler seg raskt. Tatt i betraktning deres innvirkning på innbyggernes helse, sikkerhet og personvern er IoT-trusselandskapet ekstremt variert. Når det gjelder personvern, er IoT basert på innsamling, utveksling og behandling av store datamengder fra en rekke kilder, noen ganger inkludert sensitive data, og dette kan være uklart for brukerne.

Begrensede enhetsressurser

Bruk av konvensjonell IoT sikkerhetspraksis kan kreve en betydelig omforming på grunn av tekniske begrensninger. De fleste IoT-enheter har begrensede funksjoner, f.eks. prosessering, minne og strøm, og derfor kan avanserte sikkerhetstiltak ikke implementeres effektivt.

Komplekse økosystem

Sikkerhetsproblemer forverres siden IoT ikke bør sees på som en samling av uavhengige enheter, men snarere et mangfoldig og bredt økosystem som involverer aspekter som IoT enheter, kommunikasjon, grensesnitt og mennesker.

Fragmentering av standarder og forskrifter

Fastsettelsen av standarder og forskrifter for implementering av IoT-sikkerhetstiltak og god praksis er fragmentert og langsom, mens veksten av nye teknologier er stadig større.

Utbredt bruk av IoT

I senere tid har man stadig oftere sett at kritisk infrastruktur går over til smart infrastruktur med utgangspunkt i gamle systemer.   

Cybersikkerhetsintegrasjon

Dette er en veldig utfordrende oppgave, på grunn av potensielt motstridende synspunkter og krav fra alle involverte interessenter. For eksempel kan forskjellige IoT-enheter og systemer være basert på forskjellige autentiseringsløsninger, som må integreres og gjøres interoperable.
Sikkerhetsaspekter: De er veldig relevante i IoT-sammenheng på grunn av aktuatorer, som styrer den fysiske verden. Cybersikkerhetstrusler kan bli sikkerhetstrusler som i for eksempel de nylige cybersikkerhetsangrepene på oppkoblede kjøretøy.

Lave kostnader

Grunnet de avanserte funksjonalitetene IoT tilbyr til flere kritiske sektorer, som bl.a. datastrømmer og avansert overvåking og integrasjon, innser stadig flere potensialet for betydelige kostnadsbesparelser. Likevel er det ofte slik at de lave kostnadene som vanligvis er forbundet med IoT-enheter og systemer kan ha uønskede effekter når det gjelder cybersikkerhet. Produsenter kan være fristet til å begrense sikkerhetsfunksjonene for å sikre lave kostnader, og den innebygde produktsikkerheten vil derfor ikke være i stand til å beskytte mot visse typer IoT-angrep.

Mangel på kompetanse

Cybersikkerhet er et nytt domene, og derfor er det mangel på mennesker med riktig kompetanse.

Cybersikkerhetsoppdateringer

Det er ekstremt utfordrende å kjøre sikkerhetsoppdateringer på IoT, ettersom brukergrensesnittene ikke tillater tradisjonelle oppdateringsmekanismer. Å sikre seg disse mekanismene er i seg selv en risikabel oppgave, spesielt med tanke på trådløse oppdateringer.

Usikker programmering

Ettersom time-to-market for IoT-produkter er kortere enn i andre domener, har man også mindre tid for å utvikle sikkerhet og personvern i produktdesignfasen. Av denne grunn, og noen ganger også på grunn av budsjettproblemer, legger selskaper som utvikler IoT-produkter generelt mer vekt på funksjonalitet og brukervennlighet enn på cybersikkerhet.

Uklare forpliktelser

Mangelen på en klar ansvarfordeling kan føre til uklarheter og konflikter i tilfelle en sikkerhetshendelse, spesielt med tanke på den store og komplekse forsyningskjeden som er involvert i IoT. Spørsmål angående hvordan man skal håndtere sikkerheten hvis en enkelt komponent deles av flere parter, og hvordan ansvaret skal håndheves, bør besvares. 

For å organisere de forskjellige domenene av sikkerhetstiltak på en logisk måte, ble de klassifisert i tre hovedgrupper: 

• Retningslinjer
• Organisatorisk praksis
• Teknisk praksis 

Disse gruppene gir en kategorisering på et overordnet nivå og er i tråd med klassifiseringen av ENISAs “Baseline Security Recommendations for IoT”.

Denne første gruppen av sikkerhetstiltak henviser for det meste til retningslinjer og prosedyrer som bør etableres i organisasjoner for å sikre et godt nivå av cybersikkerhet, spesielt når det gjelder IoT-løsninger. I tillegg har personvernproblemer blitt dekket i sammenheng med produsenter som skal sørge for at løsningene deres ikke bryter personvernforskrifter, og operatører som bør være følsomme for personvernrelaterte risikoer og gjort oppmerksom på hvordan man bruker IoT-enheter uten å avsløre brukernes personlige informasjon.

7.3.1 Sikkerhet ved design

Sikkerhetstiltak som bør brukes helt fra begynnelsen av produktutviklingen:

• PS-01: Behandle IoT cybersikkerhet som en syklus, ikke som en ende-til-ende-prosess, ved å ta en sikkerhet-ved-design-tilnærming fra perspektivet til enheter og infrastruktur på hvert trinn i en smart produksjonssystemutviklingslivssyklus (SDLC).
• PS-02: Adresser cybersikkerhet gjennom innebygde funksjoner i endepunktene i stedet for bare på nettverksnivå.
• PS-03: Utstyr, som anses hensiktsmessig etter en sikkerhets- og trygghetsvurdering, til og med de mest grunnleggende tilkoblede enhetene har svært begrensede behandlingsmuligheter (f.eks. aktuatorer, konvertere) med identifikasjons- og autentiseringsfunksjoner og sikrer kompatibilitet med IAM-klasseløsninger.
• PS-04: Utfør risiko- og trusselanalyse som involverer cybersikkerhetseksperter fra de tidlige stadiene av designprosessen for å finne ut hvilke sikkerhetsfunksjoner som vil være nødvendige.
• PS-05: Hvert designdokument inneholder et kapittel som tar for seg sikkerheten til alle informasjons- og kontrollsystemene i det industrielle miljøet.

7.3.2 Personvern etter design

Sikkerhetstiltak knyttet til personvern og beskyttelse av personopplysninger. Disse tiltakene bør brukes fra de første stadiene av produktutviklingen:

• PS-06: Adresser personvernrelaterte spørsmål basert på gjeldende lokale og internasjonale forskrifter, for eksempel General Data Protection Regulation (GDPR).
• PS-07: Definer omfanget av dataene som skal behandles av enheten, så vel som målet med denne behandlingen i prosjekteringsfasen, og unngå å samle inn eller sende unødvendige sensitive data.
• PS-08: Etablere en fysisk plassering av datalagring og definere hvilke organisasjoner data skal overføres mellom, og begrense tilgangen til innsamlede personopplysninger kun til autoriserte personer.
• PS-09: Gjennomfør en PIA (Privacy Impact Analysis) for dataene som skal behandles av enheten.
• PS-10: Separere data som kan brukes til å identifisere en person fra annen informasjon og sikre dens sikkerhet, f.eks. gjennom kryptering av all personlig informasjon som er overført i IoT-miljøet.

7.3.3 Kapitalforvaltning

Sikkerhetstiltak vedrørende eiendomsfunn, administrasjon, overvåking og vedlikehold:

• PS-11: Bruk verktøy som støtter kapitalforvaltning som dynamisk kan oppdage, identifisere og oppregne eiendeler som er spesifikke for organisasjonen og det industrielle miljøet.
• PS-12: Forsikre deg om at firmaet ditt har en jevn og oppdatert eiendelbeholdning.
• PS-13: I komplekse industrielle miljøer med gamle systemer, bruk passive overvåkingsenheter der det er mulig eller gjennomgå en testfase før implementeringen hvis du vurderer aktive overvåkingsverktøy.
• PS-14: Bruk en sentralisert eiendelsbeholdning for hele det datastyrte miljøet i et produksjonsanlegg.
• PS-15: Vurder sikker administrasjon av eiendeler med administrasjon av infrastruktur og sikkerhetsenheter via et dedikert styringsnettverk.
• PS-16: Introduser en ny enhet i systemet bare i henhold til en etablert, akseptert og kommunisert endringshåndteringsprosess.
• PS-17: Unngå bruk av flyttbare enheter som deaktiverer USB-portene hvis det ikke er et akseptert forretningskrav. 

7.3.4 Risiko- og trusselstyring

Sikkerhetstiltak angående den anbefalte tilnærmingen til risiko- og trusselstyring tilpasset industri 4.0-miljøet:

• PS-18: Vedta en tilnærming til risikostyring dedikert til industri 4.0 og Smart Manufacturing med tanke på nye parametere, trusler og angrepsscenarioer.
• PS-19: For kritisk infrastruktur i produksjonsmiljøer, etabler en rekke risikostyringsområder som er helt på linje med bedrifts-, sikkerhets- og miljøaspektet. Vurder og karakteriser trusler, sårbarheter og beskyttelsestiltak mot disse risikostyringsområdene.
• PS-20: Etabler en risiko- og trusselstyringsprosess i henhold til individuelle behov og sikkerhetskrav i din bedrift.
• PS-21: Utfør risikoanalyse som inkluderer cybersikkerhetsaspekter ikke sjeldnere enn en gang i året. Integrer den også med andre prosesser, for eksempel endringshåndtering, hendelseshåndtering og sårbarhetshåndtering. Risikovurderingen skal dekke teknisk og prosedyremessig testing av effektiviteten til sikkerhetspolicyene og prosessen.
• PS-22: Vurder å innlemme etterretningsprosess i trusselstyringen til selskapet ditt vedrørende å stole på forskjellige informasjonskilder og å dele informasjon med pålitelige industripartnere, ISAC og CERTer.
• PS-23: Fra et organisasjonsperspektiv, overvåk utvalgte trusler og bestem deres innvirkning på systemer ved å utføre en risikoanalyse.
• PS-24: Når det gjelder risikostyring, bruk to forskjellige tilnærminger samtidig: ovenfra-og-ned adresser cybersikkerhet fra det organisasjonsdekkende perspektivet og nedenfra-og-opp og gir et veldig detaljert og detaljert syn på selskapets situasjon.

7.3.5 Organisatorisk praksis

Organisasjonsprinsipper og styring er uunnværlige faktorer som vanligvis er kritiske når det gjelder selskapets sikkerhet. Følgende sikkerhetstiltak forklarer hvordan «smart manufacturing» og andre industri 4.0-selskaper skal operere, hvilke organisatoriske regler og ansvar de skal etablere og følge og hvilken tilnærming de skal ta i retning av sine ansatte og tredjepartsentreprenører for å effektivt håndtere cybersikkerhetshendelser, håndtere sårbarheter og sikre sikkerhet av IoT-løsninger gjennom hele deres livssyklus.

7.3.6 Endepunktets livssyklus

Sikkerhetstiltak relatert til sikkerhet i forskjellige stadier av produktets livssyklus (inkludert sluttapparater og infrastruktur, anskaffelsesprosess, forsyningskjede, overleveringsfase, bruk og end-of-life:

• OP-01: Fokus på sikkerheten til programvare og maskinvare i alle faser av endepunktets livssyklus.
• OP-02: Ta hensyn til sikkerhet i hele forsyningskjeden.
• OP-03: Vurder sikkerhetsaspekter under den samlede anskaffelsesprosessen og definer sikkerhetstiltak og krav tilpasset bestemte enheter/ løsninger.
• OP-04: Gjennomfør godkjenningstester for cybersikkerhet mot teknisk spesifikasjon under forskjellige valideringsaktiviteter eller stadier av produktets livssyklus.
• OP-05: I overleveringsfasen av prosjektgjennomføringsprosessen må du bygge og overføre all dokumentasjon, prosesser og prosedyrer.

7.3.7 Sikkerhetsarkitektur

Sikkerhetstiltak angående den arkitektoniske tilnærmingen og etablering av sikkerhetsarkitektur:

• OP-06: For å sikre sikkerhet i et datastyrt økosystem, ta i bruk en helhetlig arkitektonisk tilnærming og gå til utvikling av en risikojustert sikkerhetsarkitektur basert på forretningskrav.
• OP-07: Når du definerer sikkerhetsarkitektur, må du sørge for at den omfatter alle relevante sikkerhetsaspekter - fra organisatoriske til utfordringer med fysiske implementeringer.
• OP-08: Innen sikkerhetsarkitekturen, tildel klare roller og ansvar for sikkerhet. Definer og kommuniser roller for både OT-systemer og sikkerhetsprosesser tydelig.
• OP-09: Integrer kontroll av overholdelse til den etablerte sikkerhetsarkitekturen og sikre at alle produktene oppfyller kravene som er definert i den.

7.3.8 Håndtering av hendelser

Sikkerhetstiltak angående deteksjon og respons på hendelser som kan oppstå i industri 4.0-miljøer:

• OP-10: Definer cyberhendelser som er relevante for din organisasjon basert på selskapets område og driftsområde, og klassifiser dem i henhold til gjeldende standarder.
• OP-11: Vurder å opprette en cybersikkerhetssentral (SOC) som består av OT- og IT-cybersikkerhetsspesialister for å støtte cybersikkerhetshendelser ved å dele dem inn i spesifikke støttelinjer med passende roller og ansvar.
• OP-12: Etablere en prosess for håndtering av hendelser som består av identifisering av berørte eiendeler, identifisering og klassifisering av sårbarheter, opptrapping og varsling.
• OP-13: Oppdag og undersøk øyeblikkelig alle unormale sikkerhetsrelaterte hendelser.

7.3.9 Sårbarhetsledelse

Sikkerhetstiltak for sårbarhetsstyringsprosessen, relaterte aktiviteter og avsløring av sårbarhet:

• OP-14: Definer en omfattende sårbarhetsstyringsprosess i organisasjonen som dekker bruk av automatiske og manuelle verktøy som følge av risikoanalyse.
• OP-15: Mens du eliminerer sårbarheter, kan du begynne fra de mest kritiske og ta i betraktning kritikalitet til eiendeler og systemer.
• OP-16: Etablere en omfattende og veldefinert prosess for avsløring av sårbarheter.
• OP-17: Gjennomfør penetrasjonstester av nye IoT-løsninger i et kontrollert miljø eller før/ under idriftsettelsesfasen, regelmessig i drift og etter en viktig oppdatering av systemet.
• OP-18: Etabler et tett samarbeid med OT- og IT-avdelinger for å sikre effektivt samarbeid med systembedriftseiere, beslutningsmyndigheter og andre interessenter.

7.3.10 Opplæring og bevissthet

Sikkerhetstiltak angående den anbefalte tilnærmingen knyttet til sikkerhetstrening og bevisstgjøring hos ansatte som jobber med IoT-enheter og systemer:

• OP-19: Ta i bruk en helhetlig tilnærming til sikkerhetstrening og bevisstgjøring for de ansatte, som dekker ansatte på alle nivåer i organisasjonen og adresserer nye trusler knyttet til industri 4.0.
• OP-20: Gi alle nyansatte nettbasert opplæring før jobbstart.
• OP-21: Sørg for at sikkerhetstrening er kontinuerlig, regelmessig og oppdatert.
• OP-22: Gjennomfør opplæring for brukere av IoT på sikker bruk av enhetene og forklar teknologiene som er iverksatt for å beskytte IoT-enheter og økosystemet.
• OP-23: Vurder å kommunisere med andre selskaper på sektornivå, inkludert forsyningskjeden, og delta i internasjonal sikkerhetsinfrastruktur som er dannet for å muliggjøre diskusjon, samarbeid og etterretningsdeling på tvers av organisasjoner for å forbedre sikkerhetsbevisstheten.

7.3.11 Tredjepartsledelse

Sikkerhetstiltak relatert til tredjepartsstyring og kontroll av tredjepartstilgang:

• OP-24: Tilganger til styring- eller produksjonssystem fra tredjepart skal kontrolleres strengt. Tilgang skal bare gis ved forespørsel, i et spesifisert tidsvindu, for et spesifikt formål og minst mulig rettigheter.
• OP-25: Ikke gi en direkte forbindelse mellom leverandøren og et system i kontroll- eller produksjonssystem. Tillat bare tilgang til nødvendige valgte funksjoner og deler av nettverket.
• OP-26: Be leverandørene om informasjon angående sikkerhet for sine prosesser og forpliktelser til deres produkt, og opprett dedikerte sikkerhetskrav for leverandører og tjenesteleverandører.
• OP-27: Definer tydelig alle relevante aspekter ved partnerskapet med tredjeparter, inkludert sikkerhet, innenfor de aktuelle avtaler og kontrakter.

7.3.12 Teknisk praksis

Bortsett fra å iverksette retningslinjer og organisasjonspraksis, må sikkerhet også adresseres gjennom de best tilpassede tekniske mulighetene for IoT-løsninger og miljøene der de er utplassert. De tekniske sikkerhetstiltakene som er oppført nedenfor utgjør et siste stykke av puslespillet som gjør at industri 4.0-bedrifter kan forbedre sikkerhetsnivået. Denne delen gir en oversikt over hvilke tekniske sikkerhetstiltak som skal gjennomføres i enhetene, samt tilsvarende løsninger og hvordan de skal implementeres. Vi diskuterer også anbefalte metoder for smarte produksjonsbedrifter for å sikre motstandskraft i infrastrukturen og kontinuiteten i produksjonsprosessene.

7.3.13 Tillit og integritetsledelse

Sikkerhetstiltak som kan bidra til å sikre integriteten og påliteligheten til data og enheter:

• TM-01: Kontroller programvarens integritet før du begynner å kjøre den, og forsikre deg om at den kommer fra en pålitelig kilde (signert av leverandøren) og at den er ervervet på en sikker måte.
• TM-02: Autoriser alle IoT-enheter i OT-nettverket ved å bruke riktige metoder, f.eks. digitale sertifikater/ PKI.
• TM-03: Definer datautvekslingskanaler mellom IoT-enheter i form av en hviteliste og velg bare sikre kanaler der det er mulig.
• TM-04: Iverksette hvitelister over applikasjoner og gjennomgå listen minst årlig og i tilfelle endring av systemet.
• TM-05: Sikre produktdataintegritet gjennom bruk av passende kryptografiske mekanismer og nøkkellagring tilpasset prosesseringsmulighetene til de implementerte løsningene.
• TM-06: Overvåke produksjonsdataene under lagring og under overføring, for å identifisere potensiell uautorisert datamodifisering.

7.3.14 Skysikkerhet

Sikkerhetstiltak angående ulike sikkerhetsaspekter ved skytjenester:

• TM-07: Baser dine beslutninger om valg av type sky på en vurdering av virksomhet og påvirkning av personvern, og ta også hensyn til lover og forskrifter som gjelder leverandøren av skysikkerhetens land og tilstedeværelsespunkter.
• TM-08: Inkluder sikkerhets- og tilgjengelighetsaspekter i avtaler med skysikkerhetsleverandører, der det er relevant.
• TM-09: I sammenheng med skybasert applikasjon og sentraliserte systemer, unngå enkle sviktpunkter.
• TM-10: Finn kritiske systemer og applikasjoner i de private, eller i det minste hybride, distribusjons-modellene og gjennomfør en risikoanalyse i forkant hvis du vurderer bruk av en offentlig skytjeneste.
• TM-11: For å senke risikoen knyttet til skyangrep, ta i bruk en sikkerhetsmetode med nullkunnskapbevis, og beskytt alle data i skyen og ved overføring.

7.3.15 Forretningskontinuitet og bedring

Sikkerhetstiltak som gjelder utvikling, testing og gjennomgang av selskapets plan for å sikre resistens og kontinuitet i driften i tilfelle sikkerhetshendelser:

• TM-12: Fokus på å sikre resistens i industri 4.0-systemer ved å lage en forretningskontinuitetsplan (BCP) og katastrofegjenoppretningsplan (DRP). Test planene med jevne mellomrom og tilpass dem i henhold til erfaringer fra tester og faktiske sikkerhetshendelser.
• TM-13: Definer kritiske forretnings- og teknologiske prosesser og bestem i hvilken grad de påvirker forretningskontinuiteten.
• TM-14: Utfør trussel- og risikovurdering og utvikle skriftlige prosedyrer for hvordan man går tilbake til den normale - veldefinerte - driftstilstand skreddersydd til vurderingens resultater.
• TM-15: Vurder beredskapsplanlegging etter å ha gjennomført en risikoanalyse. Definer beredskapsplaner og test dem i kontrollerte øvelser. Gjennomgå planen regelmessig og juster den ved behov.
• TM-16: Ta med tredjepartsaspekter i forretningskontinuitet og gjenoppretningsplaner.
• TM-17: Definer viktige parametere for bedriftens forretningskontinuitet, for eksempel et gjenoppretningstidsmål, gjenoppretningspunktmål, maksimalt tolererbart avbrudd og minimum forretningskontinuitetsmål.

7.3.16 Maskin-til-maskin-sikkerhet

Sikkerhetstiltak angående nøkkellagring, kryptering, inndatavalidering og beskyttelse i maskin-til-maskin-kommunikasjonssikkerhet:

• TM-18: Lagre langsiktige servicelagsnøkler (annet enn offentlige nøkler) på en HSM-server som er bosatt i infrastrukturutstyret.
• TM-19: Etabler en sikkerhetsforening med utprøvde og sikre kryptografiske algoritmer mellom de kommuniserende enhetene for å gi gjensidig autentisering, integritet og konfidensialitet.
• TM-20: Bruk kommunikasjonsprotokoller som inkluderer funksjonalitet for å avdekke om hele eller deler av en melding er en uautorisert gjentakelse av en tidligere melding.
• TM-21: Bruk positiv/ hvitelistet inndatavalidering for å beskytte mot skripting på tvers av nettsteder og kommandoinjeksjon.

7.3.17 Databeskyttelse

Sikkerhetstiltak som gjelder beskyttelse av konfidensielle data på forskjellige nivåer i en organisasjon og styring av tilgang til data:

• TM-22: Beskytt data under lagring (både i flyktig og ikke-flyktig minne), under overføring og i bruk.
• TM-23: Kategoriser data relatert til OT-systemet basert på risikoanalyse, vurder kritikalitet og definer nødvendige sikkerhetstiltak som vil sikre et riktig sikkerhetsnivå.
• TM-24: Gi bare tilgang med minst mulig privilegier til tredjeparter med need-to-know-prinsipper i mente, og dokumenter denne tilgangen.
• TM-25: For data med høy konfidensialitet, iverksett kryptering og nøkkelhåndtering slik at informasjonen bare kan leses av autoriserte brukere og bruke løsninger for forebygging av tap av data.
• TM-26: Anonymisere og sikre eventuelle direkte eller indirekte personopplysninger behandlet i bedriften, f.eks. gjennom rollebasert tilgangskontroll og kryptering, etter å ha vurdert alle relevante juridiske krav. 

7.3.18 Programvare-/fastvareoppdateringer

Sikkerhetstiltak angående verifisering, testing og utførelse av programvareoppdateringer:

• TM-27: Verifiser endepunkts programvare/ fastvare -autentisitet og integritet og sikre tett kontroll over oppdateringen.
• TM-28: Kontroller kilden til oppdateringen og utfør prosedyrer for automatisk oppdatering bare hvis de er basert på risikoanalysen.
• TM-29: Utfør distribusjon av programvareoppdatering for IoT-enhetene bare etter å ha bevist at det ikke eksisterer noen negative konsekvenser og test programvareoppdateringer i et testmiljø før de implementeres i produksjon.
• TM-30: Tillat tredjeparter å utføre programvareoppdateringer bare hvis de garanterer og er i stand til å bevise at oppdateringen er testet og ikke vil føre til uheldige konsekvenser på enheten eller hvis de aksepterer ansvar for oppdateringen i henhold til en gjeldende avtale.
• TM-31: For kontrollsystemer som ikke kan oppdateres, bruk kompenserende tiltak.

7.3.19 Tilgangskontroll

Sikkerhetstiltak angående kontroll av fjerntilgang, autentisering, privilegier, kontoer og fysisk tilgang:

• TM-32: Segreger fjerntilgang, dvs. definer et sett med regler for kontroll av fjernkommunikasjonen.
• TM-33: Sikre minimum autentiseringsnivå for IoT-enhetene og -systemene, og sørg for at autorisasjon bare gir tilgang til et bestemt segment av systemet.
• TM-34: Iverksette/ bruk multifaktor-autentiseringsevne i IoT-løsningene.
• TM-35: Endre standardpassord og brukernavn under idriftsettelse eller ved første bruk. Bruk sterke passord og krev innstilling av et nytt passord etter en definert periode.
• TM-36: Bruk minsteprivilegiet prinsippet og sørg for at roller i et miljø med flere brukere blir adskilt og godkjent av en riktig person.
• TM-37: Lag individuelle kontoer for hver bruker når det er mulig.
• TM-38: Iverksett/ bruk en konto-utlåsings funksjonalitet i IoT-enheter.
• TM-39: Ved omfattende og diversifiserte nettverk med et stort antall enheter, bruk en PAM-løsning (Privilege Access Management).
• TM-40: Innen tilgangskontroll, vurder aspekter ved fysisk tilgang til bygninger, områder, rom og skap.

7.3.20 Nettverk, protokoller og kryptering

Sikkerhetstiltak kan bidra til å sikre kommunikasjonssikkerhet gjennom riktig implementering, kryptering og nettverkssegmentering av protokoller:

• TM-41: Sikre kommunikasjonskanaler relatert til IoT-løsninger og krypter kommunikasjon av viktige data der det er teknisk mulig.
• TM-42: Segmenter industrianleggsnettverk basert på en forhåndsdefinert reguleringsmodell som inkluderer etablering av demilitariserte soner (DMZ) og kontroll av trafikk mellom soner, f.eks. i henhold til Purdue modellen.
• TM-43: Følg mikrosegmenteringsmetoden, dvs. bygg små øyer med komponenter i et enkelt nettverk som kun kommuniserer med hverandre og styr nettverkstrafikken mellom segmentene.
• TM-44: Isoler sikkerhetsnett fra forretnings- og kontrollnett hvis mulig.
• TM-45: For IoT-løsninger, implementer utestede protokoller med kjente sikkerhetsfunksjoner, basert på standarder og tekniske anbefalinger. Velg løsninger som bruker protokoller som er bevist som sikre eller takler historiske sikkerhetsproblemer (f.eks. TLS 1.3) og unngå de med kjente sårbarheter (f.eks. Telnet, SNMP v1 eller v2).
• TM-46: Sikre sikkerhetsfunksjoner og interoperabilitet mellom protokoller når du implementerer forskjellige protokoller for forskjellige enheter i samme system.
• TM-47: Begrens antallet protokoller som er iverksatt i et gitt miljø, og deaktiver standardnettverkstjenester som er ubrukte.
• TM-48: Sikre et sikkert miljø for nøkkelutveksling og nøkkelhåndtering, unngå å dele kryptografiske nøkler på flere enheter.
• TM-49: Sørg for riktig og effektiv bruk av kryptografi for å beskytte konfidensialitet, autentisitet og/ eller integritet til data og informasjon (inkludert kontrollmeldinger), under transport og under lagring. Sørg for riktig valg av standard, sterke krypteringsalgoritmer og sterke nøkler, og deaktiver usikre protokoller. Kontroller implementeringens robusthet.

7.3.21 Overvåking og revisjon

Sikkerhetstiltak som gjelder nettverkstrafikk og overvåking av tilgjengelighet, samling av logger og gjennomgang:

• TM-50: Iverksette en passiv overvåkningsløsning i IT- og OT-miljøene for å lage en industriell nettverkstrafikklinje og overvåk avvik og overholdelse av normal aktivitet.
• TM-51: Samle sikkerhetslogger og analyser dem i sanntid ved hjelp av dedikerte verktøy, f.eks. SIEM-klasseløsninger, for eksempel i et Security Operation Center (SOC).
• TM-52: Utfør periodiske gjennomganger av nettverkslogger, tilgangskontrollrettigheter og asset- konfigurasjoner.
• TM-53: Overvåk tilgjengeligheten av IoT-enhetene i sanntid, der det er teknisk mulig.

7.3.22 Konfigurasjonsstyring

Sikkerhetstiltak angående sikkerhetskonfigurasjon, styring av endringer i konfigurasjon, utprøving av enheter og verifisering av sikkerhetskopier:

• TM-54: Etabler grunnleggende sikkerhetskonfigurasjoner skreddersydd til forskjellige typer eiendeler.
• TM-55: Iverksett en mekanisme og støtteverktøy som muliggjør konfigurasjonsstyring.
• TM-56: Iverksett og dokumenter endringer i konfigurasjonen i henhold til en endringshåndterings-politikk utviklet av organisasjonen basert på risikoanalyse.
• TM-57: Utvikle en dedikert prosedyre for konsekvensanalyse og utfør den før implementering av endring i systemet.
• TM-58: Utprøve IoT-løsninger og inkludere dette i endringshåndteringspolitikken.
• TM-59: Lag og bruk en omfattende sikkerhetskopieringsplan, inkludert bestemmelser for periodisk testing, skreddersydd til forskjellige typer eiendeler.

Integrering av IT og OT-cybersikkerhet krever å forstå forskjellene mellom dem, og mellom deres tilnærminger til systembeskyttelse. IT og OT cybersikkerhet, -forskrifter og -standarder må både utvikles hver for seg og sammen for å være effektive. De kan ikke lenger ha et snevert fokus.

7.4.1 Konvergensen mellom informasjonsteknologi (IT) og driftsteknologi (OT)

Tidligere var det et sterkt skille mellom IT og OT. Informasjonsteknologi omfatter datamaskiner og kommunikasjons-systemer, som er vanlige i alle bransjer. Videre er programvareapplikasjoner menneskesentriske og risikoen er ofte lav. Sanntidsadferden er vanligvis begrenset av menneskelige interaksjonstider, for eksempel hvor lenge noen vil vente på at informasjonen skal vises. OT er derimot en kombinasjon av maskinvare (opprinnelig) og programvare (nylig) som samler inn informasjon og utløser endringer i den fysiske verdenen gjennom overvåknings- og kontrollsystemer. Styring av fysiske systemer, i motsetning til IT-systemer er avhengig av type operasjon, automatisert og krever mindre brukerinteraksjon. I OT kan sanntidsadferd være essensielt for hvor riktig operasjonen er, noe som kan påvirke typen sikkerhetstiltak som er implementert.

Konvergensen av IT og OT innebærer en kompleks sammenslåing av deres viktigste systemegenskaper. Selv om mange industrisystemer kombinerer IT og OT ved å styre enheter ved hjelp av programvare, er disse systemene vanligvis isolert på OT-siden. Å bringe disse systemene sammen forandrer implementeringen av cybersikkerhet så vel i IT som i OT. For eksempel kan det å bevare integriteten til informasjonen som er lagret i skyen, påvirke OT-systemets pålitelighet, og dermed påvirke sikkerheten. Hvis styringsinformasjonen som er lagret i et IT-system blir endret uten autorisasjon på grunn av feil sikkerhetsimplementeringer, kan OT-systemet som er avhengig av disse dataene mislykkes.

Konvergens av IT og OT frembringer også ulike pådrivere og holdninger. IT-spesialister vurderer ikke sikkerheten i sine design, mens sikkerhet er obligatorisk i OT. Når kvalitetskravene til systemet er oppfylt, fokuserer IT-leverandørene som regel på kostnadsreduksjon, og dermed har de kanskje ikke nok ressurser til å forbedre systemets sikkerhetskvalitet. Det å sikre sentrale systemegenskaper er prioritert på forskjellige måter i IT og OT verdenene, og dette må forenes.

Denne konvergensen krever at de forskjellige funksjonene som utføres i IoT-systemet alltid blir ivaretatt sammen. Det er av den grunnen at IoT-referansearkitekturen [IIC-IIRA2016] fusjonerte IT- og OT-funksjoner til et sett av felles domener:

• kontroll
• drift
• informasjon
• applikasjon
• virksomhet

7.4.2 Cybersikkerhetsutvikling innen IT og OT

Cybersikkerhet har stort sett vært IT-sentrisk, og risiko styres ved at endepunktene er tilstrekkelig sikret og kommunikasjonen mellom maskiner er beskyttet. IT innebærer ofte en klient-servermodell, der klienter og servere kjører flere prosesser, og kommuniserer ved hjelp av kjente protokoller som IP (Internet Protocol), TCP (Transmission Control Protocol) eller HTTP (Hypertext Transfer Protocol). På grunn av denne ensartetheten er sikkerhetstiltak og -overvåking basert på en rekke kjente angrep og angrepsmodeller.

Evalueringen av risiko i IT-systemer er basert på sannsynligheten for et vellykket angrep og skadene som dette angrepet ville forårsake. Dessverre innebærer vurderingen av skadene vanligvis bare penger eller omdømme, ikke andre utfall, som fysiske sikkerhetstrusler. OT-cybersikkerhet overses fullstendig, fra forretningsavgjørelser til implementering. Angrep som er vanlige i OT, for eksempel fysiske angrep, er ikke en del av eksisterende retningslinjer.

I disse tider legger forbrukerne til nye enheter som lyspærer eller TV-apparater IT-nettverk, ved å bruke protokoller fra industrisystemer som har blitt tilpasset til å kontrollere hvitevarer. Disse IoT-systemene fokuserer på brukervennlighet snarere enn sikkerhet, så selv om teknologidriverne er de samme som for IoT, er forretningsdriverne og de viktigste systemkravene forskjellige. OT-systemer har i mellomtiden lagt til flere IT-komponenter, spesielt enheter som kjører enhetsstyringsprogramvare. Selv styresystemer som ikke er koblet til et nettverk er utsatt for IT-angrep, som for eksempel programvarevirus fra flyttbare medier.

7.4.3 Myndighetskrav og standarder innen IT og OT

Med tanke på risikoen er det ikke overraskende at myndigheter har innført omfattende forskrifter. Regulerings- og overholdelsesregler krever kontroll av tilgang til finansielle systemer, beskyttelse av kredittkortinformasjon, opprettholdelse av personvernforventninger og beskyttelse av kritisk infrastruktur. Avgjørelser om implementering og drift av et IoT-system må redegjøre for disse pålagte retningslinjene, inklusivt strenge sikkerhetskrav.

Mange IoT-systemer er underlagt eksterne forskrifter som må overholdes. Et bredere syn på regelverk vil være nødvendig. OT-arbeidere vil være nødt til å ivareta både cybersikkerhet og sikkerheten til komplekse nettverkssystemer. IT-arbeidere må ivareta sikkerhetsforskrifter, samt vurdere hvordan IoT-systemer forholder seg til cybersikkerhetsforskrifter. I begge tilfeller blir personvernforskrifter stadig viktigere, ettersom IT og OT data blir samlet inn og delt for lagring og analyse.

Ny lovgivning vil sannsynligvis pålegge både OT og IT flere typer revisjon, forsikring og krav, knyttet til IoT. For eksempel fokuserer HIPAA (Health Insurance Portability and Accountability Act) i helsevesenet på å beskytte IT-siden, for eksempel konfidensiell informasjon om pasienter, men unnlater å dekke endepunktbeskyttelse, inklusivt røntgenmaskiner og insulinpumper, som nå er koblet til nettverket og kan være mål for angrep, eller til og med brukt til å trenge seg inn i lukkede nettverk.

7.4.4 Brownfield-utviklinger innen OT

Begrepet Brownfield beskriver et miljø der nye løsninger og komponenter må være samlokalisert og må samvirke med eksisterende eldre løsninger. Begrepet brukes i motsetning til greenfield, der det ikke fins noen eldre systemer.

OT-systemer blir ofte implementert i Brownfield-miljøer. OT-ressurser har ofte veldig lang levetid, og de krever massive investeringer i drifts-, pålitelighets- og sikkerhetstesting. Derfor er det verken økonomisk eller teknisk mulig å erstatte eksisterende utstyr og applikasjoner med nyere alternativer på kort eller mellomlang sikt.

De fleste industrielle installasjoner inneholder utstyr som, ifølge IT og sikkerhetsstandarder, er "gamle" eller "utdaterte." Slikt utstyr har større risiko for angrep enn utstyr med de nyeste sikkerhetsfunksjonene og de siste sikkerhetsoppdateringene.

I dag er fortsatt mange systemer avhengige av fysisk sikkerhet (låste dører og vakter), isolering av OT-nettverk og uklarhet i industrielle protokoller for å kompensere for mangel på cybersikkerhet. Men det fungerer ikke. For eksempel omgir kablet og trådløst nettverk tradisjonelle fysiske barrierer som dører og vegger, fordi nettverket strekker seg forbi fysiske barrierer.

Gamle OT-systemer utgjør et attraktivt mål for angripere. Mange industrisystemer brytes ofte [SANS-SSCS] på grunn av utdatert cybersikkerhetsbeskyttelse. Til slutt vil angripere utforme spesifikasjoner for å tjene penger på OT-brudd, og dermed vil antallet angrep øke dramatisk. Angrepets nyttelast for komplekse OT-endepunkter (for eksempel kjernefysiske sentrifuger) har bare vært tilgjengelig for statlige aktører, men dette kan også endre seg.

Tradisjonelle OT-systemer ble designet for å betjene industrielle prosesser trygt og pålitelig, uten kobling til noe eksternt nettverk. Siden IoT-systemer inneholder OT-komponenter og delsystemer som er produsert uten sikkerhet som prioritering, kan de ha en uforutsigbar oppførsel på grunn av gjenbruk eller omforming av komponentene. Derfor må IoT-arbeidere risikovurdere enhetenes funksjoner og interaksjoner nøye. Implementering av cybersikkerhet i Brownfield-OT-miljøer bør være så skånsom som mulig. Nettverksskallsikring som brannmurer, datadioder og rutere, og passiv deteksjonsteknologi mot nettverksinntrenging må iverksettes forsiktig, for å sikre en barriere mellom OT-styringsmiljøet og nettverk utenfor styringssystemene.

7.4.5 Skytjenestesystemer innen IoT

En av fordelene med IoT er muligheten for analyse og kontroll av OT-infrastrukturen ved hjelp av ekstern nettverksdatakraft. Denne praksisen med å bruke eksterne servere til å lagre, håndtere og behandle data, i stedet for en lokal server eller datamaskin, kalles skytjeneste. Organisasjoner som Cloud Standards Council og Cloud Security Alliance tilbyr omfattende veiledning om skytjenestearkitektur og -cybersikkerhet. Her fokuserer vi på særegenhetene som skytjenester må redegjøre for i IoT-systemer.

I et typisk IoT-system kommuniserer tusenvis av enheter med et skytjenestesystem, hvor data lagres. Å dele tredjeparts tjenesteleverandører med eksterne aktører skaper en rekke tillitsgrenser som kan påvirke både cybersikkerhet og personvern. Informasjon må beskyttes både med tanke på cybersikkerhet og personvern. Informasjon som overføres til kontrollsystemer, må være tilstrekkelig sikret for å ivareta sikkerheten til fysiske prosesser. For eksempel ved hjelp av frastjålet legitimasjon kan angripere fjernstyre fysisk infrastruktur, og tilrettelegge for angrep på mange av leverandørens kunder samtidig. Dessuten kan angrep på andre skytjenestekunder eller på skytjenesteplattformen forplante seg til prosesseieren.

7.4.6 Implikasjoner for IoT-sikring

Det er behov for endringer innen både forretningsledelse og implementering når det gjelder cybersikkerhet. Både OT og IT-sikkerhets- og cybersikkerhetssystemer må tilfredsstille forskriftskrav, og det kreves investeringer for å sertifisere utstyr som påvirker person- eller miljøsikkerheten. Nye angrep og trusselmodeller må evalueres, og sikkerhetssystemene bør omfatte alle interessenter. Disse interessentene vil ha ulike roller når det gjelder sikring av IoT systemer, og det vil være ulike systemgrenser, forretningsmodeller og risikomodeller. Når systemene var styrt av bare en eier/ operatør, var sikkerhetsproblemer tydeligere og enklere å begrense. I IoT-systemer krever økt oppkobling flere grensesnitt, og dette innebærer risiko. 

De fleste OT-systemer er avhengige av infrastruktur med en levetid på flere tiår, mens IT-systemer ofte kan oppgraderes til lav eller ingen kostnad. I de kommende årene må disse systemene integreres i et dynamisk landskap med endepunkt, kommunikasjon, overvåking og styringssystemer som muliggjør den nødvendige sikkerheten. Sikkerhetskritiske systemer er nå koblet til skyen for styring og analyse av innsamlet data.

De fem karakteristikkene som har størst påvirkning på avgjørelser som gjøres for IoT-anvendelse er:

• sikkerhet
• trygghet
• pålitelighet
• robusthet
• fortrolighet

Dette refereres til som systemets nøkkelkarakteristikk. Andre egenskaper som skalerbarhet, anvendbarhet, vedlikeholdsevne, portabilitet eller hvor godt systemet kan settes sammen kan også være viktige, men sees ikke på som nøkkelegenskaper i forhold til troverdighet. Hver av de fem nøkkelkarakterstikkene må oppnås hver for seg, selv om enkelte teknikker kan være felles for dem.

7.5.1 Sikring av nøkkelkarakteristikk

Sikring krever innsamling og analyse av bevis som begrunner design, bruk og testing av systemet samt systemets funksjon under bruk. Bevisene må synliggjøre at man har brukt rett sammensetning av funksjoner kompensert med sikkerhetskontroll som minimerer risiko.

Sikring inkluderer også risikoanalyse for å indentifisere farer og forhindre uønskede hendelser og uhell. Risiko, eller påvirkningen av usikkerhet på målsetning, tar sannsynligheten og effekten til en mulig hendelse i betraktning. Strengt produkt- og systemdesign, inkludert designgranskning og -testing, tar sikte på å unngå feilaktig bruk og å forbedre systemets motstand mot potensielle hendelser identifisert i risikoanalysen.

Når en peker på hva som har blitt gjort for å takle et angrep eller en bestemt svakhet bør en så langt det er mulig bruke offentlig tilgjengelige kilder, slik at diskusjon kan baseres på felles terminologi og referansekilder.

Sikringscase kan brukes for å begrunne hvordan sikkerhetsfunksjonalitet (eller fravær av sårbarhet) fungerer. De vil utgjøre underlag som viser hvordan svakheter er fjernet gjennom beskyttelsesmekanismer og sikkerhetsfunksjoner, og argumentere for at nøkkelkarakteristikken er oppnådd. Slike caser kan også vise interessenter at forventningene deres for hver nøkkelkarakteristikk er tilstrekkelig.

En misbrukscase er en test med ukorrekt/ falsk input til systemet som tester hvordan systemet reagerer på et eventuelt misbruk. Misbrukscase likner på brukscase på den måten at de bruker eksplisitt inngripen i systemet som verktøy, men skiller seg fra hverandre ved om resultatet av denne inngripen er skadelig eller ikke (See [McDer1999]). Misbrukscase som feiler kan være gode argumenter for at systemet fungerer. Med passende misbrukstesting inkludert i en sikringscase kan det underbygge tillit for interessentene til at angriperes innflytelse har blitt begrenset. Casene kan brukes både til kravanalyse og testing.

En trusselmodell er en systematisk tilnærming til definisjonen av potensielt skadelige hendelser og ondsinnede angrep på systemet. Det starter med å indentifisere de viktigste måtene systemfunksjonalitet kan bli redusert på. Forskjellige typer brudd blir deretter spesifisert og inndelt i ulike konkrete trusler som kan valideres i en misbrukscase. Denne ovenfra-og-ned-tilnærmingen avdekker andre trusler, slik at sammensatte sikkerhetstiltak kan utvikles under systemdesign, implementering, konfigurering og vedlikehold.

7.5.2 Sikkerhet

Det følgende avsnittet handler om systemer som ivaretar sikkerhet. En svakhet med det norske språket gjør at vi møter på et problem når vi snakker om dette feltet, som man ikke ser på engelsk – nemlig det faktum at vi ikke skiller mellom engelske security og safety. Mens security (fra latin securus som betyr fri fra bekymring) handler om sikkerhet mot trusler og overlagte handlinger, så dreier safety (fra latin salusus som betyr noe sånt som uskadet) seg om sikkerhet mot farer og risiko som konsekvens av en mulighet for uforutsette hendelser. For å tydeliggjøre denne forskjellen videre i dette avsnittet har vi valgt å bruke begrepene sikkerhet mot trusler og sikkerhet mot uforutsette hendelser.

7.5.2.1 Sikkerhet mot trusler

Sikkerhet mot trusler er tilstanden til systemet som blir beskyttet mot utilsiktet eller uautorisert tilgang, endringer eller ødeleggelse.

Sikker operasjon av et system er et spekter, og ikke en svart/hvitt tilstand. Heller kan ingen IoT-systemer operere sikkert i enhver kontekst. Derfor må en gitt situasjon som blir definert som betydningsfull defineres eksplisitt sammen på linje med den sikre operasjonen som interessentene forventer.

Sikring av et system er ofte vurdert gjennom mål på risiko. En risikovurdering er typisk basert på en gitt systemkomponent (en eiendel med en gitt verdi), typen trusler (noe eller noen forsøker å gjøre skade), en potensiell sårbarhet eller svakhet hos komponenten som truslene vil utnytte, og eventuelle mottiltak som bidrar til å redusere sannsynligheten og skaden av slike hendelser.

Elementene som må ivaretas for å opprettholde sikkerhet av informasjon og systemkomponenter er konfidensialitet, integritet og tilgjengelighet, ofte referert til med forkortelsen CIA på engelsk (Confidentiality, Integrity and Availability).

Konfidensialitet er den egenskapen at informasjonen ikke blir gjort tilgjengelig for uautoriserte brukere, enheter eller prosesser. Brudd på konfidensialitet kan forekomme muntlig, ved utskrifter, kopi, over e-post eller gjennom svakheter i programvare som tillater angripere å lese eller filtrere ut data. Dataeksfiltraksjon er uautorisert henting eller ekstrahering av data fysisk eller over nettverk under kontroll av en angriper. Disse dataene kan i verste fall brukes til utpressing eller innebære tyveri av immaterielle rettigheter (IP). Konfidensialitetskontroll inkluderer tilgangskontroll og krypteringssystemer.

God integritet beskytter mot ødeleggelse, sletting eller uønsket modifikasjon av data. Integritet kan kontrolleres gjennom hashfunksjoner, sjekksum (checksum), antivirusfunksjonalitet, hvitelisting og kodesignering som forsikrer at det ikke har blitt gjort noen endringer i kode, systemkomponenter eller fysiske prosesser i systemet. Dataintegritet, mer spesifikt, forsikrer at uautoriserte parter ikke kan endre data eller ta kontroll over systemet uten at det blir oppdaget.

Tilgjengelighet er egenskapen som muliggjør rask og pålitelig systemtilgang av en autorisert bruker. For eksempel bør systemer som kontrollerer fysiske prosesser være kontinuerlig tilgjengelige og observerbare av menneskelige operatører. En person kan ha behov for å bryte seg inn i et angrepstilfelle, for eksempel for å skru av eller stoppe systemet. Tilgjengelighetskontroller inkluderer ofte sikkerhetsfunksjoner som detekterer og minimerer sårbarheter i programvare som kan forårsake upålitelig operasjon, visualisering eller ressursbruk som påvirker systemet negativt.

I tradisjonelle operasjonsteknologisystemer (OT-systemer) har tilgjengelighet blitt ansett som den aller viktigste egenskapen, etterfulgt av integritet og konfidensialitet. Denne oppfatningen henvises ofte til som sikkerhetstriaden eller med forkortelsen AIC.

7.5.2.2 Sikkerhet mot uforutsette hendelser

Sikkerhet mot uforutsette hendelser er tilstanden til et system som opererer uten uakseptabel risiko for direkte eller indirekte skader på personer eller materiell.

Slik sikring tar sikte på å eliminere både systematiske og tilfeldige feil. Tradisjonelle teknikker for sikkerhetsvurdering innen OT fokuserer på fysiske gjenstander og prosesser, og overfører empiribaserte sannsynligheter for komponentfeil til en total systemrisiko. Risikoanalyse blir deretter utført for å identifisere farer, for igjen å kunne unngå farlig bruk og forbedre systemets evne til å tåle uforutsette hendelser.

Når en analyserer programvare derimot, så kan en ikke lage statistikk for å karakterisere feil siden den alltid fungerer slik den er programmert. Hvis en programvare aldri har ført til feil under testing, så kan det simpelthen være fordi den ikke har blitt eksponert for input som ville ha ført til feil. Testomfang er derfor ikke direkte overførbart til feilrate.

Tilnærminger for å håndtere feil probabilistisk tar ikke hensyn til trusler, fordi angripere vil være i stand til å utnytte eventuelle feil relatert til sikring mot trusler så fort disse feilene har blitt oppdaget.

Tradisjonelt har det blitt fokusert på å forsikre funksjonell korrekthet, uten å ta høyde for at en angriper kan være involvert. I dagens IoT-systemer, kan derimot en angriper være i stand til å utnytte svakheter (For a public collection of weaknesses, see [CWE]). som kan drive systemet inn i en mer sårbar tilstand. Dette står i sterk kontrast med moderne IT-sikkerhet, hvor en analyse av en trussel og angriperens evner/ ferdigheter brukes for å bestemme hvor sannsynlig det er at svakheter kan utnyttes. Mange av de samme verktøyene og teknikkene som blir brukt til å utvikle sikkerhetskritisk programvare kan også identifisere og minimere potensielle svakheter. I dag vil mange sikkerhetsreguleringer og retningslinjer (For example, Positive Train Control (PTC), see [CFR-236]) kreve at programvare som blir brukt i sikkerhetskritiske systemer blir nøye validert for å avdekke problemer, samtidig som gode og detaljerte rutiner for programvareutvikling kan hjelpe utviklere med å eliminere noen av disse svakhetene og problemene fra starten av.

7.5.3 Pålitelighet

Pålitelighet er et systems eller en komponents evne til å utføre sin funksjon under bestemte forhold i en bestemt tidsperiode.

Pålitelighet er forholdet mellom faktisk tilgjengelighet og planlagt tilgjengelighet som følge av vedlikehold, oppdateringer, reparasjoner og back-up. Slike aktiviteter reduserer tilgjengeligheten, men de reduserer ikke påliteligheten hvis de er godt og hensiktsmessig planlagte. Pålitelighet sier noe om hvor mye et selskap kan stole på at et gitt system virker når det ikke er berørt av planlagt nedetid.

Å sørge for pålitelighet krever detaljert forståelse av miljøet som systemet opererer i, hvordan systemet er bygget opp og hvordan det ble designet for å unngå feil. Parametere, konfigurasjon av innstillinger og fysiske attributter til hver komponent spiller en rolle. Det kreves også tester som viser om planlagte verdier for disse ble implementert eller ikke. Krav til oppetid og gjennomsnittlig tid til feil inntreffer blir målt i en sikringscase. Videre vil bruk av systemet gjøre det mulig å sammenligne oppnådd og påstått pålitelighet.

Det å legge til en internettilkobling til et system kan naturligvis føre til at forutsetninger for sikkerhet blir ugyldige, sammenlignet med da systemet ble utformet. I tillegg vil det vanligvis øke antallet interaksjoner med andre systemer. Tilnærminger som fokuserer på rent sannsynlighetsbaserte feil, vil ikke være sikre fordi angripere vil være i stand til å utnytte systematiske feil dersom en slik sårbarhet blir oppdaget. Ved å vurdere hvilke pålitelighetsaspekter en angriper kan påvirke og designe systemet og dets sikkerhet for å adressere disse typer angrep, kan systemets pålitelighet forbedres.

7.5.4 Motstandsdyktighet

Motstandsdyktighet er egenskapen til et system som gjør det i stand til å unngå eller håndtere dynamiske angrepssituasjoner mens systemets oppgaver fortsatt blir utført, og som kan omdefinere operasjonelt omfang etter et mulig angrep.

Ofte blir motstandsdyktighet oppnådd ved å designe systemet slik at feil som oppstår blir mest mulig begrenset. Hvis en enkelt funksjon feiler bør ikke det forårsake at flere andre funksjoner feiler som en konsekvens, og det bør være implementert alternative funksjoner i systemet som aktiveres automatisk og pålitelig i tilfelle det skjer en feil.

Sikring av motstandsdyktighet medfører fysisk eller logisk redundans for komponenter eller sammenkoblinger mellom dem og gjør overføring til alternative komponenter når det er nødvendig. Testing av normale og anormale scenarioer bør utføres slik at en undersøker hvorvidt en angriper kan slå ut en kombinasjon av komponenter i systemet.

Programvare må også være i stand til å bytte over fra et oppsett til en alternativ funksjonalitet, implementering, konfigurasjon, lokasjon eller nettverkssegment som kan ha andre svakheter, slik at en gitt trussel eller fare er minst mulig forstyrrende i tilfelle et angrep (See [NIST-800-160]).

7.5.5 Personvern

Personvern er en enkeltpersons eller gruppers rett til å kontrollere eller påvirke hvilken informasjon relatert til dem som blir innsamlet, behandlet og lagret og av hvem, og til hvem denne informasjonen deles.

Sikring av personvern avhenger av om interessenter forventer eller er lovmessig forpliktet til å beskytte eller kontrollere informasjon fra bestemte brukere. Det er viktig å holde seg oppdatert med reguleringer og standarder, slik som det nye rammeverket for transatlantisk dataflyt kalt EUUS Privacy Shield og EUs General Data Protection Regulation (GDPR) (See [EU-GDPR]).

I USA er det forvaltningsorganet for forbrukervern og konkurranseregulering (Federal Trade Commission - FTC), som vedlikeholder retningslinjer som er gjeldende i kommersielle sammenhenger. Reglene gjelder firmaer innen helse, finans, utdanning, salg av biler, markedsføring, underholdning og forbrukerkreditt. I hvert enkelt av disse områdene må firmaer følge spesifikke retningslinjer. For eksempel må HIPAA-regler (See [HHS-HIPAA]) følges når pasientrelatert informasjon behandles innen helse.

Aktsomhet må utøves for å minimere bruken av identifiserbare data, og risikoen ved identifisering må vurderes når disse identitetene ikke skal offentliggjøres. Identitet kan avsløres gjennom analyse av metadata knyttet til en bruker eller gruppe, eller sammenligning av metadata fra kilder som ikke er identifiserbare hver for seg. Integrering av industrielle IoT-systemer kan føre til en økning av slik risiko. Sikkerhetssystemer kan selv øke risikoen for brudd på personvern ved at mengden tilgjengelige data som en bruker eller gruppe økes.

Personvernsrisiko kan øke når industrielle systemer blir sammenkoblet med andre systemer som inneholder sensitive data. For eksempel, hvis et kundeforholdssystem blir integrert med et produksjonssystem, kan informasjon om produserte enheter eller produkter kobles opp mot en individuell kunde ved et sikkerhetsbrudd i et av de to systemene. Det er generelt fare for ukorrekt deling av informasjon dersom data distribueres til tredjeparter.

For å forstå påvirkningen av lover og retningslinjer for personvern på forretningsmodeller er alle regulerende rammeverk interessante. Eksempler på rammeverk som kan studeres er GAPP fra AICPA, PPTF fra OECD, FIPPS fra FTC og ‘Regulation 2016/679’ fra EU.

7.5.6 Troverdige systemer

Et sentralt mål for et system er at det skal være troverdig i forhold til sin nøkkelkarakteristikk. Viktigheten av hver karakteristikk for et gitt formål er unik for alle systemer, og det å oppnå én av dem kan komme i konflikt med en annen. Vekselvirkninger mellom et systems karakteristikk må sees på som en effekt av drivere som overholdelse av regulativer, forretningsprosesser og industrinormer.

Troverdighet er graden av tillit man har til at systemet responderer som forventet mot miljømessige endringer, menneskelige feil, systemfeil og angrep, i forhold til systemets nøkkelkarakteristikker. Både IT og OT vil ha krav som må oppfylles.

Denne flyten av tillit gjennom den hierarkiske systemstrukturen fra den allmenne bruken til alle komponenter er det en kaller gjennomsyret tillit (permeation of trust).

Ethvert IoT system har unik tillits struktur. Hvert element har aktører (designere, utviklere, produsenter, operatører, osv) som utfører forskjellige roller i utvikling, integrering og benyttelse av maskinvare og programvare i et IoT-system. Disse rollene går på tvers av flere organisasjoner, hver med sine egne interesser.

Tillitsstrukturen går tvers gjennom hele systemets livssyklus, ikke bare i driften. Det er avhengig av integriteten og forvaringskjeden/sporingen til hvert element og dens data. Helt fra forsyningskjeden, igangkjøring, tilrettelegging, benyttelse og avvikling ved endt livsløp må være nøye fulgt opp for å opprettholde tilliten gjennom hele livsløpet.

7.6.1 Systemets livssyklus

Figur 3 viser hvordan tillit gjennomsyres fra en industriell operatør, som f.eks. et sykehus eller et kjernekraftverk, gjennom maskin- og programvare som systemet består av. Denne tillits-forventningen bør tydelig beskrives, verifiseres, kontrolleres og følges opp og ikke utelukkende baseres på leverandørens gode rykte, uten å validere at tilliten faktisk blir ivaretatt.

Tillitslivssyklus starter med en kravspesifikasjon som resulterer i en leveranse av egenskaper. Forsikringen om at disse egenskapene ivaretar kravspesifikasjonene blir tillitsfundamentet i systemet.

Systemeiere og operatører iverksetter denne tillitsbygging ved å spesifisere tillitsbaserte krav som en del av de operasjonelle system kravene. Disse kravene blir stilt videre til systemutviklere som en systemspesifikasjon. Systemutviklere bryter dette videre ned i spesifikke tillits krav til hver komponent i systemet. Komponentutviklere responderer ved å levere komponenter som møter spesifiserte krav.

Samsvar mellom den leverte komponentens egenskaper mot kravspesifikasjon er en del av leverandørens forsikring før levering, av systembygger ved mottak og antagelig (potensielt uavhengig) en tredjepart aktør.

Systemutvikler er ansvarlig for integrering av alle de kontrollerte komponentene og forsikre seg om at de helhetlig ivaretar spesifiserte krav til det integrerte systemet. Det leverte systemets kapabilitet er verifisert og forsikret i operasjonell kontekst av eier/operatør eller en tredjeparts aktør.  Når en har forsikret seg operasjonelt vil en ha tillit til systemet nedover fra eier/operatør og helt til komponentutvikler gjennom systemutviklernivået. 

Tillit flyter nedover fra eier/ operatør til alle deler av systemet, men må etableres nedenfra og opp.

Figur 4 viser også eksempel på at eier/operatør kan delegere det overordnede ansvaret for å håndtere systemet til en tredjeparts aktør. Men en vil uansett som eier/operatør være ansvarlig for å forsikre seg om at det leverte systemet fortsetter å tjene sitt forretningsmessige formål og møter de operasjonelle kravene, samt opprettholder de etablerte tillitsforholdene og troverdighet.

For å etablere slike tillitsbasert forhold så må mottaker overlevere kravene og da definerer forventet kapabilitet fra leddet nedenfor. Denne prosessen innehar flere utfordringer:

• Kravene kan være vanskelige å utforme og krevende å beskrive utfra noen eksepsjonelle situasjoner.
• Kravene kan endre seg underveis i design fasen eller i systemets livssyklus.
• Grunnleggende kompetanse og teknisk terminologi kan variere. I internasjonale samarbeid kan kommunikasjon og språk skape misforståelser og forvirring.
• Små feil i arbeidet med å definere kravene til delkomponenter kan eskalere gjennom tillitssystemet til store problem for hele IoT systemet.

Standarder fra organisasjoner som ISO, IEEE, UL, IEC og statlige organisasjoner forenkler noe av denne kommunikasjonen. Krav og kapabilitet er tydelig dokumentert, slik at en kan referere til en eller flere godt etablerte standarder når en definerer systemet. Over tid burde disse standardene kunne definere forventningene rundt en fornuftig implementering av tillit i systemene.

Det finnes eksplisitte og implisitte krav. De eksplisitte kravene definerer systemegenskaper som er nødvendige, som en vannpumpe som stopper ved oppnådd vanntrykk.

Implisitte systemegenskaper er karakteristikk av systemet, som kvalitet, sammenstilling, styring, sikkerhet og fleksibilitet.

Et eksempel på et eksplisitt krav er lav pris; et eksempel på et implisitt krav er høy grad av tillit til systemet. Et praktisk eksempel på et eksplisitt krav i et moderne air-condition-system er at temperaturen kan kontrolleres gjennom internett; et implisitt krav kan være at denne internettilgangen ikke kan misbrukes av hackere.

Den mottakende aktørens fokus på eksplisitte krav og tendensen til å overse de implisitte kravene kan lede til et brudd i tillit. De fleste standarder fokuserer på implisitte krav som er enda en grunn til å benytte standarder i å definere kravspesifikasjonen.

Hvis avsenderaktøren tilbyr kapabiliteten, vil tilliten til at kapabiliteten møter kravene baseres på en forsikring. Den mottakende aktøren bør forsikre seg om at systemets troverdighet er ivaretatt ved å nøye studere dokumentasjonen som beskriver kapabiliteten. Og validere den gjennom grundige praktiske tester i tilsvarende samme miljø som tiltenkt i faktisk operasjon. Denne prosessen kan delegeres til en tredjepartsaktør, som f.eks. et kvalifisert testlaboratorium som verifiserer designet av løsningen.

Dessverre blir slik systematiske kapabilitetsverifikasjoner ofte forsømt av mottakende aktør grunnet begrensinger i tid eller ressurser. Tilliten vil da utelukkende baseres på den eksisterende relasjonen til leverandøren eller historikk og leverandørens renomme.

Da påliteligheten til systemet avhenger direkte av implementeringen av tillitsmekanismene på hvert trinn i prosessen, er påliteligheten selve sammensetningen av de viktigste systemegenskapene som er implementert i hver komponent, og sikkerheten derav.

7.6.2 Roller i et gjennomsyret tillitssystem

Rollene i dette systemet kan struktureres med tanke på rollen en spesifikk aktør innehar, i en av de tre forskjellige nivåene i Figur 4:

• Komponentutvikler er maskinvareleverandører eller programvare- og tjenestetilbydere som tilbyr spesifikke kapabiliteter som et standardisert produkt eller tjeneste.
• Systemutvikler er systemintegratorer og løsningsleverandører som integrerer eller tilpasser komponentene i brukerspesifikke og individuelle løsninger eller tjeneste.
• Den operasjonelle brukeren er systemets eier/ operatør som benytter komponentene, løsningene eller tjeneste til det tiltenkte formål.

Som nevnt er hardware, programvare og tjeneste komponenter bygget på andre komponenter, så tilliten gjennomsyres fra grunnkomponenten videre opp til høyere komponentnivå. Systemutviklere er ansvarlige for å integrere komponenter fra flere kilder korrekt. Komponentene kan bli overlevert gjennom flere overleverings mekanismer: kundetilpasset, hyllevare integrasjon eller integrasjon av et annet system. Hver av disse tilnærmingene har sine respektive prosesser for å sikre at tilliten ivaretas. For noen utstyrstyper innen: medisinsk, luftfart og jernbane behandles velbegrunnede og forsvarlige forsikringer av forsikringssaker og støttende bevis.

Tillit i kundetilpasset utviklingsmiljø er avhengig av interne eller tredje parts utviklere for å bygge komponenter som samsvarer med spesifiserte krav. Hyllevare integrasjon krever verifikasjon av samsvar av eksisterende produkter med tillitskravene. Hvis hyllevare komponenter viser seg uegnet til å levere på disse kravene, må systemintegratorene kapsle inn eller isolere denne komponenten i miljø der de kan ivareta nødvendig grad av tillit. Integrering av andre system er avhengig av å definere klare grensesnittspesifikasjoner eller grensesnittstandarder og relaterte servicenivåavtaler (SLA Service Level agrements) som oppfyller de spesifiserte tillitskravene.

I disse tilnærmingene til systemoppbygging er systemutvikler ansvarlig for å integrere hardware, programvare og tjenestekomponenter. Komponentutvikler må bevise at deres respektive komponenter møter de spesifiserte tillitskravene. Når disse komponentene er en samling av andre komponenter så er utvikleren av hovedkomponenten ansvarlig for å sikre at alle underkomponenter og deres integrasjon møter de spesifiserte tillitskravene.

IoT system eier/operatør må kunne stole på at alle prosesstegene har blitt korrekt implementert for å støtte opp om tillitsforventingen i nivåene over.

Hvert nivå i tillitsmodellen er avhengig av nivået under: Hver aktør bygger et tillitsforhold til aktøren under, som vist i Figur 4. Tillit er oppnådd i det operasjonelle systemet når en har forsikret seg om at de operasjonelle kravene til systemet er ivaretatt. Denne tilliten blir gjennomsyret tilbake nedover gjennom alle nivå av aktører som skapte, integrerte eller leverte komponenter eller delsystemer til det operative systemet.

Troverdigheten til det operative systemet levert av produsenter og leverandører er overført til troverdigheten til kapabiliteten som systemutvikler leverer. Disse kapabilitetene er igjen basert på troverdigheten i de integrerte tekniske komponentene.

Det er tilfeller der grensene mellom roller er mindre tydelige. Innehaver av en rolle kan påta seg karakteristikker fra en tilstøtende rolle. Et konkret eksempel er når produsenter ønsker å opprettholde kontroll over og håndtere enheten de har produsert. Enhetshåndtering, sikkerhetsstyring og prediktivt vedlikehold er eksempler på tilfeller hvor en produsent ønsker å inneha rolle som systemutvikler, spesielt tredje parts operasjonsstyrings leverandør eller tjenestetilbydere, i tillegg til rollen som produsent/utvikler.

Et lignende tilfelle er når IoT system eier/operatører ønsker å handle direkte fra produsent og integrere utstyret direkte inn i deres miljø. I disse tilfeller betjener eier/operatør rollen som intern systemintegrator, potensielt utviklere av egne løsninger internt.

7.6.3 Tillit på komponentutvikler rollen

Produsenter og leverandører utvikler tekniske komponenter som selges som standardkomponenter. Disse kan så tilpasses til spesifikt bruk, og dette er ansvaret til systemutvikleren. Komponentutvikler er ansvarlig for å levere kapabiliteten som er forventet og de implisitte kravene i komponentens livssyklus. Mottaker av komponenten er ansvarlig for å forsikre troverdigheten på neste nivå i tillits hierarkiet.

Tillit må gjennomsyres gjennom alle komponenter og dere underkomponenter som vist i Figur 5. Komponentutviklere må påse at tillitskravene er ivaretatt på alle delkomponenter og deres integrasjon.

Utviklere av maskinvarekomponenter må stille tillitskravene og sikre at de overholdes ned gjennom kjeden gjennom nedbrytningen av alle underkomponenter. Den opprinnelige produsenten av en kontroller er for eksempel ansvarlig for å sikre troverdigheten til alle komponenter fra mikroprosessor, minne, periferiutstyr, strømtilførsel og innkapsling.

Noen av disse komponentene kan leveres som integrert maskin- og programvarekomponenter. For eksempel kan en enhet bli levert med et kretskort som integrerer applikasjonsprosessor, minne, grafikkprosessor og integrerer UEFI (unified extensible firmware interface). Her vil igjen komponentutvikler være ansvarlig for samsvar med tillitskravene for den sammensatte komponent.

Disse komponentene kan bli levert i form av integrert tjeneste og eksponerer både maskin- og programvarekomponenter. Tilliten i en tjenestekomponent er sikret gjennom ivaretatte krav i servicenivåavtalen (SLA) på disse komponentene og deres underkomponenter.

For infrastruktur som en tjeneste (IaaS, Infrastructure as a Service) vil underkomponenter være hardware og programvarekomponenter på lavt nivå som fastvare eller hypervisor.

Platform som en tjeneste (PaaS, Platform as a Service) inkluderer vanligvis underkomponentenes operativsystem, systemkomponenter som databaser og applikasjonsrammeverk.

Til slutt kan programvare som en tjeneste (SaaS, Software as a Service) kjøre på en tredjeparts plattform. I alle tre tjenestevariantene er det hovedkomponentbygger som er ansvarlig for at tillit er gjennomsyret gjennom alle underkomponentene til tjenesten.

Leverandører og produsenter søker å implementere inkrementelle verdiskapninger til produkter som allerede er på markedet, for å opprettholde avkastningen på investeringen på forskning og utvikling som kreves for å implementere nødvendig tillit. På den andre siden, hvis produsenter og leverandører ikke implementerer nødvendige tillitsmekanismer, er det vanskelig for systemutviklere og eier/ operatør å implementere disse mekanismene på senere tidspunkt. Tillit må bygges inn fra begynnelsen.

Troverdigheten til en teknisk komponent er ikke bare definert som summen av troverdighet av underkomponenter. Det er komponentutviklers ansvar å forsikre at underkomponenter fungerer korrekt sammen i henhold til spesifisert kapabilitet.

Svakhet i en enkel underkomponent kan lede til tap av tillit til hele systemet. En feilaktig valgt maskinvarekomponent med lavere temperaturområde en spesifisert for systemet, kan lede til fullstendig systemfeil når systemtemperaturen overstiger komponentens temperaturområde. En enkel programvarekomponent med begrenset sikkerhetsegenskaper kan svekke sikkerheten til andre programvarekomponentene og til slutt hele systemet.

Innen driftsteknologi (OT), er kravene til sikkerhetssertifikater av nasjonale og internasjonale standarder og nasjonal lov, som generelt krever omfattende tester, typisk verifisert av autoriserte uavhengige testlaboratorium.

Innen informasjonsteknologi (IT), er det mindre vanlig å implementere omfattende sikkerhetstester, men det har blitt vanligere for komponenter utviklet for forbrukermarkedet å bli benyttet til industrielle formål. Manglende robusthet kan bli en utfordring sett opp mot industrielle standarder. I tillegg er livsløpet til produkter for forbrukermarkedet vanligvis mye kortere enn kravene for et industrielt bruk. Mangler eller svakheter i IT-elementenes troverdighet vil få uakseptable negative effekter på OT-prosessen. Industrielt graderte produkter er tilgjengelige, men de må eksplisitt etterspørres.

Når programvaretilbydere inkluderer underkomponenter, risikerer man at oppdateringer ikke lenger vil være tilgjengelig om en leverandør av en underkomponent ikke lenger støtter komponenten. Selv om kildekoden er tilgjengelig kan den være vanskelig å forstå, og med manglende tilgang til de riktige elementene i kodeutviklingsmiljøet kan det forhindre feilretting. 

Mange programvareprodukter har programmeringsgrensesnitt (API) som andre programvareprodukter er avhengig av. Programvare- og tjenestetilbydere må holde disse grensesnittene konsistente, eller i det minste bakoverkompatible gjennom livsløpet til alle IoT-systemer som benytter dem.

Mange SaaS tjenester er IT-basert og rettet mot menneskelig interaksjon. Små og hyppige endringer i brukergrensesnitt er lett akseptert av de fleste brukere, men å gjøre slike endringer i programmeringsgrensesnittet (API) kan redusere tilliten til tjenesteleverandøren.

7.6.4 Tillit på systemutviklerrollen

En komponentutvikler kan spre kostnaden med utvikling og krevende tester av solgte komponenter over tid. En systemutvikler på den andre siden leverer et spesifikt operasjonssystem som må være kostnadseffektivt i første utforming. Som et resultat av dette er det vanlig for systembyggere å skape et rammeverk som tillater forskjellige tekniske komponenter integrert i en plattform som kan selges om igjen til flere eiere/ operatører.

Fordi utformingen fra systemutvikler er i større grad mer tilpasset enn en teknisk komponentutviklers, vil det være mulig å påpeke tillitsproblemer i spesifikke komponenter ved å benytte forebyggende kontroller. Dette eliminerer ikke risikoen for at denne svakheten ville blitt avdekket under operasjon, men det reduserer sannsynligheten. For eksempel, en programvare komponent som ikke lenger blir oppdatert av programvareleverandøren (og uten alternative leverandører) kan inneholde en velkjent svakhet mot et potensielt nettverksangrep. Denne komponenten kan kreve nettverksbaserte mottiltak som brannmurer, strenge tilgangskontroller, monitorering av nettverkinntrenging og unormale nettverksaktiviteter for å sikre at denne komponenten ikke blir kompromittert.

En teknisk komponentutvikler burde aldri overlevere et uprøvd produkt til en kunde og en systemutvikler burde gjennomføre eksterne tester og sertifiseringer for å kunne avdekke svakheter som kan utbedres ved designmodifikasjoner. Systemutvikleren er i en posisjon til å påpeke tillitssvakheter som er overlevert av teknisk komponentleverandører.

Systemutviklere har lignende utfordringer som komponentutviklere. De må også forsikre at systemet de har satt sammen oppfyller forventningene gjennom hele systemets livsløp. Innledningsvis blir de betalt for design, installasjon og et suksessfullt oppsett og noen ganger for å sikre driftskontinuiteten. En systembygger må kunne levere funksjonalitet gjennom det forventede livsløpet til systemet. Dette inkluderer ikke bare erstatning av defekte komponenter, men også oppbevare og vedlikeholde kunnskapen om systemet gjennom dets livsløp.

7.6.5 Tillit på den operasjonelle bruker rollen

Den operasjonelle brukeren er startpunktet for gjennomsyring av tillit. Eier/ operatør rollen av det operasjonelle systemet må på jevnlig basis forsikre seg om:

• At systemet møter interessentens behov.
• At alle trusler til det iverksatte systemet er vurdert.
• At risikoen relatert til det iverksatte systemet er kvantifisert og godkjent.
• At oppdateringer, mottiltak og skadebegrensende kontroller er implementert for å håndtere denne risikoen gjennom hele systemets livsløp.

Noen ganger tar systemets eier/ operatør sin rolle til et nivå som aldri var tiltenkt av systemutvikler, som for eksempel ved å demontere et system og bruke disse komponentene et annet sted. Eier/ operatør må alltid være bevisst at tilliten til system er begrenset til leverte kapabiliteter som avhenger av spesifiserte krav. Denne bevisstheten ville raskt ekskludere et slikt misbruk av systemet.

Alle kapabilitetene i IoT systemet blir til slutt levert til eier/ operatør og all tillit til systemet starter her. Systemets eier/ operatør bærer risikoen i den operasjonelle prosessen. Enhver feil i systemets troverdighet grunnet svakt sikkerhetsnivå, trygghet, robusthet eller personvern vil direkte påvirke eier/ operatørs virksomhet.

Ved å feile med disse forsikringene kan det true eksistensen til eier/ operatør. Historien viser at de fleste skader, tapt fortjeneste, søksmålskostnader og ansvar for seriøse skader eller dødsfall ble eier/ operatør ansvarliggjort fordi tilliten til leveransen var for høy og kravene var ikke godt nok spesifisert til å kunne holde leverandører ansvarlig.

7.7.1 Referansesystemarkitekturer

Det finnes ulike modeller som presenterer systemarkitekturer for bedrifter, men 1990-tallets PERA (Purdue Enterprice Reference Architechture) brukes gjerne for datamaskinstyrte produksjonsbedrifter (computer-integrated manufacturing). Denne lagdelte modellen passer fortsatt for den digitale industrien, til tross for betydelige fremskritt når det gjelder implementering av mellomlagene, og utviklingen av den såkalte edge (beskrevet under). Mens aktuatorer, sensorer og robotstøttede handlinger er integrert med den fysiske prosessen, finnes alle de andre komponentene virtuelt i skyen. Avhengig av tidsbegrensninger og ventetidstoleranse, kan de virtuelle industrielle nettverkene enten være lokalt på fabrikkgulvet, lukket inn i anlegget eller globalisert på en eller annen måte gjennom industrielle edge- enheter.

Komponenter i et produksjonsanlegg kan være i bruk i flere tiår. Derfor er det behov for å tilrettelegge langsiktige cybersikkerhetsmekanismer som varer så lenge et system brukes, eller gi sikre oppdateringsmekanismer for å tilpasse systemets cybersikkerhet til dagens praksis.

Videre må alle områdene i en digital forsyningskjede utstyres med ende-til-ende cybersikkerhets-løsninger. I følge PwC består den digitale forsyningskjeden av åtte viktige elementer:

• Integrert planlegging og utførelse
• Logistikksynlighet
• Anskaffelse 4.0 (Procurement 4.0)
• Smart lager
• Effektiv reservedelsstyring
• Autonom og B2C logistikk
• Preskriptiv forsyningskjedeanalyse
• Muliggjørere digital forsyningskjede

7.7.2 Overordnet referansemodell

Industri 4.0-miljøer, som består av et stort antall elementer, kan virke utilbørlig kompliserte. En overordnet referansemodell, basert på Purdue-modellen, er utviklet for å kartlegge konseptet på en bedre måte (Purdue Bedrifts referensearkitekturen [36] utviklet av Theodore J. Williams og medlemmer av Industry-Purdue University Consortium for Computer Integrated Manufacturing, ISA-9537 [37]).

Industri 4.0-miljøer kan deles i 6 lag. Produksjonsprosessene ligger på det laveste nivået (Nivå 0), etterfulgt av enheter, systemer og tjenester (Nivå 1-5). Nivå 1 og 2 representerer OT-lagene. IIoT-enhetene hører til Nivå 1 i denne modellen. Nivå 4 tilsvarer IT-laget i selskapene, mens Nivå 3 er et mellomlag med systemer, mellom IT og OT lagene. IoT-plattformen inngår i Nivå 3. Det øverste laget (som ikke er representert i Purdue-modellen) er spesifikt for smart produksjon hvor eksterne tjenester ofte brukes. 

De grå pilene symboliserer kommunikasjonsveiene mellom større grupper i modellen (dvs. gruppene til venstre på bildet). Ved å integrere IoT-enheter i nettverket, har industri 4.0 introdusert nye kommunikasjonsveier, f.eks. kommunikasjonen mellom IoT-enheter, og mellom IoT-enheter og IoT-plattformen. Disse er illustrert med gule piler for å understreke deres kritikalitet når det gjelder sikkerhet og personvern. De 6 nivåene i referansemodellen er kort beskrevet under.

Nivå 0: Produksjonsprosesser og utstyr (maskiner og roboter)

Dette er det laveste nivået i IoT-miljøet, hvor smarte maskiner og roboter utfører ulike produksjonsprosesser. Disse prosessene måles og styres av enheter og systemer på de høyere nivåene.

Nivå 1: IoT-enheter - sensorer og aktuatorer

Dette laget omfatter IoT-enheter som måler systemparametere (IoT-sensorer) og utfører spesifikke handlinger (IoT-aktuatorer). Data overføres mellom IoT-enheter og styringssystemer (Nivå 2) samt IoT-plattform (Nivå 3). Nivå 1 omfatter også sikkerhetsinstrumenterte systemer (SIS).

Nivå 2: Industrielle kontrollenheter og systemer

Disse er enheter og systemer som styrer de industrielle prosessene (Nivå 0) basert på informasjon fra IoT-enheter (Nivå 1). De inkluderer kontrollere (PLS, Remote Terminal Unit-RTU), distribuerte kontrollsystemer (DCS), operatørpaneler (HMI) og overvåknings- og kontrollsystemer (SCADA).

Nivå 3: Operasjonssystemer og IoT-plattform

Dette er et mellomlag mellom OT og IT-miljøene, og omfatter systemer som brukes til å styre produksjonsprosesser, f.eks. Manufacturing Execution Systems (MES), historiker (database med historisk data), lagerstyringssystem (Warehouse Management System – WMS) og sporingssystemer (Track & Trace). Disse systemene kommuniserer med både OT- og IT-miljøer. Nivå 3 gjør det mulig å styre kommunikasjonen mellom OT- og IT-lagene. Videre inkluderer dette nivået også en IoT-plattform som analyserer og håndterer produksjonsdata og styringsdata fra IoT-enhetene, som er tett knyttet til OT-miljøet og informerer systemene på Nivå 4.

Nivå 4: Driftssystemer

Disse IT-systemene støtter produksjonsstyring og -planlegging, og forsyningskjedestyring. I motsetning til Nivå 2-systemer, fungerer de ikke i sanntid. Dette lagget inkluderer følgende systemer (denne listen er ikke ment å være komplett): Enterprise Resource Planning (ERP), Supply Chain Management (SCM), Sales & Operations Planning (S&OP), Customer Relationship Management (CRM), Material Requirements Planning (MRP), Transaction Processing System (TPS) og Executive Support System (ESS).

Nivå 5: Tredjepartstjenester 

Dette laget inkluderer tredjeparts-tjenester, som f.eks. SaaS, PaaS og IaaS.

7.7.3 Arkitekturer og overordnet referansemodell

Ettersom IoT-løsninger fokuserer på spesifikke teknologier og applikasjoner mangler de standardisering, noe som resulterer i fragmenterte og heterogene arkitekturer. ENISA studerte og gjennomgikk flere eksisterende IoT-arkitekturer og la frem en arkitektur som omfatter sentrale elementer i disse arkitekturene. Denne arkitekturen fremmer en betydelig grad av interoperabilitet på tvers av forskjellige resurser, plattformmiljøer, etc., og har som mål et felles arkitektonisk grunnlag for IoT.

De viktigste IoT-arkitekturene som er studert er: 

• AIOTI funksjonsmodellen for overordnet arkitektur [62]
• FP7-ICT - IoT-A arkitektonisk referansemodell [63]
• NIST-Tingenes nettverk (NoT) [64]
• ITU-T IoT referansemodellen [39]
• ISO / IEC CD 30141- referansearkitekturen for Tingenes internett (IoT RA) [65]
• ISACA Konseptuell IoT-arkitektur [66]
• M2M arkitektur modellen [67]
• IEEE P2413 - Standard for arkitektonisk rammeverk [68]

Følgende diagram viser den overordnede referansemodellen, som er basert på ovennevnte arkitekturer og definerer resursene som er relevante for IoT cybersikkerhet.