Impostare la gravità personalizzata degli aggiornamenti in SCCM

Perché la gravità personalizzata in SCCM non è un semplice campo cosmetico

In Configuration Manager la parola “gravità” viene usata spesso in modo informale, ma il punto tecnico è più preciso: non stai solo etichettando un aggiornamento, stai decidendo come quel contenuto verrà classificato, filtrato, prioritizzato e letto nei report. Se l’obiettivo è assegnare una gravità personalizzata agli aggiornamenti, bisogna distinguere tra il dato che esiste davvero nel catalogo, il dato che puoi esporre in console e il dato che puoi usare nei flussi operativi.

In pratica, SCCM non nasce per avere una gravità “business” arbitraria su ogni update come fosse un tag libero. La piattaforma lavora con metadati Microsoft, classificazioni, categorie, supersedence e compliance state. Il margine di personalizzazione c’è, ma va costruito sopra quei metadati, non contro di essi. Se provi a forzare la logica dentro il solo nome della patch o dentro una colonna inventata nel reporting, ottieni un sistema fragile: bello da vedere, inutilizzabile quando servono automazioni o audit.

Classificazione nativa, gravità operativa e gravità business

La prima decisione non è tecnica ma architetturale: cosa intendi per gravità?

• Gravità nativa: il livello pubblicato dal vendor o il tipo di classificazione dell’update.
• Gravità operativa: quanto impatta davvero l’ambiente, ad esempio server esposti, endpoint critici, workload regolamentati.
• Gravità business: priorità decisa dall’IT o dal security team, che può non coincidere con la severità tecnica.

Se vuoi che SCCM supporti davvero una gravità personalizzata, la cosa più pulita è separare questi tre livelli. La severità nativa resta nel catalogo; la gravità operativa la derivi con regole; la gravità business la governi con una tassonomia tua, idealmente tracciata in un campo esterno o in un meccanismo di estensione del database/reporting. Mischiarle in un solo campo produce confusione appena entrano in gioco eccezioni, rollout a anelli o server con ruoli diversi.

Dove mettere la gravità personalizzata senza rompere SCCM

Le strade realistiche sono tre.

1. Usare categorie e classificazioni già esistenti per mappare una priorità interna. È la via meno invasiva, ma anche la meno espressiva.
2. Arricchire il reporting con una tabella o una vista che associa l’update a una gravità custom. È la scelta più robusta se il tuo processo passa da dashboard, compliance e query.
3. Integrare un attributo esterno tramite import, script o automazione, mantenendo SCCM come source of truth per il contenuto ma non per la priorità.

La soluzione che di solito regge meglio in produzione è la seconda: non tocchi il catalogo Microsoft, non alteri i flussi di sincronizzazione, e puoi cambiare la logica di classificazione senza risincronizzare il mondo. In altre parole, il dato nativo resta intatto, la gravità personalizzata vive in uno strato di reporting o inventory enrichment.

Modello consigliato: mappa esterna tra update e severità

Se l’obiettivo è gestire una gravità personalizzata degli aggiornamenti in SCCM con un minimo di ordine, conviene creare una mappa con almeno questi campi:

• UpdateID o identificatore univoco equivalente.
• KB o riferimento umano leggibile.
• Gravità custom, ad esempio Low, Medium, High, Critical.
• Motivazione, breve ma verificabile.
• Owner o team responsabile della classificazione.
• Data revisione per audit e scadenza della decisione.

Questa struttura ti permette di fare due cose utili: filtrare i report per priorità reale e mantenere uno storico delle decisioni. Il secondo punto è più importante del primo. La gravità di una patch cambia nel tempo: una vulnerabilità può diventare più urgente dopo la pubblicazione di exploit pubblici, oppure meno urgente se il componente non è presente nel parco macchine. Se non tieni traccia della revisione, la tua priorità diventa un’etichetta morta.

Flusso operativo pulito: dalla console al dato usabile

Il flusso che funziona meglio è questo: catalogo SCCM, arricchimento esterno, reporting, enforcement. SCCM continua a importare gli update e a valutarne la compliance. Un processo separato associa una gravità personalizzata agli update rilevanti. I report e le dashboard leggono la gravità custom per ordinare il backlog, mentre la distribuzione resta governata dalle collection, dai maintenance window e dalle deployment ring.

Questo approccio evita un errore molto comune: usare la gravità come sostituto della targeting logic. La gravità non decide da sola dove andare; decide in che ordine e con quale urgenza trattare ciò che SCCM ha già individuato come necessario. Se confondi le due cose, finisci con deployment troppo aggressivi o con eccezioni difficili da spiegare al change board.

Se vuoi automatizzare, punta su una mappatura deterministica

La personalizzazione diventa davvero utile quando la regola è ripetibile. Esempio pratico: assegna Critical agli update che toccano il browser usato dai sistemi esposti verso Internet, High agli update che impattano server con ruolo applicativo, Medium agli aggiornamenti di componenti interni non esposti, Low a ciò che richiede condizioni molto specifiche.

La regola va scritta in modo deterministico, non “a sensazione”. Puoi basarti su:

• categoria prodotto;
• presenza di CVE con exploit pubblico;
• ruolo del dispositivo in inventory;
• esposizione esterna del servizio;
• popolarità del componente nell’ambiente.

Il trucco è non usare troppi criteri insieme. Tre o quattro segnali ben scelti bastano. Se la logica diventa troppo articolata, nessuno la mantiene e la gravità custom perde affidabilità. Meglio una classificazione meno raffinata ma costante, che una tassonomia elegante ma arbitraria.

Reporting: la parte in cui la gravità personalizzata fa davvero la differenza

Nel quotidiano, il valore vero della gravità custom sta nei report. Un elenco di compliance senza priorità è utile solo fino a metà mattina; dopo diventa rumore. Con una gravità personalizzata puoi ordinare il lavoro per impatto, costruire SLA interni e distinguere tra backlog tecnico e backlog realmente urgente.

Un buon report dovrebbe mostrare almeno:

• numero di update Critical non ancora distribuiti;
• numero di device non compliant per gravità;
• trend settimanale della remediation;
• tempo medio di chiusura per classe di gravità;
• eccezioni approvate e loro scadenza.

Se il tuo ambiente usa Power BI, SQL reporting o viste custom, la gravità diventa un campo perfetto per aggregazioni e filtri. Se invece la tieni solo in una nota operativa, la perdi appena cambia l’operatore di turno. Il reporting è ciò che trasforma una classificazione in un processo.

Quando non conviene toccare il catalogo SCCM

È tentante pensare di modificare direttamente i metadati dell’update per infilare lì la tua severità. In generale, è una cattiva idea. Il catalogo sincronizzato è un’area delicata: alterarlo per esigenze locali significa esporre la piattaforma a comportamenti incoerenti tra sincronizzazioni, console, WSUS e report.

Se il bisogno è puramente operativo, meglio un livello esterno. Se il bisogno è di visualizzazione, meglio una vista o un report. Se il bisogno è di automazione, meglio uno script che aggiorna una tabella di mapping o un database di supporto. In tutti e tre i casi, il catalogo resta pulito e reversibile.

Se il dato custom non è reversibile, non è una classificazione: è un debito tecnico con interfaccia grafica.

Esempio pratico di strategia sostenibile

Supponiamo di avere un parco con workstation, server applicativi e alcuni sistemi esposti. Gli update arrivano in SCCM con le classificazioni standard. Il team security mantiene una tabella esterna con la gravità custom assegnata ai KB più rilevanti. Ogni settimana un job esporta l’elenco degli update sincronizzati, li confronta con la tabella e produce una vista arricchita.

A quel punto il service desk e il patching team non guardano più solo “quali update mancano”, ma “quali update mancano e quanto sono importanti per noi”. La differenza è enorme. Un backlog di 200 update senza priorità è ingestibile; 200 update con 15 Critical e 40 High diventano un piano di lavoro concreto. La stessa logica si può estendere alle collection: una collection per i sistemi più esposti, una per i server standard, una per i device a rischio basso, ma la gravità custom resta sempre nel livello dati, non nel naming delle collection.

Governance: chi decide la gravità e quando la cambia

La parte più sottovalutata è la governance. Se la gravità custom è decisa dal solo team patching, rischi un bias operativo. Se è decisa solo dal security team, rischi di non considerare l’impatto reale sui servizi. La soluzione pratica è una matrice semplice: security propone, platform valida, operations conferma l’impatto.

Serve anche una revisione periodica. Una gravità assegnata in emergenza non deve restare per sempre. Metti una data di riesame, ad esempio ogni 30 o 90 giorni, e fai in modo che le eccezioni scadano. In molti ambienti il problema non è assegnare una priorità, ma rimuoverla quando non serve più.

Errori tipici da evitare

• Usare la gravità come sostituto del deployment ring: sono due cose diverse.
• Scrivere la priorità nel titolo invece che in un campo strutturato.
• Mescolare severità tecnica e urgenza business senza una legenda condivisa.
• Non versionare la mappa: senza storico non puoi spiegare perché un update è diventato Critical.
• Ignorare i report: se la gravità non compare nelle viste operative, nessuno la userà davvero.

Un approccio che regge nel tempo

La regola pratica è questa: SCCM gestisce il ciclo di vita dell’update, il tuo livello custom gestisce la priorità. Non cercare di far fare a SCCM il lavoro di un sistema di classificazione arbitraria se non hai un punto di estensione chiaro. La soluzione più robusta è quella che puoi spiegare in una riunione, esportare in un report e correggere senza toccare il catalogo.

Se vuoi partire in modo semplice, scegli una tassonomia ridotta, una tabella di mapping esterna e un report che mostri subito il valore operativo. Poi aggiungi automazione solo quando hai verificato che il processo manuale è stabile. In questo ambito, la semplicità non è povertà funzionale: è il modo migliore per evitare che la gravità personalizzata diventi un’etichetta scollegata dalla realtà.

Assunzione: l’ambiente usa Configuration Manager in modo standard, con reporting disponibile e possibilità di mantenere un mapping esterno; se il tuo setup è molto vincolato, la chiusura del gap passa da una verifica del modello dati usato nei report e delle estensioni consentite dalla tua organizzazione.