VPN-riskrapport ignorerad? Skriv beslutet, inte poängen

En riskanteckning som slutar med en allvarlighetsrangordning ger en chef en dom och ingen åtgärd. Därför kommer så många tillbaka med «tack, noterat» och inget annat. Anteckningarna som blir godkända delar en form: ett smalt, kontrollerbart påstående, två namngivna alternativ med ett pris och en person som måste svara före ett datum. Allt nedan handlar om att producera den formen utan att överdriva det du vet.

Poängen svarar på en fråga som ingen ställde

Aritmetik med sannolikhet gånger påverkan ger en siffra som sorterar fynd mot varandra. Den säger inte till en direktör vad som ska signeras, och den bjuder in till en debatt om multiplikatorn i stället för ett beslut om gatewayen. Jag har sett en exponeringssiffra med två decimaler sluka ett helt möte medan den verkliga frågan — om uppgraderingen ska finansieras det här kvartalet — aldrig ställdes.

Det finns bara några få verkliga beslut på det här området. Finansiera uppgraderingen, acceptera en avgränsad exponering till ett angivet datum eller minska vilka som kan nå tjänsten. Varje beslut har en annan ägare och en annan kostnad, och inget av dem är «minska risken med 40 procent».

Uppblåst allvar gör problemet värre. När varje fynd är kritiskt slutar rangordningen att skilja och läsaren faller tillbaka på den enda signal som återstår, nämligen vem som klagade högst. En anteckning som säger att versionen är utan support, att det är andra kvartalet utan support och att en viss grupp anställda är beroende av den är långt mer handlingsbar än ett rött märke.

Otydlighet är det andra misslyckandet. «VPN:et är osäkert» kan inte lösas, eftersom det inte säger vilken utrullning, vilken version eller vem som kan nå vad. En mening som läsaren kan kontrollera är den minsta enheten i en användbar rapport.

Krymp påståendet tills någon kan kontrollera det

Förankra påståendet i en publicerad gräns i stället för i en åsikt. Utanför leverantörens support, ett saknat obligatoriskt autentiseringssteg eller nåbarhet från ett nätverkssegment som inte borde se det är alla påståenden med ett test bakom sig. För det första är testet tre kommandon på själva gatewayen:

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

Versionsraden och paketförfrågan stämmer vanligtvis, och när de inte gör det har du hittat ett andra problem som förtjänar en egen rapport. Certifikatets utgångsdatum är fältet folk glömmer att kontrollera tills klienterna inte längre kan ansluta, och det hör hemma i samma bevisbilaga som versionssträngen.

Anteckna varifrån varje utdata kom och när den togs. En anteckning som säger «gateway gw1, insamlad på tisdag» kan en skeptiker köra igen; en skärmbild beskuren till den intressanta raden kan inte. Ta bort nycklar, privata adresser och kontonamn innan filen lämnar din maskin.

Skriv anteckningen som ett val mellan namngivna alternativ

En beslutsanteckning är kort eftersom den gör ett enda jobb. Det här är formen jag använder, ifylld för en påhittad medelstor organisation vars fjärråtkomstversion gick ur support:

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.

Varje rad förtjänar sin plats. Begäran är en mening och innehåller ett datum. Påståendet är kontrollerbart. Alternativ B finns för att alternativ A ska vara ett val och inte en formalitet, och det nämner ominstallationen av klienten eftersom det är kostnaden folk underskattar. Kostnaden för att vänta beskriver en konsekvens, inte en sannolikhet.

Det anteckningen inte får göra är att smuggla in en slutsats du inte kan stödja. Om ingen kompromettering har visats, säg det på en rad, för en läsare som senare upptäcker en överdrift kommer också att diskontera dina tre nästa anteckningar.

Vad acceptansen av risken måste innehålla

Acceptans är inte frånvaro av ett beslut och inte tystnad. Om svaret är att leva med exponeringen ett tag behöver anteckningen tre tillägg: ett slutdatum, ett övervakningssteg som någon faktiskt utför och en namngiven person som öppnar frågan igen när datumet kommer.

En tillfällig kontroll behöver samma behandling. Att begränsa tjänsten till en mindre grupp minskar exponeringen bara om begränsningen upprätthålls någonstans och någon underhåller listan. En blockering som tyst stoppar ett nattligt batchjobb är inte en kontroll, det är ett avbrott med bättre pappersarbete.

Håll ägaren av ändringen och ägaren av beslutet åtskilda när de är olika personer. Plattformsteamet utför; direktören accepterar. Att skriva båda namnen i anteckningen tar bort den vanligaste stockningen, nämligen en väl förberedd plan som väntar på en person som aldrig har sett den.

Verifiera anteckningen mot utrullningen innan du skickar den

Påståenden åldras dåligt i organisationer med mer än en gateway. Ett fynd som kopierats från en forumtråd om en annan version, eller från en värd som byggdes om förra månaden, kommer att ifrågasättas på mötet och resten av anteckningen går med. Kör bevisen igen på varje värd som anteckningen nämner:

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

Om de två värdarna inte är överens handlar anteckningen nu om en blandad flotta, vilket är ett annat och vanligtvis mer övertygande fynd. Om tjänsten är inaktiv på en värd du trodde betjänade trafik, stanna och rätta inventariet innan anteckningen går någonstans.

Bifoga sedan utdata, sätt beslutsdatumet i ämnesraden och skicka det till personen som kan säga ja i stället för till gruppen som kommer att diskutera det. Om svaret kommer tillbaka som «inte nu», fråga efter datumet då det blir «nu» och skriv in det datumet i nästa version av anteckningen.