Team di sicurezza, ruoli e funzioni

Questo articolo descrive i ruoli di sicurezza necessari per la sicurezza cloud e le funzioni eseguite in relazione all'infrastruttura e alle piattaforme cloud. Questi ruoli consentono di garantire che la sicurezza faccia parte di ogni fase del ciclo di vita del cloud, dallo sviluppo alle operazioni e al miglioramento continuo.

A seconda delle dimensioni dell'organizzazione e di altri fattori, i ruoli e le funzioni descritti in questo articolo potrebbero essere soddisfatti da persone che eseguono più funzioni (ruoli) anziché da una singola persona o team. Le aziende e le organizzazioni di grandi dimensioni tendono ad avere team più grandi con ruoli più specializzati, mentre le organizzazioni più piccole tendono a consolidare più ruoli e funzioni tra un numero minore di persone. Le responsabilità di sicurezza specifiche variano anche a seconda delle piattaforme tecniche e dei servizi usati dall'organizzazione.

Alcune attività di sicurezza verranno eseguite direttamente dai team tecnologici e cloud. Altri utenti possono essere eseguiti da team di sicurezza specializzati che operano in collaborazione con i team tecnologici. Indipendentemente dalle dimensioni e dalla struttura dell'organizzazione, gli stakeholder devono avere una chiara comprensione dei processi di sicurezza che devono essere eseguiti. Tutti devono anche essere consapevoli dei requisiti aziendali e della tolleranza ai rischi di sicurezza dell'organizzazione, in modo da poter prendere decisioni corrette sui servizi cloud che prendono in considerazione e bilanciano la sicurezza come requisito chiave.

Usare le linee guida contenute in questo articolo per comprendere funzioni specifiche eseguite da team e ruoli e come interagiscono i diversi team per coprire l'intera organizzazione della sicurezza cloud.

Trasformazione dei ruoli di sicurezza

L'architettura della sicurezza, la progettazione e i ruoli operativi sono in fase di trasformazione significativa delle responsabilità e dei processi. Questa trasformazione è simile alla trasformazione basata sul cloud dei ruoli dell'infrastruttura e della piattaforma. Questa trasformazione del ruolo di sicurezza è stata guidata da più fattori:

• Man mano che gli strumenti di sicurezza diventano sempre più basati su SaaS, è meno necessario progettare, implementare, testare e gestire infrastrutture degli strumenti di sicurezza. Questi ruoli devono comunque supportare il ciclo di vita completo della configurazione di servizi cloud e soluzioni (incluso il miglioramento continuo) per garantire che soddisfino i requisiti di sicurezza.

• Il riconoscimento che la sicurezza è il lavoro di tutti sta guidando un approccio più collaborativo e maturo che consente ai team di sicurezza e tecnologia di collaborare:

  • I team tecnici di progettazione sono responsabili per garantire che le misure di sicurezza vengano applicate in modo efficace ai carichi di lavoro. Questo cambiamento aumenta la necessità di contesto e competenze dei team di sicurezza su come soddisfare questi obblighi in modo efficace ed efficiente.

  • I team di sicurezza passano da un ruolo di controllo qualità (leggermente antagonista) a un ruolo che consente ai team tecnici di rendere il percorso sicuro il percorso più semplice. I team di sicurezza riducono l'attrito e le barriere usando automazione, documentazione, formazione e altre strategie.

• I team di sicurezza stanno ampliando sempre più le proprie competenze per esaminare i problemi di sicurezza in più tecnologie e sistemi. Affrontano il ciclo di vita completo degli utenti malintenzionati, invece di concentrarsi su aree tecniche strette (sicurezza di rete, sicurezza degli endpoint, sicurezza delle applicazioni e sicurezza cloud, ad esempio). Il fatto che le piattaforme cloud integrano strettamente tecnologie diverse amplificano questa esigenza di sviluppo di competenze.

• L'aumento del tasso di cambiamento rispetto ai servizi cloud per la tecnologia e la sicurezza richiede che i processi di sicurezza vengano costantemente aggiornati per mantenere sincronizzati e gestire efficacemente i rischi.

• Le minacce alla sicurezza ignorano ora in modo affidabile i controlli di sicurezza basati sulla rete, quindi i team di sicurezza devono adottare un approccio Zero Trust che include identità, sicurezza delle applicazioni, sicurezza degli endpoint, sicurezza cloud, CI/CD, istruzione degli utenti e altri controlli.

• L'adozione dei processi DevOps/DevSecOps richiede che i ruoli di sicurezza siano più agili per integrare la sicurezza in modo nativo nel ciclo di vita di sviluppo accelerato della soluzione risultante.

Panoramica dei ruoli e dei team

Le sezioni seguenti forniscono indicazioni su quali team e ruoli eseguono in genere le principali funzioni di sicurezza cloud (quando queste funzioni sono presenti nell'organizzazione). È consigliabile eseguire il mapping dell'approccio esistente, cercare lacune e valutare se l'organizzazione può e deve investire per risolvere tali lacune.

I ruoli che eseguono attività di sicurezza includono i ruoli seguenti.

• Provider di servizi cloud

• Team di infrastruttura/piattaforma (architettura, progettazione e operazioni)

• Team di gestione dell'architettura, della progettazione e del comportamento di sicurezza:

  • Architetti e ingegneri della sicurezza (sicurezza dei dati, gestione delle identità e degli accessi (IAM), sicurezza di rete, server e sicurezza dei contenitori, sicurezza delle applicazioni e DevSecOps

  • Ingegneri della sicurezza del software (sicurezza delle applicazioni)

  • Gestione della postura (gestione della superficie di attacco gestione delle vulnerabilità/attacco)

• Operazioni di sicurezza (SecOps/SOC):

  • Analisti di valutazione (livello 1)

  • Analisti di indagine (livello 2)

  • Ricerca di minacce

  • Intelligence per le minacce

  • Progettazione del rilevamento

• Governance della sicurezza, rischio e conformità (GRC)

• Formazione e consapevolezza sulla sicurezza

È fondamentale assicurarsi che tutti comprendano il proprio ruolo nella sicurezza e come lavorare con altri team. È possibile raggiungere questo obiettivo documentando i processi di sicurezza tra team e un modello di responsabilità condivisa per i team tecnici. In questo modo è possibile evitare rischi e sprechi da gap di copertura e da sforzi sovrapposti. Consente inoltre di evitare errori comuni (antipattern), ad esempio i team che selezionano soluzioni di autenticazione e crittografia deboli o anche tentano di crearne uno personalizzato.

Provider di servizi cloud

I provider di servizi cloud sono membri del team virtuale che forniscono funzioni e funzionalità di sicurezza per la piattaforma cloud sottostante. Alcuni provider di servizi cloud forniscono anche funzionalità e funzionalità di sicurezza che i team possono usare per gestire il comportamento di sicurezza e gli eventi imprevisti. Per altre informazioni sulle prestazioni dei provider di servizi cloud, vedere il modello di responsabilità condivisa del cloud.

Molti provider di servizi cloud forniscono informazioni sulle procedure di sicurezza e sui controlli su richiesta o tramite un portale come il portale microsoft service trust portal.

Team di infrastruttura/piattaforma (architettura, progettazione e operazioni)

I team di infrastruttura/piattaforma, progettazione e operazioni implementano e integrano i controlli di sicurezza, privacy e conformità cloud nell'infrastruttura cloud e negli ambienti della piattaforma (tra server, contenitori, rete, identità e altri componenti tecnici).

I ruoli di progettazione e operazioni possono concentrarsi principalmente sui sistemi cloud o di integrazione continua e distribuzione continua (CI/CD) oppure possono lavorare in una gamma completa di cloud, CI/CD, locali e altre infrastrutture e piattaforme.

Questi team sono responsabili di soddisfare tutti i requisiti di disponibilità, scalabilità, sicurezza, privacy e altri requisiti per i servizi cloud dell'organizzazione che ospitano carichi di lavoro aziendali. Collaborano con esperti di sicurezza, rischio, conformità e privacy per ottenere risultati che combinano e bilanciano tutti questi requisiti.

Team di gestione dell'architettura, della progettazione e del comportamento di sicurezza

I team di sicurezza collaborano con i ruoli dell'infrastruttura e della piattaforma (e altri) per convertire la strategia di sicurezza, i criteri e gli standard in architetture, soluzioni e modelli di progettazione interattivi. Questi team si concentrano sull'abilitazione del successo della sicurezza dei team cloud valutando e influenzando la sicurezza dell'infrastruttura e i processi e gli strumenti usati per gestirlo. Di seguito sono riportate alcune delle attività comuni eseguite dai team di sicurezza per l'infrastruttura:

• Architetti e ingegneri della sicurezza adattano criteri di sicurezza, standard e linee guida per gli ambienti cloud per progettare e implementare controlli in collaborazione con le controparti dell'infrastruttura o della piattaforma. Architetti e ingegneri della sicurezza aiutano con un'ampia gamma di elementi, tra cui:

  • Tenant/sottoscrizioni. Architetti e ingegneri della sicurezza collaborano con architetti e ingegneri dell'infrastruttura e architetti di accesso (identità, rete, app e altri) per stabilire configurazioni di sicurezza per tenant, sottoscrizioni e account cloud tra provider di servizi cloud (monitorati dai team di gestione del comportamento di sicurezza).

  • IAM. Gli architetti di accesso (identità, rete, app e altri) collaborano con tecnici delle identità e team operativi e di infrastruttura/piattaforma per progettare, implementare e gestire soluzioni di gestione degli accessi. Queste soluzioni proteggono dall'uso non autorizzato degli asset aziendali dell'organizzazione, consentendo agli utenti autorizzati di seguire i processi aziendali per accedere in modo semplice e sicuro alle risorse aziendali. Questi team lavorano su soluzioni come directory di identità e soluzioni Single Sign-On (SSO), autenticazione senza password e a più fattori (MFA), soluzioni di accesso condizionale basato sul rischio, identità del carico di lavoro, gestione di identità/accesso con privilegi (PIM/PAM), infrastruttura cloud e gestione entitlement (CIEM) e altro ancora. Questi team collaborano anche con tecnici e operazioni di rete per progettare, implementare e gestire soluzioni SSE (Security Service Edge). I team del carico di lavoro possono sfruttare queste funzionalità per offrire accesso semplice e più sicuro ai singoli componenti del carico di lavoro e delle applicazioni.

  • Sicurezza dei dati. Architetti e ingegneri della sicurezza collaborano con architetti e ingegneri di intelligenza artificiale e dati per aiutare i team di infrastruttura/piattaforma a stabilire funzionalità di sicurezza dei dati fondamentali per tutti i dati e le funzionalità avanzate che possono essere usate per classificare e proteggere i dati nei singoli carichi di lavoro. Per altre informazioni sulla sicurezza dei dati di base, vedere il benchmark sulla protezione dei dati di Microsoft. Per altre informazioni sulla protezione dei dati nei singoli carichi di lavoro, vedere le linee guida di Well-Architected Framework.

  • Sicurezza di rete. Architetti e ingegneri della sicurezza collaborano con architetti e ingegneri di rete per aiutare i team di infrastruttura/piattaforma a stabilire funzionalità di sicurezza di rete fondamentali come la connettività al cloud (linee private/lease), strategie di accesso remoto e soluzioni, firewall in ingresso e in uscita, web application firewall (WAF) e segmentazione di rete. Questi team collaborano anche con architetti di identità, ingegneri e operazioni per progettare, implementare e gestire soluzioni SSE. I team del carico di lavoro possono sfruttare queste funzionalità per fornire protezione o isolamento discreti dei singoli componenti del carico di lavoro e dell'applicazione.

  • Server e sicurezza dei contenitori. Architetti e ingegneri della sicurezza collaborano con architetti e ingegneri dell'infrastruttura per aiutare i team dell'infrastruttura/piattaforma a stabilire funzionalità di sicurezza fondamentali per server, macchine virtuali (VM), contenitori, orchestrazione/gestione, CI/CD e sistemi correlati. Questi team stabiliscono processi di individuazione e inventario, configurazioni di base di sicurezza/benchmark, processi di manutenzione e applicazione di patch, consentire l'elenco di file binari eseguibili, immagini modello, processi di gestione e altro ancora. I team del carico di lavoro possono anche sfruttare queste funzionalità fondamentali dell'infrastruttura per garantire la sicurezza per server e contenitori per singoli componenti del carico di lavoro e dell'applicazione.

  • Nozioni di base sulla sicurezza software (per la sicurezza delle applicazioni e DevSecOps). Gli architetti e i tecnici della sicurezza collaborano con i tecnici della sicurezza software per aiutare i team dell'infrastruttura/piattaforma a stabilire funzionalità di sicurezza delle applicazioni che possono essere usate da singoli carichi di lavoro, analisi del codice, strumenti sbom (Software Bill of Materials), WAFs e analisi delle applicazioni. Vedere Controlli DevSecOps per altre informazioni su come stabilire un ciclo di vita di sviluppo della sicurezza (SDL). Per altre informazioni sul modo in cui i team del carico di lavoro usano queste funzionalità, vedere le linee guida sul ciclo di vita dello sviluppo della sicurezza in Well-Architected Framework.

• I tecnici della sicurezza software valutano codice, script e altre logiche automatizzate usate per gestire l'infrastruttura, tra cui infrastruttura come codice (IaC), flussi di lavoro CI/CD e qualsiasi altro strumento o applicazioni personalizzati. Questi tecnici devono essere impegnati a proteggere il codice formale in applicazioni compilate, script, configurazioni di piattaforme di automazione e qualsiasi altra forma di codice eseguibile o script che potrebbe consentire agli utenti malintenzionati di modificare il funzionamento del sistema. Questa valutazione può comportare semplicemente l'esecuzione di un'analisi del modello di minaccia di un sistema o potrebbe comportare la revisione del codice e gli strumenti di analisi della sicurezza. Per altre informazioni su come stabilire un SDL, vedere le linee guida per le procedure SDL.

• La gestione del comportamento (gestione delle vulnerabilità/gestione della superficie di attacco) è il team di sicurezza operativo incentrato sull'abilitazione della sicurezza per i team tecnici. La gestione del comportamento consente a questi team di classificare in ordine di priorità e implementare controlli per bloccare o attenuare le tecniche di attacco. I team di gestione del comportamento lavorano in tutti i team operativi tecnici (inclusi i team cloud) e spesso fungono da mezzo principale per comprendere i requisiti di sicurezza, i requisiti di conformità e i processi di governance.

  La gestione del comportamento spesso funge da centro di eccellenza (CoE) per i team dell'infrastruttura di sicurezza, analogamente al modo in cui i software engineer spesso fungono da coE per la sicurezza per i team di sviluppo di applicazioni. Le attività tipiche per questi team includono quanto segue.

  • Monitorare il comportamento di sicurezza. Monitorare tutti i sistemi tecnici usando strumenti di gestione del comportamento, ad esempio Microsoft Security Exposure Management, Gestione delle autorizzazioni di Microsoft Entra, vulnerabilità non Microsoft e EASM (External Attack Surface Management) e strumenti CIEM e strumenti personalizzati per il comportamento di sicurezza e dashboard. Inoltre, la gestione del comportamento esegue l'analisi per fornire informazioni dettagliate tramite:

    • Prevedere percorsi di attacco altamente probabili e dannosi. Gli utenti malintenzionati "pensano nei grafici" e cercano percorsi per i sistemi critici per l'azienda concatenando più asset e vulnerabilità in diversi sistemi (ad esempio, compromettere gli endpoint utente, quindi usare l'hash/ticket per acquisire credenziali di amministratore, quindi accedere ai dati critici per l'azienda). I team di gestione del comportamento collaborano con architetti e ingegneri della sicurezza per individuare e mitigare questi rischi nascosti, che non vengono sempre visualizzati negli elenchi tecnici e nei report.

    • Esecuzione di valutazioni della sicurezza per esaminare le configurazioni del sistema e i processi operativi per ottenere informazioni più approfondite e informazioni dettagliate oltre i dati tecnici dagli strumenti di comportamento di sicurezza. Queste valutazioni possono assumere la forma di conversazioni di individuazione informali o esercizi formali di modellazione delle minacce.

  • Assistenza con la definizione delle priorità. Aiutare i team tecnici a monitorare in modo proattivo le risorse e definire le priorità per il lavoro di sicurezza. La gestione del comportamento consente di mettere il lavoro di mitigazione dei rischi nel contesto considerando l'impatto sul rischio di sicurezza (informato dall'esperienza, i report degli eventi imprevisti delle operazioni di sicurezza e altre informazioni sulle minacce, business intelligence e altre origini) oltre ai requisiti di conformità della sicurezza.

  • Allenarsi, mentore e campione. Aumentare le competenze e le conoscenze di sicurezza dei team tecnici attraverso la formazione, il mentoring di individui e il trasferimento informale delle conoscenze. I ruoli di gestione del comportamento possono anche lavorare con i ruoli di preparazione/formazione e formazione dell'organizzazione e formazione sulla sicurezza e sui ruoli di coinvolgimento per la formazione formale sulla sicurezza e la configurazione della sicurezza all'interno di team tecnici che eseguono l'istruzione e l'istruzione dei colleghi sulla sicurezza.

  • Identificare le lacune e sostenere le correzioni. Identificare le tendenze complessive, le lacune dei processi, gli strumenti e altre informazioni dettagliate sui rischi e sulle mitigazioni. I ruoli di gestione del comportamento collaborano e comunicano con architetti e ingegneri della sicurezza per sviluppare soluzioni, creare un caso per le soluzioni di finanziamento e facilitare l'implementazione di correzioni.

  • Coordinare le operazioni di sicurezza (SecOps). Aiutare i team tecnici a lavorare con i ruoli SecOps, ad esempio la progettazione del rilevamento e i team di ricerca delle minacce. Questa continuità tra tutti i ruoli operativi consente di garantire che i rilevamenti siano implementati correttamente e implementati correttamente, i dati di sicurezza sono disponibili per l'analisi degli eventi imprevisti e la ricerca delle minacce, i processi sono in atto per la collaborazione e altro ancora.

  • Fornire report. Fornire report tempestivi e accurati su eventi imprevisti, tendenze e metriche delle prestazioni per la gestione senior e gli stakeholder per aggiornare i processi di rischio dell'organizzazione.

  I team di gestione del comportamento si evolvono spesso dai ruoli di gestione delle vulnerabilità software esistenti per affrontare il set completo di tipi di vulnerabilità funzionali, di configurazione e operativi descritti nel modello di riferimento Open Group Zero Trust. Ogni tipo di vulnerabilità può consentire agli utenti non autorizzati (inclusi gli utenti malintenzionati) di assumere il controllo del software o dei sistemi, consentendo loro di causare danni alle risorse aziendali.

  • Le vulnerabilità funzionali si verificano nella progettazione o nell'implementazione del software. Possono consentire il controllo non autorizzato del software interessato. Queste vulnerabilità potrebbero essere difetti nel software che i propri team hanno sviluppato o difetti nel software commerciale o open source (in genere rilevati da un identificatore di vulnerabilità ed esposizioni comuni).

  • Le vulnerabilità di configurazione sono configurazioni errate dei sistemi che consentono l'accesso non autorizzato alle funzionalità di sistema. Queste vulnerabilità possono essere introdotte durante le operazioni in corso, note anche come deviazioni della configurazione. Possono anche essere introdotti durante la distribuzione iniziale e la configurazione di software e sistemi o da impostazioni predefinite di sicurezza deboli di un fornitore. Alcuni esempi comuni prevedono:

    • Oggetti orfani che consentono l'accesso non autorizzato a elementi come record DNS e appartenenza a gruppi.

    • Autorizzazioni o ruoli amministrativi eccessivi per le risorse.

    • Uso di un protocollo di autenticazione o di un algoritmo di crittografia più debole che presenta problemi di sicurezza noti.

    • Configurazioni predefinite deboli o password predefinite.

  • Le vulnerabilità operative sono punti deboli nei processi operativi standard e nelle procedure che consentono l'accesso non autorizzato o il controllo dei sistemi. Alcuni esempi:

    • Gli amministratori usano account condivisi anziché i propri account per eseguire attività con privilegi.

    • Uso di configurazioni di "esplorazione" che creano percorsi di elevazione dei privilegi che possono essere abusati da utenti malintenzionati. Questa vulnerabilità si verifica quando gli account amministrativi con privilegi elevati accedono a dispositivi utente e workstation con attendibilità inferiore (ad esempio workstation utente standard e dispositivi di proprietà dell'utente), a volte tramite jump server che non attenuano efficacemente questi rischi. Per altre informazioni, vedere Protezione dell'accesso con privilegi e dei dispositivi di accesso con privilegi.

Operazioni di sicurezza (SecOps/SOC)

Il team SecOps viene talvolta definito soC (Security Operations Center). Il team SecOps si concentra sulla ricerca rapida e sulla rimozione dell'accesso antagonista alle risorse dell'organizzazione. Collaborano in stretta collaborazione con le operazioni tecnologiche e i team di progettazione. I ruoli SecOps possono funzionare in tutte le tecnologie dell'organizzazione, tra cui l'IT tradizionale, la tecnologia operativa (OT) e Internet delle cose (IoT). Di seguito sono riportati i ruoli SecOps che spesso interagiscono con i team cloud:

• Analisti di valutazione (livello 1). Risponde ai rilevamenti degli eventi imprevisti per tecniche di attacco note e segue procedure documentate per risolverli rapidamente (o inoltrarli agli analisti di indagine in base alle esigenze). A seconda dell'ambito secops e del livello di maturità, questo potrebbe includere rilevamenti e avvisi dalla posta elettronica, soluzioni antimalware degli endpoint, servizi cloud, rilevamenti di rete o altri sistemi tecnici.

• Analisti dell'indagine (livello 2). Risponde alle indagini sugli eventi imprevisti con maggiore complessità e gravità superiore che richiedono più esperienza e competenze (oltre a procedure di risoluzione ben documentate). Questo team in genere analizza gli attacchi condotti da avversari e attacchi umani vivi che influiscono su più sistemi. Lavora in stretta collaborazione con i team di progettazione e operazioni tecnologiche per analizzare gli eventi imprevisti e risolverli.

• Ricerca delle minacce. Cerca in modo proattivo minacce nascoste all'interno del patrimonio tecnico che hanno evaso meccanismi di rilevamento standard. Questo ruolo usa analisi avanzate e indagini basate su ipotesi.

• Threat intelligence. Raccoglie e distribuisce informazioni su utenti malintenzionati e minacce a tutti gli stakeholder, tra cui business, tecnologia e sicurezza. I team di intelligence sulle minacce eseguono ricerche, condividono i risultati (formalmente o informalmente) e li distribuiscono a vari stakeholder, tra cui il team di sicurezza del cloud. Questo contesto di sicurezza consente a questi team di rendere i servizi cloud più resilienti agli attacchi perché usano informazioni sugli attacchi reali nella progettazione, nell'implementazione, nei test e nelle operazioni e nel miglioramento continuo.

• Progettazione del rilevamento. Crea rilevamenti di attacchi personalizzati e personalizza i rilevamenti degli attacchi forniti dai fornitori e dalla community più ampia. Questi rilevamenti di attacchi personalizzati integrano i rilevamenti forniti dal fornitore per gli attacchi comuni che si trovano comunemente negli strumenti di rilevamento e risposta estesi (XDR) e alcuni strumenti di informazioni sulla sicurezza e gestione degli eventi (SIEM). I tecnici di rilevamento collaborano con i team di sicurezza cloud per identificare le opportunità di progettazione e implementazione di rilevamenti, i dati necessari per supportarli e le procedure di risposta/ripristino per i rilevamenti.

Governance della sicurezza, rischio e conformità

Governance della sicurezza, rischio e conformità (GRC) è un set di discipline correlate che integrano il lavoro tecnico dei team di sicurezza con obiettivi e aspettative dell'organizzazione. Questi ruoli e team possono essere ibridi di due o più discipline o possono essere ruoli discreti. I team cloud interagiscono con ognuna di queste discipline nel corso del ciclo di vita della tecnologia cloud:

• La disciplina di governance è una funzionalità fondamentale che si concentra sulla garanzia che l'organizzazione implementi costantemente tutti gli aspetti della sicurezza. I team di governance si concentrano sui diritti decisionali (chi prende le decisioni) e sui framework di processo che si connettono e guidano i team. Senza governance efficace, un'organizzazione con tutti i controlli, i criteri e la tecnologia corretti possono comunque essere violati da utenti malintenzionati che hanno trovato aree in cui le difese previste non vengono implementate correttamente, completamente o affatto.

• La disciplina di gestione dei rischi è incentrata su come garantire che l'organizzazione stia valutando, comprendendo e mitigando efficacemente i rischi. I ruoli di gestione dei rischi collaborano con molti team nell'organizzazione per creare una rappresentazione chiara del rischio dell'organizzazione e mantenerla aggiornata. Poiché molti servizi aziendali critici possono essere ospitati nell'infrastruttura cloud e nelle piattaforme, i team cloud e di rischio devono collaborare per valutare e gestire questo rischio aziendale. Inoltre, la sicurezza della supply chain è incentrata sui rischi associati a fornitori esterni, componenti open source e partner.

• La disciplina di conformità garantisce che i sistemi e i processi siano conformi ai requisiti normativi e ai criteri interni. Senza questa disciplina, l'organizzazione potrebbe essere esposta al rischio correlato alla non conformità con obblighi esterni (multe, responsabilità, perdita di ricavi dall'incapacità di operare in alcuni mercati e altro ancora). I requisiti di conformità in genere non possono tenere il passo con la velocità dell'evoluzione degli utenti malintenzionati, ma rappresentano comunque un'origine importante dei requisiti.

Tutte e tre queste discipline operano in tutte le tecnologie e nei sistemi per favorire i risultati dell'organizzazione in tutti i team. Tutti e tre si basano anche sul contesto che ottengono tra loro e traggono vantaggio in modo significativo dai dati attuali ad alta fedeltà sulle minacce, sulle attività aziendali e sull'ambiente tecnologico. Queste discipline si basano anche sull'architettura per esprimere una visione pratica che può essere implementata e la formazione sulla sicurezza e i criteri per stabilire regole e guidare i team attraverso le numerose decisioni quotidiane.

I team tecnici e operativi del cloud possono lavorare con ruoli di gestione del comportamento, team di conformità e controllo, architettura e progettazione della sicurezza o ruoli ciSO (Chief Information Security Officer) negli argomenti relativi all'archiviazione con ridondanza geografica dei dati.

Istruzione e criteri per la sicurezza

Le organizzazioni devono garantire che tutti i ruoli abbiano un'alfabetizzazione di sicurezza di base e indicazioni su ciò che si prevede di fare per quanto riguarda la sicurezza e come farlo. Per raggiungere questo obiettivo, è necessaria una combinazione di criteri scritti e istruzione. L'istruzione per i team cloud può essere un mentoring informale da parte di professionisti della sicurezza che lavorano direttamente con loro oppure può essere un programma formale con curriculum documentato e promotori della sicurezza designati.

In un'organizzazione più ampia, i team di sicurezza collaborano con l'idoneità dell'organizzazione/formazione e formazione sulla sicurezza e i ruoli di impegno per la formazione formale sulla sicurezza e la configurazione dei promotori della sicurezza all'interno dei team tecnici per promuovere e educare i propri colleghi alla sicurezza.

L'istruzione e i criteri di sicurezza devono aiutare ogni ruolo a comprendere:

• Perché. Mostra ogni ruolo per cui la sicurezza è importante per loro e i relativi obiettivi nel contesto delle responsabilità del ruolo. Se le persone non capiscono chiaramente il motivo per cui la sicurezza è importante per loro, lo giudicano non importante e passano a qualcos'altro.

• Che cosa. Riepilogare le attività di sicurezza necessarie nel linguaggio già compreso. Se le persone non sanno cosa devono fare, presupporranno che la sicurezza non sia importante o rilevante per loro e passare a qualcos'altro.

• Come. Assicurarsi che ogni ruolo disponga di istruzioni chiare su come applicare le linee guida per la sicurezza nel proprio ruolo. Se gli utenti non sanno come eseguire effettivamente le operazioni da eseguire (ad esempio, i server patch, identificare se un collegamento è un collegamento di phishing, segnalare correttamente un messaggio, esaminare il codice o eseguire un modello di minaccia), non riusciranno e passeranno a qualcos'altro.

Scenario di esempio: interoperabilità tipica tra i team

Quando un'organizzazione distribuisce e operazionalizza un WAF, diversi team di sicurezza devono collaborare per garantire la distribuzione, la gestione e l'integrazione efficaci nell'infrastruttura di sicurezza esistente. Ecco come l'interoperabilità tra i team potrebbe apparire in un'organizzazione di sicurezza aziendale:

1. Pianificazione e progettazione
   1. Il team di governance identifica la necessità di una sicurezza avanzata delle applicazioni Web e alloca il budget per un WAF.
   2. L'architetto della sicurezza di rete progetta la strategia di distribuzione WAF, assicurandosi che si integra perfettamente con i controlli di sicurezza esistenti e si allinea all'architettura di sicurezza dell'organizzazione.
2. Implementazione
   1. Il tecnico della sicurezza di rete distribuisce il WAF in base alla progettazione dell'architetto, configurandola per proteggere le applicazioni Web specifiche e abilita il monitoraggio.
   2. Il tecnico IAM configura i controlli di accesso, assicurando che solo il personale autorizzato possa gestire il WAF.
3. Monitoraggio e gestione
   1. Il team di gestione del comportamento fornisce istruzioni per il SOC per configurare il monitoraggio e gli avvisi per WAF e per configurare i dashboard per tenere traccia dell'attività WAF.
   2. I team di progettazione di intelligence e rilevamento delle minacce aiutano a sviluppare piani di risposta per gli eventi imprevisti che coinvolgono waf e per condurre simulazioni per testare questi piani.
4. Gestione dei rischi e della conformità
   1. Il responsabile della gestione dei rischi e della conformità esamina la distribuzione di WAF per assicurarsi che soddisfi i requisiti normativi e eseduca controlli periodici.
   2. Il data security engineer garantisce che le misure di registrazione e protezione dei dati di WAF siano conformi alle normative sulla privacy dei dati.
5. Miglioramento continuo e formazione
   1. Il tecnico DevSecOps integra la gestione WAF nella pipeline CI/CD, assicurandosi che gli aggiornamenti e le configurazioni siano automatizzati e coerenti.
   2. Lo specialista di formazione e coinvolgimento della sicurezza sviluppa e fornisce programmi di formazione per garantire che tutto il personale pertinente comprenda come usare e gestire il WAF in modo efficace.
   3. Il membro del team di governance del cloud esamina i processi di distribuzione e gestione di WAF per assicurarsi che siano allineati ai criteri e agli standard dell'organizzazione.

Collaborando in modo efficace, questi ruoli assicurano che il WAF venga distribuito correttamente e monitorato, gestito e migliorato in modo continuo per proteggere le applicazioni Web dell'organizzazione dalle minacce in continua evoluzione.

Passaggio successivo