Cybersäkerhet börjar ofta i fel ände.
Ett nytt verktyg dyker upp. Någon ser en teknisk möjlighet eller identifierar ett säkerhetsproblem. Ett initiativ startas och ganska snart diskuterar vi produkter, implementationer och tekniska lösningar.
Det behöver inte betyda att lösningen är fel. Problemet är snarare att det ofta saknas ett lager ovanför tekniken: en tydlig förklaring av vad det är i verksamheten vi försöker skydda, varför det är viktigt och hur den tekniska åtgärden bidrar till det.
Tekniken och verksamheten pratar olika språk
I en tillverkande verksamhet kan ett cybersäkerhetsteam arbeta med exempelvis nätverkssegmentering, identity and access management, backup och recovery, remote access, övervakning och en mängd andra tekniska och organisatoriska åtgärder.
Mycket av detta är såklart helt nödvändigt.
Men en fabrik tillverkar produkter. Fabriksledningen har produktionsmål, kostnader, kvalitet, leveranser och tillgänglighet att förhålla sig till. Att säkerhetsteamet implementerar en PAM-plattform eller förbättrar en backup-process är inte nödvändigtvis ett språk som verksamheten kan eller ska behöva förstå.
Där uppstår ett översättningsproblem.
Teknikerna behöver kunna gå upp en nivå och förklara vilket värde säkerhetsarbetet skapar för verksamheten, utan att för den skull förenkla bort komplexiteten som faktiskt finns under ytan.
Jag tror att vi behöver bli betydligt bättre på just det.
Börja högre upp
Ett sätt att göra det är att börja med de faktorer som faktiskt driver säkerhetsarbetet.
Företagets strategi är en sådan faktor. Om ledningen har pekat ut en riktning för verksamheten bör även cybersäkerhetsarbetet kunna kopplas till den riktningen.
Andra drivkrafter kommer utifrån. NIS2, GDPR och andra regulatoriska krav påverkar verksamheten. Ramverk och standarder som IEC 62443 kan också skapa krav och vägledning.
Strategiska beslut kan dessutom förändra förutsättningarna. Ett företagsförvärv, etablering på en ny marknad eller en förändrad produktionsmodell kan innebära nya risker och nya säkerhetsbehov.
Drivkrafter kommer från olika håll: strategiska drivkrafter inifrån organisationen och externa krav från exempelvis lagstiftning och regelverk.
Därifrån kan man börja arbeta sig nedåt.
Från säkerhetsprocess till verksamhetsvärde
Nästa steg är, åtminstone i mitt sätt att tänka, att inte omedelbart gå ner till tekniken.
Ta backup och recovery som exempel.
För verksamheten är värdet knappast att säkerhetsteamet har en backup. Värdet är att verksamheten kan återhämta sig när någonting händer.
En backup som inte fungerar att använda för att återställa har inget värde. Ganska självklart kan tyckas. Därför behövs processer för att verifiera backup, testa återställning och öva på vad som faktiskt händer när systemen måste återställas.
Backup och recovery är en del av någonting större.
Det skulle exempelvis kunna beskrivas som Factory Resilience – fabrikens förmåga att motstå störningar och återhämta sig när någonting inträffar. Vilka störningar kan inträffa och hur kommer vi tillbaka med minimal påverkan för vår verksamhet och våra kunder?
Samma resonemang kan användas för access.
Identity and access management, privileged access management, remote access för leverantörer och kanske även fysisk access till fabriken är olika processer och tekniska lösningar. Vilka fysiska och logiska vägar finns in till tex fabriken och hur skyddar vi dessa?
Men på en högre nivå skulle de kunna samlas under något i stil med Secure Access.
Affärsvärdet ligger dock inte i namnet på tjänsten, utan i minskad avbrottstid, säkrare återställning och bättre förmåga att hålla produktion och leveranser igång.
Det är det värdet verksamheten behöver förstå. Under ytan kan det sedan finnas ett stort antal processer, applikationer, tekniska komponenter och specialister som gör tjänsten möjlig.
Färre begrepp uppåt – mer detaljer nedåt
I ett arbete jag varit involverad i utgick vi från de säkerhetsprocesser och ansvarsområden som redan fanns.
Sedan ställde vi en ganska enkel fråga:
Vilka av dessa hör ihop, och hur kan de grupperas på ett sätt som är meningsfullt för verksamheten?
I vårt fall resulterade det i ungefär fem övergripande business services. Under dem fanns ett större antal säkerhetsprocesser. Under processerna finns i sin tur applikationer, tekniska lösningar och ibland manuella arbetssätt.
Antalet fem är inte viktigt. I en annan organisation kanske det är tre eller åtta.
Poängen är att verksamheten inte ska behöva förstå allt som händer under ytan för att förstå vad säkerhetsfunktionen bidrar med och varför det behövs.
Ju längre ner man kommer, desto större blir detaljnivån och desto snabbare sker förändringen. Verktyg byts ut. Applikationer förändras. Skript skrivs om. Tekniska lösningar kommer och går.
Högre upp är förändringstakten betydligt långsammare.
Behovet av motståndskraft försvinner inte för att backupplattformen byts ut.
En bild av hur allt hänger ihop
Det är här en enkel modell kan vara användbar. Genom att beskriva sambanden mellan drivkrafter, verksamhetsbehov, säkerhetsprocesser och tekniska lösningar blir det lättare att se varför en åtgärd behövs och vad den bidrar till.
Tanken är att kunna följa en röd tråd:
Strategi och externa krav → verksamhetsvärde → säkerhetsprocesser → applikationer och teknik.
Helst skulle mycket av detta kunna visas i en enda begriplig bild, eller möjligen i ett mindre antal vyer av samma modell.
Som en återkommande påminnelse kring hur säkerhetsarbetet passar in i de övergripande målen och strategierna.
När frågan kommer – varför gör vi det här egentligen? – ska det gå att peka på modellen och följa sambandet tillbaka till verksamheten.
Förenkling betyder inte att säkerhet är enkelt
Förenklar man för mycket kan det se ut som att cybersäkerhet är trivialt. Det är den inte.
Att exempelvis implementera nätverkssegmentering, identity management eller säker remote access i en global industrikoncern kan vara mycket komplext och kräva djup specialistkompetens.
Den kompetensen blir inte mindre värdefull för att vi beskriver resultatet på ett enklare sätt.
Poängen är snarare att komplexiteten ska finnas på rätt nivå.
En ledningsgrupp behöver inte förstå varje teknisk detalj. En säkerhetsingenjör behöver däremot göra det. Mellan dessa nivåer behövs ett språk som gör att båda kan förstå vad som ska åstadkommas och varför.
Det är det lager jag tycker ofta saknas.
Cybersäkerhet som en del av verksamheten
Jag tror att mycket cybersäkerhet skulle vinna på att beskrivas enklare.
Inte genom att förenkla bort problemen, utan genom att skala bort terminologi och tekniska detaljer när de inte behövs.
I grunden handlar mycket av det vi försöker åstadkomma om ganska begripliga saker.
Vi vill kunna fortsätta producera när något händer.
Vi vill kunna återhämta oss.
Vi vill att rätt personer ska ha rätt åtkomst.
Vi vill förstå våra risker.
Och vi vill kunna bedriva verksamheten i linje med de lagar, krav och strategiska beslut som gäller för företaget.
Det är affärsvärden.
Tekniken, processerna, standarderna och specialisterna behövs för att skapa dem.
Jag tror bara att vi behöver bli bättre på att visa hur allt hänger ihop.
Läs mer om saker att tänka på när man väljer cyberförsäkring som metod för risköverföring eller se hur säkerhetsskulder kan skapa problem och driva kostnader längre fram.