Microsoft’s Secure Boot has been broken for a decade and no one noticed until now

Further complicating the process, even the expiration of the Microsoft certificate that signed the shims, which took place late last month, isn’t enough to revoke the ones ESET identified.

A rogue’s gallery of defective shims

The shims identified by ESET authorize secondary components that are known to be vulnerable to various exploits. The Oracle shim, for instance, signs a binary vulnerable to CVE-2015-5381. Smolár said the skill required to exploit the vulnerability is low. Other vulnerable shims fail to support protections, such as MOK deny-list enforcement and SBAT enforcement, both of which came into effect after the affected shim was released. Still other identified shims contain vulnerabilities in their own code.

In the interest of brevity, many additional details included in Tuesday’s report are omitted from this article.

An unsettling prospect

As noted, these vulnerable shims can be used against Windows and Linux machines alike, although likely not Windows 11 Secured-core PCs in their default state. Any Windows user who has installed Microsoft’s June update batch is no longer vulnerable. Linux users should check the Linux Vendor Firmware Service or consult their distributor. Revocation statuses are available using the uefi-dbx-audit script.

The prospect that attackers have had the means to bypass Secure Boot for more than a decade through what amounts to hack-by-numbers scripts isn’t much of an endorsement of the mechanism proposed by Microsoft in partnership with hardware makers. As mentioned earlier, a key contributor to this debacle is its complexity.

“This is a solid rebuke of the entire secure boot model,” HD Moore, a firmware security expert, CEO and founder of runZero, and a long-time critic of Secure Boot, said in an interview. His complaints include Microsoft being the de facto root of trust for the entire UEFI platform, the inability of the protection to scale sufficiently, and the ability for components to boot even after top-level certificates expire.

“The end result is a huge number of unknown (to everyone but Microsoft) signed things that bypass Secure Boot—some of which can then be used to boot other things—and both have normal security bugs and other mistakes that mean they can be used to boot nearly anything,” Moore added. “The whole ecosystem is somewhat broken and needs a reboot.”

https://arstechnica.com/security/2026/07/microsoft-secure-boot-has-been-broken-for-most-of-its-existence/




Gli assistenti AI di coding sono sicuri? Il caso xAI


Gli strumenti di AI per lo sviluppo software promettono di aumentare la produttività degli sviluppatori, ma una recente analisi indipendente riaccende il dibattito sulla sicurezza dei dati affidati agli assistenti di coding. Al centro della vicenda c’è Grok Build, il tool a riga di comando di xAI, accusato di aver trasmesso (in chiaro) ai server dell’azienda interi repository Git, cronologia compresa, insieme a file contenenti credenziali e altri dati sensibili. Secondo il ricercatore che ha condotto l’analisi, inoltre, il comportamento sarebbe avvenuto anche dopo aver attivato l’opzione di esclusione dall’addestramento del modello.

Un’analisi del traffico di rete fa emergere il problema

La vicenda nasce dall’analisi del traffico di rete effettuata dal ricercatore noto come cereblab, che ha instradato Grok Build attraverso mitmproxy per osservare nel dettaglio le comunicazioni tra il client e i server remoti. L’obiettivo era verificare quali dati venissero realmente inviati durante una normale sessione di sviluppo. I risultati non sono stati quelli sperati. Secondo il report, il software avrebbe aperto due canali distinti di comunicazione: uno destinato alle richieste del modello AI e un secondo utilizzato per il caricamento del codice (un comportamento decisamente non atteso e che ha allarmato il ricercatore).

Nel test effettuato su un repository Git di circa 12 GB, il traffico destinato al modello AI sarebbe stato limitato a circa 192 KB, mentre il canale di storage avrebbe trasferito 5,10 GiB di dati suddivisi in 73 blocchi da circa 75 MB ciascuno. Il rapporto tra i due flussi supera le 27.800 volte, un valore incompatibile con il semplice invio del contesto necessario alla conversazione con il modello e che di solito giustifica connessioni parallele. L’analisi sostiene inoltre che il contenuto inviato corrispondesse a un bundle Git completo, comprendente non solo i file correnti ma anche la cronologia del repository.

Anche i segreti sarebbero finiti nel trasferimento

Ancora più delicata è la parte relativa ai secret presenti nel progetto. Durante il test il ricercatore ha inserito volutamente un file .env contenente chiavi API e credenziali fittizie facilmente identificabili. Secondo quanto documentato, tali informazioni sarebbero state trasmesse integralmente durante la comunicazione con i server di xAI. Inoltre, ricostruendo il bundle Git catturato durante il trasferimento, il ricercatore afferma di aver recuperato anche un file che l’agente era stato esplicitamente istruito a non leggere, suggerendo che il caricamento del repository fosse indipendente dalle operazioni realmente effettuate dal modello.

Uno degli aspetti più controversi, secondo cerelab, riguarda l’impostazione “Improve the model”, utilizzata per escludere i propri dati dall’addestramento dell’intelligenza artificiale. Secondo la sua analisi, la disattivazione di questa opzione non avrebbe impedito il trasferimento del repository, ma soltanto il suo eventuale utilizzo per l’addestramento del modello. In altre parole, il codice continuerebbe comunque a lasciare la macchina dello sviluppatore per essere archiviato sui sistemi remoti. Si tratta di una distinzione importante, perché trasmissione, archiviazione e addestramento rappresentano tre aspetti differenti dal punto di vista della sicurezza e della conformità normativa.

xAI avrebbe già modificato il comportamento del servizio

La vicenda, tuttavia, sembra aver avuto un’evoluzione molto rapida. Nei giorni successivi alla pubblicazione del report, lo stesso ricercatore ha ripetuto i test osservando un comportamento differente. In sei prove consecutive non sarebbe più stato rilevato alcun caricamento del repository tramite l’endpoint dedicato allo storage. Al suo posto sarebbero comparsi nuovi flag server-side, tra cui disable_codebase_upload, che sembrerebbero disattivare la funzione senza richiedere un aggiornamento del client. Al momento, però, xAI non ha pubblicato alcun advisory di sicurezza, né un changelog che spieghi ufficialmente la modifica o chiarisca quale sia stato l’impatto del problema sugli utenti che hanno utilizzato Grok Build prima della mitigazione. Anche le note di rilascio più recenti del progetto non fanno riferimento alla questione.

Una lezione per tutti gli agenti di coding

Al di là del singolo caso, l’episodio evidenzia una criticità destinata a diventare sempre più rilevante con la diffusione degli AI coding agent. Molti sviluppatori tendono infatti a considerare questi strumenti come semplici assistenti locali, mentre nella maggior parte dei casi il lavoro viene svolto su infrastrutture cloud. Per le organizzazioni questo significa che repository, codice proprietario, segreti applicativi e informazioni sensibili potrebbero lasciare il perimetro aziendale se non vengono definite precise policy di utilizzo. E addirittura, questo potrebbe succedere anche se le opzioni di non condivisione sono attive, richiedendo una infrastruttura di controllo che vada oltre la semplice policy.

Condividi l’articolo



Articoli correlati

Altro in questa categoria


https://www.securityinfo.it/2026/07/14/gli-assistenti-ai-di-coding-sono-sicuri-il-caso-xai/?utm_source=rss&utm_medium=rss&utm_campaign=gli-assistenti-ai-di-coding-sono-sicuri-il-caso-xai




Julia Stuyt — Women in Security 2026

Julia Stuyt got her first exposure to the security industry at the Toronto Pearson International Airport, where she worked in call-taking, monitoring and dispatching for security-related incidents. After moving to the Ottawa area, she took on a similar role at the Ottawa International Airport (YOW).

Upon transitioning to YOW’s emergency management team, Stuyt had the opportunity to apply her operational airport knowledge to the role while gaining new skills and responsibilities.

“I prepared reports for industry partners and conducted investigations into unauthorized operations, including one case that ultimately resulted in enforcement action,” Stuyt shares.

One of the new responsibilities she took on was to build the airport’s drone response capabilities.

Stuyt has invested her time and efforts into managing drone security for YOW, finding it integral to airport security.

“The drone industry is evolving rapidly with technology advancing at an unprecedented pace. As with many emerging technologies, innovation often develops in parallel with new risks and operational challenges,” she says. “Keeping pace with changing capabilities, developing effective mitigation strategies, and ensuring legislation evolves alongside the technology will continue to be a significant challenge, not only for us at YOW, but for airports around the world.”

In 2024, Stuyt moved up to the position of Manager of Critical Operations Systems at YOW, where she focused on offering strategic direction for airport security systems, enacting lifecycle management practices, and serving as the system owner while bridging operational users and technical support teams.

“I worked really closely with the IT team that provided valuable insight into the technical and infrastructure side of the security systems, and we reinforced the importance of strong collaboration between the operational and technology teams in delivering effective security solutions,” Stuyt states.

Earlier this year, Stuyt transitioned into her current role as YOW’s Manager of Physical and Corporate Security.

“This position has allowed me to bring together the operational, technical, and strategic experience I’ve developed over the past decade to help drive meaningful change and strengthen our security operations across the airport,” she explains.

While building herself up throughout her career journey, Stuyt learned two core lessons.

“I worked really closely with the IT team that provided valuable insight into the technical and infrastructure side of the security systems, and we reinforced the importance of strong collaboration between the operational and technology teams in delivering effective security solutions.”

“The first is the importance of people. Every interaction, every role, every meeting matters. I would not be where I am today without having had the opportunity to build credibility across different parts of the organization and earn the trust of colleagues along the way. The people I’ve worked with throughout my career have played a significant role in my development. They have continuously challenged me to think differently, exposed me to new perspectives in areas of expertise, and contributed to my growth both professionally and personally,” she reflects.

Stuyt continues, “The second lesson is the importance of self-advocacy. Throughout my career, I’ve learned that if you do not speak up for yourself and your own ideas, opportunities can easily pass you by. When you identify a gap, it is important to be proactive in finding ways that you can contribute to solving it. Similarly, when you see an opportunity for growth or improvement, you cannot always wait for someone else to create that path for you. You often have to take the initiative and create it for yourself.”

Stuyt sits at a unique cross section of industries — security and aviation — both of which are traditionally male-dominated. From her perspective, this experience has highlighted the value of visibility.

“It’s important for women to see that there are opportunities to grow into operational, technical and leadership roles across all areas of the business,” she asserts. “Diverse perspectives strengthen decision-making, problem-solving and ultimately the resilience of our organizations. I would encourage anyone interested in this field to stay curious, be willing to take on new challenges, and not to be afraid to step into spaces where they may not yet see many people who look like them.”

https://www.securitymagazine.com/articles/102426-julia-stuyt-women-in-security-2026




Denise Platon — Women in Security 2026

Security professionals face constantly evolving threats and challenges – security is never static which is something that Denise Platon personally embodies.

“Security can never be approached as a static discipline,” she says. “It’s just constantly evolving.”

Growing up in the Washington DC metro area, Platon was influenced by national affairs leading to her studying global affairs and intelligence analysis at George Mason University. There she continued developing strong interest in international relations and national security.

After graduation Platon began her career as a contractor with the U.S. State Department’s Bureau of Consular Affairs. From there she transitioned into Diplomatic Security — working with the Office of the Technology Officer, then the Office of Personnel Security and Suitability.

“I was really drawn to the mission of Diplomatic Security… seeing the direct real-world impact of that work made it feel really purposeful,” Platon says.

In 2019, Platon made a deliberate career change from Diplomatic Security to Nestlé — where she’s been ever since where she currently serves as Corporate Security Manager. She joined Nestlé as one of the first people to rebuild the U.S. market security program from scratch after an office relocation

“I took that leap of faith, but that also involves taking risks… I believe I have a growth mindset,” she says.

In her role, Platon oversees physical security operations across U.S. manufacturing, corporate, and distribution center sites. Her responsibilities span access control, incident trend analysis, threat intelligence monitoring, and travel security. She also works closely with site-level personnel and follows a key philosophy that threat intelligence must be actionable.

“I have all of this information, but it has to be actionable,” she says. “I have to work very closely with our site security champions — they’re our local boots on the ground.”

Growing in Security

Working in both the public and private sector, Platon has had a front row seat to some of the differences in security leadership. These experiences have shaped her personal leadership style and ensuring buy in from all stakeholders.

“In the government, it’s very authoritative — this is a law, this is what has to be done. In the private sector, it’s the complete opposite. Security has to be relationship-driven, where security is a partner,” she says. “Building trust through transparency and being responsive — that has really helped with improving collaboration between us and stakeholders.”

Platon highlights how being a mother of two has shaped her empathy-first leadership approach and has influenced how she thinks about risk and people.

“Being a mom has really reinforced the importance of leading with empathy, having patience, and learning how to prioritize,” she says. “It made me very thoughtful about how stress and uncertainty affect people at a human level, not just an operational one.”

“In the government, it’s very authoritative — this is a law, this is what has to be done. In the private sector, it’s the complete opposite. Security has to be relationship-driven, where security is a partner.”

Paying it Forward

Platon says mentorship is an important aspect of growing a security career and has been an active participant in an annual Women in Security mentorship program through OSAC where she offers advice, support and encouragement however she can.

“In security, mentorship is really important because much of the work depends on experience and trusted networks, not just formal training,” she says. “Building relationships early will accelerate learning far more than formal training alone.”

For those looking to break into the security field, Platon emphasizes the importance of curiosity, continuous learning and a willingness to take risks.

“My biggest advice to those getting into the field is to stay curious,” she says. “Security is a really broad field… being a generalist supersedes specialization. “Ongoing learning is essential to staying really effective in this field.”

https://www.securitymagazine.com/articles/102427-denise-platon-women-in-security-2026




How Post-Quantum Cryptography is Gaining Adoption

Post-Quantum Cryptography (PQC) has made a lot of headlines in recent years. The narrative can range from an imminent threat from a malicious foreign actor to something that might be happening in 20 or 30 years. This article aims to clarify the state of the art in research and development while giving a sense of the urgency and magnitude of the threat to IT leaders. Looking forward, we’ll look at two bleeding-edge use cases that are showing traction in the cybersecurity sector.

For all our professional lives, all the digital information that is encrypted either in-flight (e.g. VPN, HTTPS) or at rest (e.g. encrypted hard drive) have been resting on the power of asymmetric mathematical functions. For example, it’s relatively simple to multiply two prime numbers, but it is quite hard to recover these two prime numbers from the product of the multiplication. That is rather impossible to do by hand. Although computers make it faster with their best CPU and GPU clusters, it might still take more than the age of the universe to get that math done!

With the emergence of quantum computing (QPUs not CPUs), the math that supports most of the encryption algorithms we love and cherish can be at risk. Shor’s algorithm (developed by Peter Shor in 1994) quite famously speeds up the factoring of large numbers in polynomial time. Quantum computing hardware does exist today, but it is very limited in its capabilities, making it irrelevant for real-world applications. The question is: when will we have powerful enough GPUs to tackle larger numbers and bigger problems?

Samuel Jacques, an assistant professor at the University of Waterloo, provides a helpful visualization to understand the gap between today’s technology and what it takes to break common encryption schemes such as RSA.

We’ve moved past the stage of invention to the stage of an actual engineering problem to make the quantum computers useful and ready for real work applications. Error correction remains the main challenge ahead. A lot of effort is being deployed into making more Qubits but also better Qubits. Most likely quantum computing will break encryption in the next few years (or few decades). What should we do now?

From Theory to Action

Fortunately, in August 2024 NIST has announced 3 standard algorithms that are known to be resistant to quantum computing: Module-Lattice-Based Key-Encapsulation Mechanism Standard (FIPS 203) for key establishment, as well as Module-Lattice-Based Digital Signature Standard (FIPS 204) and Stateless Hash-Based Digital Signature Standard (FIPS 205) for digital signatures. These standards are ready for deployment.

Last year (2025), NIST selected another algorithm to serve as a back-up for the first in the list above (FIPS 203 or ML-KEM for short). The Hamming Quasi-cyclic (HQC) is based on different math which provides another layer of security in case ML-KEM would be failing. One more is on the way: FALCON should be released as FIPS 206 soon.

The NSA defines its CNSA 2.0 framework requiring all new national security systems to implement quantum-safe algorithms by January 1st, 2027. By December 31, 2031 CNSA 2.0 algorithms will be mandatory. NIST, however, envisions a transitionary state where hybrid protocols can continue to leverage classical algorithms for key establishment and digital signatures. While making the transition easier, well-known algorithms can provide an extra layer of security in case the newer quantum-resistant algorithm becomes vulnerable.

In any case, IT leaders need to act now to procure the next wave of secure and standard compliant systems they need for the year ahead. The pressure is on because of a well-known threat called HNDL (harvest now, decrypt later). Some bad actors are known to acquire massive amounts of encrypted data which they hope to mine in the future. Private data, financial data, and healthcare data are particularly vulnerable.

Applications in the Real-World

Since most banking services are now happening online, banks and payments providers among others are busy upgrading their infrastructure. The preparation for quantum security readiness must include websites, mobile applications, bank infrastructure, as well as service providers and partners.

The most interesting case might be found in the blockchain space. Since Bitcoin came alive in 2009, the cryptographic primitives are based on Elliptic Curve Cryptography, which is vulnerable to quantum attacks. While the internal infrastructure is somewhat safe (e.g. mining, record of transactions), the “wallet” relies on vulnerable algorithms. As a result, an attacker could use a brute force attack to break into a user account to siphon its assets. Bitcoin earlier payment transactions which exposed the public key (P2PK) are the most vulnerable. Most blockchains are actively working on upgrading their protocols.

Drones have also fundamentally transformed modern industry, logistics, and data collection. Operating at a fraction of the cost of traditional aviation systems, they can maneuver rapidly and are hard to detect. They have, however, critical weaknesses. Communication with ground control can be jammed or hacked into critical components and data can be harvested later by opponents. To avoid communication interference, drone operators are using very long fiber-optic cables. However, they can’t do anything if the drone is taken down and harvested.

Quantum technologies can be used to secure communication channels using Quantum Key Distribution (QKD), a method using quantum mechanics to communicate while ensuring that eavesdropping attempts can be detected. Meanwhile, on the drone itself, information can be encrypted with PQC with secure chips specially designed to never store any key but instead can regenerate a key every time in a non-cloneable fashion . Every critical piece of hardware can be tagged and authenticated before take-off to ensure the integrity of the aircraft.

The threat brought on by quantum computing to current cryptographic standards is a present issue. Various industries, such as financial services, are upgrading their infrastructure and systems to protect sensitive data. At the same time, defense applications are implementing Post-Quantum Cryptography (PQC) and Quantum Key Distribution (QKD) to secure systems. Implementing PQC ensures the integrity and confidentiality of data against these threats for a better future. 

https://www.securitymagazine.com/articles/102404-how-post-quantum-cryptography-is-gaining-adoption




Security Leaders Discuss Exposure of 24B Credentials

The exposure of approximately 24 billion credentials was reported on in mid-June after researchers discovered 8 terabytes of datasets containing information from previous security incidents. These incidents included: 

“The sheer volume of exposed credentials is alarming, but the bigger concern is that many of these records appear to come from infostealer malware,” says Phil Wylie, Senior Consultant & Evangelist at Suzu Labs. “Unlike a traditional data breach that impacts a single company, infostealers quietly harvest credentials, session cookies, and authentication tokens directly from infected devices, creating a much broader and more difficult security challenge.

“Organizations should operate under the assumption that some credentials will eventually be exposed. Strong identity security practices, phishing-resistant MFA, endpoint protection, continuous monitoring for compromised credentials, and least privilege controls are essential. Simply changing passwords may not be enough when attackers have access to active sessions and authentication tokens.”

John Strand, Owner of Black Hills Information Security, Inc., adds, “The security industry is still spending too much time thinking about endpoints and internal networks and not enough time thinking about identity. Identity is the new perimeter. Breaches like this often get lost in the noise because they’re overshadowed by AI, a flashy new exploit, or the fact that they involve networking gear. That’s a mistake. These incidents are every bit as dangerous as the threats dominating the headlines, and every security team should be paying close attention.”

https://www.securitymagazine.com/articles/102403-security-leaders-discuss-exposure-of-24b-credentials




ROI della sicurezza: come costruire il business case della cybersecurity

Il ROI della sicurezza è la domanda più scomoda che un responsabile della cybersecurity si sente rivolgere, di solito da chi tiene i cordoni della borsa: quanto rende, esattamente, ciò che spendiamo per proteggerci? È una domanda legittima e insieme insidiosa, perché la sicurezza non genera ricavi, evita perdite, e il suo rendimento prende la forma di qualcosa che non accade. Un attacco sventato non compare in nessun bilancio, e dimostrare il valore di un disastro mancato è il problema di fondo con cui ogni CISO deve fare i conti quando si presenta davanti alla direzione finanziaria o al consiglio.

Eppure rispondere a quella domanda non è impossibile, ed è anzi sempre più necessario. Tra obblighi normativi che spostano la responsabilità sui vertici e budget contesi con ogni altra funzione aziendale, la sicurezza deve sapersi giustificare nel linguaggio che il vertice comprende, quello dell’investimento e del rendimento. Costruire un business case della cybersecurity significa proprio questo: trasformare la protezione da costo opaco a decisione economica argomentata.

Perché il ROI della sicurezza è diverso dagli altri

La prima cosa da capire è perché il ROI della sicurezza non si comporta come quello di un investimento ordinario. Un nuovo impianto produttivo genera un ritorno misurabile in pezzi venduti; un controllo di sicurezza, invece, produce un ritorno che è una perdita evitata, una grandezza per definizione ipotetica. Non si può osservare direttamente quanti incidenti non sono accaduti grazie a una certa spesa, e questo espone a due errori opposti: investire troppo poco, lasciando scoperti rischi rilevanti, oppure investire troppo, accumulando controlli il cui costo supera il danno che prevengono.

Il compito di un buon ragionamento sul ROI è quindi tenersi lontano da entrambi gli estremi, riconoscendo che esiste un livello di spesa oltre il quale ogni euro aggiuntivo rende sempre meno. La sicurezza totale non esiste, e anche se esistesse costerebbe più di ciò che protegge. La domanda giusta non è “come elimino il rischio”, ma “quanto conviene spendere per ridurlo”.

Il modello di Gordon-Loeb: quanto conviene spendere

A questa domanda ha dato una risposta rigorosa il modello di Gordon-Loeb, formulato nel 2002 da due economisti della sicurezza dell’Università del Maryland e diventato uno dei riferimenti teorici della disciplina. Il modello analizza il livello ottimale di investimento per proteggere un dato insieme di informazioni e arriva a una conclusione tanto netta quanto controintuitiva: in generale non conviene spendere in sicurezza più del 37 per cento della perdita attesa da una violazione.

Quel 37 per cento, che matematicamente corrisponde a 1 diviso il numero di Eulero, è un tetto e non un obiettivo, e nasce dal principio dei rendimenti decrescenti: superata una certa soglia, aumentare la spesa protegge sempre meno in proporzione. Il modello suggerisce anche una conseguenza pratica spesso trascurata, ovvero che non sempre conviene concentrare le risorse sulle informazioni più vulnerabili in assoluto, ma piuttosto là dove l’investimento è più produttivo, cioè dove riduce il rischio nel modo più efficiente. È un quadro teorico, non una formula di bilancio da applicare alla lettera, ma offre alla discussione una bussola che mancava.

ROSI: mettere numeri sulla decisione

Se Gordon-Loeb dà la cornice concettuale, per arrivare a un numero utilizzabile il riferimento più diffuso è il Return on Security Investment, il ROSI, di cui anche l’ENISA ha proposto una formulazione. L’idea è adattare alla sicurezza il classico calcolo del rendimento, mettendo a confronto il costo di una contromisura con la perdita che essa consente di evitare.

Il punto di partenza è l’Annual Loss Expectancy, la perdita annua attesa, che si ottiene moltiplicando il costo di un singolo incidente per la frequenza con cui ci si aspetta che accada in un anno. Una contromisura non azzera quella perdita, ma la riduce di una certa quota, il tasso di mitigazione. Il ROSI confronta allora il valore della perdita evitata con il costo della soluzione: se la perdita risparmiata supera la spesa, l’investimento ha senso; in caso contrario, no.

Un esempio con numeri puramente illustrativi rende l’idea. Supponiamo che un certo incidente costi in media duecentomila euro e che ci si attenda accada una volta ogni due anni: la perdita annua attesa è di centomila euro. Una contromisura che costa trentamila euro l’anno e neutralizza l’ottanta per cento di quel rischio evita ottantamila euro di perdita attesa; il rendimento si ottiene sottraendo il costo dalla perdita evitata e dividendo per il costo, e in questo caso è ampiamente positivo. Cambiando le ipotesi, però, il risultato si ribalta: se la stessa contromisura costasse novantamila euro, o se mitigasse solo il venti per cento del rischio, l’investimento smetterebbe di giustificarsi. È la dimostrazione di quanto il verdetto dipenda dai numeri di partenza.

La formula, in altre parole, è semplice, ma il suo valore dipende interamente dalla qualità delle stime che vi si immettono, e quelle stime poggiano a loro volta sulla capacità di misurare il rischio, cioè sulla quantificazione del rischio. Numeri inventati producono un ROSI inventato.

Dal numero alla decisione: parlare al vertice

Proprio perché i numeri sono stime, il loro scopo non è simulare una precisione che non hanno, ma strutturare un ragionamento e renderlo discutibile. Il vero destinatario di un calcolo sul ROI non è l’analista, ma il vertice aziendale, ed è lì che il business case si gioca davvero. Presentare al consiglio di amministrazione una cifra unica e perentoria è quasi sempre un errore: meglio mostrare scenari, intervalli e ipotesi esplicite, collegando la spesa proposta al rischio che riduce e alla propensione al rischio che l’organizzazione ha dichiarato.

Questa esigenza è diventata più stringente da quando le normative recenti hanno spostato sui vertici la responsabilità delle scelte di sicurezza. Un consiglio che risponde in prima persona del rischio cyber non può accontentarsi di un atto di fede verso il reparto tecnico: ha bisogno di capire perché una certa spesa è proporzionata e quali rischi residui resterebbero comunque sul tavolo. Il ragionamento sul ROI, con tutti i suoi limiti, è lo strumento che rende quella conversazione possibile, perché traduce scelte tecniche in termini di valore e di rischio che chi governa l’impresa è abituato a maneggiare.

In questo senso il ROI della sicurezza non è un numero da esibire, ma un linguaggio per decidere insieme. Un buon business case non promette un rendimento certo, perché sarebbe disonesto, ma mostra in modo trasparente perché una certa spesa è ragionevole, dove i rendimenti cominciano a calare e quali rischi si è scelto consapevolmente di accettare. È così che la cybersecurity smette di essere percepita come un costo da contenere e viene riconosciuta per ciò che è: una decisione di gestione del rischio come tutte le altre, da prendere con gli stessi strumenti con cui si valutano gli altri investimenti dell’impresa.

Fonti

Condividi sui Social Network:

https://www.ictsecuritymagazine.com/cyber-security/roi-della-sicurezza-business-case/




ISAC (Information Sharing and Analysis Center): la condivisione delle minacce organizzata per settore

Gli ISAC sono le organizzazioni che rendono ordinaria, e non occasionale, la condivisione delle informazioni sulle minacce tra aziende dello stesso settore. Un Information Sharing and Analysis Center è un punto di raccolta fidato in cui banche, ospedali, operatori energetici o di trasporto mettono in comune ciò che osservano, lo fanno analizzare e ricevono in cambio un quadro che nessuno di loro, da solo, riuscirebbe a costruire. Rispondono a un problema strutturale della sicurezza informatica: nessuna organizzazione vede l’intero panorama delle minacce, ma chi appartiene allo stesso settore tende ad affrontare gli stessi avversari, e un attacco subito da uno è quasi sempre un avvertimento per tutti gli altri.

L’idea non è recente. Gli ISAC nascono negli Stati Uniti con una direttiva presidenziale del 1998, la PDD-63, che invitò ciascun settore di infrastruttura critica a dotarsi di un’organizzazione dedicata allo scambio di informazioni su minacce e vulnerabilità, in una logica di collaborazione tra pubblico e privato. La stessa direttiva ne immaginava il funzionamento sul modello dei Centers for Disease Control, i centri statunitensi per il controllo delle malattie: come per un’epidemia, riconoscere presto un focolaio e diffondere l’allerta è ciò che limita il contagio. I primi ISAC presero forma già nel 1999, a partire dal settore finanziario, e oggi negli Stati Uniti si coordinano tra loro attraverso il National Council of ISACs, che mantiene una visione d’insieme tra i diversi comparti.

Che cosa fa un ISAC

Il compito di un ISAC si riassume in tre verbi: raccogliere, analizzare, distribuire. Raccoglie dai propri membri segnalazioni su incidenti, indicatori di compromissione e tecniche d’attacco osservate; le analizza e le arricchisce di contesto, separando il rumore dai segnali rilevanti; e restituisce ai membri intelligence utilizzabile, spesso accompagnata da indicazioni pratiche di mitigazione. Non è un fornitore commerciale che vende un prodotto, ma una struttura senza scopo di lucro alimentata dai suoi stessi aderenti: il suo valore dipende da quanto i membri vi immettono.

Un esempio rende concreto il meccanismo. Una banca aderente individua una nuova campagna di phishing che imita il proprio portale e ne ricava gli indirizzi e i domini coinvolti. Invece di tenere l’informazione per sé, la trasmette all’ISAC del settore finanziario, che la verifica, la mette in relazione con segnalazioni simili arrivate da altri membri e la ridistribuisce all’intera comunità. Nel giro di poche ore, decine di altre banche possono bloccare quei domini prima ancora di essere colpite. La stessa minaccia, vista una volta sola, diventa una difesa per molti, ed è esattamente questo moltiplicatore a giustificare l’esistenza di un ISAC.

Per far circolare quelle informazioni, un ISAC si appoggia agli stessi standard che governano la condivisione tecnica. Le asserzioni viaggiano in formati strutturati e leggibili dalle macchine, e ogni informazione porta con sé un’etichetta di riservatezza che ne stabilisce il raggio di diffusione, secondo convenzioni come il Traffic Light Protocol. È questa infrastruttura comune a permettere che ciò che un membro condivide arrivi agli altri in forma immediatamente azionabile, senza rinegoziare ogni volta le regole.

Perché il settore è la giusta unità di condivisione

La scelta del settore come perimetro non è casuale. Le organizzazioni che operano nello stesso comparto condividono tecnologie simili, gli stessi obblighi normativi e, soprattutto, gli stessi avversari: i gruppi che colpiscono le banche studiano le banche, quelli che prendono di mira la sanità conoscono i sistemi sanitari. In questo contesto, una minaccia rilevata da un’organizzazione è informazione preziosa per tutte le altre, perché con ogni probabilità saranno le prossime sulla lista. Il settore diventa così il cerchio di fiducia naturale, abbastanza ristretto perché ci si possa fidare, abbastanza ampio perché la condivisione produca un vantaggio reale.

Non sorprende che il terreno d’origine degli ISAC siano le infrastrutture critiche: energia, finanza, trasporti, sanità, comunicazioni. Sono i settori in cui un attacco non danneggia soltanto un’azienda, ma può avere conseguenze sull’intera collettività, e in cui quindi la cooperazione tra concorrenti, su questo specifico fronte, smette di essere un paradosso e diventa una necessità.

Gli ISAC in Europa

Anche l’Europa ha adottato il modello, con un percorso più recente ma in rapida crescita. L’ENISA, l’agenzia dell’Unione per la cybersicurezza, sostiene la nascita e il funzionamento degli ISAC settoriali, ne studia i modelli di cooperazione e ne favorisce il coordinamento attraverso una piattaforma comune e incontri periodici tra i centri dei diversi Paesi. Esistono ormai ISAC europei dedicati a comparti come l’energia e la finanza, e la spinta normativa verso lo scambio di informazioni, rafforzata dalla direttiva NIS2, ne sta accelerando la diffusione. La NIS2 incoraggia esplicitamente i soggetti che rientrano nel suo perimetro a scambiarsi informazioni su minacce, vulnerabilità e incidenti, e gli ISAC offrono la cornice organizzata entro cui quello scambio può avvenire in modo continuativo e fidato, anziché episodico.

In questo quadro, gli ISAC si inseriscono nella più ampia costruzione di una resilienza cibernetica europea fondata sulla cooperazione: la convinzione che, di fronte ad avversari che agiscono su scala continentale, la difesa non possa restare confinata dentro i confini di una singola organizzazione o di un singolo Stato. La condivisione settoriale è uno dei modi concreti in cui questa convinzione prende forma operativa.

Il vero ostacolo non è tecnico, è la fiducia

Accanto agli ISAC, negli Stati Uniti è nato il concetto più ampio di Information Sharing and Analysis Organization, le ISAO, pensato per consentire la condivisione anche a gruppi non legati a un singolo settore, con una struttura più flessibile. Ma, al di là delle forme organizzative, la sfida di fondo resta sempre la stessa, e non è di natura tecnologica. Gli standard per scambiare informazioni esistono e funzionano; ciò che è difficile è convincere le organizzazioni a condividere i propri incidenti.

Ammettere di essere stati colpiti, anche solo all’interno di un cerchio ristretto di pari, richiede la certezza che quell’informazione non venga usata contro chi la fornisce, né a fini concorrenziali né reputazionali. È per questo che gli ISAC investono tanto nella fiducia quanto nella tecnologia: regole chiare di riservatezza, possibilità di condividere in forma anonima, una cultura in cui contribuire è la norma e non l’eccezione. È un equilibrio fragile, perché basta qualche membro che riceve senza mai dare per erodere la reciprocità su cui tutto si regge. Un ISAC, in fondo, vale esattamente quanto la disponibilità dei suoi membri a parlare di ciò che preferirebbero tacere.

Gli ISAC non eliminano le minacce, ma cambiano i termini con cui un intero settore le affronta, trasformando l’esperienza isolata di ciascuno in un patrimonio comune. In un panorama in cui gli attaccanti collaborano e si scambiano strumenti con disinvoltura, la capacità dei difensori di fare altrettanto, in modo strutturato e fidato, non è un lusso ma una condizione di sopravvivenza. È questa la promessa degli ISAC: che nessuna organizzazione debba affrontare da sola una minaccia che qualcun altro, nello stesso settore, ha già visto.

Condividi sui Social Network:

https://www.ictsecuritymagazine.com/cyber-security/isac-information-sharing-analysis-center/




La guerra ucraina cambia la cybersecurity delle infrastrutture critiche


La guerra in Ucraina non si combatte solo sul terreno, nel mare o nello spazio aereo. Il cyberspazio è uno degli scenari più attivi, dove vengono perpetrati quotidianamente decine di attacchi mirati alle infrastrutture civili e militari. Il continuo bersagliamento di infrastrutture energetiche, reti di comunicazione e servizi pubblici ha praticamente trasformato l’intero Paese in un enorme laboratorio dove si sviluppa la cyber-resilienza. Ma una cosa è proteggere le infrastrutture critiche civili, un’altra quelle militari e, ovviamente, l’Ucraina non ha abbastanza risorse interne per far fronte all’enorme numero di problemi da affrontare. Per questo è stato creato il Tallinn Mechanism, un’iniziativa internazionale nata per sostenere la resilienza digitale delle infrastrutture civili del Paese e che, indirettamente, sta contribuendo ad accrescere anche le capacità difensive delle aziende europee. Ne abbiamo parlato con Alessio Aceti, CEO di HWG Sababa, azienda impegnata in prima fila.

Cos’è il Tallinn Mechanism

Nonostante il nome possa trarre in inganno, il Tallinn Mechanism non è un organismo con sede in Estonia. Il nome deriva semplicemente dalla città in cui si è svolto il primo incontro istituzionale. Si tratta di un programma internazionale di cooperazione civile che coinvolge diversi Paesi europei, insieme a Stati Uniti e Canada, con l’obiettivo di sostenere la digitalizzazione e la sicurezza delle infrastrutture civili ucraine, comprese quelle considerate critiche. Un elemento distintivo dell’iniziativa è la sua natura prettamente civile. Pur essendo presente come osservatore, la NATO non partecipa direttamente alle attività operative.

Il meccanismo funziona come una piattaforma di collaborazione tra settore pubblico e privato. Le istituzioni ucraine pubblicano le proprie esigenze attraverso un portale dedicato, mentre aziende e organizzazioni dei Paesi aderenti partecipano a bandi finanziati dai governi per fornire competenze, tecnologie e servizi. Dal 1° luglio al 31 dicembre, inoltre, l’Italia assume il coordinamento del programma, con il compito di facilitare la collaborazione tra istituzioni e industria.

La formazione OT per le infrastrutture ucraine e il ritorno per l’Italia

Come già accennato, tra le realtà coinvolte figura HWG Sababa che insieme al Competence Center Cyber 4.0 e a partner francesi si è aggiudicata un progetto dedicato alla formazione sulla sicurezza OT (Operational Technology). L’attività è rivolta ai tecnici che operano nelle infrastrutture critiche ucraine, in particolare nei settori della produzione e distribuzione dell’energia.

L’approccio adottato si discosta dalla formazione tradizionale. Le esercitazioni sono infatti costruite attorno a laboratori pratici nei quali gli operatori lavorano direttamente su PLC, sistemi SCADA e digital substation, simulando attacchi realistici e imparando tecniche di rilevamento, contenimento e risposta in uno scenario caratterizzato da minacce costanti. L’aspetto forse più interessante emerso dall’esperienza raccontata durante l’intervista riguarda il valore che queste attività generano anche per il sistema Paese. L’Ucraina rappresenta infatti uno degli ambienti in cui vengono sperimentate per prime nuove tecniche, tattiche e procedure (TTP) adottate dagli attaccanti. Molte delle infrastrutture utilizzate nel Paese impiegano gli stessi sistemi industriali presenti anche nelle aziende italiane, inclusi prodotti di vendor internazionali come Schneider Electric e ABB. Questo consente agli specialisti coinvolti di osservare direttamente modalità di attacco che potrebbero arrivare successivamente anche nell’Europa occidentale. L’esperienza maturata sul campo permette quindi di anticipare le difese, identificando vulnerabilità e sviluppando contromisure prima che determinate campagne diventino una minaccia concreta anche per le organizzazioni italiane.

La guerra cambia anche il cybercrime

Un altro elemento evidenziato durante l’intervista riguarda l’evoluzione delle minacce. Le tecniche sviluppate dai gruppi riconducibili agli Stati-nazione tendono infatti, con il passare del tempo, a essere riutilizzate anche dalla criminalità informatica tradizionale. Secondo gli esperti, questo fenomeno rischia di accelerare ulteriormente con la diffusione dell’Intelligenza Artificiale, che potrebbe abbassare le competenze necessarie per sviluppare campagne offensive sempre più sofisticate. Di conseguenza, strumenti e metodologie oggi osservati in scenari di guerra potrebbero trasformarsi domani nelle tecniche utilizzate dai gruppi ransomware contro aziende di ogni dimensione.

Cybersecurity e sovranità digitale viaggiano insieme

L’esperienza del Tallinn Mechanism alimenta anche una riflessione più ampia sul tema della sovranità digitale. Secondo quanto emerso nell’intervista, costruire competenze nazionali, sviluppare servizi ad alto valore aggiunto e rafforzare la collaborazione tra imprese italiane rappresenta un elemento fondamentale per ridurre la dipendenza tecnologica dall’estero. In quest’ottica, la federazione di competenze e servizi diventa un fattore strategico non soltanto per la cybersecurity, ma anche per la competitività industriale del Paese.

Condividi l’articolo



Articoli correlati

Altro in questa categoria


https://www.securityinfo.it/2026/07/10/la-guerra-ucraina-cambia-la-cybersecurity-delle-infrastrutture-critiche/?utm_source=rss&utm_medium=rss&utm_campaign=la-guerra-ucraina-cambia-la-cybersecurity-delle-infrastrutture-critiche




Traffic Light Protocol: condividere l’intelligence senza perderne il controllo

Il Traffic Light Protocol è il sistema di etichette che, nella condivisione di informazioni sulle minacce, dice a chi riceve un dato fin dove può ridiffonderlo. Quattro colori, una regola semplice: ogni informazione viaggia con un’etichetta che ne stabilisce il raggio di diffusione, da “solo per te” a “liberamente pubblicabile”. Risolve un problema che precede qualsiasi tecnologia di scambio, perché condividere intelligence richiede fiducia, e senza una convenzione condivisa su cosa il destinatario possa farne le organizzazioni oscillano tra due errori opposti: diffondere troppo, esponendo fonti e operazioni, oppure trattenere tutto, rinunciando ai benefici della condivisione.

Il protocollo non nasce nel mondo della cyber threat intelligence in senso stretto. Secondo il FIRST fu istituito nel 1999 dall’agenzia britannica NISCC per favorire lo scambio di informazioni sensibili tra chi proteggeva le infrastrutture critiche, e si è poi diffuso ben oltre quel perimetro. Lo stesso FIRST, la principale comunità internazionale dei team di risposta agli incidenti, ne ha assunto l’unificazione e la standardizzazione internazionale nel 2015 e oggi ne cura la versione 2.0, autorevole dall’agosto 2022. È diventato la lingua comune con cui CSIRT, comunità settoriali e agenzie governative si scambiano informazioni senza doverne rinegoziare ogni volta le regole di riservatezza.

Le quattro etichette del Traffic Light Protocol

Secondo le definizioni del FIRST, il protocollo prevede quattro etichette, a cui si aggiunge una variante più restrittiva. TLP:RED è il livello massimo di riservatezza: l’informazione è destinata ai soli destinatari individuali a cui è comunicata e non può essere ridiffusa a nessun altro. TLP:AMBER consente una diffusione limitata, all’interno della propria organizzazione e dei propri clienti, ma solo in base al criterio della necessità di conoscere; la sua variante TLP:AMBER+STRICT restringe ulteriormente la condivisione alla sola organizzazione, escludendo i clienti. TLP:GREEN allarga il cerchio alla propria comunità di pari e partner, ma vieta la pubblicazione su canali aperti. TLP:CLEAR, infine, non pone limiti: l’informazione può essere diffusa liberamente, nel rispetto delle normali regole sul diritto d’autore.

La forza dello schema sta nella sua semplicità. Pochi livelli, un colore, nessun manuale da consultare: chi riceve un’informazione marcata sa immediatamente cosa può farne.

Un esempio rende concreta la logica. Un centro di condivisione settoriale individua un nuovo indirizzo di comando e controllo usato in una campagna in corso e lo distribuisce ai propri membri marcandolo come TLP:AMBER. Ogni azienda che lo riceve può inserirlo nei propri strumenti di difesa e avvisare i clienti direttamente esposti, ma non può pubblicarlo né girarlo a soggetti esterni alla propria organizzazione. Se la stessa informazione fosse marcata TLP:GREEN, le aziende potrebbero condividerla con i partner della loro comunità; se fosse TLP:RED, dovrebbe restare nelle mani dei soli destinatari della comunicazione originaria. La stessa informazione, lo stesso valore difensivo, ma un confine di diffusione diverso deciso da chi la mette in circolo.

Una convenzione, non un controllo tecnico

Il punto che spesso si fraintende è che il Traffic Light Protocol non è un meccanismo di sicurezza tecnica. Non cifra nulla, non impedisce materialmente la ridiffusione, non è un sistema di gestione dei diritti digitali. È una convenzione fondata sulla fiducia: l’etichetta accompagna l’informazione e vincola chi la riceve, ma la sua efficacia dipende dal rispetto reciproco, non da un controllo automatico. Chi tradisce un’etichetta TLP non viola un sistema, viola un patto, e la sanzione è reputazionale: l’esclusione dai circuiti di condivisione che rendono utile far parte di una comunità di intelligence.

Questa natura spiega anche cosa il protocollo non fa. Non stabilisce come l’informazione vada conservata o protetta, né con quali misure tecniche, ma regola soltanto la sua ridistribuzione. Decidere fin dove un’informazione può spingersi spetta sempre alla fonte che la produce, non a chi la riceve, ed è la fonte ad apporre l’etichetta al momento della condivisione.

Proprio perché la scelta dell’etichetta spetta alla fonte, il rischio più diffuso non è la diffusione eccessiva ma il suo opposto: la tentazione di sovra-classificare. Marcare tutto come TLP:RED per eccesso di prudenza svuota di senso il protocollo, perché trasforma ogni scambio in un vicolo cieco e impedisce all’informazione di raggiungere chi potrebbe usarla per difendersi. Una buona pratica di condivisione richiede di assegnare l’etichetta più aperta che il rischio consente, non la più chiusa che l’ansia suggerisce. È un equilibrio di giudizio, e il Traffic Light Protocol fornisce il vocabolario per esprimerlo, non la regola per deciderlo al posto della fonte.

Che cosa è cambiato con la versione 2.0

La revisione del 2022 ha introdotto due cambiamenti sostanziali rispetto alla versione precedente. Il primo è la sostituzione dell’etichetta TLP:WHITE con TLP:CLEAR, una scelta lessicale pensata per rendere più immediato il significato di “nessuna restrizione” ed evitare ambiguità. Il secondo è l’aggiunta di TLP:AMBER+STRICT, che colma una zona grigia della versione precedente distinguendo i casi in cui la condivisione può estendersi ai clienti da quelli in cui deve restare confinata alla sola organizzazione. Insieme a una serie di affinamenti del linguaggio, questi ritocchi hanno reso il protocollo più preciso senza appesantirne l’uso.

Il TLP nel flusso della threat intelligence

Collocato nel processo di condivisione, il Traffic Light Protocol è ciò che rende praticabile la disseminazione di informazioni sensibili. Si integra con gli standard tecnici di scambio, che prevedono campi appositi per trasportare l’etichetta insieme al dato, così che la marcatura sopravviva al passaggio da uno strumento all’altro; lo stesso FIRST precisa però che l’uso del TLP negli scambi automatizzati non è definito dallo standard ed è lasciato a chi progetta quei sistemi. È particolarmente prezioso negli ecosistemi in cui molte organizzazioni dipendono le une dalle altre, come una supply chain estesa, dove un’informazione su una minaccia deve raggiungere rapidamente più soggetti senza però finire in mani sbagliate. Non a caso agenzie come la CISA lo hanno adottato come modalità ordinaria per classificare ciò che pubblicano e ciò che condividono in modo riservato: la CISA è passata ufficialmente al TLP 2.0 il 1° novembre 2022.

Va aggiunta una precisazione, per evitare un equivoco frequente: il Traffic Light Protocol non è un sistema di classificazione di sicurezza nel senso giuridico del termine. Non sostituisce le categorie di riservatezza previste da normative o contratti, né conferisce alcuno status legale all’informazione. Opera su un piano diverso e complementare, quello della prassi operativa tra chi condivide, e proprio per questo funziona attraverso i confini organizzativi e nazionali, dove categorie giuridiche differenti renderebbero altrimenti difficile capirsi. È un linguaggio comune sovrapposto, non un’alternativa, alle regole formali di ciascuna organizzazione.

Il Traffic Light Protocol non aggiunge sicurezza a un’informazione, aggiunge chiarezza su come trattarla, ed è proprio questa chiarezza a sbloccare la condivisione. In un settore in cui il valore dell’intelligence dipende dalla velocità con cui circola e dalla fiducia di chi la mette in comune, una convenzione semplice e universalmente compresa vale più di qualunque controllo sofisticato. Adottare il TLP significa accettare un patto: condividere di più, perché si sa esattamente fin dove ciò che si condivide potrà arrivare.

Fonti

Condividi sui Social Network:

https://www.ictsecuritymagazine.com/cyber-security/traffic-light-protocol/