Matteo Cecchini, Co-Founder e CEO di T-Consulting, ed Emanuele Briganti, Sales Solution Architect di ReeVo Cloud & Cyber Security, parleranno di Cyber Risk Management.
I nostri ospiti:
 |
| Matteo Cecchini |
|
Imprenditore IT dal 2007, Matteo è prima di tutto un appassionato di tecnologia. Fin dall’adolescenza si dedica allo studio dei sistemi e del loro funzionamento, con un interesse spiccato per la Cybersecurity. Questa passione lo porta a poter contribuire - all’inizio della sua carriera - a prestigiosi progetti di digitalizzazione e di innovazione tecnologica. Nel 2007 fonda T-Consulting allo scopo di supportare con la giusta tecnologia le imprese del suo territorio, ad oggi è attivo su più fronti, come Presidente di CNA Forlì-Cesena e come membro del Consiglio Direttivo del Distretto dell'Informatica Romagnolo. |
 |
| Emanuele Briganti |
|
Dopo la laurea in ingegneria elettronica scatta la passione per i sistemi di sicurezza e le loro potenzialità. Nel giro di pochi anni, diventa ICT Security Manager e successivamente Chief Technical Officer. Approfondisce tematiche come il Computer Forensic e la Digital Investigation. Dal 2006 al 2020 ricopre il ruolo di CTO per un importante System Provider e attualmente è CEO di ReeVo MSP, nato dalla partnership con ReeVo S.p.A., che si propone di offrire servizi gestiti white label per i Managed Services Provider. |
Il tema della videointervista di oggi: l'analisi del rischio tramite simulazione dei percorsi di attacco
Nel corso della videointervista verrà approfondito il tema del Cyber Risk Management: l’analisi del rischio tramite simulazione dei percorsi di attacco e le misure da adottare per ridurre l’esposizione ai cyber attacchi IT/OT. Individuare i possibili attaccanti e le loro strategie è fondamentale per valutare e gestire il rischio. In particolare, la valutazione deve scoprire non solo le vulnerabilità del sistema attraverso un’attività di Vulnerability Assessment e Penetration Test, ma soprattutto i percorsi degli attaccanti.
Se sei interessato ad approfondire gli argomenti trattati contattaci cliccando qui.
Transcript intervista
MATTEO: Buongiorno a tutti e bentornati a questo nuovo appuntamento! Oggi sono qui con Emanuele Briganti. Ciao Emanuele!
EMANUELE: Ciao Matteo e ciao a tutti!
MATTEO: Emanuele è Sales Solution Architect di ReeVo. Con Emanuele oggi faremo una chiacchierata su un tema che è un po’ la degna conclusione di tutte le tematiche che abbiamo toccato fino a oggi, cioè come gestire il rischio in ambito Cybersecurity, quindi parleremo proprio di Cyber Risk Management. Bene, io direi di entrare assolutamente nel vivo. Allora, Emanuele, io partirei con una premessa e una considerazione che è quella proprio legata al nostro tema, il tema del Cyber Risk Management. Ora, questa è una tematica che può essere affrontata, come ben sappiamo, in tanti modi, ma se vogliamo un comune denominatore dell’approccio a questo tema qui dovrebbe quantomeno essere quello di avere un approccio quanto più possibile scientifico/analitico, cercare di utilizzare possibilmente anche un framework che possa essere riconosciuto e standardizzato. Qual è il tuo punto di vista su questo fronte?
EMANUELE: Guarda, vengo proprio dall’Università di Pisa dove sto gestendo una tesi con un professore riguardo alla creazione di un framework per definire il rischio Cyber, quindi mi permetto di riportarti quelle che sono le nostre idee e quelli che sono i nostri dubbi, per cui il lavoro di tesi è abbastanza complesso. Sicuramente anche a livello scientifico non c’è tantissima letteratura nell’avere una misura numerica che non sia alto, medio o basso del rischio Cyber che l’azienda ha, però noi vediamo sul campo che questo è un fattore importante, cioè poter andare a creare un modello, avere una matrice perché poi le variabili sono tante che, una volta che gli ho dato l’ingresso, mi restituisca un’uscita non per magia, ma con criteri scientifici, un indice, che possiamo scegliere come ci pare, un range, però non alto, medio e basso, ma tra 0 e 1, 0-7 o tra 0 e 100 (93), è molto importante. I fattori che in questo momento stiamo analizzando partono sicuramente da dei framework internazionali che esistono, e che voi anche applicate, che poi portano a dei questionari che, ahimé, sono noiosi, ma sono fondamentali perché comunque dobbiamo andare a definire il perimetro, definire il sistema e il grado di investimento, di tecnologia e di processi che il cliente potenziali ha, e questo lo possiamo fare con dei questionari. Poi, però, questi questionari normalmente vanno tradotti in numeri e qui viene la parte difficile.
MATTEO: O divertente, dipende dai punti di vista!
EMANUELE: Lo studente non capiva questo fatto, nel senso che aveva fatto tutta una bella analisi teorica, poi dice: “ok, ma io faccio il questionario del NIST piuttosto che del CISA, ma poi anche quell’output lì mi viene magari un indice (ci sono varie elaborazioni in Excel di questa cosa), però teoricamente è alto, medio e basso. Poi in cosa lo traduci? Come lo correli poi con altre informazioni? Per esempio, in questo caso stiamo analizzando la Cyber Threat Intelligence, quindi oltre a quello che si ricava chiedendo all’azienda, possiamo andare a vedere quello che troviamo, come la visibilità aziendale da questo punto di vista, e anche quelli che sono i trend comuni di attacco e le modalità più usate. Sto dando per scontato che uno degli input fondamentali è comunque un Vulnerability Assessment/Penetration Test (se lo vogliamo fare) che ci dà un livello di vulnerabilità del cliente e anche quali, ma che abbiamo difficoltà (e questo è anche motivo di tesi) a contestualizzare sul suo sistema. Sappiamo che, anche da interventi precedenti al mio, siamo in grado di sapere le vulnerabilità di un cliente, dargli uno score/un valore, ma che è generale a livello internazionale. È più difficile andare a dire: “ok, hai queste vulnerabilità, però nel tuo sistema/contesto, per come sei organizzato (e questo lo ricaviamo dal questionario), per come è emerso dal Penetration Test o da altri strumenti di cui parleremo dopo, queste sono le tue possibili esposizioni contestualizzate, quindi riuscirò poi a dare una priorità alla remediation. Questo perché lo scopo di questo lavoro di tesi è quello di riuscire a prioritizzare le remediation. Diciamo che in questa fase lui deve trovare un modello scientifico che ci porti un output numerico valido.
MATTEO: In realtà hai già toccato alcuni punti molto interessanti che, in qualche modo, evidenziano quelli che sono dei limiti intrinsechi dell’attività di Vulnerability Assessment e di Penetration Test. Ci sono questi limiti, tu ne hai già toccati alcuni. Rispetto anche a quella che è la tua esperienza, ne vedi altri che possono essere annoverati tra le imitazioni di un’attività di VA o VA/PT tradizionale?
EMANUELE: Sì, per quello che riguarda il VA, ribadiamo che è un elemento necessario, senza di quello non sappiamo dove andiamo, quindi facciamo poca strada. La difficoltà che abbiamo nella pratica, però, è che poi a seconda della postura Cyber di un’azienda potremmo trovare un librone o un librino, dipende se hanno un processo gestito di patching o una cultura da questo punto di vista che, però, non sappiamo come prioritizzare, quindi, come dico agli eventi, “io non so fare il patch all” - è impossibile, lo sappiamo per mille motivi. In qualche modo, se partiamo da una situazione in cui la postura Cyber non è molto curata, potrei trovarmi a dover scegliere perché i tempi sono limitati, ci sono anche blocchi legati agli applicativi. Come faccio a dare priorità? Chiaramente le case software stanno lavorando su questo per cercare di creare loro degli indici, ma che comunque rimangono in questo ambito un po’ scollegati dal sistema reale che stiamo analizzando, tra cui il CVSS score e altre cose che sono state poi modificate. Lo sforzo che dobbiamo fare è quello di andare a contestualizzarle. Per fare questo potrebbe essere sicuramente utile un Penetration Test perché il Penetration Test, cosa fa? Mi va, tramite un Red Team, un gruppo di Ethical Hacking, a provare a cercare percorsi di attacco, quindi per sfruttare quelle vulnerabilità che sono emerse dal VA. Sicuramente, quindi, dico una banalità, è meglio fare un VA+PT che fare solo un VA. Essendo io di parte, che oggi racconto di quella che è la nostra soluzione nella quale io credo molto, potrei dirti quelli che vediamo nella pratica, ovvero i limiti di un Penetration Test. Il Penetration Test, e potrei anche dirti dopo in maniera totalmente trasparente quelli che possono essere i limiti di ambito, per esempio, della soluzione di cui parleremo dopo, ha un limite oggettivo: è fatto da una persona o da un gruppo di persone che comunque hanno un loro background tecnico che, diciamo che questo è molto umano, potrebbero provare a sfruttare exploit, vulnerabilità che hanno già trovato in altre situazioni e chiudere il loro lavoro arrivando a una visione sicuramente interessante perché mi dà dei percorsi di attacco, ma che in generale potrebbe essere limitante in una prioritizzazione delle remediation perché è la visione di quel Penetration Test. Magari lo prova 5 volte, ne prova 3, poi è umano, trova una strada che ha già usato, ha già l’exploit pronto, sto banalizzando, però…
MATTEO: No no, ma si sa!
EMANUELE: Lo sfrutta, arriva al target e ti fa una bella relazione. Ripeto, molto meglio un VA+PT che un VA da solo, quindi qualcosa mi dice ed è importante farlo sia interno che esterno. Quello che abbiamo visto poi noi sul campo, e per cui ci siamo spinti su soluzioni di simulazione dei percorsi di attacco, è che l’orizzonte potrebbe essere limitato e, in qualche modo, potrebbe trarmi in inganno nell’andare a fare remediation.
MATTEO: Chiaro. A fronte di tutta questa premessa e di questi limiti che oggettivamente fanno parte dell’attività di VA/PT quando questa viene portata avanti manualmente, un approccio sicuramente più innovativo può essere quello di una simulazione di attacco utilizzando, per esempio, un modello di tipo Digital Twin. Qui arriviamo proprio al punto cruciale della nostra chiacchierata. Come si può declinare questo tipo di approccio? Come lo declinate voi, ad esempio?
EMANUELE: Faccio una premessa: un’evoluzione del Penetration Test potrebbe essere un’Automatic Penetration Test, vale a dire che esistono sul mercato soluzioni che, per risolvere questa limitazione che può avere un Red Team, fanno Penetration Test automatici, quindi con varie modalità (virtual machine agent) vanno ad attaccare, con numerosi tentativi di attacco rispetto al Penetration Test, il sistema in produzione. La strada è comunque una strada valida. Avevamo visto, quando l’avevamo approcciato, che questo ha un impatto importante sull’ambiente del cliente sia in termini di probabili servizi, questo può avvenire anche nel Penetration Test manuale.
MATTEO: Un’invasività!
EMANUELE: Un’invasività, sì, e comunque anche un po’ di complessità nel metterlo in piedi rispetto a un Red Team già organizzato che ha tutti i suoi tools pronti per essere utilizzati, però questo amplierebbe il numero di percorsi di attacco. Quello che a noi è piaciuto e il motivo per cui abbiamo fatto questa partnership è l’idea di creare un gemello digitale. Non ho tantissimo tempo, ma in pratica per chiarirci: si parte comunque da un Vulnerability Assessment, da un Asset Management, quindi da un software che ci dice che device abbiamo e qual è il loro livello di vulnerabilità vengono importati in questa piattaforma che a quel punto ha solo magari l’elenco dei server, l’elenco dei client e quello delle vulnerabilità; dobbiamo dargli una topologia, quindi dobbiamo capire quel server su quale VLAN è, quell’altro client se può dialogare con quel server e quindi dobbiamo aggiungere regole di firewall, regole di routing e, in generale, poi anche relazioni logiche, questo è l’application server, quest’altro è il DB server per creare un modello che non necessariamente deve essere 1 a 1, ma deve essere il più possibile simile alla realtà del cliente, ha 5 macchine in Azure, ha una VPN, ecc. Il modello non è una duplica di macchine virtuali, ma è una rappresentazione formale, quindi avrò un software che risponde, come un Windows server, con le vulnerabilità che ho trovato nel momento in cui ho fatto il VA e con i servizi esposti nel momento in cui ho fatto il VA. Dico questo perché, sempre per essere totalmente trasparente, questa soluzione per esempio non performa bene, e lì è meglio fare un web application penetration test umano, quando dobbiamo analizzare per esempio le vulnerabilità di un’applicazione web o anche di un’applicazione in generale. Questo perché questa soluzione del gemello digitale nasce per trovare i percorsi di attacco su sistemi complessi, quindi con algoritmi che devono convergere. Complesso è anche un sistema di 100 device, non è che deve essere di 1000.
MATTEO: Sì, sì!
EMANUELE: Se io ho una web application che lui non riesce a modellare, per lui la web application è una web application generica che risponde solo a 443 e magari riconosce che c’è TOM, CARTA o AIS che la serve, però se dietro c’è un vendor di quelli che conosciamo o qualcuno che l’ha scritta a mano non riesce a fare Penetration Test se non generico come si può fare con strumenti automatici relativo e mirato per fare escalation di privilegio. A volte ci chiedono: “io sono utente non amministrativo di quella web app, mi fai un Penetration Test per capire?”. Non è la soluzione adatta.
MATTEO: Tipo SQL Injection, certo.
EMANUELE: Sì! Diciamo che lui fa delle simulazioni nelle top 10 di OWASP, ma lì a mio parere performa ancora meglio l’uomo perché andiamo proprio nel dettaglio applicativo che cambia tutte le volte a seconda del software che trova.
MATTEO: Chiaro!
EMANUELE: Una volta che ho questo gemello digitale, che è una presentazione formale, cosa ci faccio? Devo andare a dirgli quali sono gli attaccanti e quali sono i target, più che altro i target perché gli attaccanti ce li ha già modellati all’interno. Siccome è un algoritmo, Monte carlo, che deve convergere non gli posso dire di farmi vedere tutti i percorsi di attacco, gli devo dire di farmi vedere 10/15 potenziali target, quindi il file server, il gestionale, ecc. e poi ipotizzo anche da dove nascono gli attacchi, quindi magari simulano una mail di phishing che arriva su un device che non ha privilegi amministrativi, una che arriva su un device che ha, ahimé, privilegi amministrativi, un attacco dall’esterno, e tutto quello che ci possiamo immaginare. I modelli di attaccanti secondo la matrice Mitre sono già all’interno del modello e vengono aggiornati costantemente.
MATTEO: Scusami, e questo è un elemento fondamentale perché il fatto di avere già tutti gli elementi della matrice inseriti e aggiornati veramente aumenta in modo esponenziale l’efficacia della piattaforma perché va a ragionare effettivamente su quelli che sono elementi reali.
EMANUELE: Sì, le tecniche e le tattiche che poi noi vediamo anche dall’altra parte quando arrivano gli attacchi. Qui, però, è un sistema predittivo. Il cuore è poi l’algoritmo di simulazione che simula milioni di Penetration Test. Con milioni di Penetration Test simulati abbiamo la certezza scientifica che il 99,999% dei percorsi di attacco che lui troverà sono quelli reali. Rimane a livello scientifico come nei data center uno 0,001%. Ho quindi un modello digitale e un modello formale, ma in uscita ho i percorsi di attacco. Rispetto a un Penetration Test tradizionale ne faccio milioni, quindi sicuramente troverò anche quello che il Penetration Test ha trovato. Il bello della piattaforma è che mi dà in output proprio tutti i passaggi che mi portano a raggiungere l’obiettivo, anche con i tempi, perché se si simulano anche i tempi; faccio un esempio veloce, se sono troppo lungo dimmelo: se all’interno della catena di attacco devo sfruttare una vulnerabilità SSL, di quelle che ce ne sono tante, TLS 1.0, che comunque presuppone un man-in-the-middle, tutte cose che con i tools si possono fare, ma che impiegano un po’ di tempo per farle.
MATTEO: Sì, richiedono del tempo!
EMANUELE: Il modello tiene conto anche di questo, quindi riesco ad avere anche una prioritizzazione in funzione di quanto tempo l’attaccante riesce ad arrivare al target. Questo è fondamentale perché magari se ho un attacco che va a buon fine in 3 giorni, va bene, ne dovrò tenere conto, dovrò fare remediation, ma quello che va a buon fine in un quarto d’ora avrà una priorità più alta.
MATTEO: Chiaro! C’è uno schema e un modello di priorità pesati in base anche a degli elementi come quello temporale.
EMANUELE: Sì, come il tempo! Poi la cosa che hanno detto è che i modelli degli attaccanti sono veramente dettagliati, posso avere un attaccante svogliato, un attaccante che comunque trova due ostacoli e riprova, ecc., quindi la situazione è non reale perché è una simulazione, ma molto vicina alla realtà.
MATTEO: Sì, sì! Tanti scenari diversi.
EMANUELE: Tanti scenari diversi con tanti attaccanti diversi.
MATTEO: Chiaramente questo tipo di modello, come giustamente suggerivi tu all’inizio, ci va un po’ a risolvere la problematica, o meglio, realisticamente l’impossibilità di avere un’infrastruttura full patching perché sappiamo che non è realistico, non è possibile per mille motivi legati ai sistemi legacy, legati al tempo e a tante variabili. Durante il T-CON tu avevi fatto un esempio che vorrei riportare anche in questa chiacchierata perché secondo me era molto indicativo il Swiss Cheese model, quindi l’idea di bloccare anche solo un pezzetto della kill chain per bloccare l’intero attacco.
EMANUELE: Sì, quello che si vede (e c’è anche una letteratura scientifica su questo) poi anche nella pratica è che, quando andiamo ad analizzare l’output, quindi i percorsi di attacco su scenari diversi, è che comunque molti attacchi sfruttano vulnerabilità comuni. Qual è quindi il principio? Se ho visione, e con milioni di attacchi ho veramente una visione, statisticamente il campione è molto ampio...
MATTEO: Rilevante!
EMANUELE: Posso andare a evidenziare quali sono le vulnerabilità (e lo fa il software) più comuni ai vari percorsi di attacco. Questo fa sì che io ho una prioritizzazione del patching e anche una riduzione del lavoro perché, anche questo è dimostrabile, facciamo un esempio facile: abbiamo visto che se devo fare 100 patch, alla fine utilizzando questa piattaforma riesco a prioritizzarne 5. Questo non per magia, ma per il concetto che dicevi tu: se io ho vulnerabilità comuni a più percorsi di attacco, e questo è tipico, ne sano 1, 2, 3 o 5 come in questo caso, ho ridotto i percorsi di attacco magari a un rischio gestibile. Noi sappiamo che il rischio zero non esiste, magari partivo da un rischio 80 e arrivo a un rischio 20. Intanto quel 60 me lo sono portato a casa, però avrò qualche tempo per andare a provare a sistemare il 20. Se non posso fare patching, farò microsegmentazione che va tanto di moda, metterò delle honeypot per far cascare l’eventuale attaccante, rifaccio la simulazione e guardo quanto questo migliora, quindi tutto deve essere poi un servizio continuativo.
MATTEO: Ottimo. Ecco, questo è l’altro elemento secondo me molto importante da tenere in considerazione, cioè questo tipo di piattaforma è una piattaforma che effettua questo tipo di analisi su una base scadenziata e ricorrente che, se vogliamo, è un po’ un altro dei grandi limiti delle attività di VA/PT perché io l’attività di VA/PT, per quanto possa essere in gamba il Red Team che lo fa, per quanto possa utilizzare strumenti anche automatizzati, per carità, però io arrivo a un punto, un punto T, in cui chiudo l’attività, genero il report, ho chiaramente la mia fotografia, ho un piano di remediation da seguire, ma potenzialmente dal giorno dopo tutto potrebbe essere rimesso in discussione perché magari cambiano certe variabili dell’infrastruttura. In questo caso, invece, ho una ricorsività.
EMANUELE: Sì, come mi dicono spesso 10 minuti dopo perché magari esce una vulnerabilità diversa e critica. Il vantaggio di avere il modello, chiaramente c’è un po’ di effort nel farlo all’inizio, ma una volta che ce l’ho il modello si autoaggiorna per quello che riguarda le vulnerabilità nuove e note con le piattaforme di gestione e si autoaggiorna a livello di topologia perché si mantiene una sonda, che è quella poi che fa il VA, per tutto quello che la sonda può vedere, quindi se gli dai delle sun-net da scandire lui calcola le differenze (es. è venuto fuori un nuovo server).
MATTEO: E lo va ad aggiungere!
EMANUELE: Chiaramente poi se fai cose che la sonda non può vedere devi essere te...
MATTEO: Chiaro, glielo dici!
EMANUELE: Nella pratica però abbiamo visto che 3 mesi (poi in situazioni critiche andrebbe fatto anche più frequentemente), secondo noi, è il tempo giusto in cui fai il primo run, hai il tempo di fare remediation, poi cambiano le vulnerabilità, cambiano gli attaccanti, le tecniche, la tipologia, ecc., rifai il nuovo run aggiornato e vediamo che poi si riduce sempre di più. Poi può venire fuori una nuova vulnerabilità. Il bello di avere il modello, chiaramente parlo di reti un po’ più complesse, è capire: esce una vulnerabilità che è uno Zero-Day che non ha ancora la risoluzione da parte del produttore, il modello appena esce la vulnerabilità se l’è importata, posso lanciare, al di là dei 3 mesi, un run di emergenza una tantum per capire se e quali percorsi di attacco, con la nuova vulnerabilità, sfrutta quella vulnerabilità.
MATTEO: Chiaro!
EMANUELE: Allora andare, prima che esca la remediation da parte del vendor, a mettere pezza in qua e in là o di networking, o web application firewall, che comunque la piattaforma suggerisce. È sicuramente un qualcosa che va fatto. Senza esagerare perché poi ogni mese diventa pesante, però ogni 3 mesi quello che abbiamo sul campo è una misura corretta di applicazione.
MATTEO: Ottimo! Domanda per andare in chiusura: questo tipo di piattaforme, questo tipo di approccio e di modello è applicabile anche al mondo della sicurezza OT?
EMANUELE: Sì, molto bene, infatti nasce in quegli ambiti che ultimamente, come sappiamo entrambi, stanno ritornando in auge con l’esplosione dell’industria 4.0 e la convergenza dei due mondi. Assolutamente sì dal punto di vista predittivo, quindi preventivo, perché il gemello digitale non ha impatto sull’ambiente di produzione, cioè una volta che io l’ho creato, uno dei problemi di fare un VA, ma ancora peggio un PT in ambiente industriale, è che la macchina deve continuare a produrre.
MATTEO: Sempre!
EMANUELE: Sempre e comunque al di là dei problemi del CISO e del CIO che litigano con il responsabile di produzione.
MATTEO: Esatto!
EMANUELE: Quindi se io creo un modello e attacco quello sono a posto. La piattaforma ha già varie modellazioni di strumenti di automazione industriale. Non l’ho detto prima, ma va anche detto che la cosa interessante è che la piattaforma calcola il caso pessimo, quindi anche nella creazione del modello non occorre avere un dettaglio estremo. Chiaramente la topologia è importante, però a volte mi chiedono: ma io ho il Fortinet con Next generation firewall con tutti questi moduli attivi, ho Watchguard, ho Cisco; io gli dico che ho un Next generation firewall. Questo cosa comporterà? Che, nel peggiore dei casi, rallenta l’attacco, mentre nel migliore dei casi lo sventa. Siccome fa il caso pessimo, se io sano il caso pessimo, sicuramente se l’ha sventato Next generation firewall sono tranquillo. Se, invece, non è riuscito a bypassarlo, nella simulazione tiene conto che c’è un Next generation firewall, ma non entra nel dettaglio del modello. Questo l’ho detto perché si applica all’OT, ma a me basta sapere anche che lì c’è un PLC che sia Siemens, che sia ABB, però posso anche pensare di perderlo quel PLC perché quando arrivano a PLC cambiano vulnerabilità, non è progettato. Ora stanno migliorando, però quelli che sono in campo non sono progettati con criteri security by design.
MATTEO: Vero!
EMANUELE: Quello lo perdo, vediamo come possono arrivare a quel PLC, quindi anche questo che si applica bene. Mentre in ambito di chi fa prodotti e macchinari, anche lì abbiamo trovato parecchio interesse perché posso fare security by design anche per una direttiva nuova che sta facendo un po’ di polemica e che la Comunità europea sta lanciando, nella quale si dice che i produttori di qualsiasi macchinario connesso a internet (quelli che fanno manifatturiero sicuramente sì) devono certificare che, quando è uscito dalla loro catena produttiva, sia immune da vulnerabilità. Questo come si fa a farlo? Bisogna fare una simulazione dei percorsi di attacco che ti può portare anche a fare un security by design. Quando progetti il macchinario da un punto di vista dell’interazione con il mondo IT potresti spostare un mini web server, potresti mettere un mini firewall, cose banali che dico che, però, ti fanno capire quanto la tua architettura può migliorare senza essere invasivo nel mondo produttivo perché hai un gemello digitale.
MATTEO: Ottimo, ottimo! Emanuele, grazie.
EMANUELE: Grazie a te per l’opportunità.
MATTEO: Diciamo che abbiamo toccato alcuni elementi, ce ne sarebbe da parlare per altre mille mila ore. Se chi ci sta seguendo ha voglia di approfondire queste tematiche siamo a vostra completa disposizione. Qui, come al solito, i nostri riferimenti. Grazie a tutti, grazie Emanuele per questo bel confronto!
EMANUELE: Grazie a T-Consulting e alla prossima! Ciao!
