Le prime ore dopo un CVE critico: una checklist che funziona

Viene pubblicata una vulnerabilità di massima gravità in un componente centrale. Da quel momento l'orologio corre per tutti, attaccanti compresi. La differenza tra una giornata tranquilla e una brutta settimana raramente è la patch in sé. È ciò che fate nelle ore prima e dopo. Questa è la sequenza che seguiamo, scritta perché possiate adattarla alla vostra flotta.

Ora zero: leggete l'advisory due volte

Leggete l'advisory una volta per capire la falla e una volta per capire le condizioni. La maggior parte degli advisory seri arriva con dei qualificatori: solo quando un certo modulo è caricato, solo in una certa modalità del server, solo quando una funzione è raggiungibile dalla rete. Quei qualificatori decidono quali dei vostri host sono urgenti, quali sono semplicemente interessati, e quale mitigazione si adatta.

Scrivete tre cose prima di toccare qualsiasi cosa: i nomi dei pacchetti interessati, la release upstream corretta, e le condizioni per lo sfruttamento. Tutto ciò che segue viene verificato rispetto a quella nota.

Trovate ogni host che lo esegue

Interrogate il database dei pacchetti su ogni host invece di affidarvi a ciò che credete sia installato:

for h in $(cat hosts.txt); do
  printf '%s: ' "$h"
  ssh -o BatchMode=yes "$h" 'rpm -q --qf "%{NAME}-%{VERSION}-%{RELEASE}\n" <package> 2>/dev/null || echo not-installed'
done | tee exposure-$(date +%F).txt

Poi controllate le condizioni. Se la falla vive in un modulo, elencate cosa è davvero caricato. Se richiede che una funzione sia raggiungibile, controllate se lo è. Ordinate il risultato in tre gruppi: esposti e raggiungibili, installati ma non sfruttabili così come configurati, e non presenti. Il primo gruppo va mitigato adesso.

Mitigate prima che la correzione esista

C'è quasi sempre qualcosa che potete fare prima che un pacchetto corretto sia disponibile: disabilitare la funzione vulnerabile, cambiare un valore di configurazione, mettere all'edge una regola che blocchi la forma di richiesta di cui l'exploit ha bisogno. Scegliete la mitigazione meno invasiva che chiude il percorso, e applicatela con disciplina:

• Tenete una lista di ogni mitigazione che avete messo, così da poter togliere quelle che costano prestazioni una volta arrivata la correzione vera. Le mitigazioni che non costano nulla possono restare.

Costruite la correzione da soli se dovete

A volte il progetto upstream ha rilasciato il sorgente corretto e la distribuzione non l'ha ancora impacchettato. Aspettare è un'opzione, ma non l'unica. Quando decidiamo di non aspettare, costruiamo noi il pacchetto: dalla specifica del maintainer della distribuzione stessa, in un container pulito e usa e getta, da un sorgente il cui checksum è verificato rispetto alla pagina di download ufficiale del progetto, con un tag di release scelto in modo che la build del produttore sostituisca la nostra automaticamente quando arriva. I pacchetti vanno nel nostro mirror con i loro checksum a registro. Il metodo completo, con i comandi, è in Un mirror RPM vostro, e costruire la correzione prima che la distro la pubblichi.

La decisione di costruire è un giudizio, non un riflesso. Costruite quando la falla viene sfruttata o è sfruttabile banalmente, gli host interessati sono raggiungibili, e nessuna mitigazione chiude il percorso abbastanza bene. Altrimenti una solida mitigazione più una breve attesa del pacchetto del produttore è di solito la scelta più serena.

Tenete un registro, e avvisate le persone

Tenete una timeline man mano che procedete

Aprite un file di testo semplice all'ora zero e scrivete una riga per azione, con l'ora: advisory letto, inventario fatto, mitigazione messa su quali host, pacchetto costruito, ogni host patchato, revisione dei log conclusa. Costa secondi per riga. Vi dà la finestra di esposizione esatta per ogni host, che serve alla revisione dei log, e trasforma il report che dovete consegnare dopo in una modifica invece che in un esercizio di memoria.

Avvisate le persone prima che chiedano

Le persone che dipendono dai sistemi interessati sentiranno parlare di una vulnerabilità famosa dai notiziari, spesso entro poche ore. Avvisatele per primi. Un breve messaggio che dica se i loro sistemi sono interessati, cosa è già stato fatto e quando arriverà la correzione vale più di un report perfetto una settimana dopo. Se un passaggio richiede downtime, concordate con loro i tempi prima di procedere.

Distribuite un host alla volta, con la prova

Ogni host riceve un controllo prima e uno dopo, e i due vengono confrontati, non guardati a occhio:

php -m | sort > pre-modules.txt            # or the equivalent for your component
curl -s -o /dev/null -w '%{http_code}\n' https://<site>/health
# install, then reload gracefully
systemctl reload php-fpm
php -m | sort > post-modules.txt && diff pre-modules.txt post-modules.txt

Su una flotta più grande, automatizzate la parte accurata invece di saltarla. Un rollout che aggiorna un server per esecuzione, campiona siti reali prima e dopo, e ferma l'intero passaggio chiamando un ingegnere nel momento in cui un singolo sito non torna su è insieme più veloce e più sicuro di una persona che scorre una lista di notte.

Poi chiedetevi se la finestra è stata usata

Applicare la patch chiude la porta. Non vi dice se qualcuno ci è passato mentre era aperta. Una volta finito il rollout, cercate nei log web e di autenticazione il periodo tra la divulgazione e la patch su ogni host esposto. Cercate le forme di richiesta di cui l'exploit ha bisogno, processi o file inattesi creati in quella finestra, e login che non rientrano nello schema abituale. Scrivete cosa avete trovato, compreso «niente», perché le persone che dipendono da quei sistemi lo chiederanno.

La versione breve

• Leggete le condizioni, non solo la gravità.
• Inventariate dal database dei pacchetti, non dalla memoria.
• Mitigate entro ore.
• Costruite la correzione da soli solo quando è giustificato, e fatelo nel modo pulito.
• Tenete una timeline e avvisate presto le persone interessate.
• Distribuite un host alla volta con controlli prima e dopo confrontabili, e uno stop automatico.
• Rivedete la finestra di esposizione nei log, e riferitela.

Se arriva una divulgazione e volete aiuto per affrontarla sulla vostra piattaforma, ci siamo. Parla con un ingegnere

Related (rows[1])

Correlati: Risposta urgente alle vulnerabilità in giornata · La hardening baseline su ogni host · Aggiornamento delle piattaforme e disciplina degli upgrade