Risorse · 23
Dare priorità alle vulnerabilità e verificare la correzione
Collegare lo sfruttamento noto, le risorse esposte, l'impatto aziendale e la prova di una correzione funzionante.
Aggiornato · 3 min
Obiettivi di questa guida
- Associare gli avvisi alle risorse
- Classificare l'urgenza effettiva
- Implementare in sicurezza
- Verificare e chiudere
Verifica rapida
- Il prodotto e la versione interessati sono effettivamente distribuiti?
- La risorsa è raggiungibile ed è critica per l'attività aziendale?
- Lo sfruttamento è documentato?
- Cosa protegge il servizio prima di una patch?
- Un controllo conferma che il problema è stato risolto sulla risorsa?
Metodo passo passo
- 1
Consolidare l'inventario
Mappare servizi, prodotti, versioni, ambienti, esposizione e responsabili. Un avviso di componente da solo non dimostra che un'istanza vulnerabile sia distribuita.
Risultato: elenco datato delle risorse interessate e delle incertezze.
- 2
Qualificare il risultato
Confrontare l'avviso del fornitore, l'identificativo CVE, le condizioni di sfruttamento e, ove pertinente, il catalogo CISA delle vulnerabilità note sfruttate. Registrare quando è stata verificata ciascuna fonte.
Risultato: risultato con riferimenti primari.
- 3
Definire una priorità difendibile
Considerare lo sfruttamento noto, l'accessibilità delle risorse, i privilegi richiesti, i dati gestiti, l'impatto sul servizio e le soluzioni disponibili. Assegnare un responsabile e una scadenza specifica per il contesto.
Risultato: decisione motivata sulla priorità.
- 4
Preparare la modifica
Mappare le dipendenze, la finestra temporale per la modifica, il backup e il rollback. Se un aggiornamento non può essere applicato tempestivamente, registrare il controllo temporaneo e la sua scadenza.
Risultato: piano di implementazione ed eccezione limitata.
- 5
Implementare e testare
Applicare la correzione o la mitigazione del fornitore utilizzando il processo approvato. Verificare la versione risultante, il flusso di lavoro aziendale e le integrazioni che potrebbero presentare regressioni.
Risultato atteso: registro di implementazione e risultato funzionale.
- 6
Verifica della chiusura
Verifica dell'asset effettivo con un metodo appropriato, individua le istanze mancanti e rivedi le eccezioni. Non chiudere un ticket solo perché è stato programmato un aggiornamento.
Risultato atteso: documentazione di verifica e registro aggiornato.
Indicatori di gestione
| Indicatore | Cosa misura | Prima azione |
|---|---|---|
| Copertura | Risorse critiche con versioni e proprietari noti | Completare l'inventario |
| Ritardo | Tempo dalla qualificazione alla correzione verificata | Rimuovere i colli di bottiglia ripetuti |
| Verifica | Correzioni ritestate su risorse reali | Riaprire le chiusure senza prove |
| Eccezioni | Deroghe con controllo, proprietario e scadenza | Chiudere le eccezioni scadute |
Errori comuni
- Classificazione basata esclusivamente su un punteggio generico senza verificare la risorsa
- Presumere che un'inclusione in un elenco KEV implichi l'esistenza del prodotto nel proprio parco
- Implementazione senza testare il comportamento del servizio
- Lasciare i controlli compensativi senza una data di revisione
Domande frequenti
La CVE con il punteggio più alto deve sempre essere eseguita per prima?
Un punteggio descrive la gravità tecnica; lo sfruttamento noto, l'esposizione e l'impatto sul servizio locale guidano l'ordine operativo.
Cosa fare se non esiste una patch?
Seguire le misure di mitigazione del fornitore, ridurre l'esposizione ove possibile e documentare il responsabile, la data di revisione e il rischio residuo.
Quando il lavoro è chiuso?
Dopo che la versione o la misura di mitigazione è stata verificata sulle istanze interessate e la funzionalità critica è stata testata.
Riferimenti ufficiali
I riferimenti supportano il metodo. Adattare i controlli al proprio contesto; non costituiscono una certificazione. I titoli dei riferimenti originali e i documenti di origine potrebbero essere in un'altra lingua.
