VPN-risikorapport ignorert? Skriv beslutningen, ikke scoren

Et risikonotat som ender med en alvorlighetsrangering, gir en leder en dom og ingen handling. Derfor kommer så mange av dem tilbake med «takk, notert» og ingenting annet. Notatene som blir godkjent, deler en form: én smal, kontrollerbar påstand, to navngitte alternativer med en pris, og én person som må svare innen en dato. Alt nedenfor handler om å lage den formen uten å overdrive det du vet.

Scoren svarer på et spørsmål ingen stilte

Aritmetikk med sannsynlighet ganger konsekvens gir et tall som sorterer funn mot hverandre. Det forteller ikke en direktør hva som skal signeres, og det inviterer til en diskusjon om multiplikatoren i stedet for en beslutning om gatewayen. Jeg har sett en eksponeringstall med to desimaler sluke et helt møte mens det egentlige spørsmålet — om oppgraderingen skal finansieres dette kvartalet — aldri ble stilt.

Det finnes bare noen få reelle beslutninger på dette området. Finansier oppgraderingen, godta en avgrenset eksponering til en oppgitt dato, eller begrens hvem som kan nå tjenesten. Hver har en annen eier og en annen kostnad, og ingen av dem er «reduser risikoen med 40 prosent».

Oppblåst alvorlighet gjør problemet verre. Når hvert funn er kritisk, slutter rangeringen å skille, og leseren faller tilbake på det eneste signalet som er igjen, nemlig hvem som klaget høyest. Et notat som sier at utgivelsen er utenfor støtte, at dette er andre kvartal den er utenfor støtte, og at en bestemt gruppe ansatte er avhengig av den, er langt mer handlingsrettet enn et rødt merke.

Uklarhet er den andre feilen. «VPN-et er usikkert» kan ikke løses, fordi det ikke sier hvilken utrulling, hvilken versjon eller hvem som kan nå hva. En setning leseren kan kontrollere, er den minste enheten i en nyttig rapport.

Krymp påstanden til noen kan kontrollere den

Forankre påstanden i en publisert grense i stedet for i en mening. Utenfor leverandørens støtte, et manglende påkrevd autentiseringstrinn eller tilgjengelighet fra et nettverkssegment som ikke burde se det, er alle påstander med en test bak seg. For det første er testen tre kommandoer på gatewayen selv:

openvpn --version | head -n 1
dpkg-query -W -f='${Version}\n' openvpn
openssl x509 -in /etc/openvpn/server.crt -noout -enddate

Versjonslinjen og pakkespørringen stemmer vanligvis overens, og når de ikke gjør det, har du funnet et andre problem som fortjener en egen rapport. Sertifikatets utløpsdato er feltet folk glemmer å kontrollere til klientene ikke får koblet til, og det hører i samme dokumentasjonsvedlegg som versjonsstrengen.

Noter hvor hver utdata kom fra og når den ble hentet. Et notat som sier «gateway gw1, samlet tirsdag», kan en skeptiker kjøre på nytt; et skjermbilde beskåret til den interessante linjen kan ikke. Fjern nøkler, private adresser og kontonavn før filen forlater maskinen din.

Skriv notatet som et valg mellom navngitte alternativer

Et beslutningsnotat er kort fordi det gjør én jobb. Dette er formen jeg bruker, fylt ut for en oppdiktet mellomstor organisasjon hvis fjernaksessutgivelse gikk ut av støtte:

Ask: approve one of two upgrade paths for remote access before 30 June.
Claim: gw1 runs a release that left vendor support in January.
Evidence: version output and vendor notice, attached, collected 14 March.
Option A: upgrade in place, one maintenance window, staff on the current client build.
Option B: replace the gateway, two windows, client reinstall for 180 staff.
Cost of waiting: no security fixes for a service 180 staff use daily.
Owner: platform team. Decision needed from: IT director, by 28 March.

Hver linje fortjener plassen sin. Forespørselen er én setning og inneholder en dato. Påstanden kan kontrolleres. Alternativ B finnes for at alternativ A skal være et valg og ikke en formalitet, og det nevner nyinstallasjonen av klienten fordi det er kostnaden folk undervurderer. Kostnaden ved å vente beskriver en konsekvens, ikke en sannsynlighet.

Det notatet ikke må gjøre, er å smugle inn en konklusjon du ikke kan støtte. Hvis ingen kompromittering er påvist, si det på én linje, fordi en leser som senere oppdager en overdrivelse, også vil diskontere de neste tre notatene dine.

Hva aksepten av risikoen må inneholde

Aksept er ikke fravær av en beslutning og ikke stillhet. Hvis svaret er å leve med eksponeringen en stund, trenger notatet tre tillegg: en sluttdato, et overvåkningstrinn som noen faktisk utfører, og en navngitt person som åpner spørsmålet igjen når datoen kommer.

En midlertidig kontroll trenger samme behandling. Å begrense tjenesten til en mindre gruppe reduserer eksponeringen bare hvis begrensningen håndheves et sted og noen vedlikeholder listen. En blokkering som stille stopper en nattlig batchjobb, er ikke en kontroll, det er et avbrudd med bedre papirarbeid.

Hold eieren av endringen og eieren av beslutningen fra hverandre når de er forskjellige personer. Plattformteamet utfører; direktøren aksepterer. Å skrive begge navnene i notatet fjerner den vanligste stagnasjonen, nemlig en godt forberedt plan som venter på en person som aldri har sett den.

Verifiser notatet mot utrullingen før du sender det

Påstander eldes dårlig i organisasjoner med mer enn én gateway. Et funn kopiert fra en forumtråd om en annen utgivelse, eller fra en vert som ble bygget på nytt forrige måned, vil bli utfordret i møtet, og resten av notatet går med. Kjør dokumentasjonen på nytt på hver vert notatet nevner:

for h in gw1 gw2; do
  ssh "$h" 'openvpn --version | head -n 1; systemctl is-active openvpn@server'
done

Hvis de to vertene er uenige, handler notatet nå om en blandet flåte, som er et annet og vanligvis mer overbevisende funn. Hvis tjenesten er inaktiv på en vert du trodde betjente trafikk, stopp og rett inventaret før notatet går noe sted.

Legg så ved utdataene, sett beslutningsdatoen i emnefeltet, og send det til personen som kan si ja i stedet for til gruppen som vil diskutere det. Hvis svaret kommer tilbake som «ikke nå», spør om datoen det blir «nå», og skriv den datoen inn i neste versjon av notatet.