Dr. Joye Purser, PhD, spent 20 years working in Washington D.C., shaping national technology policy. First, Dr. Purser worked as a legislative assistant in the U.S. House of Representatives, working on the policy agenda for the Chair of the House Committee on Science and Technology. Hired by the Pentagon, Dr. Purser audited programs such as financial management to military communication systems.
“I realized that my knowledge and skills could help drive efficient operations as well as technical eminence, ultimately safeguarding the freedoms we hold dear,” Dr. Purser says.
Dr. Purser then moved to work for the Office of Management and Budget, serving as the subject matter expert for Defense Technology. She examined the defense research portfolio to ensure it was aligned with Presidential and other government priorities.
“In response to growing risks in microelectronics, I brought together a multi-agency group of technology leaders to build consensus and coordinate government-wide investments aimed at securing and strengthening the semiconductor supply chain,” Dr. Purser says.
In addition, Dr. Purser led high-impact communications with both legislative and executive branch leaders. She consulted on national strategies for military technology, research and sensitive communications. Dr. Purser describes working for the government as “heart work”, as everyone involved is driven by the same central mission for their organization.
Silicon Valley has increasingly turned to security professionals like me, those with military or defense backgrounds, because tech companies are under attack and need to strengthen security.
From here, Dr. Purser transitioned to the private sector. She worked on enterprise risk management before an unexpected shift during the pandemic. Dr. Purser helped the CDC with the Continuity of Operations plan at the height of the pandemic, and also helped with post-pandemic recovery.
“I was selected to lead Region 4 at the Cybersecurity and Infrastructure Security Agency (CISA) within the Department of Homeland Security. I served as the first senior executive in that position, doubling the field operations force and guiding the government response to the Colonial Pipeline attack,” Dr. Purser says.
Currently, Dr. Purser serves the Global Field Chief Information Security Officer (CISO) at Cohesity. Dr. Purser’s work includes international travel to work with critical infrastructure owners and manage various security risks.
“Silicon Valley has increasingly turned to security professionals like me, those with military or defense backgrounds, because tech companies are under attack and need to strengthen security,” Dr. Purser says.
During her time here, Dr. Purser has witnessed the trend of the technology and business sectors are strengthening their security efforts to protect their assets and customers.
Dr. Purser describes transitioning from the public to private sector as “exciting, meaningful and rewarding”. She’s been able to challenge herself with each new problem to solve, especially with how drastically the world has changed since she entered the security field. Dr. Purser learned to adapt to different priorities and risk levels, gaining additional perspectives from each role.
“Having worked in these settings has imparted a giant advantage in terms of the advice that I am able to communicate to my teams,” Dr. Purser says.
In addition, Dr. Purser works with a number of nonprofit organizations. She coaches YearUp apprentices in research and presentation skills to better develop their careers. Dr. Purser also works with Mahima Home, an organization and foster care community that helps survivors of human trafficking.
Dr. Purser’s leadership style is the perfect blend of warmth and assertiveness.
“My approach is rooted in the idea that every organization, no matter its size or sector, needs a security culture to protect its people and operations,” Dr. Purser says. The increasing sophistication of cyber threats meant that security leaders need to expand their skillsets. “I’m especially passionate about showing other women in cybersecurity that leadership doesn’t have to be loud to be powerful — and that vision, when clearly communicated, can shape real change,” Dr. Purser says.
The tragic events of September 11, 2001 was a life changing moment for Americans and for Joella Dunn-Bernstein things were no different. As a 12-year-old living in New Jersey, Dunn-Bernstein witnessed first-hand the impact on her community and that experience informed the direction her life would take.
“I saw a lot of people suffering and I wanted to prevent that from happening again,” she recalls.
With that goal in mind, Dunn-Bernstein completed a Master’s Degree in Counterterrorism and Homeland Security from Reichman University. Many of her professors encouraged Dunn-Bernstein to pursue a career in government, however despite the strong advice, she preferred more flexibility and different career dynamics.
When she was first introduced to the world of corporate security — by her now-husband — Dunn-Bernstein knew it was the right fit.
“There are so many interesting things to do in that sphere,” she says.
Growing Career
Dunn-Bernstein officially started her security career as a watch officer in The World Bank’s Global Security Operations Center (GSOC), where she became fascinated in the emergency management and intelligence portions of the job. From there, she moved from D.C. to Los Angeles after accepting a position as an intelligence analyst doing contract work for Fortune 50 companies. In 2019, Dunn-Bernstein joined The Jewish Federation of Los Angeles as an Intelligence Analyst and then the Head of Intelligence. There she had the opportunity to not only develop and hone her intelligence skills, but also learn about the physical security side of things that empower communities to keep themselves safe.
During her time with The Jewish Federation of Los Angeles, Dunn-Bernstein was tasked to help protect and prepare the LA Jewish community through intelligence gathering, security training and coordination with law enforcement. She led active shooter, situational awareness, and digital footprint training.
“An important aspect of the job was empowering the community to really understand the threats that might be presented to them,” Dunn-Bernstein said.
In 2024 Dunn-Berstein joined JetZero — an aerospace startup based in Long Beach, California — as the Head of Security. There she blends her experience in the intelligence, executive protection, and corporate security functions with real-world experience on a global scale.
“With The Jewish Federation, there are some very real threats in the physical space, and at JetZero industrial espionage is the primary concern here. But in either case, you’re taking the necessary steps to protect the incredible things and people.”
People will always be the weakest link, so strengthening folks through education and awareness to help them understand that security is a shared responsibility is important.
The Secret to Success
When thinking back on her success in the security industry, Dunn-Bernstein gives credit to knowing what she wanted and going for it.
“I’ve always told people what I wanted. I couldn’t expect someone to read my mind,” she says. “For instance, I loved being an analyst, especially at the Jewish Federation, but I expressed to a director that I wanted to learn more about the rest of the security world. I didn’t want to be pigeonholed my entire career. I loved it, but I knew that I wanted more, and I asked for more opportunities.”
She recalls that director making a conscious effort to push her out of her comfort zone and pull her into meetings, projects, training and different events that she may not have been a part of otherwise.
Another key part of a successful security career, Dunn-Bernstein continues, is knowing what you don’t know and when to ask for help.
“I’m really fortunate to have mentors and friends in different parts of the security industry who have decades of experience,” she says. “If I can’t find an effective and creative solution to a problem, I have a very small handful of trusted people who have likely encountered a similar issue and we help each other figure things out.”
Dunn-Bernstein says she likes the information and intelligence gathering and analysis portion of Security, citing the innovation of the private sector.
“Law enforcement agencies don’t carry that burden alone,” she says. “I find that the intel in the private sector is much more nimble and able to pivot to address the immediate concerns that we have, whereas my friends or acquaintances in the government sector have a harder time.”
Encouraging Empowerment
The security field is ever-evolving with each day bringing new challenges. It is that constant progression that keeps many security leaders in the profession. In addition to rising to new and interesting challenges, Dunn-Bernstein embraces the opportunity to encourage empowerment in individuals and communities.
“People will always be the weakest link, so strengthening folks through education and awareness to help them understand that security is a shared responsibility is important,” she says. “You get better results and information from a population that is educated about security and risk.”
When she first got into the security field, Dunn-Bernstein says she thought a lot of things in the industry were black and white.
“As I grew in my career, I have learned that there’s so much more nuance to those things, and engaging with groups of people who aren’t traditionally enmeshed in security and finding approachable ways for them to empower themselves and keep themselves safe was something that really helped to shape the way that I look at things, the way that I understand where someone is coming from,” she says. “That’s something that really resonated with me, and something I take to heart.”
Jewel Singh’s security career began at IBM, moving from sales to IT and data analytics. In 2015, Singh assumed the role as the India/South Asia CIO IT Business Operations Manager by leading the IT and analytics departments. Under Singh’s guidance, CIO ThinkDesks were set up across India for walk-in IT support. Singh was instrumental to building IT infrastructure across the region.
In 2019, Singh took a position to lead the India Employee Transport Safety & Operations department.
“The constant challenge, risks and uncertainties associated with Security made the role appealing. I see challenges as opportunities for growth, calculated risk-taking and a way to demonstrate our duty of care purpose, which I am passionate about,” Singh says.
Singh’s role involved ensuring a safe and secure nightly commute for women utilizing the transportation system, as required by India’s transport regulations. This included improving operations through software as a service (SaaS), strengthening regulatory compliance such as vehicle and driver safety regulations. In addition, Singh has worked to build up 24/7 control centers, panic alarms, incident reporting and response.
“We provide a safe, secure and compliant commute for thousands of employees across multiple cities across India, exceeding industry best on-time arrivals, on-time departures, employee trip feedback rating and other metrics,” Singh says.
With the rise in workplace violence and social unrest, it’s more important than ever for security leaders to place protections for their employees. This is especially true for night shift workers, who often work with a reduced staff and a unique set of security risks. Navigating densely populated cities creates its own challenges, as it can be difficult to thoroughly cover all of a building’s access points.
Singh’s role expanded to include corporate security operations, where she works to improve security risk culture, scaling access management and developing stronger crisis management.
“A typical workday begins with acute focus on the previous night’s employee transport operations, and any new or in progress critical events/crisis being tracked across APAC-J region and globally before getting down to prioritize tasks for the day,” Singh says. The scope of Singh’s coverage means a busy schedule, as there’s almost always something that requires her immediate attention. Singh also works with leaders across the area to coordinate system maintenance and ensure everyone is aligned with the current milestones and regulations.
“Technology and IT was never in my career plan,” Singh says, but that didn’t stop her from excelling with each position she held. Throughout her career, Singh learned to lead even when her team was scattered around the world. She worked to not only meet current regulations but to go above and beyond to protect her employees. Singh has led her team to win several awards for their service, safety compliance, and sustainable transportation methods. Her career has blended physical and cyber security to strengthen her organization and keep people safe.
Crittografia post-quantistica PQC: la transizione verso algoritmi resistenti al quantum computing
La crittografia post-quantistica (PQC) rappresenta uno dei pilastri fondamentali per la sicurezza informatica del futuro, configurandosi come risposta strategica all’imminente minaccia rappresentata dai computer quantistici crittograficamente rilevanti (CRQC). Con l’accelerazione della ricerca nel campo del quantum computing, la comunità della cybersecurity si trova di fronte alla necessità di ripensare radicalmente i paradigmi crittografici consolidati, implementando algoritmi resistenti alle capacità computazionali quantistiche.
Standard NIST crittografia post-quantistica: Il quadro normativo 2024
Il National Institute of Standards and Technology (NIST) ha finalizzato il suo principale set di algoritmi di crittografia progettati per resistere agli attacchi informatici di un computer quantistico, pubblicando nell’agosto 2024 i primi tre standard FIPS (Federal Information Processing Standards) per la crittografia post-quantistica.
Gli standard pubblicati comprendono:
FIPS 203 – Module-Lattice-Based Key-Encapsulation Mechanism Standard (ML-KEM)
FIPS 203 specifica uno schema crittografico chiamato Module-Lattice-Based Key-Encapsulation Mechanism Standard, derivato dalla submission CRYSTALS-KYBER. Questo meccanismo di incapsulamento delle chiavi rappresenta la soluzione primaria per la crittografia generale, caratterizzato da chiavi di crittografia relativamente piccole e velocità operativa ottimizzata.
Il ML-KEM supporta tre varianti parametriche:
ML-KEM-512: livello di sicurezza 1 (equivalente ad AES-128)
ML-KEM-768: livello di sicurezza 3 (equivalente ad AES-192)
ML-KEM-1024: livello di sicurezza 5 (equivalente ad AES-256)
FIPS 204 – Module-Lattice-Based Digital Signature Standard (ML-DSA)
FIPS 204 specifica il Module-Lattice-Based Digital Signature Standard, derivato dalla submission CRYSTALS-Dilithium. Questo algoritmo, originariamente noto come CRYSTALS-Dilithium, costituisce lo standard primario per la protezione delle firme digitali, utilizzando un approccio basato su reticoli modulari.
FIPS 205 – Stateless Hash-Based Digital Signature Standard (SLH-DSA)
FIPS 205 specifica il Stateless Hash-Based Digital Signature Standard, derivato dalla submission SPHINCS+. Questo standard implementa un algoritmo di firma digitale basato su funzioni hash, progettato come metodo di backup nel caso in cui ML-DSA dovesse rivelarsi vulnerabile.
L’algoritmo HQC come standard di backup
HQC è stato selezionato per la standardizzazione l’11 marzo 2025, rappresentando il quinto algoritmo per la crittografia asimmetrica post-quantistica. “Le organizzazioni dovrebbero continuare a migrare i loro sistemi di crittografia agli standard che abbiamo finalizzato nel 2024. Stiamo annunciando la selezione di HQC perché vogliamo avere uno standard di backup basato su un approccio matematico diverso da ML-KEM”, ha dichiarato Dustin Moody, matematico del NIST.
La minaccia “Harvest Now, Decrypt Later” e la sua rilevanza strategica
La strategia “harvest now, decrypt later” è una strategia di sorveglianza che si basa sull’acquisizione e conservazione a lungo termine di dati crittografati attualmente illeggibili in attesa di possibili sviluppi nella tecnologia di decrittazione che li renderebbero leggibili in futuro.
Caratteristiche degli attacchi HNDL
Gli attacchi HNDL presentano caratteristiche distintive che li rendono particolarmente insidiosi:
Stealth operativo: Uno degli aspetti più insidiosi degli attacchi HNDL è che non saprai quando i tuoi dati sono stati rubati. Gli attori delle minacce possono catturare dati crittografati ora e decrittarli anni dopo una volta che i computer quantistici lo permettono.
Targeting strategico: La strategia centrale di “harvest now, decrypt later” è semplice: raccogliere quanti più dati possibile e prepararsi a decrittarli in futuro. Questa è una strategia orientata agli obiettivi, e i cybercriminali sono tutt’altro che casuali nei loro sforzi.
Valore temporale dei dati: Attualmente, i segreti commerciali, l’intelligence aziendale e le tecnologie emergenti sono i dati più a rischio.
L’urgenza della transizione
Alcuni segreti rimangono preziosi per molti anni. Anche se un avversario non può craccare la crittografia che protegge i nostri segreti al momento, potrebbe comunque essere vantaggioso catturare dati crittografati e conservarli, nella speranza che un computer quantistico riesca a violare la crittografia in futuro.
La finestra di vulnerabilità è già aperta, considerando che i dati sensibili crittografati oggi potrebbero essere compromessi quando i computer quantistici raggiungeranno una potenza sufficiente.
Algoritmi di Shor e l’impatto sui sistemi crittografici attuali
L’algoritmo di Shor, sviluppato nel 1994, rappresenta la minaccia principale per i sistemi crittografici attuali. L’algoritmo di Shor permette a un computer quantistico di fattorizzare grandi numeri interi esponenzialmente più velocemente di qualsiasi algoritmo classico conosciuto, un attacco diretto alla sicurezza di RSA, DSA e ECC.
Questa capacità computazionale quantistica renderebbe vulnerabili tutti i sistemi che dipendono dalla difficoltà computazionale della fattorizzazione di numeri primi grandi o del logaritmo discreto, fondamenta della crittografia asimmetrica contemporanea.
Strategie di migrazione e crypto-agility
Principi di crypto-agility
L’agilità crittografica come soluzione per le transizioni crittografiche attraverso protocolli, applicazioni e infrastrutture rappresenta un approccio strategico fondamentale. I principi chiave includono:
Implementazione modulare della crittografia: I sistemi dovrebbero essere progettati per permettere la sostituzione degli algoritmi crittografici facilmente, evitando scelte crittografiche hard-coded nel software.
Approcci crittografici ibridi: Una strategia per la transizione alla PQC prevede l’uso di algoritmi crittografici ibridi, che combinano algoritmi classici e quantum-resistenti.
Monitoraggio continuo: Monitorare continuamente le prestazioni PQC, la compatibilità e gli aggiornamenti algoritmici emergenti.
Fasi della migrazione
La migrazione verso la crittografia post-quantistica richiede un approccio sistematico articolato in fasi specifiche:
Fase 1: Assessment e inventario crittografico
Una volta identificati i componenti di crittografia a chiave pubblica e gli asset associati nell’enterprise, l’elemento successivo dello scope del progetto è dare priorità a quei componenti che devono essere considerati per primi nella migrazione utilizzando una metodologia di gestione del rischio.
Fase 2: Implementazione di soluzioni ibride
Testare algoritmi ibridi nel proprio ambiente Windows, simulare lo scambio di chiavi con ML-KEM e RSA insieme, utilizzare API per costruire app pilota con forward secrecy.
Fase 3: Transizione completa e monitoraggio
Una volta distribuita, la PQC non è “imposta e dimentica”. Il monitoraggio continuo e l’adattamento sono essenziali.
Sfide tecniche e considerazioni implementative
Caratteristiche prestazionali degli algoritmi PQC
Gli algoritmi basati su reticoli quando progettati correttamente sono in realtà più efficienti degli algoritmi utilizzati oggi. Anche se potrebbero essere più grandi della crittografia classica, il loro tempo di esecuzione è più veloce degli algoritmi classici basati su RSA discreto più grande o curve ellittiche.
Compatibilità e interoperabilità
La transizione richiede considerazioni specifiche per:
Dimensioni delle chiavi e delle firme: Gli algoritmi PQC utilizzano tipicamente chiavi e firme di dimensioni maggiori rispetto agli algoritmi classici
Requisiti computazionali: Necessità di valutare l’impatto sulle prestazioni dei sistemi esistenti
Protocolli di comunicazione: Adattamento di TLS, SSH e altri protocolli standard
Raccomandazioni strategiche per i professionisti della cybersecurity
Immediate
Avvio della pianificazione strategica: “Non c’è bisogno di aspettare standard futuri. Procedete e iniziate a usare questi tre. Dobbiamo essere preparati nel caso di un attacco che sconfigga gli algoritmi in questi tre standard”.
Inventario crittografico: Identificazione sistematica di tutti i componenti crittografici nell’infrastruttura organizzativa.
Valutazione del rischio: Classificazione dei dati in base alla loro sensibilità temporale e valore strategico.
A medio termine
Implementazione di prototipi: Sviluppo di ambienti di test per gli algoritmi NIST-standardizzati.
Formazione del personale: Aggiornamento delle competenze tecniche per gestire le nuove implementazioni crittografiche.
Aggiornamento delle policy: Revisione e aggiornamento delle politiche di sicurezza per incorporare i requisiti PQC.
A lungo termine
Migrazione scalabile: Implementazione graduale della crittografia post-quantistica attraverso l’intera infrastruttura.
Monitoraggio continuo: Estabellimento di sistemi di monitoraggio per rilevare vulnerabilità emergenti e aggiornamenti algoritmici.
Preparazione per futuri standard: Mantenimento dell’agilità crittografica per incorporare eventuali nuovi algoritmi o standard di backup.
Conclusioni e prospettive future
La crittografia post-quantistica non rappresenta semplicemente un aggiornamento tecnologico, ma una trasformazione paradigmatica dell’approccio alla sicurezza informatica. La tecnologia del quantum computing si sta sviluppando rapidamente, e alcuni esperti prevedono che un dispositivo con la capacità di violare i metodi di crittografia attuali potrebbe apparire entro un decennio.
La pubblicazione degli standard NIST FIPS 203, 204 e 205 segna un momento decisivo per l’industria della cybersecurity. Le organizzazioni che adotteranno proattivamente questi standard otterranno un vantaggio competitivo significativo, mentre quelle che ritarderanno la transizione si troveranno esposte a rischi crittografici crescenti.
L’implementazione della crittografia post-quantistica richiede un approccio olistico che integri considerazioni tecniche, strategiche e operative. La crypto-agility emerge come competenza fondamentale, permettendo alle organizzazioni di adattarsi rapidamente all’evoluzione del panorama delle minacce quantistiche.
Il futuro della cybersecurity dipenderà dalla capacità delle organizzazioni di anticipare, pianificare e implementare efficacemente questi nuovi paradigmi crittografici, garantendo la continuità della protezione dei dati sensibili nell’era quantistica imminente.
Il Sinaloa, un cartello messicano, è riuscito ad hackerare alcuni dispositivi dell’FBI per identificare potenziali testimoni e ucciderli. Stando a quanto si legge sul blog dei MalwareBytes Labs, il gruppo ha compromesso alcune videocamere per poi ascoltare le conversazioni del personale per individuare i testimoni.
In riferimento all’accaduto, in un report pubblicato lo scorso giugno il Dipartimento di Giustizia statunitense ha dettagliato la cosiddetta “Ubiquitous Technical Surveillance” (UTS), un tipo di minaccia che si riferisce alla raccolta e alla memorizzazione a lungo termine di informazioni usate poi per analizzare specifiche persone e collegarle con altre figure, attività od organizzazioni.
Gli attaccanti che adottano questo tipo di comportamento possono fare uso di foto e immagini di persone o intercettare chiamate per ricostruire la rete di conoscenze di un obiettivo. Gli hacker sono inoltre in grado di analizzare le transazioni finanziarie, entrare in possesso delle eventuali prenotazioni delle vittime e monitorare la loro presenza online.
Nel caso di Sinaloa, il gruppo ha assunto un hacker che aveva spiato le persone che entravano e uscivano dall’Ambasciata degli Stati Uniti a Città del Messico per identificare le “persone di interesse”. Il cybercriminale assoldato dal cartello ha preso di mira in particolare un’assistente del Legal Attache dell’FBI ed è riuscito ad accedere alle chiamate ricevute e inviate dal suo dispositivo, così come i dati di geolocalizzazione.
Secondo l’FBI, l’hacker avrebbe inoltre sfruttato il sistema di telecamere di Città del Messico per identificare le persone con cui l’agente si incontrava; l’obiettivo era appunto di usare queste informazioni per intimidire o uccidere testimoni che collaboravano con le forze dell’ordine per smantellare il cartello.
L’attività di spionaggio si è verificata nel 2018, ma è stata resa nota solo adesso. Attualmente i cartelli messicani continuano a eseguire campagne di spionaggio di questo genere. Nel report, il Dipartimento di Giustizia ha analizzato la strategia di risposta dell’FBI alla minaccia dell’UTS, ritenendola non adeguata e affermando che “la strategia non definirà linee di azione chiare per quando l’FBI dovrà rispondere a incidenti di sicurezza legati all’UTS“.
Scoperti due gravi bug in Sudo, il celebre strumento da riga di comando utilizzato nei sistemi Linux e Unix-like per l’esecuzione di comandi con privilegi elevati. Le vulnerabilità, segnalate dal ricercatore Rich Mirch di Stratascale, potrebbero essere sfruttate da utenti locali non privilegiati per ottenere accesso root su macchine vulnerabili. Una delle due falle, la più critica, ha ottenuto un punteggio CVSS di 9.3.
Il progetto Sudo ha corretto entrambe le falle nella versione 1.9.17p1, rilasciata a fine giugno 2025, dopo una disclosure responsabile avvenuta lo scorso 1 aprile. I principali vendor Linux, tra cui Ubuntu, Red Hat, Debian e SUSE, hanno già pubblicato avvisi di sicurezza e aggiornamenti correttivi.
CVE-2025-32463: escalation di privilegi tramite chroot
La vulnerabilità più grave tra le due è CVE-2025-32463, che coinvolge l’opzione -R di Sudo, usata per cambiare la root directory durante l’esecuzione di un comando. Un utente locale può creare una directory arbitraria contenente un file /etc/nsswitch.conf manipolato, sfruttando il fatto che il comando Sudo, in alcuni casi, carica librerie condivise sulla base di quella configurazione.
Questo permette l’esecuzione di codice arbitrario con privilegi di root, anche se l’utente non dispone di alcuna regola nel file sudoers. La configurazione predefinita di Sudo è vulnerabile, e la falla non richiede complesse interazioni o conoscenze approfondite per essere sfruttata.
Todd C. Miller, maintainer del progetto Sudo, ha annunciato che l’opzione chroot sarà completamente rimossa nelle prossime release, definendola “intrinsecamente soggetta a errori” e difficilmente difendibile in modo sicuro.
CVE-2025-32462: un bug silenzioso che esiste da oltre 12 anni
Meno pericolosa ma comunque degna di nota è CVE-2025-32462, con punteggio CVSS pari a 2.8. Questa vulnerabilità riguarda l’uso dell’opzione -h per specificare un host alternativo nel comando Sudo. Se il file sudoers include regole che si applicano a macchine diverse dalla corrente, un utente potrebbe eseguire comandi destinati a un altro host direttamente sulla macchina locale.
Il bug è presente dal 2013, anno in cui fu introdotto il supporto per l’opzione host nel comando Sudo. La falla può avere conseguenze significative in ambienti dove il file sudoers è condiviso su più sistemi, come accade spesso nelle infrastrutture basate su LDAP o su file sudoers centralizzati tramite SSSD.
Distribuzioni coinvolte e mitigazioni
Entrambe le falle sono state risolte nella versione 1.9.17p1 di Sudo. Le distribuzioni che hanno rilasciato patch per CVE-2025-32463 includono Ubuntu, Debian, Red Hat, SUSE, Gentoo, Amazon Linux e Alpine Linux. La vulnerabilità CVE-2025-32462 è stata invece corretta anche su AlmaLinux 8 e 9 e Oracle Linux.
Tutti gli utenti Linux sono invitati ad aggiornare i pacchetti Sudo il prima possibile, in particolare se utilizzano configurazioni avanzate o ambienti multi-host, dove le vulnerabilità possono avere impatti più estesi.
As we celebrate the Fourth of July — America’s enduring symbol of freedom and independence — now is a fitting time to reflect on another kind of independence: the critical, and increasingly endangered, independence of cybersecurity assessments and risk analyses.
In today’s rapidly evolving threat landscape, organizations are under constant pressure to defend digital borders, monitor operations, and comply with complex regulatory requirements. To meet these demands, many turn to outside firms for assessments, audits, and cyber risk consulting.
But a troubling trend is growing: the merging of advisory firms that provide independent assessments with companies that offer security monitoring, incident response, and operational information technology (IT) services. This convergence, while marketed as “integrated” or “end-to-end” solutions, risks eroding one of the most important values in cybersecurity governance — independence.
Just as the Founding Fathers recognized the need to separate powers and establish checks and balances to avoid conflicts of interest, modern organizations must ensure their cybersecurity risk assessments remain free from undue influence or self-interest. A loss of independence can compromise the credibility of findings, hinder risk transparency, and reduce trust among stakeholders — from regulators and boards to patients and customers.
Mergers and the Muzzling of Objectivity
The cybersecurity market is maturing, and with that maturity has come consolidation. Large managed security service providers (MSSPs) and technology vendors are acquiring advisory firms that once provided independent risk analysis. These consolidations are often framed as synergies — pairing risk identification with real-time threat management under a single umbrella. On the surface, this practice seems efficient.
But imagine asking your building inspector to also sell you the materials for repair and then manage the construction. Would you trust that the assessment was unbiased? Or would you suspect the report might overemphasize issues that lead to billable remediation work? That same skepticism should apply when cybersecurity assessors work for — or are owned by — the same companies that profit from the operational fixes they recommend.
The Role of Independence in Effective Cyber Risk Analysis
True independence in cyber assessment isn’t just a best practice — it’s a foundational element of sound risk management. Independence allows organizations to:
Identify blind spots honestly: Without bias toward specific tools, platforms, or outcomes
Prioritize risk based on actual exposure: Not on what can be most easily mitigated with the solutions a vendor already sells
Demonstrate integrity to external stakeholders: Especially in regulated industries like healthcare, finance, and defense
Strengthen governance: By ensuring that risk decisions are based on facts and not influenced by sales objectives
Much like the independence of the judiciary in a functioning democracy, cyber assessments must remain detached from the operational tactics of monitoring, detection, and incident response. The assessor must be free to say, “This is broken,” even when that assessment leads to uncomfortable truths — or lost contracts.
Independence Is No Afterthought
Regulators increasingly recognize the importance of independent assessments. Frameworks like HIPAA, Cybersecurity Maturity Model Certificate, and ISO 27001 emphasize third-party or objective review. Auditors and certifying bodies are expected to maintain arm’s-length relationships with implementers and service providers. This practice is not bureaucratic red tape — it’s a safeguard against conflicts of interest that could compromise both data security and public trust.
We’ve seen this before in financial auditing. After the collapse of Enron and the downfall of Arthur Andersen, regulations like the Sarbanes-Oxley Act were implemented to ensure the independence of financial auditors. Why? Because auditors who also provided consulting and implementation services were often incentivized to overlook risky behavior.
Cybersecurity is now in that same critical phase of professional evolution.
What Organizations Should Demand this Independence Day
On this holiday that commemorates America’s break from dependence on external powers, organizations should declare their own cyber-independence by adopting three key practices:
1. Separate the Assessors from the Operators
Avoid using the same vendor for both security assessments and implementation or monitoring services. If you must, ensure they operate under strict separation-of-duties policies, with clearly defined firewalls between teams.
2. Demand Transparency about Ownership and Incentives
Ask your assessment provider: Who owns you? What other services do you sell? Are your recommendations influenced by your parent company’s product lines or remediation offerings?
3. Ensure Governance Includes External Oversight
Include independent voices in your cyber governance process. Whether it’s a board-level technology committee, an external audit firm, or an advisory council, independent perspectives challenge groupthink and drive accountability.
Independence Is Not Inefficiency — It’s Integrity
Some vendors will argue that combining assessments with remediation services leads to faster response times, improved continuity, or cost savings. While there is some truth to that claim, speed should never come at the cost of integrity. Independence doesn’t mean slower — it means smarter. It means the people identifying your risks aren’t also profiting from fixing them. It means you can trust what you’re told.
Liberty and Cyber Vigilance
The American Revolution was fueled by the idea that power must be kept in check and that independence is worth fighting for — even at great cost. In our digital age, that same principle applies to how we manage risk and safeguard information.
Let this Independence Day serve not only as a celebration of freedom from political tyranny but also as a call to reaffirm the freedom of our assessments from commercial influence. As you watch fireworks light up the sky, remember: The brightest beacon in cybersecurity is still the truth. And truth requires independence.
Barry Mathis, Managing Principal of IT Advisory Consulting at PYA. Barry has over three decades of experience in the information technology (IT) and healthcare industries as a CIO, CTO, senior IT audit director, and IT risk management consultant. Image courtesy of Mathis
Questo approfondimento fa parte della serie dedicata alle tecniche di onboarding sicuro dei dispositivi IoT in piattaforma cloud. L’articolo esplora tre metodologie principali: l’autenticazione basata su informazioni hardware e di connessione, l’utilizzo di credenziali statiche precaricate, e l’implementazione di certificati a mutua autenticazione x.509. Viene analizzata in dettaglio ogni tecnica, evidenziandone vantaggi, svantaggi e considerazioni di sicurezza nel contesto delle moderne piattaforme cloud come AWS.
Tecniche di Onboarding IoT: Metodi di Autenticazione e Sicurezza
L’onboarding può avvenire contattando un servizio oppure un intermediario che accetta operazioni di pubblicazione e sottoscrizione da parte dei dispositivi (il broker usato nei paradigmi di comunicazione Message Oriented Middleware). Indipendentemente dalla modalità di scambio scelta con la piattaforma, possiamo distinguere questi approcci basandoci sul tipo di dati scambiato per il riconoscimento della legittimità del dispositivo alla comunicazione.
Primo metodo. Utilizzo di Informazioni sulla connessione e l’hardware
In questo metodo la piattaforma ricorre alle informazioni correnti di connessione usate dal dispositivo per riconoscerlo e considerarlo affidabile.
Figura 5. Esempio di sequenza del primo metodo
Step 1. Un operatore autorizzato riceve l’indirizzo IP ed il codice seriale del dispositivo che dovrà essere installato in campo. Tramite un servizio presente in piattaforma, con il suo ruolo procederà all’aggiornamento della base dati contenente l’insieme delle coppie (indirizzo IP, codice seriale) autorizzate alla comunicazione.
Step 2. Il servizio dedicato all’Onboarding, a cadenza fissata recupererà dal database l’insieme di indirizzi IP e procederà con l’aggiornamento delle regole di apertura rotte in ingresso. Se stiamo lavorando sul cloud provider AWS, questa operazione consiste nell’aggiornamento delle regole in inbound del security group associato all’EC2.
Step 3. il dispositivo contatta il servizio di onboarding mandando nel suo primo messaggio il suo codice seriale. La piattaforma accerta che il codice seriale corrisponda a quello assegnato all’indirizzo IP. Se la verifica ha esito positivo, il dispositivo è abilitato alla comunicazione con i restanti servizi di monitoraggio e controllo offerti dalla piattaforma. Si noti che un dispositivo con indirizzo IP non presente in piattaforma o con codice seriale non conforme non è supportato dal servizio di onboarding.
Il vantaggio di questa tecnica consiste nel non dover mantenere alcuna credenziale a bordo del dispositivo per autenticarsi in piattaforma perché sarà la piattaforma stessa a gestire una whitelist contenente l’insieme degli indirizzi IP e dei codici seriali autorizzati al dialogo. Lo svantaggio di questo approccio consiste nel dover usare un riferimento fisso per la connessione, come un indirizzo IP pubblico statico oppure ricorrere ad una soluzione che permetta alla piattaforma di “seguire” le variazioni di connessione del dispositivo (Pensiamo ad un canonical name assegnato al dispositivo con un servizio DNS che si occupa di tradurlo).
In quest’ultimo scenario si aprono ulteriori complessità di gestione, come la scelta di chi e come dovrà aggiornare le variazioni della connessione. Delegare il dispositivo nell’aggiornamento richiederebbe l’introduzione di un ulteriore meccanismo di autenticazione e controllo.
Se volessimo lasciare questa Idra ad Ercole optando per il servizio di indirizzamento pubblico statico, un fattore da considerare sono i costi previsti dal proprio ISP (Internet Service Provider). Su logiche di larga scala potrebbe non essere la strategia migliore. Si potrebbe ovviare al problema dell’indirizzamento dinamico tramite l’allestimento di una VPN (menzionata in precedenza), accettando però i relativi costi di amministrazione e manutenzione.
Secondo metodo. Utilizzo di credenziali statiche pre-caricate a bordo del dispositivo
Esempio. Utilizzo di Access Key e secret Key di un’utenza AWS pre-caricate a bordo del dispositivo:
Step 1. un operatore autorizzato assume un ruolo in piattaforma per poter censire l’utenza dedicata per il dispositivo con la definizione dei permessi associati.
Step 2. L’operatore immette e salva in un’area di memoria sicura del dispositivo le credenziali associate all’utenza creata.
Step 3. il dispositivo si autentica in piattaforma. Se il nostro cloud provider è AWS, abbiamo una coppia di valori noti come Access Key e Secret Key con cui il dispositivo può accedere in piattaforma. Qualsiasi operazione il dispositivo tenta di fare in piattaforma è soggetta a revisione. Viene consultata una tabella che definisce per un’utenza l’insieme delle azioni consentite. AWS offre questo servizio tramite L’identity Access Management (IAM). Se l’utenza è autorizzata, potrà interagire con le funzionalità offerte dalla piattaforma.
Figura 6. Esempio di sequenza del secondo metodo
Un pre-requisito è che la sua utenza sia censita preventivamente a sistema. Nel caso di smarrimento delle credenziali, è richiesto un intervento manuale per la rigenerazione.
Minacce
In questa soluzione ci si espone al rischio di compromissione delle credenziali. un attaccante potrebbe impossessarsi della coppia username/password presente a bordo del dispositivo e impersonificarlo. Una soluzione per arginare questo problema consiste nel riportare queste credenziali in un’area sicura di memoria del dispositivo. Ciò non toglie che le credenziali sono comunque esposte al guessing, quindi deve essere costantemente aggiornata per ridurre le probabilità di individuazione.
Terzo metodo. Utilizzo di certificati a mutua autenticazione
I certificati a mutua autenticazione seguono lo standard x.509. è uno standard proposto dall’Unione internazionale delle telecomunicazioni (ITU-T), usato per definire il formato dei certificati a chiave pubblica (PKC) e delle autorità di certificazione (CA).
I certificati superano diverse limitazioni dei precedenti metodi. A differenza della password, anche se un certificato viene rubato, senza la chiave privata di cui solo il dispositivo può essere in possesso l’attaccante non può interagire con la piattaforma. I certificati possono essere revocati in caso di compromissione mentre l’invalidamento di una password permette all’attaccante di poter sfruttare la sessione corrente per completare la sua attività. Infine, ogni volta che mandiamo un messaggio con l’autenticazione basata su certificati il messaggio viene “firmato”, mentre con l’utilizzo di password i messaggi non lo sono.
Con la firma digitale abbiamo la garanzia che il messaggio provenga effettivamente dal dispositivo e che il contenuto del messaggio non sia stato alterato durante il transito. Solo il dispositivo che possiede la chiave privata corrispondente al certificato può generare quella firma e non può affermare di non aver inviato il messaggio “firmato”.
Le autorità di certificazione sono gli enti che attestano che un certificato è autorizzato. Possiamo vederle come i nostri Paesi che ci rilasciano il passaporto.
Figura 7. Esempio di sequenza del terzo metodo. La rappresentazione mostra la prima fase di scambio con la PKI
Step 1. Un operatore PKI autorizzato genera le credenziali specificando quale sarà la CA associate alle richieste dietro queste credenziali. Le credenziali cambiano a seconda del protocollo scelto per la verifica di identità del dispositivo. Il più longevo è il protocollo SCEP, in cui il dispositivo ricorre ad una challenge password per poter presentare la richiesta di emissione del certificato. Il più recente è il protocollo EST, dove vengono generate delle chiavi di pre-enrollment da affidare al dispositivo. Il sistema le salva e le rende disponibili al servizio di enrollment.
Step 2. L’operatore immette e salva in un’area di memoria sicura del dispositivo le credenziali associate all’identità creata.
Step 3. Mettiamoci nei panni di un dispositivo, che ha bisogno di dialogare con la piattaforma. Il dispositivo genera una coppia di chiavi (una chiave privata e una chiave pubblica), ma non sa come generare il suo certificato firmato da un’autorità. Ricordiamo la metafora del passaporto. Dove andiamo a richiederlo? In questura. La questura nel mondo IoT è la PKI. Il dispositivo crea una richiesta di certificato (CSR, Certificate Signing Request). Questa richiesta contiene la chiave pubblica e altre informazioni identificative (ad esempio, l’Organization Unit, il Subject Name, ecc.). La PKI riceve la CSR e verifica l’identità. In questo flusso entrano in gioco i protocolli menzionati in precedenza (SCEP ed EST).
Se la verifica dell’identità è andata a buon fine, la PKI emette il certificato firmandolo con la CA dedicata per il dispositivo. Pensiamo alla piattaforma AWS. È possibile avere una sola CA attestata in una region. Cosicché, se il dispositivo deve essere installato in Nord America (es.region North Virginia), è cosa buona firmare il suo certificato con la CA di North Virginia anziché con quella europea. Questo certificato contiene la chiave pubblica del dispositivo. La PKI “firma” il certificato utilizzando la chiave privata della CA. Questa firma digitale garantisce l’autenticità del certificato e permette a chiunque riceva il certificato di verificare che sia stato emesso effettivamente dalla CA.
Quando la piattaforma IoT viene contattata dal dispositivo e riceve il certificato, può usare la chiave pubblica della CA per verificare la firma. Se la verifica ha successo, la piattaforma può fidarsi della validità del certificato.
Figura 8. Esempio di sequenza del terzo metodo. La rappresentazione mostra la seconda fase di scambio con la Piattaforma IoT
Implementazione di Policy Progressive per la Sicurezza IoT
In questo metodo, notiamo un aspetto peculiare. C’è bisogno di un’interazione tra la PKI e la piattaforma IoT per aggiornare il censimento dei certificati autorizzati a dialogare con la piattaforma. I certificati sono visti dalla piattaforma IoT come un’identità a cui tramite delle policies è possibile dire cosa fare e non fare.
Ad esempio, al certificato associato ad un dispositivo che deve ancora stabilire la sua prima connessione in piattaforma possiamo limitare alcune funzionalità. Sicuramente quella di cancellazione, poiché sarebbe un controsenso consentire a chi non è ancora registrato di cancellarsi da una piattaforma. Ma potremmo anche bloccare tentativi di invio dati.
La piattaforma non può accettare messaggi da chi deve ancora formalmente registrarsi. È come se si consentisse ad un utente non registrato di poter scambiare in totale anonimato dei messaggi con gli altri utenti registrati su un forum. Questa restrizione è un esempio di implementazione di policy progressive di accesso, dove i permessi per interagire con i canali di comunicazione della piattaforma sono rilasciati solo a quei dispositivi pre-autorizzati, che rispettano le condizioni previste di ingresso.
Con AWS è possibile ricorrere al servizio di Just in time Registration. La Just in Time Registration è un processo che consente alla piattaforma di non dover conoscere a priori quali sono i certificati autorizzati a comunicare, a patto che si presentino con un certificato firmato da una CA considerata affidabile. Quindi un pre-requisito per abilitare questo scenario è quello di rendere attendibile su AWS la stessa CA usata dalla PKI.
Tra i 3 approcci suggeriti, a costo di una gestione ed implementazione più complessa, il terzo è quello che permette di mitigare i principali rischi legati all’ingresso di un nuovo dispositivo in piattaforma. Spetta all’architetto di soluzioni software il compito di disegnare e adottare la soluzione più indicata per l’organizzazione in cui lavora, venendo incontro ai requisiti temporali ed economici.
In questo approfondimento abbiamo esplorato le principali metodologie di onboarding sicuro per dispositivi IoT, dalla gestione basata su IP fino ai certificati x.509, analizzando vantaggi e criticità di ogni approccio. Nel prossimo articolo della serie approfondiremo le tecniche di validazione hardware nell’onboarding IoT, con particolare focus sulle best practice di sicurezza. Per una visione completa dell’argomento, vi invitiamo a scaricare il white paper integrale “Onboarding dei dispositivi IoT” di Fabrizio Giorgione e Giovanni Cappabianca.
Profilo Autore
Fabrizio Giorgione è nato a Napoli (NA) nel 1992. Si è laureato in ingegneria informatica presso l’università degli studi del Sannio il 17 dicembre del 2018 con una tesi dal titolo: “Analisi della superficie di un sistema SCADA”. Ha sviluppato, presso il laboratorio ISWATlab, un’applicazione Android denominata “Privacy Guard” la quale valuta il rischio di privacy leakage, ovvero il furto di informazioni, sugli smartphone (http://www.iswatlab.eu/?page_id=499). Ha effettuato il tirocinio presso lo “ZLab” di “Cse Cyber Sec” nell’ambito “SOC”, “Forensic” e “Malware Analysis”. Attualmente lavora presso la società di “NTT DATA” come “Cyber security Analyst” nel SOC di Napoli. Il suo compito è quello di effettuare analisi di log, di malware e di prevenire minacce interne ed esterne alla sua azienda e ai clienti della società. Si è occupato, inoltre, del montaggio e della gestione di sonde IDS/IPS presso Telecom Italia nella sede di Roma (RM).
OSHA and Amarillo College Partner to Promote Safety Training
The Occupational Safety and Health Administration (OSHA) has signed an alliance agreement with Amarillo College that focuses on providing safety training and hazard identification skills for students, employers and workers.
Under the three-year agreement, the alliance will provide free safety training classes and continuing education courses on protecting workers from a range of occupational hazards, including falls, electrocution, being struck by objects, and other risks in the construction, oil and gas, and general industry sectors.
Recentemente il team Satori Threat Intelligence di HUMAN ha scoperto un’operazione sofisticata di pubblicità fraudolenta nota come IconAds che coinvolge ben 352 app Android progettate per ingannare l’utente e sfuggire ai controlli. Al picco della sua attività, questa rete generava circa 1,2 miliardi di richieste pubblicitarie al giorno, un volume impressionante per una campagna malevola in the wild (Human Security).
La peculiarità più preoccupante di IconAds è la capacità di dissimulare la propria presenza sul dispositivo: l’icona delle app veniva sostituita da un elemento trasparente e il nome veniva azzerato. L’utente, trovandosi davanti a una schermata apparentemente vuota, non poteva individuare l’app responsabile del comportamento intrusivo, né rimuoverla con facilità.
IconAds non è un fenomeno isolato, ma si inserisce in un filone iniziato già nel 2023, con operazioni note come HiddenAds e Vapor. In quel primo stadio i volumi di traffico fraudolento erano inferiori, nell’ordine delle decine di milioni di richieste al giorno, ma con l’evoluzione in IconAds gli attori malevoli hanno moltiplicato i volumi e perfezionato le tecniche di evasione.
Tecniche di offuscamento a più livelli
Gli sviluppatori hanno messo in atto sofisticate tecniche anti-analisi, camuffando il codice con metodi dai nomi casuali composti da zeri e “O”. Le librerie native utilizzavano l’offuscamento O-MVLL, e le stringhe inviate ai server C2 venivano trasformate in parole inglesi casuali, rendendo difficile l’individuazione delle informazioni trasmesse. Il livello di complessità raggiunto rendeva l’analisi quasi impossibile senza una visione d’insieme coordinata.
Ogni app collegata a IconAds comunicava con un dominio di comando e controllo dedicato, caratterizzato da sottodomini generati in modo sistematico. Le comunicazioni avvenivano tramite JSON con chiavi casuali e dati sul dispositivo. Questa frammentazione delle infrastrutture C2 ha reso particolarmente ardua l’attribuzione e la neutralizzazione delle app fraudolente, sebbene gli analisti di HUMAN siano riusciti a individuarne le tracce attraverso pattern ricorrenti.
Una delle tecniche più subdole adottate da IconAds è l’uso degli alias per l’attività principale dell’applicazione. Al primo avvio, veniva attivato un alias e disattivato il componente principale, facendo “scomparire” l’app dallo spazio visibile della schermata home. In questo modo, anche se l’utente voleva cancellarla, non riusciva nemmeno a trovarla tra le app installate.
L’azione dell’intera operazione risultava molto efficace per i criminali. Alcune app, come “com.works.amazing.colour”, caricavano pubblicità interstiziali a schermo intero pochi secondi dopo l’avvio, senza alcuna interazione da parte dell’utente, attivandole da timer o da comandi remoti. La visualizzazione forzata generava profitti ingenti, simulando un comportamento legittimo agli occhi degli inserzionisti, pur essendo completamente fraudolenta.
Impatto globale e risposta al fenomeno
La diffusione delle app malevole è stata globale, con picchi particolarmente elevati in Paesi come Brasile, Messico e Stati Uniti. Google ha reagito rapidamente rimuovendo le 352 app dallo store e attivando Play Protect per proteggere i dispositivi già infettati. HUMAN, dal canto suo, ha aggiornato la sua piattaforma Ad Fraud Defense, bloccando quasi in tempo reale il traffico generato da IconAds.
Nonostante l’intervento di Google, IconAds continua a evolversi, e nuove varianti vengono sviluppate per eludere le misure di difesa. Il team Satori è ancora impegnato nel monitoraggio dell’infrastruttura, cercando di anticipare i nuovi sviluppi. Solo un approccio proattivo e collaborativo tra aziende di sicurezza e fornitori di servizi può arginare efficacemente minacce di questo livello.
.jpg?1751564396)
.jpg?height=635&t=1751564396&width=1200)
