A.3 Teori
A.3.3 Användarfall
Användarfall används för att beskriva hur en viss interaktion mellan systemet och användare ska fungera för att utföra en uppgift. Oftast används ett diagram för att förtydliga beskriv- ningen. [60]
A.4. Metod
A.4
Metod
A.4.1
Informationssökning
För att hitta vetenskapliga källor på kravanvändning i liknande mjukvaruprojekt användes söktjänsten Google Scholar med sökorden agile requirement engineering practices. Ett annat sätt som användes var att utgå från en källas referenser för att hitta flera källor som behandlade samma ämne.
A.4.2
Datainsamling
Utvärderingen grundades på gruppmedlemmars erfarenheter kring projektets kravhante- ringsmetoder. Därför gjordes en datainsamling i slutet av projektet genom att låta grupp- medlemmarna i ett mjukvaruprojekt svara på ett frågeformulär, se figur A.1. Frågeformuläret innehöll frågor om gruppmedlemmens erfarenheter till varje kravhanteringsmetod projektet haft samt en fråga där gruppmedlemmen fick dela med sig av förbättringar den hade ve- lat göra på kravhanteringen. Svaren på respektive fråga sammanfattades och presenterades i resultatet.
Tabell A.1: Frågor i frågeformulär för Vad är dina erfarenheter kring projektets kravspecifikation? Vad är dina erfarenheter kring projektets prioritering av krav? Vad är dina erfarenheter kring projektets kundmöten?
Vad är dina erfarenheter kring projektets user story? Vad är dina erfarenheter kring projektets användarfall?
Vad är dina erfarenheter kring att analysansvarig agerade kund mot resten av gruppen? Vad är dina erfarenheter kring projektets uppgiftslistor för iterationer?
Vilka ändringar hade du velat göra med projektets kravhantering?
A.5
Resultat
A.5.1
Informationssökning
Totalt användes två artiklar som båda presenterade ett antal agila kravhanteringsmetoder. Den första artikeln jämför traditionell kravhantering med agil kravhantering [59] och den andra presenterar sju agila kravhanteringsmetoder som de kunnat specificera genom att ana- lysera data från 16 mjukvaruutvecklingsorganisationer [18]. Metoder från båda artiklarna presenteras i följande stycken, namnen på metoderna skrivs på engelska då artiklarna är på engelska.
Interviews/Face-to-Face Communication Då agil kravhantering oftast utelämnar metoden att dokumentera kraven så är det viktigt att kunden effektivt kan förmedla sina idéer till utvecklarna. Förmedla kunskap via flera personer eller med skrift är allmänt känt att kunna leda till missuppfattningar. Därför är metoden att kommunicera med kunden i person att föredra. [59, 18]
Iterative Requirements Engineering Det kan vara svårt specificera krav i början av ett pro- jekt. Istället kan det vara enklare att specificera dem när arbetet har börjat då de involverade har fått sätta sig in mer i projektet. Denna metod går ut på att ha ett kravspecificeringsmoment flera gånger under projektet där utvecklarna och kunden lägger till nya krav eller ändrar be- fintliga. [18]
A.5. Resultat
Prioritization Att projektet ändras under utveckling är något som ofta händer i ett agilt projekt på grund av att de involverade oftast får mer förståelse för produkten längre in i projektet. Det är därför viktigt att uppdatera prioriteringen av krav för att hålla den rele- vant. [59, 18]
JAD sessions För att snabbt få fram dokument till ett agilt projekt kan kunden tillsam- mans med projektgruppen använda sig av denna form av workshop. Detta är precis som Interviews/Face-to-Face Communication en bra metod för att låta kunden förmedla sina idéer. I ett agilt projekt kan dessa workshops hållas ett flertal gånger under projektet för att gruppen ska kunna få feedback mer än en gång. [59, 24]
Modeling/Prototyping I ett agilt projekt är modellering ett effektivt sätt att visa hur man förstått produkten vid avsaknad av dokumentation. Det händer även att modeller blir en del av produkten i ett agilt projekt och de bör därför hållas uppdaterad under hela projek- tet. [59, 18]
Documentation Trots att en dokumentation av krav inte anses vara agilt så kan avsaknaden av en skapa problem i agila projekt. Samtidigt kan dokumentation minska frågor mellan gruppmedlemmar och förhindra att kunskap går förlorad vilket är tidskrävande. [59]
Test-Driven Development Att implementera tester som testar kraven på nya funktioner innan funktionerna implementeras kan fungera som ett sätt att specificera kraven. Denna metod är därför ett bra sätt för att skapa kopplingar mellan krav och kod. [18]
A.5.2
Datainsamling
Kravspecifikation Övervägande delen av gruppen ansåg att kravspecifikation var något bra att ha då den gav gruppmedlemmarna en bild av kraven i början av projektet. De ansåg också att den borde använts mer under utvecklingen som en checklista och för att följa upp om produkten uppfyllde kraven. En gruppmedlem ansåg att kravspecifikationen endast var något gruppen tog fram för att de var tvungna och att den inte var av något värde för kunden.
Prioritering Alla gruppmedlemmar var positiva till prioritering och tyckte att kraven var prioriterade rimligt. En gruppmedlem påpekade att detta berodde på att kunden var kun- nig. Ett fåtal tog upp svårigheter med att prioritera krav som är beroende av varandra. En gruppmedlem ansåg att prioriteringen skulle använts mer vid val av uppgifter.
Kundmöten Övervägande delen av gruppen ansåg att det hade varit bra att träffa kunden efter varje yttre iteration för att göra kunden mer delaktig i projektet genom att föra en dialog om kommande implementationer och förbättringar på produkten. En gruppmedlem ansåg sig dock inte fått ut något av värde för egen del från mötena.
User story Endast ett fåtal av gruppmedlemmarna ansåg att kraven varit användbara för att förstå produkten och kraven. Resten hade inte använt sig av dem. En av dessa tog upp att den inte visste att de fanns.
Användarfall Ingen av gruppmedlemmarna hade använt sig av användarfallen. En nämn- de att de var som en hopslagning av user story vilket gjorde dem överflödiga.
A.6. Diskussion
Gruppmedlem agerar kund Alla gruppmedlemmar tyckte att det var bra att ha en grupp- medlem som stod närmast kunden och på så sätt hade extra bra koll på kraven. Det poängte- rades att detta då ledde till endast en tolkning av kundens krav så att hela gruppen arbetade mot samma sak vilket är bra men att det finns en chans att denna tolkning är felaktig. Några nämnde att följden av denna metod var att de själva inte var så insatta i kraven.
Uppgiftslistor Alla ansåg att ta fram uppgiftslistorna var kostsamt i tid och därför resul- terade i att det genomfördes med sämre kvalitet mot slutet av projektet när projektet blev stressigare. En gruppmedlem tyckte uppgiftslistor var en bra metod men att det kan ha varit för tidskrävande i detta projekt på grund av att de skapats i ett dokument på Google Dri- ve för att sedan föras in i Jira. En annan nämnde att uppgiftslistorna hade behövt vara mer strukturerade för att de skulle varit användbara.
Ändringar Övervägande delen av gruppen hade velat haft en tydlig genomgång av kraven och deras prioritet så att de fått en tydligare bild av dem och produkten. En gruppmedlem nämnde att den velat använda kraven mer under planering av projektet.
A.6
Diskussion
Överlag verkade alla kravhanteringsmetoderna inte använts som gruppen bestämt fullt ut under hela projektet, frågan var om detta berodde på dålig disciplin i gruppen eller opas- sande metoder för typen av projekt. Till exempel så verkade sättet gruppen använt sig av metoderna inte passat deras projektkonfiguration om man utgår från artiklarna från infor- mationssökningen. Bland annat så nämnde en artikel användningen av en lättare typ av do- kumentation som byggdes på under utveckling. Gruppen hade dock använt sig av en full- ständig kravspecifikation som de skapat i början av projektet. Orsaken till detta var förstås att gruppen skulle lämna in kravspecifikationen till examinatorn tidigt i projektet.
Att gruppen hade skapat en kravspecifikation kan ha medfört att gruppen kände sig nöj- da med det de gjort kopplat till krav och därför avstått att använda andra metoder som hade funkat bättre för gruppen då det hade tagit extra tid. En kravspecifikation bör dock ha passat projektet då kraven inte ändrats under utvecklingen. Trots det använde gruppen ändå inte sig av den under resten av projektet. Att gruppen inte följt upp metoder eller använt sig av meto- der i senare delen av projektet verkar inte bara gälla kravspecifikationen då liknande resultat från en enkät gällande arbetsmetoden och de andra dokumentet tagits fram och presenteras i den gemensamma resultatdelen, avsnitt 4.1.
Det är även intressant i denna rapport att spekulera om vad som hade kunnat förbättras om kravspecifikationen inte hade varit ett obligatoriskt metod. Dålig disciplin i gruppen är enligt resultatet nästintill ett faktum. Enligt resultatet passade inte kravspecifikation grup- pen då den kräver bra disciplin för att följas upp och på så sätt vara till mer nytta än till att få en introduktion till kundens krav. En iterativ kravspecificering som nämns från informa- tionssökningen hade haft samma problem och varit onödig då kraven inte ändrats så mycket under projektet. Många gruppmedlemmar ville ha tydligare genomgångar av kraven så JAD sessions hade i så fall varit ett bra alternativ för att på ett strukturerat sätt ta fram kraven och samtidigt ge alla bättre vetskap om dem. Dock hade det varit slöseri med tid då kraven som sagt inte ändrades. Varje gruppmedlem hade även kunnat kommunicera med kunden för att förstå kraven men gruppen tyckte att det var bra att ha endast en som jobbade med kunden för att ta fram kraven och det påpekades att utan denna metod hade flera tolkningar av vad kunden ville kunnat skapats.
Båda artiklarna nämner modellering som lättförståeligt och lättillgängligt. En modell skulle troligtvis följts upp av alla i gruppen då den oftast blir en del av produkten. Testdriven utvecklingen är också något som gör kraven lättillgängliga samt gör att kraven följs upp av gruppen. Till skillnad från modeller är tester dock inget bra sätt att validera kraven med hjälp
A.7. Slutsatser
av kunden och skulle därför behöva användas tillsammans med modellering, kravspecifika- tion eller annan liknande metod som är det.
A.7
Slutsatser
Då det var obligatoriskt i kursen att skriva en kravspecifikation så finns det inte några förbätt- ringar att göra med projektets kravhantering då att använda andra metoder som fyller samma syfte som kravspecifikationen tillsammans med kravspecifikationen hade krävt tid från ut- vecklingen. Förbättringar hade istället behövts göras på gruppens disciplin eller struktur så att kravspecifikationen följts upp bättre.
Om kravspecifikationen inte hade varit obligatorisk hade modellering tillsammans med testdriven utveckling kunnat ersätta den och troligtvis givit gruppen en tydligare bild av produkten och kraven vilket i sin tur hade kunnat förbättra utvecklingen och resultatet av produkten. Då kravspecifikationen var obligatorisk hade användningen tillsammans med båda eller en av dessa metoder haft samma eller bättre följder om man ignorerar kostnaden i tid det skulle medföra.
B
Studenters kunskap om och
inställning till lösenord och
internetsäkerhet av Gustav
Eriksson
B.1
Inledning
Har jag blivit hackad? Varje dag blir den frågan allt mer relevant. Troy Hunt, en av de mest framgångsrika säkerhetsteknikerna på Microsoft, har för att kunna besvara den frågan ska- pat hemsidan haveibeenpwned.com där det går att söka på ett specifikt konto för att se om det har utsatts för fientlig aktivitet. Där går det även att se ett urval av de största kända dataläckorna genom tiderna. Till exempel utsattes LinkedIn 2016 för en attack som resultera- de i att nästan 165 miljoner konton läcktes, och totalt sett har över sju miljarder konton blivit utsatt för fientlig aktivitet [1]. Ett annat exempel är Facebook, som så sent som i september 2018 utsattes för den största attacken i deras 14-åriga historia där runt 30 miljoner konton läcktes [65]. Det utförs dock inte bara attacker mot stora företag och hemsidor. Incitamenten att hacka persondatorer och liknande har ökat då fler och fler tjänster digitaliseras och alltmer information skickas över nätet. Vikten av säkra lösenord och säker lösenordshantering stiger därför ständigt.
För att undersöka hur bra kunskap studenter vid Linköpings universitet har om detta äm- ne har en enkätundersökning utförts. Enkäten behandlade frågor som på olika sätt relaterar till lösenord och inställning till internetsäkerhet generellt.
B.1.1
Syfte
Syftet med denna rapport är att undersöka hur välinformerade studenter vid Linköpings universitet är om lösenord och internetsäkerhet samt vad de har för inställning till det. Detta innefattar vilka kvaliteter ett lösenord bör ha för att kunna klassas som starkt, vilka risker som finns vid användning av internettjänster samt vilka åtgärder som finns för att skydda sig mot dessa risker.
B.1.2
Frågeställningar
1. Hur bra kunskap har studenter om lösenord generellt?
2. Vilka risker med internetaktivitet är de mest kända bland studenter? 3. Vilka egna säkerhetsåtgärder vidtas?
B.2. Teori
B.1.3
Avgränsningar
Denna rapport behandlar endast svar från 33 deltagande, vilket är en relativt liten svarsgrupp när det kommer till statistiska undersökningar. Diskussionen tar därför hänsyn till detta. Det finns även många olika åsikter om vad som är ett bra lösenord. Referensen för detta kommer i denna rapport främst utgöras av argumentationen i [28] och [76].
B.2
Teori
I bedömningen av ett lösenords säkerhet måste flera faktorer vägas in. För att lättare få en bild om varför de ska hålla vissa standarder beskrivs i detta avsnitt några ganska vanliga metoder och verktyg angripare använder sig av för att knäcka lösenord och få åtkomst till andras kon- ton. Begreppet entropi, som introducerades till informationsteorin av Claude Shannon, bör också kännas till. Det är definerat som ett mått på slumpmässighet hos en stokastisk variabel, och i lösenordskontext kan det ses som graden av slumpmässighet för varje tecken. Om ett lösenord har hög entropi medför det att det också är av hög kvalitet. Alltså bör ett lösenord innehålla många olika tecken i en ologisk följd. Lösenordet ”(1cat)**” har till exempel mycket hög entropi, och är därför av hög kvalitet. [76]
B.2.1
Brute force
En brute force attack går ut på att angriparen försöker knäcka ett lösenord genom att syste- matiskt testa sig igenom så många teckenkombinationer som möjligt i förhoppningen att så småningom gissa rätt. Metoden kan variera men ofta brukar en brute force attack syfta till att testa dem helt systematiskt, till exempel alfabetisk ordning. Ett enkelt sätt att göra det svårare för angriparen att lyckas med en sådan attack är därför att använda långa lösenord eftersom de tar längre tid att knäcka. Om ett lösenord består av n karaktärer, där varje karaktär är ett av a olika tecken, finns det an olika kombinationer som angriparen måste prova sig igenom. För att sätta detta i perspektiv kan två lösenord av längderna n1=8 respektive n2=9 jämfö-
ras, där båda består av stora och små bokstäver från det svenska alfabetet samt siffror, alltså a=68.
an1 =688=457163239653376
an2 =689=31087100296429568
31087100296429568 ´ 457163239653376=30629937056776192 « 31 ¨ 1015
Lösenordet med längden 9 ger alltså upphov till knappt 31 biljarder fler kombinationer som angriparen måste prova sig igenom.
B.2.2
Dictionary attack
En dictionary attack är en speciell typ av brute force-strategi. Här använder sig angriparen av en ordbok med förlagrade lösenord eller vanligt förekommande ord istället för att pro- va slumpmässiga kombinationer. Ordboken innehåller typiskt lösenord från stora dataläckor orsakade av andra attacker. Ett bra sätt att minimera risken för att låta en sådan attack lyckas är att undvika användning av vanligt förekommande lösenord som till exempel ”123456”, ”qwerty”, eller ”password”. Ett bra skydd mot detta är lösenord som består av minst 6 helt slumpmässiga ord i följd. Dessa kallas lösningsfraser, och rekommenderas i Linköpings uni- versitets lösenordspolicy [15].
B.2.3
Social engineering
Social engineering är en term som används för att beskriva en av de vanligaste typerna av angreppsmetoder. Det finns flera olika typer, men alla har gemensamt att de utnyttjar män-
B.2. Teori
niskans sociala natur för att bryta sig in i system eller komma åt känslig information. Nedan listas några vanliga exempel på social engineering.
• Phishing är ett försök till att få tillgång till privata uppgifter eller plantera virus genom att skicka infekterade massmail eller dela infekterade hyperlänkar.
• USB-drops innebär att infekterade enheter som till exempel ett USB-minnen planteras på offentliga platser i hopp om att någon ska hitta det och råka infektera en egen enhet. • Tailgating är förföljandet av någon med syftet att försöka få tillgång till privata uppgifter som till exempel bankkortsnummer, lösenord eller liknande. Detta innefattar primitiva metoder som att titta offret över axeln när denne matar in sin kod.
Detta är en av de svåraste formerna av attacker att helt skydda sig mot. Generellt gäl- ler det att vara misstänksam mot okända länkar och apparater samt att aldrig ge ut kritisk information till okända personer. [5]
B.2.4
Rootkit
Ett rootkit, eller spökprogram på svenska, är egentligen endast en samling verktyg designade för att ge administratörsrättigheter åt en dator eller nätverk, men eftersom dessa verktyg kan användas av en angripare för att dölja spår av intrång är termen idag nästan synonym med datorvirus. [64]
B.2.5
SQL-injection
SQL-injection är en metod som utnyttjar säkerhetsbrister för att plantera skadlig kod i databa- ser och är en av de vanligaste teknikerna som används i webbattacker. Vanligtvis sker detta när en hemsida ber om användarinput och användaren skriver in ett giltigt SQL-kommando som då körs på databasen. Detta kan exempelvis utnyttjas av en angripare för att komma åt kontouppgifter på en hemsida när den ber om angriparens inloggningsuppgifter. Därför är det mycket viktigt att all användarinput valideras innan den används. [70]
B.2.6
Keylogger
Keylogger är en typ av programvara som registrerar information som användare matar in med tangentbord eller andra liknande enheter. Detta kan användas av en nätbrottsling för exempelvis spionage eller för att komma åt lösenord, vilket har gjort att termen idag ofta förknippas med brottslig verksamhet. [44]