En av sakerna som diskuterats under dagen är den snedvridna synen IT-säkerhetsbranschen överlag många gånger har i form av att man identifierar ett enskilt problem för att därefter ta fram produkter för att adressera problemet ifråga. Det är förvisso en god tanke att hitta lösningar på de säkerhetsproblem som utmanar tillvaron men det är inte speciellt komplicerat att komma fram till det faktum att det skalar otroligt dåligt att anskaffa, underhålla och få ut maximalt värde ur enskilda säkerhetsprodukter som bara är tänkta att lösa enskilda problem och som saknar förmåga att samverka med övrig säkerhetsinfrastruktur.
I takt med att mängden enskilda säkerhetsprodukter växer i kombination med att mängden risker och hot förändras över tid ökar komplexiteten och arbetsinsatsen associerad med nyttjande, förvaltning och underhåll, varje ”låda” ska tas om hand på ett tillräckligt bra sätt och någon ska ju förhoppningsvis vara beredd att reagera på situationer som ”lådan” ifråga är tänkt att skydda mot. Vilket värde har exempelvis en intrångsdetektor vars larmfunktion inte är tillräckligt bra anpassad eller vars larm ingen reagerar på?
En sammanfattande kommentar från oss är att branschen måste sluta upp med att enskilda problem ska lösas med enskilda produkter eller produktsviter som inte har förmågan att integreras med övrig säkerhetsinfrastruktur. I en nykter verklighet existerar inte tanken på att inköp av en ny ”låda” är det som ska lösa de säkerhetsutmaningar som man står inför. Här har både leverantörsledet och konsumentledet en hel del att fundera över om man menar allvar med att adressera säkerhetsfrågor på sätt som ligger i linje med skyddsvärde samt förmågan att faktiskt tillämpa skyddsåtgärder i relation till sammanhang, risker, hotbild och den egna förmågan att dra nytta av de verktyg som behövs i kampen mot incidenter och illasinnade element.
Ett annat viktigt område som togs upp var hur man hanterar kodbasen på uppkopplade enheter, allt från telefoner, kameror och sensorer, det som också kallas IoT, Internet of Things. Den gemensamma nämnaren för dessa enheter är att koden ofta måste laddas ned på omständigt sätt, den är inte generisk utan specifik för varje modell och version och att man som användare helt är i beroende av att leverantören visar intresse att uppgradera. Koden i dessa enheter är också, i majoriteten av fallen, en blandning av proprietär programvara och programvara som hämtats som öppen källkod. Utvecklarna är naturligtvis lata när det gäller utveckling och om det finns en programvara som löser ett problem och den finns tillgänglig för nedladdning och licensvillkoren tillåter användning av den så är det självklart lockande att nyttja den.
Problemet som uppstår är nu flera: vem bär ansvaret att ta fram uppdateringar om man hittar sårbarheter i den öppna källkoden, hur ser man till att enheterna blir uppdaterade och hur informerar man användarna om vilken öppen programvara man använder? Den första punkten skulle även kunna inkludera den proprietära delen av koden, men delen är oftast inte lika utsatt för att bli granskad efter sårbarheter som den öppna källkoden som har en mycket större distributionsbas och således ett större mål. Redan idag vet vi om ett antal allvarliga säkerhetshål som resulterat i att behovet att IoT-enheter måste uppdateras: Heartbleed i OpenSSL (2014), bufferöverskrivning i Glibc (2016) och libxml2 (2013). Många projekt för öppen källkod är också rätt inaktiva, likväl som att en gammal version kan ha använts. En början till lösning är att man som kund tvingar tillverkaren att uppge vilka öppna källkodsbibliotek som används i produkten och vilken version det är. Då har man i alla fall en chans att veta vilka sårbarheter som finns och använda kompletterande skydd om det inte kommer någon uppdatering.
Conny Balazs och Carl Önne
