Penetration test fintech: requisiti DORA, TLPT o PCI DSS?

La decisione che questa guida vi aiuta a prendere

Definite la persona giuridica, l’attività regolamentata e l’ambiente dei dati delle carte di pagamento prima di scegliere le etichette di valutazione. L’applicabilità del DORA e la selezione per il TLPT sono questioni distinte. Mantenete espliciti gli obiettivi di sicurezza del prodotto anche quando il test di penetrazione è stato avviato da un requisito di conformità.

Individuare l’attività regolamentata

La definizione fintech può riferirsi a un istituto di pagamento regolamentato, a un fornitore di software oppure a più entità diverse appartenenti allo stesso gruppo. Determini quale entità fornisce il servizio e quali obblighi le si applicano. L’applicabilità di DORA e la selezione per un TLPT sono questioni correlate, ma distinte.

Mappare separatamente l'ambito delle carte di pagamento

PCI DSS riguarda i dati delle carte di pagamento e i sistemi compresi nel relativo ambito definito. Un’applicazione finanziaria non coincide automaticamente con un ambiente di dati dei titolari di carta. Collabori con il team di compliance o con il valutatore responsabile per individuare i confini pertinenti e le evidenze attese prima di definire il test.

Mantenere visibili i rischi del prodotto

L’isolamento dei tenant, i poteri dei token di servizio e la gestione dello stato delle transazioni possono essere rilevanti anche quando non si applica uno specifico quadro normativo. Descriva esplicitamente questi obiettivi aziendali. Un test concepito esclusivamente attorno al nome di un quadro normativo può tralasciare il comportamento del prodotto più importante per i clienti.

Evitate di sovrastimare il risultato

Una valutazione tecnica documenta i rilievi osservati e i relativi limiti. Non certifica una conformità universale a DORA, PCI o GDPR. Allinei il rapporto alle evidenze richieste, riservi le conclusioni normative al processo appropriato e pianifichi test di verifica per i controlli modificati dal team di ingegneria.

Distinguere l'entità dall'architettura del prodotto

Un prodotto fintech può coinvolgere più entità giuridiche, attività regolamentate e fornitori di servizi. Individui quale entità gestisce il servizio pertinente e chi è responsabile degli obblighi applicabili. Mappi quindi i sistemi che supportano l’attività. Non deduca una classificazione giuridica dall’uso di API di pagamento, da una partnership bancaria o da una categoria di marketing. Il team tecnico può fornire evidenze sull’architettura e sui flussi di dati, mentre le funzioni legali e compliance responsabili determinano l’applicabilità.

Una nota di definizione dell’ambito dovrebbe riportare il responsabile della decisione e le questioni ancora aperte. In questo modo si evita che una proposta del fornitore diventi implicitamente l’interpretazione giuridica dell’organizzazione solo perché contiene gli acronimi normativi appropriati.

Commisurare le dichiarazioni di assurance alla copertura

Per una valutazione tecnica con ambito definito, indicate le applicazioni, le identità, gli ambienti e i metodi effettivamente inclusi. Specificate se i sistemi con dati dei titolari di carta, i servizi di supporto o i confini con terze parti rientrano nel lavoro concordato. Una valutazione API completata con esito positivo non dimostra, da sola, la conformità al PCI DSS. Analogamente, un rapporto che menziona DORA non prova che sia stato svolto un esercizio avanzato di red teaming basato sulle minacce, ove richiesto. Collegate ogni risultato richiesto al suo utilizzo previsto, invece di rilasciare un’unica dichiarazione generale di assurance.

La guida sul confronto tra test di penetrazione bancaria e TLPT DORA spiega la differenza tra i test tecnici di routine e un’esercitazione avanzata governata da un’autorità. Per il modello di erogazione del TLPT, consulti la guida su TIBER-EU e DORA.

Definire un ambito coerente con una finalità esplicita

I team possono spesso riutilizzare la preparazione di architetture, responsabilità ed evidenze tra diversi ambiti di assurance. Il riutilizzo non deve cancellare le differenze di obiettivi, metodi o criteri di accettazione. Create una matrice che colleghi ogni decisione aziendale o requisito alla relativa attività di test, alle evidenze e al responsabile. Indicate dove resta necessaria un’altra valutazione o una revisione specialistica. In questo modo gli acquisti sono più efficienti senza affermare che un unico test abbia soddisfatto ogni obbligo.

Alla chiusura, conservate la versione sottoposta a test, i limiti dell’ambito e le decisioni ancora da prendere. Se il prodotto trasferisce a un altro fornitore il trattamento di dati sensibili o aggiunge una nuova identità di servizio, riesaminate il confine pertinente invece di presumere che un rapporto precedente copra automaticamente la modifica. Il risultato utile è una dichiarazione chiara e sostenibile su ciò che è stato testato e su ciò che l’organizzazione deve ancora accertare.

Applicate le indicazioni

Utilizzate la lista di preparazione per documentare le ipotesi oppure consultate il rapporto fittizio di Fintech AG per esempi di evidenze e piani di trattamento. Contattate Atlant Security con una descrizione non sensibile dell’ambito.