Kamstrup: Nødvendigt at få white hackere til at teste vores IoT-udstyr

Et skrækscenarie for virksomheder, der leverer IoT-udstyr til forsyningssektoren, er, at hackere og ondsindede mennesker overtager kontrollen med udstyret.

Det ved de også i teknologivirksomheden Kamstrup i Skanderborg, hvor it-sikkerhed altid har været prioriteret højt. Men med målere forbundet over internettet har sikkerheden dog alligevel fået et hak opad.

»Vores skrækscenarie og vores kunders skrækscenarie er, at der er nogen, der evt. sidder langt væk og potentielt kan hacke sig ind og skade systemet. Det kan jo være systemer, der ender med at lukke for strømmen til en hel by eller et hospital, altså steder hvor det koster rigtig mange penge og potentielt menneskeliv, så derfor skal vi være kritiske med vores sikkerhedsvurderinger,« fortæller Carsten Nielsen, der er Head of Product Management i Kamstrup.

Dyrt bekendtskab

Kamstrup sælger intelligente måleløsninger inden for el, varme, køling og vand til energiselskaber og forsyningsselskaber i hele verden, og usikkerhed omkring et produkt kan hurtigt blive et dyrt bekendtskab.

»Vi vil ikke læse i avisen, at nu er sikkerheden i en IoT-teknologi brudt, og det påvirker millioner af vores målere. Nogle af udfordringerne kan man løse med en form for software-opdatering, men lykkes det at bryde sikkerheden i en eller anden kommunikationsteknologi på en måde, så det kræver, at vi skal skifte nogle målere, så er det jo et kæmpe projekt og milliarder af kroner, vi taler om,« uddyber Carsten Nielsen.

Ekstra sikkerhedslag

Som udgangspunkt anvender Kamstrup standard-produkter til f.eks. kommunikationen, men for at være på den sikre side har Kamstrup også udviklet deres eget sikkerhedslag, som de lægger uden på standardkomponenterne.

»Vi arbejder meget med penetrationstest - både af vores egne systemer og ude hos kunderne i deres installationer. Vi bruger også eksterne it-sikkerhedseksperter og white hats og får deres vurdering af vores systemer og får dem til at forsøge at hacke sig ind i vores systemer. Der er ikke nogen tvivl om, at it-sikkerhed er stort inden for forsyningsbranchen.«

Kamstrup har også kontakt til universiteter, hvor professorer og studerende kommer med deres vurdering og evaluering af systemsikkerheden.

Carsten Nielsen har indlæg på sikkerhedskonference Infosecurity 2018, hvor han vil fortælle mere om udfordringerne med anvendelse af IoT-enheder, og hvordan Kamstrup tackler sikkerheden på den bedste måde.

sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først

Lugter det ikke lidt af, at Kamstrup ikke selv tror at det er sikkert - så de skal have hackere til at teste det for sig.

Jeg synes det er positivt at man begynder at erkende at man ikke kan lave noget 100% sikkert og at vejen frem er åbenhed fremfor at forsøge at gemme sig. En dedikeret "black hat" skal nok få fat i en udgave af udstyret, splitte det ad og finde en vej ind.

Problemet er at du skal stole på rigitg mange forskellige parter i udviklingen af dit produkt:

  • chips/processorer med mangelfuld dokumentation - fordi ingen helt præcist ved hvordan de virker. Endvidere kan der være tilsigtede bagdøre
  • underleverandører der f.eks putter bonus kredsløb (bagdøre) ind i printkort m.m.
  • Hele stakken af udviklingsværktøjer og compiler optimering, der kan give utilsigtede "features"
  • Forsmåede ansatte eller ansatte der er kommet i klemme (afpresning)
  • Find selv på mere

Vi kan alle bygge vores eget lille "Fort Knox" paradis vi ikke selv kan bryde ind i. Det kræver mange øjne - jo flere jo bedre - at opbygge solid sikkerhed. Det eneste der er 100% sikkert er at der ikke er noget der er 100% sikkert ;)

  • 1
  • 0

Problemet er at du skal stole på rigitg mange forskellige parter i udviklingen af dit produkt:

chips/processorer med mangelfuld dokumentation - fordi ingen helt præcist ved hvordan de virker. Endvidere kan der være tilsigtede bagdøre  

I embedded produkter er der ingen utilsigtede bagdøre. Der er ingen ekstern hukommelse til koden. Koden ligger i selve microprocessorens flash. Og, når den programmeres, til at ikke kunne læses ud, så er det umuligt at læse den ud. Bagdøren - det er, når virksomhederne glemmer at programmere den, til at ikke kunne læses ud. Og det er her, at man skal sætte ind. Derudover kan flere processorer også programmeres med en bagdør. Og så kan det være fint, at man bruger en hacker, for at se om de kan gætte det password man har lagt på. Men, man programmerer altså selv bagdøren ind! Endeligt, så er det muligt at sætte nogle bits, der tillader producenten kan få adgang til koden. Disse bestemmer man selv om man vil sætte. Typiske fejl, er at bittene sættes forkert. Jeg har aldrig hørt om, at nogen har fået adgang til kode, hvor bittene har været programmeret i henhold til producentens anvisninger.

Den næste bagdør, er når det kommer til koden. Her er ikke umuligt, at udviklere lægger bagdøre ind, for at kunne f.eks. se hvordan kunden bruger produktet, og for at kunne omprogrammere koden, og for at kunne vedligeholde den. Det er helt tilsigtede bagdøre, som producenten lægger ind. Også her, kan det være relevant at have en hacker til at se, om de kan gætte eller finde koden, ved at aflytte kommunikationen, når producenten opgraderer. Faktum er, at det normalt ikke er muligt. Det som sker, er at det er tale om insider viden, som på en eller anden måde havner i hacker kredse. Eller ved at kode der ikke var tænkt til offentliggørelse, bliver offentliggjort ved en fejl. Mange hackere påstår, at det mest sikre er at offentliggøre koden. Men, hvis koden ikke er lavet til offentliggørelse, så er det naturligvis en fejl at gøre det. I embeddede produkter, har hackere normalt ikke mange muligheder, uden at kende koden. Det vil sige, at de igen enten skal have insider viden, eller mulighed for at få koden på anden vis.

Der er altså to årsager til bagdøre:

1) At virksomheden har gjort noget dumt, f.eks. ikke programmeret chipsene til den tilsigtede beskyttelse, eller at de offentliggør kode og oplysninger, som ikke skulle offentliggøres.

2) At hackerne kommer i besiddelse af insider viden, f.eks. ved at bestikke, betale, eller at der er en ingeniør, som mener at hackerne skal have viden om hvordan produktet fungerer - det kan ske f.eks. at ingeniøren fyres, at ingeniøren mener produktets håndtering af data er uetisk, f.eks. at produktet optager data, der ikke burde kunne aflæses af virksomheden.

Og i ingen af de to ovenstående tilfælde, nytter det noget, at virksomheden ansætter et hold hackere til at teste udstyret!

Det er præcis samme teknik, som når virksomheder ansætter læger, til at sige at medarbejderne ikke bliver syge af jobbet. Det er ævl og latin.

  • 0
  • 0
Bidrag med din viden – log ind og deltag i debatten