Sulla futura ISO/IEC 27001

Durante il meeting di Roma del WG1 dell'SC27, sono continuati i lavori sulla nuova ISO/IEC 27001, che dovrebbe uscire a ottobre 2013. Si osservi però che la versione attualmente in bozza è oggetta di parecchie critiche (personalmente, ne condivido solo una parte) e non è detto che la nuova norma verrà pubblicata.

La Polonia si è lamentata, tra le altre cose, che nella discussione nessuno ha fatto riferimento al proprio mercato di riferimento e alle sue richieste. Ciò mi ha fatto riflettere e ho pensato a quale possano essere le richieste del mercato italiano (accetto contributi):
- semplificazione dei requisiti del metodo di risk assessment perché la sua elaborazione, secondo lo schema del 2005, richiede troppe risorse togliendole ad altri progetti e non fornisce risultati sempre utili perché troppo di dettaglio
- irrobustimento delle garanzie per i clienti delle aziende che si certificano ISO/IEC 27001
- migliore leggibilità per garantire corrette relazioni tra organizzazioni certificate e auditor

Procedo quindi nel dare notizia delle novità più rilevanti.

Scopo dell'ISMS    Rimane il requisito generale di descrivere lo scopo dell'ISMS (da non confondere con la frasetta sul certificato), senza ulteriori specificazioni (ad esempio, "includendo le caratteristiche del business, dell'organizzazione, della localizzazione, dei beni e delle tecnologie") perché ritenute implicite; rimane il requisito di descrivere i confini dell'ISMS e le sue relazioni con entità esterne.    Il Giappone (e anche l'Italia) sono stati molto contrariati da questa scelta; personalmente, mi chiedo perché non voler esplicitare qualcosa di implicito, se questo può migliorare la leggibilità dello standard e ridurre incomprensioni tra imprese e auditor.    Anche in altre situazioni, l'Italia ha promosso l'aggiunta di testo esplicativo per migliorare la leggibilità dello standard e ridurre incomprensioni tra imprese e auditor. Purtroppo è prevalsa la linea della "eleganza": dove il requisito è implicito, non si aggiunge testo.

Direzione    Molto dibattere si è fatto sulle responsabilità della Direzione. In particolare, l'Australia ha voluto ridurle. Questo aspetto mi è risultato incomprensibile perché, a mio avviso, la norma attuale prevede (sintetizzo) che la Direzione garantisca la realizzazione dell'ISMS e comunichi l'importanza della sicurezza delle informazioni. Non mi sembrano compiti gravosi. 
    E' vero che molte Direzioni si disinteressano della sicurezza delle informazioni tranne quando c'è l'audit (e neanche questo caso si verifica sempre), ma fornire loro una giustificazione per farlo mi sembra scorretto. Tra l'altro, è ben noto che, se la Direzione si disinteressa della sicurezza delle informazioni, il resto dell'impresa farà altrettanto, con ovvi risultati. 
    Un'ultima riflessione: ogni articolo o conferenza ribadisce il concetto dell'importanza della Direzione: mi piacerebbe vedere ben sviluppati gli argomenti di chi è contrario, sempre che ciò sia possibile.

Processi e attività di business    Il testo "comune" alla future norme sui sistemi di gestione prevedeva frasi come "attività di business" o "processi di business". Su proposta dell'Italia è stata tolta la dizione "di business", in parte perché bisognerebbe capire quali sono le attività "non di business" e in parte perché, quali esse siano, la sicurezza delle informazioni si applicherebbe anche a loro.

Metodo di risk assessment    L'attuale ISO/IEC 27001 sviluppa una metodologia di risk assessment: individuare gli asset, le minacce e le vulnerabilità; valutare la verosimiglianza delle minacce e i loro potenziali impatti sugli asset. Tutto questo è stato eliminato: non si fa più riferimento agli asset, alle minacce o alle vulnerabilità. Si fa riferimento ai rischi che riguardano le informazioni.    Non mi pare sia un male: seppure implicitamente, si richiede di individuare le informazioni e i rischi che incombono su di esse, senza imporre metodologie che nella pratica sono troppo onerose e non utili. Sarà poi agli "esperti" sviluppare un metodo che garantisca di aver individuato (al giusto livello di granularità) tutti i rischi. Agli auditor, esattamente come oggi, viene solo richiesto di verificare la coerenza (o la "validità", come si è deciso) del metodo di risk assessment e dei suoi risultati.    Il Giappone si è dichiarato contrario a questa impostazione.    Personalmente, mi pare una buona soluzione, ma devo ancora rifletterci: probabilmente qualche indicazione in più potrebbe essere utile (per la cronaca: Fabio Guasconi, Presidente dell'SC 27 di Uninfo è solidale con il Giappone).

Misurazione dei controlli    Con mia grande gioia (anche perché la proposta era mia), è stato eliminato il concetto di misurazione dei controlli. Rimane il fatto che l'organizzazione deve valutare l'efficacia del proprio ISMS grazie ad attività di monitoraggio o misurazione, secondo quanto necessario. 
    Questo includerà sicuramente la misurazione dell'efficacia di alcuni controlli, ma se qualcuno vorrà misurare cose inutili, almeno non avrà la scusa dello standard.

Riesame della Direzione    Su proposta dell'Italia, è passato senza quasi discussione il fatto che la Direzione, nel riesame periodico, deve anche riesaminare i risultati del risk assessment e lo stato del piano di trattamento del rischio. Interessante che ciò sia successo dopo che si era detto che la stessa Direzione non poteva svolgere troppi compiti.

Statement of Applicability e Annex A    E' stato confermato il requisito che richiede l'elaborazione di un SOA collegato all'Annex A della norma. Come Italia siamo lievemente a favore della sua eliminazione. Personalmente, credo che sia un bene che rimanga il SOA collegato all'Annex A, perché impone al mercato l'adozione di una terminologia e di uno schema unico (insomma, impone l'adozione di uno standard!).

Risk assessment: nella pianificazione o nelle operation?
    Ho lasciato per ultimo l'argomento più difficile.  
    Si è molto dibattuto su: i requisiti sul risk assessment vanno nel capitolo "planning" o nel capitolo "operation"? 
    L'Italia (con la maggioranza) ha votato per la prima ipotesi perché il risk assessment fornisce i risultati necessari alla scelta dei controlli di sicurezza e alla loro pianificazione.
    Altri dicono che il capitolo planning riguarda il solo sistema di gestione che ha altri rischi rispetto alla sicurezza delle informazioni.
    Personalmente, vedo come molto pericolosa questa seconda impostazione perché prevede che il "sistema di gestione" sia una cosa e la sicurezza delle informazioni sia un'altra cosa, buttando all'aria tanta letteratura e pratica sul fatto che la sicurezza delle informazioni debba essere vista come un insieme integrato di tecnologia e processi. La norma, comunque, riguarda il "sistema di gestione per la sicurezza delle informazioni" (e non un generico "sistema di gestione") di cui i controlli di sicurezza sono parte integrante. Pertanto, pianificare il sistema di gestione per la sicurezza delle informazioni implica necessariamente la scelta dei controlli di sicurezza, da fare con il risk assessment.    Altra mia obiezione è: quale rischio al "sistema di gestione" vedete che non è applicabile al "sistema di gestione per la sicurezza delle informazioni"? La risposta è sempre stata una sola: "indisponibilità della Direzione" e mi pare un po' pochino.    Il problema è che il common text presenta alcuni requisiti che creano confusione: nella pianificazione si richiede di considerare rischi e "issues" (in italiano, "questioni"), e qui c'è chi distingue tra rischi strategici e operativi (ma questo ragionamento non toglie nulla alla necessità di avere il risk assessment dell'ISMS nel planning); nelle operation si fa comunque riferimento alla pianificazione delle attività, ma qui si dovrebbe fare riferimento ai piani di dettaglio o ai piani di produzione (per esempio, il piano di verifica dei backup, secondo le politiche stabilite in fase di scelta del controllo di sicurezza).

Mi piacerebbe ricevere pareri in merito (anche a favore!), sul blog o via email.