Convergenza di ITDR, PAM e IGA. Quale dei tre è presente quando arriva l'attacco?
Oct 5, 2026
Il nostro Rapporto sulla Sicurezza dell'Identità e dei Dati 2026 posiziona l'identità compromessa davanti ai permessi mal configurati come la principale via verso l'accesso non autorizzato, 41,8% rispetto al 33,9%. Se l'identità è il modo per entrare, i controlli intorno all'identità devono stare insieme, e questa è la ragione dietro la maggior parte del consolidamento che abbiamo visto negli ultimi anni.
Ma come viene diviso il lavoro? Gestione dell'Accesso Privilegiato e Governance dell'Identità e Amministrazione gestiscono la prevenzione: decidono chi detiene il privilegio e quando è permesso usarlo. Il lavoro di Rilevamento e Risposta alle Minacce di Identità è diverso. Osserva e ti dice quando qualcosa è già andato storto. Unisci tutti e tre in una console e sotto di essa, hai ancora tre lavori separati.
Abbiamo scoperto dove quella divisione si rompe pagando estranei per attaccarci.
Cosa hanno ottenuto gli aggressori reali
Abbiamo eseguito una gestione dei bug bounty attraverso Bugcrowd contro una Active Directory moderatamente rafforzata. Gli attacchi sono stati presentati da persone pagate per risultati piuttosto che per completare una lista di controllo. DCSync, dumping del processo LSASS e bypass dell'accesso NTDS.dit erano tra questi. Abbiamo scoperto che il 100% degli attacchi eseguiti da utenti standard e account amministratore IT sono stati rilevati e prevenuti.
Ma nei casi in cui un hacker ha iniziato a mantenere credenziali di amministratore di dominio valide, gli attacchi hanno avuto successo, perché le richieste provenienti da tale account erano le richieste che fa un amministratore di dominio. Quel caso appartiene a PAM. Scoprire quali account detengono potere nascosto appartiene a IGA.
La scommessa di rollback non sempre ripaga
Abbiamo fermato tutto in quell'elenco mentre stava ancora being tentato, non dopo il fatto. Quella distinzione conta più di quanto sembri. Un attacco fermato a metà del tentativo non diventa mai un incidente che qualcuno deve investigare; non fa mai il nome della tua azienda nei titoli delle violazioni.
Parte di essa può essere annullata: ripristinare un'appartenenza al gruppo, reimpostare una password, eliminare una delega, e sei più o meno tornato al punto di partenza.
Ma con alcuni attacchi smette di funzionare. Prendi Certificate Services ad esempio. Un modello che consente al richiedente di fornire il proprio nome alternativo del soggetto emetterà un certificato che nomina il richiedente come qualcun altro. Registrati, nomina un account privilegiato e te ne vai con una credenziale che si autentica come tale.
Nessuno dei soliti fix tocca questo. Reimposta la password e il certificato funziona ancora. Correggi il modello e hai solo fermato l'aggressore successivo, non quello che già detiene una credenziale valida. Ripristina la directory e non l'hai ancora toccato, perché il privilegio non era mai nella directory. Si trova in un archivio certificati, valido fino alla scadenza o fino a quando qualcuno revoca manualmente quel certificato specifico.
A quel punto, un avviso ti dice solo da dove iniziare a scavare. Bloccare l'iscrizione è l'unica cosa che lo ferma in modo affidabile.
Dove ogni pezzo deve fare il suo lavoro
PAM, IGA e ITDR contano solo in un momento specifico in un attacco. Se nessuno ha mai contrassegnato un account come privilegiato, la colpa è di IGA. Se una credenziale permanente esisteva già per tale account, PAM era l'unica cosa che avrebbe potuto fermare ciò che è venuto dopo. Se il compromesso è passato oltre entrambi e ha iniziato ad agire come un aggressore, ITDR era l'ultima occasione per catturarlo prima che si spostasse più lontano.
Come Netwrix aiuta
Netwrix PingCastle e 1Secure valutano la posizione della sicurezza dell'identità, mappano i risultati su MITRE ATT&CK e li classificano per rischio, quindi la correzione inizia con ciò che farebbe veramente male. A livello di protocollo, la prevenzione delle minacce brevettata blocca le letture NTDS.dit, i dump LSASS e le richieste di replica non autorizzate direttamente al controller di dominio, prima che abbiano successo. Netwrix Threat Manager rileva e risponde alle minacce che non possono essere bloccate. E quando qualcosa riesce a passare, il ripristino automatico della foresta AD e il rollback granulare in AD, Entra ID e Okta riportano le cose indietro, fino all'oggetto specifico che è stato modificato.
Se vuoi vederlo contro la tua directory, possiamo arrangiarci. Contattaci per una demo.
Condividi su
Scopri di più
Informazioni sull'autore
Tatiana Severina
Product Marketing Manager
Tatiana Severina è Product Marketing Manager presso Netwrix con oltre 15 anni di esperienza nel settore della cybersecurity aziendale e dell'infrastruttura IT, supportando gli sforzi di go-to-market in mercati globali. Si concentra sulla traduzione di complesse informazioni sulle minacce e capacità tecniche in un valore chiaro e azionabile per i professionisti della sicurezza. In Netwrix, lavora in modo trasversale per collegare la ricerca sulla sicurezza con il valore per il cliente, aiutando le organizzazioni a ridurre il rischio di identità, semplificare la risposta agli incidenti e rafforzare la loro strategia di sicurezza complessiva.
Scopri di più su questo argomento
Copilot ha rotto il tuo rilevamento delle minacce interne, e MITRE ne ha scritto la prova
NIST CSF 2.0: Novità nel Cybersecurity Framework
Violazione del sistema di Endpoint Management: perché Privileged Access Management (PAM) è ora fondamentale
Come aggiungere e rimuovere gruppi AD e oggetti nei gruppi con PowerShell
Attributi di Active Directory: Ultimo accesso