Deutsch English French Swedish
KONTAKTA OSS
KONTAKTA OSS
Deutsch English French

AI-driven testning

Kvalitetssäkringsteknik

SAP QA-migrering

Cybersäkerhets- och sårbarhetsbedömning

Finansiella tjänster och bankverksamhet

QESTIT Cybersecurity

QESTIT Academy

QESTIT Systems

Bloggar

Fallstudier

Vita papper

Webinar och evenemang

Nyheter & Press

Om QESTIT

Certifieringar och partners

QESTIT referenser
Buntar

Livet på QESTIT

Lediga jobb
KONTAKTA OSS
move-left Back
🌍 All Regions
Quality Assurance Engineering

Skillnader mellan sårbarhetsskanning och penetrationstestning

I dagens digitala värld blir det allt viktigare att se till att ditt företags samlade information inte kan hittas och komma i händerna på andra. Därför bör du kontinuerligt arbeta för att förbättra säkerheten genom att genomföra tester för att upptäcka eventuella sårbarheter. Vi vet att informationssäkerhet kan vara komplicerat, så i den här artikeln kommer jag att förklara skillnaden mellan sårbarhetsskanning och penetrationstestning. Jag hoppas att det ger dig en bättre förståelse för testerna och deras betydelse för din verksamhet.

Sårbarhetsskanning

Sårbarhetsskanning är helt automatiserad – du anger bara vilka tillgångar som ska skannas. Du talar om för systemet vad det ska leta efter, och sedan sker allt automatiskt. Genom att regelbundet utföra sårbarhetsskanningar får du en bra överblick över din mognadsnivå, till exempel vid varje release. Om du släpper nya versioner varje vecka kan det vara klokt att investera i ett dynamiskt eller statiskt sårbarhetsverktyg.

Vid sårbarhetsskanning letar systemet aktivt efter konfigurationsfel eller sårbarheter baserat på brister eller faktiska fel i programvara, server, klient, switch, router osv. Ofta handlar det om ett grundläggande problem i koden – antingen har du gjort något utan att veta om det, eller så har du utelämnat något, t.ex. i konfigurationen.

Den största fördelen med en automatiserad skanning är att du kan hitta många av de ”lågt hängande frukterna”, såsom bristfällig autentisering, cross-site scripting (XSS) eller andra typer av injektioner. Det är en bra början.

Exempel på de vanligaste sårbarheterna i webbapplikationer finns bland annat i OWASP: s (Open Web Application Security Project) topp 10-lista eller i Sans Top 25.

Penetrationstestning

Penetrationstestning, även kallat pentest, är ett manuellt arbete. Här går man djupare än att bara kontrollera befintliga sårbarheter. Med ett pentest tar man sig längre in i systemet för att se kopplingar och få en djupare förståelse för affärslogiken. När man förstår tankesättet bakom utvecklingen och lösningarna kommer man troligen att hitta ytterligare brister, eftersom den mänskliga faktorn aldrig kan ignoreras. Vi vet att människor gör misstag när det gäller installation, utveckling och hantering av system. Denna information skulle aldrig kunna upptäckas av ett automatiserat skanningsverktyg, eftersom det saknar det rationella tänkande som vi människor besitter.

Ett exempel på detta är åtkomstkontroll. Ett automatiserat skanningsverktyg för webbapplikationer kan inte avgöra om de data det får åtkomst till ska betraktas som ett säkerhetsintrång eller inte. Om en ”vanlig användare” kan komma åt information som endast en administratör borde ha åtkomst till, innebär det att åtkomstkontrollen är bristfällig. En människa kan avgöra detta genom att analysera data och vad som händer.

En kort berättelse om ett verkligt fall:

”I ett av våra tidigare uppdrag utförde vi penetrationstest på en webbapplikation som var tillgänglig via internet och vi upptäckte ett antal sårbarheter, däribland oautentiserad SQL-injektion. Sårbarheten gjorde det möjligt att läsa data från databasen, såsom användare och hashvärden. Efter en djupare analys visade det sig att hashvärdena hade manipulerats, och när vi väl förstod hur det gick till kunde vi knäcka lösenorden, logga in på webbapplikationen, ladda upp filer och köra kod på deras webbserver.”

Från webbservern fick vi full åtkomst till hela produktionsnätverket, vilket möjliggjorde åtkomst via domänkontrollanterna. En av dessa hade flera sårbarheter och trots att den hade ersatts med en ny domänkontrollant och domän användes den fortfarande för den äldre domänen. Den gamla och den nya domänen hade ömsesidigt förtroende, vilket innebär att oavsett om man har ett konto i den ena domänen har man åtkomst till resurser i den andra. På grund av en kombination av dålig konfiguration, direkta fel i programvaran, brist på logisk åtskillnad mellan externt exponerade och interna system, samt att kunden inte helt avvecklat den äldre domänen, kunde vi ta oss så här långt in i företagets nätverk och system.”

Om ni endast hade utfört en sårbarhetsskanning av applikationen och inte någon penetrationsprovning, skulle ni i bästa fall ha upptäckt att det fanns en SQL-injektion, men inte de övriga bristerna.

Återkommande problem som vi ser hos företag

Ett vanligt problem inom företag är att de endast ser dessa tester som en del av en process baserad på krav såsom PCI-DSS eller GDPR. Så snart företaget har åtgärdat de röda (hög risk) och lila (kritiska) markeringarna i sin rapport anser de att jobbet är klart. Det anses inte vara viktigt vad man gör med resultaten, fokus ligger på att bocka av kraven.

Det finns en risk i att helt enkelt utföra en sårbarhetsskanning eller ett penetrationstest med en slags ”kryssa i rutan”-strategi. Faktum är att miljöerna i många fall oftast ser likadana ut året efter och att samma sårbarheter och konfigurationsfel fortfarande finns kvar. Samma tester körs och visar samma sårbarheter, vilket innebär att mognadsnivån ökar med 0 %. Precis som i exemplet med webbapplikationen ovan – hade företaget endast genomfört testerna utan att vidta åtgärder utifrån resultaten, kunde det ha slutat illa.

Bättre kommunikation och förståelse för 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 rapporterna ordentligt och få hjälp med att förtydliga innehållet. Om man inte förstår innebörden av resultaten är det svårt att vidta åtgärder.

Risken med att inte genomföra en sårbarhetsskanning eller penetrationstest

Om du inte har en tydlig bild av hur säkerheten ser ut i dina olika system vet du inte heller vilka sårbarheter som finns och hur långt in i systemen en utomstående kan ta sig. Så länge den bilden är oklar finns det alltid en risk att du utsätts för intrång. Detta kan i sin tur orsaka extremt kostsamma förluster för dig som företag. Inte bara i form av pengar utan även vad gäller anseende och arbetet med att åtgärda skadan. Vågar du verkligen ta den risken?

Sammanfattningsvis

För att förenkla kan du tänka dig sårbarhetsskanning som den första nivån och penetrationstestning som nästa. Sökningen är en förberedelse inför penetrationstestning utan den mänskliga aspekten. Den fungerar som en grund och lyfter fram befintliga kända sårbarheter. Efter grundarbetet måste du gräva djupare för att förstå hur utvecklare och administratörer har konfigurerat systemen, se samband och säkerställa att det inte finns några dolda ingångar.

Om ditt säkerhetsarbete idag är bristfälligt och du inte har kontroll över vad du exponerar mot internet, löper du en högre risk att personer med avsikt att ta kontroll över din infrastruktur eller stjäla dina data får obehörig åtkomst. Därför är det viktigt att genomföra tester kontinuerligt och agera utifrån testresultaten. Sluta se det som ett krav som måste uppfyllas och börja istället betrakta det som ett långsiktigt arbete för ett säkrare system och en säkrare miljö.

Som vi sa vet vi att det kan vara svårt att få grepp om allt när det gäller IT-säkerhet. Därför har vi anordnat ett webbinarium med fokus på applikationssäkerhet där vi kommer att fördjupa oss i viktiga områden, såsom hur man integrerar säkerhet i utvecklingsprocessen, vilka de vanligaste attackerna är och när man bör välja öppen källkod. Anmäl dig genom att klicka på bilden.

Tags

Quality Assurance Engineering All Industries All Business Units