Penetrationstest eller sårbarhetsskanning: vad är skillnaden?

En skanner arbetar mot en lista. Den känner igen en version med känd sårbarhet, en felkonfiguration som matchar ett mönster, ett certifikat som gått ut. Det gör den bra på bredd och snabbhet, och den bör köras ofta av just det skälet.

Det den inte kan se är fel som bara existerar i förhållande till er verksamhet. Att en användare kan läsa en annan användares faktura genom att räkna upp ett id är inte en känd sårbarhet i något system, det är ett behörighetsfel i er logik. Ingen signaturdatabas innehåller det.

Den andra blinda fläcken är kombinationen. Ett läckt versionsnummer, ett vidöppet testkonto och en intern tjänst som litar på nätverket är var för sig lågprioriterade fynd. Tillsammans är de en väg in. Skannern rapporterar tre trior; testet rapporterar en femma.

Den som olovligen bereder sig tillgång till en uppgift som är avsedd för automatiserad behandling döms för dataintrång till böter eller fängelse i högst två år.

Skanning hör hemma i driften. Den ska vara automatiserad, köras minst veckovis, och dess utdata ska hamna i samma flöde som annan drifthantering. Poängen är tidsavstånd: en känd sårbarhet som publicerades i går ska inte upptäckas vid nästa årliga test.

Test hör hemma vid beslutstillfällen. Innan en ny tjänst går i produktion, efter en större arkitekturförändring, inför en upphandling där ni ska kunna visa något, eller när ni behöver underlag för att bedöma om åtgärderna faktiskt fungerar.

Den vanligaste feltajmingen är att beställa test för att kompensera för att skanning saknas. Då används dyr manuell tid till att hitta det ett verktyg hade hittat gratis, och de svåra fynden hinner aldrig göras.

Det finns ett kommersiellt gränsland där automatiserad skanning säljs som penetrationstest. Det är sällan uttalat bedrägeri; det är oftare en gradvis glidning där verifieringssteget tunnas ut tills det inte finns kvar.

Kännetecknen är konkreta. Rapporten innehåller ovanligt många fynd. Allvarsgraderna ser ut som verktygets standardnivåer snarare än som en bedömning av er miljö. Fynden saknar reproduktionssteg. Och ingen angreppsväg beskrivs, bara enskilda punkter.

Ett enkelt test vid utvärderingen: be om ett exempel på ett fynd som verktygen flaggade och som leverantören sedan avfärdade som falskt positivt, med motiveringen. En leverantör som verifierar har flera sådana. En som inte gör det har inga.

Varken cybersäkerhetslagen eller NIS2 föreskriver ett verktyg. Kravet i 2 kap. 3 § punkt 6 avser strategier för att bedöma om åtgärderna är effektiva, och det är bedömningen som ska gå att visa, inte kvittot på ett verktyg.

Praktiskt betyder det att både skanning och test kan vara delar av samma argument, och att argumentet är starkare när det framgår varför just den kombinationen valdes. Skriv ned den motiveringen samtidigt som ni fattar beslutet, inte i efterhand när någon frågar.