NTLM verso lo “switch-off”: Microsoft si prepara a bloccarlo di default


Microsoft ha comunicato che l’autenticazione NTLM verrà disabilitata di default nelle future versioni, lasciando comunque il protocollo presente nel sistema operativo e riattivabile solo tramite policy quando davvero necessario.

Perché NTLM è un bersaglio: relay, replay e pass-the-hash

Il problema di NTLM non è soltanto la sua età, ma la sua esposizione a classi di attacchi che si innestano bene in ambienti enterprise moderni. Microsoft, e diversi esperti, citano esplicitamente relay, replay e man-in-the-middle come le “famiglie” di tecniche che diventano particolarmente pericolose quando un attore malevolo riesce a posizionarsi “in mezzo” a una conversazione di rete o a sfruttare autenticazioni legacy per muoversi lateralmente. In termini di tassonomie operative, il tema si collega a pattern noti come l’Adversary-in-the-Middle e il pass-the-hash, che continuano a comparire un po’ troppo spesso quando si fa la forensica di un attacco proprio perché “funzionano” quando l’azienda mantiene queste dipendenze.

La roadmap in tre fasi: audit, nuove capability Kerberos, poi blocco di default

Microsoft ha strutturato la transizione in tre fasi per ridurre il rischio senza provocare un blackout improvviso di applicazioni e servizi. La prima fase ruota attorno a capacità di auditing potenziate, già disponibili su Windows 11 24H2 e Windows Server 2025, utili a capire dove e perché NTLM viene ancora usato. La seconda fase, prevista per la seconda metà del 2026, introduce nuove funzionalità pensate per “chiudere” i buchi che oggi portano al fallback su NTLM, tra cui IAKerb e un Local Key Distribution Center (Local KDC). La terza fase è quella decisiva: nelle future release, l’NTLM di rete sarà disabilitato per impostazione predefinita, pur restando riabilitabile tramite policy per scenari legacy inevitabili.

 

“Disabilitato di default” non significa “rimosso”: cosa cambia operativamente

Microsoft sottolinea che non si tratta ancora della rimozione completa del protocollo, ma di una consegna del sistema in uno stato più sicuro “by default”, dove l’OS preferisce alternative moderne e Kerberos-based. Questo permetterà di usare NTLM ancora, ma sarà una scelta chiara dell’utente e non un possibile ripiego automatico in caso di sfruttamento di una vulnerabilità o un derivato di vecchie configurazioni di cui si è persa memoria.

In molte reti, infatti, l’uso di NTLM non è “intenzionale”, ma il risultato di condizioni che impediscono a Kerberos di funzionare come previsto. Microsoft, nella propria serie di hardening su Active Directory, entra nel dettaglio delle cause tipiche: problemi di connettività verso i domain controller, uso di account locali, errori o assenza di Service Principal Name (SPN), accesso alle risorse via indirizzo IP invece che tramite FQDN, oppure applicazioni configurate (o addirittura hardcoded) per chiamare NTLM. Ed è proprio qui che la roadmap prova a intervenire: IAKerb nasce per gestire scenari dove il client non ha una visione completa, mentre LocalKDC mira a ridurre l’uso di NTLM in autenticazioni basate su account locali, storicamente uno dei punti più difficili da eliminare.

Audit potenziato: visibilità prima del blocco

La parte più importante, oggi, è ottenere telemetria affidabile su dove NTLM sta ancora transitando. Microsoft indica esplicitamente che Windows 11 24H2 e Windows Server 2025 offrono auditing più ricco per identificare dipendenze e priorità di remediation, evitando di scoprire “a produzione ferma” che un pezzo di infrastruttura si appoggia ancora al legacy. Nella pratica, la stessa documentazione Microsoft enfatizza la necessità di mappare le dipendenze applicative e validare i workload critici con Kerberos, iniziando a testare configurazioni “NTLM-off” in ambienti non produttivi.

Questo implica un uso approfondito dei log: NTLM va trattato come un “debito tecnico misurabile”, non come un dettaglio di protocollo. Nei suggerimenti sull’hardening dello scenario, Microsoft cita famiglie di eventi utili a capire chi autentica, verso cosa e con quale versione negoziata; nelle build più recenti (24H2/Server 2025) compaiono anche eventi più dettagliati che aiutano a ricostruire il motivo del fallback e, in alcuni casi, il processo coinvolto. L’obiettivo operativo è trasformare l’eliminazione di NTLM in un percorso governato: riduzione progressiva, controllo dell’impatto e blocchi mirati dove non esistono più dipendenze.

NTLMv1: già fuori gioco, ma attenzione ai “derivati” e alle eredità crittografiche

Il percorso di dismissione è iniziato da tempo: NTLMv1 risulta già rimosso in Windows 11 24H2 e Windows Server 2025, ma restano casi in cui sopravvivono elementi di crittografia legacy. Microsoft descrive esplicitamente scenari in cui “rimasugli” di NTLMv1 possono ancora emergere, ad esempio in contesti legati a MS-CHAPv2 in ambienti domain-joined, e introduce chiavi di registro e log dedicati per passare da una modalità di audit a una di enforcement. La timeline pubblica include anche un punto rilevante: a ottobre 2026, in assenza di configurazione esplicita, il default può spostarsi verso una postura più restrittiva per specifici meccanismi collegati a derivati di NTLMv1.

Condividi l’articolo



Articoli correlati

Altro in questa categoria


https://www.securityinfo.it/2026/02/03/ntlm-verso-lo-switch-off-microsoft-si-prepara-a-bloccarlo-di-default/?utm_source=rss&utm_medium=rss&utm_campaign=ntlm-verso-lo-switch-off-microsoft-si-prepara-a-bloccarlo-di-default




Web portal leaves kids’ chats with AI toy open to anyone with Gmail account

Earlier this month, Joseph Thacker’s neighbor mentioned to him that she’d preordered a couple of stuffed dinosaur toys for her children. She’d chosen the toys, called Bondus, because they offered an AI chat feature that lets children talk to the toy like a kind of machine-learning-enabled imaginary friend. But she knew Thacker, a security researcher, had done work on AI risks for kids, and she was curious about his thoughts.

So Thacker looked into it. With just a few minutes of work, he and a web security researcher friend named Joel Margolis made a startling discovery: Bondu’s web-based portal, intended to allow parents to check on their children’s conversations and for Bondu’s staff to monitor the products’ use and performance, also let anyone with a Gmail account access transcripts of virtually every conversation Bondu’s child users have ever had with the toy.

Without carrying out any actual hacking, simply by logging in with an arbitrary Google account, the two researchers immediately found themselves looking at children’s private conversations, the pet names kids had given their Bondu, the likes and dislikes of the toys’ toddler owners, their favorite snacks and dance moves.

In total, Margolis and Thacker discovered that the data Bondu left unprotected—accessible to anyone who logged in to the company’s public-facing web console with their Google username—included children’s names, birth dates, family member names, “objectives” for the child chosen by a parent, and most disturbingly, detailed summaries and transcripts of every previous chat between the child and their Bondu, a toy practically designed to elicit intimate one-on-one conversation. Bondu confirmed in conversations with the researchers that more than 50,000 chat transcripts were accessible through the exposed web portal, essentially all conversations the toys had engaged in other than those that had been manually deleted by parents or staff.

https://arstechnica.com/security/2026/01/web-portal-leaves-kids-chats-with-ai-toy-open-to-anyone-with-gmail-account/




Securing Trust: Why Crisis Communication is Your First Line of Defense

@import url(‘https://fonts.googleapis.com/css2?family=Handlee&display=swap’); h3 { font-weight: bold; font-size: 18px; color: #C72026; } .pqFull { display: block; border-width: 2px 0; border-style: solid; border-color: #404144; padding: 1.5em 0 0.5em; margin: 1.5em 0; position: relative; Handlee”, Arial, sans-serif; font-size: 20px; text-align: center; color: #0067A6; } .pqFull:before { content: ‘\275D’; position: absolute; top: -.10em; left: 50%; transform: translate(-50%, -50%); background: #fff; width: 4rem; height: 2rem; color: #666; text-align: center; } .pqFull:after { content: attr(cite); display: block; text-align: center; font-size: 18px; color: #404144; }

“Who You Gonna Call?” is a fun movie quote, but in a security breach, it’s the question that keeps CISOs awake at night.

Most security frameworks focus heavily on the technical side of incident response — patching the hole, stopping the exfiltration, and restoring backups. But the battle for your organization’s survival often isn’t won in the server room; it’s won in the inbox and on social media.

Crisis communication isn’t just “PR’s problem” — it is a functional security control. If we lose the narrative, we lose trust.

The Reality of the Panic Spiral

When an incident hits, information vacuums are dangerous. If you don’t fill the silence, someone else will — usually with rumors, fear or bad data.

Effective communication does four things immediately:

  1. Kills the Panic: It gives employees and stakeholders a “north star” to follow.
  2. Protects the Brand: It shows you are competent, even if you are currently vulnerable.
  3. Clears the Airwaves: It stops the Incident Commander from being bombarded by “What’s happening?!” emails so they can actually fix the problem.
  4. Beats the Clock (and the Fines): Whether it’s the SEC’s 4-day rule, GDPR’s 72-hour window, or HIPAA notifications, the regulatory clock starts ticking the moment you confirm a material incident. You do not want to be drafting legal notifications from scratch while your hair is on fire. A solid comms plan ensures you meet those hard deadlines, preventing an operational crisis from turning into a massive regulatory penalty.

The Playbook: What Actually Works

We all know we need a plan, but a 50-page binder that gathers dust isn’t a plan; it’s a paperweight. A usable strategy focuses on agility over perfection.

1. Accuracy Over Speed — But Not by Much: There is massive pressure to “say something” immediately. This is where companies get burned (remember the confusing initial statements from the Equifax breach?).

  • The Golden Rule: It is better to say, “We are aware of an issue and are investigating,” than to guess, be wrong, and have to retract it later. A retraction kills credibility faster than silence does.

2. Define the “Wartime” Roles: During a calm Tuesday, the Marketing VP approves press releases. During a breach on a Saturday night, that chain of command might be too slow. You need a streamlined roster:

  • The Truth Teller: Who finds the facts? (Security/Ops)
  • The Scribe: Who writes the message? (Comms)
  • The Gavel: Who has the final “Go/No-Go” on hitting send? (Legal/Exec)

We can’t prevent every crisis. Threats evolve too fast. But we can control how we react. When the dust settles, people might forgive a security lapse, but they rarely forgive a cover-up or a chaotic, insensitive response.

3. Choose Your Channels Before the Fire Starts: If your email system is the thing that got hacked, how do you tell employees not to open email? You need “out-of-band” communication channels established now. Whether that’s a mass-texting service, a dark site hosted on a separate server, or a dedicated Slack channel — have a backup way to talk when the primary lines are cut.

4. The “Hot Wash” (Post-Incident Review): Survival isn’t the same as success. Once the smoke clears, you have to audit your communication performance just as strictly as your technical response. Did the press release take too long to approve? Did the tone of your social posts calm the waters or stir the pot? Analyze the media sentiment and stakeholder feedback honestly. Most importantly, update the plan immediately. If you don’t operationalize the lessons learned, you’re doomed to repeat the same fumbles next time. Don’t forget to integrate revised communications steps into your IR plan and re-train teams.

The Human Element: Don’t Sound Like a Robot

ISACA State of Cybersecurity research shows the importance of communications skills for security professionals, but this is where most technical teams struggle. We want to speak in technicalities — “mitigation strategies” and “attack vectors.” The public wants to hear empathy and ownership.

If people’s data is at risk, they are scared. A sterile corporate statement feels like a slap in the face.

  • Be Human: Use plain language. “We are sorry this happened,” goes a long way. Legal-approved language doesn’t have to sound robotic; pre-scripting human responses ensures you have alignment before the crisis hits.
  • Be Transparent: If you don’t know something yet, admit it. “We don’t have the full scope yet, but we will update you in two hours.” However, be cautious with timelines. Only promise updates on a cadence you can realistically sustain.
  • Be Ethical: Don’t hide the ball. If you made a mistake, own it, fix it, and explain how you’ll prevent it next time.

Practicing the “Soft” Skills

You probably simulate phishing attacks and run disaster recovery drills. But when was the last time you ran a drill on drafting a press release while the legal team screamed at you? Integrate a comms lead into every major tabletop.

Tabletop exercises need to include the communication layer. Make the executives sit in a room and actually draft the social post they would send if the customer database leaked. It exposes the cracks in your process faster than any theoretical meeting ever will.

Final Thoughts

We can’t prevent every crisis. Threats evolve too fast. But we can control how we react. When the dust settles, people might forgive a security lapse, but they rarely forgive a cover-up or a chaotic, insensitive response.

Review your plan tonight. Not the 50-page binder — the one-page cheat sheet you’d grab at 3:00 a.m. If it doesn’t exist, you just found your next project. If it does exist, does it work? If not, fix it now.

https://www.securitymagazine.com/articles/102099-securing-trust-why-crisis-communication-is-your-first-line-of-defense




County pays $600,000 to pentesters it arrested for assessing courthouse security

Two security professionals who were arrested in 2019 after performing an authorized security assessment of a county courthouse in Iowa will receive $600,000 to settle a lawsuit they brought alleging wrongful arrest and defamation.

The case was brought by Gary DeMercurio and Justin Wynn, two penetration testers who at the time were employed by Colorado-based security firm Coalfire Labs. The men had written authorization from the Iowa Judicial Branch to conduct “red-team” exercises, meaning attempted security breaches that mimic techniques used by criminal hackers or burglars.

The objective of such exercises is to test the resilience of existing defenses using the types of real-world attacks the defenses are designed to repel. The rules of engagement for this exercise explicitly permitted “physical attacks,” including “lockpicking,” against judicial branch buildings so long as they didn’t cause significant damage.

A chilling message

The event galvanized security and law enforcement professionals. Despite the legitimacy of the work and the legal contract that authorized it, DeMercurio and Wynn were arrested on charges of felony third-degree burglary and spent 20 hours in jail, until they were released on $100,000 bail ($50,000 for each). The charges were later reduced to misdemeanor trespassing charges, but even then, Chad Leonard, sheriff of Dallas County, where the courthouse was located, continued to allege publicly that the men had acted illegally and should be prosecuted.

Reputational hits from these sorts of events can be fatal to a security professional’s career. And of course, the prospect of being jailed for performing authorized security assessment is enough to get the attention of any penetration tester, not to mention the customers that hire them.

“This incident didn’t make anyone safer,” Wynn said in a statement. “It sent a chilling message to security professionals nationwide that helping [a] government identify real vulnerabilities can lead to arrest, prosecution, and public disgrace. That undermines public safety, not enhances it.”

DeMercurio and Wynn’s engagement at the Dallas County Courthouse on September 11, 2019, had been routine. A little after midnight, after finding a side door to the courthouse unlocked, the men closed it and let it lock. They then slipped a makeshift tool through a crack in the door and tripped the locking mechanism. After gaining entry, the pentesters tripped an alarm alerting authorities.

https://arstechnica.com/security/2026/01/county-pays-600000-to-pentesters-it-arrested-for-assessing-courthouse-security/




OpenSSL ha fixato 12 vulnerabilità scoperte da AISLE


Pochi giorni fa OpenSSL ha rilasciato alcune patch per risolvere 12 vulnerabilità individuate, col supporto dell’IA, dalla compagnia di sicurezza AISLE.

“L’analizzatore autonomo di AISLE ha individuato tutte e 12 le CVE nella versione coordinata di gennaio 2026 di OpenSSL, la libreria crittografica open source che è alla base di una parte consistente delle comunicazioni sicure a livello mondiale. Alcune di queste vulnerabilità erano presenti nel codice OpenSSL da decenni e sono riuscite a sfuggire all’attenzione di migliaia di ricercatori nel campo della sicurezza” ha specificato il team della compagnia. Alcuni bug risalivano addirittura al 1998.

Le 12 vulnerabilità di OpenSSL sono presenti in più di otto sottosistemi diversi, tra cui CMS, QUIC e algoritmi di firma post-quantum. Tra i bug considerati più gravi c’è la CVE-2025-15467, uno Stack Buffer Overflow nell’analisi di dati CMS AuthEnvelopedData che consente l’esecuzione di codice remoto.

OpenSSL vulnerabilità

Il tool ha individuato anche una vulnerabilità di gravità moderata: la CVE-2025-11187 è una mancata validazione dei parametri PBMAC1 in PKCS#12 che potrebbe innescare un buffer overflow basato su stack.

Le altre dieci falle sono considerate di gravità bassa e possono abilitare attacchi di Denial of Service, corruzione della memoria, esaurimento delle risorse e sfruttamento di difetti di crittografia.

Oltre a queste 12 vulnerabilità, AISLE ha scoperto altre 6 criticità che però non hanno ricevuto una designazione CVE: grazie all’integrazione dell’analisi autonoma nei flussi di sviluppo, i bug sono stati rilevati e corretti prima che il codice vulnerabile venisse effettivamente rilasciato agli utenti.

Non appena il sistema automatizzato ha individuato i bug, AISLE ha collaborato a stretto contatto con OpenSSL per risolvere le vulnerabilità e rilasciare le patch il prima possibile.

Stanislav Fort, fondatore e Chief Scientist della compagnia di sicurezza, ha sottolineato che l’uso di uno strumento potenziato dall’IA ha permesso di individuare più facilmente i bug, rafforzando un processo che prima era quasi esclusivamente umano. “I revisori umani sono limitati dal tempo, dall’attenzione e dall’enorme volume di codice nei sistemi moderni. L’analisi statica tradizionale rileva alcune classi di bug, ma ha difficoltà con errori logici complessi e problemi dipendenti dal tempo. Al contrario, l’analisi autonoma basata sull’intelligenza artificiale opera su una dimensione diversa. È in grado di esaminare percorsi di codice e casi limite che richiederebbero mesi di lavoro ai revisori umani e funziona in modo continuo anziché periodico” ha specificato Fort.

Si raccomanda agli utenti OpenSSL di aggiornarlo il prima possibile alla versione più recente.

Condividi l’articolo



Articoli correlati

Altro in questa categoria


https://www.securityinfo.it/2026/01/29/openssl-ha-fixato-12-vulnerabilita-scoperte-da-aisle/?utm_source=rss&utm_medium=rss&utm_campaign=openssl-ha-fixato-12-vulnerabilita-scoperte-da-aisle




Site catering to online criminals has been seized by the FBI

RAMP—the predominantly Russian-language online bazaar that billed itself as the “only place ransomware allowed”—had its dark web and clear web sites seized by the FBI as the agency tries to combat the growing scourge threatening critical infrastructure and organizations around the world.

Visits to both sites on Wednesday returned pages that said the FBI had taken control of the RAMP domains, which mirrored each other. RAMP has been among the dwindling number of online crime forums to operate with impunity, following the takedown of other forums such as XSS, which saw its leader arrested last year by Europol. The vacuum left RAMP as one of the leading places for people pushing ransomware and other online threats to buy, sell, or trade products and services.

I regret to inform you

“The Federal Bureau of Investigation has seized RAMP,” a banner carrying the seals of the FBI and the Justice Department said. “This action has been taken in coordination with the United States Attorney’s Office for the Southern District of Florida and the Computer Crime and Intellectual Property Section of the Department of Justice.” The banner included a graphic that appeared on the RAMP site, before it was seized, that billed itself as the “only place ransomware allowed.”

Screenshot

Screenshot

RAMP was founded in 2012 and rebranded in 2021, according to security firm Rapid 7. The platform served Russian, Chinese, and English speakers and counted more than 14,000 registered users, who underwent strict vetting before being accepted or paid a $500 fee for anonymous participation. The forum provided discussion groups, cyberattack tutorials, and a marketplace for malware and services. Its chief administrator said in 2024 the site earned $250,000 annually.

https://arstechnica.com/security/2026/01/site-catering-to-online-criminals-has-been-seized-by-the-fbi/




There’s a rash of scam spam coming from a real Microsoft address

There are reports that a legitimate Microsoft email address—which Microsoft explicitly says customers should add to their allow list—is delivering scam spam.

The emails originate from no-reply-powerbi@microsoft.com, an address tied to Power BI. The Microsoft platform provides analytics and business intelligence from various sources that can be integrated into a single dashboard. Microsoft documentation says that the address is used to send subscription emails to mail-enabled security groups. To prevent spam filters from blocking the address, the company advises users to add it to allow lists.

From Microsoft, with malice

According to an Ars reader, the address on Tuesday sent her an email claiming (falsely) that a $399 charge had been made to her. It provided a phone number to call to dispute the transaction. A man who answered a call asking to cancel the sale directed me to download and install a remote access application, presumably so he could then take control of my Mac or Windows machine (Linux wasn’t allowed). The email, captured in the two screenshots below, looked like this:

Online searches returned a dozen or so accounts of other people reporting receiving the same email. Some of the spam was reported on Microsoft’s own website.

Sarah Sabotka, a threat researcher at security firm Proofpoint, said the scammers are abusing a Power Bi function that allows external email addresses to be added as subscribers for the Power Bi reports. The mention of the subscription is buried at the very bottom of the message, where it’s easy to miss. The researcher explained:

https://arstechnica.com/information-technology/2026/01/theres-a-rash-of-scam-spam-coming-from-a-real-microsoft-address/




PackageGate: trovati sei bug zero-day nei package manager, ma NPM non interviene


La società di sicurezza Koi Security ha pubblicato una ricerca che ha sta scuotendo la comunità degli sviluppatori: i ricercatori hanno scoperto sei vulnerabilità zero-day nei principali package manager dell’ecosistema JavaScript (npm, pnpm, vlt e Bun) che permettono agli attaccanti di aggirare le difese usate per mitigare gli attacchi alla supply-chain dei pacchetti.

Negli ultimi anni il mondo JavaScript è stato al centro di una serie di attacchi alla supply-chain, tra i quali la campagna Shai-Hulud avvenuta lo scorso novembre che ha compromesso pacchetti NPM per distribuire malware. In risposta a questi attacchi, la difesa standard adottata da aziende e progetti open source è diventata disabilitare gli script automatizzati durante l’installazione (ad esempio con l’opzione –ignore-scripts di npm) e committare sempre i lockfile (package-lock.json, pnpm-lock.yaml, ecc.) per vincolare le versioni e le integrità dei pacchetti.

NPM zero day

Sebbene queste due tecniche siano considerate delle best practice di sicurezza, la ricerca di Koi Security ha dimostrato che esistono delle vulnerabilità, complessivamente chiamate PackageGate, che permettono di aggirarle; nel dettaglio, i bug zero-day individuati consentono di eseguire l’esecuzione di codice anche quando gli script sono disabilitati e invalidare l’integrità dei lockfile.

Le tecniche di attacco sono diverse a seconda del tool usato: nel caso di npm, un pacchetto di dipendenza Git può includere un file .npmrc manipolato che reindirizza il binario Git a uno script malevolo, eseguendo codice arbitrario; in pnpm il meccanismo che disattiva gli script durante la build non copre la fase di fetch da un repository Git, permettendo l’esecuzione dei preparativi dei pacchetti malevoli; in vlt un bug di path traversal nell’estrazione dei pacchetti consente di scrivere file ovunque nel filesystem; infine, in Bun la whitelist per i pacchetti di fiducia non valida la fonte dei pacchetti, consentendo l’inclusione e l’esecuzione di artefatti malevoli con nomi considerati “trusted”.

NPM si rifiuta di risolvere i bug zero-day

Il team di Koi ha notificato il problema a tutti i vendor coinvolti; tutti si sono occupati di risolvere le vulnerabilità, tranne NPM che ha affermato che il comportamento dell’ecosistema è “quello atteso” e non è quindi intervenuto per sanare i bug zero-day. Il vendor ha specificato che “gli utenti di npm sono responsabili della verifica dei contenuti dei pacchetti che scelgono di installare“, sottolineando che essendo Git uno strumento esterno, essi non sono responsabili di quello che l’utente sceglie di fare.

I ricercatori si sono opposti a questa visione spiegando che –ignore-scripts nella documentazione di npm è esplicitamente consigliato per difendersi dai malware e che quindi se esistono percorsi di esecuzione che lo bypassano allora il modello di sicurezza è incompleto; inoltre eseguendo “npm install” l’utente non sta eseguendo Git manualmente, ma lo fa tramite npm: Git è formalmente un tool esterno, ma operativamente, in questo caso, la questione è diversa.

“Gli abbiamo chiesto più volte di riconsiderare la decisione, sottolineando l’errore nella documentazione. Nessuna risposta. Come ultimo tentativo, abbiamo utilizzato le nostre conoscenze personali per contattare qualcuno del team npm che potesse riconsiderare la decisione. Purtroppo, anche questo tentativo è stato un fallimento” ha spiegato il team di Koi Security.

I ricercatori hanno sottolineato che disabilitare gli script e committare i lock file rimangono due indicazioni valide, ma non sono la soluzione completa al problema. Finché PackageGate non sarà risolto del tutto, le organizzazioni che dipendono da npm dovrebbero trattare le dipendenze come potenzialmente malevole e agire di conseguenza.

Condividi l’articolo



Articoli correlati

Altro in questa categoria


https://www.securityinfo.it/2026/01/27/packagegate-trovati-sei-bug-zero-day-nei-package-manager-ma-npm-non-interviene/?utm_source=rss&utm_medium=rss&utm_campaign=packagegate-trovati-sei-bug-zero-day-nei-package-manager-ma-npm-non-interviene




IoMT e il paradosso della certificazione: quando la compliance normativa ostacola la cybersecurity dei dispositivi medicali

La sicurezza dei dispositivi medicali IoMT (Internet of Medical Things) rappresenta oggi uno dei paradossi più critici e meno discussi nel panorama della cybersecurity sanitaria europea. Il Regolamento MDR 2017/745 impone che i dispositivi certificati CE non possano essere modificati – inclusa l’installazione di software antivirus o l’applicazione di patch di sicurezza – senza invalidare la certificazione stessa.

Questa rigidità normativa, concepita per tutelare la sicurezza del paziente, si scontra frontalmente con le esigenze di protezione cyber imposte dalla Direttiva NIS2 e dalle minacce ransomware che nel 2024 hanno colpito il 67% delle organizzazioni sanitarie a livello globale, secondo il report Sophos condotto su 14 Paesi. L’articolo analizza questo conflitto regolatorio e propone il modello della “securizzazione laterale” – basato su microsegmentazione di rete e architetture Zero Trust – come soluzione architetturale che consente di proteggere i dispositivi senza alterarne la configurazione certificata.

Il nodo irrisolto della sicurezza IoMT negli ospedali europei

La sicurezza IoMT è diventata la questione centrale per ogni CISO del settore sanitario. Il motivo è tanto semplice quanto allarmante: secondo analisi di settore basate su dati Forescout, la stragrande maggioranza degli ospedali gestisce dispositivi medicali con vulnerabilità note e attivamente sfruttate dagli attaccanti. Non si tratta di un dato astratto, ma di una realtà operativa quotidiana che i responsabili della sicurezza informatica ospedaliera conoscono bene.

Il problema, tuttavia, non risiede nella mancanza di consapevolezza o di competenze tecniche. Il vero ostacolo è strutturale e normativo: i dispositivi medicali certificati CE ai sensi del Regolamento MDR 2017/745 non possono essere modificati senza compromettere la loro conformità regolatoria. Questo significa che un monitor cardiaco, una pompa per infusione o un sistema di imaging diagnostico – tutti dispositivi critici per la cura del paziente – devono rimanere esattamente nella configurazione in cui sono stati certificati, anche quando presentano vulnerabilità software documentate.

Il paradosso emerge in tutta la sua evidenza: la normativa pensata per proteggere il paziente impedisce di fatto l’implementazione delle misure di cybersecurity necessarie a proteggerlo da minacce che, secondo il report IBM Cost of a Data Breach 2024, hanno causato danni per una media di 9,77 milioni di dollari per ogni violazione nel settore sanitario – il costo più alto tra tutti i comparti industriali per il quattordicesimo anno consecutivo.

Il conflitto normativo: MDR 2017/745 versus requisiti di cybersecurity

Per comprendere la profondità di questo conflitto è necessario esaminare le due cornici normative che, paradossalmente, dovrebbero entrambe tutelare la sicurezza dei pazienti.

Il Regolamento MDR 2017/745: la logica della certificazione

Il Medical Device Regulation europeo, entrato in vigore nel maggio 2021, ha sostituito le precedenti direttive introducendo requisiti più stringenti per l’immissione sul mercato dei dispositivi medicali. L’Allegato I, Sezione 17.2, stabilisce che il software contenuto nei dispositivi medicali deve essere sviluppato e prodotto “allo stato dell’arte”, considerando il ciclo di vita, la gestione del rischio e la sicurezza delle informazioni.

Tuttavia, la certificazione CE – rilasciata dagli Organismi Notificati dopo rigorosi processi di valutazione della conformità – cristallizza la configurazione del dispositivo. Qualsiasi modifica sostanziale richiede una nuova valutazione di conformità, con tempi e costi che possono risultare proibitivi. Il principio sottostante è chiaro: garantire che il dispositivo funzioni esattamente come testato e validato, senza alterazioni che potrebbero comprometterne la sicurezza clinica.

Questa rigidità ha senso dal punto di vista della sicurezza del paziente in senso tradizionale. Un’alterazione del firmware di una pompa per infusione potrebbe teoricamente modificarne il dosaggio; un aggiornamento software di un ventilatore polmonare potrebbe introdurre malfunzionamenti. La certificazione CE è progettata per prevenire questi rischi.

La Direttiva NIS2: l’imperativo della cybersecurity

Sul versante opposto, la Direttiva NIS2 – in vigore dal 18 ottobre 2024 – classifica ospedali e produttori di dispositivi medicali come “entità essenziali” o “importanti”, imponendo obblighi stringenti in materia di gestione del rischio cyber. L’Articolo 21(2) elenca dieci misure di sicurezza obbligatorie, tra cui la gestione delle vulnerabilità, la sicurezza della supply chain e la capacità di risposta agli incidenti.

Il problema emerge quando si considera che la gestione delle vulnerabilità, nel contesto IT tradizionale, si traduce principalmente nell’applicazione tempestiva di patch di sicurezza. Ma per un dispositivo medicale certificato CE, applicare una patch significa potenzialmente invalidare la certificazione.

Un esempio concreto: la pompa per infusione vulnerabile

Consideriamo uno scenario reale documentato dalla University of New Brunswick nel dataset CICIoMT2024. Una pompa per infusione connessa alla rete ospedaliera presenta una vulnerabilità nota nel protocollo MQTT utilizzato per la comunicazione. Gli attaccanti possono sfruttare questa vulnerabilità per intercettare i comandi o, nel peggiore dei casi, alterare i parametri di infusione.

La soluzione tecnica sarebbe immediata: applicare la patch rilasciata dal vendor o, in alternativa, installare un agente di endpoint protection. Tuttavia, entrambe le opzioni comporterebbero una modifica del software del dispositivo. Secondo la lettura più conservativa del MDR, questo richiede una nuova valutazione di conformità da parte dell’Organismo Notificato – un processo che può richiedere mesi e che il vendor potrebbe non essere disposto ad affrontare per dispositivi già in commercio.

Il risultato? La pompa rimane vulnerabile, connessa alla rete ospedaliera, in attesa che il vendor rilasci un aggiornamento già validato nell’ambito del suo processo di Post-Market Surveillance. Un’attesa che può protrarsi per anni nei casi di dispositivi legacy.

La fotografia delle vulnerabilità IoMT nel 2025

I numeri raccontano una situazione critica. Il report 2025 di Forescout documenta un incremento del 15% anno su anno del rischio medio dei dispositivi connessi, con quattro nuove tipologie di dispositivi IoMT entrate nella lista dei più rischiosi: dispositivi di imaging, apparecchiature di laboratorio, workstation sanitarie e controller per pompe di infusione. Questi ultimi sono particolarmente critici poiché una compromissione potrebbe permettere agli attaccanti di alterare i parametri di somministrazione dei farmaci.

Secondo analisi di settore, una percentuale significativa dei dispositivi medicali opera su sistemi operativi end-of-life che non ricevono più aggiornamenti di sicurezza, mentre i controller delle pompe di infusione mostrano vulnerabilità critiche e wormable nel 20% dei casi analizzati.

La situazione in Italia

In Italia, la situazione è particolarmente preoccupante. L’Agenzia per la Cybersicurezza Nazionale ha documentato un incremento del 111% degli eventi cyber nel settore sanitario tra il 2023 e il 2024, passando da 27 a 57 eventi. Gli incidenti effettivi hanno raggiunto quota 57, influenzati in parte da un attacco supply chain che ha coinvolto numerosi clienti del settore sanitario attraverso un fornitore. Nel solo 2024 sono stati registrati 10 casi significativi di ransomware che hanno colpito strutture sanitarie italiane.

L’attacco alla ASST Rhodense del giugno 2024 esemplifica le conseguenze operative: il gruppo ransomware Cicada3301 ha compromesso i sistemi informatici degli ospedali di Garbagnate, Bollate e Rho, costringendo le strutture a sospendere interventi chirurgici non urgenti, esami di laboratorio e altri servizi programmati. Il gruppo ha rivendicato l’esfiltrazione di 1 terabyte di dati sensibili, inclusi documenti medici, prescrizioni e informazioni personali dei pazienti.

Il contesto europeo

A livello europeo, i dati di Check Point Research per gennaio-settembre 2024 indicano che le organizzazioni sanitarie europee hanno subito una media di 1.686 attacchi settimanali per organizzazione, con un incremento del 56% rispetto allo stesso periodo dell’anno precedente – il maggiore aumento percentuale tra tutte le regioni analizzate. L’Italia si posiziona tra i Paesi più colpiti nel settore healthcare a livello globale.

La securizzazione laterale: proteggere senza modificare

Di fronte a questo paradosso normativo, la comunità della cybersecurity sanitaria ha sviluppato un approccio alternativo che consente di proteggere i dispositivi medicali IoMT senza alterarne la configurazione interna. Questo paradigma, che possiamo definire “securizzazione laterale”, opera esclusivamente sul contesto di rete in cui il dispositivo è inserito, lasciando intatto il software certificato.

Il principio architetturale

L’idea fondamentale è semplice: se non posso installare un antivirus sul dispositivo, posso però controllare con precisione chi può comunicare con esso e come. Invece di proteggere il dispositivo dall’interno, lo proteggo dall’esterno, creando un perimetro di sicurezza granulare che ne limita l’esposizione alle minacce.

Questo approccio si articola in tre componenti principali:

Visibilità completa dell’ambiente IoMT. Prima di proteggere, è necessario conoscere. Piattaforme come Claroty Medigate o Armis consentono di identificare automaticamente tutti i dispositivi medicali connessi alla rete, classificarli per tipologia e rischio, e mappare i loro pattern di comunicazione legittimi.

Microsegmentazione identity-based. Una volta identificati i dispositivi e i loro flussi di comunicazione autorizzati, è possibile implementare policy di segmentazione granulare che consentano solo il traffico strettamente necessario. Un monitor cardiaco, ad esempio, deve poter comunicare con il sistema di gestione dei dati clinici (PACS) e con la workstation del reparto, ma non ha alcun motivo legittimo per accedere a Internet o comunicare con la stampante dell’amministrazione.

Prevenzione del lateral movement. Il vero valore della microsegmentazione emerge nella capacità di contenere un’eventuale compromissione. Se un attaccante riesce a violare un dispositivo vulnerabile, la segmentazione impedisce che possa utilizzarlo come punto di pivot per raggiungere altri sistemi critici. Il lateral movement rappresenta un vettore di attacco prevalente nelle violazioni riuscite nel settore sanitario.

Il caso MultiCare Health System

L’implementazione della microsegmentazione in ambito sanitario trova un esempio significativo nel caso di MultiCare Health System, il più grande sistema sanitario no-profit dello Stato di Washington con 14 ospedali e circa 29.000 dipendenti.

Jason Elrod, CISO di MultiCare, ha affrontato la sfida partendo da una posizione di scetticismo – come lui stesso ha dichiarato – verso le promesse dei vendor. L’implementazione di una piattaforma di microsegmentazione identity-based ha permesso di ottenere il 99% di visibilità sui dispositivi connessi in meno di 4 ore, con un deployment completo delle policy di segmentazione in 4-16 settimane, senza alcuna interruzione dei flussi clinici.

L’aspetto cruciale dell’approccio adottato è che la protezione avviene a livello di rete, senza richiedere l’installazione di agenti software sui dispositivi medicali. Questo consente di proteggere anche dispositivi legacy che operano su sistemi operativi obsoleti – come Windows 7 o Windows XP Embedded – impossibili da aggiornare sia per ragioni tecniche che normative.

L’allineamento con i nuovi requisiti regolatori

La securizzazione laterale non è solo una soluzione tecnica elegante; sta diventando un requisito normativo esplicito.

Stati Uniti: la proposta di aggiornamento HIPAA Security Rule

La proposta di aggiornamento alla HIPAA Security Rule, pubblicata dall’Office for Civil Rights (OCR) del Department of Health and Human Services il 27 dicembre 2024, prevede esplicitamente la segmentazione di rete come misura obbligatoria per la protezione delle informazioni sanitarie elettroniche (ePHI). Il documento elimina la distinzione tra specifiche required e addressable, rendendo di fatto obbligatorie tutte le misure di sicurezza precedentemente considerate opzionali.

Il periodo di commenti pubblici si è chiuso il 7 marzo 2025 e si attende la pubblicazione della regola finale entro la fine dell’anno. Le organizzazioni sanitarie statunitensi dovrebbero già prepararsi a soddisfare questi requisiti.

Europa: le linee guida per il settore sanitario

Le linee guida HHS 405(d) Health Industry Cybersecurity Practices richiedono esplicitamente capacità di defense-in-depth attraverso la segmentazione di rete, con particolare enfasi sulla prevenzione del lateral movement. L’NHS Digital britannico ha rilasciato guidance che impongono la segmentazione di rete come requisito per tutti i Trust del sistema sanitario nazionale.

Implicazioni operative per i professionisti della sicurezza sanitaria

Per i CISO e i security architect del settore sanitario, questo scenario impone un ripensamento delle strategie di protezione. Non è più possibile affidarsi esclusivamente alle tradizionali misure di endpoint security; è necessario adottare un approccio architetturale che riconosca le specificità dell’ambiente IoMT.

Assessment della superficie di attacco IoMT

Il primo passo è acquisire visibilità completa sull’inventario dei dispositivi medicali connessi. La mancanza di visibilità è indicata da una percentuale significativa di CISO ospedalieri come la principale barriera alla gestione efficace del rischio IoMT. Non è possibile proteggere ciò che non si conosce.

Piattaforme specializzate nella discovery IoMT consentono di identificare dispositivi che spesso sfuggono ai tradizionali strumenti di network scanning, includendo apparecchiature biomedicali, sistemi di building automation connessi alla rete clinica e dispositivi shadow IT introdotti dai reparti senza coinvolgimento dell’IT centrale.

Prioritizzazione risk-based

Non tutti i dispositivi presentano lo stesso livello di rischio. Un sistema di imaging diagnostico connesso al PACS e contenente dati clinici di migliaia di pazienti richiede una protezione diversa rispetto a un sensore di temperatura ambientale. La prioritizzazione deve considerare:

  • la criticità clinica del dispositivo per la cura del paziente;
  • la sensibilità dei dati trattati;
  • il livello di connettività e l’esposizione a Internet;
  • la presenza di vulnerabilità note con exploit pubblici;
  • la disponibilità o meno di patch da parte del vendor.

Secondo i dati di Forescout, i sistemi di imaging diagnostico e i dispositivi di monitoraggio dei pazienti rappresentano i target primari degli attacchi ai dispositivi medicali, seguiti da apparecchiature di laboratorio e pompe per infusione.

Implementazione della microsegmentazione

L’implementazione della microsegmentazione in ambiente sanitario richiede un approccio graduale che minimizzi il rischio di interruzione dei servizi clinici. Le best practice suggeriscono:

Fase di discovery e learning. Acquisire visibilità completa e mappare i pattern di comunicazione legittimi prima di implementare qualsiasi policy restrittiva.

Definizione delle policy in modalità audit. Configurare le regole di segmentazione in modalità di solo monitoraggio, verificando che non blocchino traffico clinico legittimo.

Enforcement progressivo. Attivare l’enforcement partendo dai segmenti meno critici, espandendo gradualmente la copertura.

Integrazione con incident response. Predisporre procedure per l’isolamento rapido di dispositivi compromessi senza impatto sui servizi clinici essenziali.

Gestione del rapporto con i vendor

Un aspetto spesso trascurato riguarda la relazione con i produttori di dispositivi medicali. La NIS2 impone esplicitamente requisiti di sicurezza della supply chain (Articolo 21(2)(d)), richiedendo alle organizzazioni sanitarie di valutare e monitorare la postura cyber dei propri fornitori.

I Manufacturer Disclosure Statements for Medical Device Security (MDS2) forniscono informazioni strutturate sulla sicurezza dei dispositivi, ma troppo spesso rimangono documenti statici che non vengono operazionalizzati. L’integrazione dei dati MDS2 con le piattaforme di microsegmentazione consente di tradurre automaticamente le caratteristiche di sicurezza dichiarate dal vendor in policy di protezione effettive.

Prospettive evolutive: verso una convergenza normativa

Il paradosso normativo tra MDR e requisiti cyber non potrà rimanere irrisolto a lungo. Diversi segnali indicano una progressiva consapevolezza della necessità di armonizzazione.

L’Action Plan europeo sulla cybersecurity ospedaliera

Il 15 gennaio 2025 la Commissione Europea ha pubblicato un Action Plan dedicato alla cybersecurity di ospedali e provider sanitari. Il documento riconosce esplicitamente l’interdipendenza tra provider sanitari e industria medicale, e propone misure che impattano l’intera supply chain del settore.

Tra le azioni più significative, il piano propone che gli Stati membri richiedano alle entità soggette a NIS2 di riportare i pagamenti di riscatti ransomware – un cambio significativo rispetto all’attuale framework. L’obiettivo dichiarato è raccogliere dati per comprendere l’efficacia delle misure anti-ransomware e supportare le investigazioni.

L’evoluzione dell’approccio FDA

Dall’altra parte dell’Atlantico, la FDA statunitense ha adottato un approccio più progressivo. Con la Sezione 524B del FD&C Act, introdotta nel dicembre 2022 tramite il Consolidated Appropriations Act, i produttori di dispositivi cyber sono ora obbligati a:

  • fornire una Software Bill of Materials (SBOM) che documenti tutti i componenti software;
  • progettare e mantenere processi per garantire la cybersecurity del dispositivo lungo l’intero ciclo di vita;
  • rendere disponibili aggiornamenti e patch post-market.

La guidance finale aggiornata di giugno 2025 chiarisce esplicitamente i requisiti per i cyber devices e le aspettative per il ciclo di vita post-market.

Il Cyber Resilience Act europeo

Il Cyber Resilience Act europeo, parte del più ampio framework di cybersecurity dell’Unione, introduce requisiti di sicurezza by-design per i prodotti con componenti digitali. L’integrazione tra CRA, MDR e NIS2 dovrà necessariamente portare a un approccio più coerente alla gestione delle vulnerabilità nei dispositivi medicali.

Considerazioni conclusive

La sicurezza dei dispositivi medicali IoMT si trova oggi al centro di una tensione normativa che riflette due concezioni diverse – ma entrambe legittime – della protezione del paziente. La certificazione CE tutela il paziente da malfunzionamenti del dispositivo; la cybersecurity lo tutela da attacchi che potrebbero comprometterne l’integrità o renderlo indisponibile nel momento del bisogno.

La securizzazione laterale rappresenta, allo stato attuale, la risposta più efficace a questo paradosso. Proteggere il contesto invece del dispositivo consente di implementare misure di sicurezza robuste senza entrare in conflitto con i requisiti regolatori sulla certificazione.

Tuttavia, questa soluzione architetturale non può rimanere l’unica risposta a lungo termine. È necessario che il framework normativo europeo evolva verso un modello che consenta l’aggiornamento tempestivo dei dispositivi medicali senza richiedere complesse ri-certificazioni per ogni patch di sicurezza. L’esperienza FDA dimostra che questo equilibrio è possibile.

Nel frattempo, i professionisti della sicurezza IoMT nel settore sanitario devono adottare un approccio pragmatico: implementare la microsegmentazione come misura di protezione immediata, mantenere una visibilità completa sull’inventario dei dispositivi connessi e strutturare un dialogo costruttivo con i vendor per accelerare la disponibilità di aggiornamenti validati.

La posta in gioco è troppo alta per attendere una soluzione normativa perfetta. La significativa presenza di vulnerabilità note nei dispositivi medicali ospedalieri non è una statistica accettabile. È un rischio che richiede azione immediata, nei limiti – ma non oltre – di quanto la normativa consente.

Condividi sui Social Network:

https://www.ictsecuritymagazine.com/articoli/iomt/




Prova digitale tra garanzie costituzionali, prassi operative e “copia-mezzo”

L’avvento della Digital Forensics ha imposto una transizione irreversibile ed inarrestabile nel paradigma investigativo, la ricostruzione del fatto storico è migrata in un’istante dalla tradizionale (e spesso fallibile) prova dichiarativa verso un modello di accertamento scientifico del dato.

In questo scenario, la Legge 48/2008 ha rappresentato lo spartiacque normativo necessario per recepire la Convenzione di Budapest, ma il suo limite è emerso chiaramente nella prassi: se da un lato ha codificato il “come” (blindando l’acquisizione tramite protocolli di integrità e immodificabilità, come l’hashing e la catena di custodia), dall’altro ha lasciato una zona d’ombra sul “cosa” sia legittimo acquisire e, soprattutto, sul limite temporale della detenzione del dato e gestione dello stesso. È proprio in questo vuoto che si inserisce l’elaborazione giurisprudenziale della “copia-mezzo”.

Ontologicamente, la copia-mezzo non rappresenta l’oggetto del sequestro in sé, ma si configura come una “copia servente” (il mezzo): uno strumento tecnico-giuridico volto a bilanciare l’esigenza investigativa con il diritto alla restituzione del “contenitore” fisico (smartphone, workstation, notebook etc.) all’avente diritto.

Si assiste, di fatto, alla dematerializzazione della perquisizione, che si sposta dal piano fisico a un ambiente digitale controllato. Tuttavia, come evidenziato dalla Suprema Corte[1] , questa copia speculare genera un paradosso investigativo: essa cristallizza una massa di dati “indistinti e magmatici”, un vero e proprio “ecosistema digitale”[2] che, ab origine, è privo di una funzione probatoria definita e contiene la totalità della vita privata dell’interessato. La legittimità della ritenzione di tale massa è dunque subordinata a un vincolo temporale e finalistico stringente: il “tempo strettamente necessario”[3] per l’attività di filtering e selezione dei dati pertinenti.

Oltrepassare tale limite significa snaturare l’istituto: senza una selezione mirata, la copia-mezzo smette di essere uno strumento probatorio e diventa una forma di sequestro esplorativo indiscriminato, eludendo il precetto dell’art. 253 c.p.p. e trasformando l’indagine in una pericolosa attività di fishing expedition (pesca a strascico) vietata dal nostro ordinamento.

Il dato comunicativo tra “documento” e “corrispondenza”: la nuova barriera della Corte Costituzionale

La complessità epistemologica della “copia-mezzo”, appena introdotta, raggiunge, probabilmente il suo apice critico, quando l’analisi si sposta dai file statici al dominio della comunicazione digitale, sempre più diffusa nella nostra quotidianità.

La rivoluzione interpretativa innescata da qualche anno dalla Corte Costituzionale (sent. 170/2023) e dalle Cassazione [4] ha scardinato la prassi consolidata che considerava SMS, e-mail e messaggistica istantanea (WhatsApp, Telegram) alla stregua di meri “documenti” una volta archiviati nella memoria del dispositivo. Si è oggi affermato un principio di “ultra-vitalità ed attualità della corrispondenza”: il dato comunicativo, finché conserva un carattere di attualità per gli interlocutori e non degrada a mero reperto storico, rimane protetto dall’inviolabile scudo dell’art. 15 della Costituzione.

Questa ontologia del dato impone un radicale cambio di passo: l’acquisizione non può più avvenire tramite un generico decreto di sequestro probatorio (art. 253 c.p.p.), ma esige un atto motivato che rispetti le forme dell’art. 254 c.p.p., con tutte le garanzie che ne conseguono in termini di riserva di giurisdizione. Sul piano operativo, l’impatto per la Polizia Giudiziaria e per gli specialisti di Digital Forensics è, per certi versi, dirompente. La prassi dell’ispezione immediata del contenuto del dispositivo al momento del sequestro – volta a ricercare “a caldo” elementi utili – diviene un terreno minato.

L’operatore deve oggi limitarsi alla mera apprensione fisica o alla duplicazione integrale (bit-stream image) del supporto, astenendosi da qualsiasi attività di cognizione diretta del contenuto comunicativo prima dell’emissione di un decreto specifico. Ogni incursione non autorizzata nel “flusso del pensiero” cristallizzato nei messaggi rischia di generare un’inutilizzabilità patologica della prova, rendendo vano lo sforzo investigativo.

A questo scenario interno si sovrappone la pressione della giurisprudenza sovranazionale. La Corte di Giustizia UE (sent. C-548/21)<[5] sta spingendo verso un modello in cui l’accesso ai dati digitali sia subordinato al controllo preventivo di un giudice o di un’autorità amministrativa indipendente.

Questo orientamento mette in crisi l’architettura del nostro Codice, laddove il Pubblico Ministero, pur essendo parte dell’Autorità Giudiziaria, è percepito dalla giurisprudenza europea come parte processuale priva di quella terzietà assoluta necessaria per autorizzare l’intrusione massiva nella sfera privata garantita dai moderni smartphone. In sintesi, la “copia-mezzo” non è più solo un contenitore tecnico, ma un sacrario di diritti che la tecnica forense deve imparare a maneggiare con estrema cautela procedurale.

Il mosaico delle prassi: la risposta resiliente delle Procure al vuoto normativo

In attesa di un intervento organico del legislatore — con lo sguardo rivolto al dibattito sul DDL S. 806 (approvato) – C.1822 (in corso di esame in commissione)[6]— il panorama nazionale si presenta come un laboratorio a cielo aperto.

Le Procure italiane, consapevoli che la “copia-mezzo” non può più essere “negata” ma va gestita[7], hanno elaborato linee guida (direttive) [8] che tentano di sintetizzare due esigenze opposte: il rigore del “Giusto Processo – Fair Trial” e l’efficacia dell’azione di contrasto al crimine.

L’evoluzione della Digital Forensics nel panorama giudiziario italiano ha imposto l’adozione di protocolli d’azione che, pur in assenza di una riforma organica del codice di rito, garantiscano l’integrità del dato e la tenuta costituzionale delle indagini, in particolare dall’analisi delle direttive emanate dalle principali Procure della Repubblica, emerge innanzitutto un solido nucleo di tratti comuni, che costituiscono ormai il “minimo denominatore” della disciplina.

Tutte le direttive/circolari concordano sulla natura strumentale e temporanea del sequestro del supporto fisico: lo smartphone o il PC non sono più il fine dell’apprensione, ma il mero veicolo per giungere alla formazione della “copia-mezzo”. Il riconoscimento della copia forense come unico ambiente di analisi investigativa e l’obbligo di restituzione immediata dell’originale rappresentano il pilastro di un sistema che tenta di rispettare il principio di proporzionalità, limitando l’invasività del sequestro ai soli tempi tecnici di duplicazione bit-stream.

Tuttavia, superata questa base metodologica, il panorama si frammenta in un mosaico di prassi e direttive che riflettono diverse interpretazioni del bilanciamento tra efficienza e garanzie. Questo sforzo di auto-regolamentazione ha prodotto modelli d’eccellenza che nelle loro similitudini e differenze meritano un’analisi di dettaglio.

La Procura di Trento, ad esempio, declina il tema con un marcato accento sulla protezione dei dati personali. La sua direttiva si distingue per una lotta serrata contro la proliferazione dei cosiddetti “archivi di massa paralleli”. In questa visione, la Polizia Giudiziaria non deve trattenere duplicati informali che potrebbero trasformarsi in banche dati permanenti al di fuori del controllo giudiziario. Il focus trentino è quasi “ecologico”: una volta selezionato il dato pertinente (chat, mail, messaggistica), tutto ciò che è eccedente deve essere rimosso, per evitare che la vita privata di indagati o terzi rimanga cristallizzata nei server degli uffici investigativi senza una reale necessità processuale.

Spostandoci verso il modello adottato dalla Procura di Bari, l’attenzione si sposta sul rigore procedurale e sulla compartimentazione delle competenze. Qui, la differenza sostanziale risiede nella “neutralizzazione” tecnica della Polizia Giudiziaria nella fase di analisi profonda. Agli operanti è richiesto un ruolo di primi soccorritori (First Responders): devono isolare il dispositivo e assicurarne l’integrità. La fase successiva, quella della creazione della copia e del filtering, viene idealmente sottratta alla discrezionalità investigativa per essere affidata al tecnicismo dei consulenti ex art. 359 c.p.p. L’uso della crittografia obbligatoria per la copia-mezzo, con chiavi consegnate in busta chiusa al PM, eleva lo standard di sicurezza a un livello quasi notarile, rendendo Bari l’avamposto della “certificazione del dato”.

Un approccio radicalmente diverso è quello che emerge dalla Procura di Roma, la quale rivendica con forza l’autonomia investigativa del Pubblico Ministero. Mentre la tendenza europea spinge per un controllo preventivo del giudice, il modello romano difende la prerogativa dell’organo inquirente di disporre il sequestro senza autorizzazione del GIP, a patto che il decreto sia supportato da una motivazione “chirurgica”. Roma non punta sulla distruzione immediata o sulla delega a terzi, ma sulla qualità della perimetrazione investigativa: è il magistrato che, definendo parole chiave e archi temporali, deve farsi garante della pertinenza, mantenendo però la rapidità d’azione tipica della fase inquirente.

Infine, le realtà di Torino e Cagliari introducono una variabile fondamentale per la tenuta del futuro processo: la “copia di sicurezza”. Queste Procure hanno compreso che la cancellazione eccessivamente zelante dei dati non pertinenti potrebbe paradossalmente ledere il diritto di difesa. Torino, in particolare, si distingue per l’adozione di standard tecnologici elevati, come l’uso dei nastri magnetici LTO, per conservare una copia integrale in un “limbo” protetto.

Questa scelta operativa garantisce la parità delle armi, permettendo alla difesa di accedere, se autorizzata, a quella massa magmatica originaria che la PG potrebbe aver scartato, ma che potrebbe contenere elementi a discarico. Cagliari, dal canto suo, specifica con precisione i provvedimenti di distruzione nel caso di assenza di esigenze conservative, ma ribadisce che tale atto deve sempre fare salvo il diritto al contraddittorio, ponendosi come sintesi equilibrata tra il rigore della privacy di Trento e le esigenze garantiste di Torino.

In conclusione, sebbene il “punto di partenza” (la copia forense) sia identico per tutte, il “punto di arrivo” varia significativamente: dalla distruzione cautelativa di Trento alla conservazione archivistica di Torino, passando per il blindaggio tecnico di Bari e il pragmatismo inquirente di Roma. Questo scenario delinea un’Italia a più velocità, dove la Digital Forensics non è solo una disciplina tecnica, ma un vero e proprio esercizio di ingegneria costituzionale applicata.

Selezione del dato e crisi del contraddittorio nell’analisi forense

Il passaggio dalla “massa magmatica” della copia-mezzo alla formazione della prova utilizzabile in dibattimento non è un’operazione neutra, ma un processo di distillazione tecnicamente insidioso e giuridicamente parziale, invero, se la creazione della copia forense garantisce l’integrità del reperto, è nella fase di selezione che si gioca il destino del processo.

Tuttavia, gli strumenti oggi utilizzati per setacciare i gigabyte di vita digitale contenuti in uno smartphone si rivelano spesso inadeguati o, peggio, forieri di pericolosi bias investigativi[9].

L’uso delle keyword (parole chiave), pur essendo il metodo più diffuso, manifesta limiti strutturali che rasentano la fallacia metodologica. Da un lato, l’utilizzo di termini troppo generici genera un “rumore di fondo” che viola il principio di proporzionalità, trascinando nel fascicolo processuale stralci di vita privata del tutto irrilevanti. Dall’altro, l’impiego di termini eccessivamente specifici rischia di fallire l’obiettivo, non intercettando comunicazioni occultate dietro linguaggi gergali o criptici.

Nel gergo dei narcotrafficanti, termini come “bamba” o “bimba” / “ananas” o “banane” sostituiscono la sostanza stupefacente, rendendo una ricerca testuale standard del tutto inefficace. La selezione, dunque, non è mai un atto puramente meccanico, ma un’operazione semantica complessa che richiede un’interpretazione contestuale che la macchina, da sola, non può fornire. Peraltro, un “sistema” complesso e cronologico, basato su una tempistica stringente come quello della “copia-mezzo” non sempre permette di apprezzare compitamente quali siano i termini gergali o criptici se non dopo una peculiare analisi dell’intero “patrimonio digitale” acquisito all’indagine. Il cuore della criticità risiede nella natura unilaterale di questa attività.

La prassi attuale delega la delicata fase del filtering al consulente tecnico del PM o alla Polizia Giudiziaria, spesso confinando la difesa in un ruolo meramente passivo. Sebbene l’acquisizione della copia sia tecnicamente ripetibile (art. 359 c.p.p.), la selezione dei dati avviene in un cono d’ombra dove il contraddittorio è assente. Il rischio è la cristallizzazione di un quadro probatorio parziale: se l’accusa seleziona solo i frammenti che confermano l’ipotesi di reato, la verità processuale risulterà irrimediabilmente zoppa.

In questo solco si inseriscono le proposte del DDL 806, già prima richiamato e le riflessioni della dottrina più avanzata, che premono per una “proceduralizzazione” della selezione. L’obiettivo è anticipare il contraddittorio già nella fase di definizione dei criteri di ricerca.

Trasformare l’accertamento da consulenza unilaterale in una sorta di “perizia garantita“ — magari attraverso lo schema dell’incidente probatorio (art. 360 c.p.p.) — permetterebbe alla difesa di interloquire su cosa cercare e con quali strumenti, garantendo che l’indagine non diventi una ricerca a senso unico[10]. Un aspetto troppo spesso trascurato è il pericolo legato alla distruzione della copia-mezzo dopo la selezione iniziale. Operativamente, ogni indagine vive di una “escalation investigativa“: elementi emersi mesi dopo il sequestro potrebbero dare un significato nuovo a dati inizialmente scartati.

Se la copia integrale viene distrutta in nome di una privacy malintesa o di una prassi frettolosa, si preclude definitivamente la possibilità di correlare nuovi indizi a vecchi dati, mutilando sia la capacità di accertamento della verità da parte del PM, sia il diritto della difesa di ricercare elementi a discarico emersi in un secondo momento. La sfida della moderna Digital Forensics è dunque questa: proteggere la privacy senza accecare la giustizia, e garantire la prova senza sacrificare il diritto alla difesa nel nome di un’efficienza puramente formale.

Oltre la tecnica: verso un’etica della prova digitale e il nuovo ruolo del giudice

Il percorso fin qui delineato rende evidente come il quadro attuale non sia più sostenibile attraverso il solo strumento delle prassi circolari o dell’auto-regolamentazione delle singole Procure. Siamo giunti a un punto di rottura epistemologico che esige un intervento legislativo organico e coraggioso. In questo senso, il DDL 806 non rappresenta solo una proposta normativa, ma una vera e propria necessità di civiltà giuridica: il passaggio verso un controllo giurisdizionale preventivo (affidato al GIP) sul sequestro dei dispositivi elettronici non è più procrastinabile e richiede una presa di posizione che permetta di uscire dalla situazione “a macchia di leopardo” in cui oggi gli addetti ai lavori si trovano ad operare[11].

Equiparare l’intrusione digitale alle intercettazioni telefoniche significa finalmente riconoscere che uno smartphone non è un semplice oggetto, ma l’estensione digitale dell’anima e della libertà della persona.

Sottrarre al Pubblico Ministero la gestione esclusiva di una fase così pervasiva risponde non solo alle pressanti sollecitazioni della giurisprudenza sovranazionale (Corte EDU e CGUE), ma riporta l’equilibrio tra poteri al centro del processo penale. La “copia-mezzo” deve cessare di essere un’appendice tecnica gestita unilateralmente per diventare il fulcro di una procedura garantita, dove la duplicazione avvenga in un contraddittorio effettivo e il “congelamento” del dato sia funzionale a una selezione partecipata, e non a un’acquisizione indiscriminata.

In questa nuova architettura della prova, il tecnico forense non è più solo un estrattore di bit, ma un custode di garanzie. La sfida del futuro legislatore sarà quella di codificare un sistema capace di prevenire le cosiddette “pesche a strascico” (fishing expeditions) nella vita privata dei cittadini, garantendo che ogni byte acquisito rispetti rigorosamente i canoni di pertinenza e proporzionalità.

La “copia-mezzo”, in definitiva, non può e non deve più essere considerata un mero artefatto transitorio. Essa è lo specchio di una metamorfosi che vede il processo penale misurarsi con la complessità dell’era digitale, solo attraverso una sintesi equilibrata tra rigore tecnico, controllo del giudice e centralità del contraddittorio, potremo assicurare che la ricerca della verità non avvenga mai a discapito dei diritti fondamentali, trasformando la Digital Forensics da strumento di potenziale oppressione a presidio di legalità e giustizia.

Se il dato è il “nuovo petrolio”, la procedura penale deve esserne il raffinato sistema di controllo ambientale, per evitare che la fuoriuscita indiscriminata di informazioni personali inquini irrimediabilmente le basi dello Stato di Diritto.

Note:

[1] Cass. pen. Sez. VI, Sent., (ud. 09-12-2020) 19-02-2021, n. 6623 – Sez. VI, n. 34265 del 22/9/2020, Aleotti, Rv. 279949; ma per riferimenti alle modalità operative si rinvia anche a Sez. VI, n. 13165 del 4/3/2020, Scagliarini, Rv. 279143.

[2] Un vero e proprio “ecosistema digitale” che, nella realtà tecnologica odierna, risulta ulteriormente esaltato dal fenomeno della sincronizzazione permanente. Quest’ultima trasforma il dato da elemento statico, confinato nel singolo hardware, in un flusso ubiquo che si concretizza nella circolazione bidirezionale tra dispositivi fisici (smartphone, tablet, PC) e infrastrutture cloud. Ne deriva che l’ecosistema del soggetto non è più una “scatola” chiusa, ma un reticolo di informazioni costantemente aggiornate e speculari, dove il confine tra memoria locale e archivio remoto sfuma, rendendo la cristallizzazione investigativa ancora più complessa e invasiva.

[3] Cass. Pen., Sez. VI, n. 543/2026.

[4] In particolare: Sez. VI, n. 34265 del 22/9/2020, Aleotti, Rv. 279949 – Cass. pen. Sez. VI, Sent., (ud. 21-05-2024) 30-07-2024, n. 31180.

[5] https://archiviopenale.it/corte-di-giustizia-dell-unione-europea-(grande-camera)-4-ottobre-2024-causa-c-548-21/contenuti/29682

[6] https://www.senato.it/leggi-e-documenti/disegni-di-legge/scheda-ddl?did=57327

[7] Già citata in nota 3 – Cass. Pen. Sez. VI, sentenza n. 543 depositata l’8 gennaio 2026.

[8] Dirette alla PG e al PM.

[9] Talvolta aggravati dall’utilizzo sempre più spinto di sistemi di intelligenza artificiale. In merito rimando ad altri miei articoli e ad altri contributi reperibili in rete: “Pier-Luca Toselli, AI e digital forensics”.

[10] Sui lavori in corso in Parlamento, rinvio a questo link: https://www.camera.it/leg19/126?leg=19&idDocumento=1822
dove si possono leggere, nella sezione Attività conoscitiva, le audizioni informali, tra gli altri, di Giovanni Melillo, procuratore nazionale antimafia e antiterrorismo; Cesare Parodi, presidente dell’Associazione nazionale magistrati; Francesco Cajani, Sostituto Procuratore della Repubblica presso il Tribunale di Milano; Maurizio De Lucia, Procuratore della Repubblica di Palermo.

[11] Si pensi alle situazioni investigative che interessano più Procure con diverse direttive.

Profilo Autore

Sono un ufficiale di polizia Giudiziaria che ha maturato un’esperienza ormai trentennale nel settore della sicurezza e delle investigazioni, con specifico riferimento negli ultimi 8 anni alla digital forensic per la quale ho conseguito la qualifica di Computer Forensic e Data Analysis . L’esperienza ha anche permesso di consolidare ed affinare una solida preparazione tecnico-giuridica sia nel settore delle investigazioni in genere sia in quello più prettamente informatico. Sono stato docente nell’ambito del Master Executive di II livello in Criminologia e Cyber Security – Modulo 7: Lotta al Crimine organizzato (Master Sida – Fondazione INUIT Tor Vergata).

Condividi sui Social Network:

https://www.ictsecuritymagazine.com/articoli/copia-mezzo/