Vad är ett penetrationstest?

Penetrationstest, ofta kallat pentest, låter dramatiskt, och på sätt och vis är det just det: ett inbrott man beställer själv. Men bakom det spännande ordet finns en av de mest handfasta säkerhetsåtgärder ett företag kan ta till. Här är vad ett penetrationstest är, hur det skiljer sig från enklare kontroller och när det bör göras.

Vad ett penetrationstest är

Ett penetrationstest är ett kontrollerat angrepp mot ett system, utfört av säkerhetsexperter som medvetet försöker ta sig in – precis som en riktig angripare skulle. Skillnaden är att de gör det på uppdrag, under överenskomna former, för att hitta svagheterna innan någon med onda avsikter gör det.

Bilden är ett inbrott på beställning. I stället för att vänta på att en tjuv ska hitta det olåsta fönstret, anlitar du någon som får i uppdrag att på riktigt försöka bryta sig in och sedan berätta exakt var och hur de lyckades. Målet är inte att orsaka skada, utan att avslöja bristerna medan de fortfarande går att laga i lugn och ro.

Testarna tänker och arbetar som angripare: de letar hål, provar sig fram och försöker kedja ihop små svagheter till en väg ända in. Det är den mänskliga uppfinningsrikedomen som gör testet värdefullt.

Skillnaden mot automatisk sårbarhetsskanning

Här är en åtskillnad som ofta blandas ihop. En sårbarhetsskanning är ett automatiskt verktyg som söker igenom systemet efter kända svagheter och listar det som ser misstänkt ut – snabbt, billigt och brett, men det stannar vid att peka på vad som kan vara fel. Ett penetrationstest går steget längre: människor försöker faktiskt utnyttja hålen och bevisa vad en angripare verkligen skulle kunna åstadkomma. Skanningen ger en lista med misstankar, testet ger bevis och sammanhang. De två kompletterar varandra snarare än ersätter.

Vad rapporten ger dig

Värdet av ett penetrationstest ligger till stor del i vad du får ut på slutet: en rapport som gör säkerhetsläget begripligt och åtgärdbart. Den nöjer sig inte med att lista misstänkta svagheter, utan levererar bevisade hål satta i sitt sammanhang.

• Bevisade sårbarheter. Varje brist beskrivs med hur den utnyttjades, inte bara att den kanske finns.
• Konsekvens. Vad det skulle betyda om en angripare tog sig in just där – vilka uppgifter eller funktioner som stod på spel.
• Riskrangordning. Hålen sorteras efter allvar, så att det farligaste hamnar högst och ni vet var ni ska börja.
• Åtgärdsförslag. Konkreta råd om hur varje brist täpps till.

Resultatet blir i praktiken en prioriterad att-göra-lista för säkerheten, där ni kan ta det allvarligaste först i stället för att gissa.

Ett konkret scenario

Säg att ett bolag ska lansera en ny tjänst där kunder loggar in och lämnar personuppgifter och betalkortsuppgifter. Innan lanseringen beställer de ett penetrationstest.

Testarna hittar att en till synes harmlös svaghet i inloggningen, i kombination med en felkonfigurerad behörighet, går att kedja ihop till att nå andra användares uppgifter. En automatisk skanning hade kanske flaggat de två sakerna var för sig som lågt prioriterade – men det var kombinationen, som bara en tänkande angripare hittar, som var farlig. Bolaget får detta svart på vitt, med hög prioritet och åtgärdsförslag, och hinner laga hålet före lansering. Alternativet hade varit att en riktig angripare gjort samma upptäckt efteråt, med skarpa kunduppgifter i kläm.

När det bör göras

Tidpunkten spelar roll. Ett penetrationstest är mest angeläget:

• Före lansering av tjänster som hanterar känsliga uppgifter, betalningar eller andra värden värda att skydda. Bättre att hitta hålen innan tjänsten möter verkligheten.
• Regelbundet därefter. Ett system står inte still: ny funktion tillkommer, beroenden uppdateras och nya hot uppstår. Ett test speglar läget vid ett givet tillfälle och är därför en färskvara, inte en engångsstämpel. Många återkommer inför större releaser och med jämna mellanrum.

Så förhåller du dig till det

Se penetrationstestet som en återkommande hälsokontroll av säkerheten snarare än ett intyg på att allt är tryggt för gott. Det avslöjar brister medan de går att laga, men ersätter inte det löpande säkerhetsarbetet med uppdateringar, behörigheter och medvetna medarbetare.

Planerar ni att lansera något som hanterar känsliga uppgifter, är det värt att bygga in säkerhet – och testning av den – från början. Vill ni ha hjälp att göra det på rätt sätt, tar vi på Weapp gärna med säkerhetsarbetet i systemarbetet redan från start.