Examensarbete
Kandidatexamen
Riskbaserad säkerhetstestning
En fallstudie om riskbaserad säkerhetstestning i utvecklingsprojekt
Risk-based security testing: A case study on risk-based security testing in development projects
Författare: Pontus Engblom Handledare: Hans Jones Examinator: Azadeh Sarkheyli
Ämne/huvudområde: Mikrodataanalys Kurskod: GMI2C8
Poäng: 15hp
Examinationsdatum: 2020-06-02
Vid Högskolan Dalarna finns möjlighet att publicera examensarbetet i fulltext i DiVA.
Publiceringen sker open access, vilket innebär att arbetet blir fritt tillgängligt att läsa och ladda ned på nätet. Därmed ökar spridningen och synligheten av examensarbetet.
Open access är på väg att bli norm för att sprida vetenskaplig information på nätet.
Högskolan Dalarna rekommenderar såväl forskare som studenter att publicera sina arbeten open access.
Jag/vi medger publicering i fulltext (fritt tillgänglig på nätet, open access):
Ja ☒ Nej ☐
Högskolan Dalarna – SE-791 88 Falun – Tel 023-77 80 00
Abstract:
A risk is something that can happen and a problem is something that we know will happen or that has already happened. Security testing is used to evaluate a programs security using various methods and risk-based security testing is used to analyze, calculate and correct potential defects or problems in a system.
Testing can be very costly and it is the most primary way of removing software defects. Many people focus their testing looking for correct behavior and not deviant behaviors in software, therefore security testing has not been as relevant in traditional testing. It is usually not possible to perform exhaustive testing on a system, instead you must selectively choose tests to conduct. How should the selection of tests be conducted? The study therefore intends to investigate how one can start working with risk-based security testing in development projects in order to prioritize and choose test cases and test methods. The study also aims to answer whether you can get any financial or practical benefits from working with risk-based security testing. To conduct the study a case study was used and to collect data, a document study was used to provide the opportunity to answer the questions. In order to analyze the collected data, a qualitative data analysis method has been used to explain and describe the content with a descriptive research approach. The results of the study provided an example of risk management with different steps one can take to start working on risk-based security testing in existing or new development projects. The study’s conclusion also shows that if you work with risk-based security testing there are practical benefits. For instance, higher quality of the system and economic benefits by finding defects or implementing countermeasures for possible risks at an early stage during the systems development.
Keywords:
Security testing, testing, risk-based security testing, risks, risk evaluation, risk management, system development
Sammanfattning:
En risk är någonting som kan hända och ett problem är någonting som vi vet kommer hända eller som redan har hänt. Säkerhetstest används för att med olika metoder värdera ett programs säkerhet och riskbaserad säkerhetstestning används för att analysera, kalkylera och åtgärda potentiella defekter eller problem i ett system.
Testning kan vara väldigt kostnadskrävande och det är det mest primära sättet som används för att ta bort defekter i mjukvaror. Många fokuserar sin testning på att leta efter ett korrekt beteende och inte avvikande beteenden i programvara, därför har säkerhetstestning inte varit så aktuellt i traditionell testning. Det är oftast inte möjligt att utföra uttömmande testning på ett system utan man måste selektivt välja tester, men hur ska selektionen gå till?
Studien ämnar därför att undersöka hur man kan börja arbeta med riskbaserad säkerhetstestning i utvecklingsprojekt för att kunna prioritera och välja testfall och testmetoder. Studien ämnar också svara på om man kan få några ekonomiska eller praktiska fördelar av att arbeta med riskbaserad säkerhetstestning.
För att genomföra studien gjordes en fallstudie och för att samla in data utfördes en dokumentstudie för att ge möjlighet att besvara frågeställningarna. För att analysera den insamlade data har en kvalitativ dataanalysmetod använts för att med en deskriptiv undersökningsansats kunna djupare förklara och beskriva innehållet.
Resultaten från studien har medfört ett riskhanterings exempel med olika steg man kan ta för att börja arbeta med riskbaserad säkerhetstestning i befintliga eller nya utvecklingsprojekt. Studiens slutsats visar också att om man arbetar med riskbaserad säkerhetstestning så finns det praktiska fördelar. Exempelvis högre kvalitet på systemet och ekonomiska fördelar genom att man i ett tidigt skede under systemets utveckling hittar defekter eller implementerar motåtgärder för eventuella risker.
Nyckelord:
Säkerhetstest, testning, riskbaserad säkerhetstestning, risker, riskvärdering, riskhantering, systemutveckling
Centrala begrepp
Begrepp som benämns i studien och dess förklaring.
Begrepp Definition
UML (unified modeling language) – ett språk för modellering av objektorienterade program. Det används för att beskriva hur programmen ska vara uppbyggda. (International Data Group, u.åc)
Mjukvara Även kallat programvara eller program. Mjukvara representerar ett program eller annat som exempelvis en instruktion som kan köras på en dator. Den vanligaste termen är att kalla något för ett program. (International Data Group, u.åb)
Risk En faktor som kan leda till framtida negativa konsekvenser och uttrycks normalt med sannolikhet och påverkan.
(Felderer & Schieferdecker, 2014)
IEEE The Institute of Electrical and Electronics Engineers – en amerikansk branschorganisation som fastställer standarder inom datateknik. (International Data Group, u.åd)
Test Stevenson (2010) definierar test som ett förfarande som är avsett att fastställa kvalitet, prestanda eller tillförlitlighet för något, särskilt innan det tas i användning.
Testdriven utveckling Att skriva program som testar koden som ska lämnas in till projektet måste testas först. Kod testas ofta och godkänns eller underkänns. Koden måste klara alla satta tester innan man får använda den. (International Data Group, u.å) Agil Systemutveckling ”arbetssätt för systemutveckling som betonar snabbhet,
informellt samarbete, täta kundkontakter och möjlighet att ändra under arbetets gång. Även kravspecifikationen bör kunna revideras. Det är en rörelse, inte en enhetlig metod.”
(International Data Group, u.å)
Innehållsförteckning
1. Inledning ... 1
1.1 Bakgrund ... 1
1.2 Problemformulering ... 2
1.3 Avgränsning ... 2
1.4 Frågeställning ... 3
1.5 Syfte ... 3
1.6 Samarbetspartner ... 4
1.7 Målgrupp ... 4
1.8 Kunskapsbidrag ... 4
2. Teori ... 5
2.1 Informationssäkerhet ... 5
2.2 Test ... 5
2.2.1 V-modellen ... 6
2.3 Säkerhetstest ... 7
2.3.1 Riskbaserad säkerhetstestning ... 7
2.3.2 Riskanalys ... 8
2.3.3 Riskvärdering ... 8
2.3.4 Riskåtgärd ... 8
2.4 Livscykelmodellen ... 9
2.4.1 Definiera & Design ... 10
2.4.2 Utveckla ... 10
2.4.3 Använda ... 10
2.4.4 Underhålla ... 10
2.5 Tidigare forskning ... 11
3. Metod ... 13
3.1 Forskningsprocessen ... 13
3.2 Fallstudie ... 14
3.3 Undersökningsansats ... 14
3.4 Litteraturstudier ... 15
3.4.1 Klassificering av litteratur ... 16
3.5 Datainsamling ... 16
3.5.1 Dokumentstudie ... 17
3.6 Dataanalys ... 18
3.6.1 Kvalitativ dataanalys ... 18
3.6.2 Utvärdering ... 19
3.7 Validitet & Reliabilitet ... 20
3.8 Metodkritik ... 20
4. Resultat och analys ... 22
4.1 Resultat och analys av dokument- och litteraturstudie ... 22
4.1.1 Säkerhetstest ... 22
4.1.2 Riskanalys ... 25
4.1.3 Riskbaserad säkerhetstestning ... 27
4.2 Ekonomiska aspekter ... 28
4.3 Praktiska fördelar ... 30
4.4 Framtaget riskhanteringsexempel ... 31
5. Slutsats och diskussion ... 32
5.1 Slutsats ... 32
5.1.1 Hur börjar man arbeta med riskbaserad säkerhetstestning i utvecklingsprojekt? ... 32
5.1.2 Finns det ekonomiska fördelar om man väljer att arbeta med riskbaserad säkerhetstestning? ... 34
5.1.3 Finns det några praktiska fördelar med att börja arbeta med riskbaserad säkerhetstestning? ... 34
5.2 Diskussion ... 35
5.2.1 Studiekritik ... 36
5.3 Förslag till vidare forskning ... 36
Litteraturförteckning ... 37
Figurförteckning
Figur 1 Begränsningar i studien, markerat med röda ringar i figuren. ... 3
Figur 2 V-modellen ... 6
Figur 3 Generisk livscykelmodell ... 9
Figur 4 Modell över den valda Forskningsprocessen ... 13
Figur 5 Övergripande illustration av säkerhetstestning ... 23
Figur 6 Flödesschema för riskanalys. ... 25
Figur 7 Översikt över säkerhetstestning ... 28
Figur 8 Kostnaden för att laga defekter per fas i systemutveckling ... 29
Figur 9 Riskhanteringsexempel baserat på dokumentstudie ... 31
Figur 10 Säkerhetstestning - steg för steg ... 32
Tabellförteckning
Tabell 1 Inledande sökord i litteraturstudie ... 15
Tabell 2 Klassificering av använd litteratur ... 16
Tabell 3 Exempeltabell på viktade faktorer ... 26
Tabell 4 Exempeluträkning från viktade faktorer ... 26
Förord
Jag vill rikta ett stort tack till min samarbetspartner Precio Fishbone AB och min handledare Carina Jones för visat intresse i min studie och det stora privilegiet att få arbeta med dem.
Dessutom vill jag tacka min handledare från Högskolan Dalarna, Hans Jones för väldigt bra feedback och bra vägledning under studiens gång.
Pontus Engblom
Borlänge den 20 september 2020
1
1. Inledning
I det här kapitlet presenteras bakgrunden till studien samt problemformuleringen och syftet. Kapitlet tar även upp studiens målgrupp, avgränsningar och studiens samarbetspartner.
1.1 Bakgrund
Projekt inom IT är sällan färdiga i tid eller håller sin budget. Detta beror oftast på att faser i ett projekts början är försenade, när det sen kommer till testning så är tiden till leverans oftast väldigt kort och det finns ofta ingen budget kvar (Amland, 2000).
Sedan mjukvaruindustrins start har testning varit det primära sättet för att få bort defekter. Att hitta och laga defekter i system har varit den dyraste uppgiften i programvaruutveckling i mer än 50 år (Jones & Bonsignour, 2012).
Säkerhetstest är ett begrepp för flera olika metoder att värdera ett systems säkerhet, de mer välkända metoderna inom det här samlingsbegreppet är penetrationstestning, kodanalysering och sårbarhetsscanning, externt och internt inom ett system (McGraw, 2006).
Området säkerhetstestning har i många år senarelagts och inte varit så aktuellt inom den traditionella mjukvarutestningen (Wysopal, 2006).
Många program fokuserar ofta sin testning på närvaron av korrekt beteende och inte avsaknaden av andra beteenden (Thompson, 2003).
En risk är något som kan hända medan ett problem är något vi känner till kommer hända (eller som redan hänt). Om en händelse är associerad med en risk finns det en potentiell förlust eller påverkan i samband med den händelsen (Amland, 2000).
Det ansågs därför vara möjligt att undersöka hur man ska kunna implementera testning som även tar till vara på andra beteenden än det korrekta beteendet som förväntas.
Det är sällan kostnadseffektivt och oftast inte möjligt att utföra uttömmande test inom en ändlig tid.
Att planera vilka test som ska utföras sker selektivt.
Men hur ska selektionen gå till? (Redmill, 2004).
”Software Security unifies the two sides of software security - attack and defense,
exploiting and designing, breaking and building - into a coherent whole. Like the yin and
the yang, software security requires a careful balance.” (McGraw, 2006, s. 11).
2
1.2 Problemformulering
Som Jones & Bonsignour (2012) beskriver tidigare så har testning varit den mest kostnadskrävande och det primära sättet för att få bort defekter i mjukvaror, de påpekar även att hitta och laga defekter och problem i system varit den dyraste uppgiften i mer än 50 år.
Dessutom beskriver Thompson (2003) att många fokuserar sin testning på att leta korrekt beteende och inte avsaknaden av avvikande beteenden i program.
Precio Fishbone arbetar redan idag med agil systemutveckling.
I detta arbetssätt används testdriven utveckling inom utvecklingsprojekt för att säkerställa att koden uppför sig korrekt och som förväntat.
Enligt Wysopal (2006) så har säkerhetstestning senarelagts och inte varit så aktuellt i traditionell testning, därför finns ett behov för Precio Fishbone och övriga intressenter att analysera och tolka området säkerhetstestning, då det i vissa fall enligt Precio Fishbone kan vara krav på att använda säkerhetstestning inom vissa utvecklingsprojekt.
Därför finns det ett behov av att få reda på mer om området och hur man kan börja använda sig av detta i sin utveckling och vilka fördelar man eventuellt kan få av att nyttja riskbaserad säkerhetstestning.
Eftersom det enligt Redmill (2004) sällan är kostnadseffektivt eller ens möjligt att genomföra alla tester man kan tänka sig måste man kunna utföra tester selektivt. För att eventuellt få en ekonomisk vinning kan det vara bra att förstå hur man bäst väljer testfall.
1.3 Avgränsning
Området säkerhetstest innehåller många olika delområden. Att bedriva en fallstudie inom hela säkerhetstestnings kedjan som McGraw (2006) beskriver i Figur 1 skulle inte vara möjlig att genomföra med den tidsperiod denna studie har.
Rapporten fokuserar på hur man gör riskbaserade säkerhetstester i en applikations utvecklingsfaser. Begränsningen i studien görs för att kunna genomföra ett kvalitativt arbete inom begränsningsområdet.
För att kunna genomföra riskbaserad säkerhetstestning behöver man först göra en riskanalys. I en riskanalys kan man fånga upp potentiella hot och sårbarheter för systemet och sedan med hjälp av riskanalysen kan man gå vidare med att utforma och implementera riskbaserade tester (McGraw, 2006).
Så för att kunna komma in på just delområdet riskbaserad säkerhetstestning har studien avgränsats till just riskanalys och riskbaserad säkerhetstestning.
Se Figur 1 för en illustration över områden denna studie avgränsar sig till.
3
Figur 1 Begränsningar i studien, markerat med röda ringar i figuren.
Figuren visar en mjukvaras utvecklingsfaser (Potter & McGraw, 2004).
1.4 Frågeställning
Tidigare beskriven problemformulering, vilket är ett ganska stort problemområde, leder efter studiens avgränsning till huvudfrågan:
Hur börjar man arbeta med riskbaserad säkerhetstestning i utvecklingsprojekt?
Det är också intressant att utreda ytterligare två delfrågor inom området, detta för att dessa frågor troligen kan ses som motivation till att börja arbeta med riskbaserad säkerhetstestning:
1) Finns det ekonomiska fördelar om man väljer att arbeta med riskbaserad säkerhetstestning?
2) Finns det några praktiska fördelar med att börja arbeta med riskbaserad säkerhetstestning?
1.5 Syfte
Syftet med den här studien är att undersöka och beskriva hur man kan använda riskbaserad säkerhetstestning i utvecklingsprojekt. Det finns två delfrågor som presumtivt kan fungera som incitament att börja arbeta med riskbaserad säkerhetstestning i utvecklingsprojekt.
Målet med forskningen är också att bidra till ökad förståelsen för säkerhetstestning med fokus på icke korrekt beteende och vikten av att analysera, utvärdera och hantera risker under hela utvecklingsfasen.
För att kunna beskriva tillvägagångssätten på ett tydligt sätt kommer det att illustreras och presenteras i grafiska figurer.
4
1.6 Samarbetspartner
Precio Fishbone är ett specialistbolag med fokus på Microsoftbaserade lösningar.
Inom företagets specialistkonsulter återfinns några av branschens bästa utredare, krav-/verksamhetsanalytiker och projektledare.
Företaget finns i Sverige, Danmark, Storbritannien, Kanada och Vietnam, företaget har ungefär 250 anställda specialister (Precio Fishbone, u.å).
1.7 Målgrupp
Resultat från studien blir ett underlag för Precio Fishbone och andra intressenter som vill öka sin förståelse för området säkerhetstestning. Det kan även vara intressant att se om det eventuellt finns några ekonomiska incitament för säkerhetstestning och kunna lyfta fram om det finns några praktiska fördelar med det.
För personer utan tidigare teknisk kännedom inom huvudområdet säkerhetstestning kan en del begrepp vara okända. Det kan därför vara svårt att förstå alla terminologier och begrepp i rapporten.
Därför presenteras studiens centrala begrepp före studiens innehållsförteckning, denna tabell ska fungera som ett stöd för läsaren.
1.8 Kunskapsbidrag
Den här studiens mål är att analysera riskbaserad säkerhetstestning inom huvudområdet för säkerhetstester och ge en beskrivning över hur man kan börja arbeta med riskbaserad säkerhetstestning.
Studien försöker också lyfta fram eventuella praktiska och ekonomiska fördelar man kan få av att arbeta med riskbaserad säkerhetstestning i utvecklingsprojekt.
5
2. Teori
Syftet med kapitlet är att beskriva den teoretiska referensramen för studien. Kapitlet tar upp begrepp och metoder som är bra att känna till för att ge en ökad förståelse för studien.
2.1 Informationssäkerhet
Eriksson (2016) beskriver att inom informationssäkerhet finns tre huvudbegrepp:
• Konfidentialitet – information görs ej tillgänglig för obehöriga.
• Integritet – information är korrekt och fullständigt.
• Tillgänglighet – informationen är åtkomlig och användbar för en behörig vid behov.
Dessa tre förkortas på engelska CIA, vilket på engelska står för confidentiality, integrity and availability (Eriksson, 2016).
Det är viktigt att veta hur mycket säkerhet ett visst projekt kommer att kräva, man måste veta vilka tillgångar som ska skyddas och dessa bör ges en klassificering hur känsligt de ska hanteras, ett exempel på sådan klassificering är konfidentiell, hemlig och topphemlig (OWASP, 2020).
McGraw (2006) anser att aspekter inom informationssäkerhet kan vara extremt värdefulla när man genomför säkerhetstestning. Man kan fråga sig om kända sårbarheter eller kända problem med informationssäkerhet har inträffat och kan inträffa för systemet. Alla dessa typer av frågeställningar kan öka ens medvetenhet vid en riskanalys och de val man väljer för riskåtgärd.
2.2 Test
Testning är en process som används för att identifiera och kontrollera funktioner i ett system. Syftet med testning är att identifiera resultaten som fås efter man matat in en given indata (Palanivel & Selvadurai, 2014).
En testprocess innehåller kärnaktiviteterna test planering, testdesign, testimplementation och testutförande, den innehåller även utvärdering av testen (Felderer & Ramler, 2016).
En testplan är det dokument som beskriver omfattningen av testningen, metoder, resurser och tidsplanering för de tänkta testerna. Vid testdesign skapar man testfall och därefter implementeras test och knyts samman med exempelvis testdata som behövs för att köra testet, testet körs sedan och utfallet noteras i en testlogg (Felderer
& Ramler, 2016).
6
2.2.1 V-modellen
Figur 2 V-modellen (Eriksson, 2008)
V-modellen är en internationellt erkänd modell som ofta används för att illustrera hur kravhantering hänger ihop med test och programmering i systemutveckling (Eriksson, 2008). I Figur 2 sammanfattas modellen uppdelad i tre delar, röd innefattar de krav som ställs på systemet, blå är kodning/utveckling och grön är testdelen.
2.2.1.1 Enhetstester (unit tester)
Enhetstester (även unit tester) kan verifiera dynamiskt (exempelvis när programmet körs) att komponenter fungerar som förväntat. Innan man inför ändringar i en applikation ska resultat analyseras och valideras (OWASP, 2020).
De hotscenarion som identifierats för ett system kan man använda unit tester för att dokumentera och testa komponenter mot bedömda hot fall och missbruksscenarion, exempelvis kan man testa inloggningsfunktionalitet och försöka missbruka inmatningen med negativa tal när det förväntas textsträngar (OWASP, 2020).
7 2.2.1.2 Integration test
När komponenterna i ett system är testade var för sig tar man och testar så att de fungerar tillsammans. Man implementerar komponenter succesivt till större och större bitar i det befintliga systemet (Eriksson, 2008).
2.2.1.3 Systemtest
När man har integrerat alla komponenter i ett system så anses systemet vara komplett, då återstår att testa systemet för att säkerställa att systemet är funktionellt och att systemet arbetar och fungerar som det var tänkt från de krav som systemet utvecklades för (Eriksson, 2008).
2.2.1.4 Acceptanstest
Det sista steget är att man genomför ett acceptanstest, där man låter andra än testare använda systemet och samlar in deras återkoppling. Det är viktigt att användarna accepterar systemet, annars kan det inte godkännas för driftsättning (Eriksson, 2008).
2.3 Säkerhetstest
Säkerhetstest är användandet av olika testtekniker specifikt för att undersöka säkerhet. Det finns två huvudmetoder av säkerhetstestning: testa säkerhetsfunktioner för att säkerställa att dessa fungerar och testa olika inneslutna system hur de beter sig under en skadlig attack (C.C., van Wyk, & Radosevich, 2005).
Med hjälp av säkerhetstest kan man identifiera om de angivna eller avsedda säkerhetsegenskaperna är korrekt implementerade, exempelvis genom att införa riskbaserad eller kravbaserad testning (Felderer, Büchler, Johns, Brucker, Breu &
Preschner, 2016).
De områden som inkluderas i området säkerhetstest illustreras i Figur 1 Begränsningar i studien, markerat med röda ringar i figuren. De områden man oftast genomför någon typ av aktivitet i är riskanalys, riskbaserade säkerhetstester, kodgranskning och penetrationstestning (McGraw, 2006). De områden som är intressanta för denna studie är riskanalys och riskbaserade säkerhetstester.
2.3.1 Riskbaserad säkerhetstestning
Riskbaserad säkerhetstestning är en välkänd strategi för att anpassa testaktiviteter till affärsvärde och risker. Det är ett sätt att förbättra resursfördelning, mildra risker, identifiera kritiska områden tidigt och ge beslutsstöd till ledningen (Felderer &
Ramler, 2014).
När man utför riskbaserad säkerhetstestning beaktar man de risker som finns för systemet som de vägledande faktorerna som beslutsstöd i alla faser under hela testprocessen (Felderer & Schieferdecker, 2014).
8 Vid riskbaserad säkerhetstestning använder man sig av två värden för att beräkna ett riskvärde, konsekvens och sannolikhet.
Konsekvensvärdet baseras på den påverkan en defekt har, kostnadsmässigt eller skadan på ett system i drift. (Felderer & Schieferdecker, 2014).
Sannolikheten är antagandet om hur stor chans det är att just den defekten inträffar.
Det resulterande riskvärdet tilldelas en riskpost som sedan kan användas som ett testfall eller ett krav (Felderer & Schieferdecker, 2014).
Baserat på värdena från riskevalueringen kan riskposter prioriteras och tilldelas risknivåer (Felderer & Ramler, 2016).
En kärnaktivitet i den riskbaserade testningsprocessen är riskbedömning då den avgör betydelsen av riskvärdena, detta används för den övergripande riskbaserade testprocessen (Foidl & Felderer, 2018).
2.3.2 Riskanalys
Meningen med en riskanalys är att ge ett informativt beslut om riskhantering. Därför bör riskanalys följas av beslut och lämpliga motåtgärder för att minska eller förhindra den identifierade risken (Redmill, 2005).
En riskanalys är den kvantitativa analysen av närvaron av risker i ett system.
Riskanalys görs för att hitta de sårbara faser som måste testas (Palanivel &
Selvadurai, 2014).
Genom att tänka över de potentiella hot och sårbarheter som är möjliga kan man ta fram strategiskt utvalda testfall som simulerar just sådana potentiella hot och sårbarheter. En organisation kan även använda sig av sårbarhetsdatabaser för att skapa säkerhetsdrivna testfall för att på så sätt validera systemet mot troliga attackscenarion (OWASP, 2020).
2.3.3 Riskvärdering
En riskvärdering är en form av uppskattningsteknik. Man kan använda sig av olika bedömningsbaserade uppskattningsprocessor som sträcker sig från rena magkänslor till strukturerade och historiska data över tidigare kända risker (Felderer &
Schieferdecker, 2014).
Varje riskvärdering sker med hjälp av någon typ av skala för att bestämma risknivån.
Man kan antingen använda sig av en kvantitativ eller kvalitativ skala. Kvantitativa riskvärde är numeriska och möjliggör därför beräkningar medan kvalitativa riskvärde bara kan sorteras och jämföras. Ett exempel på kvalitativa riskvärde är låg, mellan och hög och ett exempel på kvantitativa riskvärde är 1,2,3,4 och 5 (Felderer
& Schieferdecker, 2014).
2.3.4 Riskåtgärd
En riskåtgärd avgör vilka typer av motåtgärder man ska införa mot en risk och vilka tester man tänk använda. Med hjälp av en riskvärdering kan olika riskåtgärder sättas in beroende på vilken typ av risknivå en risk har (Felderer & Schieferdecker, 2014).
9 Idén med att använda sig av risknivån när man bestämmer åtgärder för en risk är så att man kan fokusera på det som man anser vara viktigt (Amland, 2000).
Att välja riskåtgärder från en prioriterad lista betyder att man kan få ner sina kostnader för testande och öka kvaliteten och feldetektionsgraden för sitt system.
Har man en förmodad låg risk kan man antagligen börja med väldigt lite testning för just den risken. Har man däremot en risk med högt riskvärde kan man lägga ner mer tid och göra grundliga tester. Detta är en metod man kallar ”As Low as Reasonably Practicable (ALARP)” vilket kan översättas till så lågt som praktiskt rimligt. I ALARP prioriteras risker med hög risknivå och då får man kvar risker som har lägre riskvärde, vilket är målet (Felderer & Schieferdecker, 2014).
2.4 Livscykelmodellen
Figur 3 Generisk livscykelmodell (OWASP, 2020)
Testning sker väldigt sent i mjukvaruutveckling och är väldigt närliggande i tid tills det att systemet ska tas i bruk. Detta har visat sig vara väldigt ineffektivt. En av de bästa metoderna för att förhindra säkerhetsdefekter i systemet är att förbättra livscykelmodellen för mjukvaruutveckling (Felderer et al., 2016).
10
2.4.1 Definiera & Design
De inledande faserna är väldigt sammansatta och när man påbörjar ett projekt så ska man i denna fas ta ställning till:
• Granska systemets krav
• Granska arkitektur och design
• Granska och skapa UML modeller
• Granska och skapa hotmodeller (OWASP, 2020)
2.4.2 Utveckla
När man har gått igenom Definiera och Design fasen och ska påbörja utveckling så ska man också börja planera och genomföra:
• Kodgranskning
• Kodgenomgång
• Unit och Systemtester (OWASP, 2020) 2.4.3 Använda
Denna fas kan även kallas driftsätta, här har man alltså ett färdigt system där man ska utföra:
• Penetrationstestning (vid behov)
• Granska generell konfiguration och hanteringskonfiguration
• Granska och genomföra Unit och Systemtester
• Genomföra acceptanstester (OWASP, 2020)
2.4.4 Underhålla
I underhållsfasen ingår dessa faser:
• Övervaka systemets driftstatus
• Granska och genomföra operativa ändringar
• Regressionstester (OWASP, 2020)
11
2.5 Tidigare forskning
Majoriteten av den tidigare forskningen som återfunnits har varit forskning på engelska. Det har endast hittats en tidigare forskningsrapport på svenska som vidrört området säkerhetstestning och riskbaserad säkerhetstestning. Den studien utfördes av Larsson (2009).
En hel del av forskningen inom området är daterat från tidigt 2000-tal till 2010 tal, då var säkerhet inom mjukvara väldigt aktuellt och därför finns det väldigt mycket studier från denna tidsperiod.
Larsson (2009) har i sin studie förklarat begreppen säkerhetstestning och riskbaserad säkerhetstestning men har inte konkret fokuserat sin rapport på dessa områden. I studien finns dock bra jämförelser om traditionell testning kontra säkerhetstestning.
Därför anses att Larsson (2009) studie enbart kan användas till att referera begreppsförklaringar och teoretiska förklaringar. Mycket ur den studien har sitt ursprung hos C.C., van Wyk, & Radosevich (2005).
Den studie som C.C., van Wyk, & Radosevich (2005) genomfört hämtades från Cybersecurity and Infrastructure Security Agency (CISA) som drivs av Department of Homeland Security i USA.
Även om C.C., van Wyk, & Radosevich (2005) studie har ett antal år på nacken så har innehållet de beskriver inte förändrats. Detta framgår om man jämför innehållet med nyare litteratur.
Man bör kunna påstå att C.C., van Wyk, & Radosevich (2005) är en väldigt betrodd källa eftersom myndigheter har rekommenderat deras rapport i många år.
McGraw (2006) refereras det mycket till i många olika studier, så även i denna studie. McGraw anses vara en ledande expert inom området (Department of Homeland Security, u.å) och han har tillsammans med andra författare publicerat många artiklar och tidskrifter hos IEEE (The Institute of Electrical and Electronics Engineers).
Två väldigt intressanta artiklar McGraw publicerat med andra är:
• Potter & McGraw, 2004 – Risk Analysis in Software Design
• Verdon & McGraw, 2004 – Software Security Testing
De två ovannämnda artiklarna är publicerade hos IEEE och de återfinns till stora delar i McGraws bok, Software Security: Building Security In.
Efter att ha fått fram så mycket information om McGraw så anses han vara en ledande expert inom området både från det akademiska hållet men även från säkerhetsmyndigheter och branschkunniga. Därför finns det i studien ingen anledning att misstro hans publikationers validitet och reliabilitet.
12 En del nyare artiklar och studier är bland annat Palanivel & Selvadurai (2014) som går igenom riskbaserad säkerhetstestning och jämför ett antal olika hotmodeller.
De har även inkluderat en hel del tidigare forskning om säkerhetstestning i sin rapport där mycket är från tidigt 2000 tal, precis som i denna studie.
För den teoretiska utgångspunkten i denna studie har tidigare forskning använts som ett stöd och analysverktyg. Studier, tidskrifter och artiklar har jämförts och använts för att tillsammans med övrigt funnet material ge studien trovärdighet.
Det finns en stark koppling i litteratur både akademisk och övrig icke-akademisk som anträffats via normala sökmotorer som alla hänvisar till OWASP. Eftersom OWASP anses vara en trovärdig källa i de akademiskt granskade källorna så har alltså även OWASP litteratur tagits med i denna studie.
13
3. Metod
I detta kapitel ges en inblick i de tillvägagångssätt som tillämpas i studien. Därtill presenteras en illustration kring den valda forskningsprocessen och forskningsstrategin för studien, hur litteraturstudien och datainsamling genomförts och analyserats. Avslutningsvis för kapitlet ges en kort metodkritik.
3.1 Forskningsprocessen
Oates (2006) beskriver de komponenter som en forskningsprocess kan ha, för att representera de valda komponenter studien använt sig av illustreras dessa med grön färg i Figur 4.
Figur 4 Modell över den valda Forskningsprocessen (Oates, 2006)
Den här studiens forskning har genomförts enligt Figur 4. Studien har initierats genom egna upplevelser och egen motivation till valt forskningsområde. Studien har styrts till stor del av den litteraturstudie som genomförts.
För studien ansågs fallstudie vara den mest passande forskningsstrategin att använda, detta för att få en djupare förståelse för området säkerhetstestning.
Undersökningen fokuserar enbart på området riskbaserad säkerhetstestning och riskanalys som endast är en del i hela kedjan säkerhetstestning, se Figur 1 i kapitel 1.3 avgränsning för en illustration av hela säkerhetstestning kedjan.
Eftersom det fanns någorlunda med litteratur inom området riskbaserad säkerhetstestning eller mer specifikt, säkerhetstestning inom mjukvaruutveckling, valdes dokumentstudie som datagenererings metod.
14 För att analysera den data som genererats tillämpades den kvalitativa dataanalyseringsmetoden, för att kunna framföra ett kunskapsbidrag.
3.2 Fallstudie
Eftersom det fanns ett uttalat behov av att gå djupare med just säkerhetstestning och det området är väldigt stort och brett, valdes fallstudie för att titta närmare på just riskbaserad säkerhetstestning som är en del av hela området säkerhetstestning.
Valet av fallstudie är tack vare Oates (2006) och hans beskrivning av fallstudie som är att fokus läggs på en instans av det som ska undersökas:
• ett informationssystem
• en organisation
• ett beslut
Målet med fallstudien är att tillgodogöra sig en detaljerad och rik insikt av det som undersöks liv och dess komplexa relationer och processer.
3.3 Undersökningsansats
En studies undersökningsansats kan delas in i tre olika ansatser, explorativ, deskriptiv och förklarande (Oates, 2006).
Dessa tre ansatser och ytterligare en ansats, normativa studier, beskrivs av Björklund
& Paulsson (2012) som förklarar hur ansatserna skiljer sig och kan delas in baserat på tidigare befintlig kunskap och den kunskap som studien bidrar till.
Explorativa, undersökande, studier används då det finns lite kunskap inom området och man försöker uppnå en grundläggande förståelse.
Deskriptiva, beskrivande, studier används när det finns grundläggande kunskap inom och förståelse för området, varvid målet är att beskriva, men inte förklara relationer.
Explanativa, förklarande, studier kan användas då man söker djupare kunskap och förståelse och då man både vill beskriva och förklara.
Normativa studier, slutligen, används när det redan finns viss kunskap inom och förståelse för forskningsområdet, och då målet är att ge vägledning och föreslå åtgärder (Björklund & Paulsson, 2012, s. 60).
Studiens ansats kan till viss del anses vara deskriptiv. Då det finns tidigare kunskap inom området riskbaserad säkerhetstestning och studien försöker förklara och beskriva riskbaserad säkerhetstestning och eventuella ekonomiska och praktiska fördelar.
Vissa delar i studien kan dock anses vara explanativ då exempelvis riskhantering är ett begrepp och definition som används hos företag i andra branscher och andra syften än just säkerhetstestning. Så här finns det större tillgång till kunskap från utomstående branscher att tillgå.
15
3.4 Litteraturstudier
Litteratur har sökts kring säkerhetstestning och riskanalys. Där fanns det en tydlig trend att riskbaserad säkerhetstestning har mindre litteratur och tenderar att vara ett mindre fokuserat område om man jämför med övriga delområden inom säkerhetstestning. Många har bedrivit forskning om riskanalys och riskhantering men det är inte alltid fokuserat på vare sig säkerhetstestning eller systemutveckling.
Efter att studerat innehållet och valt delområdet så begränsades sökningar ner till just riskbaserad säkerhetstestning, se Tabell 1 för förstudiens sökord och utfall.
Inledande sökord (förstudie) Utfall (val av delområde) Säkerhetstestning Riskbaserad (säkerhets)testning
Security testing Risk based testing / Risk driven testing Software security testing Software risk assessment / management
Tabell 1 Inledande sökord i litteraturstudie
För att inhämta information användes Högskolan Dalarnas databas Summon och Googles Scholar sökfunktion.
Vid sökning i Högskolan Dalarnas databas Summon filtrerades det på endast peer- reviewed källor. Detta för att endast få fram publikationer som genomgått en kritisk granskning av oberoende forskare inom ämnesområdet för publikationen (Oates, 2006).
Från det material som anträffades i litteraturstudien har även en del egen sökning med tidigare angivna sökmotorer gjorts för att inhämta information om källreferenser i funnen litteratur.
En del information har inhämtats genom att söka på Googles ordinarie sökmotor.
Den har mestadels använts för att få begreppsförklaringar eller för att inhämta omnämnda metoder, teorier eller övriga omnämningar i akademiska rapporter som saknat källreferenser. Googles ordinarie sökmotor har också använts för vidare efterforskning om det saknades resultat i Google Scholar och Summon eller om det saknats förklaringar i publikationen som exempelvis begreppsförklaringar.
Genom att studera titlar och de minisammanfattningar som sökmotorerna ger vid en sökning har vissa träffar verkat intressanta att studera. De träffar som verkat relevanta har därför öppnats från söklistan och därefter har studiens sammanfattning lästs igenom och även en snabb koll igenom brödtexten har genomförts.
Om titeln efter att ha granskats på en mer abstrakt nivå varit relevant för studien har den sparats ner och blivit läst först i abstrakt men även i fulltext om innehållet visat sig vara kunskapsgivande för denna studie.
Eftersom en del litteratur härstammar från Googles vanliga sökmotor kan det vara svårt att avgöra validiteten och reliabiliteten för sådana källor. De källor som använts och hittats för den här studien genom Googles vanliga sökmotor och som behandlar området säkerhetstestning är OWASP.
16 OWASP har använts till en hel del teoretiskt ramverk, detta för att OWASP är en välkänd och väletablerad organisation som får sina utgivna guider granskade av en rad människor, det är alltså inte akademiskt granskad litteratur men till stor del allmänt granskad litteratur av branschkunniga.
3.4.1 Klassificering av litteratur
För att besvara de forskningsfrågor som är aktuella för studien har en hel del litteratur granskats och klassificerats för att kunna användas till att besvara en frågeställning.
Område/Koncept Definition Litteraturreferens Säkerhetstest Säkerhetstest är användandet
av olika testtekniker specifikt för att undersöka säkerhet.
(Thompson, 2003)
(Potter & McGraw, 2004) (Oates, 2006)
(Wysopal, 2006) (Larsson, 2009) (Felderer et al., 2016)
(Winkler & Treu Gomes, 2016) (OWASP, 2020)
Riskhantering Metod(er) för att analysera och värdera risker för att sedan välja lämpliga åtgärder för funna hot.
(Amland, 2000)
(Verdon & McGraw, 2004) (Redmill, 2005)
(Oates, 2006)
(Palanivel & Selvadurai, 2014) (Felderer & Schieferdecker, 2014) (Felderer & Ramler, 2014)
(Felderer & Ramler, 2016) (Winkler & Treu Gomes, 2016) (Foidl & Felderer, 2018)
(OWASP, 2020) Ekonomiska och
praktiska fördelar Påvisande av faktiskt vinning vid utnyttjande av ovanstående metoder och områden vid utveckling av mjukvara.
(Verdon & McGraw, 2004) (Wysopal, 2006)
(McGraw, 2006)
(Jones & Bonsignour, 2012) (Winkler & Treu Gomes, 2016) (Foidl & Felderer, 2018)
(OWASP, 2020)
Tabell 2 Klassificering av använd litteratur
Tabell 2 försöker på ett överskådligt sätt påvisa den använda litteraturen till varje forskningsfråga. Detta presenteras här för att öka studiens validitet och reliabilitet.
En hel del litteratur är äldre och inte peer-reviewed. Det är förklarat varför den litteraturen ändå inkluderats i kapitel 2.5 Tidigare forskning och kapitel 3.4 Litteraturstudier. Majoriteten av litteraturen är dock akademiskt granskad.
3.5 Datainsamling
Oates (2006) berättar att varje studie innefattar en eller flera datainsamlingsmetoder och just i denna studie så har litteraturstudien och dokumentstudien varit den metod som använts för att samla in data.
17 I tidigare kapitel 3.4 Litteraturstudier har litteraturstudien redovisats och i följande kapitel 3.5.1 Dokumentstudieges en genomgång över den dokumentstudie som genomförts.
En del kurslitteratur har använts i den här studien, detta är följande böcker:
• Kravhantering för IT-system av Ulf Eriksson (Andra upplagan, 2008) – ISBN: 9789144054100
• Researching and Information Systems and Computing av Briony J Oates (Första upplagan, 2006) – ISBN: 9781412902243
• Seminarieboken av Maria Björklund & Ulf Paulsson (Andra upplagan, 2012) – ISBN: 9789144059853
• Forskningsmetodikens grunder - Att planera, genomföra och rapportera en undersökning av Runa Patel & Bo Davidson (Femte upplagan, 2019) – ISBN: 9789144126050
Denna kurslitteratur har använts då den rekommenderats av universitetet eller varit väldigt informativa och väl passande till denna studie.
3.5.1 Dokumentstudie
När man utför en dokumentstudie som datainsamlingsmetod genererar man sekundärdata till sin studie. Dokument som det refereras till inkluderar många olika studieobjekt som exempelvis litteratur, bilder, video, internetdokument och officiella eller privata handlingar (till exempel: dagböcker, mötesprotokoll, beslut, anteckningar med mer). (Oates, 2006).
Det är viktigt att vara objektiv när man bedriver dokumentstudie, forskaren måste vara öppen för att välja alla dokument inte enbart de som stödjer forskarens åsikt (Patel & Davidson, 2019).
I den här studien har dokumentstudier använts för att på kort tid få så stor förståelse som möjligt för riskbaserad säkerhetstestning och alla de moment som ingår i det området.
De dokument som studerats är i största del andra akademiska arbeten eller artiklar, böcker och hemsidor. Huvuddelen av alla dokument som sökts igenom litteraturstudien är helt eller delvis från den akademiska världen, hur dokumenten funnits och vilken litteraturen är finns förklarat i kapitel 3.4 Litteraturstudier.
3.5.1.1 Sekundärdata
Enligt Björklund & Paulsson (2012), anses all litteratur och data som inte har sin grund i den aktuella rapporten vara sekundärdata. Denna sekundärdata kan vara i form av böcker, tidskrifter, vetenskapliga artiklar och konferensbidrag.
Det är också av stor betydelse att veta om de sökrutiner som rapportens litteratursökning är baserad på, vilka sökmotorer och databaser som använts och de sökord som angetts som underlag (Björklund & Paulsson, 2012).
18 De sökmotorer som använts för att inhämta litteratur och de använda sökbegrepp återfinns i kapitel 3.4 Litteraturstudier.
3.6 Dataanalys
Data från datainsamlingen måste analyseras. Enligt Oates (2006) finns det två olika metoder att analysera data, kvalitativ och kvantitativ - valet av metod ska baseras på den typ av data som man har samlat in.
Oates (2006) beskriver vidare att kvalitativ dataanalys utförs på kvalitativa data som samlats in. Denna data beskrivs som att exempelvis innefatta all icke-numeriska data, som exempelvis ord, bilder, ljud, dokument och hemsidor.
Dessutom beskriver Oates (2006) att man bör förbereda sin data till en form som är redo att analysera, detta är att exempelvis få materialet i samma storlek av pappersformat för att enklare kunna få en överblick av materialet och hitta teman, mönster eller samband.
Därefter anser Oates (2006) att den data man samlat in kan delas upp i tre kategorier:
• Data som ej är relevant för studiens syfte.
• Data som kan ge en generellt beskrivande information som kan behövas för att i studien kunna beskriva forskningssammanhanget.
• Data som kan besvara studiens forskningsfrågor.
Efter att kategoriseringen genomförts kan den data som är relevant för att beskriva forskningens sammanhang eller kunna besvara forskningens frågor studeras noggrannare och tilldelas en kategoriseringstyp.
Den kategoriseringstyp som används på den relevanta data för studien kan delas upp i två typer:
• Induktivt, vilket betyder att utgå från den observerade data.
• Deduktivt, vilket betyder att utgå från de befintliga teorier som återfinns i litteraturstudien.
När kategorisering och kategoriseringstyp är valt får man återigen gå igenom den data man har för att tillämpa de valda indelningssätten och försöka leta mönster och försöka förklara dessa (Oates, 2006).
Den här studien har ansetts vara bäst lämpad att utnyttja kvalitativ dataanalys då studien är en dokumentstudie och Oates (2006) anser att kvalitativ dataanalys är ett passande val för dokument.
I nästa kapitel här nedan förklaras hur den kvalitativa dataanalysen skett för denna studie.
3.6.1 Kvalitativ dataanalys
I denna studie har litteraturstudien och dokumentstudien gjorts med en kvalitativ dataanalysmetodologi. Det har i ett tidigt skede studerats hela huvudområdet
19 säkerhetstestning för att senare begränsa ner studien till att enbart innefatta just grunderna för riskbaserad säkerhetstestning.
Efter att studien fått en tydlig begränsning har en mer fokuserad dokumentstudie genomförts där genererat material har kategoriserats och fått en kategoriseringstyp bestämt för att på så sätt enklare kunna sålla vad som är relevant för studien och inte.
Den data som framkommit i denna studie har blivit kvalitativt analyserat, där dokument som framkommit sorterats på det som är relevant för forskningen och det material som förklarar huvudområdet säkerhetstestning.
Den data som enbart behandlat huvudområdet och knappt nämnt riskbaserad säkerhetstestning eller riskanalys/riskhantering överhuvudtaget har sållats ut från studiens dokument.
De dokument som varit av relevans för studien har genomlästs och sedermera sorterats i relevans och sammanställts i textform. Sedermera har dokumenten använts friskt som referenser i både studiens teori men mestadels i studiens analys.
3.6.2 Utvärdering
Oates (2006) beskriver hur man kan utvärdera dokument, för att de ska kunna ses som en trovärdig källa, enligt att kontrollera följande punkter:
• Hade skaparen av dokumentet någon anledning att försöka vilseleda eller vinkla det?
• Framställdes dokumentet en kort tid efter att någon händelse bevittnats eller tog det tid att skapa ett sammanställt dokument från vittnesuppgifter vid händelsen?
• Varför togs dokumentet fram? Var det för en organisations fördel?
Att i denna studie ha ett stort förbehåll för alla dokument som framkommit har varit viktig, speciellt när man söker utanför akademiska databaser. Då är det viktigt att försöka utvärdera den data som hittas enligt ovanstående punkter. För den akademiska litteraturen förklaras synsättet på de dokument som framkommit mer detaljerat i kapitel 3.7 Validitet & Reliabilitet
20
3.7 Validitet & Reliabilitet
Enligt Patel & Davidson (2019) så anses det att bra validitet och reliabilitet är viktigt i en forskningsstudie. För att få en hög validitet bör de data som mäts vara relaterade till syftet för det egna arbetet.
För att få en hög reliabilitet bör man granska och utvärdera källan, se kapitel 3.6.2 Utvärdering. Detta görs för att kritiskt granska källan och dess författare, för att på ett tillförlitligt sätt se om källan som hänvisas går att lita på (Oates, 2006).
Björklund & Paulsson, 2012 beskriver att validitet & reliabilitet behövs för att kunna genomföra forskningen på ett likadant sätt vid ett senare tillfälle och då få samma eller ett liknande resultat som presenterats.
Majoriteten av den insamlade data som återfinns i denna studie är sökta via akademiska databaser, se kapitel 3.4 Litteraturstudier, dessutom har en hög nivå av kriticism använts för tidigare forskning, se kapitel 2.5 Tidigare forskning.
Övriga insamlade icke-akademiska data har samlats in från statliga myndigheter och hemsidor där man kan, enligt kapitel 3.6.2 Utvärdering fastslå att man på ett betryggande sätt kan lita på källan.
3.8 Metodkritik
Litteraturstudiens styrka är att man kan ta del av väldigt mycket information, på kort tid med knappa ekonomiska resurser. Det är väldigt bra för att få en överblick över området och för att kunna skapa en teoretisk referensram (Oates, 2006).
Litteraturstudiens nackdel är att den data man samlar in är så kallad sekundärdata, det vill säga att insamlad data inte har sin grund i den aktuella rapporten. Därför kanske det inte alltid framgår exakt med vilka metoder den sekundärdata har samlats in med och för vilket syfte (Björklund & Paulsson, 2012).
I en studie måste man ifrågasätta den data man samlat in och tänka på hur man använder denna data i studien (Björklund & Paulsson, 2012). Denna studie har så långt som möjligt försökt kritiskt granska alla källor som återfunnits, från tidigare forskning till övriga data som funnits på nätet.
Anledningen med att kritiskt granska data är att kunskapen som framtagits i de ovannämnda underlagen oftast är ämnade åt andra syften än vad den aktuella studien har. Därför bör man ha det i åtanke och vara medveten om detta, då det kan finnas brister i underlaget då det ursprungliga syftet inte är detsamma som rapportens egna (Björklund & Paulsson, 2012).
Som förklarat i kapitel 3.5.1.1 Sekundärdata så genererar dokumentstudier enbart sekundärdata, så för att för att få en så överskådlig bild som möjligt på hur litteraturen åtkommits måste man tydligt beskriva vad som sökts på och vilka databaser som använts (Björklund & Paulsson, 2012). I studien har de sökbegrepp och den litteratur som använts klart och tydligt presenterats i kapitel 3.4 Litteraturstudier.
21 I kapitel 3.5.1 Dokumentstudie tas det även upp att när man genomför en dokumentstudie måste man vara öppen för alla dokument, inte bara välja dokument som stödjer forskarens åsikter, det är med andra ord ett måste för forskaren att vara objektiv för all typ av dokument som framtagits (Patel & Davidson, 2019).
De dokument och litteratur som insamlats för denna studie har enbart sållats om de ej behandlat de avgränsningar studien har enligt kapitel Avgränsning. Annars har dokument behandlats i enighet med kapitel 3.6 Dataanalys.
Eftersom hela studien är baserat på sekundärdata så har stor vikt lagts vid validitet
& reliabilitet, kapitel 3.7 Validitet & Reliabilitet och att noggrant utvärdera dokumenten som framkommit, se kapitel 3.6.2 Utvärdering.
22
4. Resultat och analys
Detta kapitel redogör för de resultat som framkommit inom studien. Först presenteras resultat från den dokument- och litteraturstudie som gjorts följt av ett exempel på riskhantering med hjälp av en mall som ska redovisa syftet med undersökning.
4.1 Resultat och analys av dokument- och litteraturstudie
Här nedan kommer dokument som är relevanta för studien redovisas. Tanken är att övergripande förklara och analysera de olika momenten i riskbaserad säkerhetstestning. För att försöka öka förståelsen så kommer en hel del figurer presenteras som förklaringsmoment i detta kapitel.
McGraw (2006) beskriver i sin bok att om man ska kunna påbörja säkerhetstestning måste man först använda sig av någon typ av riskhanteringsmetod. Detta för att man ska kunna använda de olika säkerhetstestmetoderna på rätt teknisk risk som återfinns.
För att man ska kunna göra en fundamental riskvärdering skriver McGraw (2006) att det krävs att man:
• Förstår sig på verksamhetssammanhanget
• Identifierar de affärsmässiga och tekniska riskerna
• Värderar och prioriterar riskerna genom någon form av rankning (hög/mellan/låg eller åtgärda/acceptera)
• Antecknar vald riskreduceringsstrategi
• Utför vald riskreduceringsstrategi och bekräftar att det har implementerats
4.1.1 Säkerhetstest
Felderer et al. (2016) beskriver säkerhetstest som att man verifierar och validerar programvara, systemkrav, säkerhetsegenskaper som konfidentialitet, integritet och tillgänglighet.
Winkler & Treu Gomes (2016) menar att säkerhet handlar om riskhantering, definitionen av säkerhet är att vara helt fri från risker – dock kan du aldrig bli helt fri från risker. Att gräva ner en dator under jord gör den inte säker, det gör den otillgänglig, är den otillgänglig har den förlorat allt sitt värde.
McGraw (2006) menar att den mest effektiva ordningen att genomföra säkerhetstest är enligt illustrationen i Figur 5, detta baserar han på åratal av erfarenhet och inte på någon uppmätt metod, därav är det endast baserat på hans erfarenhet.
23
Figur 5 Övergripande illustration av säkerhetstestning (McGraw, 2006)
Vidare poängterar McGraw (2006) samtidigt att denna ordning inte är optimal för alla organisationer, han påpekar i samma mening att detta är hans personligt vinklade teori som framkommit under många års användande.
McGraw (2006) fortsätter också förklara varför han anser att man bör börja med kodgranskning och efter det ge sig på den arkitektoniska riskanalysen.
Kodgranskning används för att hitta buggar och den arkitektoniska riskanalysen används för att hitta brister.
Utesluter man kodanalysen eller kodgranskningen är det stor sannolikhet att man enbart löser halva problemet. Då det oftast är uppdelat 50/50 på buggar/brister och vidare kan man utan problem byta ordning på dessa två, riskanalys först eller kodgranskning först fungerar utan märkbar förlust (McGraw, 2006).
Alla systemartefakter har en sak gemensamt – källkod, därför anser McGraw (2006) att man ska införa någon typ av kodgranskning med hjälp av verktyg för ändamålet.
Det kan låta konstigt att man ska införa detta redan innan man ens påbörjat ett projekt och är i designfasen, men McGraw (2006) menar att ett projekt gör stora
24 vinster igenom att implementera ett sådant system redan innan man börjar skapa systemet. Då har man kontrollen på plats redan vid starten. Han menar även att igenom att införa kodgranskning betyder det att man lokaliserar och åtgärdar defekter i ett tidigt skede.
Att fånga misstag eller defekter i källkod är kritiskt för projekt och utvecklare gör ofta fel. Ett saknat semikolon, felaktigt användande av en inbyggd funktion i kodspråket eller en evighetsloop som aldrig bryts, dessa är endast några av relativt vanliga defekter som kan ligga dolda i system (McGraw, 2006).
McGraw (2006) skriver i sin litteratur att hans synsätt på genomförandet baseras på ett redan existerande system. Detta för att det är svårare att implementera i ett redan existerande system eller projekt än att modifiera ett systems utvecklingsmodell. Han poängterar också att hans fokus på redan existerande system eller utvecklingsprojekt gynnar projekt där man har köpt in utomstående system som ska integreras med ens egen utveckling.
OWASP (2020) påpekar en viktig sak man bör ha med sig, det finns ingen universallösning för säkerhet, man kan inte lösa säkerhetsrisker med enbart kodgranskning eller penetrationstestning.
OWASP (2020) skriver också att man för säkerhetstestning ska tänka strategiskt, inte taktiskt. Metoden att invänta ett problem för att sedan lappa och laga problemet leder inte till någon typ av säkerhetsvinst, snarare förlorar man katt- och råtta leken då attackerare oftast ligger ett steg före.
En väldigt bra analogi som OWASP (2020) citerar Denis Verdon, Informationssäkerhets chef på Fidelity National Financial, från OWASP AppSec 2004-konferensen i New York är:
” If cars were built like applications … safety tests would assume frontal impact only. Cars would not be roll tested, or tested for stability in emergency maneuvers, brake effectiveness, side impact, and resistance to theft.” – Denis Verdon, 2004, citerat av (OWASP, 2020).
Detta är en utmärkt analogi som tyvärr ofta är sanningen för system, som Thompson (2003) beskriver i sin litteratur är ofta tester för system enbart fokuserade på att testa funktioner för deras korrekta beteende. Det är just därför McGraw (2006) påpekar att man ska genomföra säkerhetstester med stort fokus på just riskanalys och förståelse för potentiella risker systemet kan ha.
25
4.1.2 Riskanalys
Redmill (2005) menar att en riskanalys betonar båda de komponenter som omfattas av en risk, sannolikhet och konsekvens. I systemutveckling kan konsekvenser oftast estimeras på mer eller mindre precisa mått men sannolikheten är oftast svårbedömd till dess att systemet är färdigproducerat.
I en riskanalys använder man sig av mätbara faktorer som sannolikhet, konsekvens och riskgräns. Sannolikhet motsvarar möjligheten att en risk uppstår, konsekvens är den påverkan och skadan som risken medför och riskgränsen är det maximala gränsvärde en risk kan tolereras (Palanivel & Selvadurai, 2014).
Testfall väljs utifrån riskanalysens resultat så att funktioner eller programbeteenden med högt riskvärde prioriteras och testas. Att genomföra en riskanalys optimerar valet av testfall att använda och köra (Palanivel & Selvadurai, 2014).
Figur 6 Flödesschema för riskanalys.
(Palanivel & Selvadurai, 2014)
Flödet för en riskanalys är enligt Figur 6 att man påbörjar en riskanalys för varje potentiellt hot som kan finnas i ett systems olika tillstånd.
Därefter gör man en riskidentifiering, i Figur 6 innefattar en riskidentifiering punkterna 2 till 5, man måste alltså göra dessa tre punkter för varje risk man identifierar. För att göra en riskkalkyl behöver man något att basera den på, senare i kapitlet kommer en typ av riskkalkylering gås igenom.
4.1.2.1 Riskkalkylering
Palanivel & Selvadurai (2014) menar att en riskkalkylering bör baseras på:
𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅ä𝑟𝑟𝑟𝑟𝑟𝑟 = 𝑅𝑅𝑠𝑠𝑠𝑠𝑠𝑠𝑠𝑠𝑠𝑠𝑅𝑅𝑅𝑅ℎ𝑟𝑟𝑒𝑒 ∗ 𝑅𝑅𝑠𝑠𝑠𝑠𝑅𝑅𝑟𝑟𝑅𝑅𝑅𝑅𝑟𝑟𝑠𝑠𝑅𝑅
26 Amland (2000) förklarar att man vid riskkalkylering ska använda sig av kvantitativa data. Det är möjligt att ange olika värden för sannolikhet eller konsekvens men förslagsvis kan man använda sig av en skala från 1 till 5.
Felderer & Ramler (2014) menar att oftast är riskvärdet enbart en multiplicering av sannolikhetsvärdet och konsekvensvärdet, antingen kan det räknas ut manuellt eller beräknas automatiskt.
Amland (2000) föreslår att man kan utöka sin kalkylering och lägga till övriga faktorer som man vill att ens riskvärdering ska ta hänsyn till. Dessutom ges ett exempel på en annan metod för riskkalkylering.
Ny funktionalitet 5
Design kvalitet 5
Storlek 1
Komplexitet 3
Tabell 3 Exempeltabell på viktade faktorer
De värden man anger i Tabell 3 multipliceras sedan med rader från Tabell 4 kolumnvis.
Funktionsnamn Ny
funktionalitet Design
kvalitet Storlek Komplexitet
Avsluta konto 2 2 2 3
Tabell 4 Exempeluträkning från viktade faktorer
Amland (2000) menar att om man utgår från ovanstående tabeller, så är riskvärdet enligt följande formel: 𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅ä𝑟𝑟𝑟𝑟𝑟𝑟 = 2 ∗ 5 + 2 ∗ 5 + 2 ∗ 1 + 3 ∗ 3 = 31.
Både Amland (2000) och Palanivel & Selvadurai (2014) menar att man bör ha olika riskvärdesskalor, där man delar in värdet i tre kategorier: låg, mellan och hög.
McGraw (2006) skriver i sin bok att företag och organisationer ska välja den riskkalkylmetod som bäst passar deras behov.
4.1.2.2 Riskvärdering
Palanivel & Selvadurai (2014) förklarar att efter man har gjort färdigt steg 2 till 5 i Figur 6 för varje risk man kan identifiera, gör en riskbedömning. De förklarar i sin litteratur att man vid riskbedömningen avgör ifall en risk överstiger ett riskgränsvärde.
Ett riskgränsvärde är det intervall av riskvärde där man anser en risk vara acceptabel.
Värdet för riskgränsen varierar för olika system, men förslagsvis kan man ha tre olika skalor för riskvärde: låg, mellan och hög. (Palanivel & Selvadurai, 2014).
Enligt Figur 6 tar man sedan de risker som överstiger ens riskgränsvärde och väljer lämpliga testfall för varje risk. Detta kallas att man gör en riskåtgärd, vilket förklaras i nästa kapitel. Efter att man har valt sin riskåtgärd utför man de utvalda åtgärderna.
27 4.1.2.3 Riskåtgärd
Bannerman (2008) förklarar i sin studie att det finns olika sätt att åtgärda en risk.
När man gör en åtgärd är det oftast för att minska sannolikheten eller konsekvensen.
Dessutom listar han ett antal olika strategier:
• Undvikande – En strategi för att försöka förhindra att något inträffar eller påverkar projektet. Detta innefattar ändrande av krav eller designstruktur så en risk inte kan inträffa.
• Överföra – Här flyttar man över ansvaret för en risk till en tredje part.
• Begränsa – Här försöker man övergripande införa förstärkande åtgärder utformade för att minska sannolikheten eller konsekvensen att något inträffar. Detta kan innefatta att man tar in oberoende testare eller försöker minimera skadan en risk kan göra.
• Acceptera – Riskacceptans innehåller en rad passiva svarsstrategier, antingen kan man passivt acceptera att det finns en risk men man väljer att inte införa någon motåtgärd, eventuellt kanske man inför någon form av extra övervakning. I andra fall kanske risken finns men kan inte åtgärdas förrän den realiseras, i sådant fall kan beredskap vara en typ av strategi.
4.1.3 Riskbaserad säkerhetstestning
Det här kapitlet är en utökning från den teori som beskrivits i kapitel 2.3.1 Riskbaserad säkerhetstestning, för att i studien mer kvalitativt kunna förklara och beskriva valda områden. För att få en grafisk representation över området säkerhetstestning har Figur 7 illustrerats och presenteras i detta kapitel.
Larsson (2009) förklarar i sin studie att man vid riskbaserad säkerhetstestning styrs av risker och inte funktionella krav. För att inleda tester bör man först göra någon form av riskanalys för att identifiera potentiella hot och sårbarheter för systemet.
När en sådan genomförts kan man baserat på utfallet från analysen besluta lämpliga testmetoder och hur mycket testning som ska utföras.
Enligt McGraw (2006) så är riskbaserade säkerhetstester baserade på både den arkitektoniska riskanalysen men också från en attackerares perspektiv. Därför har området mycket gemensamt med penetrationstestningsområdet.
Den största skillnaden mellan riskbaserad säkerhetstestning och penetrationstestning är att riskbaserad säkerhetstestning kan implementeras innan mjukvaran är färdig, på enhetstest nivå. Penetrationstestning utförs oftast när hela systemet är färdigt och driftsatt. (McGraw, 2006).
28
Figur 7 Översikt över säkerhetstestning (Potter & McGraw, 2004)
McGraw (2006) beskriver också en signifikant skillnad i nivåskillnaderna för riskbaserad säkerhetstestning:
• Penetrationstester utförs på black box testnivå, där man inte känner till de interna funktioner och komponenter i systemet och riktar sig oftast utifrån
→ in.
• Riskbaserad säkerhetstestning utförs på white box testnivå, där man känner till de interna funktioner och komponenter i systemet.
White box och Black box är två test analysmetoder där man i båda metoderna försöker förstå mjukvaran men har olika infallsvinklar. Vid white boxtestning har man tillgång till källkoden och försöker analysera och förstå den. Black boxtestning är motsatsen, där har man inte insyn i systemet utan får rikta in sig på ett fungerande och driftsatt system, där man försöker hitta sårbarheter utifrån. (McGraw, 2006).
Därför anser McGraw (2006) att man i ett tidigt skede ska börja implementera säkerhetstestning, på funktion eller komponentnivå innan man börjar integrera funktioner och komponenter i systemet.
Med hjälp av riskanalys ska testfall struktureras så att de utformas för både obehörigt missbruk av systemet och fall som bryter mot funktioners antaganden för exempelvis indata (McGraw, 2006).
4.2 Ekonomiska aspekter
Figur 3 i kapitel 2.4 Livscykelmodellen visar att ju längre man kommer i modellen så ökar kostnaden för att laga defekter.
McGraw (2006) menar att det är en ökande kostnad ju längre fram i utvecklingskedjan man kommer, detta illustrerar han i nedanstående graf.
29
Figur 8 Kostnaden för att laga defekter per fas i systemutveckling (McGraw, 2006)
McGraw (2006) vill med Figur 8 försöka påvisa hur galet det blir om man lägger all sin fokus på säkerhetstestning i slutet av utvecklingsfaserna. Han poängterar att det givetvis är bra att hyra in penetrationstestare i slutet av utvecklingsfasen men alla andra typer av säkerhetstest måste prioriteras i början. McGraw menar att det annars kommer sluta med en katt- och råtta lek där man på kontinuerlig basis får sätta sig och laga uppkomna defekter till mycket höga kostnader.
Jones & Bonsignour (2012) beskriver också ekonomiska konsekvenser för låg kvalitativa system, några av dessa konsekvenser inkluderar:
• Förseningar i leveranser av nya applikationer
• Överskridande av budget för utvecklingsprojekt
• Skador för en verksamhet, antingen skadat rykte för att ha levererat en undermålig produkt eller ekonomiska på grund av dataintrång eller liknande
• Höga underhållskostnader
Även OWASP (2020) poängterar att det kan vara ekonomiskt gynnsamt, att man potentiellt kan göra besparingar på upp till en tredjedel av underhållskostnaderna.
Winkler & Treu Gomes (2016) beskriver att det kan anses vara två typer av konsekvenser man kan ställas inför vid en risk ur ett ekonomiskt perspektiv:
• monetär förlust – man förlorar faktiska pengar
• vanrykte – man förlorar sitt goda anseende, det sprids dåligt rykte
