Il 25 luglio 2018 lo US Department of Homeland Security (DHS) ha diffuso un alert su possibili attacchi di varia origine (cybernazionalisti, no global, gruppi criminali e hacktivisti) contro gli Enterprise Resource Planning di aziende, gruppi e istituzioni pubbliche. Vasta è la platea e disparate sono le motivazioni, il che rende virtualmente inazzerabile il rischio. Occorre conviverci, e difendersi.
Gli ERPs sono applicazioni integrate, basate su server farm proprietaria o su web browser o sempre più spesso cloud-based, in grado di gestire tutte le fasi del business (contabilità clienti e fornitori, finanza e controllo, risorse umane, project management, logistica, produzione, marketing, vendite, distribuzione). Sono il cuore dei sistemi IT, che assieme agli OT (operating technologies, i sistemi di fabbrica o di governo di grandi strutture, con gli ICS / SCADA che supervisionano le operazioni e i comandi e controlli) costituiscono il grosso dei sistemi aziendali e istituzionali.
I sistemi ERP non contengono solo i crown jewels aziendali (dati dei clienti, scorte materiali, ordini, piani produttivi e distinte base, contratti, prezzi, ricerca e sviluppo …) ma anche i processi integrati come l’order to cash (OTC), il budget & forecast, le campagne promozionali e tanto altro.
Fonte: TechTarget
La convergenza tra IT e OT non è ancora stata del tutto standardizzata per quanto riguarda la cybersecurity; i due filoni sono andati ciascuno per conto proprio, esponendosi reciprocamente a un potenziale rischio causato dall’altro. Il mix tra cruciale importanza e aree grige di scopertura rende l’ERP una ghiotta preda per i diversi mascalzoni. La riuscita di tale attacco porterebbe gli hacker a lauti festeggiamenti e champagne, le aziende a pane e cipolle e gazzosa. Concordanti osservazioni ci dicono, tutte, che gli attacchi a ICS e altri OT sono più che triplicati nel 2020 e tramite l’integrazione con sistemi MES si spalancano così le porte verso gli ERP: SAP e Oracle, per parlarci chiaro. Gli hacker non si fermano ormai da parecchio al banale denial-of-service (DDoS) ma puntano, attraverso il ransomware di cui già ci siamo occupati in particolare, a una disruption totale della vittima. Un allarme di questo genere è arrivato anche dal governo Merkel di recente.
L’allerta del DHS è basato sul report congiunto delle agenzie specializzate Digital Shadows e Onapsis, qui. Vi si dice che 10,000+ server operano in US su software mal configurato. E si stima che ogni anno saltino fuori 4,000 bugs in SAP e 5,000 in Oracle. Chi scrive ha molte volte nelle aziende messo in solution selection i due fornitori ERP, che nella contesa hanno sempre provveduto a segnalare i flop dell’avversario, trasformando i miei cassetti in autentici musei degli orrori informatici.
Un ulteriore elemento di complessità è il fatto che, contrariamente a quanto avveniva con i vecchi sistemi fatti in casa (tecnicamente, bespoke), c’è poca visibilità sul funzionamento interno del package, che arriva preconfezionato e patch o upgrade vengono direttamente trasmessi nell’ambiente di trasporto, da questo a quello di test-sviluppo e infine in esercizio. D’altra parte è lampante che l’esistenza di residui sistemi legacy, i vecchi sistemi fatti in casa con l’Assembler o il Cobol, sono di per sé un fattore di rischio. Diceva Cicerone che la vecchiaia è di per sé una malattia.
Molti ERP usano vecchie tecnologie sui legacy, come file transfer protocol (FTP) o la trasmissione testi in chiaro, facili da hackerare. Il phase-out dei vecchi sistemi sicuramente migliora la sicurezza ma in generale non basta. Succedono intrusioni anche con sistemi nuovi di zecca. Il dilemma su come fare convivere un ERP nuovo con i vecchi legacy c’era 30 anni fa e c’è ancora oggi. Affiorano come zombie da grandi sistemi come Poste o Ferrovie Nord vecchi programmi dei tempi del nonno, scritti in CICS o in DL1 e semplicemente incapsulati in ambiente MS Windows. Nessuno sa come metterci mano. Il budget IT per le manutenzioni di quei sistemi è visto talmente male che si lesina e poi si paga pegno.
Le aziende potrebbero anche sfruttare i propri sforzi per migrare i propri sistemi al cloud come opportunità per migliorare la sicurezza informatica. La maggior parte degli attacchi moderni inizia con la crittografia dei dati di backup per impedirne il ripristino. Ciò significa che quando le aziende eseguono i loro backup, se infettate stanno sistemticamente eseguendo il backup di un sistema già danneggiato! Ad aggravare il problema c’è il fatto che le aziende spesso eseguono i backup in tempo reale (a caldo), rendendo difficile separare i sistemi sani da quelli corrotti. Per quanto bizzarro, può essere meglio eseguire backup discreti, quotidiani o settimanali, per isolare meglio il prima e il dopo l’infezione da malware.
La citata ricerca Digital Shadows e Onapsis segnala il crescente interesse degli hacker per le vulnerabilità note ma anche per i cosiddetti zero-days, quelle non espressamente note allo sviluppatore o alla casa che ha prodotto quel sistema, che consentono lo sviluppo di programmi exploit che sfruttano queste neo-vulnerabilità. Nel report si riferisce testualmente: “Abbiamo osservato informazioni dettagliate sull’hacking di SAP, scambiate in un importante forum criminale in lingua russa, nonché individui interessati ad acquisire exploit specifici di SAP HANA sul dark web“. SAP HANA (High-performance ANalytic Appliance) è il nuovo data-base di SAP che archivia i dati in memoria invece che su disco. Gli attaccanti di solito si orientano su applicazioni ERP in locale, non su cloud, che siano rimaste indietro come aggiornamenti del software e non godano di fama di particolare rigore nella sicurezza. Del tutto logico.
Molto spesso, affermano i ricercatori, gli aggressori sfruttano nome utente e password trafugati in altre violazioni così da entrare nell’account ERP di un dipendente. Per esempio, chi ha bazzicato SAP sa che all’inizio della sessione veniva richiesto il Mandant, cioè l’azienda cliente (SAP nacque come software per i commercialisti tedeschi) e poi il Benutzer (lo user name). In alternativa a questo approccio secco e brutale, i ricercatori affermano di aver identificato oltre 500 file di configurazione ERP esposti online in repository non protetti. Gli aggressori possono estrarre dati da questi file per successivi attacchi. Digital Shadows e Onapsis evidenziano che il trojan bancario Dridex è stato potenziato nel 2017 per cercare e mietere le credenziali (credential harvesting) specificamente di SAP. Report ancora precedenti (FireEye e ProtectWise) sulle attività dei gruppi cinesi di cyber-spionaggio APT10 e APT17 confermavano l’interesse di hacker ”statali” in applicazioni ERP cloud. Facendo la tara all’impostazione “nazionalistico-patriottica” americana, le minacce appaiono comunque plausibili.
Tutto sommato, la ricerca e l’alert DHS associato volevano lanciare un segnale per quanto riguarda la protezione dei sistemi ERP stimolando le organizzazioni ad agire: gli attacchi su larga scala alle applicazioni ERP potrebbero anche avere implicazioni macroeconomiche, affermano i ricercatori, temendo che si potrebbe verificare un nuovo caso WannaCry, il worm ransomware responsabile di un’epidemia su larga scala del maggio 2017 su ambienti Microsoft Windows.
Semplifichiamo molto brevemente come si implementa SAP. La sua prerogativa di integrazione fa sì che il dato scritto in un punto sia propagato in tutto il sistema senza doverlo ridare, e che un’anagrafica sia la stessa sia nel ciclo passivo (logistica, acquisti, contabilità fornitori) che in quello attivo (produzione, vendita, distribuzione, contabilità clienti). La prima cosa che il sistema richiede è l’impianto della struttura aziendale e dei plant (tutte le unità produttive o i magazzini). La descrizione di come viene controllato il gruppo, che può essere anche molto complesso, non può poi essere modificata alla leggera. Viene quindi richiesto il piano dei conti, anch’esso fondamentale per la chiarezza della fotografia aziendale. Area per area si individuano i processi, si condividono con gli utenti che dovranno accettare la soluzione nativa di SAP (reingegnerizzazione) salvo imprescindibili verticalizzazioni del business; il sistema viene quindi parametrizzato con l’utente o se proprio necessario customizzato con nuovo software scritto in linguaggio SAP (il vecchio ABAP4). Tralasciando i tecnicismi, i web services, le BAPI per la fruizione dei sistemi, etc., boiled down è poco più di quanto testè detto. Poi farlo è un bel cinema.
I vertici aziendali raramente hanno una percezione chiara di quali sono e dove si trovano i loro dati e sistemi più importanti. È un problema che viene da lontano. Andava di moda fare gli snob con l’IT: ci si vantava di avere l’orticaria per quelle diavolerie. Occuparsi di IT per molti capi e capetti era sporcarsi le mani, roba per tecnici con il camice. Così siamo arrivati ai ransomware di oggi.
La complessità dell’impianto e della configurazione/customizzazione dell’ERP è una sfida per l’ICT. Il modo di metterlo in esercizio può considerarsi un progetto nel progetto. L’ideale sarebbe lo slam in (nessuna personalizzazione del sistema, adattamento 100% dell’utente al package) con avvio a big bang (tutto assieme). C’è però il problema dei business che hanno stagionalità: operative, commerciali o finanziarie che vincolano date sì e date no. E poi se non parte bisogna fare il roll back e tornare al vecchio. Un tempo per un po’ si teneva il parallelo fra sistemi vecchio e nuovo ma era veramente complesso perché non solo i sistemi ma i processi erano diversi. Allora si ipotizzava di partire con un settore solo (tipicamente la contabilità), ma con le interfacce con il legacy. Oppure, se si trattava di un gruppo, fare un piccolo big bang sull’affiliata o la business company meno critica per dimensione e complessità. Poi c’era il problema della pulizia dei dati vecchi, dove c’era di tutto, e la migrazione degli stessi sul nuovo ERP. Sperimentammo allora l’integratore o come lo chiamano oggi il bus di servizio: un middleware su cui convergevano tutte le interfacce dell’ERP con il legacy. Era con il senno di poi una buona idea: oggi, con la cybercriminalità, accogliere e organizzare le interfacce di sistema in un unico middleware ne semplifica il monitoraggio e la disattivazione tempestiva quando una si trovi sotto attacco.
