In Italia, informaticamente parlando (ma anche sotto altri aspetti), tutto (il peggio) è possibile: anche che la Giurisprudenza debba ribadire l’ovvio, lo scontato, il lapalissiano, esattamente come il titolo di questo articolo. Dovrebbe essere una verità inequivocabilmente scontata e palese per tutti, ma evidentemente non lo è se una sentenza della Suprema Corte (sent. n. 50205) ha confermato la condanna penale di un dirigente che aveva utilizzato le credenziali di accesso di un suo “sottoposto” per accedere al sistema informatico aziendale.
🔑 i FATTI: – il dirigente si era fatto comunicare le credenziali di un collaboratore – aveva utilizzato queste credenziali per accedere a circa 90.000 schede individuali – riteneva (a torto) che la sua posizione gerarchica lo legittimasse a tale comportamento
⚠️ PRINCIPIO stabilito dalla Suprema Corte: – La posizione di superiore gerarchico NON autorizza l’accesso ai dati tramite credenziali altrui: questo comportamento integra il reato di ACCESSO ABUSIVO a SISTEMA INFORMATICO (art. 615-ter c.p.)
📋 CONSEGUENZE PRATICHE per AZIENDE e ORGANIZZAZIONI: – Ogni dipendente deve avere CREDENZIALI PERSONALI e non cedibili; – Le DELEGHE di ACCESSO devono essere espressamente AUTORIZZATE; – Va implementato un SISTEMA di PROFILAZIONE UTENTI con diversi LIVELLI di AUTORIZZAZIONE; – Occorre una POLICY AZIENDALE chiara sulla GESTIONE delle CREDENZIALI; – Rischio di responsabilità penale per i TRASGRESSORI.
💡 AZIONI da intraprendere: – Revisione tempestiva delle policy di accesso ai sistemi ICT; – Implementazione di protocolli di sicurezza informatica (AUTENTICAZIONE, PROFILAZIONE, AUTORIZZAZIONE e PROTEZIONE) adeguati; – Formazione specifica del personale; – Vulnerability Assessment e Audit dei sistemi; – Adeguamento dei modelli organizzativi al GDPR.
Come ripeto spesso ai miei studenti e contatti professionali, la sentenza (una delle tante) sottolinea come la Cybersecurity non sia solo una questione tecnica, ma anche legale, con rilevanti profili di responsabilità penale (a questo indirizzo, chi fosse interessato può reperire e leggere la sentenza con calma)
Durante una visita ospedaliera fuori regione, annoiato tra un’attesa e l’altra, attraverso alcune scansioni di rete ho riscontrato una preoccupante malagestione nella rete Wi-Fi del policlinico. La segmentazione delle reti, che generalmente dovrebbe garantire un isolamento dei dispositivi interni da quelli esterni, risultava inadeguata: ho riscontrato che dispositivi di norma riservati al personale ospedaliero, come stampanti con firmware non aggiornato nonché fileserver, erano accessibili dalla rete Guest (tipicamente la rete WLAN dedicata alle utenze dei visitatori e pazienti di una struttura ospedaliera) semplicemente variando la subnet mask sul mio scanner di rete. Questo scenario rappresenta un rischio per la sicurezza informatica della rete ospedaliera, poiché l’assenza o la carenza di una efficace segregazione tra le reti pubbliche e quelle interne può esporre l’infrastruttura ospedaliera ad attacchi informatici.
In un contesto come quello sanitario, dove le reti informatiche sono già di per sé un’infrastruttura critica, trascurare la Cybersecurity può avere conseguenze ragguardevoli. Dispositivi non aggiornati o direttamente vulnerabili possono diventare una facile preda per attacchi ransomware, che possono compromettere la continuità dei servizi essenziali, mettendo a rischio la sicurezza fisica dei pazienti nonché le capacità operative dell’ospedale.
Le immagini qui sopra fanno riferimento a delle stampanti in rete: ma cosa succederebbe se gli attacker prendessero di mira i PLC usati dall’ospedale, che pure erano raggiungibili attraverso la medesima sottorete delle stampanti? (e che per carità divina ho evitato di postare!)
Mandiant ha recentemente rilasciato CAPA Explorer, una GUI (un’interfaccia grafica) per esplorare i risultati estratti da CAPA.
CAPA è un software FOSS utilizzato per velocizzare il processo di identificazione delle capacità di possibili malware, mappandole avvalendosi delle matrici MITRE ATT&CK e MBC 🔍
L’aspetto interessante è che adesso è possibile analizzare e scorrere tra i risultati usando appunto una comoda interfaccia grafica! 🖥️
CAPA, a sua volta, utilizza un insieme di regole per riconoscere i comportamenti specifici (pattern o capability) di un programma eseguibile. Le regole, che possono anche essere personalizzate dall’analista, descrivono azioni tipiche dei malware come (ad esempio): – capacità (capability) di comunicazione con un server esterno: questo potrebbe indicare che il malware sta cercando di inviare dati rubati o di ricevere nuove istruzioni. – capacità (capability) di cifrare o decifrare dati: la crittografia viene spesso utilizzata dai malware per occultare le proprie attività o per azioni estorsive (ransomware) – capacità (capability) di modificare il registro di sistema: moltissimi malware modificano il Registry di Windows per rimanere persistenti nel sistema o per disabilitare le difese di sicurezza. – Capacità (capability) di eseguire codice arbitrario: la capacità più insidiosa a fronte di un’infezione, in quanto permette al malware di eseguire qualsiasi azione sul sistema infetto, come se fosse eseguita da un sysadmin.
Un esempio dell’utilizzo di capa applicato ad un eseguibile
Concludendo, se come me ti occupi di Cybersecurity dovresti quantomeno valutare il suo utilizzo poiché: -> velocizza il processo di analisi dei malware: CAPA può analizzare rapidamente un gran numero di campioni di malware, identificando le loro funzionalità principali, ergo aiutando gli analisti InfoSec a concentrarsi sulle parti più insidiose del malware in esame -> facilita la condivisione delle informazioni: CAPA utilizza un formato di regole condivisibili, che permette alla comunità di ricercatori di malware e agli analisti di collaborare e di creare un database sempre più ricco di comportamenti e pattern malevoli -> è integrabile con i più diffusi software di reverse engineering (Ghidra, IDA, Binary Ninja)
Un esempio di utilizzo della GUI di CAPA, CAPA Explorer, applicato ad un malware per architetture x64
Prossimamente (data da destinarsi), un paio di post integrativi al presente articolo su: -> come creare regole in CAPA -> come integrare CAPA in un workflow di analisi malware
Certo, i confini e le proporzioni delineate nel grafico a torta in basso non sono e continueranno a non essere mai così nette e definite in nessuna organizzazione, ma globalmente questa infografica delinea a grandi linee il bias cognitivo di molta gente a proposito di ciò che si pensa sia dietro la sigla CYBERSECURITY (vero e proprio Leitmotiv professionale dei nostri tempi), rispetto alle problematiche attuali di cui la CYBERSECURITY è realmente costituita… ed appunto, il grafico in basso è indubbiamente una rappresentazione del settore meno sbrigativa e meno superficiale rispetto a quella illustrata nel primo grafico, ossia da quelle ipocrite rappresentazioni con cui il mainstream continua a beffare tantissimi non addetti ai lavori.
C’è gente che continua ad usare i propri dati personali come password…che è quasi come prestare le proprie chiavi di casa o d’ufficio ad un hacker: praticamente un invito aperto a un incidente informatico.
Passlord, ad esempio, è un software progettato per generare un ampio elenco di password su misura per singoli account, incorporando al contempo dati personali nell’algoritmo di generazione. Con Passlord è possibile generare con il minimo sforzo migliaia di password univoche, ciascuna contenente informazioni personalizzate al fine di dare vita a un dizionario cucito ad-hoc per il target (ogni password conterrà qualche riferimento ai dati personali del soggetto, come sottostringhe della data di nascita e/o del cognome e/o del nome del soggetto ecc..).
Tutti i moduli utilizzati dal programma fanno parte della Python Standard Library. Sono forniti in bundle con Python stesso, quindi non c’è neanche bisogno di installarli separatamente.
Superfluo scrivere che se il target ha scelto come password proprio una delle combinazioni generate da Passlord, salvo meccanismi di hardening da parte del sistema o del servizio, l’accesso abusivo all’archivio o al sistema target sarà solo questione di tempo.
A tratti unpopular opinion, ma fondamentalmente biasimo da nostalgico della disciplina che insegno da tempo e che continuo a praticare sia con vecchie che con nuove infastrutture informatiche, virtualizzate e non: l’amministrazione dei sistemi ICT, pane quotidiano di tutti i veri sysadmin.
Francamente penso che il mercato dell’Informatica da una parte si stia assuefacendo all’Automazione dei sistemi finalizzata alla riduzione dei costi (DevOps), dall’altra parte stia perdendo di vista il Santo Graal di tutti i sistemi informatici: la Disponibilità.
L’Automazione può rendere i sistemi più veloci ed economici riducendo l’elemento umano, ma un’operazione critica come quella di aggiornare un componente fortemente (troppo?) integrato nel sistema operativo andrebbe supervisionata: il recente disastro informatico legato al BSOD provocato da Falcon – l’agent software commercializzato dalla nota azienda CrowdStrike – è infatti la dimostrazione che anche i più blasonati operatori del settore commettono errori e possono provocare devastanti incidenti informatici, e almeno per ora, francamente non vedo un orizzonte rassicurante nemmeno per un futuro prossimo: non possono infatti testare alla perfezione ogni rilascio, per ogni possibile target, per ogni intricato scenario di utilizzo variabile (da più di qualche anno, ormai, ci si sono messi in mezzo sia il Cloud che il mondo IoT con i suoi firmware personalizzati spesso Insecure by Default).
La soluzione non è ovviamente quella di aspettare che i sistemisti abbiano il tempo di applicare gli aggiornamenti a mano, ma definire preventivamente procedure chiare e testate, e avere in squadra persone che sappiano eseguirle nei tempi e modi opportuni: cioè tempestivamente, ma non alla cieca. Ci devono essere precise fasi di STAGING ed esperti (ossia figure senior)che possano bloccare il passaggio in produzione prima che avvengano danni gravi…come quelli provocati da CrowdStrike.
Costoso? Ovviamente… e invece bloccare inaspettatamente voli intercontinentali e banche di mezzo mondo non ha avuto alcun impatto?
Obsoleto pensare a interventi manuali? Già, proprio come quelli che sono stati necessari per ripristinare i sistemi coinvolti, secondo alcuni esperti addirittura per mesi.
Suggerimento: rileggere le due frasi precedenti immaginando che un episodio analogo colpisca, invece degli aeroporti (la foto sottostante ritrae i nastri trasportatori presso l’aeroporto “LaGuardia” di NYC durante l’incidente informatico del 20 luglio 2024), i sistemi di controllo di una rete idrica o elettrica, o impianti chimici, o i sistemi di sale operatorie o ancor peggio sistemi MILITARI.
Forse è utile riportare l’attenzione sulla Formazione,e relativamente al mercato del lavoro, coinvolgere chi realmente conosce e ha esperienza nella gestione delle infrastrutture o si è preparato alacremente per questo, non solo chi sa esclusivamente installarci sopra delle applicazioni solo perché costa meno sul libro paga.
Addendum: tutti i media sono corsi a intervistare gli esperti di Cybersecurity più in voga (tutti esperti di kernel Windows, di puntatori a puntatori nonché di gestione della memoria heap a basso livello?!?🤔ma davvero?🤔) poiché così vanno le cose (anche in Italia), giacché se oggi un sistema informatico o una rete si interrompe, immediatamente il mainstream grida all’attacco informatico, tuttavia nel caso di CrowdStrike non si è trattato di questo.
Intendiamoci, c’è effettivamente di mezzo un’azienda (CrowdStrike) che di quello si occupa (e se non fosse un aspetto importante della vicenda, non insegnerei Cybersecurity e Sistemi operativi in contesti diversi, dai corsi professionalizzanti per diplomati ai master per neolaureati) ma focalizzarsi sul fatto che detta azienda si occupi di Cybersecurity fa perdere di vista il problema essenziale, ossia che si è trattato di un problema sistemistico, generato da un bug contenuto in un software proprietario commercializzato da un’azienda che sviluppa software per la Sicurezza Informatica, e la soluzione al problema, pur avendola tirata fuori dal cilindro i progettisti stessi di CrowdStrike, sulle reti in produzione l’hanno poi applicata dei sistemisti, non dei malware analyst né dei penetration tester.
Poi è interessante notare come la profezia in qualche modo si sia auto-avverata, con svariati attacchi informatici mascherati da soluzioni al problema… di nuovo facendo leva sul pretenzioso desiderio di Automazione perfetta.
A questo link è possibile consultare un recente articolo della stessa CrowdStrike per approfondire la soluzione della problematica che essi stessi hanno generato.
Concludo questo messaggio in bottiglia destinato a quei CISO e architetti di sistemi ICT che transitano da queste parti: incidenti informatici come questo invocano la necessità di ridefinire il concetto di HA (High Availability) studiato nelle Università; se i vari Domain Controller, server FTP, HTTP, SMB ecc.. fossero stati duplicati anche su sistemi Linux (quante sono le organizzazioni che continuano a investire ciecamente solo su Microsoft Windows quando invece molti dei medesimi servizi si possono erogare anche su Linux/Unix?), questo disastro informatico di portata globale si sarebbe potuto “banalmente” evitare con una migrazione temporanea verso i relativi sistemi Linux/Unix ridondati e aggiornati con i medesimi dati contenuti nei database Windows operativi fino a qualche minuto prima. La (Cyber)Security by Design (che oltre al codice andrebbe applicata anche alle architetture dei sistemi informativi) è tutt’altro che improvvisazione: non si può dunque improvvisare affidando il disegno e la gestione del proprio patrimonio informativo al primo ciarlatano o alla prima società di consulenza solo perché suggerita dall’amico dell’amico del collega del CISO tal dei tali (che magari non ha mai realmente seguito un corso né di (Cyber)Security by Design, né di Secure Coding né di Zero Trust Security), poiché prima o poi potrebbe ricapitare ciò che è già successo…e cadresti, come tanti altri/e, nel medesimo (o|e)rrore strutturale provocato dall’approccio ingenuo di chi ti ha evidentemente venduto incompetenza spacciata per Professionalità.
Più che interessante lettura estiva…direi doverosa per tutti coloro interessati alla malware analysis.
Sono rimasto affascinato da questo libro di Zhassulan Zhussupov: seguo l’autore da un po’ su Twitter, e onestamente posso dire che questo volume non solo ha soddisfatto, ma che ha superato le mie aspettative con la sua ricchezza di contenuti nonché di applicazioni pratiche.
Testo fondamentale per qualsiasi professionista operativo nel mondo della Cybersecurity e che desideri approfondire la propria comprensione degli attuali malware, in esso l’autore discute e mostra tecniche avanzate di persistenza (APT) ed evasione dei malware in modo chiaro e dettagliato, integrando esempi pratici di codice di facile lettura (a patto che si abbia un minimo di basi di programmazione a basso livello tramite Python e C/C++) che trasforma la teoria complessa in un apprendimento accessibile e coinvolgente.
I capitoli dedicati agli APT, alle tecniche anti debugging e agli algoritmi matematici per cifrare i payload dei malware sono tra i miei preferiti, poiché offrono approfondimenti dettagliati difficili da trovare in altre pubblicazioni. Interessante il collegamento tra APT e cybercrime, che fornisce considerazioni e spunti di riflessione tali da evidenziare la complessità e le sinergie operative tra i malware e le moderne minacce informatiche in un modo che altri testi (almeno tra quelli da me studiati fino ad oggi) non fanno.
L’autore discute più di 100 esempi di malware, del resto è tra coloro che alimentano il noto portale Malpedia.
Prima di accettare un ingaggio per un penetration test o per un vulnerability assessment non solo risulta prudente ma anche doveroso accertarsi che il cliente sappia effettivamente cosa vuole… giacché non gli è sempre così chiaro, anche perché penetration test è ormai diventato un termine abusato per svariate problematiche: – sta cercando solo un audit del codice e in realtà confonde i termini? – forse è alla ricerca solo di una Code Review? – il cliente si aspetta che lavoriamo in ambito Blackbox, Whitebox o Greybox? – l’analisi dovrà essere circoscritta al perimetro ICT oppure dovrà coinvolgere anche gli apparati e i sistemi del mondo ICS? – il cliente si aspetta che venga incluso anche il perimetro VoIP/IoT nell’assessment? …e oltre alle variabili ad alto livello indicate nel grafico, aggiungo fattori contestuali non banali: – i sistemisti che gestiscono l’infrastruttura del cliente sono dipendenti interni o consulenti esterni del cliente? – la società che ci sta commissionando l’attività, effettivamente è la società proprietaria dei sistemi da scansionare ed attaccare? – chi di dovere ci ha firmato le necessarie manleve a norma di legge? – i sistemi da testare sono pubblicamente raggiungibili da Internet oppure per testarli occorre necessariamente essere collegati alla LAN/WLAN del cliente? – chi di dovere ci ha fornito la lista aggiornata delle sottoreti da sottoporre a scansione oppure dovrà essere nostra cura scoprire quali siano gli indirizzi IP associati ai sistemi? – il target fa uso anche di sistemi o servizi in Cloud? e se sì, quali? – gli utenti operativi nell’eventuale rete on-premises del target adottano abitualmente smart card per le loro operazioni? – il target è una piccola azienda, una media realtà o addirittura un S.O.C. / M.S.S.P. di portata nazionale? – il cliente è interessato a qualunque vulnerabilità eventualmente presente nei suoi servizi e sistemi oppure solo al mondo OWASP? . . …ecc.. ecc..
Bollettini di sicurezza informatica (CVE) riguardanti vulnerabilità intrinseche in VPN realizzabili tramite appliance (Fortinet, PAN, CheckPoint, Cisco) piuttosto che tramite software di terze parti (vedi Ivanti) tra il 2023 e il 28 maggio 2024: spaventoso.
Un ISMS (Information Security Management System, in italiano “Sistema di gestione della Sicurezza delle Informazioni“) è uno strumento fondamentale per supportare le organizzazioni nell’adottare le necessarie misure tecnologiche, i servizi e gli strumenti di monitoraggio e controllo digitale che consentono di proteggere il patrimonio informativoaziendale dalle minacce informatiche.
Adeguare gli ISMS aziendali agli standard ISO 27001 continua ad essere un compito arduo per molte organizzazioni, tuttavia esistono numerosi consulenti, aziende e professionisti del settore che possono facilitare i processi di migrazione ed ingegnerizzazione dei sistemi ICT per ristrutturare in maniera efficiente e tempestiva l’intero sistema informativo a ciò che lo standard prevede (rendendo anche l’ISMS stesso compliant alle normative): se come me sei uno tra questi, potresti trovare utile questo diagramma mentre approfondisci o applichi l’attuale standard ISO 27001.
dmzware.com 