India: nuove regole di sicurezza per smartphone, tra le richieste anche la revisione del codice sorgente

Oggi lo smartphone non è solo un telefono: è un portafoglio, un archivio di identità digitali, un punto d’accesso a servizi bancari e un hub di autenticazione. Per questo, le regole sulla sicurezza degli smartphone non sono un dettaglio tecnico: determinano come si gestiscono vulnerabilità, permessi e aggiornamenti in milioni di dispositivi.

In India, il tema assume un peso specifico enorme: per dimensione del mercato, crescita dei servizi digitali e pressione su frodi e attacchi informatici. È in questo scenario che una proposta di standard tecnici può diventare un caso globale, perché tocca un nervo scoperto: fino a che punto un governo può chiedere accesso a componenti proprietarie per aumentare la sicurezza?

La notizia non è che “l’India vuole più sicurezza”. La notizia è come intende ottenerla. Secondo Reuters, il pacchetto di requisiti in discussione include una serie di controlli che vanno dal comportamento delle app in background fino alla gestione degli aggiornamenti. E, soprattutto, introduce la richiesta di mettere a disposizione codice sorgente per revisione in laboratori designati.

Sommario dei contenuti

• Cosa sta succedendo e a che punto siamo
• Codice sorgente: perché divide e cosa significa
• Requisiti chiave: permessi, log, malware, app preinstallate
• Update e patch: il tema del tempo
• Chi sono NCCS e MAIT
• Cosa resta da chiarire: le domande aperte
• Guida pratica: cosa fare già oggi
• FAQ

Cosa sta succedendo e a che punto siamo

Reuters riferisce che l’India sta valutando di rendere più stringenti e potenzialmente vincolanti nuovi requisiti di sicurezza per gli smartphone. Il pacchetto, descritto come composto da 83 standard, è stato discusso in sede tecnica e ora è al centro di un confronto tra governo e aziende.

Il punto chiave è che le aziende non contestano la necessità di sicurezza in sé, ma il perimetro e il processo. La sicurezza moderna vive di patch rapide, test ripetibili e procedure certe. Se la proposta non definisce metodi di test e tempi garantiti, il rischio è una compliance difficile e, paradossalmente, una sicurezza meno efficace.

Codice sorgente: perché divide e cosa significa

Il requisito più controverso, secondo Reuters, è la richiesta ai produttori di testare e fornire codice sorgente proprietario per una revisione in laboratori designati dal governo, con l’obiettivo di identificare vulnerabilità nel sistema operativo che potrebbero essere sfruttate da attaccanti.

Dal punto di vista tecnico, la revisione del codice può avere un vantaggio chiaro: se fatta bene, aiuta a individuare errori logici, componenti deboli, gestione non sicura delle chiavi e vulnerabilità strutturali. Il problema è come viene fatta e con quali garanzie. Il codice sorgente è il cuore di un sistema: se circola senza un perimetro robusto di confidenzialità, aumenta il rischio di fuga di informazioni sensibili e di ricostruzione di parti critiche.

Reuters riporta che l’associazione di settore MAIT (Manufacturers’ Association for Information Technology) avrebbe detto al governo che la misura è “non possibile” per ragioni di segreto industriale e politiche globali di privacy. È un punto che, in termini pratici, può tradursi in due scenari: o una riscrittura del requisito (audit mirati, accesso limitato, procedure equivalenti), oppure un braccio di ferro sul principio.

Requisiti chiave: permessi, log, malware, app preinstallate

1) Restrizioni ai permessi in background e notifiche “sempre visibili”

Tra i requisiti riportati da Reuters c’è il divieto per le app di accedere a camera, microfono e posizione in background quando il telefono è inattivo. Inoltre, sarebbe richiesta una notifica continua nella barra di stato quando questi permessi sono attivi.

La logica è comprensibile: la maggior parte degli abusi passa da permessi “silenziosi”. La criticità è definire cosa significhi “inattivo” e gestire i casi d’uso legittimi (sicurezza, emergenza, navigazione, accessibilità, gestione dispositivi). Se il requisito non precisa test e eccezioni, rischia di creare malfunzionamenti o un eccesso di notifiche.

2) Avvisi periodici per la revisione dei permessi

Un altro punto è l’obbligo di mostrare periodicamente avvisi che invitino gli utenti a rivedere i permessi concessi alle app, con notifiche continuative. Le aziende, secondo Reuters, propongono invece un approccio più selettivo, limitato ai permessi realmente critici.

In termini di esperienza utente, il rischio è la “fatica da notifiche”: se un avviso si ripete troppo spesso, viene ignorato. Qui la differenza la fanno frequenza, priorità e chiarezza: avvisi pochi, ma espliciti e utili, migliorano davvero la sicurezza.

3) Log di sicurezza per 12 mesi

Reuters riferisce l’obbligo di conservare per 12 mesi log di audit di sicurezza, inclusi eventi come installazioni di app e tentativi di login. L’industria contesta la capacità di storage su telefoni consumer e l’impatto operativo.

Dal punto di vista di cybersecurity, la retention dei log è utile per analisi forense e diagnosi di incidenti, ma apre domande immediate: dove si salvano i log, come si proteggono, chi può accedervi, quali dati contengono, come si evita che diventino un ulteriore bersaglio. Senza regole su cifratura, minimizzazione e accessi, una misura pensata per aumentare la sicurezza può generare un nuovo rischio.

4) Scansioni malware periodiche

La proposta includerebbe scansioni periodiche per malware e identificazione di app potenzialmente dannose. Reuters riporta che i produttori temono impatti significativi su batteria e prestazioni se le scansioni sono costanti e invasive.

Qui la sostenibilità tecnica è decisiva: scansioni troppo frequenti e non differenziate possono diventare un costo per l’utente. Un approccio più efficace, spesso, è la combinazione tra controlli in store, verifiche comportamentali mirate e scansioni “a rischio”, non una scansione continua per qualunque dispositivo e contesto.

5) Rimozione delle app preinstallate

Tra i punti più favorevoli ai consumatori c’è la possibilità di eliminare app preinstallate non essenziali. Secondo Reuters, il requisito prevederebbe che tutte le app preinstallate, salvo quelle necessarie alle funzioni di base del telefono, siano disinstallabili.

La difficoltà sta nel confine tra “essenziale” e “di sistema”. In molti telefoni alcune app sono interfacce a componenti di sistema, o gestiscono funzioni come chiamate, messaggi, aggiornamenti, backup e sicurezza. Una regola utile deve indicare criteri chiari per evitare che la disinstallazione comprometta stabilità e aggiornamenti.

Update e patch: il tema del tempo

Reuters segnala un requisito che preoccupa molte aziende: i produttori dovrebbero notificare a un’organizzazione governativa prima di rilasciare aggiornamenti importanti o patch di sicurezza. Il motivo della contestazione è semplice: quando c’è una vulnerabilità attiva, si corre contro il tempo.

Qui la parola chiave è “notifica”. Se la notifica è un preavviso tecnico a fini di tracciabilità, può essere gestibile. Se si trasforma in un passaggio che blocca o rallenta, diventa un problema di sicurezza operativo. Senza tempi garantiti e senza distinguere tra update ordinari, patch critiche e aggiornamenti di funzionalità, la misura rischia di colpire proprio il meccanismo che oggi protegge gli utenti: la rapidità.

Root, jailbreak e anti-rollback: protezioni avanzate, ma complesse

Tra i requisiti indicati da Reuters ci sono anche avvisi continui in caso di root o jailbreak e una protezione anti-rollback che impedisca di installare versioni più vecchie del software, anche se firmate dal produttore.

L’obiettivo è ridurre i “downgrade” a versioni vulnerabili e segnalare quando il telefono ha perso le protezioni di base. Ma la complessità è reale: rilevare con certezza alcune manomissioni non è banale, e un blocco troppo rigido può creare problemi a riparazioni, assistenza e recupero. Per essere efficace, una regola deve descrivere cosa si intende per “manomissione” e quali sono le vie legittime di ripristino.

Chi sono NCCS e MAIT

NCCS è il National Centre for Communication Security, un centro collegato alle politiche di sicurezza delle comunicazioni in ambito telecom. Nella documentazione pubblica, NCCS inquadra le proprie attività anche nella logica della certificazione e della tutela delle reti e dei sistemi di comunicazione.

MAIT è la Manufacturers’ Association for Information Technology, associazione industriale che rappresenta il settore hardware e ICT in India. Nella ricostruzione Reuters, MAIT è l’interlocutore che veicola parte delle obiezioni tecniche e industriali, in particolare sul tema del codice sorgente e sulla fattibilità dei requisiti.

Cosa resta da chiarire: le domande aperte che contano più degli slogan

Se l’obiettivo è alzare la sicurezza, la qualità del risultato dipende dai dettagli. Ecco le questioni che, ad oggi, risultano decisive per capire se la proposta porterà benefici misurabili o costi senza ritorno.

• Che cosa viene considerato “major update”: una patch critica, un update mensile o un cambio di versione?
• Notifica o approvazione: la notifica è un passaggio informativo o un gate che può fermare il rilascio?
• Metodo di test: per i requisiti senza precedenti, quale test ripetibile e certificabile è previsto?
• Confidenzialità del codice: quali garanzie, audit e responsabilità per evitare fughe di informazioni sensibili?
• Log e privacy: cifratura, minimizzazione dei dati e accessi devono essere parte della regola, non un optional.

Guida pratica: cosa fare già oggi

Indipendentemente da come evolverà la proposta indiana, ci sono azioni che aumentano la sicurezza reale e riducono il rischio di frodi e compromissioni. Le trovi nella sezione dedicata subito dopo questo approfondimento, con indicazioni semplici e applicabili su iPhone e Android.

La qualità di una politica di sicurezza non si misura dalla severità dei requisiti, ma dalla capacità di produrre meno vulnerabilità e patch più rapide. È qui che la proposta indiana deve passare un test decisivo: evitare di introdurre attrito proprio nel processo che oggi protegge gli utenti.

La richiesta di revisione del codice sorgente è il punto più delicato perché mette insieme due verità: da un lato, conoscere il codice aiuta a trovare vulnerabilità; dall’altro, far circolare il codice aumenta i rischi se non esistono garanzie robuste di confidenzialità, tracciabilità e responsabilità. In cybersecurity, la fiducia non si chiede: si progetta.

Sul resto dei requisiti, la direzione può essere positiva (più trasparenza sui permessi, più controllo sulle app preinstallate), ma serve una logica di priorità. Se tutto diventa “notifica continua”, l’utente non legge più nulla. Una regola efficace deve aiutare l’utente a capire i rischi reali e intervenire nel modo giusto, senza trasformare il telefono in un pannello di allarmi permanente.

A cura di Junior Cristarella.