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.
Overskriften her er et citat fra den rapport, jeg bruger som grundlag for denne artikel, og der er vel ikke mange, som kan være uenige i den betragtning? Rapporten kommer fra Whitehat Security, og det er en rapport, der er udkommet hvert år siden 2006. Rapporten handler om de sårbarheder og huller, der har været i webapplikationer i det forgangne år 2015. Selve rapporten handler udelukkende om huller i websoftware, eftersom der er masser af andre rapporter om sårbarheder og huller i software generelt. Sidst men ikke mindst handler rapporten om de sårbarheder, der opstår i specialudviklede webapplikationer til firmaer. Det vil her sige applikationer, der er udviklet fra bunden af et firma for at tilfredsstille et behov. Så vi taler altså om applikationer, der er udviklet i f.eks. PHP eller ASP.NET, men ikke websider der kører på f.eks. Drupal og lignende.
Usikre webapps har store omkostninger
Det er desværre ikke længere en overraskelse, når vi i dagbladene læser, at et firma igen er blevet udsat for et indbrud i deres webapplikation og har mistet data. Det er ikke en daglig foreteelse, men det er en ugentlig en af slagsen. Det er blevet så almindeligt, at det nu kun er de allerstørste af slagsen, der kommer i aviserne.
Ponemon, der er et institut, der laver uafhængige undersøgelser af forskellige aspekter af sikkerhed, siger, at 45% af alle de indbrud, der sker i webapplikationer, koster $ 500.000 eller små 3 millioner danske kroner eller mere. Det er næsten halvdelen af alle indbrud, der har omkostninger i den størrelsesorden. Det bringer os tilbage til det citat, jeg brugte i overskriften til denne artikel. Vi har brug for mere sikker software ikke mere sikkerhedssoftware. De data, der er blevet brugt til rapporten, er på flere hundrede terabytes og kommer fra titusindvis af websider fra organisationer, der dækker et vidt spektrum af virksomhedstyper og brancher. Men lad os komme i gang med at kigge på de resultater som WhiteHat er kommet frem til.
Kodeanalyse og arkitekturanalyse
For det første findes der ikke et sæt af ’best practices’, der kan bruges overalt for at implementere sikkerhed i koden. Så sikkerheden i koden er altså mere bestemt af de forhold, som koden skal kunne fungere under. Når det så er sagt, så er der metoder, man kan implementere i sin udviklingsproces, som kan hjælpe på sikkerheden. Nogle eksempler er statisk kodeanalyse og arkitekturanalyse, der kan hjælpe med at reducere de sårbarheder, der er i koden, men som f.eks. ikke vil have nogen effekt på den tid det vil tage et udviklerteam at fikse en sårbarhed, når koden først er i produktion. Begge dele skal tages med, når man kigger på sårbarheder.
WhiteHat kunder blev også spurgt om, hvad deres primære grund til at fikse de sårbarheder, de fandt var. Her svarede 35 %, at det var for at reducere risiko. Overraskende nok, så var det tal 20 % mere end dem, der svarede, at det var pga. complience. I 2013 var complience den højeste grund til, at virksomhederne fiskede sårbarheder. Vi må gætte på, at en af grundene til ændringen er, at de virksomheder, der kæmpede med at blive compliant i 2013, er blevet det i mellemtiden. Og alligevel så bliver de store hacks af webapplikationer ved med at komme. At risikoreduktion er blevet den største faktor i 2015 kan kun tolkes som en positiv udvikling. At vide hvad ens risikoeksponering er, gør det markant nemmere at fokusere sine aktiviteter på de områder, hvor risikoen er størst.
Undersøgelsen viste også, at organisationer, der er drevet af et behov for at vise, at de er compliant, finder det laveste antal sårbarheder i deres websites. 12 pr. website. Mens de organisationer, der er drevet af et behov for at reducere risiko, finder 23 sårbarheder. Hvad betyder det? En skeptisk læser kunne tolke det som, at de organisationer, der skal være compliant, leder efter og finder de sårbarheder de skal, mens dem, der er drevet af at minimere risiko, er mere grundige? Et af de sikkerhedsråd jeg altid har fulgt, dukker op her. Hvis du leder efter færre sårbarheder, så finder du også færre.
Man kan også spørge sig selv, om ikke det at fokusere på risikoreducering ikke også betyder, at man samtidigt er compliant? Det skulle man mene, og jeg er sikker på, at når de organisationer, der lige nu fokuserer på compliance kommer videre, så vil også de skifte fokus til risikoreducering. Hvad med den tid som organisationerne bruger på at fikse de sårbarheder, som de eller andre finder? Betyder det noget i det store billede? Her er rapporten meget klar. At implementere et system, der giver udviklerne feedback på de sårbarheder, der bliver fundet, og implementere et sikkerhedsfokus i udviklerafdelingen reducerer antallet af sårbarheder i webapplikationen med 45 %. Samtidigt er den tid, det tager udviklerne at fikse en sårbarhed, reduceret med 13 %. Det er tal, der er til at tage og føle på!
Jeg nævnte statisk kodeanalyse tidligere i artiklen, og rapporten har yderligere at sige om den form for analyse. De udviklingsteams/organisationer, som tager statisk kodeanalyse til sig, og laver analysen dagligt, er ca. 96 dage om at fikse en sårbarhed. Dem, der ikke bruger statisk kodeanalyse, er op til 157 dage om at fikse en sårbarhed. Det er to måneder mere end dem, der bruger det.
Hvor ligger sårbarhederne?
Her til sidst, så lad os kigge på nogle af de figurer, der er inkluderet i rapporten. På figur 1 kan du se en oversigt over de forskellige områder, som sårbarheder kommer fra. De fleste af dem er områder, som vi kender i forvejen, men jeg vil godt knytte en kommentar til den søjle, der hedder ’Information Leakage’ på figur 1. Den søjle dækker over de sårbarheder som pga. konfigurerings- eller kodefejl lækker oplysninger. Jeg synes, det er trist at lige præcis den søjle er så høj, som den er. Specielt set i lyset af, at alle de store hacks, som vi har hørt om i de seneste år, har lækket enorme mængder af oplysninger om fuldstændigt uskyldige borgere rundt omkring i verden.
Figur 2 viser, hvordan sårbarhederne i figur 1 er fordelt på forskellige brancher. Læg mærke til, at de fleste brancher ligger inden for 10 % afstand til hinanden, så det ser ud til, at de alle sammen har de samme problemer med at udvikle sikker software og vedligeholde den.
Hele rapporten er på 30 sider, og jeg vil anbefale dig at downloade og læse den, hvis du har interesse i, hvad status er på sikkerheden i specialudviklede webapplikationer. Du kan finde den til download på http://www.infosecurity-magazine.com/. God læsning!