Sicurezza del cloud e del SaaS
25 domande su Sicurezza del cloud e del SaaS, in linguaggio semplice: cosa verificare, cosa mostra NetSenX e cosa un sensore non vede.
Descrivono quanta parte dello stack gestisce il fornitore per Lei, e quindi quanto lavoro di sicurezza resta a Lei. Con l'infrastruttura come servizio (IaaS) noleggia server virtuali, archiviazione e reti; installa e aggiorna il sistema operativo, configura i firewall ed esegue le applicazioni, quindi il lavoro di sicurezza somiglia a quello sui propri server. Con la piattaforma come servizio (PaaS) il fornitore gestisce sistema operativo e ambiente di esecuzione, come un database gestito o una piattaforma applicativa; Lei resta responsabile di codice, configurazione, identità e dati. Con il software come servizio (SaaS) usa un'applicazione finita come posta, CRM o contabilità; la Sua parte riguarda soprattutto chi ha accesso, con quali diritti e quale autenticazione a più fattori, come vengono condivisi i dati e la conservazione di una propria copia dei dati importanti. Molte aziende usano tutti e tre contemporaneamente. Associ ogni servizio al suo tipo, perché le domande di un revisore o di un assicuratore cambiano per ciascuno, come cambiano i log disponibili.
Può farlo, per le parti che il fornitore prende in carico, ma sposta il rischio più che eliminarlo. Un grande fornitore aggiorna la propria infrastruttura, gestisce data center ridondanti e impiega team di sicurezza che poche medie imprese potrebbero permettersi, quindi sicurezza fisica, guasti hardware e disponibilità di base di solito migliorano. Ciò che non si sposta è la responsabilità per identità, configurazione e dati, che diventano più esposti: un account di amministrazione cloud è raggiungibile da qualsiasi punto di internet, un'impostazione di archiviazione può pubblicare file al mondo con un clic e una password rubata senza autenticazione a più fattori apre tutto in un colpo. Gli attaccanti hanno seguito le aziende nel cloud, e molti degli incidenti che vi provocano iniziano con un account sottratto via phishing o una chiave di accesso trapelata. Migrare in sicurezza significa MFA su ogni account, privilegi minimi per gli amministratori, log attivati e controllati, backup sotto il proprio controllo e qualcuno responsabile della configurazione cloud. Anche la rete dell'ufficio continua a contare: portatili, stampanti e server rimasti sono spesso il punto in cui un attaccante entra per primo.
Le connessioni tra i Suoi dispositivi e il cloud, non ciò che accade dentro il cloud. Un sensore sulla rete dell'ufficio o un agente su un server vede quali dispositivi si collegano a quali servizi cloud e SaaS, quando, quanto spesso e quanti dati passano in ciascuna direzione, oltre al nome del server nell'handshake TLS dove si catturano i pacchetti. Basta per notare un portatile che carica gigabyte su un servizio di archiviazione mai usato, un server che contatta ogni pochi minuti una macchina cloud a noleggio o un dispositivo che parla con una regione inattesa. Non vede che cosa fanno gli utenti dentro un'applicazione SaaS, come condividere pubblicamente una cartella, creare una regola di inoltro o concedere a un'app l'accesso a una casella di posta; non vede il traffico tra servizi cloud; e non vede il personale che lavora da casa su dispositivi non gestiti. Questo viene dai log di audit e dalle console di amministrazione del fornitore. NetSenX copre il lato rete: beaconing, scansioni, movimento laterale e volumi in uscita insoliti in ogni piano. Non sostituisce i log del fornitore cloud.
In parte: vede il comportamento di rete dei server Linux su cui gira il suo agente, ovunque si trovino, ma non legge il piano di controllo del fornitore cloud. L'agente NetSenX funziona su Linux e macOS, quindi un server virtuale Linux che gestisce presso un fornitore cloud può ospitarlo come qualsiasi altra macchina Linux; l'agente vede allora le connessioni di quel server, e i rilevamenti di base valgono in ogni piano: beaconing verso un server di comando e controllo, scansioni, movimento laterale verso altri server e volumi di dati in uscita insoliti. Ogni server di questo tipo conta come un dispositivo del Suo piano. Restano fuori: i servizi gestiti che non amministra direttamente, come database, funzioni serverless e archiviazione; il traffico tra servizi cloud che non passa mai da un server con l'agente; e tutto ciò che sta nel livello di gestione del fornitore, come accessi agli account, modifiche dei permessi e configurazione. Per questi attivi i log di audit e di flusso del fornitore e li invii dove qualcuno li esamina. Le due viste insieme Le danno il comportamento di rete dei server e l'attività degli account intorno a essi.
Guardando chi è la destinazione, come si comporta la connessione e se qualcosa nella Sua attività la spiega. Gli attaccanti amano i server cloud a noleggio perché chiunque ne crea uno in pochi minuti e l'indirizzo appartiene a un fornitore rispettabile, quindi il nome del fornitore da solo non prova nulla. Domande migliori: la destinazione corrisponde a un servizio che usa, in base al nome nell'handshake TLS o nel DNS, e quel servizio è nell'elenco dei fornitori? La connessione è regolare, piccola e continua, come un programma che si fa vivo, invece che guidata da persone in orario di lavoro? È iniziata subito dopo qualcosa di insolito su quel dispositivo, come un nuovo programma o un accesso dall'estero? Un server che di solito riceve solo connessioni all'improvviso ne apre verso l'esterno? Un servizio legittimo di backup o di monitoraggio di solito ha una destinazione documentata e un contratto; una macchina virtuale sconosciuta contattata ogni cinque minuti da una postazione, no. NetSenX segnala in ogni piano questo schema di contatto regolare, detto beaconing, e i volumi in uscita insoliti, con la destinazione, così può interpellare il responsabile giusto.
Lo scopra prima dalle connessioni e poi chieda al responsabile di ogni server, perché la maggior parte di queste connessioni ha una spiegazione banale e alcune no. Motivi legittimi sono servizi di monitoraggio e backup, mirror per gli aggiornamenti, l'API di un fornitore, la macchina di test di uno sviluppatore o un fornitore SaaS ospitato presso un provider economico. I segnali preoccupanti sono l'opposto: un server che non ha alcun motivo di business per parlare con internet, connessioni che si ripetono a intervalli fissi giorno e notte, traffico iniziato dopo un incidente o una nuova installazione, e destinazioni che nessuno in azienda riconosce. I server virtuali a noleggio presso provider economici sono un luogo frequente per i server di comando degli attaccanti e per accumulare dati rubati, proprio perché sono economici, rapidi e anonimi da noleggiare. Tenga per ogni server l'elenco delle destinazioni attese, lo riveda con i responsabili e blocchi il traffico in uscita dai server che non ne hanno bisogno. In ogni piano NetSenX mostra le connessioni dei Suoi host con le destinazioni e genera allarmi su beaconing e volumi in uscita insoliti, gli schemi che qui contano di più.
Sì, e lo fanno, perché il traffico verso un servizio cloud noto viene raramente bloccato o messo in discussione. Un malware può prelevare istruzioni da un file in un account di archiviazione cloud pubblico, da un documento condiviso, da un sito di hosting del codice, dall'interfaccia bot di un'app di messaggistica o da una rete di distribuzione dei contenuti, e rimandare i dati rubati per la stessa via. Per un firewall che giudica le destinazioni in base alla reputazione, sembra un normale dipendente che usa un servizio diffuso. Ciò che lo tradisce resta il comportamento. Un programma che controlla un file nel cloud a intervalli regolari, giorno e notte, da un dispositivo il cui utente non sta lavorando, ha un ritmo che le persone non hanno; i caricamenti possono essere insolitamente grandi per quel dispositivo; e l'impronta del client nell'handshake TLS può non corrispondere né a un browser né all'app ufficiale del servizio. Passi pratici: consenta solo i servizi cloud che l'azienda usa, per tenant dove gli strumenti lo permettono, e indaghi sui dispositivi che parlano con account personali di servizi diffusi. NetSenX rileva beaconing e volumi in uscita insoliti in ogni piano, qualunque sia la destinazione, e impronte TLS dal piano Starter dove l'agente cattura i pacchetti.
Confronti il trasferimento con ciò che quel dispositivo fa di solito e con gli strumenti che l'azienda usa davvero. Un client di sincronizzazione che invia file al servizio di archiviazione approvato segue uno schema: gira sulle postazioni di chi lo usa, il suo volume sale e scende con l'orario di lavoro e la destinazione è il servizio che paga. Il furto di dati di solito si distingue in almeno un aspetto: a caricare molto è un server e non una postazione; la destinazione è un account di archiviazione personale o sconosciuto, un sito di condivisione file o un server a noleggio; il volume supera di molto il livello abituale di quell'host; avviene di notte o nel fine settimana; oppure segue altri segnali di allarme come scansioni o nuovi accessi di amministratori. Gli strumenti che gli attaccanti usano per questo, come utility di sincronizzazione da riga di comando, spesso somigliano a un backup legittimo. Chieda prima al responsabile dell'host, poi controlli nei log del fornitore di archiviazione l'account usato. In ogni piano NetSenX genera allarmi sui volumi di dati in uscita insoliti per host e mostra la destinazione; non vede quali file siano stati inviati.
Può vedere se un dispositivo aziendale invia quantità insolite di dati a servizi cloud, spesso il segnale precoce più utile, ma non chi l'ha fatto né quali file. Nelle settimane prima di un'uscita, un forte aumento dei caricamenti dal portatile verso un archivio personale, un sito di trasferimento file o uno strumento di IA merita un colloquio, soprattutto in orari insoliti. Conta più un buon processo di uscita che il rilevamento: concordare per iscritto che cosa resta all'azienda, revocare l'ultimo giorno l'accesso agli account SaaS e cloud, revocare token e password per le app, controllare link di condivisione e regole di inoltro in posta e archiviazione, e ritirare i dispositivi. La prevenzione della perdita di dati e i log di audit dei servizi di archiviazione e posta possono mostrare i nomi dei file; un sensore di rete no. Mantenga ogni verifica proporzionata, concentrata su dispositivi e dati aziendali, e concordata con le risorse umane e, dove richiesto, con le rappresentanze dei lavoratori, perché il controllo del personale è regolato in ogni Paese dell'UE. In ogni piano NetSenX genera allarmi su volumi di dati in uscita insoliti da un dispositivo e mostra la destinazione.
Sì, soprattutto attraverso i dispositivi e gli account che li sincronizzano o li amministrano. Quando un ransomware cifra i file su un portatile le cui cartelle sono sincronizzate con un archivio cloud, il client di sincronizzazione carica fedelmente le versioni cifrate, così cambiano anche le copie nel cloud. Un attaccante con un account di amministrazione rubato può cancellare o cifrare dati direttamente nel servizio, eliminare backup e versioni, oppure esfiltrare prima tutto e minacciare di pubblicarlo. Ciò che aiuta: tenga attivo il controllo delle versioni dei file con una cronologia sufficiente e sappia come ripristinare un'intera cartella in una volta; protegga gli account di amministrazione con un'autenticazione a più fattori resistente al phishing e li separi da quelli quotidiani; attivi la protezione dalla cancellazione o i blocchi di conservazione dove il servizio li offre; mantenga un backup indipendente che gli stessi amministratori non possano rimuovere; e limiti la sincronizzazione alle cartelle di cui le persone hanno bisogno. Sorvegli i passi che precedono la cifratura, perché è lì che si può ancora intervenire: in ogni piano NetSenX rileva beaconing, scansioni, movimento laterale e volumi in uscita insoliti, compresi grandi caricamenti verso archivi cloud. Non vede le azioni nella console di amministrazione del servizio cloud.
Di solito non nel modo che Le serve. I fornitori SaaS proteggono il proprio servizio dai propri guasti, con archiviazione ridondante e disaster recovery, ma in genere non promettono di ripristinare i Suoi dati dopo qualcosa che Lei o un attaccante avete fatto dentro il Suo account. Gli elementi eliminati restano nei cestini e nelle cronologie delle versioni per un periodo limitato e poi spariscono; un attacco ransomware che cifra file sincronizzati, un amministratore malintenzionato che cancella caselle di posta o un errore di sincronizzazione che sovrascrive una cartella possono durare più di quelle finestre; e quando finisce un abbonamento o una licenza utente, i dati possono essere rimossi. Legga le condizioni del fornitore: la maggior parte descrive questa ripartizione come parte della responsabilità condivisa. Se i dati contano, tenga una copia propria: un servizio di backup o un'esportazione che copi posta, file e dati applicativi chiave in un archivio che gli amministratori del SaaS non possono cancellare, conservato per tutto il tempo richiesto dalle esigenze aziendali e legali. Provi almeno una volta il ripristino di una casella di posta e di una cartella, perché è lì che emergono le lacune. Un sensore di rete qui non aiuta; è pianificazione di backup e conservazione.
Parta dalle identità, perché la maggior parte delle compromissioni di account inizia con una password carpita con il phishing o riutilizzata. L'essenziale, in ordine: autenticazione a più fattori per ogni utente, con metodi resistenti al phishing come chiavi di sicurezza o passkey per gli amministratori; account di amministrazione separati, usati solo per amministrare, e il minor numero possibile di amministratori globali; protocolli di autenticazione legacy che aggirano la MFA disattivati; criteri di accesso che blocchino località a rischio o dispositivi non gestiti dove la licenza lo consente; log di audit attivi e conservati abbastanza a lungo per indagare; avvisi su nuove regole di inoltro della posta, nuovi ruoli amministrativi e nuovi consensi ad app OAuth; limiti alla condivisione esterna e alle app di terze parti che gli utenti possono collegare; e un backup di posta e file al di fuori del fornitore, perché i suoi cestini non sono un backup. Riveda ogni trimestre i ruoli amministrativi e gli account ospite. Quasi tutto è configurazione che già paga. Un sensore di rete non vede che cosa accade dentro questi servizi; ciò che aggiunge è la vista sui dispositivi che vi si collegano, come un portatile che inizia a fare beaconing dopo l'apertura di un allegato di phishing.
È un attacco in cui la vittima viene indotta a concedere a un'app malevola l'accesso al proprio account, invece di cedere la password. L'utente riceve un link a ciò che sembra un'app utile o una richiesta di documento, accede sulla vera pagina di Microsoft o Google e clicca per approvare permessi come leggere posta, file o contatti. Da quel momento l'app dell'attaccante ha un token che funziona senza password e spesso sopravvive al cambio della password e all'autenticazione a più fattori, perché l'utente ha dato il consenso. È efficace proprio perché ogni pagina che la vittima vede è autentica. Difese: limiti il consenso degli utenti in modo che l'accesso possa essere concesso solo a editori verificati o ad app approvate dall'amministratore, richieda la revisione dell'amministratore per i permessi ad alto rischio, imposti avvisi sui nuovi consensi alle app e riveda regolarmente l'elenco delle app collegate, rimuovendo ciò che nessuno riconosce. Se trova un'autorizzazione malevola, revochi l'app e i suoi token, poi verifichi nei log di audit a che cosa ha avuto accesso. Un sensore di rete non vede i consensi, che avvengono presso il fornitore di identità; è lì che vanno i controlli.
Quelli che serviranno per rispondere a che cosa è successo dopo un incidente: chi ha effettuato l'accesso, che cosa è cambiato e a quali dati si è acceduto. Per ogni servizio cloud o SaaS verifichi che siano attivi: log degli accessi con località e dispositivo; modifiche amministrative e di configurazione, come nuovi ruoli, criteri, regole di inoltro e consensi alle app; accessi a file e caselle di posta dove il servizio lo offre; attività delle API per gli account cloud; e log di flusso di rete per le reti cloud se vi gestisce server. Poi verifichi per quanto tempo ciascuno viene conservato di default, perché alcuni servizi tengono solo una finestra breve se non paga di più o non li esporta. Conservi copie dove gli amministratori di quel servizio non possano cancellarle, così un attaccante con diritti di amministratore non può cancellare le tracce. Decida chi li esamina e quali eventi generano un allarme. La notifica degli incidenti secondo NIS2 e GDPR, e il Suo assicuratore, si aspetteranno che ricostruisca una cronologia. Un sensore di rete aggiunge il lato dei dispositivi: NetSenX conserva gli allarmi per il periodo previsto dal Suo piano, con host, destinazioni e orari.
Di solito niente di buono, e in fretta, perché gli attaccanti scandagliano di continuo i repository di codice pubblici alla ricerca di chiavi. Una chiave di accesso al cloud o un token API funziona come una password che non chiede mai l'autenticazione a più fattori; chi la possiede può usare l'account con i permessi di quella chiave da qualsiasi luogo. L'abuso tipico va dall'avviare costose risorse di calcolo per il mining di criptovalute alla copia di bucket di archiviazione e database, fino alla creazione di nuovi utenti per mantenere l'accesso dopo la revoca della chiave. Le fughe avvengono tramite codice inserito in repository pubblici o condivisi, file di configurazione nei backup, screenshot, log di CI e messaggi in chat. Se succede: revochi o ruoti subito la chiave, non dopo l'indagine; controlli nei log di attività dell'account tutto ciò che è stato fatto con essa dalla fuga in poi, compresi nuovi utenti, chiavi e risorse in regioni insolite; elimini ciò che l'attaccante ha creato; e verifichi la fatturazione. Per prevenirlo usi la scansione dei segreti nei repository, credenziali di breve durata invece di chiavi permanenti, permessi ristretti per ogni chiave e avvisi di budget. Un sensore di rete non può vedere una chiave pubblicata su internet; può vederne le conseguenze sui server che osserva.
È un'archiviazione cloud leggibile, o persino scrivibile, da più persone del previsto, spesso da chiunque su internet. I servizi di archiviazione a oggetti permettono di condividere pubblicamente un bucket o un contenitore con una sola impostazione o un link, utile per le immagini di un sito web e pericoloso per backup, esportazioni, fatture o file dei clienti. Molte esposizioni di dati finite sui giornali non erano attacchi, ma file trovati da qualcuno che cercava bucket aperti. Si evita con alcune abitudini: attivi presso il fornitore il blocco dell'accesso pubblico a livello di account, a meno che un bucket non debba davvero essere pubblico, e tenga i contenuti pubblici in bucket separati con nomi chiari; preferisca link firmati a tempo alla condivisione pubblica; cifri i dati e limiti chi può cambiare le impostazioni di condivisione; usi i controlli di configurazione del fornitore o uno strumento di postura che segnali l'archiviazione pubblica; e riveda i link di condivisione nell'archiviazione SaaS, come quelli che funzionano per chiunque li abbia. Verifichi dopo ogni nuovo progetto, perché i bucket di test sono un colpevole frequente. Un sensore di rete non vede le impostazioni dei bucket; questo spetta alla gestione della configurazione cloud.
È uno speciale indirizzo interno presente su ogni macchina virtuale cloud, da cui la macchina può leggere informazioni su se stessa, comprese credenziali temporanee per i permessi che le sono assegnati. Il software che gira sul server usa quelle credenziali per raggiungere archiviazione, database e altri servizi cloud senza una password nella configurazione, il che è una buona pratica. Il rischio è che qualsiasi cosa in grado di far inviare al server una richiesta web verso quell'indirizzo possa leggere anche le credenziali. Una via comune è la server-side request forgery (SSRF): una falla in un'applicazione web che permette a un attaccante di far scaricare al server un URL a sua scelta. Con le credenziali in mano, l'attaccante agisce nel Suo account cloud con i permessi del server. Difese: richieda la versione più recente, basata su sessione, del servizio di metadati dove il fornitore la offre, perché blocca le richieste falsificate semplici; dia a ogni ruolo di server solo i permessi necessari; corregga le falle SSRF e convalidi gli URL che le applicazioni scaricano; e imposti avvisi quando credenziali del ruolo di un server vengono usate dall'esterno del Suo ambiente, cosa che i log di attività del fornitore possono mostrare.
Di solito prima in fattura, ed è per questo che gli avvisi di budget sono il rilevamento più economico da impostare. Gli attaccanti che ottengono credenziali cloud avviano spesso molte macchine virtuali o container potenti, di frequente in regioni che non usa mai, per estrarre criptovalute a Sue spese. Segnali: un aumento improvviso della spesa di calcolo o del numero di istanze, macchine con tipi di GPU che nessuno ha ordinato, nuove risorse in regioni sconosciute, nuove chiavi di accesso o nuovi utenti creati nello stesso periodo, e server che girano a pieno carico di CPU giorno e notte. Su un server che gestisce direttamente, un processo di mining si vede anche in rete: connessioni costanti e durature verso pool di mining, spesso su porte insolite, da una macchina che di norma serve solo richieste web. Reagisca revocando le credenziali usate, eliminando ciò che l'attaccante ha creato in tutte le regioni, cercando meccanismi di persistenza come nuovi utenti, ruoli e funzioni pianificate, e chiedendo al fornitore dei costi. NetSenX vede il comportamento di rete dei server su cui gira il suo agente, come connessioni regolari verso una destinazione sconosciuta; non sorveglia la Sua fattura cloud né le risorse senza agente.
Combini alcune fonti economiche, perché nessuna vede tutto. Il fornitore di identità mostra a quali app le persone accedono con l'account aziendale, comprese le app OAuth collegate a posta o file. Note spese ed estratti delle carte rivelano gli abbonamenti acquistati dai team. La gestione di browser e dispositivi può elencare estensioni e app desktop installate. I log DNS e quelli di firewall o proxy mostrano quali servizi raggiungono i dispositivi aziendali. Poi ordini l'elenco: strumenti che duplicano uno approvato, strumenti che contengono dati aziendali o dei clienti, e quelli innocui. Per ogni strumento che tratta dati decida se approvarlo come si deve, con contratto e controllo amministrativo, sostituirlo o dismetterlo, e spieghi agli utenti il perché. Farlo una volta a trimestre mantiene l'elenco breve. Una vista di rete aiuta per la parte delle connessioni: NetSenX mostra quali host si collegano a quali destinazioni, con una vista dedicata ai servizi di IA dal piano Pro; non identifica ogni applicazione SaaS per nome e non vede accessi né consensi alle app, che stanno presso il fornitore di identità.
Sono tre tipi di strumenti di sicurezza cloud che guardano cose diverse. Il cloud security posture management (CSPM) controlla la configurazione dei Suoi account cloud, come archiviazione pubblica, regole firewall aperte, cifratura mancante o permessi troppo ampi, rispetto alle buone pratiche e segnala le deviazioni. Il SaaS security posture management (SSPM) fa lo stesso per le applicazioni SaaS, verificando impostazioni come l'obbligo di MFA, la condivisione esterna e i ruoli di amministrazione. Un cloud access security broker (CASB) si pone tra utenti e servizi cloud, tramite un proxy o le API dei fornitori, per scoprire quali servizi vengono usati e applicare criteri, come bloccare il caricamento di dati sensibili. Se servano dipende dalla scala. Un'azienda con un solo account cloud e una suite d'ufficio può spesso arrivare lontano con le raccomandazioni integrate e i cruscotti di punteggio di sicurezza dei fornitori, senza costi aggiuntivi. Più account cloud, molti strumenti SaaS o dati regolamentati rendono più convenienti strumenti dedicati. Nessuno di essi osserva il comportamento dei dispositivi sulla Sua rete; quello è un altro livello, coperto dal rilevamento di rete.
Faccia domande con risposte verificabili e che contano se qualcosa va storto. Evidenze: quali rapporti o certificati indipendenti coprono il servizio che acquista, come un rapporto SOC 2 Type II o un certificato ISO/IEC 27001, con perimetro e data, e se può leggerli. Dati: dove vengono archiviati e trattati, quali sub-responsabili sono coinvolti, se vengono usati per addestrare modelli, per quanto tempo sono conservati e come li riottiene in un formato utilizzabile quando se ne va. Accesso: single sign-on, MFA obbligatoria, permessi basati sui ruoli e log di audit esportabili. Incidenti: quanto rapidamente La avvisano, con quale canale e quale supporto offrono ai Suoi obblighi di notifica ai sensi del GDPR o della NIS2. Resilienza: backup, obiettivi di ripristino e protezione contro l'abuso di un account di amministrazione. Vulnerabilità: come gestiscono le segnalazioni e quanto in fretta correggono. Porti le risposte chiave nel contratto o nell'accordo sul trattamento dei dati, non solo in un questionario. Un fornitore più piccolo con risposte chiare e oneste può essere più sicuro di uno grande con risposte vaghe.
Di solito entrambi, per cose diverse. Il fornitore è responsabile della sicurezza del proprio servizio e, ai sensi del GDPR, un fornitore che agisce come Suo responsabile del trattamento deve informarLa senza ingiustificato ritardo dopo essere venuto a conoscenza di una violazione dei dati personali. Lei, come titolare dei dati dei Suoi clienti o dipendenti, resta responsabile di valutare il rischio per le persone coinvolte e, se necessario, di notificare l'autorità di controllo entro 72 ore dal momento in cui ne è venuto a conoscenza, e di informare gli interessati se il rischio è elevato. Se la Sua azienda rientra nella NIS2, un incidente significativo causato da un fornitore può far scattare i Suoi obblighi di notifica, e la NIS2 si aspetta che gestisca la sicurezza della catena di approvvigionamento tra le misure di gestione del rischio. Molti aspetti pratici li decidono i contratti: tempi di notifica, cooperazione, informazioni che riceverà e responsabilità. Si prepari prima: sappia quali fornitori detengono quali dati, conservi i loro contatti per la sicurezza e includa una violazione presso un fornitore nel piano di risposta agli incidenti. La legge nazionale di recepimento della NIS2 può aggiungere dettagli; la verifichi.
Non di gestirla, ma di gestire il rischio che ne deriva per Lei, se la Sua azienda rientra nella NIS2. La direttiva (UE) 2022/2555 elenca la sicurezza della catena di approvvigionamento, compresi gli aspetti di sicurezza dei rapporti con i fornitori diretti e i fornitori di servizi, tra le misure di gestione del rischio di cibersicurezza dell'articolo 21. In pratica significa sapere da quali fornitori cloud e SaaS dipendono i Suoi servizi importanti, valutarne la sicurezza, inserire requisiti nei contratti e pianificare un loro guasto o una loro compromissione. I fornitori di servizi di cloud computing sono essi stessi elencati nella NIS2 come soggetti del settore delle infrastrutture digitali, quindi molti hanno obblighi propri, il che aiuta ma non sostituisce la Sua valutazione. Evidenze utili dai fornitori sono rapporti di audit indipendenti, certificazioni con un perimetro chiaro, impegni di notifica degli incidenti e condizioni di uscita. Tenga un registro dei fornitori che indichi i dati e i servizi che ciascuno supporta, e lo riveda ogni anno e dopo gli incidenti. I recepimenti nazionali possono aggiungere requisiti o linee guida; verifichi la legge del Suo Paese e le pubblicazioni della Sua autorità.
Prima contenere, poi capire che cosa è successo, e documentare tutto man mano. Contenimento: reimposti la password e revochi tutte le sessioni e i token attivi dell'account; rimuova i metodi MFA che non ha registrato e li registri di nuovo; cerchi ed elimini nuove regole di inoltro, consensi ad app, chiavi API, utenti o ruoli di amministrazione creati dall'attaccante; e se era un account di amministrazione, esamini l'intero tenant o account cloud, perché gli attaccanti creano backdoor. Indagine: usi i log di accesso e di audit del fornitore per stabilire quando è iniziato l'accesso, da dove e che cosa è stato letto, modificato, condiviso o scaricato; verifichi se la stessa password era usata altrove. Poi definisca gli obblighi: l'accesso a dati personali può comportare una notifica ai sensi del GDPR entro 72 ore da quando ne è venuto a conoscenza, e un incidente significativo può dover essere notificato ai sensi della NIS2 nel Suo Paese. Guardi anche i dispositivi: la password rubata proveniva spesso da un portatile infetto o da una pagina di phishing. In ogni piano NetSenX può mostrare se un dispositivo della Sua rete ha iniziato in quel periodo a fare beaconing, scansioni o invii insoliti. Non vede gli accessi all'account cloud.