Patching, patching, patching: lo stiamo facendo tutti forse un po’ male se non ci stiamo dotando di un processo strutturato.

Il mio martedì è iniziato con un sussulto alla lettura dell’advisory emesso dal security team di Netflix.

Denial of Service remoto per vulnerabilità del kernel di Linux e FreeBSD.

Sono tornato per un attimo con la mente alla fine degli anni ‘90 quando era il Ping of Death uno dei divertimenti dell’epoca. Un pacchetto malformato e voilà il kernel panic era servito. E così per AngeL, il mio progetto di tesi di laurea che stavo sviluppando insieme ad Aldo in quel di un LASER agli albori, scrivemmo un controllo per impedire che un host lanciasse un ping of death agganciandoci al modulo del kernel di netfilter.

A nostro modo, con quello che poteva essere un IPS primordiale, stavamo facendo del virtual patching al contrario, mettendo una pezza sulle capacità offensive del nostro attaccante.

Ritorniamo ai nostri giorni. Bollettino di sicurezza in mano, processo di patch management dall’altra, si parte con il “cosa facciamo ora?”.

Straordinario vs Ordinario

Ho cercato di dividere il patching di un sistema tra ordinario e straordinario per guidare le azioni mitigative in caso di emergenza, elevando la criticità delle stesse per avere una risposta più veloce.

Quello di SACK è stato quindi un caso in cui si è attivato il processo di patching straordinario:

• triage della vulnerabilità
• identificazione degli asset e prioritizzazione della mitigazione a seconda dell’esposizione
• individuazione delle attività contenitive (e per fortuna che in questo caso erano disponbile dei workaround per gestire eventuali server dove non poteva essere fatto un riavvio)
• esecuzione secondo una timeline concordata.

Stessa cosa fatta qualche giorno prima per gestire la remote code execution di exim.

Avere in mano una scaletta di cose che ti dica quando intervenire e cosa fare è fondamentale se non si vuol lasciare la propria società in balìa degli eventi, nel mezzo di un possibile attacco.

E’ altresì importante distinguere il patching straordinario, dove la focalizzazione deve essere massima, da quello ordinario. Il patching ordinario deve essere un’attività scandita dagli advisory del vendor ed effettuato con una periodicità che, caso per caso, voi come security manager, andrete a decidere.

Il nostro team che gestisce le macchine, server e client, non deve essere soffocato dai nostri processi. Come blue team dobbiamo ricordarci sempre che il business conta sul fatto che l’operatività delle macchine non sia intaccata, ecco perché dobbiamo studiare un timing efficace per la nostra infrastruttura.

Nel patching ordinario, le cose importanti da fare sono:

• collezionare i bollettini dei vendor (sia del sistema operativo, che del software principale utilizzato in azienda)
• fare un triage per dare una priorità di cosa deve essere installato mandatoriamente prima del prossimo patching ordinario
• trovare eventuali azioni contenitive nel caso non si possa applicare una o più patch
• ingaggiare i team coinvolti e presidiare l’attività fungendo da coordinatore.

Off by one

Tu come dividi le richieste di patching che indirizzi verso i team di sysadmin? Usi uno schema custom di triage, ti basi solo sul CVSS o altro?

Perché non lasci il tuo commento qui sotto. Ne può nascere una discussione interessante.

Ti ricordo, che da qualche giorno è disponibile anche il canale telegram di Codice Insicuro dove potrai stare in contatto con me e con tutta la community che ruota attorno al progetto Codice Insicuro.

Enjoy it.