Varför system är osäkra, och vad utvecklare kan göra åt det

Det finns ingen magisk genväg till säkerhet. Men att behandla säkerhetsarbetet som något mer än bara en eftertanke när man utvecklar saker och bygger system är ett bra ställe att börja.

Författare: F-Secure Business Security Insider
Datum: 12.07.2017
Lästid: 5 Minuter

Det kanske vanligast förekommande rådet man kan få från en säkerhetsexpert är att se till att köra uppdaterade, fullt patchade system. Det är inte konstigt, för det är ett mycket bra råd med tanke på hur system konstrueras och implementeras. Du behöver bara titta närmare på WannaCry-utbrottet för att förstå hur det går till när en enda enskild sårbarhet skapar kaos över hela världen.

Men en sak som det pratas betydligt mindre om är något som F-Secures säkerhetskonsult Olle Segerdahl pratade om på konferensen T2 förra året – Hur man bygger system som är säkra redan från början.

Det övergripande problemet är att företag inte sätter säkerhet i första rummet. Det är något man lägger på när produkten eller tjänsten redan är färdig. Som Olle påpekar så brukar företag först bygga något och först därefter testa det för att då upptäcka eventuella problem – som exempelvis att det de byggt inte är tillräckligt säkert. Och då tar man tag i det.

Det finns flera olika sätt att testa säkerheten hos en specifik tjänst eller produkt. Det traditionella är att företaget kör en serie säkerhetstester, eller penetrationstester, på en så gott som färdig produkt för att upptäcka problem. Sedan åtgärdas de problem som testet blottlade innan man går vidare.

Den typen av tester är värdefulla, men det finns begränsningar. Till exempel har de en tendens att vara mer effektiva ju mer pengar, tid och resurser som företaget lägger på att utföra dem. Det finns också stora skillnader beroende på om de utförs en gång eller om de utförs återkommande under utvecklingsarbetet. Dessutom spelar det stor roll vad som inkluderas i testprocessen (eller mer exakt: vad som inte är en del av testet).

Enligt Olle räcker det inte med att göra ett test efter att man har en färdig produkt eller tjänst för att kunna ge ett acceptabelt svar på frågan Är det säkert?

Tester kan ge en användbar lista över buggar att åtgärda, men att hitta och fixa buggar är inte samma sak som att bygga ett säkert system. Det finns som sagt problem både vad gäller metod och resursallokering som kan begränsa hur effektivt ett säkerhetstest är. Det innebär också att utvecklare lägger fokus på att åtgärda problem snarare än att proaktivt arbeta för att minimera antalet problem.

Och i ett längre perspektiv är det ju så att det utgör en risk om man låter cyberbrottslingar komma över säkerhetsluckor som man själv missat – det kan sätta såväl det egna företaget som partners, återförsäljare och kunder i riskzonen och ge samtliga inblandade parter stora problem.

 

Argumenten för att bygga säkra system

Knäckfrågan är att hitta ett tillförlitligt sätt att besvara frågan ”Är det säkert?”

Ett annat sätt att formulera den frågan är ”kommer det att kosta mer för en angripare att ta sig in och stjäla informationen än vad informationen är värd för dem?”

Enligt Olle Segerdahl finns det goda exempel på utvecklingsprocesser där säkerhet är prioriterat, bland annat inom transportindustrin där man ofta använder sig av strukturerade argument för att visa att något är säkert att använda inom ramarna för ett antal förutbestämda variabler. Det är en metod som används av de flesta aktörer för att påvisa att ett fordon – eller någon särskild typ av utrustning – är säkert att använda på det sätt som det är avsett att användas.

Under sitt föredrag så lyfter Olle fram en mer allmän variant av den här metoden, kallad ”assurance cases” som något som utvecklare kan använda sig av. Det inbegriper att man utgår från att ett påstående om en specifik egenskap hos systemet är sant. Till exempel att ”systemet verifierar användarens identitet innan den delar någon känslig information med dem”. Detta påstående kan utvecklare, testare, konsulter och andra som är involverade i utvecklingsprocessen sedan verifiera och lägga fram bevis för.

Nyckeln är att använda det här som en del av utvecklingsprocessen och kontinuerligt ta fram nya argument, uppdatera de befintliga – och självklart även undersöka om de stämmer. Genom att genomföra det här utvärderingsarbetet sida vid sida med utvecklingsarbetet så kan de båda processerna lyfta varandra genom att det skapas synergier mellan säkerhetskrav och systemdesign och implementering.

Utvecklingsarbetet innehåller flera av de delar som den här processen kräver – analys av arkitektur och identifiering av de risker som systemet behöver hantera med olika typer av säkerhetskontroller; säkerhetsingenjörer som kan se till att systemet designas på rätt sätt och att rätt säkerhetskontroller implementeras; och validering av de implementerade kontrollerna för att bevisa att kontrollerna finns på plats och gör det de ska.

Processen innebär också att man automatiskt avvecklar modellen med säkerhetstester i slutet av utvecklingsarbetet. Genom det här tillvägagångssättet kan man visa upp att utvecklarna har designat och testat produkten kontinuerligt på ett sätt som minimerar risken för säkerhetsluckor. Det är så man måste göra för att säkerhet inte ska vara något man slänger på i slutet, utan något man bygger in.

Det här är för övrigt precis vad en stor del av IoT-branschen skulle behöva ta till sig. F-Secure har under det senaste året hittat sårbarheter i bland annat webbkameror, routrar och lagringsenheter.

Många företag som inte har någon som helst erfarenhet av att utveckla uppkopplade prylar tillverkar idag så kallade ”smarta” prylar (eller sårbara, som Mikko Hyppönen säger). Och brottslingar lär sig hur de ska göra för att utnyttja dessa prylars sårbarhet, vilket inte minst visade sig i och med förra årets enorma DDoS-attacker.

En del experter menar att det krävs regleringar för att tvinga IoT-tillverkare att prioritera säkerhet. Men den modell som Olle Segerdahl lyfter fram skulle kunna vara ett kostnadseffektivt alternativ till trubbiga regleringar och komplicerade lagar – genom att helt enkelt göra säkerhetsarbetet till något hanterbart och praktiskt för företagen och deras utvecklare.

Det kanske inte finns någon magisk genväg att ta, men en sak är säker: alla kommer att tjäna på att säkerhet blir mer än bara en eftertanke.

Podtips:

Olle Segerdahl och Cristoffer Jerkeby är inne på just det här temat i ett avsnitt av podcasten Säkerhetssnack för ett tag sedan – om hur företag bör göra säkerhet till en del av sina utvecklingsprocesser.

Podden finns på Itunes och överallt där du går för att få dina poddbehov tillgodosedda.

 

[Foto: Alan Levine, Flickr]


Lämna ett svar

Fyll i dina uppgifter nedan eller klicka på en ikon för att logga in:

WordPress.com Logo

Du kommenterar med ditt WordPress.com-konto. Logga ut / Ändra )

Twitter-bild

Du kommenterar med ditt Twitter-konto. Logga ut / Ändra )

Facebook-foto

Du kommenterar med ditt Facebook-konto. Logga ut / Ändra )

Google+ photo

Du kommenterar med ditt Google+-konto. Logga ut / Ändra )

Ansluter till %s