Punti chiave
- La versione v2026 del CSCF ha già ampliato il perimetro, includendo i connettori client dei clienti (come gli endpoint di API , il middleware e i client per il trasferimento di file) nell’ambito di applicazione di 14 controlli, a seconda del tipo di architettura
- La versione v2027 del CSCF porta avanti l'ampliamento dell'ambito di applicazione con 32 controlli, 26 dei quali obbligatori, in vista del periodo di attestazione compreso tra luglio e dicembre 2027
- Le classificazioni architetturali precedenti alla versione 2026 potrebbero richiedere una rivalutazione qualora siano presenti connettori client dei clienti o altri fattori che modificano l'ambito di applicazione; i valutatori esamineranno il secondo ciclo con ambito di applicazione ampliato
- Un principio pratico di sicurezza per il perimetro esteso consiste nell’ispezionare, sanificare e controllare i file e i flussi di dati prima che raggiungano l’infrastruttura critica di pagamento
- I punti di controllo lungo tali flussi possono fornire elementi utili ai fini della registrazione, del monitoraggio e della certificazione, sebbene la conformità rimanga di competenza dell’istituzione
Preparazione alla valutazione CSCF del 2027
La maggior parte delle istituzioni collegate a Swift è in grado di definire la propria “ Secure ” (zona di sicurezza) attingendo alla propria memoria: l’interfaccia di messaggistica, i server di transito, il segmento protetto in cui transita il traffico dei pagamenti. Si tratta di alcune delle aree meglio difese all’interno dell’organizzazione. Lo standard CSCF v2027 si interroga sul livello di protezione di tutto ciò che conduce a tale zona.
Il cambiamento più significativo è già avvenuto. La versione CSCF v2026, pubblicata nel luglio 2025, ha reso obbligatorio, con un’implementazione graduale, il controllo 2.4, “Sicurezza dei flussi di dati di back-office”, e ha incluso i connettori dei clienti nell’ambito di applicazione di 14 controlli.
Gli scambi di dati diretti con il back-office dei sistemi legacy mantengono per ora carattere consultivo, con il 2028 indicato in via provvisoria come data per una futura transizione obbligatoria. L’attuale quadro normativo prevede 32 controlli di sicurezza distribuiti su sette principi, 26 dei quali obbligatori, e l’ambito di applicazione ampliato viene mantenuto nel ciclo del 2027. La versione CSCF v2027, pubblicata nel luglio 2026, non aggiunge nuovi controlli obbligatori ma estende l’ambito di applicazione del modello SKV (Secrets and Keys Vault ) alla maggior parte di essi. I controlli di tipo consultivo rimangono pratiche raccomandate che potrebbero diventare obbligatorie nelle versioni successive. Le istituzioni effettueranno per la prima volta l’attestazione in base all’ambito di applicazione ampliato tra luglio e dicembre 2026, mentre il periodo di attestazione per la v2027 si estenderà da luglio a dicembre 2027, supportato da una valutazione indipendente.
Se la classificazione della vostra architettura risale ancora a prima della versione 2026, rivalutatela subito, soprattutto se dall’ultima valutazione sono stati introdotti connettori client, flussi di file esterni o nuovi percorsi di integrazione. I team che stanno mettendo insieme la loro prima attestazione ad ambito esteso ricorrendo all’improvvisazione si troveranno ad affrontare un 2027 in cui i valutatori si aspetteranno che il lavoro alla base di tale attestazione appaia ben pianificato. In ogni caso, la domanda è: la vostra architettura di sicurezza è pronta per ciò che ora si trova oltre la zona “ Secure ”?
Connettori per i clienti e ambito di applicazione ampliato
È raro che un ambiente di pagamento venga attaccato proprio attraverso il suo punto di maggiore sicurezza. I file e i dati raggiungono i sistemi collegati a Swift tramite portali clienti, caricamenti da parte dei partner, piattaforme di trasferimento file gestito, code di middleware, integrazioni di tipo “ API ” e supporti rimovibili introdotti nel data center. Ciascuno di questi canali può veicolare contenuti dannosi o non attendibili verso un’infrastruttura che, secondo le valutazioni delle architetture precedenti, era considerata al sicuro e fuori dall’ambito di rischio.
Il framework ora considera questi percorsi come parte integrante dell’architettura di sicurezza pertinente. I connettori client dei clienti rientrano nell’ambito di applicazione in base al nome: endpoint API , middleware e client di trasferimento file, indipendentemente dal fatto che siano in esecuzione su server o su endpoint client. Il controllo si estende al software stesso, dagli aggiornamenti di sicurezza e dalla scansione delle vulnerabilità all’integrità del software, sottoponendo il codice dei connettori interni allo stesso esame dei file che trasportano.
Se la classificazione della vostra architettura è antecedente alla versione v2026, i componenti che in passato avete considerato fuori dall’ambito di applicazione (un servizio di caricamento rivolto ai clienti, un bus di integrazione o un server di trasferimento file) potrebbero richiedere una nuova valutazione, in particolare qualora utilizzino o costituiscano un connettore client per i clienti.
La nostra infografica Swift illustra questi punti di accesso in un'unica pagina.
Per i responsabili della sicurezza, la posta in gioco si riduce a due scenari. Un file dannoso che raggiunge l’infrastruttura di pagamento minaccia la disponibilità stessa dell’attività di pagamento, mentre una lacuna nell’ambito di copertura individuata durante la valutazione diventa un riscontro documentato che viene portato all’attenzione del consiglio di amministrazione. Entrambi gli esiti comportano costi superiori rispetto alla rivalutazione necessaria per prevenirli.
La sicurezza dei file deve essere inclusa nella revisione dell'architettura
Quasi tutti i canali coperti dall’ambito di applicazione ampliato servono a trasferire file o dati strutturati: caricamenti da parte di clienti e partner, trasferimenti in batch tra istituzioni, allegati che attraversano il middleware e file che superano i confini dell’ API . Un singolo motore antivirus ai margini della rete è stato progettato per affrontare un problema più circoscritto rispetto a questo.
Ciò rende la sicurezza dei file una scelta architettonica. Un principio pratico consiste nell’ispezionare, sanificare e controllare i file e i flussi di dati prima che raggiungano l’infrastruttura critica di pagamento, assicurandosi al contempo che i controlli applicati siano adeguati a ciascun flusso e al relativo rischio.
Controllo dei file prima che raggiungano i sistemi di pagamento
Un partner carica un lotto di fatture tramite il vostro portale clienti. Il file viene trasferito su una piattaforma di trasferimento file gestito, viene prelevato da una coda di middleware, un servizio di integrazione ne riformatta il contenuto e l’output raggiunge un’applicazione collegata ai sistemi Swift. Quattro passaggi separano un file esterno dall’infrastruttura di pagamento critica e, in molte istituzioni, ogni passaggio si affida a quello precedente.
L'applicazione del principio "ispeziona, sanifica e controlla" comporta l'implementazione di un controllo specifico in ogni fase del percorso. MetaDefender™ Core e MetaDefender ICAP Server eseguono la scansione dei file caricati tramite applicazioni web rivolte ai clienti, tramite REST API o l'integrazione ICAP . MetaDefender Managed File Transfer ispeziona i contenuti che transitano tra i sistemi di back-office e quelli relativi a Swift, supportando il requisito Control 2.4, "Sicurezza del flusso di dati di back-office".
Entrambi i file vengono sottoposti a scansione tramite Metascan™ Multiscanning, con oltre 30 motori anti-malware che eseguono la scansione in parallelo. Questa scansione multi-motore supporta Control 6.1 e Malware Protection, rilevando i contenuti dannosi noti con una precisione superiore rispetto a quella di qualsiasi singolo motore. La tecnologia Deep CDR™ provvede quindi a sanificare e rigenerare ogni file supportato, rimuovendo i contenuti attivi incorporati prima che il file prosegua il suo percorso. I file sospetti vengono inviati a Adaptive Sandbox , dove l’analisi basata sull’emulazione aiuta a individuare minacce evasive e zero-day, in conformità con la linea guida Control 6.5A, Rilevamento delle intrusioni.
Lo stesso trattamento si estende agli archivi in cui vengono salvati i backup e gli estratti, con Proactive DLP™ che verifica la presenza di contenuti sensibili nei file inattivi. Il sistema copre anche i supporti rimovibili e i dispositivi temporanei, che MetaDefender Kiosk e MetaDefender Drive analizzano e ripuliscono in un punto di controllo prima dell’accesso, a supporto del requisito Control 3.1, Sicurezza fisica.
Per quanto riguarda il software per connettori sviluppato internamente, MetaDefender Software Supply Chain esegue la scansione dei pacchetti e delle dipendenze alla ricerca di vulnerabilità e componenti dannosi prima della distribuzione, supportando i Controlli 2.2 (Aggiornamenti di sicurezza), 2.7 (Scansione delle vulnerabilità) e 6.2 (Integrità dell’ Software ).
Il risultato è un unico livello di prevenzione applicato in modo coerente a tutti i canali di file che lo attraversano, posizionato a monte dei sistemi che è destinato a proteggere.
Documenti di ispezione a sostegno della tua valutazione
Quando a luglio si aprirà la finestra del 2027, i valutatori esamineranno il secondo ciclo di attestazione nell’ambito dell’ambito di applicazione ampliato, e le prove dell’esistenza e dell’efficace funzionamento dei controlli avranno un peso maggiore rispetto alle intenzioni dichiarate.
I punti di controllo lungo i flussi di file e dati possono generare prove utili: eventi di controllo, tracciati di audit inoltrati al sistema SIEM e registrazioni relative all’applicazione delle politiche che documentano le modalità di verifica dei contenuti durante il loro percorso verso i sistemi di pagamento. Tali prove a sostegno del Controllo 6.4, “Registrazione e monitoraggio”, e della stessa attestazione CSCF.
La conformità rimane una responsabilità dell'istituzione stessa e i valutatori giudicano l'architettura nel suo complesso. Il risultato di questo lavoro è una risposta sostenibile alla domanda fondamentale del valutatore: cosa può accedere alla vostra infrastruttura di pagamento e cosa le accade lungo il percorso?
Tre domande per il tuo team di architetti
Tre domande possono costituire un utile primo punto di partenza in vista del periodo del 2027:
- Quali flussi di file e dati esterni possono arrivare, in ultima analisi, alla vostra infrastruttura di pagamento?
- In che modo vengono controllati i file prima di entrare nei flussi di lavoro relativi a Swift?
- L'ampliamento dell'ambito di applicazione del CSCF comporta modifiche alla vostra attuale classificazione dell'architettura o ai vostri controlli?
La nostra scheda tecnica SWIFT CSCF v2027 riassume in poche pagine l'ambito di applicazione ampliato, l'infrastruttura interessata e i relativi controlli preventivi, che potrete condividere con i team di architettura e GRC.
Scarica la scheda tecnica di SWIFT CSCF v2027
Se preferisci esplorare il tuo ambiente, parla con un esperto di OPSWAT e porta con te la classificazione attuale della tua architettura.
