®Offensive Security / Pentesting per software e SaaS
Release rapide richiedono un controllo di sicurezza che comprenda la vostra applicazione. OTOKO® analizza prodotti SaaS, API, applicazioni eseguite su PaaS e software legacy sviluppato nel tempo. Al centro ci sono gli impatti concretamente ottenibili: dati di altri tenant, azioni non consentite, logica di business utilizzata in modo improprio e i confini tra i ruoli utente. Risultati riproducibili offrono al vostro team di sviluppo una base per la correzione.
Servizi in dettaglio
Analisi, integrazione e passaggio di consegne documentato
Cosa affidate a OTOKO®
I pacchetti di lavoro derivano dalla vostra situazione di partenza. Il vostro team conosce l'ambito concordato, la collaborazione necessaria e i risultati che devono essere disponibili al momento del passaggio di consegne.
Definiamo insieme i processi di business più importanti e i ruoli di test. Successivamente verifichiamo se una funzione può essere utilizzata oltre i limiti previsti. I controlli automatizzati vengono integrati da un'analisi manuale dell'applicazione.
Risultati valutati con impatto sul business ed evidenza verificabile.
Assegnazione ai tenant, accessi agli oggetti e funzioni privilegiate vengono verificati nell'ambito autorizzato. Un insieme di dati di test dedicato rende valutabili gli impatti, senza dover utilizzare dati di altri clienti per fornire un'evidenza.
Verifica documentata dei confini concordati tra ruoli e tenant.
Nelle applicazioni PaaS consideriamo le impostazioni e le interfacce di vostra responsabilità. Nei sistemi legacy, i limiti operativi noti e le dipendenze vengono inclusi nella pianificazione del test. Le piattaforme di terzi restano escluse se non è stata concessa un'autorizzazione.
Ambito di test delimitato con procedure adeguate dal punto di vista tecnico e operativo.
I risultati vengono classificati per priorità e discussi con il vostro team di sviluppo. Il retest concordato verifica se la causa concreta è stata eliminata nella nuova versione. I risultati sono riferiti all'ambito e al momento effettivamente testati.
Report tecnico, inquadramento per il management e risultati del retest documentati.
Pianificazione e realizzazione
Un prodotto SaaS non è costituito solo da endpoint pubblicamente accessibili. Ruoli diversi, inviti, esportazioni, attività in background e funzioni di amministrazione compongono insieme la logica di business. Prima del test chiariamo quindi quali processi necessitano di una protezione particolare e quali limiti l'applicazione deve far rispettare. Questa visione integra i controlli tecnici classici. Una funzione può rispondere in modo formalmente corretto e comunque consentire un'azione non prevista per la persona autenticata o per il suo tenant.
Su questa base si definisce un ambito di test concordato. Le componenti black box, grey box o white box vengono scelte in base all'obiettivo e alle informazioni disponibili. Se vengono forniti il codice sorgente o la documentazione dell'architettura, le osservazioni possono essere inquadrate in modo più mirato. Il test si concentra sull'applicazione autorizzata e utilizza gli account e i dati concordati. Un risultato prodotto da uno strumento non viene considerato una vulnerabilità confermata senza una valutazione; l'impatto e i presupposti devono essere comprensibili per il vostro team.
Per SaaS e PaaS, il confine di responsabilità è determinante. La verifica della vostra applicazione o configurazione non costituisce automaticamente un'autorizzazione ad attaccare l'infrastruttura di un gestore della piattaforma. Vengono definiti insieme obiettivi, procedure consentite e autorizzazioni necessarie. API e integrazioni vengono verificate in base all'ambito di dati e autorizzazioni previsto. Particolare attenzione viene posta al fatto che ruoli e tenant diversi restino effettivamente separati nei percorsi applicativi reali.
Il software legacy richiede spesso un approccio diverso. La documentazione può essere incompleta, gli ambienti di test riproducono solo parzialmente l'ambiente di produzione e alcuni componenti reagiscono in modo sensibile al carico. Queste condizioni devono essere considerate nella pianificazione prima dell'inizio. Concordiamo finestre di test, referenti raggiungibili e criteri di interruzione. Dove un controllo non può essere eseguito in modo responsabile, questo limite viene reso visibile nel risultato. In questo modo resta chiaro quali conclusioni consente il test e dove sarebbe necessaria un'indagine supplementare.
Un report deve consentire una decisione e aiutare lo sviluppo nella correzione. Un risultato confermato descrive quindi la versione interessata, i presupposti necessari, l'evidenza concordata e il possibile impatto. Management e team tecnici richiedono un livello di dettaglio diverso. La definizione delle priorità considera il contesto applicativo, invece di produrre solo un lungo elenco di segnalazioni di pari peso. Le evidenze vengono limitate alla misura necessaria e condivise con i referenti autorizzati tramite canali concordati.
La correzione viene discussa con il vostro team; un retest concordato valuta la modifica concreta. La correzione di un singolo risultato non significa tuttavia automaticamente che l'intera applicazione sia priva di vulnerabilità. Nuove release e modifiche alla configurazione possono cambiare la situazione di partenza. Su richiesta, se ne può ricavare un controllo periodico delle modifiche rilevanti. Per obiettivi adeguati e chiaramente delimitati può inoltre essere concordato il Result as a Service: il compenso dipende in tal caso dal risultato definito in anticipo e dimostrato.
Scenario di progetto illustrativo
Due tenant di test separati rappresentano utenti regolari e amministrazione. Prima della release vengono analizzati i processi di business concordati e i limiti di autorizzazione. Il team riceve evidenze classificate per priorità e verifica le correzioni nel retest, senza che siano necessari dati di altri clienti per la dimostrazione.
Prima di iniziare
Sì. Le applicazioni legacy vengono pianificate considerando i loro limiti operativi, gli ambienti di test disponibili e le dipendenze. I controlli non realizzabili vengono indicati nel report come limitazione.
Gli scanner supportano il lavoro. La logica di business, i ruoli e il contesto applicativo effettivo richiedono tuttavia una valutazione nel merito e un controllo manuale mirato.
Per progetti idonei può essere concordata un'evidenza di risultato definita per scritto, con un importo fisso. Senza questa evidenza, il compenso concordato per il pentest, legato al risultato, non è dovuto. I dettagli sono disponibili nella pagina Result as a Service.
No. L'affermazione si riferisce all'ambito concordato, alla versione verificata e all'intervallo di tempo considerato. L'assenza di riscontri non costituisce una garanzia generale di sicurezza.
Servizi correlati
Pentesting per software e SaaS con OTOKO®
Indicateci i sistemi interessati e l'obiettivo della vostra richiesta. Nel primo colloquio definiamo insieme ambito, presupposti e i prossimi passi.
Parliamo di Pentesting per software e SaaS.
