Slik leser du en sikkerhetsrapport

Ikke begynn på funn nummer én. Begynn med å finne ut hva som faktisk ble undersøkt, ellers vurderer du en liste uten å vite hva den er en liste over.

Leser du funnene først, blir det høyeste tallet det du husker, og det høyeste tallet er ikke nødvendigvis det som betyr mest hos dere.

Leser du dekningen først, vet du med en gang om «ingen funn» i et område betyr at det ble undersøkt og var i orden, eller at det aldri ble nådd. De to ser helt like ut i en ren funnliste, og bare den ene er en god nyhet.

De fleste rapporter oppgir CVSS, en skala fra 0 til 10 som beskriver hvor alvorlig en sårbarhet er i seg selv. FIRST, som forvalter standarden, skriver selv at grunnskåren «should not be used alone to assess risk», og at den «represents only the intrinsic characteristics of a vulnerability and is independent of any factor associated with threat or the computing environment».

Med andre ord vet tallet ingenting om dere. Det vet ikke om systemet er nåbart fra internett, hva som ligger i det, om noen utnytter sårbarheten ute i verden i dag, eller hva det koster å fikse.

Standarden har egne deler for nettopp dette, Environmental og Threat, som justerer skåren etter miljø og trusselbilde. En rapport som bare oppgir grunnskåren har oppgitt et tall som gjelder alle, ikke dere, så det er verdt å spørre om de to andre er vurdert.

Fem spørsmål som flytter et funn opp eller ned, uavhengig av hvilket tall som står ved siden av det.

Still dem til den som skrev rapporten. Det er en del av leveransen og ikke en klage, og svarene er det som gjør listen om til en plan.

Den som ikke kan svare på spørsmål én og tre om sitt eget funn, har ikke bekreftet det. Det er helt greit at et funn er en mistanke, så lenge rapporten sier at det er en mistanke. Det er ikke greit at en mistanke er presentert som en observasjon.

Spørsmål fire er det som oftest sparer penger. Mange alvorlige funn har et strakstiltak som tar en time og fjerner det meste av risikoen, mens den riktige løsningen tar et kvartal. Da kan begge deler planlegges, i stedet for at alt venter på den store fiksen.

Spørsmål fem er det som skiller en rapport fra en jobb som er gjort. Uten etterprøving vet dere at noe var galt, ikke at det er rettet.

Begge deler hører hjemme i en rapport. Automatiske verktøy finner ting mennesker overser, og en rapport uten dem er dårligere. Forskjellen er at et verktøyfunn er en påstand, mens et bekreftet funn er en observasjon, og de skal ikke leses likt.

Tegn på at et funn er kopiert rett fra et verktøy:

Funnet navngir deres endepunkt, deres felt eller deres id. Dokumentasjonen inneholder forespørselen og svaret. Det står hvorfor nettopp deres oppsett gjør det mulig, og ikke bare hva sårbarhetsklassen heter. Tiltaket peker på noe konkret hos dere.

Og det mest talende: falske positive står oppført som avvist, med en begrunnelse. Noen har altså gått gjennom det verktøyene foreslo og tatt stilling til hvert punkt. En rapport som bare tar med det som ser ut som funn, har hoppet over den jobben.

Vil du ha noe å sammenligne med, ligger eksempelrapporten på denne siden. Der står funnene med forespørsel og svar, og vedlegget skiller mellom kjente CVE-er i det som er i bruk og de som er sjekket og avvist.

Den delen leses sjelden, og den er den eneste som svarer på om sikkerhetsarbeidet dere allerede betaler for virker.

Et forsøk som ble stoppet er et resultat. Ble noe stanset, er det verdt å vite hvorfor og av hvilken kontroll, og kom testeren rundt kontrollen likevel, er det enda mer verdt å vite.

En rapport som bare lister det som gikk galt gir deg ingenting å måle mot senere, og ingenting å svare kunder med. Det er en rimelig ting å be om, også i ettertid.

«Ingen funn» i et område som aldri ble nådd er ikke et resultat. Før du bestemmer noe, finn ut av dette:

En rapport som blir liggende som en PDF er penger brukt på å vite noe man ikke gjorde noe med. Det som skiller de som får verdi ut av en test fra de som ikke gjør det, er de neste to ukene.

Rapporten beskriver hvordan man kommer inn hos dere. Den skal ha samme tilgangsstyring som systemene den handler om, og den skal ikke ligge i en delt mappe alle når.

Dukker det opp et passord, en nøkkel, et token eller en tilgangsstreng i dokumentasjonen, skal den byttes ut. Ikke sladdes, ikke noteres som noe å se på senere.

Den er nå skrevet ned i et dokument som sendes rundt, lagres flere steder og sannsynligvis skrives ut minst én gang, uansett hvor forsiktige dere er. Rotasjon tar minutter. Alternativet er å håpe.

Mye av det som ser ut som standard i en sikkerhetsrapport er konvensjon, ikke krav.

Den eksterne sjekken leser det som er synlig utenfra og gir dere funnene med en gang, uten innlogging og uten e-postadresse.