Quanto lontano potrebbe arrivare un attaccante?

L'approccio adeguato viene definito in base al fabbisogno di protezione e al rischio operativo. Finestre temporali, procedure consentite, referenti e criteri di interruzione vengono concordati per iscritto in anticipo.

No. I diritti sui sistemi di terzi e i requisiti del gestore della piattaforma devono essere chiariti separatamente. Viene verificato solo l'ambito espressamente autorizzato.

No. Queste procedure richiedono un accordo esplicito e una preparazione adeguata. Non possono essere dedotte dal solo termine pentesting.

Un report con ambito del test, risultati confermati, evidenze, impatti, limitazioni e misure classificate per priorità. Un retest concordato valuta le correzioni concrete.

OTOKO® verifica in modo autorizzato reti, configurazione cloud e IaaS: percorsi di accesso, identità, segmentazione, risultati classificati per priorità e retest.

Vengono definiti indirizzi, sistemi, account e punti di partenza consentiti. Le dipendenze in produzione e i componenti esclusi fanno parte dell'autorizzazione. Il test inizia solo quando c'è una comprensione condivisa dell'ambito consentito.

Il controllo analizza quali azioni siano effettivamente possibili dal punto di partenza concordato. Identità e confini di rete vengono valutati nel loro insieme. Le evidenze si limitano all'ambito autorizzato e alla misura necessaria per la valutazione.

Account cloud, sistemi virtuali e accessi di responsabilità del cliente vengono verificati rispetto all'obiettivo concordato. I requisiti del gestore della piattaforma e i diritti sui sistemi di terzi coinvolti devono essere chiariti in anticipo.

I risultati tecnici vengono trasformati in miglioramenti comprensibili. Responsabilità e dipendenze vengono considerate nella definizione delle priorità. Un retest analizza le modifiche concordate sulla versione aggiornata.

Un test condotto da internet risponde a domande diverse rispetto a una verifica effettuata con un normale account interno. Definiamo insieme quale scenario considerare e quali autorizzazioni siano presenti all'inizio. Da questa situazione di partenza viene derivato l'ambito consentito. Sistemi, indirizzi e identità vengono documentati; i servizi condivisi e i sistemi di terzi richiedono particolare attenzione. In questo modo la pianificazione impedisce che l'indagine superi involontariamente un'autorizzazione concessa a causa di responsabilità poco chiare. Anche le condizioni operative fanno parte della preparazione. Vengono definiti referenti, finestre temporali e criteri di interruzione. Modifiche ai sistemi, test di carico o misure più estese non fanno tacitamente parte di ogni pentest. Devono essere espressamente compatibili con la procedura concordata. I risultati indicano poi la posizione di partenza effettiva e la versione verificata. Questo facilita l'interpretazione: una vulnerabilità osservata con diritti amministrativi già presenti ha un valore diverso rispetto a un'evidenza rilevata da un punto di partenza senza privilegi.

La segmentazione di rete da sola non descrive tutte le possibilità di accesso. Account utente, account di servizio e percorsi di amministrazione possono creare altre connessioni tra i sistemi. Il controllo valuta quindi, nell'ambito autorizzato, se i limiti tecnici e i ruoli impongano effettivamente il modello previsto. I singoli errori di configurazione vengono valutati in relazione al loro impatto. Un risultato deve mostrare perché è rilevante per il vostro ambiente e quali presupposti esistono per l'accesso dimostrato. Negli ambienti IaaS si aggiunge la delimitazione rispetto al provider. Le risorse e la configurazione di responsabilità del cliente possono essere oggetto dell'indagine; i servizi di piattaforma condivisi non vengono per questo automaticamente autorizzati. Prima del controllo vengono chiariti i diritti necessari e i requisiti. Possono essere interessate anche sedi e applicazioni collegate. La pianificazione collega quindi i responsabili cloud e infrastruttura, in modo che il test resti tracciabile e i suoi effetti possano essere controllati entro l'ambito concordato.

Il risultato distingue tra riscontri confermati, indicazioni e aree non verificate. Le evidenze descrivono i presupposti necessari e l'impatto osservato. Devono consentire la valutazione senza raccogliere dati sensibili non necessari. Management e team tecnici ricevono una presentazione adeguata; le osservazioni particolarmente rilevanti vengono comunicate tramite i canali di notifica concordati. In questo modo un pentest diventa più di un semplice export di segnalazioni tecniche: i responsabili possono decidere quali misure attuare per prime. Nella correzione possono essere coinvolti più team, ad esempio la gestione delle identità, la gestione della rete e l'assistenza applicativa. Le raccomandazioni vengono quindi discusse insieme alle loro dipendenze. Il retest si concentra sulla versione modificata concordata e documenta se la specifica evidenza è ancora ottenibile. Un compenso basato sul risultato può essere regolato, per un obiettivo adeguato e chiaramente definito, tramite Result as a Service. L'ambito di test consentito resta in ogni caso vincolante e non viene ampliato da un incentivo economico.

Un'azienda collega sistemi interni a un ambiente IaaS. Nell'ambito autorizzato vengono verificati i percorsi di accesso necessari e indesiderati a partire da ruoli definiti. I risultati vengono classificati per priorità insieme ai responsabili di rete e cloud e verificati nuovamente in modo mirato dopo le modifiche.

Stato attuale, rischi, priorità IT, sicurezza delle informazioni, protezione dei dati, architetto della sicurezza OTOKO® Analisi dello stato attuale, valutazione dei rischi, piano d'azione con priorità

Architettura target, piano crittografico, modello operativo Architettura, team operativo IT, aree di business, direzione Architettura target, piano crittografico, piano di rilevamento e risposta, piano delle evidenze