L'attuale modello per sicurezza informatica è rotto. Consiste nell'acquisizione e nell'implementazione di molti strumenti autonomi, ciascuno con la propria console, per analizzare i registri o il traffico e rilevare anomalie che potrebbero essere minacce. In questo modello, spetta a ciascun analista della sicurezza comunicare con altri analisti per determinare se il rilevamento individuale di ogni strumento (ognuno dei quali, di per sé, può sembrare innocuo), può essere correlato ad altri rilevamenti di altri strumenti per rivelare un attacco complesso.
Questo modello obbliga le aziende a creare stack di sicurezza complessi costituiti da file SIEM, SOAR, EDR, NDR e altro ancora, allo scopo di fornire strumenti all'azienda, identificare le minacce, rispondere alle minacce e gestire i rischi. L'acquisizione di tutti questi strumenti e la gestione delle loro licenze è complesso e costoso e la correlazione manuale richiesta per confrontare i rilevamenti di ogni strumento lascia molte lacune nell'infrastruttura di sicurezza complessiva.
Anche gli analisti sono spesso bombardati da falsi positivi da questi sistemi, che causano "stanchezza da allerta" e insoddisfazione sul lavoro. Anche le imprese che si dichiarano soddisfatte del proprio esistere SIEM e altri strumenti ammetteranno che la quantità di tempo ed energia che hanno investito per realizzare un'infrastruttura di sicurezza multi-strumento non sta fornendo i risultati richiesti.
Il caso per XDR
XDR, o Rilevamento e risposta estesi, è diventata una definizione onnicomprensiva per qualsiasi tecnologia che esegua rilevamento e risposta, perché nell'acronimo, X è in realtà una variabile. Sebbene X possa rappresentare "Endpoint+" o "Network+", ciò ignora l'attuale difficoltà dell'azienda dovuta a strumenti isolati, dati non correlati e alla stanchezza da allarmi. L'obiettivo principale di XDR è quello di affrontare questo problema, e quindi X deve significare "Tutto". Tutto, quindi, implica un approccio di piattaforma per coprire l'intera superficie di attacco attraverso rilevamento e risposta.
Questo approccio basato sulla piattaforma può correggere l'attuale modello fallimentare convertendo strumenti isolati in un set di strumenti unificato, convertendo dati non correlati in una rappresentazione correlata e dinamica della superficie di attacco e convertendo l'affaticamento da allerta in tranquillità. Il modo in cui una tecnologia realizza questo obiettivo è la questione architetturale chiave. Esistono due tipi di XDR oggi: Aperto e Nativo.
Aperto vs. Nativo XDR
- Open XDR viene fornito tramite un'architettura aperta in grado di sfruttare le capacità di telemetria e risposta degli strumenti di sicurezza esistenti sulla superficie di attacco
- Native XDR viene fornito da una suite di strumenti di sicurezza di un unico fornitore che fornisce telemetria e risposta su tutta la superficie di attacco
Indipendentemente dall'approccio architettonico di un XDR piattaforma, deve soddisfare i seguenti requisiti tecnici per essere considerata XDR:
- Distribuibilità - Architettura di microservizi cloud-native per scalabilità, disponibilità e flessibilità di implementazione
- Fusione dei dati - Dati normalizzati e arricchiti su tutta la superficie di attacco, inclusi rete, cloud, endpoint, applicazioni e identità
- Correlazione - Rilevamenti correlati ad alta fedeltà su più strumenti di sicurezza
- Risposta intelligente - Un clic o risposta automatica dalla stessa piattaforma
Un malinteso comune su Aperto vs. nativo XDR è che sono tipi di mutuamente esclusivi XDRNon lo sono. Un XDR piattaforma può essere completamente aperta e parzialmente nativa. Ad esempio, un XDR piattaforma può avere alcuni strumenti incorporati dal suo fornitore mentre si integra apertamente con gli strumenti esistenti degli altri fornitori. Ciò consente una strategia di sicurezza componibile, la capacità di sfruttare gli strumenti esistenti consentendo al cliente di ritirarne alcuni quando e dove lo ritengono opportuno.
La composizione di Open vs. Native XDR che una piattaforma adotta nel suo approccio è un mezzo per raggiungere un fine: in particolare, il modo in cui la piattaforma esegue il rilevamento e la risposta sull'intera superficie di attacco. Gli acquirenti di XDR devono considerare l'approccio architettonico come un mezzo per raggiungere un fine e prendere la decisione migliore per la loro azienda.
L'Ideale XDR è aperto
Ci saranno alcune aziende che non avranno problemi a trasferire il loro intero stack di sicurezza a un unico fornitore e ad adottare un sistema chiuso, Native XDR piattaforma. Ci saranno anche alcune aziende che si preoccupano meno di coprire l'intera superficie di attacco e desiderano solo il rilevamento e la risposta per i loro endpoint, ad esempio. In questo caso dovrebbero perseguire un Nativo basato su EDR XDR piattaforma.
Tuttavia, per la maggior parte delle aziende, un file Open XDR piattaforma deve essere considerata la massima priorità. Perché? Perché nessun singolo fornitore sarà mai in grado di creare o acquisire i migliori strumenti per cloud, endpoint, reti, identità, ecc., quindi un'infrastruttura nativa XDR piattaforma non sarà la migliore della categoria. Inoltre, è estremamente probabile che l'impresa abbia già ha investito capitali e sforzi significativi nell'implementazione degli strumenti di sicurezza esistenti: non vorrebbe abbandonare quegli investimenti, quindi un Native XDR la soluzione non interagirebbe con quegli strumenti e non catturerebbe l'intera superficie di attacco in quell'azienda. Se uno Open XDR piattaforma ha alcuni attributi nativi per coprire determinate aree della superficie di attacco per le aziende in crescita, ottimo. Ma prima deve essere aperto.
Alla fine, se un'impresa vuole definire ed eseguire una strategia di sicurezza componibile e ottenere tutti i XDRrequisiti tecnici forniti tramite una piattaforma, completamente Open XDR piattaforma è l'unico modo realistico per farlo.
