{"id":915923,"date":"2026-10-29T16:31:52","date_gmt":"2026-10-29T16:31:52","guid":{"rendered":"https:\/\/www.ninjaone.com\/blog\/policy-di-sicurezza-perfette\/"},"modified":"2026-10-29T16:31:52","modified_gmt":"2026-10-29T16:31:52","slug":"policy-di-sicurezza-perfette","status":"publish","type":"post","link":"https:\/\/www.ninjaone.com\/it\/blog\/policy-di-sicurezza-perfette\/","title":{"rendered":"Perch\u00e9 le policy di sicurezza perfette non esistono"},"content":{"rendered":"

Le policy di sicurezza perfette non esistono non perch\u00e9 siano difficili da scrivere, ma perch\u00e9 rispecchiano male la realt\u00e0. C\u2019\u00e8 una bella differenza tra una policy scritta e una policy scritta che sia applicabile<\/a>.<\/p>\n

La maggior parte delle policy non \u00e8 pensata per reggere il ritmo e i continui cambiamenti del contesto in cui ci troviamo. Vengono scritte con le migliori intenzioni, ma crollano perch\u00e9 descrivono stati \u201cideali\u201d e scenari perfetti.<\/p>\n

Perch\u00e9 le buone policy falliscono nella pratica<\/h2>\n

Ai tempi in cui ero sysadmin e mi occupavo di patch management, sono caduto esattamente in questa trappola. Avevo introdotto quella che sembrava una policy lineare: tutte le patch critiche devono essere distribuite entro 30 giorni dal rilascio. Era una metrica chiara, facile da misurare e, soprattutto, in linea con i requisiti normativi e di conformit\u00e0 che dovevamo soddisfare.<\/p>\n

Sulla carta era perfetta, esattamente come dovrebbe essere una buona sicurezza. O forse no? Nella pratica \u00e8 andata in pezzi quasi subito.<\/p>\n

Dato che facevo parte anche del team responsabile del monitoraggio e dell\u2019installazione delle patch su endpoint e server, senza accorgermene avevo appena azzerato tutto il mio tempo libero. Nel tempo necessario per individuare cosa andava aggiornato e quando, testare le patch all\u2019interno dell\u2019IT (eravamo sempre noi le cavie), pianificare le finestre di manutenzione per il resto dell\u2019organizzazione e infine distribuirle, erano gi\u00e0 passati quasi 30 giorni. Poi il ciclo ricominciava. E a me non restava tempo per fare altro che fare da balia alle patch.<\/p>\n

Come se non bastasse, facevamo svolgere un penetration test, e i risultati del pentest erano molto diversi da quelli delle nostre scansioni delle vulnerabilit\u00e0<\/a>. I pentester ci spingevano a correggere quanto avevano rilevato, ma alcune vulnerabilit\u00e0 non erano classificate come \u201cCritical\u201d. Cos\u00ec quei problemi ad alto rischio sono rimasti senza correzione per parecchio tempo dopo quelli critici.<\/p>\n

Non \u00e8 stato un problema di intenzioni. Non sbagliavo a volere un patching tempestivo. La policy ha fallito perch\u00e9 non teneva conto dell\u2019ambiente reale, del rischio effettivo per l\u2019organizzazione o delle priorit\u00e0 in conflitto tra loro. \u00c8 qui che la maggior parte delle policy di sicurezza crolla. Sono progettate per condizioni perfette che negli ambienti IT reali non esistono e spesso non prevedono decisioni realmente basate sul rischio. Alla fine, policy di questo tipo non vengono seguite: vengono aggirate o ignorate del tutto.<\/p>\n

Non sono solo le policy sviluppate internamente a cadere in questa trappola. Anche standard di settore ampiamente riconosciuti possono fallire se applicati senza considerare le specificit\u00e0 della tua organizzazione e del tuo ambiente.<\/p>\n

Quando lo \u201cstandard di settore\u201d smette di essere utile<\/h2>\n

Gli standard di settore esistono per ottime ragioni. Si basano sulle lezioni apprese da incidenti di sicurezza e violazioni dei dati e rappresentano la competenza collettiva dei professionisti della sicurezza. Forniscono una baseline che funziona per la maggior parte delle organizzazioni nella maggior parte dei casi. Il problema \u00e8 che \u201cla maggior parte delle organizzazioni nella maggior parte dei casi\u201d lascia comunque ampio margine di fallimento.<\/p>\n

Il team IT di un\u2019azienda manifatturiera l\u2019ha imparato a sue spese quando ha deciso di applicare l\u2019hardening ai propri server Windows usando i benchmark CIS Level 1. I CIS Benchmark sono ottimi punti di partenza: sono molto apprezzati, aggiornati con regolarit\u00e0 e raccomandati da auditor e professionisti della sicurezza. Non era questo il problema.<\/p>\n

Il problema \u00e8 stato pensare di poterli applicare in modo uniforme a ogni sistema dell\u2019ambiente. Peccato che i sistemi di controllo della linea di produzione non siano tipici sistemi per utenti finali. Hanno uno scopo preciso e requisiti specifici, diversi da quelli di ambiti come la contabilit\u00e0, per esempio.<\/p>\n

I benchmark hanno disabilitato diversi protocolli e servizi legacy su cui i loro macchinari industriali di 15 anni facevano affidamento per comunicare con il server. Il risultato \u00e8 stato il fermo della produzione per quasi tutta la giornata (6 ore), mentre si correva ai ripari per annullare le modifiche. L\u2019impatto economico non \u00e8 stato trascurabile. Non al punto da mettere a rischio l\u2019azienda, ma ha causato parecchia preoccupazione e confusione nei team IT e di produzione.<\/p>\n

Applicare i benchmark CIS<\/a> non era l\u2019approccio sbagliato. Sono progettati per ambienti IT moderni, con sistemi operativi attuali e apparecchiature aggiornate. Ma restano un punto di partenza, e non tutte le impostazioni previste dal benchmark sono necessariamente adatte a un ambiente di tecnologia operativa, dove aggiornare \u00e8 molto pi\u00f9 complicato e i tempi di inattivit\u00e0 possono avere pesanti conseguenze economiche.<\/p>\n

\u00c8 qui che seguire alla cieca gli \u201cstandard di settore\u201d pu\u00f2 farti male. Questi benchmark si basano su presupposti riguardo al tuo ambiente, alle tue risorse e alle tue operazioni. Quando quei presupposti non corrispondono al tuo ambiente reale \u2013 perch\u00e9 usi sistemi legacy, operi in un settore specializzato o devi fare i conti con altri vincoli che i benchmark non considerano \u2013 seguire ciecamente le best practice pu\u00f2 creare pi\u00f9 problemi di quanti ne risolva.<\/p>\n

I benchmark sono uno strumento utile e vanno usati. Troppo spesso, per\u00f2, le policy ne impongono l\u2019adozione solo per spuntare una casella di conformit\u00e0, senza prima capire quali siano i requisiti specifici del proprio ambiente.<\/p>\n

Come progettare policy che funzionano davvero<\/h2>\n

Dopo il fallimento della mia policy originale di patching a 30 giorni, io e il mio team l\u2019abbiamo riprogettata attorno ai risultati anzich\u00e9 alle scadenze. La nuova policy era incentrata sul rischio<\/a>. C\u2019erano molte integrazioni, ma questa \u00e8 quella che rende meglio l\u2019idea:<\/p>\n

\u201cLe vulnerabilit\u00e0 critiche che interessano asset esposti su internet con evidenza di sfruttamento attivo devono essere mitigate entro 72 ore. Le vulnerabilit\u00e0 critiche per cui \u00e8 disponibile codice proof-of-concept devono essere corrette entro 7 giorni. La riduzione del rischio pu\u00f2 avvenire tramite patching, controlli compensativi o isolamento temporaneo del servizio. Tutte le azioni e le eccezioni devono essere documentate con l\u2019accettazione del rischio da parte del CISO (direttore del dipartimento per la sicurezza informatica).\u201d<\/p>\n

Il vero cambiamento non riguardava solo le tempistiche. Abbiamo iniziato a dare priorit\u00e0 a vulnerabilit\u00e0 e patch in base all\u2019esposizione reale: se i sistemi fossero esposti su internet, se esistessero exploit gi\u00e0 in circolazione e quali dati quei sistemi trattassero.<\/p>\n

Ma, cosa altrettanto importante, abbiamo capito che la visibilit\u00e0 \u00e8 fondamentale per l\u2019IT. Abbiamo implementato una scansione automatizzata delle vulnerabilit\u00e0<\/a> che confluiva direttamente nella nostra dashboard di patch management. Quando un sistema usciva dai parametri di conformit\u00e0 e gli mancavano patch critiche, lo sapevamo subito. Abbiamo iniziato a poter monitorare le nostre metriche nel tempo, per capire quanto bene (o male) stessimo lavorando e su cosa dovessimo migliorare.<\/p>\n

Abbiamo anche riconosciuto che a volte applicare le patch entro i tempi previsti non era possibile, per i motivi pi\u00f9 diversi. In quei casi servivano controlli compensativi, servivano documentazione e serviva l\u2019approvazione del management.<\/p>\n

Nel caso della policy sui CIS Benchmark la lezione \u00e8 stata simile, ma il team IT l\u2019ha affrontata da un\u2019altra prospettiva. Non ha abbandonato del tutto i benchmark, n\u00e9 li ha rimossi dalla policy. Ha invece aggiornato la policy per richiedere valutazioni di hardening CIS per ogni tipo di sistema presente in azienda, cos\u00ec da stabilire una baseline di quali benchmark avrebbero compromesso i componenti di produzione e quali no. Il team IT ha documentato quali benchmark si applicavano a ciascun tipo di sistema, quali entravano in conflitto con i requisiti di quel tipo di sistema e quali controlli compensativi erano stati adottati. I sistemi di produzione hanno ottenuto una baseline di hardening dedicata, e lo stesso \u00e8 avvenuto per i sistemi degli utenti finali e per i server.<\/p>\n

Come procedere da qui in avanti<\/h2>\n

Come sappiamo, nell\u2019IT e nella sicurezza non c\u2019\u00e8 praticamente nulla di ideale. L\u2019innovazione e il progresso tecnologico corrono sempre pi\u00f9 veloci della sicurezza.<\/p>\n

Il nostro compito, come professionisti IT e della sicurezza, \u00e8 sfruttare al meglio ci\u00f2 che abbiamo a disposizione: progettare sistemi, processi e policy abbastanza sicuri da permettere a utenti, reparti e funzioni aziendali di lavorare nel modo pi\u00f9 sicuro possibile, senza ostacolare troppo le loro attivit\u00e0.<\/p>\n

Dobbiamo accettare che la sicurezza perfetta non esiste e capire che le policy che pretendono la perfezione sono destinate a fallire.<\/p>\n

La sicurezza funziona meglio quando fa parte del modo in cui l\u2019IT lavora ogni giorno, non quando viene aggiunta a posteriori. Funziona meglio quando \u00e8 anche l\u2019opzione pi\u00f9 efficiente e pi\u00f9 comoda. Quando ostacola il lavoro il meno possibile.<\/p>\n

Se il tuo team deve scegliere tra portare a termine il lavoro e rispettare una policy di sicurezza, sceglier\u00e0 sempre di portare a termine il lavoro. Progetta le tue policy in modo che le due cose coincidano.<\/p>\n","protected":false},"excerpt":{"rendered":"

Le policy di sicurezza perfette non esistono non perch\u00e9 siano difficili da scrivere, ma perch\u00e9 rispecchiano male la realt\u00e0. C\u2019\u00e8 una bella differenza tra una policy scritta e una policy scritta che sia applicabile. La maggior parte delle policy non \u00e8 pensata per reggere il ritmo e i continui cambiamenti del contesto in cui ci […]<\/p>\n","protected":false},"author":35,"featured_media":755711,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"_relevanssi_hide_post":"","_relevanssi_hide_content":"","_relevanssi_pin_for_all":"","_relevanssi_pin_keywords":"","_relevanssi_unpin_keywords":"","_relevanssi_related_keywords":"","_relevanssi_related_include_ids":"","_relevanssi_related_exclude_ids":"","_relevanssi_related_no_append":"","_relevanssi_related_not_related":"","_relevanssi_related_posts":"","_relevanssi_noindex_reason":"","_lmt_disableupdate":"","_lmt_disable":"","footnotes":""},"categories":[4367],"tags":[],"class_list":["post-915923","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-sicurezza"],"acf":[],"modified_by":null,"_links":{"self":[{"href":"https:\/\/www.ninjaone.com\/it\/wp-json\/wp\/v2\/posts\/915923","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.ninjaone.com\/it\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.ninjaone.com\/it\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.ninjaone.com\/it\/wp-json\/wp\/v2\/users\/35"}],"replies":[{"embeddable":true,"href":"https:\/\/www.ninjaone.com\/it\/wp-json\/wp\/v2\/comments?post=915923"}],"version-history":[{"count":1,"href":"https:\/\/www.ninjaone.com\/it\/wp-json\/wp\/v2\/posts\/915923\/revisions"}],"predecessor-version":[{"id":915924,"href":"https:\/\/www.ninjaone.com\/it\/wp-json\/wp\/v2\/posts\/915923\/revisions\/915924"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.ninjaone.com\/it\/wp-json\/wp\/v2\/media\/755711"}],"wp:attachment":[{"href":"https:\/\/www.ninjaone.com\/it\/wp-json\/wp\/v2\/media?parent=915923"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.ninjaone.com\/it\/wp-json\/wp\/v2\/categories?post=915923"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.ninjaone.com\/it\/wp-json\/wp\/v2\/tags?post=915923"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}