Se si chiama “punto di contatto” deve essere reperibile… o no?!? E invece, per la governance NIS2 il ruolo è affidato spesso a figure apicali, che per mille motivi non possono garantire quella reperibilità (e talvolta neanche quella necessaria competenza tecnica) doverosa per segnalare tempestivamente un incidente informatico.
Legali rappresentanti o manager che sono spesso in trasferta, ad eventi di networking o che ancor peggio non presidiano operativamente i sistemiICT.
E in uno scenario di emergenza, tutto questo può avere gravi conseguenze.
Il punto di contatto non dovrebbe essere visto come un ruolo di rappresentanza: è infatti una funzione operativa chiamata a “curare” l’attuazione degli adempimenti NIS2!
🔹E se il S.O.C. chiamasse alle 2 di notte? 🔹E se il referente CSIRT (magari esterno) avesse necessità di un confronto? 🔹E se venisse inserito come figura attiva nelle procedure di Incident Response?
L’anno scorso, mossi anche da una certa fretta, sono state fatte alcune scelte sul portale ACN, ma adesso e fino al 31 maggio è possibile aggiornare anche questi dati!
👉 La governance può diventare proprio un elemento di aggiornamento, anche alla luce delle procedure di Incident Response che devono essere implementate con estrema attenzione.
Acronimo di Enterprise JavaBeans Certificate Authority, EJBCA è un interessante software open-source per mettere in piedi un’infrastruttura a chiave pubblica (PKI) in grado di avvalersi di crittografia PQC (Post Quantum Cryptography) per emettere e proteggere i certificati digitali dei propri utenti e dispositivi. Gestito e sponsorizzato dalla società svedese PrimeKey Solutions AB, il pacchetto software EJBCA può essere utilizzato per installare un’autorità di certificazione (una C.A.), un’autorità di convalida e un’autorità di registrazione gestibili privatamente. Ormai giunto alla versione 9.4.2 nel momento in cui sto scrivendo, il software EJBCA è utilizzato per gestire autorità di certificazione (C.A.) in diversi contesti, tra cui e-Government, endpoint management, sistemi IoT, energia, telecomunicazioni, eIDAS, networking e perfino nell’ambito delle PMI.
Una Certification authority EJBCA sotto forma di appliance
Due analisti di sicurezza informatica (S.O.C.) di recente si sono dichiarati colpevoli di attacchi ransomware.
Ryan Goldberg era un manager che si occupava di DFIR (Digital Forensics Incident Response) per la società Sygnia. Viceversa, Kevin Martin ricopriva il ruolo di negoziatore di ransomware presso DigitalMint.
Il loro lavoro era proteggere le aziende da cyber gang e attacchi informatici. E invece, sono diventati degli hacker…della peggior specie: degli insider.
Tra maggio e novembre 2023 hanno attaccato cinque aziende statunitensi usando il ransomware BlackCat, tra cui: – un’azienda di dispositivi medici in Florida – un’azienda farmaceutica nel Maryland – un produttore di droni in Virginia
Ad una sola vittima hanno estorto ben 1,3 milioni di dollari in bitcoin.
I pubblici ministeri hanno affermato che hanno “abusato di una posizione di fiducia pubblica o privata” e hanno utilizzato “speciali competenze” per commettere i loro crimini.
Sapevano esattamente come le aziende reagiscono agli attacchi ransomware. Conoscevano i loro punti deboli. E soprattutto, sapevano cosa induce le vittime a pagare per poter avere indietro i loro dati e ottenere il ripristino tempestivo dei loro sistemi.
E hanno usato questa conoscenza per diventare dei moderni predoni. Ma gli è andata male: entrambi ora rischiano fino a 20 anni di carcere federale.
Ogni team di sicurezza informatica dovrebbe basarsi sulla fiducia: la fiducia che le persone che hai ingaggiato o con cui collabori per difendere l’organizzazione in cui lavori o le aziende clienti non siano mai e poi mai quelle da temere ma quelle su cui poter contare, che siano persone non dico sante, ma verosimilmente persone oneste e affidabili. Prima di poter iniziare la loro professione, gli aspiranti medici si impegnano a prestare fedeltà al “giuramento di Ippocrate” per il resto della loro vita professionale, perché gli analisti S.O.C. non hanno qualcosa di equivalente?
In questo periodo è ancora su tutti i giornali e su centinaia di blog il caso del furto al Louvre, “il Museo” per definizione.
Non solo per il prestigio del museo e della città (“Paris, je t’aime!”) scalfiti (seppur solo temporaneamente) da questo incidente informatico contestuale al furto dei gioielli, quanto per le inettitudini a livello di gestione della Cybersecurity – questa materia complessa e variegata, piena di sigle strumenti e protocolli, di svariate figure professionali, che pur tuttavia si regge solo rispettando i suoi pilastri (“best practice“) e le sue fondamenta strutturali – che hanno favorito il furto.
E una delle regole fondamentali della Cybersecurity (vera, non a chiacchiere) è: devi avere un sistema di autenticazione (caro utente dietro la connessione in arrivo, ma CHI diavolo sei?) dietro cui ci sia un sistema autorizzativo (dimmi appunto prima CHI sei, e ti dirò COSA sei AUTORIZZATO o meno a fare nel SISTEMA).
Gli enti pubblici spendono milioni di euro (o dollari) in consulenze, infrasrutture, server, certificazioni, appliance e quant’altro il (ricco) mercato della Cybersecurity mette a disposizione, ma spesso mancano le basi, si trascurano i dettagli delle fondamenta strutturali e si dà per scontato questo o quello. Accade in Italia così come all’estero. Ed è stato questo, ad esempio, proprio ciò che è successo al sistema di videosorveglianza del Louvre, evidentemente gestito con negligenza a livello di sicurezza (chi ha configurato i dispositivi ha impostato “Louvre” 🙃 come password: una lezione di (in)sicurezza informatica da 100 milioni di dollari che – almeno i parigini – ricorderanno a lungo).
Le interfacce di management di una webcam, di un sistema di videosorveglianza e/o di un qualunque altro dispositivoIoT che ha un piede su Internet devono essere configurate con password lunghe e complesse, o ancor meglio con una passphrase facile da ricordare ma non banale né corta (es: “EvvivaLEuropaUnitaOraESempre”)
Non rispetti queste semplici regole? Dai tuoi tecnici fai gestire con superficialità gli aspetti di sicurezza informatica dei tuoi sistemi ICT/OT? Non effettui un monitoraggio proattivo e meticoloso di ciò che accade nel tuo datacenter attraverso SIEM né EDR? Spiacente, ma la prossima vittima di un databreach o di un’intrusione informatica (con conseguente furto fisico o digitale) potresti essere tu.
P.S.: accertarsi se l’interfaccia di management di un dispositivo (webcam, router, access point ecc..) e/o API e/o webapp sia stata o meno configurata con una password banale non è un processo lungo e complicato, basta un ICT audit o un vulnerability assessment fatto a dovere da un professionista del settore (…come, guarda caso, il sottoscritto).
Ancora oggi, molti addetti ai lavori utilizzano questo magnifico tool di Fyodor con superficialità… ad esempio in molti credono che da nmap non sia possibile farsi restituire solo gli indirizzi IP (quindi senza gli ulteriori dettagli che il tool normalmente ci restituirebbe) che hanno effettivamente la porta che ci interessa in stato open, ma come si evince da questa schermata, è possibile farlo concatenando in pipe qualche comando bash.
Di seguito il comando testuale se desideri (ri)utilizzarlo: nmap -n -Pn target/subnet -p3389 -oG – | grep ‘/open/’ | awk ‘/Host:/{print $2}’ (attenzione agli apici e al simbolo – quando incollerai questo codice nella tua shell: riconfrontali con la videata, poiché WordPress cambia volutamente gli apici)
target/subnet va ovviamente sostituito con la sottorete che desideri scansionare (ma puoi inserire banalmente anche un unico target /32), come nella scansione che vedi in videata (da cui è possibile desumere che un sysadmin imprudente abbia lasciato raggiungibili da Internet ben 11 servizi RDP!), mentre immediatamente a destra del flag -p va inserito il numero di porta che ti interessa verificare (da remoto o in locale).
P.S.: è possibile personalizzare ulteriormente il comando per farsi restituire anche l’hostname del target di cui nmap rileva la porta aperta.
Letture di approfondimento: – “Nmap Network Exploration” (Calderon, 2021) – “Nmap Network Scanning: A Complete Guide to Exploring And Scanning Networks With NMAP” (S. Gellis, 2024)
CVE-2025-33073 è una vulnerabilità remota (RCE) sfruttabile se sul target (sistemi Windows) è attivo il servizio SMB sprovvisto di firma digitale nei domini AD (Active Directory) on-premises in cui il sysadmin ha lasciato le impostazioni di default (diciamo il 99% dei casi?🤑😱😈).
Perché dovresti preoccupartene se non hai ancora aggiornato Windows? Poiché sfruttando questa vulnerabilità, un attacker riuscirebbe a fare privilege escalation (permette di acquisire i permessi dell’account SYSTEM partendo da un account con pochi privilegi) in poco tempo sulla maggior parte di host Windows (consulta Link2) sprovvisti di firme SMB.
Per agevolare il rilevamento dell’exploit, è possibile utilizzare la seguente query KQL progettata per identificare richieste DNS sospette, ossia con informazioni di destinazione potenzialmente indicative dello sfruttamento di CVE-2025-33073
Link di approfondimento: – Link1 – Link2 (PoC originale, pubblicata il 14-giugno-2025) – Link3 (PoC di approfondimento)
Ti sei mai chiesto come rilevare eventuali sessioni utente sospette o insolite sui computer del tuo dominio Windows? FindUnusualSessions è un tool di enumerazione delle sessioni remote che sfrutta il protocollo Windows RPC per agevolare il rilevamento di anomalie relative agli utenti connessi alle tue reti.
🛠️ Funzionalità principali: ✅ segnala utenti di dominio esterni insoliti o inusuali che potrebbero costituire un sintomo di movimenti laterali o compromissioni non ancora individuate dai tuoi XDR/EDR ✅ utilizza RPC per interrogare da remoto i dispositivi Windows
Manca poco (8 aprile 2025) al rilascio di un innovativo software gratuito per applicare crittografia moderna: OpenSSL 3.5.
Per la prima volta un’intera gamma di applicazioni, inclusi i web server, saranno in grado di utilizzare PQC (Post Quantum Cryptography) e quindi di migliorare la Cybersecurity del settore nonché dei servizi erogati. OpenSSL è la libreria globalmente più utilizzata per cifrare file e stream, e appunto dalla versione 3.5 supporterà la sostituzione del protocollo crittografico ECDH con ML-KEM nonché degli algoritmi RSA ed ECDSA con ML-DSA.
L’integrazione più interessante per lo scambio di chiavi sarà quella di poter utilizzare un metodo ibrido, come ML-KEM-X25519, il quale utilizza sia X25519 (con curve ellittiche) che ML-KEM per creare la chiave. Dalla versione 3.5 in avanti ci sarà anche la possibilità di applicare metodi di firma digitale ibridi, come ML-DSA-Ed25519.