Schemi di risposta agli incidenti

Ulteriori informazioni su Well-Architected Trust → Security Incident Response

Si verificheranno incidenti di sicurezza nonostante le misure preventive. L’architettura Trust richiede la progettazione per l’individuazione, la risposta rapida, l’indagine forense e il ripristino graduale. Questa pagina raggruppa gli schemi di risposta agli incidenti della sezione Risposta agli incidenti del pilastro Trust, che include l’architettura di rilevamento, le procedure di risposta, le funzionalità forensi e l’apprendimento post-incidente.

Schemi

Dove cercare	Che bell’aspetto
Monitoraggio evento	✅ Abilitare Monitoraggio evento per acquisire schemi di accesso, esportazioni di dati in blocco, modifiche delle autorizzazioni e attività API con instradamento alle piattaforme SIEM per la conservazione che superano i limiti di conservazione nativi
Policy sulla sicurezza delle transazioni	✅ Configurare le policy che valutano gli eventi in tempo reale per bloccare le azioni sospette, richiedere l’autenticazione step-up o attivare notifiche in base alle basi di riferimento comportamentali
Itinerario di controllo impostazioni	✅ Monitorare le modifiche alla configurazione amministrativa abilitando il rilevamento di modifiche non autorizzate con conservazione di 180 giorni
Registrazione applicazione personalizzata	✅ Implementare la registrazione degli eventi rilevanti per la sicurezza in Apex acquisendo errori di autenticazione, rifiuti di autorizzazione e schemi di input sospetti
Monitoraggio dello stato	✅ Configurare il rilevamento automatico della fluttuazione della configurazione dalle basi di riferimento di sicurezza che potrebbero indicare modifiche non autorizzate
Integrazione SIEM	✅ Instradare i registri di Monitoraggio evento alle piattaforme SIEM aziendali per la correlazione con la telemetria di sicurezza aziendale e l’analisi comportamentale
Regole di avviso	✅ Progettare regole di avviso che rilevano schemi sospetti (accesso in blocco al di fuori dell’orario di ufficio, accesso da nuove aree geografiche, inoltro rapido delle autorizzazioni al livello superiore) con valori di riferimento comportamentali per ridurre al minimo i falsi positivi
Analytics comportamentale	✅ Stabilire i valori di riferimento comportamentali abilitando il rilevamento delle anomalie per volumi di accesso ai dati insoliti, attività amministrative fuori orario e modelli di consumo API
Rilevamento multicanale	✅ Implementare il rilevamento tramite Monitoraggio evento, Sicurezza delle transazioni, Itinerario di controllo impostazioni, registrazione personalizzata e Controllo dello stato che fornisce più segnali di rilevamento indipendenti
Archiviazione registri immutabile	✅ Instradare i registri a memoria esterna immutabile che gli aggressori non possono modificare nemmeno con l’accesso amministrativo a Salesforce, garantendo l’integrità delle prove forensi

Anti-schemi

Dove cercare	Che brutto aspetto
Solo conservazione dei registri nativi	⚠️ Basandosi esclusivamente sulle finestre di conservazione native dell’itinerario di controllo Salesforce (limiti nativi Monitoraggio evento, 180 giorni Itinerario di controllo impostazioni) senza archiviazione esterna, scoprendo che i registri sono scaduti quando l’analisi richiede un’analisi storica
Nessuna base di riferimento comportamentale	⚠️ Non avere basi di riferimento comportamentali per il rilevamento dell’anomalia, generando eccessivi falsi avvisi positivi che addestrano i team di sicurezza a ignorare le notifiche
Nessuna integrazione SIEM	⚠️ Mancanza di integrazione SIEM aziendale, mancanza di opportunità di correlazione con la telemetria di sicurezza di altri sistemi che rivelerebbero schemi di compromesso più ampi
Revisione manuale del registro	⚠️ A seconda della revisione periodica manuale del registro anziché dell’avviso automatico, la scoperta di incidenti settimane o mesi dopo l’evento quando il danno è esteso
Nessuna policy sulla sicurezza delle transazioni	⚠️ Non avendo policy sulla sicurezza delle transazioni in tempo reale, mancando la capacità di bloccare le azioni sospette per prevenire i danni prima che si verifichino
Copertura incompleta	⚠️ Monitoraggio solo di sottoinsiemi di eventi rilevanti per la sicurezza (accesso ma non accesso ai dati, modifiche della configurazione ma non modifiche delle autorizzazioni)
Avvisa affaticamento	⚠️ Generazione di avvisi falsi positivi eccessivi senza sintonizzazione, formazione dei team per ignorare le notifiche, inclusi gli eventi di sicurezza legittimi

Schemi

Dove cercare	Che bell’aspetto
Confini dell’isolamento	✅ Progettare l’architettura in modo che i componenti compromessi possano essere isolati tramite la revoca dell’insieme di autorizzazioni, le modifiche delle restrizioni IP o la chiusura della sessione senza interrompere le funzioni aziendali critiche
Gestione sessioni	✅ Implementare funzionalità di chiusura rapida delle sessioni per gli account compromessi, tra cui forzare la disconnessione e l’invalidazione della sessione in tutte le sessioni attive
Revoca dell’autorizzazione	✅ Concedere privilegi tramite insiemi di autorizzazioni anziché profili di base in modo che la revoca sia rapida: la rimozione dell’assegnazione dell’insieme di autorizzazioni revoca l’accesso quando nessun profilo o altra assegnazione concede in modo indipendente la stessa autorizzazione
Restrizioni IP	✅ Configurare gli intervalli IP di accesso a livello di profilo per gli account con privilegi in modo che gli accessi da altri indirizzi vengano negati definitivamente, abilitando l’isolamento rapido a livello di rete nelle posizioni amministrative note
Congelamento degli account utente	✅ Implementare procedure di congelamento degli account che impediscono l’autenticazione preservando i dati per l’analisi senza eliminare l’account compromesso
Controlli di accesso API	✅ Progettare l’autenticazione API con funzionalità di revoca dei token che consentono un rapido isolamento degli account di integrazione compromessi
Isolamento multi-organizzazioni	✅ Per gli asset di valore elevato, valutare l’architettura multi-organizzazione che offre il massimo isolamento per i componenti critici a costo di una maggiore complessità operativa
Procedure per la rottura di emergenza del vetro	✅ Mantenere procedure di accesso documentate per l’accesso amministrativo di emergenza con controllo e convalida post-uso

Anti-schemi

Dove cercare	Che brutto aspetto
Nessun confine di isolamento	⚠️ Mancanza di confini di isolamento architettonico che richiedono l’arresto completo del sistema per contenere qualsiasi compromesso, interrompendo tutte le funzioni aziendali
Accesso eccessivamente permissivo	⚠️ Concessione di ampie autorizzazioni Modifica tutti i dati che impediscono la revoca granulare dei privilegi senza interrompere più processi aziendali
Account di servizio condivisi	⚠️ Utilizzo di un singolo account “Utente API” o “Utente integrazione” condiviso in più sistemi per impedire l’isolamento di specifiche integrazioni compromesse senza interrompere tutte le integrazioni
Nessuna restrizione IP	⚠️ Non avere elenchi IP consentiti per gli account con privilegi, mancanza di funzionalità di contenimento a livello di rete quando gli account sono compromessi
Nessuna gestione sessione	⚠️ Mancanza di funzionalità di terminazione della sessione che richiedono la reimpostazione della password come unico modo per forzare la disconnessione, introducendo ritardi durante le finestre di risposta critiche
Nessuna procedura di emergenza	⚠️ Non avere procedure documentate per rompere i vetri o accedere alle emergenze, improvvisare decisioni critiche sotto pressione durante gli incidenti attivi

Schemi

Dove cercare	Che bell’aspetto
Registri di Monitoraggio evento	✅ Acquisire registri attività dettagliati tra cui azioni utente, chiamate API, eventi di autenticazione e schemi di accesso ai dati con dettagli sufficienti per l’analisi forense
Itinerario di controllo campi	✅ Abilita Itinerario di controllo campi conservando la cronologia delle modifiche dei dati per i campi Limitati e Riservati con conservazione corrispondente ai requisiti normativi (supporta la conservazione indefinita; confermare il periodo richiesto in base al regolamento di riferimento)
Archiviazione immutabile	✅ Instradare i registri ad archivi esterni immutabili che gli aggressori non possono modificare, garantendo l’integrità delle prove forensi durante l’indagine
Itinerario di controllo impostazioni	✅ Conservare la cronologia delle modifiche della configurazione amministrativa abilitando l’analisi delle modifiche del sistema non autorizzate con conservazione di 180 giorni
Valutazione Scope	✅ Progettare modelli di autorizzazioni e controlli di accesso ai dati che consentono una valutazione rapida dell’ambito dell’esposizione dei dati in base ai privilegi account compromessi
Modifica correlazione	✅ Mantenere la correlazione tra le modifiche alla configurazione dell’itinerario di controllo delle impostazioni e gli schemi di attività di Monitoraggio evento che consentono di indagare sulle tecniche degli aggressori
Registrazione dell’accesso ai dati	✅ Registrare tutto l’accesso ai dati riservati e confidenziali che consentono di indagare sui dati esposti durante il periodo di compromesso
Itinerario di controllo integrazione	✅ Acquisire schemi di autenticazione API, autorizzazione e scambio di dati per i sistemi integrati che consentono di indagare sulla compromissione tra sistemi
Conservazione delle prove	✅ Instradare i registri e gli itinerari di controllo in modo continuo a un archivio esterno immutabile in modo che le prove forensi siano conservate e disponibili quando si indaga su un incidente

Anti-schemi

Dove cercare	Che brutto aspetto
Archiviazione registro variabile	⚠️ Archiviazione dei registri solo all’interno di Salesforce dove gli aggressori con accesso amministrativo possono eliminare o modificare le prove forensi
Dettagli registro insufficiente	⚠️ Acquisizione di eventi di alto livello senza dettagli sufficienti per l’indagine (accesso registrato ma non indirizzo IP, accesso ai dati registrato ma non record specifici)
Nessuna registrazione di accesso ai dati	⚠️ Mancanza di una registrazione dettagliata dell’accesso ai dati limitati e riservati, impossibilità di valutare l’ambito dell’esposizione ai dati durante la notifica della violazione
Itinerario di controllo campi mancanti	⚠️ Non abilitazione dell’itinerario di controllo campi per i campi sensibili, impossibilità di determinare quali valori di dati sono stati esposti durante la compromissione
Correlazione nessuna modifica	⚠️ Non avere alcuna funzionalità di correlazione tra le modifiche alla configurazione dell’itinerario di controllo impostazioni e i successivi schemi di attività di Monitoraggio evento
Cronologia di controllo eliminata	⚠️ Consentire la scadenza della cronologia di controllo prima del minimo di conservazione previsto dalla normativa vigente per la distribuzione, creando violazioni della conformità

Schemi

Dove cercare	Che bell’aspetto
Obiettivi del tempo di recupero	✅ Definire e testare l’obiettivo tempo di ripristino (RTO) e l’obiettivo punto di ripristino (RPO) per gli scenari di incidenti di sicurezza, non solo per gli scenari di ripristino di emergenza
Procedure di ripristino testate	✅ Processi di ripristino dei documenti per account compromessi, esfiltrazione di dati in blocco, distribuzioni non autorizzate, inoltro dei privilegi al livello superiore e compromissione dei pacchetti con test trimestrali
Convalida del backup	✅ Convalida regolarmente l’integrità del backup assicurando che le funzionalità di ripristino funzionino durante gli incidenti di sicurezza, non solo gli errori operativi
Funzionalità di ritiro	✅ Progettare pipeline di distribuzione con procedure di ritiro testate per distribuzioni di codice non autorizzate o modifiche della configurazione dannose
Rotazione credenziali	✅ Implementare procedure di rotazione rapida delle credenziali per account di integrazione, utenti API e credenziali denominate compromessi
Ripristino delle autorizzazioni	✅ Documentare le procedure per ripristinare l’accesso appropriato dopo azioni di isolamento troppo ampie durante la risposta agli incidenti
Ripristino dei dati	✅ Progettare funzionalità di ripristino dei dati per risolvere il danneggiamento o l’eliminazione dei dati derivanti da incidenti di sicurezza, distinte dal ripristino di emergenza
Continuità del servizio	✅ Soluzioni architettoniche che consentono alle procedure di risposta agli incidenti di sicurezza di mantenere la continuità delle funzioni aziendali critiche durante l’indagine e la riparazione
Convalida ripristino	✅ Testare le procedure di ripristino trimestralmente verificando che i sistemi ripristinati funzionino correttamente e che la compromissione non sia persistita durante il ripristino

Anti-schemi

Dove cercare	Che brutto aspetto
Procedure non testate	⚠️ Avere procedure di recupero documentate mai testate attraverso esercizi, scoprire durante incidenti effettivi che le procedure sono incomplete o errate
Nessun RTO/RPO per sicurezza	⚠️ Definizione degli obiettivi temporali di ripristino solo per il ripristino di emergenza senza considerare scenari di incidenti di sicurezza che richiedono procedure di ripristino diverse
Nessuna capacità di ritiro	⚠️ Mancanza di procedure di ritiro della distribuzione per le distribuzioni di codice non autorizzate, che richiedono una riqualificazione completa per rimuovere le modifiche dannose
Backup non convalidati	⚠️ Mai testare il ripristino del backup, scoprendo durante gli incidenti che i backup sono danneggiati o incompleti
Nessuna procedura di rotazione delle credenziali	⚠️ Non avere procedure di rotazione rapida delle credenziali per gli account di integrazione compromessi, lasciando attive le credenziali compromesse durante l’indagine
Processi di ripristino manuali	⚠️ Dipende interamente dalle procedure di ripristino manuali durante gli incidenti, introducendo errori e ritardi quando la velocità è critica
Nessun test di ripristino	⚠️ Non verificare mai che i sistemi ripristinati funzionino correttamente dopo il ripristino, potenzialmente reintroducendo compromissione o danneggiamento dei dati

Schemi

Dove cercare	Che bell’aspetto
Risposta account utente compromessa	✅ Procedure per i documenti: congelare l’utente, forzare la reimpostazione delle credenziali, rivedere l’itinerario di controllo delle impostazioni e i registri di accesso ai dati per il periodo di compromesso, valutare l’ambito dell’esposizione dei dati, eseguire la notifica di violazione se Accesso limitato ai dati
Risposta di esfiltrazione dati in blocco	✅ Procedure per i documenti: revocare immediatamente la sessione, limitare le autorizzazioni, identificare i record e i livelli di classificazione interessati, eseguire la notifica delle violazioni normative entro la tempistica impostata dal regolamento vigente per la distribuzione
Risposta di distribuzione codice non autorizzata	✅ Procedure dei documenti: ritiro immediato della distribuzione, controllo di tutte le modifiche dalla credenziale compromessa, revisione della sicurezza delle opportunità in corso di realizzazione per bypass dell’autorizzazione, scansione del codice distribuito per backdoor persistenti
Risposta di inoltro al livello superiore privilegi	✅ Procedure per i documenti: revocare immediatamente i privilegi inoltrati al livello superiore, controllare le attività eseguite con accesso elevato, analizzare in che modo l’inoltro al livello superiore ha aggirato i controlli di approvazione, implementare controlli compensativi
Risposta di compromesso del pacchetto AppExchange	✅ Procedure per i documenti: isolare le autorizzazioni per i pacchetti, valutare i dati a cui si accede per pacchetto, valutare le opzioni di sostituzione dei pacchetti, documentare le lezioni apprese per i criteri di valutazione dei pacchetti
Segnali di rilevamento	✅ Configurare il monitoraggio rilevando ogni scenario: anomalie di accesso per gli account compromessi, segnalare il volume delle esportazioni per l’esfiltrazione, il monitoraggio della distribuzione per codice non autorizzato, il monitoraggio della modifica delle autorizzazioni per l’inoltro al livello superiore
Esercizi da tavolo	✅ Condurre esercizi da tavolo per testare le procedure di risposta per scenari specifici della piattaforma convalidando la preparazione del team e la completezza delle procedure
Automazione delle risposte	✅ Le policy sulla sicurezza delle transazioni in tempo reale bloccano automaticamente le azioni sospette, richiedono l’autenticazione step-up o notificano i soccorritori sui segnali di rilevamento ad alta confidenza, fornendo un contenimento automatico che riduce il tempo di risposta

Anti-schemi

Dove cercare	Che brutto aspetto
Solo piani di risposta generica	⚠️ Avere solo procedure di risposta agli incidenti generiche senza indicazioni specifiche di Salesforce, improvvisare azioni specifiche della piattaforma durante gli incidenti attivi
Configurazione senza rilevamento	⚠️ Non avere un monitoraggio configurato per rilevare scenari specifici della piattaforma (esportazione in blocco, inoltro dei privilegi al livello superiore, distribuzione non autorizzata), rilevare incidenti tramite rapporti utente o controlli
Nessun esercizio da tavolo	⚠️ Non condurre mai esercizi da tavolo per convalidare la familiarità del team con le procedure di risposta specifiche della piattaforma, scoprendo lacune Knowledge durante gli incidenti effettivi
Nessuna automazione	⚠️ Risposta completamente manuale per tutti gli incidenti senza policy sulla sicurezza delle transazioni in tempo reale per il contenimento automatico, introducendo ritardi quando il blocco immediato potrebbe ridurre i danni
Playbook di risposta mancante	⚠️ Mancanza di playbook di risposta documentati per scenari comuni (account utente compromesso, esfiltrazione di dati, distribuzione di codice non autorizzata)
Procedure di notifica senza violazioni	⚠️ Non avere procedure per i requisiti di notifica delle violazioni normative, sforzarsi di comprendere gli obblighi durante gli incidenti effettivi quando le tempistiche sono strette

Schemi

Dove cercare	Che bell’aspetto
Comunicazione fuori banda	✅ Stabilire canali di comunicazione che non dipendono da sistemi potenzialmente compromessi (alberi telefonici, piattaforme di messaggistica esterne) per coordinare la risposta
Procedure di inoltro al livello superiore	✅ Percorsi di inoltro al livello superiore dei documenti dal rilevamento iniziale alla notifica esecutiva con informazioni di contatto e criteri di inoltro al livello superiore
Modelli di notifica	✅ Mantenere modelli di notifica predefiniti per i tipi di incidenti più comuni che consentono una comunicazione rapida con stakeholder, clienti e autorità di regolamentazione
Identificazione stakeholder	✅ Identificare gli stakeholder che richiedono la notifica per diversi tipi di incidenti, inclusi dirigenti, legali, conformità, utenti interessati e autorità di regolamentazione
Tempistica notifiche normative	✅ Documentare i requisiti di notifica normativi di ogni giurisdizione, confermati rispetto al regolamento vigente per la distribuzione, con procedure che garantiscono la conformità tempestiva
Coordinamento interno	✅ Progettare procedure di coordinamento degli incidenti specificando ruoli e responsabilità (comandante dell’incidente, responsabile tecnico, lead delle comunicazioni, collegamento legale)
Coordinamento esterno	✅ Stabilire procedure per il coordinamento con l’Assistenza Salesforce, gli investigatori forensi esterni, l’assistenza legale e le forze dell’ordine in base alle esigenze
Comunicazione stato	✅ Implementare una cadenza di comunicazione dello stato regolare durante gli incidenti attivi tenendo informati gli stakeholder senza sovraccaricare il team investigativo

Anti-schemi

Dove cercare	Che brutto aspetto
Nessuna comunicazione fuori banda	⚠️ Dipende interamente dall’email o dalla messaggistica interna potenzialmente compromessa per il coordinamento degli incidenti, perdendo capacità di comunicazione quando i canali principali sono compromessi
Percorsi di inoltro al livello superiore non chiari	⚠️ Non avere procedure di inoltro al livello superiore documentate, causando ritardi e confusione su chi deve essere informato e quando
Nessun modello di notifica	⚠️ Improvvisare le notifiche degli incidenti durante gli incidenti attivi sotto pressione temporale, causando comunicazioni incomplete o errate
Elenchi degli stakeholder mancanti	⚠️ Non avere elenchi di stakeholder pre-identificati, scoprire durante gli incidenti che le parti critiche (legali, conformità, dirigenti) non sono state informate
Nessuna consapevolezza della tempistica normativa	⚠️ Non essere a conoscenza delle tempistiche delle notifiche normative che si applicano alla distribuzione durante la risposta agli incidenti, la mancanza di scadenze e la creazione di ulteriori violazioni della conformità
Ruoli ambigui	⚠️ Avere ruoli e responsabilità di risposta agli incidenti poco chiari, che causano confusione su chi ha l’autorità di prendere decisioni di contenimento
Nessuna procedura di coordinamento esterno	⚠️ Non avere relazioni o procedure stabilite per coinvolgere l’Assistenza Salesforce, gli investigatori forensi o le forze dell’ordine quando necessario

Schemi

Dove cercare	Che bell’aspetto
Cultura senza colpa	✅ Concentrare le revisioni post-incidente sui miglioramenti del sistema anziché sulla colpa individuale, consentendo l’apprendimento organizzativo senza timore di ripercussioni
Documentazione della sequenza temporale degli incidenti	✅ Documentare la tempistica completa dell’incidente, inclusi il compromesso iniziale, il rilevamento, le azioni di risposta e la risoluzione con indicazioni orarie precise
Controllo dell’analisi errori	✅ Identificare quali controlli preventivi e detective non sono riusciti a prevenire o rilevare l’incidente, informando sui miglioramenti architettonici
Documentazione sulla debolezza architettonica	✅ Documentare i punti deboli dell’architettura rivelati dall’incidente nei record decisione architettura (ADR) acquisendo le modifiche della sicurezza
Assegnazione di priorità alla riparazione	✅ Assegnare priorità alla riparazione in base al potenziale di riduzione del rischio, affrontando le cause principali anziché i sintomi
Condivisione delle lezioni	✅ Condividere le lezioni apprese tra team e unità operative per evitare incidenti simili in altre parti dell’organizzazione
Aggiornamenti delle regole di rilevamento	✅ Aggiornare le regole di rilevamento e le basi di riferimento comportamentali in base alle tecniche di attacco osservate durante l’indagine
Perfezionamento della procedura di risposta	✅ Aggiornare le procedure di risposta agli incidenti in base a ciò che ha funzionato e ciò che non ha funzionato durante la risposta agli incidenti effettivi
Tracciamento delle metriche	✅ Monitoraggio del tempo medio di rilevamento (MTTD), del tempo medio di risposta (MTTR) e dell’impatto nel tempo identificando le tendenze che richiedono investimenti architettonici
Rivedi cadenza	✅ Condurre una revisione post-incidente tempestiva mentre i dettagli rimangono aggiornati e c’è slancio per il miglioramento

Anti-schemi

Dove cercare	Che brutto aspetto
Recensioni saltate	⚠️ Saltare le revisioni post-incidente, passando direttamente all’incidente successivo senza acquisire le lezioni apprese o miglioramenti architettonici
Colpa della cultura	⚠️ Concentrare le revisioni post-incidente sulle colpe individuali anziché sui miglioramenti del sistema, causando l’occultamento degli incidenti e impedendo l’apprendimento organizzativo
Nessuna documentazione architettonica	⚠️ Impossibile documentare le modifiche dell’architettura di sicurezza causate dagli apprendimenti degli incidenti nei record decisioni architetturali (ADR)
Trattamento dei sintomi	⚠️ Risolvere solo i sintomi degli incidenti (password compromessa) senza correggere le cause principali (mancanza di MFA), consentendo attacchi simili per avere successo
Nessuna condivisione delle lezioni	⚠️ Mantenere gli apprendimenti sugli incidenti all’interno del team di risposta anziché condividerli tra l’organizzazione, consentendo incidenti simili in altre unità operative
Nessun aggiornamento del rilevamento	⚠️ Impossibile aggiornare le regole di rilevamento o le basi di riferimento comportamentali in base alle tecniche di attacco osservate, rimanendo vulnerabili ad attacchi simili
Nessun tracciamento delle metriche	⚠️ Non tenere traccia del tempo medio di rilevamento (MTTD), del tempo medio di risposta (MTTR) o delle tendenze degli ambiti, mancando opportunità per identificare le debolezze sistemiche
Revisioni ritardate	⚠️ Esecuzione di revisioni post-incidente mesi dopo la risoluzione dell’incidente quando i dettagli vengono dimenticati e lo slancio del miglioramento viene perso
Nessun follow-through di riparazione	⚠️ Identificare i miglioramenti durante la revisione post-incidente ma non implementarli, consentendo il ripetersi di incidenti simili