Security by design – hur bygger man säkerhet från början i industrin?

Att bygga in säkerhet i produktutvecklingen från start, snarare än att lägga till det i efterhand, har blivit en självklar princip i många branscher. Men hur gör man det i praktiken – särskilt i industriella miljöer där system ofta är komplexa, uppkopplade och utvecklade under lång tid? I den här artikeln delar Robert Mungenast, CISO på Electrolux, och Jonas Stewén, VD på Secify, med sig av konkreta insikter och tips från verkligheten.

Vad är security by design?

Security by Design är ett angreppssätt där säkerhet integreras i varje steg av produktutvecklingen – från idé och kravställning till design, kodning, testning och underhåll. Det innebär att säkerheten inte ses som ett tillägg i slutet av processen, utan som en grundläggande komponent från början.

Syftet är att identifiera och hantera säkerhetsrisker tidigt, när det fortfarande är enkelt och kostnadseffektivt att göra justeringar. Det kan handla om att sätta rätt behörigheter, välja säkra kommunikationsprotokoll, kryptera data, och se till att systemet tål både kända och okända hot.

För industrin, där produkterna ofta har lång livslängd och är tätt integrerade i fysisk infrastruktur, är security by design särskilt viktigt. Att åtgärda en sårbarhet efter att en produkt är lanserad – eller i drift i en fabrik – är betydligt svårare än att bygga bort problemet redan i ritstadiet.

Från sent påkomna tester till integrerad säkerhet

Robert Mungenast beskriver hur synen på säkerhet i produktutveckling har förändrats drastiskt de senaste åren:

– Det har skett en enorm förändring, mycket tack vare ökad mediebevakning, bättre förståelse för hotbilden och ny kompetens från andra branscher – till exempel fordonsindustrin, som legat före i det här. Men det handlar också om att börja tänka livscykel: från utveckling till användning hos kund.

Tidigare gjordes säkerhetstester ofta i slutet av utvecklingsprocessen – ibland så sent som dagen innan lansering. Det innebar stora risker och förseningar. I dag har Robert och hans team infört strukturer för att få in säkerhet redan i utvecklingens första steg:

– Vi har satsat mycket på att utbilda utvecklare i säkerhet, och infört så kallade Security Champions – säkerhetsambassadörer i utvecklingsteamen som fungerar som bollplank och pådrivare. Det är ett sätt att bygga förståelse och ansvar direkt i arbetet.

Dessutom har man investerat i verktyg för att automatisera säkerhetstester av koden under utveckling, något som tidigare saknades helt.

Säkerhet handlar inte om att bromsa – utan om att få bättre produkter

Jonas Stewén lyfter fram att det ofta krävs en kulturell förändring, särskilt i mindre organisationer:

– Det handlar om att inte se den som lyfter säkerhetsfrågor som en bromskloss, utan som en hjälte. Säkerhet är inte något som hindrar utvecklingen – det är en förutsättning för att det ska bli bra i slutändan.

Han gör också en jämförelse mellan två ytterligheter inom mjukvaruutveckling: den gamla vattenfallsmodellen där säkerhet kommer sent, och vissa agila arbetssätt där den nästan glöms bort helt:

– Båda modellerna har brister. Det viktiga är att ta upp säkerhetsfrågorna tidigt, men att också kunna iterera och anpassa kraven under resans gång. Man måste veta vad man faktiskt försöker skydda, annars riskerar man att lägga krav utan mål.

En ”kickstart” kan göra skillnad

För organisationer som vill komma i gång med security by design rekommenderar Jonas att man gör en ordentlig uppstart:

– Det kan handla om att göra en mognadsanalys, eller att driva ett avgränsat pilotprojekt under ett halvår. Det viktiga är att få igång något konkret. Annars är risken stor att det bara blir en god ambition som inte blir verklighet – det är för mycket annat som pockar på.

Vanliga misstag i säker produktutveckling – och hur de kan undvikas

Trots goda ambitioner faller många organisationer i samma fällor när det gäller att bygga säkra produkter. Här är några av de vanligaste misstagen – och hur du undviker dem:

1. Att tänka säkerhet för sent
   Ett klassiskt misstag är att börja fundera på säkerhet först när produkten nästan är klar. Då blir det dyrt och svårt att rätta till grundläggande brister.Lösning: Det kanske är självklart, men det måste ändå sägas. Det bästa är att integrera säkerhet redan från kravställningen – security by design handlar just om att börja i tid.
2. Att inte förstå vad som faktiskt ska skyddas
   Säkerhetskrav sätts ibland på rutin, utan koppling till produktens användning, hotbild eller konsekvenser av ett intrång.Lösning: Gör en enkel hotmodellering tidigt i projektet – identifiera vad som är viktigt, vad som kan hända och vem som kan tänkas vilja utnyttja svagheter.
3. Att inte testa tillräckligt – eller testa fel saker
   Säkerhetstester skjuts ibland upp eller görs bara mot färdig produkt, ofta i form av ett enstaka penetrationstest.Lösning: Använd automatiserade verktyg för att testa säkerhet kontinuerligt under utvecklingen – och komplettera med manuella tester mot verkliga risker.
4. Att sakna strategi för uppdateringar och underhåll
   En produkt är inte ”färdig” när den lanseras. Om det inte finns en plan för att uppdatera mjukvara eller hantera sårbarheter i efterhand ökar riskerna snabbt.Lösning: Sätt en livscykelstrategi redan från start. Hur länge ska produkten stödjas? Hur levereras uppdateringar? Vem ansvarar för vad?
5. Att låta säkerhetsfrågor isoleras i en liten grupp
   Om bara säkerhetsteamet tänker på säkerhet blir den ofta en bromskloss – och integreras inte naturligt i produktutvecklingen.Lösning: Bygg in säkerhet i hela organisationen. Lyft fram säkerhetsambassadörer, utbilda utvecklare och se till att säkerhet blir en gemensam angelägenhet.