Sikkerhet ved oppkopling av industrielle innvevde systemer til skyen

Fremveksten av Industry 4.0 har ført til at fabrikker er blitt langt mer automatisert, med fjernstyrte produksjons- og styringskonsepter.  Mens dette gir mange fordeler i form av forretningsmessig effektivitet, utsetter man samtidig meget verdifulle ressurser for risikoen ved uønsket tilgang. Og det er ikke bare den høye kapitalverdien av maskinene som settes i fare, men også selskapets inntekter fra varene som produseres i fabrikken i et gitt tidsrom kan på denne måten kompromitteres.

Sårbarhet
Hvis, som vanlig er, fabrikken koples til en offentlig eller privat sky, vil det i seg selv medføre sikkerhetsrisiki. Det vil skje så snart en smartfabrikk blir utsatt for et nettverk, som for eksempel et eksternt datasenter. Utfordringen ligger i å bevare de fleksible fordelene ved den smarte tilkoplede fabrikken, og å holde tritt med å skalere sikkerheten over de ulike nettverkene.

Bruk standarder
Et godt utgangspunkt er å bestemme hvorvidt løsningen vil anvende en ledningsbasert, trådløs- eller en kombinasjonsløsning.  Derifra anbefales det å benytte kommunikasjonsteknologi med standard protokoller, som Wi-Fi, Bluetooth eller Ethernet, for å nevne de mest kjente innen industrisegmentet. Utnyttelse av standard praksis for sikkerhet senker risikoen for at forbindelser kompromitteres.  Dette går noen ganger på tvers av den historiske praksisen innen industrisegmentet, der man gjerne liker å bruke proprietære løsninger. Infrastrukturen må bygges for å kunne vare i mange år. Selv om mange nettverk har noen proprietære protokoller, bør disse begrenses til utelukkende innomhus bruk, og ikke for eksterne forbindelser.

Kunnskapshull
Ett av problemene er imidlertid at selv de mest kvalifiserte ingeniørene har begrenset kunnskap når det kommer til sikkerhetskonsepter innen IT. De er ikke eksperter på IT-sikkerhet, og dette kunnskapshullet hindrer dem i å kunne skape en robust og sikker infrastruktur for IoT. Så snart en forbindelse er gjort fra fabrikken til skyen, blir ingeniørene plutselig kastet ut i en verden av Amazon Web Services (AWS), Google, Microsoft Azure osv. og vil raskt finne ut at de trenger hjelp fra IT-eksperter for å håndtere det store spekteret av sikkerhetstrusler som de nå står overfor. 

Hacker-mål
For hackere er ett av hovedmålene å utnytte et enkelt tilgangspunkt for å kunne oppnå fjerntilgang til et stort antall systemer. Eksterne angrep kan gjøre skade i stor skala, som vi har sett av nylige massive angrep, slik som det såkalte Distributed Denial of Service (DDoS) har vist. For et IoT-nettverk er det svakeste punkt som regel maskinvaren og dens bruker ved sluttnoden, ettersom ingeniørene som styrer med dette vanligvis mangler IT-kunnskapen som kreves for å kunne håndtere problemet. 

Opplæring viktig
Dette er i endring. Selskaper som Microchip Technology ser det som en del av sin oppgave å fylle dette kunnskapshullet, ved å utdanne ingeniørene på hvordan en ende-til-ende infrastruktur for sikkerhet bør se ut.  I tillegg er store skyselskaper som AWS, Google og Microsoft viktige kilder til ekspertise. Den viktigste lærdommen er å ikke overse sikkerheten eller å unngå å ta vurdere den som en tilleggsfunksjon etter at et IoT-nettverk er blitt designet. På det tidspunktet er det nemlig for sent. Sikkerhet er noe som må implementeres strategisk fra starten av ethvert IoT design. Sikkerhet starter i maskinvare og er ikke noe som simpelthen kan legges på i form av etterarbeid eller som et tillegg i programvare.

Autentisering
Den viktigste delen av sikkerhets-puslespillet er autentisering. En systemdesigner må starte med idéen om at hver eneste node som er koplet til et nettverk må en unik, beskyttet og sikkerhetsklarert identitet. Å vite hvorvidt noen i nettverket er hvem de sier de er, og om de er til å stole på er essensielt. For å kunne gjøre dette, må tradisjonell bruk av TLS 1.2 og gjensidig autentisering gjøres mellom en server og en IoT sluttnode. Dette gjøres ved å anvende informasjon som begge parter stoler på – en sertifikatmyndighet. 

Beskytte klarering
Dette fungerer imidlertid bare dersom klareringen utstedt fra sertifiseringsmyndigheten er beskyttet hele veien fra starten av prosjektet, via produksjon og til systemet er implementert i den smarte fabrikken. Den private nøkkelen, som brukes til å godkjenne autentiteten til IoT sluttnoden, må være sikker og beskyttet. En svak, men fortsatt vanlig måte å implementere dette på, er å lagre den private nøkkelen i en mikrokontroller, i et åpent flashminne der den kan være tilgjengelig for programvaremanipuleringer. Imidlertid kan hvem som helst få tilgang til og se på denne minnesonen, styre den og hente ut den private nøkkelen. Dette er en dårlig implementering, og gir designere en falsk følelse av sikkerhet. Det er her skadene og de store problemene oppstår.

Sikkert element
I en sikker løsning må nøkkelen  og andre kritiske verdier ikke bare fjernes fra mikrokontrolleren, men også isoleres fra mikrokontrolleren og fra enhver eksponering for programvare. Her er det konseptet med et ”sikkert element” kommer inn i bildet. Idéen bak sikre elementer er i prinsippet å ivareta en trygg havn der nøkkelen kan lagres og beskyttes, og hvor ingen kan få tilgang til den.  Kommandoer fra CryptoAuthLib biblioteket tillater å sende de passende utfordringene/responsene fra mikrokontrolleren til det sikre elementet for å kunne validere autentiseringen. Under produktutviklingsprosessen og hele livssyklusen er den private nøkkelen på intet tidspunkt eksponert, ei heller forlater den noensinne det sikre elementet. Dermed er det mulig å etablere en ende-til-ende kjede av tillit og klarering.

De sikre elementene er frittstående CryptoAuthentication integrerte kretser (ICer) som en kan tenke på som ”safene” der selskapene kan plassere sine hemmeligheter. I dette tilfellet, inneholder de private nøkler som trengs for IoT autentisering.

Utstedelse av nøkler
Et annet og viktig konsept er hvordan de private nøklene og andre identitetsverdier leveres fra kunden til CryptoAuthentication enheten. For dette formålet tilbyr Microchip en plattform hvorfra kunden kan skape og arrangere (på en sikker måte) programmering av sine hemmeligheter under produksjon av ICer, uten å eksponere den overfor noen, inkludert Microchips eget personell. Microchip produserer deretter det sikre elementet i sine fabrikklokaler, og bare rett før det forlater disse fasilitetene som er sertifisert gjennom fellesøklene levert og sendt til sluttbrukeren.

Sertifikater
Når kunder åpner AWS IoT kontoer, tar de med seg kundesertifikatene som Microchip på sin side skapte med bruk av funksjonen Use Your Own Certificate fra AWS. Deretter bruker de en AWS IoT funkjson kalt just-in-time registration (JITR) for å gjøre en bulkopplasting av sertifikatene på enhets nivå, som er lagret og tilgjengelig i de sikre elementen i AWS IoT brukerkonto. Dette sertifikatet på kundenivå kan nå verifisere sertifikatet på enhetsnivå og sikkerhetskjeden er komplett. Denne funksjonen muliggjør ekte, profesjonell IoT-skalerbarhet  med hensyn til sikkerhet. Flere tusen sertifikater kan håndteres ved bruk av JITR-prosessen. De kan håndteres i bulk, i stedet for ett om gangen, uten innblanding fra brukeren. I stedet for å måtte laste sertifikater manuelt fra de assosierte enhetene til en skykonto og eksponere dem for tredjeparter, kan brukerne å arrangere registrering av nye enhetssertifikater automatisk, som del av den initielle kommunikasjonen mellom enheten og AWS IoT, alt uten å kompromittere sikkerheten.

Kom i gang
Om bord i evalueringssettet Zero Touch, som vist under, er kryptoautentiseringsenheten ATECC508AMAHAW, som kommer forhåndskonfigurert for å kunne kjøre autentiseringsprosessen overfor brukerens AWS IoT konto. Det første steget er å lære hva en sikkerhetskjede er, ved å bruke de nye Python-skriptene, så vel som å lære om provisjoneringsprosessen som pågår gjennom Microchips fabrikker under provisjoneringsfasen. Settet viser til en viss grad hvordan prosessene som er integrert i produksjonen fungerer.  I tillegg har enheten god motstandsdyktighet mot fysisk tukling, inkludert mottiltak mot sideangrep. Det har også en høykvalitets Federal Information Processing Standard (FIPS) kompatibel tilfeldig-nummergenerator, laveffekt – kryptografisk akselerator for kompatibilitet med det største utvalget av ressursbegrensede IoT-enheter og evnen til å ømløst dra nytte av ulike produksjonsflyt på en kosteffektiv måte.

Lukke gapet
For å bidra til å lukke gapet mellom innvevd-ingeniører og IT-ingeniører, i tillegg til on-boarding erfaring med Python-skript, kommer settet med CloudFormation skript for å akselerere AWS kontooppsett og gjøre skyen mer pedagogisk. Ved å anvende et CloudFormation skript, kan brukeren definere et brukergrensesnitt (UI) i AWS-miljøet på kun minutter.

Konklusjon
Kombinasjonen av Just in Time Registration (JITR) fra AWS IoT,  kombinert med ATECC508MAHAW kryptoautentiseringsenhet og sikkerhetsprovisjoneringsprosessen integrert i produksjonen som Microchip tilbyr, gir klassens beste IoT-sikkerhet. Dette er en sann ende-til-ende IoT sikkerhetsløsning som muliggjør vellykket sikkerhet for Industry 4.0, for trygg og effektiv vekst.

Artikkelen kan også lastes ned som PDF her