Rispondo al messaggio che coglie in pieno il problema (anche dopo aver letto e condiviso il commento del 26 febbraio). Da un’analisi tempo addietro è emerso che i punti realisticamente attaccabili sono due:
Il primo è la copia cortesia inviata via email o posta cartacea ordinaria, che troppi continuano ancora ad accettare come fosse una fattura. Questa è figlia dell’analfabetismo digitale e delle abitudini dure a morire. Sì, c’è gente che ancora pretende la copia cartacea
Il secondo è che SdI accetta tutto quello che l’intermediario gli manda, come Romolo conferma nel suo intervento dopo
Sul secondo punto mi spendo un po’. Per mia esperienza lo stato di sicurezza del software in Italia è in generale discutibile. In teoria se sei intermediario SdI e hai un parco clienti dovresti minino minimo
Lavorare su connessioni protette sempre, non solo quando fai SFTP/web service verso AdE
Pretendere autenticazione forte quando ricevi una fattura dal cliente
Controllare che i dati della fattura del ciclo attivo corrispondano con quelli del tuo cliente e/o delle aziende da lui controllate e che comunque hanno sottoscritto contratto con te
Non plus ultra, tu indermediario potresti aggiungere ulteriori verifiche come IBAN censiti, ma nessuno te lo chiede, su questo siamo d’accordo.
Ora cosa succede… abbiamo ipotizzato che se un intermediario SdI non effettuasse controlli a sufficienza sarebbe teoricamente possibile per la Hacker Team Srl (CF 012344444444) inviare una fattura ad Acme srl (CF 98765555555) attraverso il proprio intermediario SdI, ma utilizzando tutti i dati (e l’allegato pro forma) di un reale fornitore, Inconscius Snc (CF 03654778474).
La colpa sarebbe dell’intermediario a mio avviso, perchè se hai un contratto con Hacker Team devi permettere solo a loro di introdurre il ciclo attivo nel sistema di fatturazione. Devi cioè tu intermediario essere sentinella di confine del sistema SdI.
A questo problema ci sono poche soluzioni, perchè ciascun intermediario si fa il software in casa e può non essere esente da vulnerabilità anche più sofisticate e del tutto non intenzionali. Non si può a mio avviso reggere la sicurezza di un sistema distribuito su un anello debole la cui resistenza non è materialmente stimabile.
Soluzioni?
AdE / SdI potrebbe, a seguito della registrazione del codice univoco intermediario nell’area F&C, impedire la consegna di fatture attive emesse da altro intermediario e/o produrre avvisi (“Caro intermediario, mi stai mandando una fattura di un tizio che non si è registrato. E’ tuo cliente? E’ tutto a posto?”)
Il payload della fattura potrebbe contenere dati aggiuntivi per la tracciabilità analoghi ai campi di routing delle email che indicano i vari server da cui la mail è passata. Non risolve il problema ma sapere da quale nodo SdI proviene una fattura hackerata aiuta. A differenza delle email in cui i singoli server sono colabrodo almeno i nodi SdI sono autenticati e controllati!
Se hai come cliente un commercialista, questo punto è ben difficile visto che il commercialista normalmente emette fatture per infiniti clienti di cui tu, intermediario, ignori l’esistenza.
Noi abbiamo un autentificazione forte, ma implementare il punto precedente sarebbe quanto meno scomodo/impraticabile; anche far censire al cliente tutti i codici fiscali/partite iva per i quali è delegato sposterebbe solo il problema alla sicurezza del cliente finale (che tipicamente non è proprio forte).
Comunque sia, nessuno ha ancora chiarito dove avverebbe questa alterazione dell’IBAN…
che io sappia il problema non è che Azienda A manda fatture all’Azienda B come se fosse l’Azienda C
Ma che Azienda A manda le fatture ad Azienda B e “FONTE ESTERNA” intercetta e modifica l’iban in fattura in modo da farsi accreditare i soldi.
questa cosa succede/succedeva perché l’utente medio usa hotspot gratuiti, o wifi libere o pc non sicuri e digita le credenziali della propria mail. A quel punto la “FONTE ESTERNA” recupera le credenziali e le usa per intercettare la fattura in pdf o XML che è arrivata tramite mail, modificandola.
questa cosa può ancora succedere principalmente perché c’è ancora molta ignoranza.
ieri un cliente mi ha riferito: “la ragazza che lavora dal commercialista mi ha detto che è sufficiente che il ristorante mi inoltri l’XML della fattura” e credeva che l’XML andasse inoltrato via mail dal ristorante e non tramite SDI
un’altro cliente mi ha chiesto: “Come faccio ad estrarre l’XML delle fatture che ho emesso? la banca lo vuole per preparare i bonifici di acconto, il pdf non gli basta più” Quindi anziché usare il portale apposito della banca, deve avere un accordo particolare con chissà quale banca dove inoltra via email le fatture xml.
Quando sei davanti a questi casi penso che c’è poco da discutere di sicurezza informatica.
i casi di contraffazione possono anche esserci quando usi portali dove fai l’upload dei file xml precompilati da altri software o caricati in pacchetto tramite mail o c’è un trasferimento dati da un sistema all’altro senza le dovute sicurezze.
ma se l’utente accede al sistema, inserisce i dati nel DB manualmente (senza invii remoti/mail) e dal DB viene prelevato e inoltrato il dato direttamente a SDI, dovrebbe essere abbastanza sicuro.
Certamente sempre che il computer da cui si inviano i dati o il server stesso non sia compromesso.
