Sådan integrerer du sikkerhedsanalyse i agil softwareudvikling

Code reviews har længe været en integreret del af udviklingsprocessen, men væsentligt mere sjældent bliver en sikkerhedsanalyse inkluderet som en integreret del af udviklingen i et projekt. Ofte udelades sikkerhed indtil slutningen af et projekt, hvor man forsøger at lappe noget sammen ved fx at opsætte en firewall. Det er sjældent nok til at gøre systemet sikkert. Samtidig har virksomheder siden d. 25. maj 2018 fået et ekstra ansvar for brugernes data i form af GDPR*.

Men så må det være godt nok blot at indtænke sikkerhed i starten af projektet, og så lave en afsluttende sikkerhedsanalyse i slutningen af processen, ikke?

Svaret er principielt set jo, men det giver nogle udfordringer:

• Projekter har det med at ændre sig undervejs, så antagelser man gjorde sig i starten, holder ikke længere.
• Man kan ikke tænke på alle sikkerhedsmæssige detaljer i starten af et projekt.
• Selv hvis man fanger alle sikkerhedsfejl i den afsluttende analyse, så vil det blive dyrere og mere tidskrævende at rette op på fejlene, end hvis man havde fundet fejlen og mitigeret den i løbet af projektet.
• Hvis fejl først bliver opdaget i den afsluttende analyse, kan det lede til beslutninger om at acceptere risici, som ellers kunne været undgået.
• Det kan være dyrt at lave en stor analyse up-front, hvilket kan udmønte sig i, at der ikke er flere penge til at implementere de fundne problemer.

Én løsning er at inkludere sikkerhedsanalyse oftere og optimalt som en integreret del af udviklingsprocessen. Dette kan gøres på flere måder. Fx ved at have en dedikeret sikkerhedsekspert på projektet, som sørger for at sikre processen og løbende foretage code reviews. Det kan dog ikke altid lade sig gøre – enten fordi projektet ikke har økonomi til det, eller fordi mængden af sikkerhedseksperter er begrænset.

Man kan også opdele den afsluttende analyse i mindre bidder undervejs og opsummere til sidst. En anden tilgang kan være at benytte det, som Jim Gumbley beskriver som agile threat modelling, der naturligt passer ind i Scrum metodikkens sprints. Det er denne tilgang, vi fokuserer på her.

Hvorfor er sikkerhed overhovedet vigtigt?

I disse moderne tider vil din virksomhed ofte benytte noget mere eller mindre intelligent IT i forbindelse med udførslen af et stykke arbejde. Det kan være en computer, en IoT enhed, en intelligent mejetærsker etc. Formentlig har det forbindelse til internettet, og selv hvis det ikke har, så har den kode, der udgør kredsløbet i fx mejetærskeren formentlig været tilgængelig via internettet på et tidspunkt.

Det kan være, en konkurrent vil sætte dig ud af spillet. Det kan være, en organisation vil benytte jeres IoT-enhed som del af et bot-net. Måske er det blot én, der leger med hacking og bruger jer som legeplads. Har I mange brugere, kan I være et springbræt til at få fat på brugernes passwords, som de formentligt har genbrugt andre steder. Så selvom I ikke tror I har interessant data, kan det sagtens være tilfældet alligevel.

Pointen er: Hvis du ejer noget der har værdi, så kan det være værd at angribe.

Agil Trusselsmodellering

Agil trusselsmodellering er et framework, der søger at muliggøre udførelsen af en sikkerhedsanalyse på relativt kort tid ved at udnytte et for hver session fastdefineret scope, som sikrer det nødvendige fokus.

Trusselsmodellering lyder måske fancy og svært, men egentlig handler det blot om at finde sårbarheder i dit system ud fra en model, der viser systemet, men ikke introducerer unødvendig kompleksitet. Det agile består i at begrænse sig til mindre dele af systemet og eventuelt gennemgå samme del flere gange i løbet af projektet, hvis den del ændrer sig nok.

Agil trusselsmodellering søger at gøre den almindelige udvikler i stand til at indtænke sikkerhed i ethvert system.

Udførsel af trusselsmodellering

Når man skal udføre en trusselsmodellering, skal man som minimum stille sig selv disse tre spørgsmål:

1. Hvad bygger vi?
2. Hvad kan gå galt?
3. Hvad skal vi gøre ved det?

De næste afsnit vil give idéer til, hvordan de forskellige aspekter af disse spørgsmål kan afdækkes.

Scope

Uanset hvilken tilgang man benytter, så skal man overveje, hvilket scope man benytter til sin analyse. Ens scope definerer rammen for analysen og dermed også, hvad man ikke skal analysere. Uden et defineret scope sker det nemt, at man forsøger at overskue samtlige angreb verden kan kaste mod én. Det resulterer ofte i, at man mister detaljer, og at man ikke når at fordybe sig i tekniske problemer.

Når man er enige om, hvad scope for analysen er, kan man gå i gang. Forsøg at rammesætte et scope, der passer med den feature eller epic, som næste sprint skal fokusere på.

Glem ikke at benytte et mere high-level scope en gang imellem for at fange evt. problemer i systemet, som måske kun opdages ved at kigge på arkitekturen mere abstrakt.

Outcome

Resultatet af analysen bør være en række punkter, der potentielt skal på backlog’en. Dette kan gøres enten lavpraktisk med en række post-its eller ved indførsel i et issue tracking system såsom Jira. Uanset hvad, skal der være en beslutningstager, der afgør hvilke mitigeringsstrategier, der bør indføres i backloggen, og hvilke sikkerhedsproblemer man accepterer risikoen af.

Hvem skal udføre trusselsmodelleringen?

Den klassiske tilgang er, at en sikkerhedsekspert udfører analysen med hjælp fra udvalgte personer, der kender systemet godt fra de vinkler, der er nødvendige for analysen.

I denne agile tilgang vil vi vende det lidt om og argumentere for, at sikkerhedseksperten ikke er en kritisk ressource, men blot endnu en facet til analysen. Vi foreslår at inkludere så mange roller, som det er praktisk muligt. Dette sørger for at sprede viden til hele teamet og specifikt til beslutningstagere, som vil opnå en bedre forståelse for, hvorfor de problemer, der er fundet, faktisk er vigtige at adressere. Husk derfor at inkludere de ikke tekniske roller i analysearbejdet.

Hvad bygger vi?

Low level arkitektur-tegning

Start med, på en tavle, at tegne de systemer, der interagerer med hinanden. Indtegn også alle data flows som scopet definerer og hvilke personer, der er involveret. Det kunne fx se ud som på figur 1. Her er de røde pile dataflows, grøn er opdeling af autorisationsgrænser og blå er relevante assets for det givne scope.

Assets

Find dernæst de assets, der måtte være relevante for scope og som dataflows berører. Et asset er noget, der er vigtigt for virksomheden, som benytter produktet. Det kan fx være data (personfølsom, system kritisk, nøglemateriale etc.), personer involveret (biometric login) eller fysiske objekter såsom USB nøgler.

Hvad kan gå galt?

Angreb

Nu til det sjove! Stil dig i angriberens sko og forsøg at finde så mange sårbarheder i systemet som tidsrammen giver mulighed for.

Fokusér på de tekniske problemer.

For at sikre at vi ikke hopper ned i et kaninhul, foreslår vi at nøjes med et fokus på tekniske problemer fremfor at forsøge at sikre sig mod store organisationer eller efterretningstjenester. Dette vil formentlig hurtigt lede til en konklusion om, at intet system er sikkert nok, og vi derfor ligeså godt kan give op på forhånd.

Lidt kynisk skal man i stedet tænke: Vi skal blot sørge for, at vi er tilpas svære at angribe, så andre er lettere mål.

Hvis I skal bruge inspiration, så spørg jeres sikkerhedseksperten, hvis han eller hun er til stede. Ellers kan du benytte følgende muligheder:

• Fokusér på det asset, der betyder mest og følg data flows ud til, hvor en angriber kan befinde sig i systemet.
• Benyt CIA-tankegangen (Confidentiality, Integrity og Availability). Overvej hver af de tre og hvordan angreb kan foretages, hvis én af de tre ikke er til stede.
• Benyt STRIDE og gennemgå systemet for hver kategori af trusler.
• Find inspiration i OWASP’s top ten eller deres cheat sheets.
• Tænk out-of-the box. Det kan fx være at der findes et dataflow, I ikke har indtegnet.

Notér hvert mulige angreb i brainstorm stil og gå videre til næste potentielle angreb.

Når I løber tør for mulige angreb, benyt da en risikovurderingsmetodik til at afgøre, hvor stor omfanget af angrebet måtte være. Vi foreslår at tage inspiration fra OWASP’s risikovurderingsmetodik. Her giver man hvert angreb en samlet karakter fra 0-9 indenfor sandsynlighed og effekt, som tilsammen giver omfanget af angrebet.

Find den måde, der fungerer bedst for jer, således at det ikke tager for lang tid, men hvor I samtidig overvejer alle de vigtigste faktorer.

Et par eksempler på angreb baseret på figur 1 kunne fx være:

• Databasen benytter ikke encryption at rest, og credentials til det eksterne system kan derfor læses hvis adgang til databasen tiltvinges.
• Forbindelsen fra Angular App’en og backend’en benytter kun http, hvilket muliggør at JWT’en kan stjæles og brugeren kan impersoneres af en angriber.

Hvad skal vi gøre ved det?

Mitigering

Sidst, men ikke mindst, skal vi forsøge at finde måder at undgå angrebene på. Overvej hvilke måder man kan forsvare sig på og overvej gerne flere forskellige. Formentligt vil projektet gerne have den billigste løsning, men gør det klart hvis nogen løsninger har mangler. Overvej også om løsningen skaber nye sårbarheder.

Gør disse løsninger tilgængelige for beslutningstager og sørg for at denne har alle forudsætninger for at tage de rigtige valg. Der er intet problem i ikke at fikse samtlige sårbarheder, så længe man tager beslutningen med åbne øjne.