Sådan sikrer du, at IT-sikkerheden af produkter er tilstrækkelig i hele levetiden

Begreber som Internet-of-things (IoT) og Industry 4.0 er blevet benyttet flittigt i de seneste år, og det er ikke småting, der bliver lovet af løsninger. Fra at køleskabet selv kan bestille varer, som er ved at være brugt op, til overvågning af produktionslinjer og godstransport. Der er mange gevinster at hente både økonomisk og samfundsmæssigt. Disse bunder dog alle i sidste ende i, at systemerne har en fornuftig pålidelighed – med andre ord at de fungerer næsten 100 % af tiden. I takt med at flere og flere enheder indeholder software, vil denne funktion også blive mere og mere afhængig af IT-sikkerhed. Men hvordan sikrer vi os, at produkterne er tilstrækkeligt sikre og forbliver sikre i hele deres levetid?

Skyggeeffekten IT versus OT

Flere og flere virksomheder bliver ramt af cryptolockere, ransomware, phishing angreb og det, der er værre. Dette er en trussel, som er kraftigt voksende, men de fleste større virksomheder er ved at have styr på de værktøjer og procedurer, der skal benyttes samt den kultur, som skal fremavles for at sikre virksomheden. Den helt store udfordring er, at dette primært handler om IT-systemer, e-mails, servere, fildeling, medarbejderregistre, økonomisystemer etc. Altså IT i den oprindelige forstand – InformationsTeknologi.

Men der ligger en lige så stor trussel lige i skyggen af IT, og det er OT – OperationsTeknologi. Dette er systemer, som sidder i produktionslinjer, bilernes kontrolsystemer, signalsystemerne til tog etc. Det er den teknologi, som de fleste danske virksomheder inkluderer i sine produkter for at blive ved med at være konkurrencedygtige og have forretningsmodeller, der er baseret på servitization. Hvad ville der ske med din virksomhed, hvis samtlige af dine produkter blev låst med et password, som hverken I eller kunderne kendte og med en besked om, at det koster 1000 USD at få dette password? Eller endnu værre, hvad hvis I er underleverandør til en nøglekunde, og deres udstyr holder op med at fungere, fordi jeres komponent er blevet låst? Udfordringen er, at de fleste virksomheder har rigeligt at slås med hensyn til IT og derfor glemmer OT.

Hav en ambitiøs men realistisk screeningproces

Tanken bag langt de fleste cybersikkerhedsstrategier er i dag 360 graders beskyttelse. Det vil sige, man tager højde for access control, kommunikaitonssikkerhed, hændelseshåndtering osv. på systemniveau. Dette er en effektiv strategi, men fører ofte til, at man har et stort arbejde med at validere alle de små komponenter, der opbygger systemet.

Samtidigt er det også værd at huske, at mange systembyggere ikke har dybdegående viden omkring cybersikkerhed og ikke ved, hvad de skal kigge efter på komponentniveau. Derfor er det vigtigt at have en troværdig screening af cybersikkerheden for produkterne. Samtidigt er det vigtigt, at denne screening har et ambitionsniveau, der er realistisk i forbindelse med det, den skal bruges til. Det er ikke nødvendigt at have samme sikkerhedsniveau som for fly og atomkraftværker, men det er essentielt, at botnet-algoritmer som Petya og Wannacry ikke får adgang, bare fordi der ikke er patchet.

Hav en grundig process for risikoanalyse 

Det første element i en screening af et produkt er gennemgang af dokumentationen til produktet og ”intended use”, altså tiltænkt brug. Hvad skal produktet bruges til, og hvor sidder det? Er der firewall før produktet? Må det kun installeres på bestemte måder? Og er der begrænset fysisk adgang til produktet? Når dette er klarlagt, er det tid til at se på risikoanalysen.

Hvad er risikoen for at en given funktion kan kompromitteres, og hvad er konsekvenserne, hvis den bliver det? De to værdier ganget med hinanden bliver så den samlede risikoscore. Dette er fx en vurdering af, at en pumpe, der pumper kølevand rundt i en motor og slår automatisk fra, når temperaturen kommer under en grænseværdi, kan aktiveres via et GSM-modem, som kræver en 4-cifret adgangskode. Dette har altså en rimelig lille konsekvens, men en middelstor risiko for, at denne adgangskode bliver brudt. Altså en samlet vurdering på ’middel’.

Men hvis der ikke er nogen automatisk stopfunktion, og denne derfor også styres via GSM-modemmet, kan pumpen stoppes for tidligt og derved overophede motoren med stor konsekvens til følge. Altså en høj samlet vurdering og et behov for at mitigere, dvs. formindske risikoen for, at dette sker, fx med stærkere adgangskode. Samtidigt er der også krav til, at der skal være en proces i virksomheden for overvågning af cyber-usikkerheder i produktet. Hvis der kommer en sikkerhedspatch, skal der være en strategi for, hvordan denne bliver implementeret i produktet.

Testen

Det sidste og nok mest interessante for fagnørden er testen. Denne vil normalt indeholde 3-5 tests og en analyse. De 5 mest normale testtyper er:

1. Sårbarhedstest – eller vulnerability test

Tester efter kendte sårbarheder i software moduler, som benyttes i produktet på alle de interfaces, der er tilgængelig udadtil.

2. Infektionstest – eller malware test

Det kontrolleres, om produktet er inficeret med malware eller bagdøre fra dag 0.

3. Forvirringstest – malformed input

Man forsøger at forvirre produktet ved at sende tusindvis af fejlagtigt formaterede beskeder mod produktet.

4. Krypteringstest

Man tester om alle kritiske data, der bliver sendt og modtaget fra produktet, er krypteret og ikke bliver sendt som klar tekst.

5. Struktureret penetrationstest

Man prøver at omgå de sikkerhedsforanstaltninger, der er beskrevet i dokumentationen, såsom at omgå at skulle indtaste adgangskode.

Testene fungerer på den måde, at de skal understøtte, at de tiltag, der er beskrevet i dokumentationen af produktet, rent faktisk også er blevet implementeret og dækker korrekt. Det er ikke en 100 % test (for så bliver man aldrig færdig), men det er en stikprøveverifikation på de mest åbenlyse huller.

Derefter er der nogle ting, som er meget svære at fange i en test. For eksempel hvis der er en stump kode, der gerne vil sende fortrolige data hjem hver 3. uge. Denne type af fejl fanges lettere ved at analysere koden, og derfor er det sidste trin af en screening af et produkt, at der foretages et kode-review af en fagperson, som er specialist i netop det kodesprog, der er brugt i produktet.

Less is more

Det essentielle i hele tilgangen til screeningen er dog, at ambitionsniveauet skal sættes ud fra risikoanalysen. Derved kan basal cybersikkerhed sikres for lavrisiko produkter, fx at der er en adgangskode og at det ikke kan sættes til ’1234’, mens de mere kritiske produkter kræver en stærkere sikkerhed, som vi kender det fra EMC-krav, functional safety krav eller medical device krav.