Questo sito web utilizza cookie tecnici e, previo Suo consenso, cookie di profilazione, nostri e di terze parti. Chiudendo questo banner, scorrendo questa pagina o cliccando qualunque suo elemento acconsente all'uso dei cookie. Leggi la nostra Cookie Policy per esteso.OK

La PA dimentica la sicurezza delle applicazioni: 5 punti per rimediare

Home PA Digitale Sicurezza Digitale La PA dimentica la sicurezza delle applicazioni: 5 punti per rimediare

25 Novembre 2015

A

Andrea Rigoni, consulente

L’incidente avvenuto qualche settimana fa in Lombardia Informatica è l’ennesima dimostrazione che la situazione della sicurezza informatica nella PA ha bisogno non solo di maggiore attenzione, ma di un cambio radicale di approccio, in particolare nello sviluppo applicativo.

Non siamo ancora arrivati a comprendere che la sicurezza non è data da un software, da una funzionalità o da un progetto specifico. Questo era vero vent’anni fa. Ma le cose sono cambiate. Radicalmente.

In una PA moderna, come d’altronde in una azienda, la sicurezza è una garanzia che viene offerta alla comunità, ai cittadini e ai dipendenti; è un modo di acquisire, di sviluppare, di far evolvere e di gestire (e dismettere) le applicazioni e i servizi della PA.

Questo approccio è oramai consolidato in molti settori in cui la sicurezza è chiave: dalla costruzione/gestione di complesse opere architettoniche (ponti, stadi, aeroporti), ai sistemi di trasporto (aereo, ferroviario, navale). Ognuno di questi sistemi viene concepito in modo sicuro fin dall’inizio: la sicurezza è una disciplina che accompagna ogni fase.

Come per gli altri settori, anche in quello ICT è fondamentale l’analisi e la gestione del rischio: è la guida che accompagna e indirizza ogni scelta. La gestione del rischio è fondamentale per individuare le giuste contromisure, ma anche le necessarie evoluzioni dovute all’evoluzione della minaccia.

Esistono diversi riferimenti per lo sviluppo sicuro del software: tra i più completi e maturi vi è quello sviluppato dal NIST americano. Si tratta del System Development Life Cycle (SDLC), ovvero di un processo in cinque fasi, le cui attività sono descritte puntualmente in ben 25 standard diversi. Le cinque fasi individuate dal NIST sono:

  1. Fase preliminare: è il momento in cui una applicazione viene pensata e in in cui vengono definiti i requisiti. In questa fase sarebbe fondamentale ingaggiare i partner tecnologici, documentare le architetture nelle quali l’applicazione verrà inserita, identificare le policy, gli standard e le norme a cui dovrà sottostare, identificare i requisiti in termini di Confidenzialità, Integrità e Disponibilità, svolgere una analisi dei rischi preliminare
  2. Acquisizione e sviluppo: in questa fase è fondamentale svolgere una analisi dei rischi completa e sulla base di questa e degli elementi della fase precedente, identificare i controlli e le contromisure di sicurezza necessarie; i controlli verranno selezionati tra quelli messi a disposizione dagli standard e dalle guide di riferimento. In ambito PA, questi riferimenti non esistono ancora. Negli altri paesi, questi controlli sono definiti da standard e riferimenti estremamente dettagliati (si vedano ad esempio gli Standard NIST come l’SP800.53 rev.4 sui Controlli di Sicurezza o l’SP800-36 sulla selezione dei prodotti di sicurezza informatica)
  3. Implementazione: è la fase in cui si verifica che i prodotti acquisiti rispondano ai requisiti definiti nelle fasi precedenti; si procede all’integrazione dei controlli con i processi e le procedure dell’organizzazione, come ad esempio i processi di monitoraggio e compliance; se fossero disponibili standard di riferimento per la PA, questa sarebbe la fase in cui l’applicazione andrebbe certificata
  4. Gestione/Manutenzione: in questa fase, si gestisce la sicurezza dell’applicazione durante il suo uso corrente e la sua manutenzione. E’ la fase spesso più trascurata da un punto di vista di sicurezza. Il monitoraggio continuo è uno degli aspetti chiave, finalizzato alla rilevazione e alla gestione delle intrusioni. E’ fondamentale anche verificare la presenza di vulnerabilità che nel frattempo potrebbero essere state scoperte nelle componenti applicative o di sistema attraverso attività periodiche di audit. In caso di certificazione, si dovrebbe procedere alla ricertificazione e riaccreditamento periodico.
  5. Dismissione: la sicurezza va gestita anche in fase di dismissione di una applicazione. Oltre al piano di transizione, è fondamentale definire un opportuno piano di smaltimento delle componenti, inclusa una “sanitizzazione” dei dispositivi di archiviazione e una archiviazione cautelativa del codice e dei dati per eventuali necessità future.

Tale principio è contenuto nel Piano di Crescita Digitale 2014-2020: avevo già avuto modo di proporre questo tema all’AgID, che lo aveva incluso nel Piano. A pag. 50 il Piano recita: “Il Governo Italiano attraverso l’Agenzia per l’Italia Digitale definisce gli Standard e le linee guida di sicurezza per tutta la pubblica amministrazione. L’aderenza agli standard di servizio e di processo sarà̀ obbligatorio per tutte le Amministrazioni Pubbliche.”.

Tale indicazione è in linea con gli indirizzi Strategici del Quadro Strategico Nazionale per la Sicurezza dello Spazio Cibernetico, pubblicata nel 2014, in particolare l’indirizzo n. 2 che recita: potenziamento delle capacità di difesa delle Infrastrutture Critiche nazionali e degli atto- ri di rilevanza strategica per il sistema-Paese assicurando la business continuity e, al contempo, la compliance con standard e protocolli di sicurezza internazionali”.

I principi e le indicazioni ci sono, ora è il momento di passare all’azione, definendo un quadro di riferimento per la sicurezza nella PA e cominciando a definire gli Standard e i processi di compliance/certificazione. Per farlo è però necessario disporre di risorse competenti e di una visione chiara.

Su questo argomento

APP PA: l'elenco delle app ufficiali della Pubblica Amministrazione