📚 CORSO COMPLETO sulle misure minime ICT AgID [Parte 2 di 2]

Ciao a tutti, benvenuti in questa seconda parte del video sulle misure di sicurezza dell'Agid. Se non l'avete vista, andatevi prima a vedere la prima parte. Riprendiamo subito da dove ci eravamo interrotti. Andiamo avanti perché siamo arrivati alla misura numero 4: valutazione e correzione continua della vulnerabilità. Le vulnerabilità sono una parte essenziale degli attacchi informatici, perché è molto più semplice sfruttare qualcosa che è già vulnerabile, una vulnerabilità già scoperta, un punto debole, piuttosto che andare a inventarlo. Se ad esempio un computer Windows ha una determinata vulnerabilità per cui chiunque inserisca una chiavetta USB riesce a infettarlo con un malware, faccio per dire, sarà molto più facile sfruttare quella che ingegnarsi, inventare backdoor, superamenti di firewall e cose del genere. Quindi bisogna prestare molta attenzione a quelli che sono i punti deboli già noti. Infatti dice la misura: acquisire, valutare, intraprendere continuamente azioni in relazione a nuove informazioni allo scopo di individuare vulnerabilità, correggere e minimizzare la finestra di opportunità per gli attacchi informatici. Una vulnerabilità quindi altro non è che una porticina lasciata aperta per un attaccante che, se la conosce, può decidere di sfruttarla. La misura minima qui descritta è: ad ogni modifica significativa della configurazione, quindi quindi torniamo al concetto della configurazione standard, eseguire la ricerca delle vulnerabilità su tutti i sistemi in rete con strumenti automatici che forniscano a ciascun amministratore di sistema dei report con indicazione delle vulnerabilità più critiche. Qui banalmente gli strumenti a cui fa riferimento sono quei tool che prendono le vulnerabilità note, ad esempio l'elenco delle CVE, le Common Vulnerability and Exposures, e le va a confrontare con quelle che sono effettivamente presenti in un sistema. Ad esempio, Decido di prendere un nuovo software, so che il software ha questo difetto qua, questa vulnerabilità descritta in questa lista. Devo avere un sistema automatico che mi dica ogni volta che io installo un nuovo software quale vulnerabilità ha e quindi come potrebbero essere sfruttate. Come vedete qui la misura si limita a rilevare le vulnerabilità, non dice come agire, dice solo dovete avere un modo per capire se c'è una vulnerabilità. Ovviamente questa cosa andrebbe fatta più volte, ma qui ce la mette come misura, diciamo, standard. Non come misura minima, eseguire periodicamente la ricerca delle vulnerabilità. Quindi questa cosa facciamola un po' più spesso. La cosa ancora più avanzata, infatti è una misura qualificata come avanzata, è usare uno SCAP, uno strumento automatico di validazione delle vulnerabilità che rilevi sia le vulnerabilità basate sul codice, e dice proprio come quelle descritte dalle voci CVE, Common Vulnerabilities and Exposures, che sono appunto queste banche dati di vulnerabilità note, che quelle basate sulla configurazione. E qui fa riferimento a un'altra lista che invece fa riferimento proprio alla configurazione. È come la CVE, sempre del NIST, ma si chiama CCE, Common Configuration Enumeration Project. Continuiamo. Abbiamo sempre misure standard o avanzate in questo caso, tranne una misura minima che però è un po' più avanti. Dice che non basta quindi rilevare le vulnerabilità, ma bisogna correlare i log di sistema, quelli che dovremmo già avere implementato secondo le misure— mi sembra fossimo nel controllo numero 1 addirittura— con le informazioni ottenute dalle scansioni delle vulnerabilità. Cioè, questi log dicono che ci sono questi dispositivi che fanno queste cose, abbiamo adesso una lista di vulnerabilità, cerchiamo di capire qual è il sistema che ha questa vulnerabilità e come in generale si interfacciano fra di loro. E non basta fermarsi qua, bisogna anche verificare che i log registrino le attività dei sistemi di scanning delle vulnerabilità. Cioè, dobbiamo avere in questo registro dei log che dice che cosa faccia ciascun software, ciascun dispositivo, anche come si comportano i sistemi che scannerizzano le vulnerabilità, ogni quanto partono, cosa rilevano. Bisogna tenere una cronologia di tutto. Le linee guida AGID, come tantissime altre normative, prevedono sicuramente dei controlli di tipo tecnico, ma molte cose documentali. Quando si parla di implementare un sistema di log, è tecnica la prima parte, ma diventa documentale nel momento in cui io ho un registro di log. Quello devo tenerlo aggiornato, devo mantenerlo sempre E poi andiamo avanti. Verificare nei log la presenza di attacchi pregressi condotti contro target riconosciuti come vulnerabili. Quindi non basta avere il log di tutti i dispositivi, di quello che fanno, non basta avere una correlazione fra i log e le vulnerabilità, non basta che i log registrino le attività degli scanning di vulnerabilità, ma devo anche verificare se ci sono già stati degli attacchi. Quindi non mi basta avere il registro, non mi basta tenere monitorato, controllare che ci finiscano anche i risultati degli scanning, io devo anche fare in modo di verificare in modo automatico, o con qualcuno che lo faccia, se nei log emerge che effettivamente c'è stato qualche attacco. Non mi basta quindi un censimento generico, devo portarlo chiaramente a terra. Andando avanti, le scansioni di vulnerabilità devono essere eseguite in modalità privilegiata, quindi ovviamente non con un account che non abbia accesso a tutto il sistema, ma con un account con privilegi molto alti, sia localmente sia da remoto. Quindi dobbiamo farlo sia in loco sia da remoto, utilizzando un account dedicato che non deve essere usato per nessun'altra attività di amministrazione. Quindi teniamo un account, visto che comunque sono account che fanno un'attività molto delicata, è importante che non interferiscano col resto del sistema, sia perché potrebbero essere danneggiati. Immaginiamoci la mente di un hacker, la prima cosa di cui va a prendere possesso è l'account che rileva le vulnerabilità per fare in modo che non le rilevi più. Ma è vero anche il contrario, un account che verifica se ci sono delle vulnerabilità potrebbe essere infettato e E così potrebbe anche, se è un account che fa anche altre cose, danneggiare tutto il sistema. Per cui la cosa importante è che l'account sia separato dal resto. E torna un po' al discorso dell'air gap, no, del tenere separata la rete che fa le attività operative dalla rete che si occupa della sicurezza. Sempre più o meno su questa falsariga abbiamo questa misura, che è vincolare l'origine delle scansioni delle vulnerabilità a specifiche macchine o indirizzi IP. Cioè, devo capire chi è che ha fatto una scansione della vulnerabilità. Banalmente, anche solo perché? Perché se io per sbaglio assumo una persona che in realtà è malintenzionata, quella persona come prima cosa farà proprio una scansione delle vulnerabilità per capire quali sono i punti deboli dell'azienda. Io devo fare in modo di poterla scoprire, di poterla bloccare, di avere un registro che dica chi è che ha fatto la scansione delle vulnerabilità e che sia associato a qualcuno di definito. In questo modo quella persona potrà rendermene conto. Altra misura minima, e questa è banalissima, se vogliamo: assicurare che gli strumenti di scansione delle vulnerabilità siano regolarmente aggiornati con tutte le più rilevanti vulnerabilità di sicurezza. Non mi serve a niente prendere un sistema che però sia fermo alle vulnerabilità del 2008. Devo avere un sistema che ogni settimana aggiorni la lista delle vulnerabilità e quindi sia sempre in grado di scannerizzare in modo effettivo e buono quelle che sono le mie vulnerabilità. Volendo si può fare, ma chiaramente non è una cosa obbligatoria, registriamoci a un servizio che fornisca informazioni informazioni sulle nuove minacce e vulnerabilità. Esistono, son tool che ci sono, si trovano tranquillamente su Google. Non voglio fare pubblicità a nessuno, però ovviamente basta fare una ricerca per trovarne parecchi. Ci sono dei servizi che aggiornano ogni volta che viene scoperta una nuova vulnerabilità, e questa è una cosa che si può fare. Cioè, con un piccolo costo, anche solo annuale, mi registro a un servizio che mi avvisa: guarda, c'è una nuova vulnerabilità. Controllo che il mio sistema di scansione ce l'abbia già dentro, perché dovrebbe essere aggiornato, però controllo. E poi a quel punto faccio una scansione su quella vulnerabilità, controllo se ce l'ho anch'io. Sempre in tema di vulnerabilità, una volta che l'abbiamo scoperta, che cosa dobbiamo fare? Scopriamo che abbiamo dei sistemi vulnerabili, che cosa si fa? Misure minime: installiamo automaticamente gli aggiornamenti di sicurezza dei software, sia per il sistema operativo sia per le applicazioni. La metà, forse anche l'80% in realtà, degli aggiornamenti che arrivano sono aggiornamenti di sicurezza. Quando ricevete la notizia che è necessario installare un nuovo aggiornamento, è quasi sempre non perché hanno modificato effettivamente qualcosa, ma perché è stata scoperta una vulnerabilità e quell'aggiornamento la va a tappare. Quindi manteniamo aggiornati tutti i sistemi, assicuriamoci l'aggiornamento dei sistemi separati dalla rete, ok? Quindi se abbiamo qualche software, qualche servizio un po' a livello critico, che sono quelli appunto isolati dal resto o air-gapped, che cosa dobbiamo fare? Assicuriamo anche di questi, forse a maggior ragione di questi, l'aggiornamento dei sistemi. Continuiamo a mantenerli aggiornati adottando in misura adeguata al loro livello di criticità. Chiaramente, se scopriamo che c'è una vulnerabilità enorme e non esiste ancora un aggiornamento di sicurezza, valutiamo, se possibile, di sospendere il servizio finché non venga emanato questo aggiornamento di sicurezza. Torniamo un po' ai documenti. Verificare regolarmente che tutte le attività di scansione effettuate con gli account bla bla bla siano state eseguite secondo delle policy predefinite. Cioè, se possibile, facciamo proprio delle policy predefinite, delle procedure di come si deve fare una scansione, e controlliamo che tutte le attività di scansione siano effettuate seguendo queste procedure. Ovviamente verifichiamo se ci sono delle vulnerabilità, installiamo l'aggiornamento, e poi cosa dobbiamo fare? Verifichiamo che le vulnerabilità emerse dalle scansioni siano state risolte tramite quell'aggiornamento. Perché se mi rendo conto che l'aggiornamento in realtà ha risolto una vulnerabilità di cui magari non mi ero nemmeno reso conto e non ha risolto quella che avevo già notato, devo intervenire in qualche modo, anche sospendendo il servizio oppure implementando opportune contromisure o documentazione aumentando, accettando un ragionevole rischio. E qui c'è un concetto enorme che in realtà è un po' un tana libera a tutti, perché cos'è un ragionevole rischio? Allora, partiamo dal presupposto che il rischio si può mitigare ma mai eliminare, no? Io posso anche mettere le password super sicure, avere il firewall super top, avere la rete configurata alla perfezione, avere solo software perfettamente aggiornati, ma l'unico computer al sicuro è il computer spento, rotto, smontato con i pezzi uno qui, uno là. Non è possibile diminuire il rischio. Pensiamo un attimo a questo esempio qua. Se io attraverso la strada, posso minimizzare il rischio di essere investita guardando a destra e a sinistra prima di attraversare, ma non posso azzerarlo, perché ci può essere sempre il pazzo, o la luce non mi ha fatto vedere bene chi stava arrivando, o c'era una macchina in lontananza che però andava sparata. Quindi io non posso mai azzerare il rischio di essere investita. Il modo in cui posso azzerare il rischio di essere investita è stare a casa, ok? Nel momento in cui io esco di casa perché devo andare dall'altra parte strada e devo attraversare, guardo a destra, guardo a sinistra, accetto il rischio di essere investita e attraverso. Questo è, diciamo, l'accettazione del ragionevole rischio. Ho fatto tutto quello che potevo, più di così non posso fare, devo andare per forza dall'altra parte della strada, quindi accetto il rischio di essere investita. Mi capiterà una volta su un milione perché sono stata molto attenta, però può capitare, e questa è una cosa che va accettata. Chiaramente nel 2025, ma era già vero qui nel 2017, non si può pensare che un ente, un'azienda, non siano connessi a internet, non abbiano dei dispositivi. Quindi un minimo di rischio ce l'avranno sempre. Devono valutare, se emergono delle vulnerabilità non sanate, come comportarsi. Cioè, accetto che ci sia questa vulnerabilità e io non ho modo per sanarla, il servizio mi serve, continuo a usarlo. Chiaramente deve essere ragionevole il rischio, non deve essere una vulnerabilità enorme sfruttata già in tutti i comuni del circondario per un servizio che fondamentalmente a me non serve. Quello non è un ragionevole rischio, lì la cosa da fare è sospendere servizio. Ragionevole rischio è: viene attaccato un computer su un milione fra i computer che usano questo servizio qua, però è fondamentale, tiene sulle sue spalle tutto l'ente. Beh, allora accetto il rischio. Ovviamente anche qui il passo successivo qual è? Rivedere periodicamente l'accettazione dei rischi. Cioè, nel momento in cui mi rendo conto che comunque magari una vulnerabilità è stata sanata dopo, allora non posso più dire accetto il rischio di tenermi la vulnerabilità, faccio l'aggiornamento e il rischio è ulteriormente diminuito. Questo, misura, come vedete è molto lunga. Siamo ancora nella fase delle vulnerabilità. Altre due misure minime: definire un piano di gestione dei rischi che tenga conto dei livelli di gravità delle vulnerabilità, del potenziale impatto e della tipologia degli apparati. E qui è un po'— mi ricollego a quello che ho detto prima, no? Se dobbiamo accettare un rischio, è una cosa che dobbiamo documentare. Dove la documentiamo? In un piano di gestione dei rischi che tenga conto di tutte queste cose qua. Non ci fermiamo qua, ma definiamo anche delle azioni per risolvere queste vulnerabilità. E queste azioni devono avere un livello di priorità, no? Ovviamente dice in particolare applichiamo le patch, quindi gli aggiornamenti di sicurezza per le vulnerabilità, a partire da quelle più critiche, perché l'aggiornamento di sicurezza è la cosa più facile da fare e le vulnerabilità più critiche sono quelle più pericolose. Quindi questa dovrebbe avere una priorità molto alta. Prevedere in caso di nuove vulnerabilità delle misure alternative se non sono immediatamente disponibili patch o se i tempi di distribuzione non sono compatibili. E qui diciamo lascia molto la palla all'ente, all'azienda, cosa che sono misure alternative se non sono immediatamente disponibili delle patch. Non so, ad esempio implemento appunto un air gap, isolo quel servizio, faccio in modo che anche se fosse una porta d'accesso per dei malintenzionati rimanga isolata e faccia meno danni possibili. Però lascia appunto un po' la scelta in capo all'ente, all'azienda. Valutare in un opportuno ambiente di test— e qui siamo ancora nelle misure standard, pensavo fossimo già nelle avanzate, in realtà— valutiamo in un opportuno ambiente di test le patch prodotti non standard prima di installarle, perché a volte le patch hanno a loro volta dei bug, dei malfunzionamenti. Quindi prima mettiamole in ambiente di test. Ad esempio, ho il software su tutti i computer, non proverò la patch che va a sistemare la vulnerabilità sul computer centrale. Crea un ambiente protetto in cui provare la patch, verifico che il sistema funzioni regolarmente. Arriviamo alla misura numero 5: uso appropriato dei privilegi di amministratore. Come dicevo, questa è una parte fondamentale. Dobbiamo capire bene chi chi è che ha i privilegi di amministratore, perché più una persona è in alto a livello di dispositivi, no, quindi ha più privilegi degli altri, più sarà ghiotta l'occasione per gli hacker di andare proprio su quell'account lì, perché l'account che può fare tutto. Ora, non tutte le persone devono poter fare tutto, è molto importante questo. Normalmente si danno i privilegi di amministrazione agli utenti, come dice qua, che abbiano le competenze adeguate e la necessità operativa di modificare la configurazione dei sistemi. Di chi si parla? Parla delle ditte di manutenzione, se hanno un rapporto molto stretto con l'ente, del CED, del reparto IT, dell'amministratore di sistema. Tutte queste figure qui che hanno una concreta necessità. Non serve che Francesca Rossi, che lavora nel reparto anagrafe e prende le carte di identità dei cittadini, abbia dei privilegi di amministratore. Non serve proprio. Utilizziamo le utenze amministrative solo per operazioni che ne richiedono i privilegi, perché tutte le cose in realtà si possono fare cliccando col destro, no, esegui come amministratore. Ma non serve, si fanno queste cose solo per quello che è strettamente necessario, ad esempio installare una patch di sistema, modificare qualcosa nel computer, documentando tutto. Ogni accesso effettuato va registrato. E questo è un po' un corollario, in realtà lo mette come misura standard, secondo me dovrebbe essere una misura minima anche questa. Assegniamo a ciascun utenza solo i privilegi necessari per svolgere le attività previste per essa. Non c'è bisogno, ad esempio, che la bibliotecaria veda i filmati di videosorveglianza che sono nel comando di polizia locale. È una cosa che non ha senso. Dobbiamo fare in modo che ciascuno, a seconda della funzione, veda quello che deve vedere e nulla di più. Registriamo le azioni compiute da un'utenza amministrativa e rileviamo ogni anomalia di comportamento. Questa addirittura è avanzata, bisogna essere un po' più skillati, diciamo. Ancora, documentiamo, documentiamo, documentiamo. Manteniamo un inventario di tutte le utenze amministrative, quindi tutti gli utenti che hanno dei privilegi di amministratore, garantendo che ciascuna sia debitamente formalmente autorizzata. In questo modo, se ne viene fuori una che io non mi aspettavo, capisco che c'è qualcuno che sta cercando di fare un escalation, dove l'escalation è una tecnica di attacco in cui parto da un account che ha pochi privilegi e piano piano arrivo sempre più in alto per fare in modo di arrivare a essere un account amministrativo. E giustamente, come misura standard, cosa dice? Cerchiamo uno strumento automatico che ci levi appunto da solo ogni volta che c'è una variazione nella definizione dei privilegi amministrativi. Quindi non basta tenere un inventario, bisogna anche tenerlo aggiornato. E la cosa migliore è avere uno strumento automatico che ci segnali in automatico: guarda che Francesca Rossi adesso è un utente amministrativo, c'è qualcosa che non va, controlla. Prima di collegare alla rete un nuovo dispositivo, sostituire le credenziali dell'amministratore predefinito con valori coerenti con quelle delle utenze amministrative in uso. Sembra una cosa difficile, ma in realtà è molto banale. Quando noi ad esempio compriamo, non so, una nuova stampante, arriva con delle credenziali predefinite. Molto spesso sono banali. Una delle cose più facili per un attaccante è provare a entrare sfruttando proprio i valori di default di una stampante, di un computer, di un dispositivo in generale, no? Quindi se io ho una stampante che ha come utente admin e come password admin, la prima cosa che devo fare è cambiare le credenziali. Metto esempio Ente Cervignano del Friuli come admin e come password una password super difficile e complessa. È la prima cosa da fare, perché altrimenti io vado a mettere all'interno della rete un dispositivo di cui le credenziali potrebbero essere già note, ed è molto pericoloso. Tracciamo nei log l'aggiunta o la soppressione di un'utenza amministrativa. Questo più o meno è già collegato al discorso dell'inventario, ma qui dice proprio lo mettiamo nei log. Cioè, non basta avere un inventario che dice questo era amministratore, ora non lo è più, ma dobbiamo avere la cronologia quello che è successo. Come possiamo fare ad accorgercene? Generiamo un alert quando viene aggiunta un'utenza amministrativa, facciamo in modo che ci sia un sistema che ci avvisa. Oppure generiamo un alert quando vengono aumentati i diritti di un'utenza amministrativa, è collegato a quello precedente, nuova utenza oppure utenza già esistente a cui vengono aumentati i privilegi. Sono due cose che permettono di fare questa cosa qui, no? Tracciare nei log l'aggiunta, la soppressione di un'utenza amministrativa. Lo faccio tramite gli alert che mi arrivano. E un'altra cosa importante che viene sottovalutata è questa: tracciare nei log i tentativi falliti di accesso con un'utenza amministrativa. Perché vuol dire che c'è qualcuno che sta cercando di entrare, e sta cercando di entrare non passando dall'utente X, ma passando da un utente che abbia dei privilegi molto alti. Quindi tracciamo nei log i tentativi falliti, capiamo che c'è qualcosa che non va, qualcuno sta provando a entrare. Misura avanzata: utilizziamo sistemi di autenticazione a più fattori per tutti gli accessi amministrativi. Secondo me questa misura è un po' figlia del suo tempo. Nel 2017 sembrava una cosa avanzata. Oggi credo che dovrebbe essere praticamente la norma. Non dico magari rientrare nelle misure minime, mi rendo conto che non sia facilissimo per tutti, ma in quelle standard sì. Invece qua viene considerata proprio una cosa avanzata. L'autenticazione a più fattori può utilizzare diverse tecnologie, quindi smart card, certificati digitali, eccetera eccetera eccetera. Se non è supportata l'autenticazione a più fattori, cosa facciamo? Utilizziamo credenziali di elevata robustezza, almeno 14 caratteri. Diciamo che non è che 14 caratteri ci salvino la vita. Ovviamente la cosa migliore sarebbe 14 caratteri con determinati requisiti, come almeno una lettera maiuscola, una minuscola, un numero, un simbolo e così via. Meglio ancora se casuali, generate casualmente e salvate da qualche parte di sicuro. Diciamo che questa cosa non è una misura minima, è proprio una misura meno che minima, ecco. Perché se poi come password metto Francesca Rossi, non sono sicuramente al sicuro. Impedire che per l'utenza amministrativa vengano utilizzate credenziali deboli. E anche qui siamo in una misura standard che oggi sicuramente è minima, non si può considerare più standard. È una cosa che deve essere assolutamente implementata. Non posso pensare che un'utenza amministrativa abbia la password Pippo22, deve avere una password forte. Assicuriamoci che vengano sostituite con sufficiente frequenza, password aging, perché le password possono avere un'età, possono invecchiare, e quindi la cosa migliore è cambiarle di frequente. In realtà adesso stessa cosa è un po' in fase di superamento, perché si è visto che è meglio una singola password molto forte che cambiare password di continuo mettendo vacanza 2024, vacanza 2025, vacanza 2026, come fanno moltissime persone. Se io costringo le persone a cambiarle più frequentemente, chiaramente metteranno password più facili da ricordare, o metteranno la vecchia password ma con una singola cosa cambiata. Cambiarle spesso sì, ma mantenendo comunque dei requisiti di robustezza minimi. Fra le due cose direi che è quasi meglio cambiarle una volta in meno, ma obbligarli a usare password particolarmente forti. Impedire che credenziali già utilizzate possano essere riutilizzate a breve distanza di tempo, altrimenti cosa si rischia? Che da vacanze 2024 passo a vacanze 2025, quando mi dicono che la devo cambiare torno a vacanze 2024, e quindi chiaramente non ha molto senso. Assicuriamoci che dopo la modifica delle credenziali trascorra un sufficiente lasso di tempo per poterne effettuare una nuova, perché altrimenti il rischio, ovviamente anche qua, è che un malintenzionato mandi una richiesta di reset della password. In realtà questo lo vedo un po' difficoltoso, ma per un semplice motivo: se obbligo le persone ad avere password difficili, se gli dico che la password non deve essere vacanza2024, metteranno una password complicata, ci sta che se la dimentichino subito dopo. Quindi questa cosa mi sembra un po' complicata, diciamo, da implementare nell'ottica di tutto. Assicurare che le stesse credenziali non possono essere riutilizzate prima di 6 mesi, diciamo che la ripetizione di questo qua, Password History, però dice proprio un termine minimo di 6 mesi. Questo invece mi piace molto: non consentire l'accesso diretto ai sistemi con le utenze amministrative. Gli amministratori devono accedere con utenza normale e poi eventualmente, e solo se ce n'è bisogno, eseguire come utente privilegiato i singoli comandi. Non devo avere la possibilità di fare tutto in automatico come amministratore. Semplicemente io mi comporto come utente normale, nel momento in cui ho necessità di fare un'operazione per cui mi serve il privilegio un po' più alto, allora in quel momento userò i miei privilegi, ma non di default. Per le operazioni che richiedono privilegi, gli amministratori devono usare macchine dedicate collocate su una rete logicamente dedicata, isolata, bla bla bla. E questo, ok, più o meno bene o male è una ripetizione di quello che abbiamo già detto. Cerco di andare un pelo più veloce perché altrimenti stiamo qua fino a dopodomani e non ha molto senso. Assicuriamo la completa distinzione fra le utenze privilegiate e non privilegiate degli amministratori, alle quali devono corrispondere credenziali diverse. E questo è interessante, cioè gli amministratori non è detto che debbano avere un'utenza privilegiata di default e in automatico. La cosa migliore sarebbe avere un'utenza non privilegiata e fare le singole cose appunto come privilegiato. Però la cosa migliore è avere credenziali diverse per fare queste cose qua, in modo che se anche un malintenzionato prende accesso all'account amministratore non possa fare le cose previste solo per le utenze privilegiate perché non ha questa password che è diversa da quella che lui ha in mano, che è quella dell'utente utenza non privilegiata. Tutte le utenze, in particolare quelle amministrative, devono essere nominative, riconducibili da una sola persona, altrimenti ovviamente si fa confusione, non si capisce chi ha fatto cosa. Le utenze amministrative anonime, come root per Unix o Administrator di Windows, devono essere utilizzate solo per le situazioni di emergenza, perché queste chiaramente non sono ricollegabili a qualcuno di specifico. Le relative credenziali devono essere gestite in modo da assicurare l'imputabilità di chi ne fa uso. Dobbiamo capire ad esempio che solo Mario Brambilla che può usare l'account root. Ok, in questo modo sappiamo che se qualcuno usa l'account root o è lui o è un malintenzionato, ma almeno riusciamo a capirlo. Evitiamo l'uso di utenze amministrative locali per le macchine se sono disponibili utenze amministrative di livello più alto. Questa è un po' più complicata, non mi ci dilungo. Sostanzialmente quello che si intende è: se abbiamo un dominio, quindi qualcosa di più alto. Non usiamo le utenze amministrative presenti sul singolo computer, colleghiamoci con le utenze amministrative del dominio. Ma questa è una cosa un po' più complicata, tant'è che è una misura non minima ma standard. Conserviamo le credenziali amministrative in modo che siano disponibili e riservate, e questo direi che ci siamo tutti. Se per l'autenticazione usiamo certificati digitali, ad esempio una chiavetta con l'impronta digitale, garantiamo che rimangano adeguatamente protette, e su questo direi di sì. Se per l'autenticazione utilizziamo certificati digitali, anche questi vanno protetti, e direi che anche su questo ci siamo tutti. Arriviamo alle difese contro i malware, la misura numero 8: installare su tutti i sistemi connessi alla rete locale degli strumenti che rilevino la presenza o l'esecuzione di malware. Banalmente, tutti devono avere un antivirus aggiornato in modo automatico per rilevare nuovi malware e per non avere falle e vulnerabilità loro stessi. Installare su tutti i dispositivi firewall e IPS personali. IPS sta per intrusion preventing system, cioè sistemi che servono proprio a prevenire le intrusioni. Gli eventi rilevati dagli strumenti, ma qui diventa già una misura un po' più alta, devono essere inviati a un repository centrale. Quindi dobbiamo capire tutto quello che viene rilevato dall'IPS, dobbiamo fare in modo che vada su questo repository centrale. Tutti questi strumenti devono essere monitorati e gestiti centralmente. Non può essere che Francesca Rossi, che si collega computer modifica il suo IPS, modifica il firewall o modifica altre cose. È possibile forzare manualmente dalla console centrale l'aggiornamento dei sistemi anti-malware, quindi dobbiamo fare in modo che non sia rimesso al singolo utente, diciamo, l'onere di andare ad aggiornare il proprio anti-malware, ma deve essere una cosa che si può fare a livello centrale. Il reparto IT deve poterlo fare per tutti. L'analisi dei potenziali malware deve essere effettuata su un'infrastruttura dedicata, meglio se sul cloud. Cosa vuol dire questo? Ho un file sospetto, cosa faccio? Lo apro sul computer? No, cerco di aprirlo in un ambiente protetto, meglio se un'infrastruttura dedicata, perché così se è un malware non fa danni nel resto del sistema. Se non lo è, tanto meglio, poi lo sposto nel resto della rete. Limitiamo l'uso di dispositivi esterni a quelli necessari per le attività aziendali. E questo direi che è abbastanza banale. I dispositivi esterni, e si intende tutto, si intende altri computer, si intendono USB, eccetera, solo quelli necessari, niente di più. Monitoriamo l'uso e i tentativi di utilizzo di dispositivi esterni. C'è qualcosa che non va? C'è un dipendente che magari è un po', non so, non mi fido, è un po' sospetto? Ecco, va monitorato. Abilitiamo delle funzioni che possano contrastare lo sfruttamento delle vulnerabilità. E anche questi, diciamo, sono cose un po' più specifiche, sono strumenti che esistono. Quindi dice implementate questi strumenti che servono appunto a evitare che le vulnerabilità possano essere sfruttate, oppure in generale che si diffondano dei dei malware. Installiamo degli strumenti aggiuntivi, ad esempio quelli forniti come optional dai produttori di sistemi operativi. Quindi, ad esempio, non so, Windows prevede un nuovo sistema che evita che vengano sfruttate le vulnerabilità, magari lo attivo. Usare strumenti che filtrino il traffico per fare in modo che il codice malevolo sia bloccato prima di raggiungere la rete. Anche questa è una cosa molto importante: il traffico va monitorato. Se c'è un pacchetto strano che potrebbe essere qualcosa di scaricato ma per sbaglio, o comunque è un file sospetto, devo bloccarlo prima, possibilmente con sistemi di analisi avanzata del software sospetto, così capisco subito che cos'è, non ho bisogno di aprirlo. Monitoriamo, analizziamo e blocchiamo, se c'è bisogno, gli accessi a indirizzi che abbiano una cattiva reputazione, siti non sicuri, siti HTTP e non HTTPS, e così via. E qui arrivano una serie di misure tutte minime, quindi tutte da implementare. Disattiviamo l'esecuzione automatica dei contenuti al momento della connessione dei dispositivi removibili. Ci sono delle opzioni che si possono appunto disattivare, per cui quando io inserisco la chiavetta automaticamente quello che c'è nella chiavetta viene eseguito. Disattiviamo questa cosa, deve essere tutto attentamente valutato da un essere umano. Disattiviamo l'esecuzione automatica dei macro presenti nei file. Anche questa è una cosa un po' specifica, però un malware potrebbe essere incluso anche all'interno di un PDF tramite macro, appunto contenuti dinamici. Quindi che cosa devo fare io fare in modo che non si attivi automaticamente. La macro si attiva se a me serve, dico che si deve attivare. Disattiviamo l'apertura automatica dei messaggi di posta elettronica, anche questo perché magari una mail è di phishing, anche se in realtà ci sono veramente pochi client che adesso aprono automaticamente la mail. Disattiviamo l'anteprima automatica dei contenuti dei file. Sostanzialmente qua, se vedete, siamo in una linea molto chiara: deve esserci sempre un'azione umana alla base. Dobbiamo evitare che ci siano cose automatiche, perché altrimenti anche il dipendente dipendente attento non può farci nulla. Se c'è una mail che il dipendente attento avrebbe riconosciuto come mail di phishing, ma si apre in automatico, scarica in automatico della roba, non va bene. Eseguiamo automaticamente delle scansioni antimalware dei supporti rimovibili al momento della connessione. Metto una chiavetta, prima di avviarla scansione antimalware. Filtriamo il contenuto dei messaggi di posta prima che raggiungano la casella del destinatario, quindi ad esempio strumenti antispam o anti-phishing. Filtriamo il contenuto del traffico web, ci sono tantissimi strumenti per farlo. Facciamo in modo che il traffico sia sicuro, blocchiamo ad esempio i siti non protetti, blocchiamo nella posta elettronica e nel traffico web i file la cui tipologia non è strettamente necessaria per l'organizzazione, potrebbe essere pericolosa. Ad esempio .cab, non si può bloccare il .pdf ad esempio, ma ci sono delle estensioni che probabilmente a un ente non servono, quindi facciamo in modo che vengano bloccati. Molti bloccano anche i file .zip, perché spesso nei file zip viene nascosto un malware. Credo che non sia un'alternativa praticabile, è molto comune che vengano zippate le cartelle che vengono inviate, per cui penso che sia difficile. Utilizziamo strumenti antimalware che sfruttino non solo le firme— la firma è l'identificativo del malware ed è una cosa che ovviamente funziona se un malware è già stato appunto identificato e la sua firma è stata associata a un file sospetto— ma usiamo antimalware che usino tecniche di rilevazione basate sulle anomalie di comportamento comportamento. È normale che un PDF mi apra una cartella, mi faccia— probabilmente no. Quindi questa è un'anomalia di comportamento che deve essere rilevata dall'antimalware. Implementiamo una procedura di risposta agli incidenti che preveda la trasmissione al provider di sicurezza dei campioni di software sospetto per la generazione di firme personalizzate. E anche qui questa è una cosa molto tecnica. Banalmente quello che viene detto è: dobbiamo fare in modo che vengano trasmessi in automatico al provider di sicurezza i campioni di software se pensiamo che possano essere dei malware. Andiamo avanti, mancano solo gli ultimi due controlli che sono il numero 10, copie di sicurezza, e poi il numero 13. Numero 10: procedure e strumenti necessari per produrre e mantenere copie di sicurezza. Banalmente stiamo parlando dei backup, ok? Effettuare almeno settimanalmente una copia di sicurezza, almeno delle informazioni strettamente necessarie. Qui è tagliato, ma è per il completo ripristino del sistema. Per assicurare la capacità di recupero di un sistema da proprio backup, le procedure di backup devono riguardare il sistema operativo, le applicazioni software e la parte dati. Anche questa frase non c'è, non so perché è venuta così questa qui. Qui banalmente stiamo parlando del fatto che le procedure non devono riguardare solo il faccio il backup, ma anche il dal backup riesco a ripristinare il sistema. Effettuare backup multipli con strumenti diversi per contrastare possibili malfunzionamenti. E questo è abbastanza banale. Se io faccio un solo backup e quel backup si rompe, o non l'ho impostato bene, o ha qualsiasi altro problema, io sono fregato. Quindi che cosa faccio? Ne faccio almeno 2. Verificare periodicamente l'utilizzabilità delle copie, cioè non mi basta dire: ah sì, ho il backup, è lì da 5 anni, lo fa settimanalmente, sono a posto. Devo controllare che quello che fa siano copie che io posso usare. Assicuriamoci la riservatezza delle informazioni contenute nei backup mediante adeguata protezione fisica dei supporti o mediante cifratura. Cifriamo i dati di backup perché altrimenti una persona che mette le mani sul backup, mettere mani su tutto il sistema. Ed è una cosa ovviamente gravissima. La frase che qui manca riguarda il fatto che se faccio la codifica prima della trasmissione del backup, posso anche valutare di usare backup in cloud. Quindi io imposto un sistema per cui nel momento in cui il backup viene effettuato viene già cifrato e poi viene conservato in cloud. Visto che comunque bisognerebbe sempre avere un backup fisico e uno in cloud, almeno questa è una cosa che devo fare, devo codificarli prima. Anche qui abbiamo una cosa un po' specifica Specifica ma molto utile: assicuriamoci che i supporti contenenti almeno una delle copie non siano permanentemente accessibili dal sistema, per evitare che attacchi su questi possano poi influire su tutte le altre copie. Perché banalmente, se io tengo tutti i backup in locale, tutti i backup collegati al sistema, se metto le mani su un backup metto le mani su tutti e non ci sarà modo, se ad esempio vengo colpito da un ransomware, di recuperare i miei dati. Ne tengo almeno uno non accessibile. Arriviamo all'ultima misura: la protezione dei dati. Effettuiamo analisi dei dati per individuare quelli con particolari requisiti di riservatezza. Devo stare più attento ai dati sensibili dei cittadini, dei clienti e così via, e valutare anche eventualmente la crittografia di questi dati. Devo fare in modo che siano più al sicuro. Utilizziamo sistemi di cifratura per i dispositivi portatili e i sistemi che contengono informazioni rilevanti. Forse lo metterei anche su tutto, ma capisco che magari questo possa rallentare un po' il sistema o rendere più complicato poi l'accesso ai file. Però almeno quelli che contengono dati più rilevanti, ecco, ricifriamoli. Utilizziamo nella rete strumenti automatici che blocchino, limitino oppure monitorino in maniera puntuale l'impiego di crittografia non autorizzata, oppure l'accesso ai siti che consentono lo scambio o le sfiltrazioni di informazioni. Anche qui banalmente, non devo stare attento solo a quello che entra ma anche a quello che potrebbe uscire, o che impieghi crittografia non autorizzata. Perché ribadisco, ad esempio il ransomware consiste proprio in questo: io prendo prendo un backup che magari so che è l'unico backup del sistema, lo cifro tutto e dico che gli do la chiave per decifrarlo solo se pagano il riscatto. Effettuiamo poi periodiche scansioni attraverso sistemi automatizzati in grado di rilevare sui server la presenza di specifici data pattern, quindi per evidenziare l'esistenza di dati rilevanti in chiaro. Questa è una misura avanzata, lo vedo dalla A che c'è qua in fondo. Qui è un monito per l'amministrazione a cui viene detto: attenta a quello che metti in chiaro. Veniamo alle ultimissime massime misure. Nel caso in cui non sia strettamente necessario l'utilizzo di dispositivi esterni, facciamo in modo che sia impedita la scrittura su questi dispositivi. Perché, ad esempio, se io non ho strettamente bisogno di avere una chiavetta USB che si collega a un PC e gli si può copiare tutto dentro, perché dovrei averla? Perché dovrei permettere questa cosa? Il rischio è che una persona infili la chiavetta, copi dei gran dati e li rubi, li porti via. Quindi meglio evitare. Utilizziamo strumenti software centralizzati che gestiscano il collegamento alle workstation o server in locale solo dei dispositivi esterni autorizzati, ad esempio in base al numero seriale, cifrando comunque i dati. Teniamo aggiornata la lista dei dispositivi, quindi anche qui autorizziamo, documentiamo, autorizziamo, documentiamo. Implementare strumenti di data loss prevention, quindi di prevenzione per la perdita dei dati, per monitorare e controllare i flussi di dati all'interno della rete, in modo da rilevare subito se ci sono delle anomalie. E anche questo abbastanza in linea con tutto quello che abbiamo detto finora. Qualsiasi anomalia, cosa deve essere fatto? Documentazione. Ogni anomalia deve essere registrata, devo analizzarla, devo capire cosa c'è che non va. Questa fra l'altro è una misura avanzata. Io forse non dico che l'avrei messa come misura minima, ma quantomeno come standard. Monitoro il traffico e registro le anomalie, altrimenti monitorare il traffico non mi serve a nulla. Monitoriamo il traffico che esce rilevando le connessioni applicazioni che usano la crittografia senza che ciò sia previsto. Perché banalmente la crittografia si usa anche per proteggere i malintenzionati. Per cui se c'è un sistema che non dovrebbe usare la crittografia e che la usa, devo preoccuparmi un pochettino. Blocchiamo il traffico da e verso URL presenti in una blacklist. Se ho bloccato determinati link, determinati siti, indirizzi e così via, devo bloccare anche il traffico che porta quei siti. Assicuriamoci che la copia di un file fatta in modo autorizzato mantenga le limitazioni di dell'accesso della sorgente. Quindi evitiamo che un file che aveva determinati accessi venga copiato in un altro file che ha molti più accessi. E questa cosa deve essere mantenuta anche quando i dati sono trasferiti al di fuori di dove erano originariamente conservati. Bene, allora, tantissima roba. Fra l'altro, non so chi di voi ha seguito anche la prima parte o se avete seguito solo la seconda, però direi che comunque abbiamo messo parecchia carne sul fuoco. Questa è veramente una bibbia di tutto quello che dovrebbe essere fatto come misura basilare per partire. Parlo delle misure minime, ma parlo anche, volendo, delle misure standard avanzate, perché abbiamo visto in un po' di occasioni che comunque quello che era avanzato nel 2017 oggi è quasi considerabile minimo o comunque standard. Bene, come sempre spero che questo video vi sia piaciuto. Fatemi sapere nei commenti cosa pensate di queste misure, se le ritenete ragionevoli, se sono troppo, troppo poco, quello che ne pensate in generale. È sempre bello fare un po' di scambi su queste cose qua, anche perché sono comunque cose che ci vengono imposte, per cui c'è poco che possiamo fare. Però è sempre bello parlarne. Noi ci vediamo al prossimo video.