Che cosa rientra nell’ambito?
Due preventivi sono confrontabili solo se coprono lo stesso lavoro. Per un penetration test fintech, elencate i flussi di pagamento, le API multi-tenant e le identità cloud, definendo anche i ruoli, gli ambienti e le operazioni aziendali da testare. Specificate quali evidenze vi aspettate, quali azioni sono vietate e se la richiesta include un nuovo test.
Associare i servizi alle dipendenze
Un’API per esercenti può autenticare correttamente chi effettua la chiamata senza vincolare un oggetto a quell’esercente. Un webhook può essere autentico e tuttavia venire riprodotto in uno stato di transazione errato. I test devono considerare le decisioni aziendali previste dal prodotto, non limitarsi a un elenco di URL degli endpoint.
Elencare prima i servizi aziendali o assistenziali, quindi mappare le applicazioni, i sistemi di identità, le reti e i fornitori che li supportano. Registrare quale responsabile può autorizzare ciascun componente. Il solo numero di domini non descrive i limiti di autorizzazione né le conseguenze operative.
Preparate ruoli e dati rappresentativi
Fornire identità dedicate con ruoli documentati e autorizzazioni attese note. Utilizzare più di un tenant, cliente o unità organizzativa quando i confini rientrano nell’obiettivo. Contrassegnare gli oggetti canary affinché chi esegue i test e i responsabili possano distinguerli dai record reali.
Selezioni le aree di valutazione
- Test delle API fintech e dei confini tra tenant: L’autenticazione può riuscire mentre l’autorizzazione fallisce. I ruoli di esercenti, clienti, partner e amministratori richiedono un’associazione esplicita al tenant nelle richieste ordinarie, nelle esportazioni e nei processi asincroni.
- Test della logica di pagamento e dello stato delle transazioni: La ripetizione delle richieste, le richieste duplicate, le approvazioni obsolete e un’errata separazione dei ruoli possono compromettere l’integrità delle transazioni anche quando l’API non presenta comuni vulnerabilità di injection.
- Test delle identità cloud e dei workload fintech: Anche un’applicazione con ambito ristretto può dipendere da un’identità di deployment con privilegi estesi. Archivi di build, token dei workload e ruoli di supporto dei fornitori richiedono evidenze delle autorizzazioni effettive e della loro durata.
Concordare le condizioni di test
Utilizzi tenant dedicati, dati sintetici dei clienti e circuiti di pagamento di test con il regolamento effettivo disabilitato. Concordi le autorizzazioni per i sistemi dei partner, i limiti delle transazioni, il rollback e le finestre di rilascio. Le attività in produzione devono avere responsabili espliciti e un canale chiaro per interromperle.
- Origini dei test, destinazioni e interfacce consentite designate.
- Finestre temporali, limiti di frequenza e metodi esclusi approvati.
- Consenso delle terze parti, referenti per il controllo e autorità di arresto.
- Responsabilità per la gestione delle evidenze, la pulizia, la rendicontazione e le verifiche di retest.
Rendere visibili le modifiche
Registrare i rilasci, i nuovi percorsi e le modifiche alle autorizzazioni durante il test. Se un percorso imprevisto raggiunge un sistema al di fuori dell’ambito autorizzato, sospendere il test e chiarire l’ambito con il responsabile decisionale designato. Indicare le dipendenze non testate nella dichiarazione finale di copertura.
Preparare un brief prima della chiamata di definizione dell’ambito
Iniziate dal flusso operativo del prodotto, dai confini tra tenant e dalle identità che la valutazione deve verificare. Documentate come osservare una transazione di test senza movimentare fondi reali dei clienti.
Utilizzi il generatore gratuito di documenti di definizione dell’ambito per test di penetrazione fintech per indicare obiettivi, aree di valutazione, vincoli e preferenze relative all’NDA. Riveda l’ambito proposto, quindi lo invii direttamente ad Atlant Security tramite il modulo di contatto.
