Protezione degli asset

Gli asset includono elementi fisici e virtuali quali portatili, database, file e account di archiviazione virtuali. La protezione degli asset business critical si basa spesso sulla sicurezza dei sistemi sottostanti, ad esempio risorse di archiviazione, dati, dispositivi endpoint e componenti dell'applicazione. Gli asset tecnici più importanti sono in genere i dati e la disponibilità di applicazioni quali siti Web aziendali, linee di produzione e comunicazioni.

La protezione degli asset implementa i controlli per supportare l'architettura, gli standard e i criteri di sicurezza. Ogni tipo di asset e requisito di sicurezza è univoco. Gli standard di sicurezza per qualsiasi tipo di asset devono essere applicati in modo coerente a tutte le istanze.

La protezione degli asset è incentrata sull'esecuzione coerente in tutti i tipi di controllo. La protezione preventiva, di rilevamento e di altro tipo si allinea per soddisfare i criteri, gli standard e l'architettura.

La protezione degli asset funge da esperto tecnico in materia di asset. Si affianca ad altre discipline, ad esempio governance, architettura, operazioni di sicurezza e team del carico di lavoro. La protezione degli asset garantisce che criteri e standard siano fattibili e consente l'implementazione di controlli per supportarli. La protezione degli asset garantisce feedback per il miglioramento continuo.

Nota

La protezione degli asset viene in genere implementata dai team delle operazioni IT che gestiscono gli asset e sono affiancati dal team di sicurezza. Per altre informazioni, vedere Progettare controlli come team.

Gli attori delle minacce sono persistenti e cercano vulnerabilità che derivano da lacune nell'applicazione di standard e criteri. Gli utenti malintenzionati possono scegliere direttamente come destinazione i dati o le applicazioni business critical. Possono anche scegliere come destinazione l'infrastruttura che concede loro l'accesso ai dati e alle applicazioni business critical. Il controllo di accesso è incentrato in particolare sulla gestione dell'accesso autorizzato alle risorse. La protezione degli asset permette di gestire tutte le altre potenziali modalità fuori banda per ottenere l'accesso alle risorse o il loro controllo. Queste due discipline si completano a vicenda e devono essere progettate insieme per soddisfare l'architettura, i criteri e gli standard. Per altre informazioni, vedere Controllo di accesso.

Guardare il video seguente per informazioni sulla cronologia della protezione degli asset e su come mantenere protetti gli asset vecchi e nuovi.

Ottenere sicurezza

La sicurezza è incentrata sull'aggiornamento delle risorse per soddisfare gli standard di sicurezza, i criteri e l'architettura dell'organizzazione correnti. Sono disponibili due tipi di attività:

• Brownfield: permette di adattare gli attuali controlli e standard di sicurezza agli asset esistenti. Le organizzazioni possono progettare e gestire ambienti IT con la sicurezza come priorità bassa. Questo approccio crea un "debito tecnico": configurazioni di sicurezza deboli, software non aggiornati, comunicazioni o risorse di archiviazione non crittografate, software e protocolli legacy e altro ancora. Aggiornare i controlli di sicurezza all'approccio corrente. Questo miglioramento è fondamentale per attenuare i rischi perché gli utenti malintenzionati migliorano continuamente la capacità di sfruttare queste opportunità.
• Greenfield: assicurarsi che i nuovi asset e i nuovi tipi di asset siano configurati in base agli standard. Questo processo è fondamentale per evitare la creazione continua di sistemi legacy o Brownfield immediati o che non soddisfano gli standard correnti. Questo debito tecnico dovrà essere corretto in un secondo momento a spese maggiori, con un aumento dell'esposizione al rischio fino al completamento.

A livello finanziario, la sicurezza è in genere mappata alle dinamiche di spesa in conto capitale (CAPEX) di un investimento una tantum. Il budget Greenfield per la sicurezza deve essere mappato il più vicino possibile alla creazione dell'asset, con una percentuale riservata del budget per la sicurezza per ogni nuovo progetto software, l'aggiornamento software principale o l'iniziativa di adozione del cloud complessiva. Molte organizzazioni riservano circa il 10% del budget alla sicurezza. Il budget Brownfield è in genere un progetto speciale che consente di aggiornare i controlli di sicurezza agli standard e alla conformità correnti.

Rimanere al sicuro

Tutto si riduce nel tempo. Gli elementi fisici si consumano e anche l'ambiente attorno a elementi virtuali quali software, sicurezza e controlli di sicurezza cambia, rischiando di non soddisfare più requisiti in costante evoluzione. Oggigiorno, questi cambiamenti si verificano rapidamente, a causa delle seguenti modifiche rapide:

• Requisiti aziendali, determinati dalla trasformazione digitale.
• Requisiti tecnologici, determinati dalla rapida evoluzione della piattaforma cloud e dalle release funzionali.
• Requisiti di sicurezza, determinati dalle innovazioni degli utenti malintenzionati e dalla rapida evoluzione delle funzionalità di sicurezza cloud native.

Questa dinamica influisce su tutte le parti della sicurezza, incluse le operazioni di sicurezza, il controllo di accesso e in particolare DevSecOps in sicurezza nell'innovazione.

La sicurezza include molti elementi. Concentrarsi su queste due aree specifiche della protezione degli asset:

• Miglioramento continuo del cloud: adottare il miglioramento continuo delle funzionalità di sicurezza del cloud. Ad esempio, molti servizi in Azure, come Archiviazione di Azure e Database SQL di Azure, hanno aggiunto funzionalità di sicurezza per difendersi dagli utenti malintenzionati nel tempo.
• Fine del ciclo di vita del software: qualsiasi software, inclusi i sistemi operativi, raggiunge sempre la fine del ciclo di vita, quando non vengono più forniti aggiornamenti della sicurezza. Questa situazione può esporre i dati e le applicazioni business critical ad attacchi semplici e a basso costo. Anche se l'infrastruttura e le piattaforme SaaS (Software as a Service) e cloud vengono gestite dal provider di servizi cloud, le aziende spesso dispongono di un numero significativo di software installati, creati e gestiti.

Pianificare l'aggiornamento o il ritiro del software a fine vita. L'investimento nel comportamento di sicurezza riduce il rischio di un grave evento imprevisto di sicurezza. Garantire la sicurezza rientra nelle dinamiche di spesa operativa (OPEX) di un investimento regolare in corso.

Il problema delle patch

È fondamentale che i responsabili aziendali supportino team e responsabili IT e della sicurezza. L'esecuzione di software complessi in un ambiente ostile presenta rischi intrinseci. I responsabili della sicurezza e dell'IT prendono costantemente decisioni difficili sui rischi operativi e per la sicurezza.

• Rischio operativo: una modifica al software in cui viene eseguito il sistema potrebbe compromettere i processi aziendali. Tali modifiche influiscono sui presupposti definiti quando il sistema è stato personalizzato per l'organizzazione. Questo spinge a evitare di modificare il sistema.
• Rischio per la sicurezza: un attacco comporta il rischio aziendale di tempi di inattività. Gli utenti malintenzionati analizzano ogni aggiornamento della sicurezza principale al momento della release. Possono sviluppare un exploit funzionante in 24-48 ore per attaccare le organizzazioni che non hanno applicato l'aggiornamento della sicurezza.

Un'organizzazione può trovarsi davanti a questo problema a causa spesso delle continue modifiche alla tecnologia e dell'evoluzione della tecnica di attacco. I responsabili aziendali devono riconoscere il rischio di gestire un'azienda con software complessi. Supportare l'aggiornamento dei processi aziendali, come gli esempi seguenti:

• Integrazione della manutenzione software nei presupposti operativi aziendali, pianificazione, previsione e altri processi aziendali.
• Investire in architetture in grado di semplificare la manutenzione e ridurre l'impatto sulle operazioni aziendali. Questo approccio potrebbe comportare l'aggiornamento delle architetture esistenti o il passaggio a nuove architetture interamente mediante migrazione a servizi cloud o a un'architettura orientata ai servizi.

Senza il supporto della leadership aziendale, i responsabili della sicurezza e dell'IT sono distratti dal supporto di importanti obiettivi aziendali. Devono gestire costantemente la politica di una situazione no-win.

Isolamento rete

L'isolamento della rete può essere un'opzione valida per proteggere asset meno recenti che non possono più essere protetti, ma non possono essere ritirati immediatamente. Questo scenario può in genere verificarsi per sistemi operativi e applicazioni a fine vita. È comune negli ambienti OT (Operational Technology) e nei sistemi legacy.

L'isolamento stesso è considerato un controllo di accesso, anche se gli asset che non possono essere protetti vengono identificati come parte della protezione degli asset. Per altre informazioni, vedere Evitare di applicare il firewall e dimenticarsi di tutto.

Alcuni sistemi a fine della vita sono difficili da disconnettere e isolare completamente. Non è consigliabile lasciare questi sistemi non sicuri completamente connessi a una rete di produzione. Questa configurazione può consentire agli utenti malintenzionati di compromettere il sistema e ottenere l'accesso agli asset nell'organizzazione.

Non è mai economico o facile aggiornare o sostituire una tecnologia informatica che funziona bene da un decennio o più. La documentazione relativa alle funzionalità potrebbe essere limitata. Il potenziale impatto aziendale della perdita del controllo di più asset business critical spesso supera il costo dell'aggiornamento o della sostituzione. Per questi asset che non possono essere isolati, le organizzazioni spesso trovano che la modernizzazione del carico di lavoro con la tecnologia e l'analisi cloud può creare nuovo valore aziendale che può compensare o giustificare il costo dell'aggiornamento o della sostituzione.

Rimanere al sicuro è difficile in un mondo in continua evoluzione. È fondamentale decidere costantemente quali asset modernizzare e cosa proteggere al meglio. Effettuare una valutazione in base a rischi e priorità aziendali.

Introduzione

Per iniziare a usare la protezione degli asset, è consigliabile che le organizzazioni esercitino i passaggi seguenti.

• Concentrarsi prima sulle risorse note: si pensi a macchine virtuali, reti e identità nel cloud con cui il team ha già familiarità. Questa tecnica consente di fare progressi immediati e spesso è più facile da gestire e proteggere con strumenti cloud nativi come Microsoft Defender for Cloud.

• Iniziare con le baseline del fornitore/settore: avviare la configurazione della sicurezza con una soluzione nota e comprovata, ad esempio:

  • Baseline di sicurezza in Azure Security Benchmark. Microsoft offre linee guida per la configurazione della sicurezza personalizzate per i singoli servizi di Azure. Queste baseline applicano i benchmark di sicurezza di Azure agli attributi univoci di ogni servizio. Questo approccio consente ai team di sicurezza di proteggere ogni servizio e perfezionare le configurazioni in base alle esigenze. Per altre informazioni, vedere Baseline di sicurezza per Azure.
  • Baseline di sicurezza Microsoft. Microsoft offre indicazioni sulla configurazione della sicurezza per tecnologie di uso comune, tra cui Windows, Microsoft Office e Microsoft Edge. Per altre informazioni, vedere baseline di sicurezza Microsoft (.Microsoft-security-baselines) per altre informazioni
  • Benchmark CIS. Il CIS (Center for Internet Security) offre linee guida di configurazione specifiche per molti prodotti e fornitori. Per altre informazioni, vedere Benchmark CIS.

Informazioni chiave

Questi elementi chiave guidano il processo di protezione degli asset:

Team affidabili e responsabili

La responsabilità della sicurezza spetta sempre al proprietario finale delle risorse nell'azienda proprietaria di tutti gli altri rischi e vantaggi. I team di sicurezza e gli esperti in materia sono collettivamente tenuti a consigliare al proprietario responsabile dei rischi eventuali soluzioni di mitigazione e di eseguirne l'implementazione effettiva.

Le responsabilità di protezione degli asset possono essere eseguite da operazioni IT che gestiscono asset a livello aziendale, team DevOps e DevSecOps responsabili delle risorse del carico di lavoro o team di sicurezza che collaborano con i team IT o DevOps e DevSecOps.

Quando le organizzazioni passano al cloud, molte di queste responsabilità possono essere trasferite al provider di servizi cloud, come l'aggiornamento della soluzione di firmware e virtualizzazione, o semplificate, come l'analisi e la correzione della configurazione di sicurezza.

Per altre informazioni sul modello di responsabilità condivisa, vedere Responsabilità condivisa nel cloud.

Elasticità del cloud

A differenza delle risorse locali, le risorse cloud potrebbero esistere solo per un breve periodo di tempo. In base alle esigenze, i carichi di lavoro possono creare più istanze di server, Funzioni di Azure e altre risorse per eseguire un processo. Azure rimuove le risorse in un secondo momento. Questo scenario può verificarsi entro alcuni mesi, ma talvolta in pochi minuti o ore. Prendere in considerazione questa possibilità per i processi e le misurazioni di protezione degli asset.

L'elasticità del cloud richiede la regolazione di molti processi. Migliora la visibilità, grazie a un inventario su richiesta anziché report statici. L'elasticità del cloud migliora anche la possibilità di risolvere i problemi. Ad esempio, la creazione di una nuova macchina virtuale per motivi di sicurezza può avvenire rapidamente.

Gestione delle eccezioni

Dopo aver identificato una procedura consigliata per un asset, applicarla in modo coerente a tutte le istanze dell'asset. Potrebbe essere necessario creare eccezioni temporanee, ma gestire le eccezioni con date di scadenza specifiche. Assicurarsi che le eccezioni temporanee non diventino rischi aziendali permanenti.

Problemi con la misurazione del valore

Può essere difficile misurare il valore aziendale della protezione delle risorse. L'impatto di un problema non è ovvio fino a quando non si verifica un errore reale. Il rischio di non aggiornare la sicurezza per le vulnerabilità è silente e invisibile.

Prediligere criteri automatizzati

Favorire l'applicazione automatizzata e meccanismi di correzione come Criteri di Azure per la protezione degli asset. Questo approccio consente di evitare problemi di costi e di esecuzione ripetuta di attività manuali, oltre a ridurre il rischio di errori umani.

I Criteri di Azure consentono ai team centrali di specificare le configurazioni da usare per gli asset nei cloud.

Progettare controlli in team

Tutti i controlli devono essere progettati in partnership con i principali stakeholder:

• La protezione degli asset offre competenze in materia in merito agli asset, ai controlli disponibili e alla fattibilità dell'implementazione dei controlli.
• Il team di governance fornisce un contesto per il modo in cui i controlli rientrano nell'architettura di sicurezza, nei criteri e negli standard e nei requisiti di conformità alle normative.
• Le operazioni di sicurezza suggeriscono i controlli di sicurezza e integrano avvisi e log in strumenti, processi e training per le operazioni di sicurezza.
• Fornitori e provider di servizi cloud offrono competenze approfondite in materia di sistemi e componenti per evitare problemi noti nella base clienti.

Passaggi successivi

La prossima disciplina da esaminare è la governance della sicurezza