Af Tom Madsen, Alt om Data
Denne artikel er oprindeligt bragt på Alt om Data. Computerworld overtog i november 2022 Alt om Data. Du kan læse mere om overtagelsen her.
I de senere år har vi set en flodbølge af nye hacks, der frigiver et utal af personlige oplysninger på Internettet. Vi har set eksempler på hacks, der har resulteret i hundredvis af millioner af oplysninger på kunder og ansatte, der pludseligt ligger frit tilgængelige på internttet. Hackerangreb er ikke længere noget, vi hører om i pressen en gang eller to om året, det er på en ugentlig basis, at vi hører om disse hackerangreb, og de konsekvenser det har for både firmaerne og de ramte kunder og ansatte.
Der er mange grunde til, at det lykkedes for angriberne at trænge ind i systemerne, og mange måder for dem at gøre det på, men der er dog også ganske mange muligheder for at gøre det vanskeligere for dem at trænge ind. I denne artikel vil jeg fokusere på et framework fra organisationen OWASP. Du kender måske allerede OWASP, fra de ti sårbarheder, der bliver frigivet derfra hvert tredje år. Du kan se de to seneste på figur 1.
OWASP er en organisation, der er rettet imod at oplyse og hjælpe organisationer med sikkerheden i deres webudviklings-projekter.
Med hjælp mener jeg, at de har udviklet metoder og teknikker, der kan inkorporeres i et udviklingsprojekt, og af den vej medvirke til at reducere de sårbarheder der måtte være i applikationen. OWASP er det man kalder en ’Non Profit Organisation’, og de anbefaler ikke produkter fra leverandører. Deres fokus er kun på, hvordan en web-applikation bliver udviklet på en sikker måde, og ikke på de teknologier der bliver brugt til udviklingen. OWASP har adskillige teknikker og processer, men her vil jeg fokusere på den der hedder CLASP.
Clasp gør web-appen sikker
CLASP står for Comprehensive Lightweight Application Security Process. CLASP er fremkommet fra mange års erfaring med udviklingsprojekter og er designet til at kunne blive tilføjet til de allerede eksisterende ALM- (Application Lifecyckle Management) teknikker i brug. CLASP er delt ind i enkelt aktiviteter rettet imod de personer, der er i de forskellige roller i et udviklingsprojekt. Aktiviteterne hjælper så disse personer med retningslinjer for, hvordan de skal reducere/fjerne antallet af sårbarheder i applikationen. Det vil sige, at der findes aktiviteter for udviklere, projektledere, testere m.m.
De enkelte aktiviteter er delt ind i det, man kalder for Views i CLASP. Du kan se, hvordan de enkelte Views er inddelt på figur 2. Det er inddelingen på figur 2, der gør, at man kan tilføje CLASP-metodikken til en allerede eksisterende ALM. Læg mærke til at det først er fra View II, at man skal til at tildele roller. Det samme gør sig gældende for de andre OWASP-metodikker. Der er en fase, hvor man evaluerer, om metodikken er den rette for et udviklingsprojekt.
Når man når til View III, er man nået til der, hvor arbejdet med CLASP begynder. Det er her selve evalueringen af udviklingsprojektet begynder, og de enkelte risici-områder bliver identificeret. Det er også her, at man evaluerer den risiko, man løber ved ikke at sætte ind overfor en identificeret risiko. Mens man er i View II, består evalueringen også i identificeringen af, om nogle af aktiviteterne er anvendelige på udviklingsprojektet.
I View IV begynder så selve arbejdet med at implementere de aktiviteter, der er blevet identificeret i View III. Der er i alt 24 individuelle aktiviteter i CLASP, men under View III, er det ikke nødvendigvis alle 24, der er blevet dømt anvendelige i udviklingsprojektet. I View V er de aktiviteter, der er blevet fundet anvendelige i View III og IV, fuldt integreret i ALM for projektet. Der er ikke noget til hinder for, at implementeringen af CLASP- aktiviteterne sker en af gangen.
Så hvis man f.eks. bruger Scrum, kan de enkelte aktiviteter blive implementeret sammen med de enkelte sprints i projektet. OWASP kommer med masser af hjælp til de enkelte dele af CLASP. Min personlige favorit er de Use Cases, der kommer sammen med CLASP-dokumentationen. På figur 3, kan du se hvor i processen disse Use Cases passer. De Use Cases, der kommer med CLASP, er rettet imod den traditionelle http-applikation, men kommer også med Cases til både Unix og Mainframe! CLASP har naturligvis også definitioner for sårbarheder.
For CLASP består en sårbarhed i en fejl i applikationen, der gør det muligt for en angriber at tilegne sig øgede rettigheder i applikationen. Hvad vil det sige, kan man spørge. Softwarefejl, specielt sikkerhedsfejl, kan klassificeres på mange måder. I nogle metodikker er en fejl, der får applikationen til at gå ned, klassificeret som en sikkerhedsfejl, men for CLASP er en sikkerhedsfejl noget, der giver en angriber adgang til data og/eller applikationsoperation.
CLASP har klassificeret 104 problemer i applikationssoftware, der danner basis for sårbarheder. 104 lyder måske som meget, men det er ikke nødvendigvis en fejl i en enkelt blok af kode, men en fejl, der sammen med en fejl i en eller flere andre kodeblokke tilsammen vil udgøre sårbarheden.
Flere andre metoder
Det her var en hurtig introduktion til CLASP-metodikken fra OWASP. OWASP har flere andre metoder, der kan finde anvendelse i et applikations-udviklingsprojekt. Der findes endda anbefalinger for projekter, der er baseret på Java og .NET. Har du selv ideer til et projekt, som kunne have interesse for OWASP, så er der rig mulighed for at komme i gang med det.
På OWASP-hjemmesiden (www.owasp.org) kan du downloade deres projektguide. Her til sidst skal det siges, at OWASP ikke er de eneste, der har anbefalinger for sikre software-udviklingsprojekter. F.eks. har Microsoft selv deres egne retningslinjer for sikker programmering. Fra de mere åbne organisationer er der anbefalinger fra www.cert.org og www.isc2.org.
Uanset hvilken metode du vælger at bruge, så er det at tænke sikkerhed ind fra starten, ikke bare i selve applikationen, men i selve udviklingen af den, en god idé! Ikke bare for dig selv og din organisation, men også for de kunder du har, og som køber din applikation, og for dem der har data gemt i applikationen. Hvis vi skal væk fra alle de kæmpe historier om datalækager i medierne, så er sikkerhed ikke længere noget, der skal tilføjes applikationen til sidst, men tænkes ind fra starten af.
