Elementi consigliati per la risposta agli incidenti di sicurezza

Si applica alla raccomandazione della checklist di sicurezza ben progettata: Power Platform

Questa guida descrive gli elementi consigliati per l'implementazione di una risposta agli incidenti di sicurezza per un carico di lavoro. Se si verifica una compromissione della sicurezza di un sistema, un approccio sistematico alla risposta agli incidenti aiuta a ridurre il tempo necessario per identificare, gestire e mitigare gli incidenti di sicurezza. Questi incidenti possono minacciare la riservatezza, l'integrità e la disponibilità dei sistemi software e dei dati.

La maggior parte delle aziende dispone di un team operativo di sicurezza centrale (noto anche come Centro Operazioni per la sicurezza [SOC] o SecOps). La responsabilità del team operativo di sicurezza è quella di rilevare, assegnare priorità e classificare rapidamente potenziali attacchi. Il team monitora inoltre i dati di telemetria relativi alla sicurezza e indaga sulle violazioni della sicurezza.

Tuttavia, hai anche la responsabilità di proteggere il tuo carico di lavoro. È importante che qualsiasi attività di comunicazione, indagine e ricerca sia uno sforzo di collaborazione tra il team del carico di lavoro e il team SecOps.

Questa guida fornisce consigli a te e al tuo team del carico di lavoro per aiutarti a rilevare, classificare e indagare rapidamente sugli attacchi.

Definizioni

Strategie di progettazione chiave

Tu e il tuo team eseguite operazioni di risposta agli incidenti quando un segnale o un avviso indica un potenziale incidente di sicurezza. Gli avvisi ad alta fedeltà contengono un ampio contesto di sicurezza che semplifica il processo decisionale degli analisti. Gli avvisi ad alta fedeltà generano un numero minimo di falsi positivi. Questa guida presuppone che un sistema di avviso filtri i segnali a bassa fedeltà e si concentri su avvisi ad alta fedeltà che potrebbero indicare un incidente reale.

Assegnare una notifica di incidente

Gli avvisi di sicurezza devono raggiungere le persone appropriate nel tuo team e nella tua organizzazione. Stabilisci un punto di contatto designato nel tuo team del carico di lavoro per ricevere notifiche sugli incidenti. Queste notifiche dovrebbero includere quante più informazioni possibili sulla risorsa compromessa e sul sistema. L'avviso deve includere i passaggi successivi, in modo che il tuo team possa accelerare le azioni.

Ti consigliamo di registrare e gestire le notifiche e le azioni degli incidenti utilizzando strumenti specializzati che mantengano una traccia di controllo. Utilizzando strumenti standard, è possibile conservare le prove che potrebbero essere necessarie per potenziali indagini legali. Cerca opportunità per implementare l'automazione in grado di inviare notifiche in base alle responsabilità delle parti responsabili. Mantieni una chiara catena di comunicazione e reporting durante un incidente.

Sfrutta le soluzioni SIEM (informazioni di sicurezza e gestione degli eventi) e le soluzioni SOAR (Security Orchestration Automated Response) fornite dalla tua organizzazione. In alternativa, puoi procurarti strumenti di gestione degli incidenti e incoraggiare la tua organizzazione a standardizzarli per tutti i team del carico di lavoro.

Indagare con un team di triage

Il membro del team che riceve una notifica di incidente è responsabile dell'impostazione di un processo di triage che coinvolga le persone appropriate in base ai dati disponibili. Il team di triage, spesso chiamato team bridge, deve concordare la modalità e il processo di comunicazione. Questo incidente richiede discussioni asincrone o chiamate bridge? In che modo il team dovrebbe monitorare e comunicare lo stato di avanzamento delle indagini? Dove il team può accedere alle risorse dell'incidente?

La risposta agli incidenti è un motivo cruciale per mantenere aggiornata la documentazione, come il layout dell'architettura del sistema, le informazioni a livello di componente, la classificazione della privacy o della sicurezza, i proprietari e i punti chiave di contatto. Se le informazioni sono imprecise o obsolete, il team bridge perde tempo prezioso cercando di comprendere il funzionamento del sistema, chi è responsabile di ogni area e quale potrebbe essere l'effetto dell'evento.

Per ulteriori indagini, coinvolgere le persone appropriate. È possibile includere un responsabile degli incidenti, un responsabile della sicurezza o un lead incentrato sul carico di lavoro. Per mantenere incentrato il triage, escludi le persone esterne all'ambito del problema. A volte diversi team separati esaminano l'incidente. Potrebbe esserci un team che inizialmente analizza il problema e tenta di attenuare l'evento imprevisto e un altro team specializzato che potrebbe eseguire analisi forensi per un'indagine approfondita per verificare problemi di ampia scala. È possibile mettere in quarantena l'ambiente del carico di lavoro per consentire al team forense di eseguire le indagini. In alcuni casi, lo stesso team potrebbe gestire l'intera indagine.

Nella fase iniziale, il team di triage è responsabile della determinazione del vettore potenziale e del relativo effetto sulla riservatezza, l'integrità e la disponibilità (denominata anche CIA) del sistema.

Nelle categorie della CIA, assegnare un livello di gravità iniziale che indica la profondità del danno e l'urgenza della correzione. Questo livello dovrebbe essere modificato nel tempo, poiché altre informazioni vengono individuate nei livelli di valutazione.

Nella fase di individuazione è importante determinare un corso immediato di azioni e piani di comunicazione. Sono state apportate modifiche allo stato in esecuzione del sistema? Come si può contenere l'attacco per fermare l'ulteriore sfruttamento? Il team deve inviare comunicazioni interne o esterne, ad esempio una divulgazione responsabile? Prendi in considerazione il tempo di rilevamento e di risposta. Potrebbe essere legalmente obbligatorio segnalare alcuni tipi di violazioni a un'autorità normativa entro un periodo di tempo specifico, generalmente ore o giorni.

Se decidi di arrestare il sistema, i passaggi successivi portano al processo di ripristino di emergenza del carico di lavoro.

Se non si arresta il sistema, determina come correggere l'evento imprevisto senza influire sulla funzionalità del sistema.

Ripristino da un incidente

Tratta un incidente di sicurezza come un disastro. Se la correzione richiede un ripristino completo, utilizza meccanismi di ripristino di emergenza adeguati dal punto di vista della sicurezza. Il processo di ripristino deve prevenire la possibilità di ricorrenza. In caso contrario, il ripristino da un backup danneggiato ripropone il problema. La ridistribuzione di un sistema con la stessa vulnerabilità porta allo stesso incidente. Convalida passaggi e processi di failover e failback.

Se il sistema continua a funzionare, valuta l'effetto sulle parti funzionanti del sistema. Continuare a monitorare il sistema per garantire che altri obiettivi di affidabilità e prestazioni siano raggiunti o riadattati implementando processi di degradazione adeguati. Non compromettere la privacy a causa della mitigazione.

La diagnosi è un processo interattivo fino all'identificazione del vettore e di una potenziale soluzione e fallback. Dopo la diagnosi, il team lavora alla riparazione, che identifica e applica la soluzione richiesta entro un periodo accettabile.

Le metriche di ripristino misurano il tempo necessario per risolvere un problema. In caso di blocco potrebbe esserci urgenza riguardo ai tempi di ripristino. Per stabilizzare il sistema, è necessario del tempo per applicare correzioni, patch, test e distribuire gli aggiornamenti. Determina strategie di contenimento per prevenire ulteriori danni e la diffusione dell'incidente. Sviluppa procedure di eradicazione per eliminare completamente la minaccia dall'ambiente.

Compromesso: Esiste un compromesso tra obiettivi di affidabilità e tempi di ripristino. Durante un incidente imprevisto, è probabile che non soddisfi altri requisiti non funzionali o funzionali. Ad esempio, potrebbe essere necessario disabilitare parti del sistema durante l'analisi dell'incidente oppure potrebbe anche essere necessario prendere offline l'intero sistema finché non si determina l'ambito dell'incidente. I responsabili delle decisioni aziendali devono decidere esplicitamente quali sono gli obiettivi accettabili durante l'incidente. Specifica chiaramente la persona responsabile di tale decisione.

Informazioni da un incidente

Un incidente rivela lacune o punti vulnerabili in una progettazione o un'implementazione. Si tratta di un'opportunità di miglioramento guidata da lezioni sugli aspetti di progettazione tecnica, automazione, processi di sviluppo di prodotti che includono test ed efficacia del processo di risposta agli incidenti. Mantenere record di incidenti dettagliate, comprese le azioni intraprese, le sequenze temporali e i risultati.

Ti consigliamo vivamente di condurre revisioni strutturate post-incidente, come analisi delle cause di origine e retrospettive. Tieni traccia e stabilisci la priorità dei risultati di tali revisioni e considera l'utilizzo di ciò che impari nelle future progettazioni dei carichi di lavoro.

I piani di miglioramento dovrebbero includere aggiornamenti alle esercitazioni e ai test di sicurezza, come esercitazioni di continuità aziendale e ripristino di emergenza (BCDR). Utilizza la compromissione della sicurezza come scenario per eseguire un'esercitazione BCDR. Le esercitazioni possono convalidare il funzionamento dei processi documentati. Non dovrebbero esserci più playbook di risposta agli incidenti. Utilizza un'unica origine che puoi adattare in base alle dimensioni dell'incidente e alla diffusione o alla localizzazione dell'effetto. Le esercitazioni si basano su situazioni ipotetiche. Conduci esercitazioni in un ambiente a basso rischio e includi la fase di apprendimento nelle esercitazioni.

Condurre revisioni post-incidente o post-mortem, per identificare i punti deboli nel processo di risposta e le aree di miglioramento. Sulla base delle lezioni apprese dall'incidente, aggiorna il piano di risposta all'incidente (IRP) e i controlli di sicurezza.

Inviare la comunicazione necessaria

Implementare un piano di comunicazione per avvisare gli utenti di un'interruzione e informare le parti interessate interne sulla riparazione e sui miglioramenti. Altre persone nell'organizzazione devono essere informate di eventuali modifiche alla baseline di sicurezza del carico di lavoro per prevenire incidenti futuri.

Genera report sugli incidenti per uso interno e, se necessario, per conformità normativa o scopi legali. Inoltre, adottare un report in formato standard (un modello di documento con sezioni definite) che il team SOC utilizza per tutti gli incidenti. Assicurati che a ogni incidente sia associata una segnalazione prima di chiudere l'indagine.

Facilitazione di Power Platform

Le sezioni seguenti descrivono i meccanismi che è possibile utilizzare come parte delle procedure di risposta agli incidenti di sicurezza.

Microsoft Sentinella

Microsoft La soluzione Sentinel per Microsoft Power Platform consente ai clienti di rilevare varie attività sospette, tra cui:

• Esecuzione Power Apps da aree geografiche non autorizzate
• Distruzione di dati sospetti da parte di Power Apps
• Eliminazione di massa di Power Apps
• Attacchi di phishing tramite Power Apps
• Attività dei flussi Power Automate da parte dei dipendenti in partenza
• Connettori Microsoft Power Platform aggiunti a un ambiente
• Aggiornamento o rimozione dei criteri di prevenzione della perdita dei dati di Microsoft Power Platform

Per ulteriori informazioni, vedere Microsoft Soluzione Sentinel per Microsoft Power Platform panoramica.

Microsoft Registrazione delle attività di competenza

Power Apps, Power Automate, i connettori, i dati prevenzione delle perdite e la Power Platform registrazione delle attività amministrative vengono monitorati e visualizzati dal Microsoft portale di conformità Purview.

Per altre informazioni, vedi:

• Power Apps registrazione delle attività
• Power Automate registrazione delle attività
• Copilot Studio registrazione delle attività
• Power Pages registrazione delle attività
• Power Platform registrazione attività connettore
• Registrazione attività dati prevenzione delle perdite
• Power Platform registrazione delle attività delle azioni amministrative
• Microsoft Dataverse e registrazione delle attività delle app basate su modelli

Customer Lockbox

La maggior parte delle operazioni, del supporto e della risoluzione dei problemi eseguiti dal personale (inclusi i sub-responsabili) non richiedono l'accesso ai dati dei clienti. Microsoft Con Power Platform Customer Lockbox, Microsoft fornisce un'interfaccia che consente ai clienti di esaminare e approvare (o rifiutare) le richieste di accesso ai dati nelle rare occasioni in cui è necessario l'accesso ai dati dei clienti. Viene utilizzato nei casi in cui un tecnico deve accedere ai dati del cliente, sia in risposta, sia in un ticket di supporto avviato dal cliente o in un problema identificato da. Microsoft Microsoft Per ulteriori informazioni, vedi Accedere in modo sicuro ai dati dei clienti utilizzando Customer Lockbox in Power Platform e Dynamics 365.

Aggiornamenti della protezione

I team di servizio eseguono regolarmente la procedura seguente per garantire la sicurezza del sistema:

• Ricerca il servizio per identificare le possibili vulnerabilità di sicurezza.
• Valutazioni del servizio per verificare che i controlli di sicurezza chiave funzionino in modo efficace.
• Valutazioni del servizio per determinare l'esposizione a eventuali vulnerabilità identificate dal Microsoft Security risposta Center (MSRC), che monitora regolarmente i siti esterni di sensibilizzazione sulle vulnerabilità.

Questi team inoltre rilevano e registrano tutti i problemi identificati e cercano di ridurre al minimo i rischi quando necessario.

Come posso scoprire gli aggiornamenti di sicurezza?

Poiché i team di servizio si sforzano di attenuare i rischi in modo da non dover ricorrere all'interruzione del servizio, gli amministratori in genere non guardano le notifiche del Centro messaggi relative agli aggiornamenti della sicurezza. Se un aggiornamento di sicurezza richiede un impatto sul servizio, viene considerato manutenzione pianificata e viene pubblicato con la durata prevista dell'impatto e la finestra in cui viene eseguito il lavoro.

Per ulteriori informazioni sulla sicurezza, consultare Microsoft Centro protezione.

Gestire la finestra di manutenzione

Microsoft esegue regolarmente aggiornamenti e manutenzione per garantire sicurezza, prestazioni, disponibilità e per fornire nuove caratteristiche e funzionalità. Questo processo di aggiornamento offre miglioramenti per la sicurezza e servizi minori su base settimanale. Ogni aggiornamento viene distribuito area per area secondo un programma di distribuzione sicuro, organizzato in stazioni. Per informazioni sulla finestra di manutenzione predefinita per gli ambienti, vedi Criteri e comunicazioni per incidenti di servizio. Vedi anche Gestire la finestra di manutenzione.

Assicurati che il portale di registrazione di Azure includa le informazioni di contatto amministratore in modo che le operazioni di sicurezza possano essere notificate direttamente tramite un processo interno. Per altre informazioni, vedere Aggiorna impostazioni di notifica.

Allineamento organizzativo

Cloud Adoption Framework per Azure fornisce indicazioni sulla pianificazione della risposta agli incidenti e sulle operazioni di sicurezza. Per altre informazioni, vedi Operazioni di sicurezza.

Informazioni correlate

• Microsoft Soluzione Sentinel per Microsoft Power Platform panoramica
• Crea automaticamente incidenti dagli avvisi di sicurezza Microsoft
• Esegui la ricerca delle minacce end-to-end utilizzando la funzione Hunts
• Utilizzare Hunts per condurre una caccia alle minacce proattiva end-to-end in Sentinel Microsoft
• Panoramica dell'incidente risposta

Elenco di controllo della sicurezza

Fai riferimento alla serie completa di elementi consigliati.