02 / AI-driven penetrationstestning

AI-driven testning.
Förstå riskerna.

AI-driven penetrationstestning av webbapplikationer och API:er. AI hjälper oss att undersöka möjliga angreppsvägar inom den avtalade testomfattningen. Våra specialister styr testerna, validerar fynd och bedömer konsekvenserna.

01Webbapplikationer och API:er
02Överenskomna mål och testregler
03Validering och dokumenterad påverkan
Det här granskar vi

Angreppsvägar som
betyder något för er.

Vi börjar med viktiga data och funktioner och väljer kontroller som passar systemet och uppdragets mål.

01

Åtkomst mellan kunder

Åtkomst till enskilda objekt och isolering mellan kunder: kan en användare läsa eller ändra en annan kunds information?

02

Roller och administration

Kan en vanlig användare nå funktioner som ska kräva högre behörighet?

03

Inloggning och sessioner

Hur inloggning, åtkomsttoken och sessioner fungerar, från inloggning till utloggning och utgången giltighetstid.

04

Affärslogik och dataflöden

Flöden där ett tekniskt giltigt anrop kan kringgå en regel, röja information eller orsaka oavsedd påverkan.

05

Indata och API-anrop

Relevanta tester av hur anrop, parametrar, filer och externa referenser behandlas.

06

Exponering och konfiguration

Inställningar som kan kontrolleras utifrån, felmeddelanden och åtkomliga gränssnitt. Infrastrukturtester läggs till när de uttryckligen ingår.

Aktiva tester kräver godkänd omfattning och regler för testningen. Skrivtester, belastningsprov, externa tjänster för att registrera återanrop och produktionspåverkan ingår bara när de är uttryckligen avtalade.

Er leverans

Resultat som går
att agera på.

Ett testresultat ska förklara vad som faktiskt visades, varför det spelar roll och vad som återstår. En namngiven bedömare står för bedömningen.

  • Bedömning för tekniska team och ledningPrioriterade fynd och en sammanfattning av de konsekvenser som testerna har visat.
  • Teststeg som går att upprepaRelevanta teststeg och bevis för validerade fynd, med hänsyn till känslig information.
  • Tydlig redovisning av testomfattningenVad som testades, vilka kontroller som inte gav ett entydigt resultat och vad som låg utanför uppdraget.
  • Åtgärder och kriterier för omtestRekommendationer och ett tydligt förväntat resultat när samma brist kontrolleras igen.
EXEMPEL / OBJEKTBEHÖRIGHET

Samma objekt.
Två olika identiteter.

Ägare → 200 · förväntad åtkomst
Annan kund → 200 · objektet returneras
Anonym → 401 · nekad åtkomst
VALIDERINGKontrollera vem objektet tillhör och vem som ska få läsa det. En HTTP-status räcker inte som bevis.
VERIFIERAS ÅTGÄRDAT NÄRAnnan kund nekas objektet, medan ägaren fortfarande får avsedd åtkomst.

SYNTETISKT EXEMPEL — INTE ETT KUNDRESULTAT

Så går det till

Från säkerhetsfråga till verifierat resultat.

01

Mål och tillstånd

Vi dokumenterar system, miljöer, testkonton, tillåtna aktiviteter och kontaktvägar.

02

Testa i rundor

Vi genomför kontroller och prövar utvalda angreppsvägar. Resultaten styr vad vi undersöker vidare.

03

Verifiera och bedöm

Vi kontrollerar åtkomstregler, underlag och konsekvenser och skiljer bekräftade brister från misstänkta brister.

04

Leverera och följ upp

Resultatet gås igenom. Efter åtgärder kan ett avgränsat omtest beställas.

Bra att veta

Inför ert
första uppdrag.

Behöver ni tillgång till källkoden?

Ett penetrationstest kan genomföras utan källkod. Kodåtkomst kan ge ytterligare förståelse när det ingår; en separat kodgranskning kan också kombineras med testningen.

Kan ni testa i produktion?

Testmiljö väljs tillsammans. Produktion kräver uttrycklig överenskommelse om aktiviteter, risker, tidpunkter och regler för att avbryta testningen.

Är testet en engångsinsats eller löpande?

Båda uppläggen kan avtalas. En avgränsad granskning passar inför lansering. Styrkan i vårt arbetssätt är dock löpande testning: bekräftade fynd blir återkörbara kontroller som kan köras vid varje release, så att en ändring som återinför en brist upptäcks tidigt och ni ser en trend över tid.

Ingår ett omtest?

Omfattning och pris för omtest ska framgå av förslaget. Omtestet prövar åtgärdernas effekt mot dokumenterade kriterier; det är ingen garanti för att hela systemet är säkert.

Stödjer testningen DORA och andra krav?

Ja. Bedömningen, bevisunderlaget och omtest-spåret blir en del av det underlag ni behöver för t.ex. DORA (ICT-risk och operativ motståndskraft), NIS2 och ISO 27001. En namngiven bedömare står för resultatet; det är underlag och bedömning, inte en formell certifiering.

Ta nästa steg

Vilka angrepp behöver
ert system stå emot?

Berätta om systemet, de viktigaste tillgångarna och er tidsplan.