Il TeamSystem data breach che ha interessato Contabilità in Cloud non è un semplice disservizio tecnico. TeamSystem ha rilevato un accesso non autorizzato alla piattaforma con conseguente esfiltrazione di dati presenti negli ambienti interessati.
Secondo la comunicazione dell’azienda riportata da Federprivacy, tra le informazioni coinvolte possono esserci dati anagrafici, dati di contatto, coordinate bancarie IBAN e informazioni relative alle movimentazioni contabili, comprese causali, importi e controparti. Le verifiche svolte finora non avrebbero invece rilevato una compromissione delle credenziali di accesso.
Quest’ultimo punto è importante, ma non chiude il problema. Un insieme di dati che collega persone, aziende, IBAN, importi e rapporti economici può rendere molto più credibili phishing mirati, false richieste di modifica delle coordinate bancarie e tentativi di impersonificazione.
La situazione richiede quindi due cose: evitare allarmismi su ciò che non è stato confermato e non sottovalutare quello che sappiamo già.
TeamSystem data breach: cosa è successo il 24 agosto
TeamSystem ha comunicato di aver rilevato nel pomeriggio del 24 agosto un incidente di sicurezza che ha interessato Contabilità in Cloud.
Non si parla soltanto di un tentativo di intrusione. Le informazioni disponibili indicano un accesso non autorizzato seguito da esfiltrazione di dati, cioè dal trasferimento di informazioni al di fuori dell’ambiente nel quale erano conservate.
È questo che distingue l’episodio da un normale problema di disponibilità del servizio.
Contabilità in Cloud continua a essere presente nell’offerta ufficiale dei software cloud TeamSystem come soluzione per la gestione di contabilità e fatturazione elettronica. Non risultano quindi indicazioni che il prodotto sia stato ritirato o dismesso in conseguenza dell’incidente.
Cosa è confermato e cosa non sappiamo ancora
| Informazione | Stato |
|---|---|
| Contabilità in Cloud è il prodotto interessato | Confermato |
| È avvenuto un accesso non autorizzato | Confermato |
| Sono stati esfiltrati dati | Confermato |
| Possono essere coinvolti dati anagrafici e di contatto | Confermato |
| Possono essere coinvolte coordinate bancarie IBAN | Confermato |
| Possono essere coinvolte informazioni sulle movimentazioni contabili | Confermato |
| Le credenziali di accesso risultano sottratte | Non risulta dalle verifiche comunicate finora |
| Fatture in Cloud è stata compromessa | Non confermato |
| È stato utilizzato un ransomware | Non noto |
| È conosciuto il gruppo responsabile | Non noto |
| È nota la vulnerabilità utilizzata | Non noto |
| È noto il numero complessivo di clienti o interessati | Non noto pubblicamente |
| Eventuali precedenti disservizi sono collegati all’intrusione | Non dimostrato |
Questa distinzione conta perché durante un incidente di cybersecurity un’informazione incompleta può facilmente trasformarsi in una conclusione non supportata.
Al momento, per esempio, non abbiamo elementi sufficienti per parlare di ransomware, supply chain attack, furto generalizzato di password o compromissione dell’intero ecosistema TeamSystem.
Quali dati risultano sottratti da Contabilità in Cloud
Nel TeamSystem data breach il problema principale non è solamente la presenza degli IBAN.
L’incidente diventa più delicato perché informazioni diverse possono essere combinate tra loro.
Dati anagrafici, contatti e IBAN
Le categorie comunicate comprendono dati anagrafici, informazioni di contatto e coordinate bancarie IBAN, naturalmente nei casi in cui questi dati fossero effettivamente presenti nell’ambiente coinvolto.
Un IBAN da solo non equivale alla password di un conto corrente e non permette normalmente a qualcuno di entrare nell’home banking.
Il rischio cambia quando quell’IBAN viene associato a un’identità, a un’azienda, a un recapito e alle operazioni economiche che la riguardano.
Un criminale può così disporre di informazioni utili per rendere credibile una richiesta fraudolenta: conoscere una controparte reale, un rapporto commerciale esistente oppure un importo compatibile con le normali operazioni dell’azienda riduce gli elementi che deve inventare.
Perché causali, importi e controparti sono particolarmente delicati
Le informazioni sulle movimentazioni contabili possono avere un valore molto superiore a quello di un semplice elenco di indirizzi email.
Una causale può indicare il motivo di un pagamento. Una controparte permette di ricostruire una relazione commerciale. Gli importi aiutano a capire quali operazioni siano plausibili per quella specifica azienda.
Combinando questi elementi, un attaccante potrebbe costruire richieste come una modifica dell’IBAN di un fornitore, una verifica apparentemente richiesta dalla banca, una falsa correzione contabile o un messaggio che utilizza proprio l’incidente TeamSystem come pretesto.
Non significa che queste frodi siano già avvenute.
Significa che i dati sottratti possono ridurre sensibilmente la quantità di informazioni che un truffatore deve indovinare per rendere credibile un tentativo di social engineering.
Le credenziali TeamSystem sono state compromesse?
Sulla base delle informazioni rese disponibili finora, le verifiche non hanno evidenziato una compromissione delle credenziali di accesso degli utenti.
È una distinzione importante.
Non sarebbe corretto affermare che sono state rubate password TeamSystem quando gli elementi disponibili non lo dimostrano.
Questo non rende però irrilevante il rischio relativo agli account.
I dati già esposti potrebbero essere utilizzati successivamente per convincere una persona a fornire password, codici OTP o altre informazioni attraverso un sito falso, una telefonata o una comunicazione apparentemente legittima.
È uno dei motivi per cui, dopo un incidente del genere, diventa particolarmente utile sapere come funziona il phishing e quali segnali controllare.
Contabilità in Cloud e Fatture in Cloud: cosa è realmente coinvolto
Su questo punto conviene essere molto precisi.
Contabilità in Cloud e Fatture in Cloud sono prodotti distinti nell’offerta TeamSystem.
La stessa pagina ufficiale dedicata ai software cloud presenta Contabilità in Cloud come soluzione per contabilità e fatturazione elettronica e Fatture in Cloud come prodotto separato per la gestione della fatturazione elettronica e delle attività correlate.
Questo non impedisce ai prodotti e ai servizi dell’ecosistema TeamSystem di essere integrati tra loro.
Ma integrazione non significa compromissione condivisa.
Il perimetro pubblico dell’incidente riguarda Contabilità in Cloud. Non possiamo quindi trasformare automaticamente questa informazione in “Fatture in Cloud è stata hackerata” o “tutto TeamSystem è stato compromesso”.
Per estendere il perimetro servirebbe un’evidenza specifica.
La stessa cautela vale per eventuali altri servizi dell’ecosistema: utilizzare infrastrutture, autenticazioni o componenti comuni non dimostra da solo che l’accesso non autorizzato abbia raggiunto ogni sistema collegato.
Quali sono i rischi per aziende, professionisti e clienti
Una volta separati i fatti dalle ipotesi, il rischio più concreto del TeamSystem data breach è più facile da individuare.
Non è necessariamente l’accesso diretto al conto bancario.
È l’utilizzo delle informazioni sottratte per manipolare una persona che può autorizzare un pagamento, modificare un’anagrafica o fornire ulteriori dati.
Phishing costruito su informazioni reali
Un normale messaggio di phishing deve indovinare molte cose.
Deve sperare che la vittima utilizzi il servizio imitato, abbia un rapporto con l’azienda citata e trovi plausibile la richiesta.
Con informazioni contabili reali, una parte di questo lavoro è già stata fatta.
Una comunicazione fraudolenta potrebbe conoscere il nome corretto di una controparte, un rapporto economico realmente esistente o un importo coerente con le normali attività dell’azienda.
Il messaggio può quindi sembrare molto più credibile della classica email inviata indiscriminatamente a migliaia di indirizzi.
Il rischio delle false richieste di cambio IBAN
Uno degli scenari da sorvegliare con maggiore attenzione è la modifica fraudolenta delle coordinate bancarie di un fornitore.
Il meccanismo è semplice: qualcuno impersona una controparte reale e comunica che i prossimi pagamenti devono essere effettuati verso un nuovo conto.
Quando chi scrive conosce già nomi, relazioni commerciali o dati sulle operazioni, la richiesta può risultare molto convincente.
La contromisura più efficace è procedurale.
Una modifica dell’IBAN non dovrebbe essere approvata utilizzando esclusivamente le informazioni contenute nella stessa comunicazione che richiede il cambiamento.
Meglio verificare attraverso un secondo canale già conosciuto: per esempio chiamando il referente utilizzando il numero presente nella propria rubrica, nel gestionale o nella documentazione precedente, non quello eventualmente indicato nella nuova email.
Questa separazione dei canali può bloccare la frode anche quando il messaggio contiene informazioni autentiche.
Impersonificazione di banca, commercialista, cliente o fornitore
L’attaccante non deve necessariamente fingersi TeamSystem.
Può essere più efficace presentarsi come qualcuno con cui l’azienda ha già un rapporto.
Banca, commercialista, amministrazione, cliente o fornitore sono tutti interlocutori plausibili quando una comunicazione viene costruita utilizzando informazioni contabili.
Per questo un TeamSystem data breach non dovrebbe essere gestito solamente dal reparto IT.
Anche chi si occupa di pagamenti, tesoreria, anagrafiche fornitori e amministrazione deve sapere che una comunicazione contenente dati corretti non è automaticamente una comunicazione autentica.
Cosa fare se hai ricevuto la comunicazione di TeamSystem
Non esiste una singola azione capace di “risolvere” un data breach.
Serve piuttosto una sequenza di verifiche che consenta di capire quali dati erano effettivamente presenti nell’account, quali persone possono essere coinvolte e quali abusi risultano realistici nel proprio contesto.
Conserva la comunicazione ricevuta
La comunicazione del fornitore è parte della documentazione dell’incidente.
Conviene conservarla insieme agli eventuali allegati e agli aggiornamenti successivi, perché permette di ricostruire quando l’organizzazione è stata informata, quale perimetro è stato comunicato e quali categorie di dati risultano potenzialmente interessate.
Questo diventa particolarmente importante anche per le valutazioni privacy successive.
Individua quali dati erano realmente presenti nel tuo ambiente
L’elenco generale delle categorie coinvolte non significa che ogni account contenga necessariamente tutte quelle informazioni.
La domanda utile è più specifica:
quali dati erano presenti nel mio ambiente di Contabilità in Cloud e a chi si riferivano?
Potrebbero essere coinvolte informazioni di clienti, fornitori, collaboratori, dipendenti, professionisti o altri soggetti.
Ricostruire questo perimetro consente di passare da una notizia generale a una valutazione concreta del rischio.
Coinvolgi privacy, sicurezza e amministrazione
L’incidente non riguarda soltanto la sicurezza informatica.
Se l’organizzazione dispone di un DPO, di un referente privacy o di professionisti incaricati della protezione dei dati, questi soggetti devono poter valutare il caso.
Allo stesso tempo chi gestisce pagamenti, tesoreria e anagrafiche fornitori deve essere informato del possibile aumento di comunicazioni fraudolente costruite utilizzando dati reali.
La risposta efficace coinvolge quindi privacy, sicurezza e processi amministrativi.
Verifica ogni modifica bancaria attraverso un canale indipendente
Per un periodo di maggiore attenzione considererei qualsiasi richiesta di modifica di coordinate bancarie come un’operazione da verificare separatamente.
Non significa bloccare i pagamenti.
Significa evitare che la stessa email sia contemporaneamente richiesta e prova della legittimità della richiesta.
Se un fornitore comunica un nuovo IBAN, la conferma dovrebbe arrivare da un secondo canale già conosciuto dall’azienda.
Diffida dei messaggi che utilizzano l’incidente come pretesto
La notorietà del caso può essere sfruttata anche da criminali che non hanno avuto alcun accesso ai dati sottratti.
Una falsa comunicazione potrebbe chiedere di confermare l’IBAN, riattivare l’account, scaricare un documento, verificare una fattura, inserire nuovamente le credenziali o comunicare un codice di autenticazione.
Il fatto che il messaggio faccia riferimento a un incidente realmente avvenuto non rende autentico il messaggio.
Quando hai un dubbio, raggiungi il servizio attraverso il normale indirizzo che utilizzi abitualmente invece di seguire il link ricevuto.
Rafforza l’accesso senza confondere precauzione e compromissione
Poiché le credenziali non risultano compromesse nelle verifiche comunicate finora, non dobbiamo presentare il cambio password come prova che le password siano state rubate.
Resta però sensato controllare la sicurezza degli account.
Password riutilizzate su servizi differenti, richieste di reset inattese e accessi anomali rappresentano rischi indipendenti dall’incidente.
Quando disponibile, anche l’autenticazione a due fattori aggiunge una barriera importante nel caso in cui una password venga successivamente sottratta attraverso phishing o altri attacchi.
Controlla pagamenti e comunicazioni bancarie senza creare falso allarme
La presenza di un IBAN nei dati esposti non significa automaticamente che qualcuno possa svuotare il conto corrente.
È però ragionevole aumentare l’attenzione verso operazioni non riconosciute, richieste bancarie insolite, comunicazioni relative a pagamenti e tentativi di cambiare coordinate finanziarie.
Un interlocutore che conosce un tuo dato corretto non è necessariamente chi dice di essere.
Dopo una violazione di dati, quella conoscenza può essere proprio uno degli strumenti usati per conquistare fiducia.
TeamSystem data breach e GDPR: cosa deve valutare l’azienda cliente
Dal punto di vista privacy, il TeamSystem data breach merita particolare attenzione perché è facile trasformare la regola delle 72 ore in uno slogan sbagliato.
TeamSystem spiega nella propria documentazione sugli accordi per la protezione dei dati che, quando non si limita a fornire una soluzione tecnologica ma effettua trattamenti di dati per conto del cliente, come avviene nei servizi cloud, assume il ruolo di responsabile del trattamento.
Il ruolo effettivo va comunque verificato rispetto al servizio utilizzato, al contratto e ai trattamenti concretamente svolti.
Per una visione generale dei ruoli e degli obblighi puoi approfondire anche nella nostra guida al GDPR.
TeamSystem come responsabile e cliente come titolare
Quando un fornitore tratta dati personali per conto di un cliente in qualità di responsabile, l’articolo 33 del GDPR prevede che informi il titolare senza ingiustificato ritardo dopo essere venuto a conoscenza della violazione.
Da quel momento il cliente deve capire se e come la violazione riguardi i trattamenti dei quali è titolare.
La comunicazione del fornitore non sostituisce quindi la valutazione dell’organizzazione cliente.
Le fornisce gli elementi necessari per iniziarla.
Le 72 ore non significano notifica automatica per tutti
Il Garante per la protezione dei dati personali chiarisce che il titolare deve notificare una violazione all’Autorità senza ingiustificato ritardo e, ove possibile, entro 72 ore dal momento in cui ne viene a conoscenza, a meno che sia improbabile che la violazione comporti un rischio per i diritti e le libertà delle persone fisiche.
Questo significa che:
ricevere la comunicazione TeamSystem non equivale automaticamente a dover notificare il Garante.
Prima bisogna valutare la violazione nel proprio contesto.
Il percorso corretto è:
conoscenza dell’incidente → ricostruzione dei dati coinvolti → valutazione del rischio → decisione sulla notifica → documentazione della decisione.
Se la notifica è necessaria, entra in gioco il termine previsto dal GDPR.
Se invece il titolare conclude che è improbabile un rischio per i diritti e le libertà delle persone fisiche, la notifica all’Autorità non è automaticamente richiesta. La valutazione deve comunque essere sostenibile e documentata.
Notifica al Garante e comunicazione agli interessati sono due valutazioni diverse
La notifica all’Autorità e la comunicazione diretta alle persone coinvolte non hanno esattamente lo stesso presupposto.
La comunicazione agli interessati entra in gioco quando la violazione è suscettibile di presentare un rischio elevato per i loro diritti e le loro libertà, salvo le eccezioni previste dalla normativa.
Non esiste quindi una regola generale:
“c’è stato un data breach, bisogna inviare una mail a tutti”.
La decisione dipende dai dati effettivamente coinvolti, dal contesto, dalle possibili conseguenze, dalle misure adottate e dalla probabilità che le informazioni possano essere utilizzate contro le persone.
Il breach va documentato anche quando non viene notificato
La gestione della violazione non si esaurisce nella domanda “devo notificare oppure no?”.
Il GDPR richiede al titolare di documentare le violazioni di dati personali, comprese le circostanze, le conseguenze e le misure adottate per porvi rimedio.
In pratica è importante poter ricostruire quando si è venuti a conoscenza dell’incidente, quali dati risultavano interessati, quale valutazione del rischio è stata effettuata, quali misure sono state adottate e perché si è deciso di notificare o non notificare.
Per un caso concreto è opportuno coinvolgere il proprio DPO o un professionista competente: questa sezione serve a chiarire il meccanismo generale, non a sostituire una valutazione legale sul singolo trattamento.
Cosa non sappiamo ancora sull’attacco a TeamSystem
Gli elementi mancanti sono ancora numerosi e alcuni potrebbero cambiare in modo significativo la lettura dell’incidente.
Il vettore iniziale dell’attacco
Non risulta pubblicamente chiarito come sia stato ottenuto il primo accesso.
Non sappiamo quindi se sia stata sfruttata una vulnerabilità, una credenziale privilegiata, una configurazione errata, un componente esterno o un altro vettore.
Attribuirne uno senza prove significherebbe inventare la catena dell’attacco.
Quando è iniziato realmente l’accesso non autorizzato
Il 24 agosto indica il momento in cui TeamSystem ha rilevato l’incidente.
Non dimostra necessariamente che l’accesso sia iniziato nello stesso momento.
Per ricostruire la compromissione sarebbe utile conoscere la finestra temporale effettiva durante la quale soggetti non autorizzati hanno avuto accesso all’ambiente.
Quanti clienti e quante persone sono coinvolti
Non risulta pubblicamente quantificato il numero complessivo di clienti, account o interessati.
Per questo non è corretto utilizzare cifre sull’impatto complessivo finché non vengono fornite da una fonte attendibile.
Conoscere le categorie di dati esposte non permette da solo di dedurre quanti record siano stati esfiltrati.
Chi è responsabile dell’attacco
Non risulta un’attribuzione pubblica verificata a uno specifico gruppo criminale.
Allo stesso modo non abbiamo elementi sufficienti per classificare automaticamente l’incidente come ransomware.
Se dovesse apparire una rivendicazione, andrebbe verificata separatamente: il fatto che un gruppo criminale affermi di aver colpito un’azienda non costituisce da solo una conferma tecnica dell’attribuzione.
I problemi segnalati a TeamSystem durante agosto sono collegati al data breach?
Al momento non possiamo dimostrarlo.
È un punto importante perché parte dell’interesse intorno alla vicenda nasce anche da problemi e difficoltà segnalati dagli utenti durante agosto.
Una segnalazione può documentare che una persona ha incontrato un problema.
Non permette però di concludere automaticamente che esistesse un outage generale, che il problema riguardasse lo stesso ambiente coinvolto nel breach o che fosse provocato dall’accesso non autorizzato.
Lo stesso vale per eventuali segnalazioni relative a Fatture in Cloud: abbiamo visto che è un prodotto distinto da Contabilità in Cloud.
Una coincidenza temporale non dimostra una relazione causale.
Fino a quando TeamSystem o un’altra fonte attendibile non forniranno elementi che collegano eventuali disservizi precedenti alla compromissione, i due fenomeni devono essere trattati separatamente.
Se emergeranno nuove evidenze, questa parte dell’articolo sarà uno dei primi punti da rivalutare.
Conclusione
Il TeamSystem data breach va preso sul serio soprattutto per la qualità delle informazioni che possono essere state sottratte, non perché esista già la prova di una compromissione totale dei sistemi o dei conti bancari.
Il perimetro attualmente confermato riguarda Contabilità in Cloud. Le categorie di dati coinvolte possono comprendere informazioni anagrafiche, contatti, IBAN e dati sulle movimentazioni contabili. Le credenziali di accesso, sulla base delle verifiche comunicate finora, non risultano compromesse.
Per aziende e professionisti la priorità pratica è proteggere i processi nei quali quelle informazioni potrebbero essere sfruttate: richieste di pagamento, variazioni di IBAN, comunicazioni con fornitori, phishing e tentativi di impersonificazione.
Per chi tratta dati personali serve inoltre una valutazione GDPR documentata, senza confondere il termine delle 72 ore con un obbligo automatico di notifica per chiunque abbia ricevuto l’avviso.
La regola più utile resta quindi mantenere una distinzione netta fra ciò che è stato confermato, ciò che rappresenta un rischio realistico e ciò che ancora non sappiamo.