Ett penetrationstest behöver börja med ett avgränsat uppdrag: vad som får testas, vilken fråga testet ska besvara och när testaren måste stanna. Beställningen ska också ange hur fynd lämnas, vem som rättar dem och hur rättningen kontrolleras. Annars kan resultatet bli en rapport som varken visar rätt risker eller leder till bättre säkerhet.
Den här guiden hjälper en systemägare att skriva ett användbart uppdragsunderlag för ett auktoriserat test. Den innehåller ett ifyllt exempel för en kundportal och en mall för att följa ett fynd till verifierad åtgärd. Den praktiska säkerhetsplanen bör samtidigt omfatta grundläggande IT-säkerhet, så att testet blir en del av löpande förvaltning.
Vad ett penetrationstest kan visa
Ett penetrationstest är en avgränsad undersökning där testaren prövar säkerhetsbrister och möjliga konsekvenser inom ett godkänt uppdrag. En sårbarhetsskanning kan ge ett brett automatiserat underlag, medan en manuell prövning ofta behövs för att förstå exempelvis fel i affärslogik eller åtkomst mellan användarroller. Metoderna kan komplettera varandra.
Ett test utan fynd bevisar inte att systemet saknar sårbarheter. Resultatet beror på tid, omfattning, behörigheter, information och miljö. Begär därför att rapporten beskriver vad som undersökts, vad som inte kunnat kontrolleras och vilka begränsningar som påverkar slutsatsen. OWASP:s Web Security Testing Guide ger en referens för systematisk granskning av webbapplikationer; välj relevanta delar för just er tjänst. OWASP: Web Security Testing Guide.
Artikel 32 GDPR kräver ett förfarande för regelbunden prövning av säkerhetsåtgärdernas effektivitet. Penetrationstest kan vara en del av det förfarandet, men artikeln anger inte att varje svenskt företag måste beställa samma test två gånger per år. Om sektorsregler eller avtal gäller behöver de prövas separat. GDPR: artikel 32.
1. Välj den fråga som ska besvaras
Utgå från vad en person kan förlora om skyddet brister. Kan en kund läsa en annan kunds bilagor? Kan ett avslutat konto återfå åtkomst? Kan en vanlig användare utföra en administrativ ändring? Frågan behöver kopplas till ett faktiskt dataflöde och en relevant användarroll.
Använd systemkartan för att välja mål och beroenden. Om portalen hämtar data från ett API behöver beställaren veta om API:et ingår. Ett test som bara omfattar den publika startsidan svarar inte på frågor om inloggade kunders åtkomst.
Skilj också mellan en konfigurationsgranskning, ett applikationstest och ett bredare test av organisationens förmåga att upptäcka angrepp. De kräver olika förberedelser. Låt leverantören förklara hur den föreslagna metoden besvarar er fråga och vilka förutsättningar som måste finnas.
2. Säkerställ behörigt tillstånd och tydliga gränser
Dokumentera tillståndet före teststart. Den som godkänner behöver kunna förfoga över den aktuella miljön och de åtgärder som tillåts. Kontrollera villkor för molnplattform, driftleverantör och andra berörda tjänster; tillåtelse från kunden täcker inte automatiskt alla underliggande system eller andra kunders miljöer.
Olovlig åtkomst till uppgifter för automatiserad behandling och vissa andra olovliga åtgärder kan utgöra dataintrång enligt 4 kap. 9 c § brottsbalken. Ett väl beskrivet uppdrag ska därför visa både vilka system och vilka metoder som omfattas av tillståndet. Avtalet ger inte rätt att gå utanför vad beställaren faktiskt kan godkänna. Riksdagen: brottsbalken.
Skriv mål med exakta identifierare, miljö och tidsfönster. Ange uttryckligen om testet får omfatta produktionssystem, kontolåsning, social manipulation, fysiskt tillträde eller belastning som kan störa tjänsten. Om en metod inte ingår ska den stå som undantagen, inte lämnas till muntliga antaganden.
3. Ifylld beställning för en kundportal
Exemplet nedan är fiktivt. Det gäller ett företag som vill kontrollera åtkomst mellan två kundorganisationer efter en ändring av portalens behörighetsmodell. Exempeladresserna och tiderna ska ersättas i ett verkligt uppdrag.
| Del av uppdraget | Beslut i exemplet |
|---|---|
| Huvudfråga | Kan en inloggad användare nå en annan kundorganisations ärenden eller bilagor? |
| Miljö | Godkänd testmiljö på portal.example och det dokumenterade API som används av portalen |
| Underlag | Systemöversikt, rollbeskrivning och syntetiska ärenden i två separata kundorganisationer |
| Konton | Ett vanligt kundkonto och ett kundadministratörskonto per organisation; inga verkliga kundkonton |
| Tillåtna moment | Avgränsad manuell granskning av inloggning, sessionshantering och åtkomstkontroller inom målen |
| Undantagna moment | Produktionssystem, belastningstest, social manipulation och åtkomst till andra leverantörers gränssnitt |
| Startvillkor | Kontaktpersoner nåbara, återställning förberedd och systemägaren har bekräftat mål och datamängd |
| Stoppvillkor | Oväntade verkliga personuppgifter, påverkan utanför testmiljön eller tecken på pågående verkligt angrepp |
| Leverans | Omedelbar säker kontakt vid kritiskt fynd, därefter rapport med omfattning, bevis och åtgärdsförslag |
| Återkontroll | Rättade åtkomstfel prövas med samma relevanta roller och närliggande funktioner före avslut |
Beställningen kan behöva kompletteras om testmiljön skiljer sig från produktion. Dokumentera vilka delar av konfigurationen och behörighetsmodellen som motsvarar verklig drift. Om skillnaderna är avgörande ska rapporten inte påstå att hela produktionsmiljön har verifierats.
4. Förbered kontaktvägar, data och återställning
Utse en beställaransvarig, en teknisk kontakt och någon som kan stoppa eller återställa miljön. Bestäm hur testaren når dem under hela det godkända tidsfönstret. Öva kontaktvägen innan start när konsekvenserna av ett missförstånd kan bli stora.
Använd syntetiska data när de ger tillräckligt realistiska förutsättningar. Om verkliga personuppgifter ändå behöver behandlas ska omfattning, rättsligt stöd, åtkomst, överföring och radering bedömas. Reglera leverantörens roll utifrån den faktiska behandlingen; ett sekretessavtal ersätter inte ett nödvändigt personuppgiftsbiträdesavtal.
Bestäm hur bevis ska sparas. En skärmbild med en fullständig kundakt kan vara mer ingripande än det som behövs för att visa ett åtkomstfel. Begär minsta tillräckliga bevis, säker överföring och begränsad åtkomst till rapporten. Skriv också hur testkonton, tillfälliga rättigheter och material hos leverantören ska avslutas.
NIST SP 800-115, publicerad 2008, är en metodreferens för planering, genomförande och hantering av säkerhetsbedömningar. Den kan stödja strukturen för ett uppdrag och reglerna för genomförandet, men är inte svensk lag eller en aktuell produktkonfiguration. NIST: Technical Guide to Information Security Testing and Assessment.
5. Kräv en rapport som går att använda
För varje fynd behöver rapporten beskriva berörd funktion, nödvändiga förutsättningar, möjlig konsekvens och tillräckligt underlag för att ansvarig utvecklare ska förstå felet. Ett numeriskt allvarlighetsvärde kan hjälpa prioriteringen, men behöver kombineras med verksamhetens data och exponering.
Be också om en redovisning av täckning. Vilka roller prövades? Vilka delar av API:et ingick? Var någon funktion otillgänglig? En sammanfattning som säger ”inga kritiska sårbarheter” måste läsas tillsammans med dessa begränsningar.
Skilj verifierade fynd från misstänkta brister och förbättringsförslag. Leverantören ska inte behöva samla in stora datamängder eller orsaka onödig skada för att bevisa maximal konsekvens. Avtala hur en risk kan bekräftas på ett begränsat sätt och när beställaren behöver besluta om en fördjupning.
6. Följ fyndet till en verifierad rättning
Ett ifyllt åtgärdsärende kan se ut så här: ”Fynd P-03: användare i kundorganisation A kunde se metadata för ett syntetiskt ärende i B. Utvecklingsansvarig rättar serverns åtkomstkontroll. Systemägaren begränsar den berörda funktionen tills rättningen är införd. Återkontroll ska visa att åtkomst nekas för fel organisation och fortsatt fungerar för rätt organisation.”
Lägg till ansvarig, intern tidsplan, tillfällig riskhantering och hur beslutet följs upp. Tidsplanen ska bygga på fyndets risk, inte en generell artikel som hävdar att alla kritiska fel alltid har samma lagstadgade frist. Om rättningen kräver en större förändring behöver den ansvarige kunna förklara hur risken hanteras under tiden.
Kontrollera även närliggande funktioner. Ett fel i en behörighetsregel kan finnas i både visning, export och bilagehämtning. Ett enskilt lyckat återtest av visningen visar inte att resten av samma felmönster är borta. Koppla relevanta ändringar till säkerhetsbilagan och härdningsarbetet.
7. Avsluta åtkomst och behåll rätt lärdomar
När uppdraget är klart ska testkonton stängas, tillfälliga tillstånd tas bort och material hanteras enligt överenskommelsen. Bekräfta att testet inte lämnat kvar en alternativ åtkomstväg. Spara det underlag som behövs för åtgärder och uppföljning med begränsad åtkomst.
Koppla fynd om inloggning, kryptering eller övervakning till respektive rutin. Exempelvis bör ett TLS-fynd följas upp i kontrollen av TLS och certifikat, medan bristande upptäckt kan påverka säkerhetsloggningen. Nästa uppdrag kan då utgå från tidigare resultat och de förändringar som faktiskt har införts.
Vanliga frågor
Hur jämför vi offerter utan att ha en färdig prisbild?
Ge leverantörerna samma mål, roller, miljöer och förväntade leveranser. Be dem ange vad som ingår, vilka antaganden priset bygger på och om rapportgenomgång och återkontroll omfattas. Ett lägre pris kan annars avse ett helt annat testomfång.
Räcker en automatisk skanning?
Det beror på frågan. En skanning kan hitta kända brister men behöver ofta kompletteras för behörigheter och affärslogik. Be leverantören visa hur metoden täcker er konkreta risk, och dokumentera det som återstår oprövat.
Ska vi testa efter varje ändring?
Anpassa kontrollen till vad som ändras och hur risken påverkas. En ny autentiseringslösning eller åtkomstmodell kan motivera en fördjupad prövning. Mindre förändringar kan hanteras med andra relevanta kontroller. Planera regelbunden bedömning utan att likställa alla förändringar eller kalla ett intervall i ett exempel för lagkrav.