Governance del dangling DNS per NIS2, DORA e GDPR

Il CISO riceve il messaggio alle 07:12 di lunedì.

Un ricercatore di sicurezza ha individuato promo.company.com, che punta a un’applicazione cloud abbandonata. Il record DNS è ancora attivo. La risorsa cloud non esiste più. Il tenant SaaS che in passato erogava la campagna è stato eliminato sei mesi prima, poco dopo il passaggio del Marketing a un’altra piattaforma. Nessuno ha rimosso il CNAME.

Alle 08:30 la domanda non è più: “Qualcuno può prendere il controllo del sottodominio?”. È: “Perché nessuno sapeva che questo asset esistesse?”.

Alle 09:15 è coinvolta la funzione Legale, perché il sottodominio in passato raccoglieva indirizzi e-mail per una lista d’attesa di prodotto. È coinvolta la funzione Acquisti, perché la piattaforma della campagna era gestita da un’agenzia. È coinvolta la funzione Compliance, perché l’azienda si sta preparando a un audit di sorveglianza ISO/IEC 27001:2022, all’adeguamento a NIS2 e a questionari di assurance dei clienti. Il DPO chiede se l’esposizione possa diventare una violazione dei dati personali ai sensi del GDPR qualora il sottodominio venga usato in modo offensivo. Il CFO chiede se la stessa debolezza possa interessare un portale pagamenti nel perimetro regolamentato dei servizi finanziari del gruppo.

La correzione tecnica può richiedere pochi minuti. Il problema di governance può richiedere mesi, se l’organizzazione non è in grado di dimostrare che ogni asset esposto a Internet è noto, ha un proprietario, è riesaminato, monitorato e dismesso tramite un processo controllato.

Per questo la prevenzione del dangling DNS e del subdomain takeover non può essere trattata come una mera attività di pulizia DNS. Un record DNS obsoleto è spesso un sintomo visibile di carenze di controllo più profonde: inventario degli asset incompleto, titolarità debole, assenza di evidenze di dismissione, controllo delle modifiche inadeguato, gestione insufficiente dell’uscita dai fornitori, monitoraggio inadeguato della superficie di attacco esterna e classificazione degli incidenti non chiara.

Per i clienti Clarysec, il dangling DNS è una prova del sistema di gestione. Dimostra se politiche, controlli, registri, evidenze e responsabilità funzionano davvero quando una dipendenza cloud dimenticata diventa un’opportunità per un attaccante.

Che cosa significa davvero dangling DNS

Il subdomain takeover diventa possibile quando un record DNS, spesso un CNAME, punta a una risorsa che non esiste più o non è più controllata dall’organizzazione. Se un attaccante può rivendicare o ricreare la risorsa di destinazione sulla piattaforma cloud o SaaS, potrebbe essere in grado di pubblicare contenuti sotto un sottodominio considerato affidabile dell’organizzazione.

Esempi comuni includono:

• Un CNAME che punta a un servizio applicativo cloud non rivendicato.
• Un hostname SaaS personalizzato lasciato nel DNS dopo la cancellazione dell’abbonamento.
• Una distribuzione CDN rimossa dalla console del fornitore ma ancora referenziata nel DNS pubblico.
• Un microsito marketing dismesso da un’agenzia senza rimozione del DNS.
• Un endpoint di archiviazione o una mappatura di sito statico che può essere registrata nuovamente.
• Un sottodominio di sviluppo esposto tramite un progetto platform-as-a-service dimenticato.

L’impatto aziendale può essere significativo. Gli attaccanti possono ospitare pagine di phishing, acquisire credenziali, distribuire malware, abusare della reputazione del dominio, intercettare dati di sessione o danneggiare la fiducia nel marchio. Quando il sottodominio in precedenza trattava dati personali, anche un takeover di breve durata può attivare un’analisi della violazione ai sensi del GDPR. Quando il servizio interessato supporta operazioni finanziarie regolamentate, l’incidente può richiedere anche una valutazione ai sensi di DORA o dei framework interni di rischio ICT.

Gli auditor considerano sempre più spesso il dangling DNS come evidenza della maturità dei controlli. Un singolo record obsoleto può indicare che l’organizzazione non sa che cosa possiede, chi ne è proprietario, come vengono riesaminate le modifiche, come viene gestita l’uscita dai servizi cloud o come sono monitorati gli asset esposti verso l’esterno.

Per questo Clarysec mappa questo tema rispetto alle aspettative di audit di ISO/IEC 27001:2022, ISO/IEC 27002:2022, NIS2, DORA, GDPR, NIST CSF 2.0 e COBIT 2019.

Perché ISO 27001:2022 è la base operativa più efficace

Il modo più solido per governare il dangling DNS non consiste nel creare programmi separati per NIS2, DORA e GDPR. Consiste nell’utilizzare ISO/IEC 27001:2022 come base del sistema di gestione e produrre una sola volta le evidenze necessarie per più esigenze di assurance.

I requisiti rilevanti iniziano prima dell’Allegato A. Le clausole da 4.1 a 4.4 richiedono all’organizzazione di comprendere il proprio contesto, i requisiti delle parti interessate, il campo di applicazione del SGSI e le dipendenze con altre organizzazioni. Per la governance del dangling DNS, il campo di applicazione dovrebbe includere DNS esterno, domini, registrar, servizi cloud, piattaforme SaaS, agenzie, hosting gestito, CDN e qualsiasi terza parte in grado di creare o dismettere servizi esposti a Internet.

Le clausole da 5.1 a 5.3 rendono questo un tema di leadership e responsabilità. La direzione deve allineare il SGSI alla direzione strategica dell’organizzazione, fornire risorse, comunicare l’importanza della sicurezza delle informazioni e assegnare responsabilità. Se il Marketing può lanciare un microsito, il team di engineering può creare endpoint cloud e la funzione Acquisti può risolvere contratti SaaS, l’organizzazione ha bisogno di un modello di governance che assegni chiaramente la titolarità del DNS e dei servizi tra tutte queste funzioni.

Le clausole da 6.1.1 a 6.1.3 forniscono la logica di valutazione del rischio, trattamento del rischio e Dichiarazione di Applicabilità. Il dangling DNS dovrebbe essere registrato come scenario di rischio realistico, non solo come output di uno scanner. Incide su riservatezza, integrità e disponibilità e spesso si collega a obblighi legali, normativi e contrattuali.

Le clausole 7.5, 8.1, 8.2 e 8.3 trasformano la governance in evidenze. Richiedono informazioni documentate controllate, processi operativi pianificati e controllati, considerazione delle modifiche non intenzionali, controllo dei processi forniti dall’esterno, valutazioni periodiche del rischio ed esiti documentati del trattamento.

L’Allegato A fornisce poi il catalogo dei controlli. Nei progetti Clarysec, le relazioni principali con ISO/IEC 27002:2022 sono di norma le seguenti:

Il punto è semplice. ISO/IEC 27001:2022 non richiede una pulizia una tantum eroica. Richiede un modello operativo controllato che prevenga il ripetersi del problema.

La visione di Zenith Controls: un rischio, tre ancoraggi di controllo

In Zenith Controls: The Cross-Compliance Guide Zenith Controls, Clarysec utilizza i controlli ISO/IEC 27002:2022 pertinenti come ancoraggi di conformità trasversale. Per la governance del dangling DNS e del subdomain takeover, tre controlli sono centrali.

Il controllo 5.9, Inventario delle informazioni e degli altri asset associati, è classificato come preventivo, supporta riservatezza, integrità e disponibilità, si allinea al concetto di cibersicurezza Identify e ricade nella gestione degli asset come capacità operativa, con governance, ecosistema e protezione come domini di sicurezza.

Il controllo 5.23, Sicurezza delle informazioni per l’uso dei servizi cloud, è classificato come preventivo, supporta riservatezza, integrità e disponibilità, si allinea a Protect e ricade nella sicurezza delle relazioni con i fornitori come capacità operativa, con governance, ecosistema e protezione come domini di sicurezza.

Il controllo 8.8, Gestione delle vulnerabilità tecniche, è classificato come preventivo, supporta riservatezza, integrità e disponibilità, si allinea a Identify e Protect e ricade nella gestione di minacce e vulnerabilità come capacità operativa, con governance, ecosistema, protezione e difesa come domini di sicurezza.

Questo è importante perché il dangling DNS non è solo una carenza di controllo sugli asset, non è solo una carenza di controllo cloud e non è solo una vulnerabilità. È tutte e tre le cose. L’organizzazione deve dimostrare che inventario degli asset, governance dell’utilizzo del cloud e gestione delle vulnerabilità si rafforzano reciprocamente.

Clarysec aggiunge spesso pratiche di supporto attorno a questi ancoraggi: ISO/IEC 27005 per la disciplina di valutazione e trattamento del rischio, ISO/IEC 27017 per la governance della sicurezza dei servizi cloud, ISO/IEC 27018 quando i servizi cloud trattano PII, ISO/IEC 27701 per la gestione delle informazioni sulla privacy e ISO 22301 quando continuità e risposta alla crisi sono rilevanti.

Le evidenze di policy che richiedono già il controllo del ciclo di vita DNS

Molte organizzazioni dispongono già di politiche che, se applicate correttamente, prevenirebbero il dangling DNS. La lacuna è che il controllo del ciclo di vita DNS non è collegato esplicitamente a tali politiche.

La Politica di gestione degli asset per PMI di Clarysec Politica di gestione degli asset per PMI, Requisiti di applicazione della politica, clausola 6.6.1, stabilisce:

Anche gli asset basati sul cloud (ad es. account di archiviazione, piattaforme SaaS, domini web) devono essere inclusi nell’inventario.

La stessa politica aggiunge, alla clausola 6.6.2:

Titolarità, finalità, privilegi di accesso e tempistiche di rinnovo devono essere documentati.

Per la governance del dangling DNS, questo significa che ogni sottodominio di produzione e ogni sottodominio non di produzione rilevante dovrebbe avere un proprietario nominato, una finalità aziendale, un servizio collegato, un modello di accesso e una data di riesame.

La clausola più importante è la 6.6.3:

I servizi scaduti o inutilizzati devono essere disattivati e rimossi dall’inventario.

Per il DNS, questa indicazione deve essere interpretata con attenzione. Rimuovere il servizio dall’inventario non è sufficiente. Devono essere riesaminati anche il record DNS, il binding cloud, la rivendicazione del dominio personalizzato SaaS, il certificato, la regola WAF, la configurazione CDN e la voce di monitoraggio.

La versione enterprise rafforza questo concetto più ampio di asset. La Politica di gestione degli asset di Clarysec Politica di gestione degli asset, Ambito di applicazione, clausola 2.2.5, stabilisce:

Asset logici: nomi di dominio, licenze, account utente, baseline di configurazione

Nomi di dominio e configurazioni non sono dettagli amministrativi. Sono asset che veicolano fiducia e possono diventare percorsi di attacco.

Il collegamento con il controllo delle modifiche è altrettanto importante. La Politica di gestione dei cambiamenti di Clarysec Politica di gestione dei cambiamenti, Finalità, clausola 1.1, stabilisce:

Questa politica istituisce un quadro formale per avviare, valutare, approvare, implementare e riesaminare le modifiche ai sistemi informativi, all’infrastruttura, alle applicazioni e ai processi correlati dell’organizzazione.

Una rimozione DNS, la cessazione di un servizio SaaS, l’eliminazione di un’applicazione cloud, una migrazione CDN o la dismissione di un microsito marketing dovrebbero quindi generare evidenze di modifica. L’assenza di un ticket di modifica è spesso il primo segnale di allarme in sede di audit.

Anche la governance del cloud deve essere collegata. La Politica di utilizzo del cloud di Clarysec Politica di utilizzo del cloud, Requisiti di governance, clausola 5.5, stabilisce:

Il Team di sicurezza delle informazioni deve valutare regolarmente il traffico di rete, l’attività DNS e i log per rilevare l’utilizzo non autorizzato del cloud (shadow IT). Le violazioni rilevate devono essere indagate tempestivamente.

Per la prevenzione del subdomain takeover, il monitoraggio dell’attività DNS non riguarda solo lo shadow IT. Riguarda anche gli asset IT obsoleti: asset che in passato erano autorizzati, ma che non sono più controllati.

Un flusso operativo Clarysec per la governance del dangling DNS

Un programma solido per il dangling DNS non è complesso. Deve essere disciplinato, ripetibile e collegato al SGSI, alla gestione delle vulnerabilità, alla gestione dei cambiamenti e al ciclo di vita dei fornitori.

Per le PMI, questo può iniziare come registro leggero. Per le imprese più grandi, di norma si integra con esportazioni DNS, gestione della superficie di attacco esterna, inventari degli asset cloud, registrazioni CMDB, scanner di vulnerabilità, allerte SIEM e sistemi di ticketing.

La domanda di governance resta la stessa: potete dimostrare che ogni sottodominio raggiungibile dall’esterno è noto, ha un proprietario, è monitorato e può essere rimosso tramite un processo controllato?

Il sottodominio di campagna abbandonato, gestito correttamente

Torniamo all’incidente del lunedì. promo.company.com punta a un sito di campagna SaaS abbandonato.

Per prima cosa, il responsabile della sicurezza crea una registrazione di vulnerabilità perché l’asset è esposto verso l’esterno. La Politica di gestione delle vulnerabilità e delle patch di Clarysec Politica di gestione delle vulnerabilità e delle patch, Requisiti di applicazione della politica, clausola 6.1.1, stabilisce:

Tutti i sistemi devono essere sottoposti a scansione almeno mensilmente; gli asset ad alto rischio o esposti verso l’esterno devono essere sottoposti a scansione settimanalmente.

Per le PMI, la politica equivalente rafforza la prioritizzazione. La Politica di gestione delle vulnerabilità e delle patch per PMI Politica di gestione delle vulnerabilità e delle patch per PMI, Requisiti di applicazione della politica, clausola 6.5.1, stabilisce:

I sistemi che trattano dati personali, forniscono accesso remoto o sono esposti verso l’esterno devono essere prioritizzati per scansioni e aggiornamenti.

In secondo luogo, il proprietario viene identificato tramite il registro degli asset. Se il proprietario è sconosciuto, ciò costituisce una carenza di controllo rispetto alla governance degli asset. Il registro viene aggiornato per includere nome DNS, provider di destinazione, proprietario aziendale originario, classificazione dei dati, fornitore e stato.

In terzo luogo, l’IT verifica la piattaforma cloud o SaaS. Se l’account cloud è stato eliminato, la Politica di utilizzo del cloud per PMI di Clarysec Politica di utilizzo del cloud per PMI, Requisiti di applicazione della politica, clausola 6.3.6, è direttamente pertinente:

Gli account cloud eliminati devono essere riesaminati dal fornitore IT o dal direttore generale (GM) per verificare accessi residui, dati orfani o contenuti trascurati.

In quarto luogo, il Change Manager apre un ticket di modifica di emergenza o accelerato per rimuovere il record DNS o rivendicare temporaneamente la risorsa prima della rimozione. Il ticket include valutazione dell’impatto, piano di rollback, approvazioni, evidenze di implementazione e convalida post-modifica.

In quinto luogo, il responsabile privacy valuta se il sottodominio abbia trattato o potuto esporre dati personali. La Politica sulla sicurezza dei dati personali e sul controllo degli accessi di Clarysec Politica sulla sicurezza dei dati personali e sul controllo degli accessi, Configurazione sicura e gestione delle vulnerabilità, clausola 4.7.4, stabilisce:

[Entrambi] Il Proprietario del sistema / Proprietario dell’applicazione DEVE registrare in REG12 la copertura della valutazione delle vulnerabilità per i sistemi che trattano PII almeno trimestralmente e dopo ogni modifica tecnica sostanziale.

La clausola 4.7.5 aggiunge:

[Entrambi] Il Responsabile della sicurezza delle informazioni DEVE registrare in REG12 le vulnerabilità ad alto rischio non risolte che interessano PII entro cinque giorni lavorativi dalla convalida.

Queste clausole si applicano sia quando l’organizzazione agisce come titolare del trattamento sia quando agisce come responsabile del trattamento, perché sono contrassegnate come [Entrambi]. Per un problema di dangling DNS che coinvolge PII, le evidenze non devono rimanere soltanto in un ticket tecnico. Devono essere riflesse nel registro delle evidenze delle vulnerabilità relative a PII.

In sesto luogo, se un’agenzia o un fornitore SaaS ospitava la campagna, la funzione Acquisti verifica le registrazioni relative alle terze parti. La Politica per la gestione privacy di responsabili, sub-responsabili e terze parti di Clarysec Politica per la gestione privacy di responsabili, sub-responsabili e terze parti, Identificazione e classificazione del rapporto, clausola 4.1.2, stabilisce:

[Tutti] Il Proprietario del processo / Titolare dell’attività DEVE identificare in REG08 ogni rapporto con terze parti proposto che tratterà, accederà, riceverà, conserverà, trasmetterà, supporterà o altrimenti interesserà PII prima dell’approvvigionamento, dell’onboarding, del rinnovo o di una modifica sostanziale privacy relativa a terze parti.

La clausola 4.5.5 richiede:

[Entrambi] Il Responsabile del fornitore / Responsabile Acquisti DEVE registrare in REG08 i luoghi del trattamento, i luoghi di hosting e gli indicatori di trasferimento internazionale, e collegare a REG09 le evidenze di trasferimento applicabili prima di approvare un responsabile del trattamento, un sub-responsabile, una modifica del luogo o una modifica del servizio rilevante ai fini dei trasferimenti.

Infine, il responsabile della compliance prepara il pacchetto di evidenze. La Politica di audit e monitoraggio della conformità di Clarysec Politica di audit e monitoraggio della conformità, Obiettivi, clausola 3.4, indica che un obiettivo è:

Generare evidenze difendibili e una traccia di audit a supporto di richieste delle autorità di regolamentazione, procedimenti legali o richieste di assurance dei clienti.

Questo è l’esito di cui il CISO ha bisogno quando un cliente, un’autorità di regolamentazione o un auditor chiede: “Come sapete che non accadrà di nuovo?”.

Dove si inserisce Zenith Blueprint

Zenith Blueprint di Clarysec Zenith Blueprint converte i controlli in pratiche operative idonee all’audit. Il dangling DNS si mappa in modo rilevante su quattro aree.

Nella fase Controlli in azione, il passaggio 22 copre i controlli organizzativi da 5.1 a 5.18, incluso il controllo 5.9 di ISO/IEC 27002:2022. Zenith Blueprint afferma:

Nessuna organizzazione può proteggere ciò che non sa di possedere. Il controllo 5.9 formalizza questo principio fondamentale, richiedendo l’istituzione e il mantenimento di un inventario aggiornato di tutte le informazioni e degli asset associati rilevanti per il SGSI.

Prosegue:

Nella sua forma più strategica, un inventario degli asset funge da sistema nervoso centrale del vostro SGSI.

L’inventario dei sottodomini non è un elenco accessorio. Alimenta le decisioni sugli accessi, le scansioni di vulnerabilità, il logging, la gestione dei fornitori, la mappatura privacy e la risposta agli incidenti.

Nel passaggio 20, Zenith Blueprint copre i controlli tecnologici da 8.18 a 8.26. Per il controllo 8.21, Sicurezza dei servizi di rete, richiede alle organizzazioni di convalidare la sicurezza dei servizi di rete:

Elencare tutti i servizi di rete interni ed esterni (DNS, VPN, SMTP, DHCP, gateway API, ecc.).

Per questo provider DNS, registrar, DNS cloud, piattaforme CDN e funzionalità SaaS per domini personalizzati devono rientrare nel registro dei servizi.

Nel passaggio 19, Zenith Blueprint copre i controlli tecnologici da 8.1 a 8.17. Per il controllo 8.8, afferma:

La gestione delle vulnerabilità è una delle aree più critiche della moderna igiene cyber. Sebbene firewall e strumenti antivirus forniscano protezione, possono essere vanificati se sistemi privi di patch o servizi configurati in modo errato restano esposti.

Un record DNS dangling è un percorso di servizio esterno configurato in modo errato. Anche quando non esiste una CVE, dovrebbe essere gestito tramite la gestione delle vulnerabilità: convalidare, attribuire un punteggio, assegnare, correggere, rieseguire il test e chiudere.

Nel passaggio 23, Zenith Blueprint affronta i controlli organizzativi da 5.19 a 5.37. Per il controllo 5.23, raccomanda:

Elencare tutti i servizi cloud attualmente in uso (5.23), incluso lo shadow IT ove noto. Identificare chi li ha approvati e se è stata eseguita due diligence. Sviluppare una checklist di valutazione leggera che copra ubicazione dei dati, modello di accesso, logging e cifratura.

Per la prevenzione del subdomain takeover, aggiungere domini personalizzati, dipendenze DNS, proprietario della dismissione ed evidenze di uscita a tale checklist di valutazione dei servizi cloud.

Mappatura NIS2, DORA e GDPR

NIS2 rende la governance del dangling DNS un tema a livello di organo di gestione per molti soggetti essenziali e importanti. Article 20 richiede agli organi di gestione di approvare le misure di gestione dei rischi di cibersicurezza, supervisionarne l’attuazione e seguire una formazione in materia di cibersicurezza. Article 21 richiede misure tecniche, operative e organizzative adeguate e proporzionate secondo un approccio multirischio. Le aree minime includono analisi dei rischi, gestione degli incidenti, continuità operativa, sicurezza della catena di fornitura, acquisizione, sviluppo e manutenzione sicuri, gestione delle vulnerabilità, valutazione dell’efficacia, igiene cyber, formazione, controllo degli accessi e gestione degli asset.

Un programma di dangling DNS si mappa in modo diretto su queste aree. Article 21(3) richiede inoltre che la sicurezza della catena di fornitura consideri le vulnerabilità specifiche di ciascun fornitore diretto o prestatore di servizi. Se un’agenzia di marketing, un fornitore SaaS, un fornitore di hosting gestito o una piattaforma cloud gestisce domini personalizzati, i controlli specifici del fornitore dovrebbero coprire titolarità del DNS, uscita dal servizio, supporto agli incidenti e consegna delle evidenze.

Article 23 rileva se il takeover si verifica o è in grado di causare una grave interruzione operativa, una perdita finanziaria o un danno materiale o immateriale considerevole. NIS2 utilizza una segnalazione per fasi: preallarme entro 24 ore dal momento della presa di conoscenza di un incidente significativo, notifica entro 72 ore, rapporti intermedi ove richiesti e rapporto finale entro un mese dalla notifica dell’incidente.

Per le entità finanziarie, DORA è il regime settoriale di resilienza operativa digitale. Articles 5 e 6 richiedono un quadro interno di governance e controllo per la gestione del rischio ICT, con responsabilità ultima dell’organo di gestione, ruoli ICT chiari, politiche per disponibilità, autenticità, integrità e riservatezza dei dati, piani di audit, risorse, politica sui servizi di terze parti e un quadro documentato di gestione del rischio ICT.

Gli Articles da 8 a 14 costituiscono il nucleo operativo. Article 8 richiede identificazione, classificazione e documentazione delle funzioni aziendali supportate da ICT, degli asset informativi, degli asset ICT, delle dipendenze, delle interconnessioni con terze parti ICT, degli inventari, degli scenari di rischio e dei sistemi legacy. Un CNAME dangling è spesso una dipendenza mancante. Article 9 richiede protezione e prevenzione. Article 10 richiede la rilevazione di attività anomale, incidenti ICT e potenziali singoli punti di guasto. Gli Articles 11 e 12 affrontano continuità, ripristino, backup e restoration. Article 13 richiede apprendimento da vulnerabilità, minacce, incidenti e test.

Gli Articles da 17 a 19 formalizzano gestione, classificazione e segnalazione degli incidenti. Gli Articles da 28 a 30 rendono il rischio ICT di terze parti basato sul ciclo di vita. Le entità finanziarie restano pienamente responsabili quando utilizzano prestatori di servizi ICT. Per la preparazione a DORA, Clarysec raccomanda di aggiungere quattro campi a ogni registro DNS e dei servizi cloud: supporto a funzione essenziale o importante, fornitore terzo ICT, riferimento contrattuale o di registro e stato del test di uscita.

Il GDPR si applica quando il problema riguarda dati personali. Un subdomain takeover non è automaticamente una violazione dei dati personali, ma può diventarlo se il sottodominio interessato raccoglie credenziali, acquisisce dati di moduli, impersona un servizio, espone identificativi utente o consente accessi non autorizzati a dati personali. GDPR Article 5 richiede integrità, riservatezza e responsabilizzazione. Article 32 richiede un’adeguata sicurezza del trattamento. Article 33 può richiedere la notifica all’autorità di controllo se una violazione dei dati personali è suscettibile di presentare un rischio per i diritti e le libertà delle persone fisiche.

La Politica di gestione degli incidenti e delle violazioni di dati personali di Clarysec Politica di gestione degli incidenti e delle violazioni di dati personali, Classificazione e valutazione della violazione, clausola 4.2.6, supporta questa analisi dei presupposti multi-regime:

[Condizionale] Il Responsabile privacy / Responsabile del PIMS DEVE valutare i presupposti di segnalazione legali, settoriali, del settore finanziario, di cibersicurezza, contrattuali, verso i clienti e verso i destinatari del servizio applicabili a ciascun incidente relativo ai dati personali ad alto impatto e registrare l’esito dell’applicabilità in REG01, REG08 e REG10.

Questa registrazione della decisione è esattamente ciò che serve quando un subdomain takeover può coinvolgere GDPR, NIS2, DORA, contratti e notifiche ai clienti.

Come gli auditor testeranno le vostre evidenze

Un SGSI integrato dovrebbe consentire di rispondere ad auditor diversi con la stessa base di evidenze. La formulazione della domanda cambia, ma spesso la prova è la stessa.

Una prospettiva di assurance più ampia include spesso NIST CSF 2.0 e COBIT 2019. NIST CSF 2.0 aiuta a esprimere lo stato desiderato tramite esiti GOVERN, IDENTIFY, PROTECT, DETECT, RESPOND e RECOVER. Un profilo attuale potrebbe mostrare riesami DNS trimestrali manuali e dismissione SaaS incoerente. Un profilo target potrebbe richiedere verifiche automatizzate settimanali del takeover, assegnazione obbligatoria del proprietario, evidenze di uscita dei fornitori e integrazione con la gestione dei cambiamenti.

Un auditor orientato a COBIT 2019 o ISACA di norma chiederà chi possiede il processo, come il rischio è valutato e indirizzato, se le modifiche sono controllate, se i fornitori sono gestiti, se configurazioni e asset sono affidabili e se le evidenze di assurance supportano la reportistica di gestione. Potrebbe non chiedere inizialmente un elenco di CNAME. Potrebbe chiedere come la direzione sappia che i servizi digitali esterni sono controllati lungo tutto il loro ciclo di vita.

Che aspetto hanno buone evidenze di audit

Un pacchetto di audit per il dangling DNS dovrebbe essere abbastanza snello da poter essere mantenuto, ma sufficientemente completo da risultare difendibile. Clarysec raccomanda di norma il seguente set di evidenze:

• Inventario delle zone DNS con fonte, data, tipo di record, target e proprietario.
• Risultati delle scansioni della superficie di attacco esterna che mostrano le verifiche di takeover.
• Voci del registro degli asset per domini, sottodomini, servizi cloud, applicazioni SaaS e CDN.
• Registro dei servizi che mostra responsabilità interne o del fornitore.
• Ticket di modifica per creazione, modifica ed eliminazione dei record DNS.
• Checklist di attivazione cloud e SaaS che includano riesame di domini personalizzati e DNS.
• Contratti con i fornitori o clausole di sicurezza relative a DNS, hosting, supporto agli incidenti e uscita.
• Ticket di vulnerabilità con gravità, proprietario, data di remediation ed evidenze di retest.
• Valutazione PII quando il sottodominio tratta o ha trattato dati personali.
• Registrazioni di classificazione degli incidenti per takeover sospetto o confermato.
• Lezioni apprese e procedure aggiornate dopo le risultanze.

Anche le metriche sono importanti. La direzione dovrebbe vedere il numero di sottodomini esterni, la percentuale con proprietari assegnati, il numero di risultanze dangling, il tempo medio di remediation, le risultanze ad alto rischio scadute, i sottodomini ospitati da fornitori senza riferimento contrattuale corrente e la percentuale di uscite dal cloud con evidenza della rimozione DNS.

Queste metriche trasformano l’igiene tecnica in evidenze di supervisione della direzione.

Schemi di carenza comuni rilevati da Clarysec

Tra clienti SaaS, fintech, tecnologia sanitaria, servizi gestiti ed e-commerce, ricorrono gli stessi schemi.

Primo, la titolarità del DNS è suddivisa tra team. Il team di engineering possiede il cloud. Il Marketing possiede le campagne. L’IT possiede l’accesso al provider DNS. La funzione Acquisti possiede la cessazione del SaaS. Nessuno possiede l’intero ciclo di vita.

Secondo, l’eliminazione cloud è trattata come la fine del servizio. In realtà, DNS, certificati, regole WAF, monitoraggio, segreti, documentazione e registrazioni dei fornitori possono rimanere.

Terzo, gli scanner di vulnerabilità si concentrano sugli host attivi ma non rilevano condizioni di takeover specifiche dei provider. Le organizzazioni hanno bisogno di controlli della superficie di attacco esterna che comprendano gli stati di errore comuni di SaaS e cloud.

Quarto, le procedure di uscita dei fornitori si concentrano su fatture e restituzione dei dati, ma non su domini personalizzati, record DNS e modifiche dei sub-responsabili.

Quinto, i team privacy vengono informati troppo tardi. Se un sottodominio ha trattato PII, il DPO o il responsabile privacy dovrebbe partecipare alla classificazione prima che vengano formulate assunzioni.

Sesto, le evidenze esistono ma sono disperse. L’esportazione DNS è in uno strumento, i ticket di modifica in un altro, i contratti dei fornitori nella funzione Acquisti, i report di vulnerabilità negli scanner e l’analisi privacy nelle e-mail. Gli auditor vedono la frammentazione come una debolezza.

Il toolkit Clarysec risolve questo problema collegando politiche, registri, controlli e flussi di evidenza.

Piano d’azione di 30 giorni per la governance DNS

Se avete trovato un record DNS dangling, assumete che ce ne siano altri. Se non ne avete trovati, assicuratevi di poter dimostrare perché.

Iniziate con questo piano di 30 giorni:

1. Esportare tutte le zone DNS autoritative.
2. Identificare i record CNAME, ALIAS, A e AAAA che puntano a servizi cloud, SaaS, CDN e gestiti da agenzie.
3. Assegnare proprietari e finalità aziendali.
4. Eseguire verifiche di takeover e convalidare manualmente i record sospetti.
5. Creare ticket di vulnerabilità per i rischi confermati.
6. Rimuovere o rivendicare i record esposti tramite controllo delle modifiche.
7. Aggiornare il registro degli asset, il registro cloud e il Registro dei fornitori.
8. Riesaminare se un sottodominio interessato abbia trattato PII.
9. Aggiungere controlli del ciclo di vita DNS all’attivazione cloud, all’approvvigionamento SaaS e all’uscita dei fornitori.
10. Segnalare le metriche alla direzione.

La correzione tecnica del dangling DNS è spesso semplice. La correzione della governance è ciò che previene il prossimo takeover.

Clarysec può aiutarvi a rendere operativo questo approccio utilizzando Zenith Blueprint Zenith Blueprint, Zenith Controls Zenith Controls e il nostro toolkit di politiche per gestione degli asset, utilizzo del cloud, gestione delle vulnerabilità, governance dei fornitori, sicurezza PII, risposta agli incidenti ed evidenze di audit.

Se desiderate un approccio idoneo all’audit, Clarysec può aiutarvi a costruire il pacchetto di evidenze sull’esposizione DNS e cloud, mapparlo a ISO/IEC 27001:2022, NIS2, DORA e GDPR, e trasformare sottodomini dimenticati in asset controllati, con proprietario e monitorati. Scaricate il toolkit Clarysec pertinente, richiedete una demo o pianificate una valutazione della governance DNS prima che un penetration tester, un auditor o un attaccante trovi il prossimo puntatore dimenticato.