Eseguire un PoV di sicurezza che abbia senso

Quando valuta gli strumenti di sicurezza della posta elettronica, non dovrebbe scegliere tra un test corretto e la sicurezza dei suoi utenti. Eppure, in qualche modo, questa è diventata la richiesta.

Ecco uno schema che abbiamo visto. Le organizzazioni eseguono un PoV confrontando gli strumenti solo API con le soluzioni SEG. Poi qualcuno suggerisce di disattivare le protezioni principali sul SEG (riscrittura degli URL, controlli degli allegati, politiche avanzate sulle minacce) per "livellare il campo di gioco."

Questo non significa livellare nulla, ma solo eliminare completamente il campo.

Parliamo di come valutare onestamente queste architetture senza creare rischi e del perché le stranezze della progettazione solo API rendono necessaria questa conversazione.

Due architetture, diversi lavori da fare

Le differenze fondamentali dell'architettura non sono solo tecniche: determinano ciò che ogni soluzione può o non può proteggere.

I SEG si trovano in linea. Ispezionano ogni messaggio prima della consegna, analizzano i link e gli allegati in tempo reale e applicano i controlli sul perimetro. (Se qualcosa è pericoloso, non arriva mai alla casella di posta elettronica). Ispezionano ogni URL o allegato nel momento in cui viene cliccato dall'utente, offrendo un ulteriore livello di sicurezza contro le minacce dinamiche.

Gli strumenti solo API si collegano dopo la consegna. Osservano ciò che arriva in Microsoft 365 o Google Workspace, analizzano i modelli di comportamento e tentano di porre rimedio, a volte pochi minuti o ore dopo, attraverso le chiamate API.

Uno previene. Uno risponde. Entrambi possono essere preziosi. Ma non sono intercambiabili e per valutarle fianco a fianco occorre capire cosa può fare effettivamente ciascuna architettura.

Perché qualcuno potrebbe chiederle di indebolire il suo SEG

Quando uno strumento API viene eseguito dietro un SEG completamente configurato, accade qualcosa di prevedibile: la maggior parte delle minacce non arriva mai alla fase di analisi.

Il malware delle materie prime viene bloccato. Le campagne di phishing conosciute si fermano al cancello. I tentativi evidenti di impersonificazione non passano. Ciò che rimane da analizzare per lo strumento API è un set di dati significativamente più piccolo e pulito.

Questo è il risultato ideale per la sicurezza: i livelli lavorano insieme, con le cose più pericolose bloccate in anticipo. Ma questo rende più difficile per un fornitore di sole API dimostrare il proprio valore durante una breve valutazione.

Quindi, il workaround diventa: disabilitare i controlli più efficaci del SEG, lasciarne passare di più e creare un maggior numero di rilevamenti "" da segnalare.

Il problema? Ha appena reso il suo ambiente dimostrabilmente meno sicuro per la durata del test.

Cosa perde in realtà quando riduce le cose

Non si tratta di un rischio ipotetico. L'indebolimento del SEG elimina la protezione in tre fasi in cui gli attacchi hanno successo o falliscono:

Pre-consegna: Fermare le minacce al cancello

Con un SEG completamente attivato, le e-mail pericolose non raggiungono mai le caselle di posta. L'ispezione profonda individua URL e allegati dannosi. Le tecniche di impersonificazione vengono identificate. Le minacce vengono bloccate prima della consegna. Se allenta i controlli, inonda Microsoft 365 di contenuti che non dovrebbero essere presenti. Lo strumento API può rispondere solo dopo la consegna, dopo che il messaggio è già visibile, leggibile e attivabile. Anche un ritardo di 30 secondi equivale a 30 secondi di esposizione non necessaria.

Click-time: Proteggere gli utenti quando si impegnano

La riscrittura degli URL è uno dei suoi controlli più preziosi. Quando gli utenti cliccano sui link, un SEG configurato correttamente:

• Percorsi di clic attraverso l'ispezione in tempo reale
• Segue i reindirizzamenti alle destinazioni finali
• Analizza le pagine a livello di coinvolgimento
• Blocca l'accesso ai siti che sono diventati dannosi dopo l'arrivo dell'e-mail.

Se lo disattiva durante un PoV, gli utenti cliccheranno direttamente verso qualsiasi destinazione scelta dall'aggressore. Gli strumenti solo API non possono intercettare i clic. Possono solo cercare di recuperare l'e-mail dopo il fatto, supponendo che la connessione API funzioni, che l'elaborazione di Microsoft non sia in ritardo e che l'utente non abbia già rinunciato alle credenziali. Questo è al contrario.

Interno e in uscita: Dove gli strumenti solo API diventano oscuri

Gli strumenti API in genere analizzano le e-mail in entrata da mittenti esterni. Ciò che non controllano è ciò che accade all'interno della sua organizzazione, dove operano gli account compromessi e il phishing laterale. Un SEG che protegge le comunicazioni interne e in uscita cattura:

• Il phishing laterale da account compromessi che prende di mira i colleghi
• Esfiltrazione di dati verso indirizzi esterni
• Attività maligne di insider che utilizzano account legittimi
• Violazioni della politica su ciò che lascia il suo ambiente

Questi attacchi utilizzano account autorizzati e domini fidati e non toccano mai il flusso di posta esterno. Gli strumenti solo API che osservano i messaggi in entrata li mancheranno del tutto.

Come gestire un PoV equo senza rompere le cose

Non è necessario compromettere la sicurezza per valutare i fornitori in modo significativo. Servono criteri di successo migliori.

Mantenga il suo SEG completamente abilitato

Qualsiasi fornitore che richieda di indebolire le difese esistenti non sta dimostrando valore, ma lo sta producendo. La riscrittura degli URL, il sandboxing degli allegati e le politiche sulle minacce devono rimanere attive durante qualsiasi valutazione.

Misurare l'esposizione, non solo i conteggi di rilevamento

Chieda a tutti i venditori:

• Per quanto tempo la minaccia è stata visibile agli utenti?
• Cosa succede se la connettività API si deteriora?
• Può prevenire i clic o pulire solo dopo?

Un rilevamento che avviene dopo che l'utente legge, clicca e inserisce le credenziali non è una prevenzione. È la risposta agli incidenti.

Valutare i risultati completi della sicurezza

Confrontate ciò che ogni fornitore ferma effettivamente:

• Soluzioni SEG: Bloccare le minacce prima della consegna, proteggere i clic in tempo reale, rimediare dopo la consegna, controllare le email in uscita e quelle interne.
• Strumenti solo API: Analizzare i messaggi in entrata post-consegna quando le API lo consentono.

Uno è la protezione completa della piattaforma. L'altro è uno strato supplementare.

Come si presenta una buona valutazione

L'obiettivo non è quello di mettere in cattiva luce un fornitore o di creare uno scenario artificiale in cui tutto ha successo. Si tratta di capire quale sia il contributo di ciascuna soluzione alla sua postura di sicurezza e dove esistano delle lacune.

Se sta valutando uno strumento solo API, lo testi in una configurazione realistica. Lo esegua dietro il suo SEG esistente con tutto abilitato. Misuri come gestisce le minacce sofisticate che riescono a superare la sua prima linea di difesa. Comprenda ciò che non può affrontare, come la protezione click-time, le minacce interne e i controlli in uscita. Poi, decide se l'analisi supplementare giustifica l'investimento e il dispendio operativo della gestione di un'altra relazione con il fornitore.

Oppure mantenga la protezione a livello di piattaforma in funzione in modo completo e lasci che faccia ciò che sa fare meglio: bloccare le minacce prima, durante e dopo la consegna in tutto il suo ambiente e-mail.

Esegua i suoi PoV in modo più intelligente

Le soluzioni puntuali risolvono i problemi puntuali. Le piattaforme risolvono l'intero problema.

Se una valutazione richiede di indebolire le protezioni che avete in atto oggi, è un segnale a cui vale la pena prestare attenzione. Gli strumenti di sicurezza dovrebbero dimostrare il loro valore in base ai propri meriti, e non per svantaggio nei confronti della concorrenza.

Esegua i suoi PoV in modo più intelligente. Mantenga i suoi utenti al sicuro. E se qualcuno suggerisce di disattivare la riscrittura degli URL per rendere le cose "eque," forse è un buon momento per chiedere cosa succede normalmente quando vengono fatte richieste insolite.