I dagens digitala värld blir det allt viktigare att säkerställa att ditt företags samlade information inte kan hittas och tas av andra. Därför bör du kontinuerligt jobba för en bättre säkerhet genom att löpande göra tester för att ta reda på om det finns sårbarheter. Vi vet att informationssäkerhet kan vara klurigt så i denna artikel kommer jag förklara skillnaden mellan sårbarhetsskanning och pentest. Jag hoppas ett det ger dig en bättre förståelse av testerna och vilken betydelse de har för ditt företag.
Sårbarhetsskanning är fullt automatiserad, du adderar endast vilka assets som ska bli skannade. Du talar om för systemet vad den ska leta efter och därefter sker allt automatiskt. Genom att löpande göra sårbarhetsskanningar har du hyfsad koll på din mognadsgrad, till exempel vid varje release. Har ni release varje vecka kan det vara klokt att investera i ett dynamisk eller statiskt sårbarhetsverktyg.
Vid sårbarhetsskanning letar systemet aktivt efter konfigurationsbrister eller sårbarheter utifrån bristfälligheter eller faktiska fel i programvara, server, klient, switch, router etc. Ofta rör det sig om ett grundläggande problem i koden, antingen har du gjort något ovetandes eller så har du utelämnat något, tex i konfigurationen.
Största fördelen med en automatiserad skanning är att du kan hitta många av de lågt hängande frukterna som tex broken authentication, cross-site scripting (XSS) eller andra typer av injektioner. Vilket är en bra början.
Exempel på de vanligaste sårbarheterna i webbapplikationer hittar du bland annat i OWASP (Open Web Application Security Project) topp 10 lista eller i Sans Top 25.
Pentest, även kallad penetrationstest är ett manuellt arbete. Här går du djupare än att bara kolla på de existerande sårbarheterna. Vid ett pentest tar du dig längre in i systemet för att se samband och få en djupare förståelse för business-logiken. När du förstår tankesättet i utvecklingen och uppsättningar av lösningar kommer du förmodligen hitta ytterligare brister eftersom den mänskliga faktorn aldrig går att bortse ifrån. Vi vet att människor gör fel när det kommer till installation, utveckling och hantering av system. Denna information skulle aldrig ett automatiserat skanningsverktyg kunna få fram eftersom den saknar det rationella tänkandet som vi människor har.
Ett exempel på detta är accesskontroll. Ett automatiserat webbapplikations-skanningsverktyg kan inte särskilja om det data den kan nå är att anse som en säkerhetsbrist eller inte, ifall en ’standardanvändare’ kan nå information som egentligen bara en administratör ska kunna nå så har du bristfälliga accesskontroller. Detta kan en människa avgöra genom att analysera data och vad som sker.
En kort berättelse av ett riktigt case:
"Ett av våra tidigare uppdrag innefattande ett webbapplikations-pentest på en applikation som var nåbar på Internet och det visade sig att den hade en mängd sårbarheter, bland annat oautentiserad SQL injektion. Sårbarheten gjorde att man kunde läsa data från databasen, så som användare och hashar. Efter djupare analys visade det sig att hasharna var manipulerade och när vi väl förstått hur, så kunde vi knäcka lösenorden, logga på webbapplikationen och ladda upp filer samt exekvera kod på deras webbserver.
Från webbservern fick vi full access till hela produktionsnätet vilket möjliggjorde åtkomst av domänkontrollanterna. En av dessa hade ett flertal sårbarheter och trots att den var ersatt med en ny domänkontrollant och domän användes denna fortfarande för den äldre domänen. Den äldre och nya domänen hade two-way trust vilket betyder att oavsett om du har ett konto i den ena domänen har du tillgång till resurser i den andra. På grund av en kombination av bristfällig konfiguration, direkta fel i mjukvara, avsaknad av logisk separation mellan externt exponerade och interna system, samt att kunden inte helt avvecklat den äldre domänen kunde vi komma så pass långt in i företagets nätverk och system."
Skillnaden om man bara hade gjort en sårbarhetsskanning mot applikationen och inte ett penetrationstest så hade man i bästa fall hittat att det fanns en SQL injection men inte de resterande bristerna.
Ett problem som är vanligt hos företag är att de endast ser dessa tester som en del av en process som ligger till grund utifrån krav som till exempel PCI-DSS eller GDPR. När företaget väl fått bukt på sina röda (högrisk) och lila (kritiska) markeringar i sin rapport så ser de jobbet som klart. Det anses inte lika viktigt vad man sedan gör med resultaten, fokus ligger på att checka av kravet.
Det finns en fara i att enbart göra en sårbarhetsskanning eller ett pentest med en slags ’check box-approach’. Det är nämligen så att i många utav fallen ser oftast miljöerna likadana ut året efter och samma sårbarheter och konfigurationsfel finns fortfarande kvar. Samma tester körs som visar på samma sårbarheter vilket gör att mognadsgraden ökar med 0%. Som i exemplet med webbapplikationen ovan - hade företaget enbart gjort testerna utan att agera på resultatet hade det kunnat sluta illa.
Bättre kommunikation och förståelse av testerna och resultaten skulle kunna lösa detta problem. Säkerhet är inte lätt att förstå vilket gör det ännu viktigare att verkligen se till att gå igenom rapporter ordentligt och ta hjälp med att tydliggöra innehållet. Förstår du inte innebörden i resultaten är det svårt att ta action.
Har du inte en tydlig bild över hur säkerheten ser ut i era olika system så vet du inte heller vilka sårbarheter som finns och hur långt in i systemen en utomstående person kan ta sig. Så länge den bilden är otydlig finns det alltid en risk för att ni kan bli utsatta för intrång. Det i sin tur kan orsaka kostsamma förluster för er som företag. Inte bara i form av pengar utan även i anseende och arbete med att reparera skadan. Vågar du verkligen ta den risken?
För att göra det enkelt kan man tänka att sårbarhetskanning är första nivån och pentest nästa. Skanningen är förstadiet till pentest utan den mänskliga aspekten på det hela. Den ligger som en grund och tar fram de existerande kända sårbarheterna. Efter grundarbetet behöver du titta djupare för att förstå hur utvecklare och administrationen satt upp systemen, se samband och säkerställa att ni inte har några gömda dörrar in.
Om ert säkerhetsarbete idag är bristfälligt och ni inte har kontroll över det ni exponerar ut mot internet så löper ni en högre risk för att personer med avsikt att ta kontroll över er infrastruktur eller ta ert data får obehörig åtkomst. Därför är det viktigt att löpande göra tester och agera utifrån testernas resultat. Sluta se det som ett krav som måste genomföras och börja se det som ett långsiktigt arbete till ett säkrare system och miljö.