De som ikke lærer historien er dømt til å gjenta den.
Vi har hørt det ordtaket utallige ganger, men det har økt betydning når det kommer til operativ teknologi (OT) cybersikkerhet.
Historien gjentar seg gang på gang ettersom enheter – fra produsenter til tredjeparter til sluttbrukere – følger de samme gamle prosessene og utfører de samme strategiene.
De siste tre årene har Forescout forsket på OT-enhetssikkerhetsproblemer og ledet den største sikkerhetsevalueringen av TCP/IP stabler — kommunikasjonsprotokoller OT-enheter er avhengige av for å fungere — avdekker 95 pluss nye sårbarheter. Dette fortsatte med evaluering av OT-utstyr og protokoller tidligere i sommer i vår OT: Isfall forskning, som fører til oppdagelsen av 56 ekstra sårbarheter.
Lignende konklusjoner kan trekkes fra all forskning: Eldre prosesser, usikker-by-design-praksis og avhengighet av tidligere sertifiseringer er primære skyldige og må tas tak i. En måte å gjøre dette på er å bruke sikkerhetssertifiseringer.
Problemer med å følge de samme prosessene og sertifiseringene
Vi lever i en tilkoblet verden som er i konstant endring. Bransjer som driver handel, støtter helsen vår og skaper nye innovasjoner, leverer sitt verditilbud i et raskere tempo, takket være OT-enheter.
Denne hastigheten og konstante endringen er nettopp grunnen til at det ikke lenger er tilstrekkelig å følge de samme prosessene og stole på de samme sertifiseringene.
For å vite hvor vi ønsker å gå, er det viktig å undersøke hva vi har opplevd frem til nå. Selv om det ikke er tilfelle for alle OT-enheter, er sikkerhet ofte en prioritet på nivå to eller nivå tre før en enhet kommer på markedet. Handlinger, som å skanne etter sårbar kode, finner ofte sted, og det samme gjør gjennomganger av komponenter og protokoller for å sikre at enheten oppfyller samsvarskravene. Disse handlingene informerer sikkerhetssertifiseringsprosessen, som er mangelfull fordi det er en statisk, tidsmessig evaluering.
Problemet med dette er at en enhet kan gå gjennom en streng sikkerhet risikovurdering prosess før den går på markedet eller distribueres på et nettverk, men det betyr ikke at den er sikker for hele levetiden. I tillegg, under denne sikkerhetsrisikovurderingsprosessen, blir sikkerheten til de faktiske protokollene og programvarekomponentene sjelden gransket til et tilfredsstillende nivå. Vår OT:Icefall-undersøkelse fant at 74 % av produktfamiliene som ble berørt av sårbarhetene som ble oppdaget, allerede hadde mottatt en form for sikkerhetssertifisering.
Dette betyr ikke at sikkerhetssertifiseringer er meningsløse. Det betyr at vi må revurdere sikkerhetssertifiseringsprosessen.
Hvordan revurdere sikkerhetssertifiseringer
Sikkerhetsteam, produsenter og reguleringsbyråer har blitt vant til sertifiseringer som er basert på ugjennomsiktige sikkerhetsdefinisjoner og funksjonstesting. De har også blitt vant til å spille en omgang varm potet når det gjelder sikkerhetsansvar. Offentlige etater har forsøkt å legge mer ansvar på produsenter og i sin tur produsenter på sikkerhetsteam. Dette er problemet. Sikkerhetssertifisering og styring av den langsiktige sikkerhetsrisikoen til OT-enheter må ha en mer helhetlig tilnærming og være en lagsport.
Sikkerhetssertifisering i en OT-verden bør omfatte følgende:
- Veldefinerte og bredt aksepterte sikkerhetskrav knyttet til realistiske angripermodeller. Sikkerhetssertifiseringer bør tydelig angi hva de sertifiserer mot. Noen ordninger tar i bruk sertifiseringsnivåer som tilsvarer angriperklasser med økende sofistikering. Denne sofistikeringen er imidlertid definert i generiske termer, som f.eks moderate ressurser, sofistikerte virkemidler og spesifikke ferdigheter. Disse vage begrepene egner seg til tolkninger som gjenspeiler en revisors oppfatninger og forventninger. Angripermodeller og deres evner bør standardiseres. I tillegg står lavere sertifiseringsnivåer noen ganger bare for problemer som utilsiktet misbruk, som er for lemfeldig, noe som muliggjør usikre design. Grunnleggende sikkerhetskrav bør inkludere signert fastvare og krypterte og autentiserte protokoller.
- Streng testing av protokollimplementeringer. Mange sertifiseringsordninger begrenser evalueringen av sikkerhetskrav til funksjonell testing, noe som betyr at funksjoner er verifisert å være til stede, men ingen inspeksjon blir utført. Denne testingen ekskluderer vanligvis proprietære protokoller. Som sådan kan en funksjonell sikkerhetsvurdering konkludere med det godkjenning er tilstede på et ingeniørgrensesnitt, mens protokollen er uautentisert, og all autentisering gjøres på klientsiden. Likeledes vurderer kommunikasjonstester ofte bare åpne protokoller kjent av revisorer. Spesifikasjonen av alle kommunikasjonsprotokoller bør gis til revisorer under sertifiseringsarbeid, og ideelt sett bør disse protokollene evalueres på implementeringsnivå for å unngå problemer der en funksjon er tilstede, men på en sårbar måte.
- Sertifisering av individuelle komponenter til en tilkoblet enhet. Sårbarheter i forsyningskjeden er utbredt. Siden praktisk talt hver enhet består av en myriade av gjenbrukbare programvarekomponenter, bør disse komponentene betraktes som den grunnleggende enheten for testing og sertifisering. Dette kan føre til biblioteker med pålitelige komponenter og gjenbrukbare sertifiseringer som vil gjøre det mulig for enhetsprodusenter å velge fra kjente gode design og implementeringer.
- Automatisk ugyldiggjøring av sertifisering. Oppdagelsen av sårbarheter på en enhet bør automatisk ugyldiggjøre dens sikkerhetssertifiserte status inntil problemene er løst og rettet. Denne automatiske ugyldiggjøringen kan gjøres med nyere tekniske utviklinger, som f.eks programvarelisterCommon Security Advisory Framework og Vulnerability Exploitability eXchange.
Når en sertifisert enhet kjører på og kommuniserer med bedriftens nettverk, begynner det virkelige arbeidet med å administrere langsiktig sikkerhetsrisiko. Konsekvent overvåking og kontekstuell risikovurdering av OT-enheter av sikkerhetsteamet er avgjørende. Tilsvarende bør produsenter av disse enhetene kontinuerlig teste disse enhetene i nye situasjoner, revurdere enhetskomponenter for å finne nye risikoer og dele denne informasjonen med bedriftens sluttbrukere. Når det gjelder forbedring av sikkerhetsstilling, husk at vi alle er på samme lag.
Om forfatteren
Daniel dos Santos er leder for sikkerhetsforskning ved Forescouts Vedere Labs, hvor han leder et team av forskere som identifiserer nye sårbarheter og overvåker aktive trusler. Han har en doktorgrad i informatikk, har publisert mer enn 30 journal- og konferanseartikler om cybersikkerhet, og har talt på konferanser inkludert Black Hat, Hack In The Box og x33fcon.