Iso 27002-2022 Ita

N O R M A I T A L I A N A C E I
Norma Italiana Data Pubblicazione
CEI UNI EN ISO/IEC 27002 2023-04

La seguente Norma è identica a: EN ISO/IEC 27002:2022-11.
Titolo
Sicurezza delle informazioni, cybersecurity e protezione della privacy -

Controlli di sicurezza delle informazioni
Title
Information security, cybersecurity and privacy protection - Information

security controls
Sommario
La Norma fornisce un insieme di controlli generici di riferimento per la sicurezza delle informazioni,
comprensivi di linee guida per la loro implementazione. Questo documento è elaborato per essere
utilizzato dalle organizzazioni:
a) nell’ambito di un sistema di gestione per la sicurezza delle informazioni (SGSI) basato sulla
UNI CEI EN ISO/IEC 27001;
b) per l’implementazione di controlli per la sicurezza delle informazioni basati sulle best practice
riconosciute a livello internazionale;
c) per lo sviluppo di linee guida per la gestione della sicurezza delle informazioni specifiche per
l’organizzazione.
La Norma in oggetto sostituisce completamente la Norma CEI UNI EN ISO/IEC 27002:2017-06, che
rimane applicabile fino al 31-05-2023.
La presente Norma riporta la traduzione completa della EN ISO/IEC 27002; la versione inglese è riportata
nel fascicolo 19238E di febbraio 2023.
© CEI COMITATO ELETTROTECNICO ITALIANO - Milano 2023. Riproduzione vietata

Tutti i diritti sono riservati. Nessuna parte del presente Documento può essere riprodotta, messa in
rete o diffusa con un mezzo qualsiasi senza il consenso scritto del CEI. Concessione per utente
singolo. Le Norme CEI sono revisionate, quando necessario, con la pubblicazione sia di nuove edizioni
sia di varianti. È importante pertanto che gli utenti delle stesse si accertino di essere in possesso
dell’ultima edizione o variante.
DATI IDENTIFICATIVI CEI
Norma italiana CEI UNI EN ISO/IEC 27002

Classificazione CEI UNI 700-36
Edizione
COLLEGAMENTI/RELAZIONI TRA DOCUMENTI
Nazionali
Europei (IDT) EN ISO/IEC 27002:2022-11;

Internazionali (IDT) ISO/IEC 27002:2022-02;
Legislativi
Legenda (IDT) - La Norma in oggetto è identica alle Norme indicate dopo il riferimento (IDT)
INFORMAZIONI EDITORIALI
Pubblicazione Norma Tecnica

Stato Edizione In vigore
Data validità 16-02-2023
Ambito validità Internazionale
Fascicolo 19388
Ed. Prec. Fasc. 15529E:2017-06 che rimane applicabile fino al 31-05-2023
Comitato Tecnico CT 700-Elettrotecnica - Argomenti correlati
Approvata da Presidente del CEI In data 13-02-2023

Approvata da Presidente dell’UNI In data 16-02-2023
CENELEC In data 30-10-2022
Sottoposta a Chiusura in data
ICS 35.030;
2
INDICE
PREMESSA CEN 1
PREMESSA ISO 2
INTRODUZIONE 3
0.1 Scenario e contesto ................................................................................................................................. 3
0.2 Requisiti di sicurezza delle informazioni ...................................................................................... 3
0.3 Controlli .......................................................................................................................................................... 4
0.4 Determinazione dei controlli................................................................................................................ 4
0.5 Sviluppo di linee guida specifiche per l'organizzazione ....................................................... 4
0.6 Considerazioni sul ciclo di vita ........................................................................................................... 5
0.7 Norme correlate ......................................................................................................................................... 5
1 SCOPO E CAMPO DI APPLICAZIONE 5
2 RIFERIMENTI NORMATIVI 5
3 TERMINI, DEFINIZIONI E ABBREVIAZIONI 6

3.1 Termini e definizioni................................................................................................................................. 6
3.2 Abbreviazioni ............................................................................................................................................... 9
4 STRUTTURA DEL DOCUMENTO 10

4.1 Punti .............................................................................................................................................................. 10
4.2 Temi e attributi ......................................................................................................................................... 11
4.3 Schema dei controlli ............................................................................................................................. 12
5 CONTROLLI ORGANIZZATIVI 12
5.1 Politiche per la sicurezza delle informazioni ........................................................................... 12
prospetto 1 Differenze tra la politica per la sicurezza delle informazioni e le politiche specifiche......... 14
5.2 Ruoli e responsabilità per la sicurezza delle informazioni ............................................... 14
5.3 Separazione dei compiti ..................................................................................................................... 15
5.4 Responsabilità della direzione ........................................................................................................ 16
5.5 Contatti con le autorità ........................................................................................................................ 17
5.6 Contatti con gruppi specialistici ...................................................................................................... 17
5.7 Threat intelligence ................................................................................................................................. 18
5.8 Sicurezza delle informazioni nella gestione dei progetti ................................................... 19
5.9 Inventario delle informazioni e degli altri asset relativi ...................................................... 21
5.10 Uso accettabile delle informazioni e degli altri asset relativi .......................................... 23
5.11 Restituzione degli asset ..................................................................................................................... 24
5.12 Classificazione delle informazioni ................................................................................................. 24
5.13 Etichettatura delle informazioni ...................................................................................................... 26
5.14 Trasferimento delle informazioni ................................................................................................... 27
5.15 Controllo degli accessi ........................................................................................................................ 29
5.16 Gestione delle identità......................................................................................................................... 31
5.17 Informazioni di autenticazione ........................................................................................................ 32
5.18 Diritti d’accesso ....................................................................................................................................... 34
5.19 Sicurezza delle informazioni nelle relazioni con i fornitori ............................................... 36
5.20 Sicurezza delle informazioni negli accordi con i fornitori.................................................. 38
5.21 Gestione della sicurezza delle informazioni nella filiera di fornitura per l’ICT ....... 40
5.22 Monitoraggio, riesame e gestione dei cambiamenti dei servizi dei fornitori........... 41
5.23 Sicurezza delle informazioni per l'utilizzo di servizi cloud................................................ 43
UNI CEI EN ISO/IEC 27002:2023 © UNI Pagina III

5.24 Pianificazione e preparazione per la gestione degli incidenti relativi alla
sicurezza delle informazioni............................................................................................................. 45
5.25 Valutazione e decisione sugli eventi relativi alla sicurezza delle informazioni ..... 47
5.26 Risposta agli incidenti relativi alla sicurezza delle informazioni ................................... 47
5.27 Apprendimento dagli incidenti relativi alla sicurezza delle informazioni .................. 48
5.28 Raccolta di prove ................................................................................................................................... 49
5.29 Sicurezza delle informazioni durante le interruzioni ........................................................... 50
5.30 Prontezza dell’ICT per la continuità operativa ....................................................................... 50
5.31 Identificazione dei requisiti legali, statutari, regolamentari e contrattuali ................ 52
5.32 Diritti di proprietà intellettuale ......................................................................................................... 53
5.33 Protezione delle registrazioni .......................................................................................................... 54
5.34 Privacy e protezione dei dati personali ...................................................................................... 56
5.35 Riesame indipendente della sicurezza delle informazioni .............................................. 57
5.36 Conformità alle politiche e alle norme per la sicurezza delle informazioni............. 58
5.37 Procedure operative documentate ............................................................................................... 58
6 CONTROLLI SUL PERSONALE 60

6.1 Screening ................................................................................................................................................... 60
6.2 Termini e condizioni d’impiego ....................................................................................................... 61
6.3 Consapevolezza, istruzione, formazione e addestramento sulla sicurezza
delle informazioni................................................................................................................................... 62
6.4 Processo disciplinare .......................................................................................................................... 64
6.5 Responsabilità dopo la cessazione o il cambio d’impiego .............................................. 64
6.6 Accordi di riservatezza o di non divulgazione ........................................................................ 65
6.7 Lavoro a distanza .................................................................................................................................. 66
6.8 Segnalazione degli eventi relativi alla sicurezza delle informazioni........................... 68
7 CONTROLLI FISICI 69
7.1 Perimetro di sicurezza fisica ............................................................................................................ 69
7.2 Controlli di accesso fisico .................................................................................................................. 70
7.3 Messa in sicurezza di uffici, locali e strutture ......................................................................... 71
7.4 Monitoraggio della sicurezza fisica .............................................................................................. 72
7.5 Protezione dalle minacce fisiche e ambientali ....................................................................... 73
7.6 Lavoro in aree sicure ........................................................................................................................... 74
7.7 Schermo e scrivania puliti ................................................................................................................. 75
7.8 Disposizione delle apparecchiature e loro protezione ....................................................... 76
7.9 Sicurezza degli asset all’esterno delle sedi............................................................................. 76
7.10 Supporti di memorizzazione ............................................................................................................ 78
7.11 Infrastrutture di supporto ................................................................................................................... 79
7.12 Sicurezza dei cablaggi ........................................................................................................................ 80
7.13 Manutenzione delle apparecchiature.......................................................................................... 81
7.14 Dismissione sicura o riutilizzo delle apparecchiature ........................................................ 82
8 CONTROLLI TECNOLOGICI 83
8.1 Endpoint degli utenti ............................................................................................................................ 83
8.2 Diritti di accesso privilegiato ............................................................................................................ 85
8.3 Limitazione degli accessi alle informazioni.............................................................................. 86
8.4 Accesso al codice sorgente ............................................................................................................. 88
8.5 Autenticazione sicura .......................................................................................................................... 89
8.6 Gestione della capacità ...................................................................................................................... 90
8.7 Protezione dal malware...................................................................................................................... 92
8.8 Gestione delle vulnerabilità tecniche .......................................................................................... 93
8.9 Gestione delle configurazioni .......................................................................................................... 96
UNI CEI EN ISO/IEC 27002:2023 © UNI Pagina IV

8.10 Cancellazione delle informazioni ................................................................................................... 98
8.11 Mascheramento dei dati ..................................................................................................................... 99
8.12 Prevenzione di leakage delle informazioni............................................................................ 101
8.13 Backup delle informazioni .............................................................................................................. 102
8.14 Ridondanza delle strutture di elaborazione delle informazioni................................... 104
8.15 Raccolta di log ...................................................................................................................................... 105
8.16 Attività di monitoraggio..................................................................................................................... 107
8.17 Sincronizzazione degli orologi ..................................................................................................... 109
8.18 Utilizzo di programmi di utilità privilegiati ............................................................................... 110
8.19 Installazione del software sui sistemi in esercizio ............................................................. 111
8.20 Sicurezza delle reti ............................................................................................................................. 112
8.21 Sicurezza dei servizi di rete .......................................................................................................... 113
8.22 Segregazione delle reti .................................................................................................................... 114
8.23 Web filtering ........................................................................................................................................... 115
8.24 Uso della crittografia ......................................................................................................................... 116
8.25 Ciclo di vita dello sviluppo sicuro................................................................................................ 118
8.26 Requisiti di sicurezza delle applicazioni ................................................................................. 119
8.27 Sicurezza dell’architettura dei sistemi e dei principi di ingegnerizzazione .......... 121
8.28 Sviluppo sicuro ..................................................................................................................................... 123
8.29 Test di sicurezza in fase di sviluppo e di accettazione ................................................... 125
8.30 Sviluppo affidato all’esterno .......................................................................................................... 126
8.31 Separazione degli ambienti di sviluppo, test e produzione .......................................... 127
8.32 Gestione dei cambiamenti ............................................................................................................. 128
8.33 Dati di test ............................................................................................................................................... 129
8.34 Protezione dei sistemi informativi durante i test di audit ............................................... 130
APPENDICE A UTILIZZO DEGLI ATTRIBUTI 132

(informativa)
prospetto A.1 Matrice dei controlli e valori degli attributi ...................................................................................... 133
prospetto A.2 Vista dei controlli #correttivi ................................................................................................................ 138
APPENDICE B CORRISPONDENZA CON LA ISO/IEC 27002:2013 140

(informativa)
prospetto B.1 Corrispondenza tra i controlli di questo documento e i controlli della ISO/IEC 27002:2013 ....... 140
BIBLIOGRAFIA 147
UNI CEI EN ISO/IEC 27002:2023 © UNI Pagina V

UNI CEI EN ISO/IEC 27002:2023 © UNI Pagina VI
PREMESSA CEN
Il testo della ISO/IEC 27002:2022 è stato elaborato dal Comitato Tecnico ISO/IEC JTC 1
“Information technology” dell’Organizzazione Internazionale di Normazione (ISO) ed è
stato ripreso come EN ISO/IEC 27002:2022 dal Comitato Tecnico CEN-CENELEC /JTC
13 “Cybersecurity and Data Protection”, la cui segreteria è affidata al DIN.
Alla presente norma europea deve essere attribuito lo status di norma nazionale, o
mediante pubblicazione di un testo identico o mediante notifica di adozione, al più tardi
entro maggio 2023, e le norme nazionali in contrasto devono essere ritirate al più tardi
entro maggio 2023.
Si richiama l’attenzione alla possibilità che alcuni degli elementi del presente documento
possano essere oggetto di brevetti. Il CEN-CENELEC non deve essere ritenuto
responsabile di avere citato tali brevetti.
Il presente documento sostituisce la EN ISO/IEC 27002:2017.
Qualsiasi commento o richiesta sul presente documento dovrebbe essere rivolta al
proprio ente di normazione nazionale. Una lista completa di tali enti è disponibile nel sito
web del CEN e CENELEC.
In conformità alle Regole Comuni CEN/CENELEC, gli enti nazionali di normazione dei
seguenti Paesi sono tenuti a recepire la presente norma europea: Austria, Belgio,
Bulgaria, Cipro, Croazia, Danimarca, Estonia, Finlandia, Francia, Germania, Grecia,
Irlanda, Islanda, Italia, Lettonia, Lituania, Lussemburgo, Malta, Norvegia, Paesi Bassi,
Polonia, Portogallo, Regno Unito, Repubblica Ceca, Repubblica di Nord della Macedonia,
Romania, Serbia, Slovacchia, Slovenia, Spagna, Svezia, Svizzera, Turchia e Ungheria.
NOTIFICA DI ADOZIONE
Il testo della ISO/IEC 27002:2022 è stato approvato dal CEN-CENELEC come EN
ISO/IEC 27002:2022 senza alcuna modifica.
UNI CEI EN ISO/IEC 27002:2023 © UNI Pagina 1

PREMESSA ISO
L'ISO (l'Organizzazione Internazionale di Normazione) e l'IEC (la Commissione
Elettrotecnica Internazionale) costituiscono il sistema specializzato per la
standardizzazione mondiale. Gli organismi nazionali che sono membri dell'ISO o dell'IEC
partecipano allo sviluppo delle norme internazionali attraverso comitati tecnici istituiti
dalla rispettiva organizzazione per occuparsi di particolari campi di attività tecnica. I
comitati tecnici ISO e IEC collaborano in settori di reciproco interesse. Ai lavori
partecipano anche altre organizzazioni internazionali, governative e non governative, in
collegamento con ISO e IEC.
Le procedure utilizzate per lo sviluppo di questo documento e quelle previste per il suo
ulteriore mantenimento sono descritte nelle Direttive ISO/IEC, Parte 1. In particolare,
vanno notati i diversi criteri di approvazione necessari per i diversi tipi di documento.
Questo documento è stato redatto in conformità con le regole editoriali delle Direttive
ISO/IEC, Parte 2 (vedere www.iso.org/directives o
www.iec.ch/members_experts/refdocs).
Si richiama l'attenzione sulla possibilità che alcuni elementi del presente documento
possano essere oggetto di diritti di brevetto. ISO e IEC non saranno ritenuti responsabili
dell'identificazione di uno o di tutti questi diritti di brevetto. I dettagli di eventuali diritti di
brevetto identificati durante lo sviluppo del documento saranno nell'Introduzione e/o
nell'elenco ISO delle dichiarazioni di brevetto ricevute (vedere www.iso.org/patents) o
nell'elenco IEC delle dichiarazioni di brevetto ricevute (vedere patents.iec.ch).
Qualsiasi nome commerciale utilizzato in questo documento è un'informazione fornita per
comodità degli utenti e non costituisce un'approvazione.
Per una spiegazione della natura volontaria delle norme, del significato dei termini e delle
espressioni specifici dell'ISO relativi alla valutazione della conformità, nonché per
informazioni sull'adesione dell'ISO ai principi relativi agli Ostacoli tecnici al commercio
(TBT) dell'Organizzazione mondiale del commercio (WTO), vedere
www.iso.org/iso/foreword.html. Nella IEC, vedere www.iec.ch/understanding-standards.
Questo documento è stato preparato dal Comitato Tecnico Congiunto ISO/IEC JTC 1,
Tecnologie Informatiche, Sottocomitato SC 27, Sicurezza delle informazioni,
cybersecurity e protezione della privacy.
Questa terza edizione annulla e sostituisce la seconda edizione (UNI CEI EN
ISO/IEC 27002:2017), che è stata tecnicamente aggiornata. Incorpora anche la Rettifica
Tecnica EC 1-2017 UNI CEI EN ISO/IEC 27002:2017.
I cambiamenti principali sono i seguenti:
- il titolo è stato cambiato;
- è stata cambiata la struttura del documento, presentando i controlli mediante una
semplice tassonomia e degli attributi associati;
- alcuni controlli sono stati fusi, altri eliminati e sono stati introdotti numerosi nuovi
controlli. La corrispondenza completa può essere trovata nell'Appendice B.
La presente versione corretta della ISO/IEC 27002:2022 include le seguenti correzioni:
- i collegamenti ipertestuali non funzionanti del documento sono stati ripristinati;
- nel prospetto introduttivo del punto 5.22 e nel prospetto A.1 (riga 5.22),
"#information_security_assurance" è stato spostato dalla colonna “Domini di
sicurezza” alla colonna “Capacità operative”.
Eventuali commenti o domande su questo documento dovrebbero essere indirizzati
all'organismo di normazione nazionale dell’utilizzatore. Un elenco completo di questi
organismi può essere trovato su www.iso.org/members.html e
www.iec.ch/national-committees.

INTRODUZIONE
0.1 Scenario e contesto

Questo documento è progettato per organizzazioni di ogni tipo e dimensione. Dovrebbe
essere utilizzato come riferimento per determinare e implementare i controlli per il
trattamento del rischio relativo alla sicurezza delle informazioni in un sistema di gestione
per la sicurezza delle informazioni (SGSI) basato sulla UNI CEI EN ISO/IEC 27001. Può
anche essere utilizzato come guida per le organizzazioni che determinano e
implementano i controlli per la sicurezza delle informazioni comunemente accettati.
Inoltre, si prevede che questo documento venga usato per sviluppare linee guida per la
gestione della sicurezza delle informazioni di settori e organizzazioni specifiche, tenendo
in considerazione i loro specifici ambienti di rischio relativo alla sicurezza delle
informazioni. Controlli specifici dell’organizzazione o dell'ambiente, diversi da quelli inclusi
nel presente documento, possono essere determinati attraverso la valutazione del rischio,
se necessario.
Organizzazioni di ogni tipo e dimensione (incluse quelle dei settori pubblico e privato,
commerciale e senza scopo di lucro) creano, raccolgono, elaborano, memorizzano,
trasmettono ed eliminano informazioni in molte forme, comprese quelle elettroniche,
fisiche e verbali (per esempio conversazioni e presentazioni).
Il valore dell'informazione va oltre le parole scritte, i numeri e le immagini: conoscenze,
concetti, idee e marchi sono esempi di forme di informazione immateriali. In un mondo
interconnesso, le informazioni e gli altri asset relativi meritano o richiedono protezione
contro varie fonti di rischio, naturali, accidentali o intenzionali.
La sicurezza delle informazioni si ottiene implementando un insieme adeguato di controlli,
tra cui politiche, regole, processi, procedure, strutture organizzative e funzioni software e
hardware. Per soddisfare i propri obiettivi di business e di sicurezza specifici,
l'organizzazione dovrebbe definire, implementare, monitorare, riesaminare e migliorare
questi controlli ove necessario. Un SGSI come quello specificato nella UNI CEI EN
ISO/IEC 27001 adotta una visione olistica e coordinata dei rischi relativi alla sicurezza
delle informazioni dell'organizzazione al fine di determinare e implementare un insieme
completo di controlli per la sicurezza delle informazioni nel quadro generale di un sistema
di gestione coerente.
Molti sistemi informativi, e la loro gestione e il loro esercizio, non sono stati progettati per
essere sicuri in termini di un SGSI come specificato nella UNI CEI EN ISO/IEC 27001 e
questo documento. Il livello di sicurezza ottenibile solo attraverso misure tecnologiche è
limitato e dovrebbe essere supportato da adeguate attività di gestione e da processi
organizzativi. Identificare quali controlli dovrebbero essere in atto richiede un'attenta
pianificazione e attenzione ai dettagli durante l'esecuzione del trattamento del rischio.
Un SGSI di successo richiede il supporto di tutto il personale dell'organizzazione. Può
anche richiedere la partecipazione di altre parti interessate, come azionisti o fornitori.
Possono essere necessari anche i consigli di esperti in materia.
Un sistema di gestione per la sicurezza delle informazioni adeguato, idoneo ed efficace
fornisce un’assicurazione alla direzione dell'organizzazione e alle altre parti interessate
che le loro informazioni e gli altri asset relativi sono mantenuti ragionevolmente sicuri e
protetti da minacce e danni, consentendo così all'organizzazione di raggiungere gli
obiettivi di business dichiarati.
0.2 Requisiti di sicurezza delle informazioni

È essenziale che un'organizzazione determini i propri requisiti di sicurezza delle
informazioni. Esistono tre fonti principali di requisiti di sicurezza delle informazioni:
a) la valutazione dei rischi dell'organizzazione, tenendo conto della strategia e degli
obiettivi di business complessivi dell'organizzazione. Ciò può essere facilitato o
supportato da una specifica valutazione del rischio relativo alla sicurezza delle
informazioni. Ciò dovrebbe portare alla determinazione dei controlli necessari per
assicurare che il rischio residuo per l'organizzazione soddisfi i criteri di accettazione
del rischio;

b) i requisiti legali, statutari, regolamentari e contrattuali che un'organizzazione e le sue
parti interessate (partner commerciali, fornitori di servizi, ecc.) dovrebbero rispettare
e il loro ambiente socio-culturale;
c) l'insieme di principi, obiettivi e requisiti di business relativi a tutte le fasi del ciclo di
vita delle informazioni che un'organizzazione ha sviluppato a supporto delle proprie
operazioni.
0.3 Controlli
Un controllo è definito come una misura che modifica o mantiene il rischio. Alcuni dei
controlli in questo documento sono controlli che modificano il rischio, mentre altri
mantengono il rischio. Una politica per la sicurezza delle informazioni, per esempio, può
solo mantenere il rischio, mentre il rispetto della politica per la sicurezza delle informazioni
può modificare il rischio. Inoltre, alcuni controlli descrivono la stessa misura generica in
diversi contesti di rischio. Questo documento fornisce una miscela generica di controlli
per la sicurezza delle informazioni organizzativi, relativi alle persone, fisici e tecnologici
derivati dalle best practice riconosciute a livello internazionale.
0.4 Determinazione dei controlli

La determinazione dei controlli dipende dalle decisioni dell'organizzazione a seguito di
una valutazione del rischio, con un ambito chiaramente definito. Le decisioni relative ai
rischi identificati dovrebbero essere basate sui criteri di accettazione del rischio, sulle
opzioni di trattamento del rischio e sull'approccio di gestione del rischio applicato
dall'organizzazione. La determinazione dei controlli dovrebbe anche prendere in
considerazione tutte le norme di legge e i regolamenti nazionali e internazionali pertinenti.
La determinazione del controllo dipende anche dal modo in cui i controlli interagiscono tra
loro per fornire una difesa in profondità.
L'organizzazione può progettare controlli come richiesto o identificarli da qualsiasi fonte.
Nello specificare tali controlli, le organizzazioni dovrebbero considerare le risorse e gli
investimenti necessari per implementare e gestire un controllo rispetto al valore di
business realizzato. Vedere ISO/IEC TR 27016 per gli orientamenti sulle decisioni
riguardanti l'investimento in un SGSI e le conseguenze economiche di tali decisioni nel
contesto di requisiti concorrenti per le risorse.
Ci dovrebbe essere un equilibrio tra le risorse impiegate per l'implementazione dei
controlli e il possibile impatto sul business risultante da incidenti relativi alla sicurezza in
assenza di tali controlli. I risultati di una valutazione del rischio dovrebbero aiutare a
guidare e determinare le azioni gestionali appropriate, le priorità per la gestione dei rischi
relativi alla sicurezza delle informazioni e per l'implementazione dei controlli ritenuti
necessari per proteggersi da tali rischi.
Alcuni dei controlli in questo documento possono essere considerati come principi guida
per la gestione della sicurezza delle informazioni e applicabili dalla maggior parte delle
organizzazioni. Ulteriori informazioni sulla determinazione dei controlli e di altre opzioni di
trattamento del rischio sono disponibili nella ISO/IEC 27005.
0.5 Sviluppo di linee guida specifiche per l'organizzazione

Questo documento può essere considerato un punto di partenza per lo sviluppo di linee
guida specifiche dell'organizzazione. Non tutti i controlli e le linee guida in questo
documento possono essere applicabili a tutte le organizzazioni. Ulteriori controlli e linee
guida non inclusi nel presente documento possono essere richiesti anche per far fronte
alle esigenze specifiche dell'organizzazione e ai rischi che sono stati identificati. Quando
vengono sviluppati documenti contenenti linee guida o controlli aggiuntivi, può essere
utile includere riferimenti incrociati ai punti di questo documento per riferimenti futuri.

0.6 Considerazioni sul ciclo di vita
Le informazioni hanno un ciclo di vita naturale, dalla creazione allo smaltimento. Il valore
delle informazioni e i rischi relativi ad esse possono variare durante questo ciclo di vita
(per esempio la divulgazione non autorizzata o il furto dei conti economici di
un'organizzazione non sono significativi dopo che sono stati pubblicati, ma l'integrità
rimane fondamentale) pertanto, la sicurezza delle informazioni rimane in una certa misura
importante in tutte le fasi.
I sistemi informativi e gli altri asset pertinenti per la sicurezza delle informazioni hanno
cicli di vita entro i quali sono concepiti, specificati, progettati, sviluppati, testati,
implementati, utilizzati, mantenuti ed eventualmente ritirati dal servizio e smaltiti. La
sicurezza delle informazioni dovrebbe essere considerata in ogni fase. Nuovi progetti di
sviluppo dei sistemi e cambiamenti ai sistemi esistenti offrono opportunità per migliorare
i controlli per la sicurezza tenendo conto dei rischi per l'organizzazione e delle lezioni
apprese dagli incidenti.
0.7 Norme correlate

Sebbene questo documento offra una guida su un'ampia gamma di controlli per la
sicurezza delle informazioni comunemente applicati in molte organizzazioni diverse, altri
documenti della famiglia ISO/IEC 27000 forniscono consigli o requisiti complementari su
altri aspetti del processo complessivo di gestione della sicurezza delle informazioni.
Fare riferimento a ISO/IEC 27000 per un'introduzione generale sia al SGSI sia alla
famiglia dei documenti. ISO/IEC 27000 fornisce un glossario che definisce la maggior
parte dei termini utilizzati nella famiglia di documenti ISO/IEC 27000 e descrive il campo
di applicazione e gli obiettivi di ciascun membro della famiglia.
Esistono standard settoriali che hanno controlli aggiuntivi che mirano ad affrontare aree
specifiche (per esempio ISO/IEC 27017 per i servizi cloud, ISO/IEC 27701 per la privacy,
ISO/IEC 27019 per l'energia, ISO/IEC 27011 per le organizzazioni di telecomunicazioni e
ISO 27799 per le aziende del settore sanitario). Tali standard sono inclusi nella
bibliografia e alcuni di essi sono citati nelle sezioni di guida e relative ad altre informazioni
nei capitoli 5-8.
1 SCOPO E CAMPO DI APPLICAZIONE

Questo documento fornisce un insieme di controlli generici di riferimento per la sicurezza
delle informazioni, comprensivi di linee guida per la loro implementazione. Questo
documento è elaborato per essere utilizzato dalle organizzazioni:
a) nell'ambito di un sistema di gestione per la sicurezza delle informazioni (SGSI)
basato su UNI CEI EN ISO/IEC 27001;
b) per l' implementazione di controlli per la sicurezza delle informazioni basati sulle best
practice riconosciute a livello internazionale;
c) per lo sviluppo di linee guida per la gestione della sicurezza delle informazioni
specifiche per l’organizzazione.
2 RIFERIMENTI NORMATIVI
In questo documento non ci sono riferimenti normativi.

3 TERMINI, DEFINIZIONI E ABBREVIAZIONI
3.1 Termini e definizioni

Ai fini del presente documento, si applicano i seguenti termini e definizioni.
ISO e IEC mantengono database terminologici da utilizzare nella normazione ai seguenti
indirizzi:
- Piattaforma di navigazione ISO Online: disponibile all'indirizzo https://www.iso.org/obp
- IEC Electropedia: disponibile su https://www.electropedia.org/
3.1.1 controllo degli accessi: Mezzi per assicurare che l'accesso fisico e logico agli asset (3.1.2)
sia autorizzato e limitato in base ai requisiti di business e relativi alla sicurezza delle
informazioni.
3.1.2 asset: Qualsiasi cosa cha ha valore per l’organizzazione.

Nota Nel contesto della sicurezza delle informazioni, si possono distinguere due tipi di asset:
- gli asset primari:
- informazioni;
- processi (3.1.27) di business e attività;
- gli asset di supporto (su cui si basano gli asset primari) di tutti i tipi, per esempio:
- hardware;
- software;
- rete;
- personale (3.1.20);
- sito fisico;
- struttura dell'organizzazione.
3.1.3 attacco: Tentativo non autorizzato, riuscito o fallito, di distruggere, modificare, disabilitare,
accedere a un asset (3.1.2) o qualsiasi tentativo di esporre, rubare o fare uso non
autorizzato di un asset (3.1.2).
3.1.4 autenticazione: Fornitura di garanzia che una dichiarata caratteristica di un'entità (3.1.11)
è corretta.
3.1.5 autenticità: Proprietà per cui un'entità (3.1.11) è ciò che afferma di essere.
3.1.6 catena di custodia: Possesso, movimento, trattamento e localizzazione dimostrabili di

specifico materiale da un istante temporale a un altro.
Nota Il materiale include, nel contesto della ISO/IEC 27002, informazioni e gli altri asset (3.1.2) relativi.
[FONTE: ISO/IEC 27050-1:2019, 3.1, modificato - Aggiunta la “Nota alla voce”.]
3.1.7 informazioni riservate: Informazioni che non si intende rendere disponibili o divulgate a
soggetti, entità (3.1.11) o processi (3.1.27).
3.1.8 controllo: Misura che mantiene e/o modifica il rischio.

Nota 1 I controlli includono, ma non sono limitati a, qualsiasi processo (3.1.27), politica (3.1.24), dispositivo, prassi o
altre condizioni e/o azioni che mantengono e/o modificano il rischio.
Nota 2 I controlli potrebbero non esercitare sempre l'effetto di modifica voluto o presunto.
[FONTE: ISO 31000:2018, 3.8]
3.1.9 interruzione: Incidente, atteso o inatteso, che causa una deviazione negativa, non
pianificata dall'erogazione prevista dei prodotti e servizi secondo gli obiettivi di
un'organizzazione.
[FONTE: ISO 22301:2019, 3.10]

3.1.10 endpoint: Dispositivo ICT di tipo hardware connesso in rete.
Nota Un endpoint può riferirsi a computer desktop, laptop, smartphone, tablet, thin client, stampanti o altro
hardware specializzato, inclusi contatori intelligenti e dispositivi dell’Internet of Things (IoT).
3.1.11 entità: Elemento pertinente all’operatività di un dominio che ha un'esistenza distinta

riconoscibile.
Nota Un'entità può avere una declinazione fisica o logica.
ESEMPIO
Una persona, un'organizzazione, un dispositivo, un gruppo di tali elementi, una persona
abbonata ad un servizio di telecomunicazioni, una scheda SIM, un passaporto, una
scheda di rete, un'applicazione software, un servizio o un sito web.
[FONTE: ISO/IEC 24760-1:2019, 3.1.1]
3.1.12 struttura di elaborazione delle informazioni: Qualsiasi sistema di elaborazione delle

informazioni, servizio o infrastruttura o collocazione fisica all’interno della quale esso è
ospitato.
[FONTE: ISO/IEC 27000:2018, 3.27, modificato - "strutture" è stato sostituito con
struttura.]
3.1.13 violazione relativa alla sicurezza delle informazioni: Compromissione della sicurezza delle
informazioni che porta alla distruzione, alla perdita, alla modifica, alla divulgazione o
all'accesso indesiderato a informazioni protette trasmesse, memorizzate o altrimenti
elaborate.
3.1.14 evento relativo alla sicurezza delle informazioni: Accadimento che indica una possibile
violazione relativa alla sicurezza delle informazioni (3.1.13) o il malfunzionamento di uno
o più controlli (3.1.8).
[FONTE: ISO/IEC 27035-1:2016, 3.3, modificato - "violazione della sicurezza delle
informazioni" è stata sostituita con "violazione relativa alla sicurezza delle informazioni".]
3.1.15 incidente relativo alla sicurezza delle informazioni: Uno o più eventi relativi alla sicurezza
delle informazioni (3.1.14) correlati e identificati che possono danneggiare gli asset (3.1.2)
di un'organizzazione o comprometterne l’operatività.
[FONTE: ISO/IEC 27035-1:2016, 3.4]
3.1.16 gestione degli incidenti relativi alla sicurezza delle informazioni: Esercizio di un approccio
coerente ed efficace alla gestione degli incidenti relativi alla sicurezza delle informazioni
(3.1.15).
[FONTE: ISO/IEC 27035-1:2016, 3.5]
3.1.17 sistema informativo: Insieme di applicazioni, servizi, asset (3.1.2) informatici o altri
componenti che trattano informazioni.
[FONTE: ISO/IEC 27000:2018, 3.35]
3.1.18 stakeholder: Persona o organizzazione che può influenzare, essere influenzata da, o
percepire se stessa come influenzata da una decisione o un’attività.
[FONTE: ISO/IEC 27000:2018, 3.37]
3.1.19 non ripudio: Capacità di provare il verificarsi di un dichiarato evento o azione e delle sue
entità (3.1.11) originanti.
3.1.20 personale: Persone che lavorano sotto la direzione dell'organizzazione.

Nota Il concetto di personale include i membri dell'organizzazione, come l'organo di governo, l'alta dirigenza, i
dipendenti, il personale temporaneo, i fornitori e i volontari.

3.1.21 dati personali; PII: Qualsiasi informazione che (a) possa essere utilizzata per identificare
la persona fisica alla quale tali informazioni si riferiscono, o (b) sia o possa essere
direttamente o indirettamente collegata a un interessato.
Nota La “persona fisica” nella definizione è l’interessato (3.1.22). Per determinare se un interessato è identificabile,
si dovrebbe tenere conto di tutti i mezzi che possono essere ragionevolmente utilizzati dal soggetto che
detiene i dati, o da qualsiasi altra parte, per stabilire un collegamento tra l'insieme di dati personali e la
persona fisica.
[FONTE: ISO/IEC 29100:2011 /Amd.1:2018, 2.9]
3.1.22 interessato: Persona fisica a cui i dati personali si riferiscono.

[FONTE: ISO/IEC 29100:2011, 2.11]
3.1.23 responsabile del trattamento dei dati personali: Stakeholder relativo alla privacy che tratta
dati personali (3.1.21) per conto e in conformità alle istruzioni di un titolare.
[FONTE: ISO/IEC 29100:2011, 2.12]
3.1.24 politica: Intenti e indirizzi di un’organizzazione espressi in modo formale dalla sua alta
direzione.
[FONTE: ISO/IEC 27000:2018, 3.53]
3.1.25 valutazione d'impatto sulla privacy; PIA: Processo (3.1.27) complessivo di identificazione,
analisi, valutazione, consultazione, comunicazione e pianificazione del trattamento dei
potenziali impatti sulla privacy in relazione al trattamento di dati personali (3.1.21),
inquadrato nel più ampio quadro di riferimento per la gestione del rischio di
un'organizzazione.
[FONTE: ISO/IEC 29134:2017, 3.7, modificato - Nota alla voce rimossa.]
3.1.26 procedura: Modalità designata per svolgere un'attività o un processo (3.1.27).

[FONTE: ISO 30000:2009, 3.12]
3.1.27 processo: Insieme di attività correlate o interagenti che utilizzano o trasformano degli input
per fornire un risultato.
[FONTE: ISO 9000:2015, 3.4.1, modificato: note alla voce rimosse]
3.1.28 registrazione: Informazioni create, ricevute e mantenute come prove e come asset (3.1.2)
da un'organizzazione o persona, nel rispetto di obblighi legali o in transazioni di business.
Nota Gli obblighi legali in questo contesto includono tutti i requisiti legali, statutari, regolamentari e contrattuali.
[FONTE: ISO 15489-1:2016, 3.14, modificato - Aggiunta la Nota.]
3.1.29 obiettivo relativo al punto di recupero; RPO: Momento nel tempo rispetto al quale i dati sono
da ripristinare dopo che si è verificata un'interruzione (3.1.9).
[FONTE: ISO/IEC 27031:2011, 3.12, modificato - "devono" sostituito da "sono da
ripristinare".]
3.1.30 obiettivo relativo al tempo di recupero; RTO: Periodo di tempo entro il quale i livelli minimi
di servizio e/o i prodotti e i sistemi, le applicazioni o le funzioni di supporto sono da
ripristinare dopo che si è verificata un'interruzione (3.1.9).
[FONTE: ISO/IEC 27031:2011, 3.13, modificato - "devono" sostituito da "sono da
ripristinare".]
3.1.31 affidabilità: Proprietà di coerenza del comportamento e dei risultati attesi.
3.1.32 regola: Principio accettato o istruzione che afferma le aspettative dell'organizzazione su

ciò che deve essere fatto, ciò che è consentito o non è consentito.
Nota Le regole possono essere formalmente espresse in politiche specifiche (3.1.35) e in altri tipi di documenti.

3.1.33 informazioni sensibili: Informazioni che è necessario proteggere da indisponibilità,
accesso non autorizzato, modifica o divulgazione al pubblico a causa di potenziali effetti
negativi su un individuo, su un’organizzazione, sulla sicurezza nazionale o sulla pubblica
sicurezza
3.1.34 minaccia: Potenziale causa di un incidente indesiderato, che può provocare un danno a
un sistema o a un’organizzazione.
[FONTE: ISO/IEC 27000: 2018, 3.74]
3.1.35 politica specifica [per argomento]: Intenti e indirizzi per un argomento o tema specifico,
come formalmente espresso dal livello manageriale appropriato.
Nota 1 Le politiche specifiche possono esprimere formalmente regole (3.1.32) o standard organizzativi.
Nota 2 Alcune organizzazioni utilizzano altri termini per le politiche specifiche.
Nota 3 Le politiche specifiche a cui si fa riferimento in questo documento sono collegate alla sicurezza delle
informazioni.
ESEMPIO
Politica specifica per il controllo degli accessi (3.1.1), politica specifica per schermo e
scrivania puliti.
3.1.36 utente: Stakeholder (3.1.18) con accesso ai sistemi informativi (3.1.17)

dell'organizzazione.
ESEMPIO
Personale (3.1.20), clienti, fornitori.
3.1.37 endpoint dell'utente: Endpoint (3.1.10) utilizzato dagli utenti per accedere ai servizi di
elaborazione delle informazioni.
Nota Un endpoint dell'utente può fare riferimento a un computer desktop, laptop, smartphone, tablet, thin client, ecc.
3.1.38 vulnerabilità: Punto di debolezza di un asset (3.1.2) o di un controllo (3.1.8) che può
essere sfruttato da una o più minacce (3.1.34).
[FONTE: ISO/IEC 27000: 2018, 3.77]
3.2 Abbreviazioni
ABAC controllo degli accessi basato sugli attributi
ACL lista per il controllo degli accessi
BIA analisi di impatto operativo
BYOD uso di dispositivi personali
CAPTCHAtest di Turing automatizzato e pubblico per discernere computer e umani
CPU unità centrale di elaborazione
DAC controllo degli accessi discrezionale
DNS domain name system
GPS sistema di posizionamento globale
IAM gestione dell'identità e degli accessi
ICT tecnologie dell'informazione e della comunicazione
ID identificatore
IDE ambiente di sviluppo integrato
IDS intrusion detection system
IoT Internet delle cose
IP internet protocol
IPS sistema di prevenzione delle intrusioni
IT tecnologie dell'informazione

SGSI sistema di gestione per la sicurezza delle informazioni
MAC controllo degli accessi obbligatorio
NTP network time protocol
PIA privacy impact assessment
PII dati personali
PIN numero di identificazione personale
PKI infrastruttura a chiave pubblica
PTP precision time protocol
RBAC controllo degli accessi basato sui ruoli
RPO obiettivo relativo al punto di ripristino
RTO obiettivo relativo al tempo di recupero
SAST test statici della sicurezza delle applicazioni
SD secure digital
SDN reti definite tramite software
SD-WANreti geografiche definite tramite software
SIEM gestore di informazioni di sicurezza e di eventi
SMS servizio di messaggi brevi
SQL linguaggio di interrogazione strutturato
SSO single sign on
SWID identificativo del software
UEBA analisi del comportamento di utenti ed entità
UPS gruppo di continuità
URL localizzatore uniforme di risorse
USB universal serial bus
VM macchina virtuale
VPN rete privata virtuale
WiFi wireless fidelity
4 STRUTTURA DEL DOCUMENTO
4.1 Punti
Questo documento è strutturato come segue:
a) Controlli organizzativi (Punto 5)
b) Controlli sulle persone (Punto 6)
c) Controlli fisici (Punto 7)
d) Controlli tecnologici (Punto 8)
Sono presenti 2 appendici informative:
- Appendice A - Utilizzo degli attributi
- Appendice B - Corrispondenza con ISO/IEC 27002:2013
L'Appendice A spiega come un'organizzazione può utilizzare gli attributi (vedere 4.2) per
creare le proprie viste basate sugli attributi di controllo definiti in questo documento o di
propria creazione.
L'Appendice B mostra la corrispondenza tra i controlli in questa edizione di
ISO/IEC 27002 e la precedente edizione 2013.

4.2 Temi e attributi
La categorizzazione dei controlli fornita nei punti da 5 a 8 è indicata come temi.
I controlli sono classificati come:
a) persone, se riguardano singole persone;
b) fisici, se riguardano oggetti fisici;
c) tecnologici, se riguardano la tecnologia;
d) altrimenti sono classificati come organizzativi.
L'organizzazione può utilizzare attributi per creare viste diverse corrispondenti a diverse
categorizzazioni dei controlli visti da una differente prospettiva rispetto ai temi. Gli attributi
possono essere utilizzati per filtrare, ordinare o presentare i controlli in visualizzazioni
diverse per destinatari diversi. L'Appendice A spiega come raggiungere questo obiettivo e
fornisce un esempio di vista.
A titolo esemplificativo, a ciascun controllo in questo documento sono stati associati
cinque attributi con corrispondenti valori di attributo (preceduti da "#" per renderli
ricercabili) come segue:
a) Tipo di controllo
Il tipo di controllo è un attributo che consente di visualizzare i controlli dal punto di
vista di quando e come il controllo modifica il rischio in relazione al verificarsi di un
incidente relativo alla sicurezza delle informazioni. I valori degli attributi sono:
Preventive (il controllo è inteso a prevenire il verificarsi di un incidente relativo alla
sicurezza delle informazioni), Detective (il controllo agisce quando si verifica un
incidente relativo alla sicurezza delle informazioni) e Corrective (il controllo agisce
dopo che si è verificato un incidente relativo alla sicurezza delle informazioni).
b) Proprietà di sicurezza delle informazioni
Le proprietà di sicurezza delle informazioni sono un attributo che consente di
visualizzare i controlli dal punto di vista di quale caratteristica delle informazioni il
controllo contribuirà a preservare. I valori degli attributi sono: Confidentiality, Integrity
e Availability.
c) Concetti di cybersecurity
I concetti di cybersecurity sono un attributo che consente di visualizzare i controlli dal
punto di vista dell'associazione dei controlli ai concetti di cybersecurity definiti nel
quadro di riferimento per la cybersecurity descritto nella ISO/IEC TS 27110. I valori
degli attributi sono: Identify, Protect, Detect, Respond e Recover.
d) Capacità operative
Le capacità operative sono un attributo per visualizzare i controlli dal punto di vista
pratico sulle capacità relative alla sicurezza delle informazioni. I valori degli attributi
sono: Governance, Asset_management, Information_protection,
Human_resource_security, Physical_security, System_and_network_security,
Application_Security, Secure_configuration, Identity_and_access_management,
Threat_and_vulnerability_management, Continuity, Supplier_relationships_security,
Legal_and_compliance, Information_security_event_management e
Information_security_assurance
e) Domini di sicurezza
I domini di sicurezza sono un attributo che consente di visualizzare i controlli dal
punto di vista dei 4 domini della sicurezza delle informazioni:
Governance_and_Ecosystem include Information System Security Governance &
Risk Management e Ecosystem cybersecurity management (con stakeholder interni
ed esterni), Protection include IT Security Architecture, IT Security Administration,
Identity and access management, IT Security Maintenance e Physical and
environmental security, Defence include Detection e Computer Security Incident
Management e Resilience include Continuity of operations e Crisis management. I
valori degli attributi sono: Governance_and_Ecosystem, Protection, Defence e
Resilience.

Gli attributi forniti in questo documento sono selezionati perché sono considerati
sufficientemente generici per essere utilizzati da diversi tipi di organizzazioni e i loro valori
di attributo non dipendono dall'organizzazione. Le organizzazioni possono scegliere di
ignorare uno o più attributi forniti in questo documento. Possono anche essere creati
attributi propri (con i valori di attributo corrispondenti) per creare le proprie viste
organizzative. L’Appendice A.2 include esempi di tali attributi.
4.3 Schema dei controlli

La struttura di ogni controllo contiene quanto segue:
- Titolo del controllo: nome abbreviato del controllo;
- Tabella degli attributi: una tabella mostra i valori di ciascun attributo per il controllo
dato;
- Controllo: cos'è il controllo;
- Finalità: perché il controllo dovrebbe essere implementato;
- Guida: come implementare il controllo;
- Altre informazioni: testo esplicativo o riferimenti ad altri documenti correlati.
I sottotitoli vengono utilizzati nel testo della guida per alcuni controlli per facilitare la
leggibilità quando la guida è lunga e affronta più argomenti. Tali titoli non sono
necessariamente utilizzati in tutti i testi di orientamento. I sottotitoli sono sottolineati.
5 CONTROLLI ORGANIZZATIVI
5.1 Politiche per la sicurezza delle informazioni
Tipo di controllo Proprietà di sicurezza Concetti di Capacità operative Domini di sicurezza

delle informazioni cybersecurity
#Preventive #Confidentiality #Identify #Governance #Governance_and_Ecosystem
#Integrity #Resilience
#Availability
Controllo
La politica per la sicurezza delle informazioni e le politiche specifiche dovrebbero essere
definite, approvate dalla direzione, pubblicate, comunicate e accettate dal personale
pertinente e dalle parti interessate pertinenti e riesaminate a intervalli pianificati e quando
si verificano cambiamenti significativi.
Finalità
Assicurare la continua idoneità, adeguatezza, efficacia degli indirizzi della direzione e il
supporto per la sicurezza delle informazioni in accordo con i requisiti di business, cogenti,
regolamentari e contrattuali.
Guida
Al livello più alto, le organizzazioni dovrebbero definire una "politica per la sicurezza delle
informazioni" che è approvata dall’alta direzione e che stabilisce l'approccio
dell'organizzazione alla gestione della sicurezza delle informazioni.
La politica per la sicurezza delle informazioni dovrebbe prendere in considerazione i
requisiti derivati da:
a) strategia e requisiti di business;
b) regolamenti, norme di legge e contratti;
c) i rischi e le minacce relative alla sicurezza delle informazioni attuali e previste.
La politica per la sicurezza delle informazioni dovrebbe contenere affermazioni
riguardanti:
a) la definizione di sicurezza delle informazioni;

b) gli obiettivi di sicurezza delle informazioni o il quadro di riferimento per impostare gli
obiettivi per la sicurezza delle informazioni;
c) i principi per guidare tutte le attività relative alla sicurezza delle informazioni;
d) l’impegno a soddisfare i requisiti applicabili relativi alla sicurezza delle informazioni;
e) l’impegno per il miglioramento continuo del sistema di gestione per la sicurezza delle
informazioni;
f) l’assegnazione a ruoli definiti delle responsabilità per la gestione della sicurezza
delle informazioni;
g) le procedure per la gestione di esenzioni ed eccezioni.
L’alta direzione dovrebbe approvare tutti i cambiamenti alla politica per la sicurezza delle
informazioni.
A un livello inferiore, la politica per la sicurezza delle informazioni dovrebbe essere
supportata da politiche specifiche, come necessario per imporre ulteriormente l'
implementazione dei controlli di sicurezza delle informazioni. Le politiche specifiche, in
genere, sono strutturate per affrontare le esigenze di determinati gruppi all'interno di
un'organizzazione o per coprire determinate aree di sicurezza. Le politiche specifiche
dovrebbero essere allineate e complementari alla politica per la sicurezza delle
informazioni dell'organizzazione.
Esempi degli argomenti trattati dalle politiche specifiche includono:
a) controllo degli accessi;
b) sicurezza fisica e ambientale;
c) gestione degli asset;
d) trasferimento di informazioni;
e) configurazione e gestione sicure degli endpoint;
f) sicurezza della rete;
g) gestione degli incidenti relativi alla sicurezza delle informazioni;
h) backup;
i) crittografia e gestione delle chiavi;
j) classificazione e trattamento delle informazioni;
k) gestione delle vulnerabilità tecniche;
l) sviluppo sicuro.
La responsabilità per lo sviluppo, il riesame e l'approvazione delle politiche specifiche
dovrebbe essere assegnata al personale pertinente in base al livello appropriato di
autorità e competenza tecnica. Il riesame dovrebbe includere la valutazione delle
opportunità di miglioramento della politica per la sicurezza delle informazioni
dell'organizzazione e delle politiche specifiche e la gestione della sicurezza delle
informazioni in risposta ai cambiamenti a:
a) la strategia dell'organizzazione;
b) l'ambiente tecnico dell'organizzazione;
c) regolamenti, statuti, norme di legge e contratti;
d) rischi relativi alla sicurezza delle informazioni;
e) le minacce relative alla sicurezza delle informazioni attuali e previste;
f) lezioni apprese da eventi e incidenti relativi alla sicurezza delle informazioni.
Il riesame della politica per la sicurezza delle informazioni e delle politiche specifiche
dovrebbe tenere conto dei risultati dei riesami della direzione e degli audit. I riesami e gli
aggiornamenti di altre politiche correlate dovrebbero essere considerati per mantenere la
coerenza quando una politica viene cambiata.

La politica per la sicurezza delle informazioni e le politiche specifiche dovrebbero essere
comunicate al personale pertinente e alle parti interessate in una forma che sia
pertinente, accessibile e comprensibile per i lettori previsti. Ai destinatari delle politiche
dovrebbe essere richiesto di riconoscere di aver compreso e accettare di conformarsi alle
politiche ove applicabile. L'organizzazione può determinare il formato e il nome di questi
documenti di politiche che soddisfano le esigenze dell'organizzazione. In alcune
organizzazioni, la politica per la sicurezza delle informazioni e le politiche specifiche
possono trovarsi in un unico documento. L'organizzazione può denominare queste
politiche specifiche come norme tecniche, direttive, politiche o altro.
Se la politica per la sicurezza delle informazioni o qualsiasi politica specifica è distribuita
all'esterno dell'organizzazione, si dovrebbe prestare attenzione a non divulgare
informazioni riservate.
La tabella 1 illustra le differenze tra la politica per la sicurezza delle informazioni e le
politiche specifiche.
prospetto 1 Differenze tra la politica per la sicurezza delle informazioni e le politiche specifiche
Politica per la sicurezza delle informazioni Politica specifica

Livello di dettaglio Generale/Alto livello Specifica/dettagliata
Formalmente approvata e Approvata dall’alta direzione Approvata dal livello manageriale
documentata appropriato
Altre informazioni
Le politiche specifiche possono variare tra le organizzazioni.
5.2 Ruoli e responsabilità per la sicurezza delle informazioni
Tipo di controllo Proprietà di sicurezza Concetti di Capacità Domini di sicurezza

delle informazioni cybersecurity operative
#Integrity #Availability #Protection #Resilience
Controllo
I ruoli e le responsabilità per la sicurezza delle informazioni dovrebbero essere definiti e
assegnati in base alle esigenze dell'organizzazione.
Finalità
Stabilire una struttura per l’implementazione, l’esercizio e la gestione della sicurezza delle
informazioni all'interno dell'organizzazione che sia definita, approvata e compresa.
Guida
L'assegnazione dei ruoli e delle responsabilità per la sicurezza delle informazioni
dovrebbe essere effettuata in accordo con la politica per la sicurezza delle informazioni e
le politiche specifiche (vedere 5.1). L'organizzazione dovrebbe definire e gestire le
responsabilità per:
a) la protezione delle informazioni e degli altri asset relativi;
b) svolgere specifici processi di sicurezza delle informazioni;
c) le attività di gestione del rischio relativo alla sicurezza delle informazioni e in
particolare l’accettazione dei rischi residui (per esempio ai responsabili dei rischi);
d) tutto il personale che utilizza le informazioni di un'organizzazione e gli asset relativi.
Tali responsabilità dovrebbero essere integrate, ove necessario, con linee guida più
dettagliate per specifici siti e strutture di elaborazione delle informazioni. Gli individui a cui
sono state assegnate responsabilità per la sicurezza delle informazioni potrebbero
assegnare compiti per la sicurezza ad altri. Tuttavia, tali individui rimangono responsabili
e dovrebbero verificare che tutti i compiti assegnati siano stati eseguiti correttamente.

Dovrebbe essere definita, documentata e comunicata ogni area di sicurezza di cui sono
responsabili le persone. I livelli di autorizzazione dovrebbero essere definiti e
documentati. Le persone che assumono uno specifico ruolo per la sicurezza delle
informazioni dovrebbero avere le conoscenze e le abilità richieste dal ruolo e dovrebbero
ricevere supporto per tenersi aggiornate sugli sviluppi relativi al ruolo e che sono richiesti
per adempiere alle responsabilità del ruolo.
Altre informazioni
Molte organizzazioni nominano un responsabile della sicurezza delle informazioni che si
assume la responsabilità complessiva per lo sviluppo e l’implementazione della sicurezza
delle informazioni e che supporta l'identificazione dei rischi e dei controlli di mitigazione.
Tuttavia, la responsabilità per fornire risorse e implementare i controlli rimane spesso in
capo ai singoli manager. Una pratica comune è nominare un responsabile per ogni asset
che diventa quindi responsabile della sua protezione quotidiana.
A seconda delle dimensioni e delle risorse di un'organizzazione, la sicurezza delle
informazioni può essere coperta da ruoli o mansioni dedicate e svolte in aggiunta ai ruoli
esistenti.
5.3 Separazione dei compiti
Tipo di controllo Proprietà di Concetti di Capacità operative Domini di sicurezza

sicurezza delle cybersecurity
informazioni
#Preventive #Confidentiality #Protect #Governance #Governance_and_Ecosystem
#Integrity #Identity_and_access
#Availability management
Controllo
I compiti e le aree di responsabilità in conflitto dovrebbero essere separati.
Finalità
Ridurre il rischio di frode, errore e aggiramento dei controlli di sicurezza delle
informazioni.
Guida
La separazione dei compiti e delle aree di responsabilità mira a suddividere, tra individui
diversi, compiti in conflitto al fine di prevenire che un individuo svolga da solo compiti
potenzialmente in conflitto.
L'organizzazione dovrebbe determinare quali compiti e aree di responsabilità dovrebbero
essere separate. Di seguito sono riportati esempi di attività che possono richiedere la
separazione:
a) avviare, approvare ed eseguire un cambiamento;
b) richiedere, approvare e implementare i diritti di accesso;
c) progettare, implementare e riesaminare il codice;
d) sviluppare software e amministrare i sistemi di produzione;
e) utilizzare e amministrare le applicazioni;
f) utilizzare gli applicativi e amministrare i database;
g) progettare, verificare e assicurare i controlli di sicurezza delle informazioni.
Dovrebbe essere considerata la possibilità di collusione nella progettazione dei controlli di
separazione. Le piccole organizzazioni possono trovare la separazione dei compiti difficile
da soddisfare, ma il principio dovrebbe essere applicato per quanto possibile e praticabile.
Quando è difficile separare, dovrebbero essere presi in considerazione altri controlli,
come il monitoraggio delle attività, gli audit trail e la supervisione di un responsabile.

Si dovrebbe prestare attenzione quando si utilizzano sistemi di controllo degli accessi
basati sui ruoli, per assicurare che alle persone non vengano assegnati ruoli in conflitto.
Quando c'è un elevato numero di ruoli, le organizzazioni dovrebbero prendere in
considerazione l'utilizzo di strumenti automatizzati per identificare i conflitti e facilitarne la
loro rimozione. I ruoli dovrebbero essere definiti e predisposti con attenzione per ridurre al
minimo i problemi di accesso se un ruolo viene rimosso o riassegnato.
Altre informazioni
Nessun'altra informazione.
5.4 Responsabilità della direzione

#Integrity
#Availability
Controllo
La direzione dovrebbe richiedere a tutto il personale di applicare la sicurezza delle
informazioni in conformità con la politica per la sicurezza delle informazioni, le politiche
specifiche e le procedure dell’organizzazione in vigore.
Finalità
Assicurare che la direzione comprenda il proprio ruolo nella sicurezza delle informazioni
e intraprenda azioni volte ad assicurare che tutto il personale sia consapevole e adempia
alle proprie responsabilità in materia di sicurezza delle informazioni.
Guida
La direzione dovrebbe dimostrare il supporto alla politica per la sicurezza delle
informazioni, alle politiche specifiche, alle procedure e ai controlli di sicurezza delle
informazioni.
Le responsabilità della direzione dovrebbero includere l’assicurazione che il personale:
a) sia adeguatamente informato sul proprio ruolo e sulle proprie responsabilità in
materia di sicurezza delle informazioni prima di ottenere l'accesso alle informazioni
dell'organizzazione e agli altri asset relativi;
b) sia dotato di linee guida che esprimono le aspettative di sicurezza delle informazioni
per il proprio ruolo all'interno dell'organizzazione;
c) sia incaricato di adempiere alla politica per la sicurezza delle informazioni e alle
politiche specifiche dell'organizzazione;
d) raggiunga un livello di consapevolezza della sicurezza delle informazioni pertinente al
proprio ruolo e alle proprie responsabilità all'interno dell'organizzazione (vedere 6.3);
e) si conformi ai termini e alle condizioni di impiego, contratto o accordo, inclusa la
politica per la sicurezza delle informazioni dell'organizzazione e ai metodi di lavoro
adeguati;
f) continui ad avere adeguate competenze e qualifiche in materia di sicurezza delle
informazioni attraverso la formazione professionale continua;
g) ove possibile, sia dotato di un canale riservato per la segnalazione di violazioni delle
politiche per la sicurezza delle informazioni, delle politiche specifiche o delle procedure per
la sicurezza delle informazioni (“whistleblowing”). Ciò può consentire segnalazioni
anonime o avere disposizioni per assicurare che la conoscenza dell'identità del segnalante
sia nota solo a coloro che dovrebbero occuparsi di tali segnalazioni;
h) sia dotato di risorse e tempi adeguati per l’implementazione dei processi e dei
controlli dell'organizzazione relativi alla sicurezza.
Altre informazioni

5.5 Contatti con le autorità

#Preventive #Confidentiality #Identify #Protect #Governance #Defence
#Corrective #Integrity #Respond #Recover #Resilience
#Availability
Controllo
L'organizzazione dovrebbe stabilire e mantenere i contatti con le autorità competenti.
Finalità
Assicurare che ci sia un adeguato flusso di informazioni rispetto alla sicurezza delle
informazioni tra l'organizzazione e le pertinenti autorità legali, regolamentari e di
supervisione.
Guida
L'organizzazione dovrebbe specificare quando e da chi dovrebbero essere contattate le
autorità (per esempio forze dell'ordine, organismi di regolamentazione, autorità di
supervisione) e come segnalare tempestivamente gli incidenti relativi alla sicurezza delle
informazioni identificati.
I contatti con le autorità dovrebbero essere utilizzati anche per facilitare la comprensione
delle aspettative attuali e future di tali autorità (per esempio le normative applicabili
relative alla sicurezza delle informazioni).
Altre informazioni
Le organizzazioni sotto attacco possono richiedere alle autorità di agire contro la fonte
dell'attacco.
Il mantenimento di tali contatti può essere un requisito per supportare la gestione degli
incidenti relativi alla sicurezza delle informazioni (vedere da 5.24 a 5.28) o i processi di
pianificazione della contingenza e di continuità operativa (vedere 5.29 e 5.30). I contatti
con gli organismi di regolamentazione sono utili anche per anticipare e prepararsi ai
cambiamenti imminenti nelle leggi o nei regolamenti pertinenti che interessano
l'organizzazione. I contatti con altre autorità includono servizi pubblici, servizi di
emergenza, fornitori di elettricità e salute e sicurezza [per esempio vigili del fuoco (in
relazione alla continuità operativa), fornitori di telecomunicazioni (in relazione
all'instradamento e alla disponibilità delle linee) e fornitori di acqua (in relazione agli
impianti di raffreddamento delle apparecchiature)].
5.6 Contatti con gruppi specialistici

#Preventive #Confidentiality #Protect #Governance #Defence
#Corrective #Integrity #Respond
#Availability #Recover
Controllo
L'organizzazione dovrebbe stabilire e mantenere contatti con gruppi specialistici o altri
forum di sicurezza specializzati e associazioni professionali.
Finalità
Assicurare che avvenga un flusso di informazioni adeguato rispetto alla sicurezza delle
informazioni.

Guida
L'appartenenza a gruppi o forum specialistici dovrebbe essere considerata un mezzo per:
a) migliorare la conoscenza delle best practice e mantenersi aggiornati con le
pertinenti informazioni relative alla sicurezza;
b) assicurare che la comprensione dell'ambiente di sicurezza delle informazioni sia
aggiornata;
c) ricevere avvertimenti precoci di avvisi, consigli e patch relativi ad attacchi e
vulnerabilità;
d) avere accesso a consulenze specialistiche in materia di sicurezza delle informazioni;
e) condividere e scambiare informazioni su nuove tecnologie, prodotti, servizi, minacce
o vulnerabilità;
f) fornire punti di collegamento adeguati quando si tratta di incidenti relativi alla
sicurezza delle informazioni (vedere da 5.24 a 5.28).
Altre informazioni
5.7 Threat intelligence
Tipo di controllo Proprietà di sicurezza delle Concetti di Capacità operative Domini di sicurezza
informazioni cybersecurity
#Preventive #Confidentiality #Identify #Threat_and_vulnerability_management #Defence
#Detective #Integrity #Detect #Resilience
#Corrective #Availability #Respond
Controllo
Le informazioni relative alle minacce alla sicurezza delle informazioni dovrebbero essere
raccolte e analizzate per produrre threat intelligence.
Finalità
Fornire consapevolezza delle minacce all'organizzazione in modo che possano essere
intraprese le azioni di mitigazione appropriate.
Guida
Le informazioni sulle minacce esistenti o emergenti vengono raccolte e analizzate al fine
di:
a) facilitare azioni basate su informazioni per prevenire che le minacce causino danni
all'organizzazione;
b) ridurre l'impatto di tali minacce.
La threat intelligence può essere suddivisa in tre livelli, che dovrebbero essere tutti
considerati:
a) threat intelligence strategica: scambio di informazioni di alto livello sul panorama
delle minacce in evoluzione (per esempio tipi di attaccanti o tipi di attacchi);
b) threat intelligence tattica: informazioni sulle metodologie, sugli strumenti e sulle
tecnologie dell'attaccante coinvolte;
c) threat intelligence operativa: dettagli su attacchi specifici, inclusi indicatori tecnici.
La threat intelligence dovrebbe essere:
a) pertinente (ossia relativo alla tutela dell'organizzazione);
b) approfondita (ossia fornisca all'organizzazione una comprensione accurata e
dettagliata del panorama delle minacce);
c) contestuale, per fornire consapevolezza situazionale (vale a dire aggiungere
contesto alle informazioni in base all'ora degli eventi, al luogo in cui si verificano, alle
esperienze precedenti e alla diffusione in organizzazioni simili);

d) utilizzabile (ossia l'organizzazione può agire in base alle informazioni in modo rapido
ed efficace).
Le attività di threat intelligence dovrebbero includere le seguenti:
a) stabilire obiettivi per la produzione di threat intelligence;
b) identificare, controllare e selezionare le fonti informative interne ed esterne
necessarie e appropriate per fornire le informazioni richieste per la produzione di
threat intelligence;
c) raccogliere informazioni da fonti selezionate, che possono essere interne ed
esterne;
d) elaborare le informazioni raccolte per prepararle all'analisi (per esempio traducendo,
formattando o corroborando le informazioni);
e) analizzare le informazioni per capire in che modo sono correlate e significative per
l'organizzazione;
f) comunicarle e condividerle con soggetti pertinenti in un formato comprensibile.
I dati ottenuti dalla threat intelligence dovrebbero essere analizzati e successivamente
utilizzati:
a) implementando processi per includere le informazioni raccolte da fonti di threat
intelligence nei processi di gestione dei rischi relativi al la sicurezza delle
informazioni dell'organizzazione;
b) come input aggiuntivo per controlli tecnici preventivi e investigativi come firewall,
intrusion detection system o soluzioni anti-malware;
c) come input per i processi e le tecniche di test di sicurezza delle informazioni.
Le organizzazioni dovrebbero condividere i dati di threat intelligence con altre
organizzazioni reciprocamente al fine di migliorare la threat intelligence complessiva.
Altre informazioni
Le organizzazioni possono utilizzare la threat intelligence per prevenire, rilevare o
rispondere alle minacce. Le organizzazioni possono produrre threat intelligence, ma più
tipicamente ricevono e utilizzano dati di threat intelligence prodotti da altre fonti.
La threat intelligence è spesso fornita da fornitori o consulenti indipendenti, agenzie
governative o gruppi collaborativi di threat intelligence.
L'efficacia di controlli come 5.25, 8.7, 8.16 o 8.23 dipende dalla qualità dei dati di threat
intelligence disponibili.
5.8 Sicurezza delle informazioni nella gestione dei progetti

#Integrity #Protect #Protection
#Availability
Controllo
La sicurezza delle informazioni dovrebbe essere integrata nella gestione dei progetti.
Finalità
Assicurare che i rischi relativi alla sicurezza delle informazioni e ai progetti e ai loro
risultati finali siano affrontati in modo efficace nella gestione dei progetti durante l'intero
ciclo di vita dei progetti.

Guida
La sicurezza delle informazioni dovrebbe essere integrata nella gestione dei progetti per
assicurare che i rischi relativi alla sicurezza delle informazioni siano affrontati come parte
della gestione dei progetti. Questo può essere applicato a qualsiasi tipo di progetto
indipendentemente dalla sua complessità, dimensione, durata, disciplina o area di
applicazione (per esempio un progetto per un processo di core business, ICT, facility
management o altri processi di supporto).
La gestione dei progetti dovrebbe richiedere che:
a) i rischi relativi alla sicurezza delle informazioni siano valutati e trattati in una fase
iniziale e periodicamente come parte dei rischi di progetto durante l'intero ciclo di
vita dello stesso;
b) i requisiti di sicurezza delle informazioni [per esempio requisiti di sicurezza delle
applicazioni (8.26), requisiti per il rispetto dei diritti di proprietà intellettuale (5.32)]
siano affrontati nelle prime fasi dei progetti;
c) i rischi relativi alla sicurezza delle informazioni associati all'esecuzione dei progetti,
come gli aspetti della sicurezza delle comunicazioni interne ed esterne, siano
considerati e trattati durante tutto il ciclo di vita dei progetti;
d) vengano esaminati i progressi del trattamento del rischio relativo alla sicurezza delle
informazioni e l'efficacia del trattamento venga valutata e verificata.
L'adeguatezza in merito alle considerazioni e alle attività sulla sicurezza delle
informazioni dovrebbe essere seguita, in fasi predefinite, da persone o organi di governo,
quali il comitato di direzione del progetto.
Le responsabilità e le autorità per la sicurezza delle informazioni dovrebbero essere
definite e assegnate a specifici ruoli.
I requisiti di sicurezza delle informazioni per i prodotti o servizi che dovrebbero essere
forniti dal progetto dovrebbero essere determinati utilizzando varie metodologie, ivi
compresa la possibilità di derivare alcuni requisiti di conformità dalla politica per la
sicurezza delle informazioni, dalle politiche specifiche e dai regolamenti. Ulteriori requisiti
di sicurezza delle informazioni possono essere derivati da attività come la modellazione
delle minacce, il riesame degli incidenti, l'uso delle soglie di vulnerabilità o la
pianificazione delle contingenze, assicurando così che l'architettura e la progettazione dei
sistemi informativi siano protetti dalle minacce note in base all'ambiente operativo.
I requisiti di sicurezza delle informazioni dovrebbero essere determinati per tutti i tipi di
progetti, non solo per i progetti di sviluppo in ambito ICT. Quando si determinano questi
requisiti dovrebbero essere presi in considerazione anche:
a) quali informazioni sono coinvolte (individuazione delle informazioni), qual è il
corrispondente loro valore di sicurezza (classificazione; vedere 5.12) e il potenziale
impatto negativo sul business che può derivare dalla mancanza di un'adeguata
sicurezza;
b) le esigenze richieste per la protezione delle informazioni e degli altri asset relativi
coinvolti, in particolare in termini di riservatezza, integrità e disponibilità;
c) il livello di confidenza o assicurazione richiesta nei confronti dell'identità dichiarata
delle entità al fine di determinare i requisiti di autenticazione;
d) i processi di fornitura degli accessi e i processi di autorizzazione, per i clienti e altri
potenziali utenti di business, nonché per utenti privilegiati o tecnici come i membri
pertinenti del progetto, il potenziale personale operativo o i fornitori esterni;
e) informare gli utenti dei loro doveri e responsabilità;
f) i requisiti derivati dai processi di business, come la registrazione e il monitoraggio
delle transazioni, i requisiti di non ripudio;
g) requisiti imposti da altri controlli per la sicurezza delle informazioni (per esempio
interfacce per la registrazione e il monitoraggio o sistemi di rilevamento delle fughe di
dati);
h) conformità con il contesto legale, statutario, regolamentare e contrattuale in cui
opera l'organizzazione;

i) livello di confidenza o assicurazione richiesto alle terze parti al fine di soddisfare la
politica per la sicurezza delle informazioni dell'organizzazione e le politiche
specifiche, comprese le clausole di sicurezza pertinenti contenute in eventuali
accordi o contratti.
Altre informazioni
L'approccio allo sviluppo del progetto, come il ciclo di vita waterfall o il ciclo di vita agile,
dovrebbe supportare la sicurezza delle informazioni in un modo strutturato che può
essere adattato per applicarsi correttamente alla gravità dei rischi relativi alla sicurezza
delle informazioni valutata, in base al tipo di progetto. L’iniziale considerazione dei requisiti
di sicurezza delle informazioni per il prodotto o servizio (per esempio nelle fasi di
pianificazione e progettazione), può portare a soluzioni più efficaci ed economiche per la
sicurezza della qualità e delle informazioni. ISO 21500 e ISO 21502 forniscono
indicazioni sui concetti e sui processi di gestione dei progetti che sono importanti per
l'esecuzione degli stessi.
ISO/IEC 27005 fornisce una guida sull'uso dei processi di gestione del rischio al fine di
identificare i controlli per soddisfare i requisiti di sicurezza delle informazioni.
5.9 Inventario delle informazioni e degli altri asset relativi

#Preventive #Confidentiality #Identify #Asset_management #Governance_and_Ecosystem
#Integrity #Protection
#Availability
Controllo
Dovrebbe essere sviluppato e mantenuto un inventario delle informazioni e degli altri
asset relativi, compresi i responsabili.
Finalità
Identificare le informazioni dell'organizzazione e gli altri asset relativi al fine di preservare
la sicurezza delle informazioni e di assegnarne la corretta appartenenza.
Guida
Inventario
L'organizzazione dovrebbe identificare le proprie informazioni e gli altri asset relativi e
determinarne l'importanza in termini di sicurezza delle informazioni. La documentazione
dovrebbe essere conservata, a seconda dei casi, in inventari a ciò dedicati o già esistenti.
L'inventario delle informazioni e degli altri asset relativi dovrebbe essere accurato,
aggiornato, coerente e allineato con gli altri inventari. Le soluzioni per assicurare
l'accuratezza di un inventario delle informazioni e degli altri asset relativi includono:
a) condurre riesami periodici delle informazioni identificate e degli altri asset relativi
rispetto all'inventario degli asset;
b) imporre un aggiornamento automatico dell'inventario durante il processo di
implementazione, cambiamento o rimozione di un asset.
A seconda dei casi, l'ubicazione di un asset dovrebbe essere inclusa nell'inventario.
Non è necessario che l'inventario sia un unico elenco di informazioni e di altri asset
relativi. Considerando che l'inventario dovrebbe essere mantenuto dalle funzioni
competenti, può essere visto come un insieme di inventari dinamici, come inventari per
asset informativi, hardware, software, macchine virtuali (VM), strutture, personale,
competenze, capacità e registrazioni.
Ciascun asset dovrebbe essere classificato conformemente alla classificazione delle
informazioni (vedere 5.12) associate a tale asset.

Il livello di granularità dell'inventario delle informazioni e degli altri asset relativi dovrebbe
essere appropriato alle esigenze dell'organizzazione. A volte non è possibile
documentare specifici utilizzi di asset relativi al ciclo di vita delle informazioni a causa
della natura stessa dell’asset. Un esempio di asset di breve durata è un'istanza VM il cui
ciclo di vita può essere di breve durata.
Responsabilità
Per le informazioni identificate e per gli altri asset relativi, la responsabilità degli asset
dovrebbe essere assegnata a una persona o a un gruppo e la classificazione dovrebbe
essere identificata (vedere 5.12, 5.13). Dovrebbe essere implementato un processo per
assicurare l'assegnazione tempestiva della responsabilità degli asset. La responsabilità
dovrebbe essere assegnata quando gli asset vengono creati o quando vengono trasferiti
all'organizzazione. Se necessario, la responsabilità degli asset dovrebbe essere
riassegnata quando gli attuali responsabili degli asset lasciano o cambiano i ruoli
lavorativi.
Doveri del responsabile
Il responsabile dell’asset dovrebbe essere responsabile della corretta gestione di questo
durante l'intero ciclo di vita dello stesso, assicurando che:
a) le informazioni e gli altri asset relativi siano inventariati;
b) le informazioni e gli altri asset relativi siano opportunamente classificati e protetti;
c) la classificazione sia riesaminata periodicamente;
d) i componenti a supporto degli asset tecnologici, come database, storage,
componenti software e sottocomponenti, siano elencati e associati;
e) siano stabiliti i requisiti per l'uso consentito delle informazioni e degli altri asset
relativi (vedere 5.10);
f) le limitazioni all'accesso siano conformi alla classificazione, siano efficaci e siano
riesaminate periodicamente;
g) le informazioni e gli altri asset relativi, quando eliminati o dismessi, siano trattati in
modo sicuro e rimossi dall'inventario;
h) sia coinvolto nell'identificazione e gestione dei rischi associati al proprio/i asset;
i) supporti il personale che ha ruoli e responsabilità nella gestione delle proprie
informazioni.
Altre informazioni
Gli inventari delle informazioni e degli altri asset relativi sono spesso necessari per
assicurare la protezione efficace delle informazioni e possono essere richiesti per altri
scopi, come salute e sicurezza, assicurazioni o motivi economici. Gli inventari delle
informazioni e degli altri asset relativi supportano anche la gestione del rischio, le attività
di audit, la gestione della vulnerabilità, la risposta agli incidenti e la pianificazione del
ripristino.
I compiti e le responsabilità possono essere delegati (per esempio a un custode che si
occupa quotidianamente degli asset), ma la persona o il gruppo che li ha delegati rimane
responsabile.
Può essere utile designare gruppi di informazioni e degli altri asset relativi che agiscono
insieme per fornire un particolare servizio. In questo caso, il responsabile di questo
servizio è responsabile della fornitura dello stesso, compreso il funzionamento dei suoi
asset.
Vedere ISO/IEC 19770-1 per ulteriori informazioni sulla gestione degli asset in ambito
informatico. Vedere ISO 55001 per ulteriori informazioni sulla gestione dei beni (asset
management).

5.10 Uso accettabile delle informazioni e degli altri asset relativi

#Preventive #Confidentiality #Protect #Asset_management #Governance_and_Ecosystem
#Integrity #Information_protection #Protection
#Availability
Controllo
Le regole per l'uso accettabile e le procedure per il trattamento delle informazioni e degli
altri asset relativi dovrebbero essere identificate, documentate e attuate.
Finalità
Assicurare che siano adeguatamente protette, utilizzate e trattate le informazioni e gli altri
asset relativi.
Guida
Il personale e gli utenti esterni che utilizzano o hanno accesso alle informazioni
dell'organizzazione e agli altri asset relativi dovrebbero essere informati in merito ai
requisiti di sicurezza delle informazioni al fine di proteggere e trattare le informazioni
dell'organizzazione e gli altri asset relativi. Essi dovrebbero essere responsabili dell’uso
che fanno di qualsiasi struttura di elaborazione delle informazioni.
L'organizzazione dovrebbe stabilire una politica specifica per l'uso accettabile delle
informazioni e degli altri asset relativi e comunicarla a chiunque utilizza o tratta
informazioni e gli altri asset relativi. La politica specifica per l'uso accettabile dovrebbe
fornire indicazioni chiare su come ci si aspetta che le persone utilizzino le informazioni e
gli altri asset relativi. Tale politica specifica dovrebbe indicare:
a) i comportamenti attesi e quelli inaccettabili degli individui dal punto di vista della
sicurezza delle informazioni;
b) l’uso consentito e quello proibito delle informazioni e degli altri asset relativi;
c) il monitoraggio delle attività svolte dall'organizzazione.
Dovrebbero essere elaborate procedure per l’utilizzo accettabile relativamente all'intero
ciclo di vita delle informazioni in conformità con la loro classificazione (vedere 5.12) e con
i rischi determinati. Dovrebbero essere considerati i seguenti elementi:
a) limitazioni di accesso a supporto dei requisiti di protezione per ciascun livello di
classificazione;
b) mantenimento di un registro degli utenti autorizzati alle informazioni e agli altri asset
relativi;
c) protezione delle copie temporanee o permanenti delle informazioni a un livello
coerente con la protezione delle informazioni originali;
d) conservazione degli asset relativi alle informazioni secondo le specifiche dei
produttori (vedere 7.8);
e) contrassegnare in modo chiaro, per richiamare l'attenzione del destinatario
autorizzato, tutte le copie dei supporti di memorizzazione (elettronici o fisici) (vedere
7.10);
f) autorizzazione alla dismissione delle informazioni e degli altri asset relativi, con i
metodi supportati (vedere 8.10).
Altre informazioni
È possibile che gli asset interessati non appartengano direttamente all'organizzazione,
come i servizi cloud pubblici. L'uso di tali asset di terze parti e di qualsiasi asset
dell'organizzazione associato a tali asset esterni (per esempio informazioni, software)
dovrebbe essere identificato come applicabile e controllato, per esempio, attraverso
accordi con i fornitori di servizi cloud. Occorre prestare attenzione anche quando si
utilizza un ambiente di lavoro collaborativo.

5.11 Restituzione degli asset

#Preventive #Confidentiality #Protect #Asset_management #Protection
#Integrity
#Availability
Controllo
Il personale e le altre parti interessate, a seconda dei casi, dovrebbero restituire tutti gli
asset dell'organizzazione in loro possesso in caso di cambiamento o cessazione del
rapporto di lavoro, del contratto o dell’accordo.
Finalità
Proteggere le risorse dell'organizzazione come parte del processo di cambiamento o
cessazione del rapporto di lavoro, del contratto o dell’accordo.
Guida
Dovrebbe essere formalizzato il processo di cambiamento o cessazione affinché includa
la restituzione di tutti gli asset fisici ed elettronici precedentemente assegnati che siano di
proprietà all'organizzazione o affidati ad essa.
Nel caso in cui il personale e le altre parti interessate acquistino apparecchiature
dell'organizzazione o utilizzino apparecchiature di proprietà personale, dovrebbero
essere seguite procedure per assicurare che tutte le informazioni pertinenti siano
tracciate e trasferite all'organizzazione e cancellate in modo sicuro dalle apparecchiature
(vedere 7.14).
Nel caso in cui il personale e le altre parti interessate siano a conoscenza di elementi
importanti per le attività in corso, tali informazioni dovrebbero essere documentate e
trasferite all'organizzazione.
L'organizzazione dovrebbe impedire la copia non autorizzata di informazioni rilevanti (per
esempio proprietà intellettuale) da parte del personale durante il periodo di preavviso.
L'organizzazione dovrebbe identificare e documentare chiaramente tutte le informazioni e
gli altri asset relativi che dovrebbero essere restituiti che possono includere:
a) endpoint degli utenti;
b) dispositivi di memorizzazione portatili;
c) apparecchiature specialistiche;
d) hardware di autenticazione (per esempio chiavi meccaniche, token fisici e smart
card) per sistemi informativi, siti e archivi fisici;
e) copie fisiche delle informazioni.
Altre informazioni
Può essere difficile la restituzione delle informazioni presenti su asset che non sono di
proprietà dell'organizzazione. In tali casi, si dovrebbe limitare l'uso delle informazioni
utilizzando altri controlli per la sicurezza delle informazioni come la gestione dei diritti di
accesso (5.18) o l'uso della crittografia (8.24).
5.12 Classificazione delle informazioni

#Preventive #Confidentiality #Identify #Information_protection #Protection
#Integrity #Defence
#Availability

Controllo
Le informazioni dovrebbero essere classificate in base alle esigenze di sicurezza delle
informazioni dell'organizzazione sulla base dei requisiti di riservatezza, integrità,
disponibilità e delle parti interessate pertinenti.
Finalità
Assicurare l'identificazione e la comprensione delle esigenze di protezione delle
informazioni in conformità con la loro importanza per l'organizzazione.
Guida
L'organizzazione dovrebbe stabilire una politica specifica per la classificazione delle
informazioni e comunicarla a tutte le parti interessate pertinenti.
L'organizzazione dovrebbe tenere conto, nello schema di classificazione, dei requisiti di
riservatezza, integrità e disponibilità.
Le classificazioni e i relativi controlli per la protezione delle informazioni dovrebbero
tenere conto delle esigenze di business di condivisione o di limitazione alla diffusione
delle informazioni, di protezione dell'integrità delle informazioni e di assicurazione della
disponibilità, nonché dei requisiti legali in materia di riservatezza, integrità o disponibilità
delle informazioni. Gli asset diversi dalle informazioni possono anche essere classificati in
conformità con la classificazione delle informazioni che vi sono memorizzate, elaborate
oppure trattate o protette dall’asset.
I responsabili delle informazioni dovrebbero essere responsabili della loro classifica.
Lo schema di classificazione dovrebbe includere convenzioni per la classificazione e
criteri per il riesame periodico della classificazione. I risultati della classificazione
dovrebbero essere aggiornati in base alle variazioni del valore, della sensibilità e della
sensibilità delle informazioni durante il loro ciclo di vita.
Lo schema dovrebbe essere allineato alla politica specifica per il controllo degli accessi
(vedere 5.1) e dovrebbe essere in grado di soddisfare specifiche esigenze di business
La classificazione può essere determinata dal livello di impatto che la compromissione
avrebbe per l'organizzazione. A ogni livello definito nello schema dovrebbe essere
assegnato un nome che abbia senso nel contesto applicativo dello schema di
classificazione.
Lo schema dovrebbe essere coerente in tutta l'organizzazione e incluso nelle sue
procedure in modo che tutti classifichino le informazioni e che sia applicabile agli altri
asset relativi allo stesso modo, in modo che tutti abbiano una comprensione comune dei
requisiti di protezione e in modo che tutti applichino la protezione appropriata.
Lo schema di classificazione utilizzato all'interno dell'organizzazione può essere diverso
dagli schemi utilizzati da altre organizzazioni, anche se i nomi dei livelli sono simili. Inoltre,
le informazioni che sono scambiate tra le organizzazioni possono variare nella
classificazione a seconda del contesto proprio di ciascuna organizzazione, anche se i loro
schemi di classificazione sono identici. Pertanto, gli accordi con altre organizzazioni che
includono la condivisione delle informazioni dovrebbero comprendere procedure per
identificare la classificazione di tali informazioni e per interpretare il corretto livello di
classificazione nelle altre organizzazioni. La corrispondenza tra diversi schemi può
essere determinata cercando l'equivalenza nei metodi di trattamento e protezione
associati.
Altre informazioni
La classificazione fornisce alle persone che si occupano di informazioni un'indicazione
sintetica su come trattarle e proteggerle. Questa operazione è facilitata dalla creazione di
gruppi di informazioni con esigenze di protezione simili e specificando procedure di
sicurezza delle informazioni applicabili a tutte le informazioni in ciascun gruppo. Questo
approccio riduce la necessità di una valutazione del rischio caso per caso e di una
progettazione personalizzata dei controlli.

Le informazioni possono cessare di essere sensibili o critiche dopo un certo periodo di
tempo. Per esempio, quando l'informazione è stata resa pubblica, non ha più requisiti di
riservatezza ma può comunque richiedere protezione per le sue proprietà di integrità e
disponibilità. Questi aspetti dovrebbero essere presi in considerazione, poiché una
classificazione eccessiva può portare all' implementazione di controlli non necessari con
conseguenti spese aggiuntive o, al contrario, una classificazione insufficiente può portare
a controlli insufficienti per proteggere le informazioni dalla loro compromissione.
Un esempio di schema di classificazione della riservatezza delle informazioni può essere
basato su quattro livelli come segue:
a) la divulgazione non arreca danno;
b) la divulgazione causa un danno reputazionale minore o un impatto minore sulle
attività operative;
c) la divulgazione ha un impatto significativo a breve termine sulle attività operative o
sugli obiettivi di business;
d) la divulgazione ha un grave impatto sugli obiettivi di business a lungo termine o
mette a rischio la sopravvivenza stessa dell'organizzazione.
5.13 Etichettatura delle informazioni

#Preventive #Confidentiality #Protect #Information_protection #Defence
#Availability
Controllo
Un insieme appropriato di procedure per l'etichettatura delle informazioni dovrebbe
essere sviluppato e implementato in conformità con lo schema di classificazione delle
informazioni adottato dall'organizzazione.
Finalità
Facilitare la comunicazione della classificazione delle informazioni e supportare
l'automazione dell'elaborazione e della gestione delle informazioni.
Guida
Le procedure per l'etichettatura delle informazioni dovrebbero riguardare le informazioni e
gli altri asset relativi in tutti i formati. L'etichettatura dovrebbe riflettere lo schema di
classificazione stabilito al paragrafo 5.12. Le etichette dovrebbero essere facilmente
riconoscibili. Le procedure dovrebbero fornire indicazioni su dove e come vengono poste
le etichette in considerazione di come si accede alle informazioni o si trattano gli asset a
seconda dei tipi di supporti di memorizzazione. Le procedure possono definire:
a) i casi in cui l'etichettatura è omessa (per esempio etichettatura di informazioni non
riservate per ridurre i carichi di lavoro);
b) come etichettare le informazioni inviate o memorizzate su dispositivi elettronici o
fisici, o qualsiasi altro formato;
c) come gestire i casi in cui l'etichettatura non è possibile (per esempio a causa di
restrizioni tecniche).
Esempi di tecniche di etichettatura includono:
a) etichette fisiche;
b) intestazioni e piè di pagina;
c) metadati;
d) filigrana;
e) timbri.

Le informazioni digitali dovrebbero utilizzare i metadati al fine di identificare, gestire e
controllare le informazioni, in particolare per quanto riguarda la riservatezza. I metadati
dovrebbero anche consentire una ricerca efficiente e corretta delle informazioni. I
metadati dovrebbero facilitare l'interazione dei sistemi e permettere di prendere decisioni
in base alle etichette di classificazione allegate.
Le procedure dovrebbero descrivere come allegare i metadati alle informazioni, quali
etichette utilizzare e come dovrebbero essere trattati i dati, in linea con il modello
informativo dell'organizzazione e l'architettura ICT.
Dei metadati pertinenti dovrebbero essere aggiunti dai sistemi quando elaborano le
informazioni in base alle loro proprietà di sicurezza.
Il personale e le altre parti interessate dovrebbero essere resi consapevoli delle
procedure di etichettatura. Tutto il personale dovrebbe ricevere la formazione necessaria
per assicurare che le informazioni siano etichettate correttamente e trattate di
conseguenza.
L'output dei sistemi contenenti informazioni classificate come sensibili o critiche dovrebbe
essere munito di un'etichetta di classificazione appropriata.
Altre informazioni
L'etichettatura delle informazioni classificate è un requisito fondamentale per la
condivisione delle informazioni.
Altri metadati utili che possono essere allegati alle informazioni sono: quale processo
organizzativo ha creato le informazioni e a che ora.
L'etichettatura delle informazioni e degli altri asset relativi può talvolta avere effetti
negativi. Gli asset classificati possono essere più facili da identificare da parte di attori
malintenzionati per potenziali usi impropri.
Alcuni sistemi non etichettano i singoli file o i record di un database con la loro classifica,
ma proteggono tutte le informazioni al più alto livello di classificazione di qualsiasi
informazione che contiene o è autorizzato a contenere. È normale in tali sistemi
determinare e quindi etichettare le informazioni quando vengono esportate.
5.14 Trasferimento delle informazioni

#Integrity #Information_protection
#Availability
Controllo
Dovrebbero essere in vigore regole, procedure o accordi per il trasferimento delle
informazioni per tutte le tipologie di strutture di trasferimento all'interno
dell'organizzazione e tra l'organizzazione e altre parti.
Finalità
Mantenere la sicurezza delle informazioni trasferite all'interno di un'organizzazione e con
qualsiasi parte esterna interessata.
Guida
Generale
L'organizzazione dovrebbe stabilire e comunicare una politica specifica per il
trasferimento delle informazioni a tutte le parti interessate pertinenti. Regole, procedure e
accordi per proteggere le informazioni in transito dovrebbero tener conto della
classificazione delle informazioni coinvolte. Quando le informazioni vengono trasferite tra
l'organizzazione e terze parti, dovrebbero essere stabiliti e mantenuti accordi per il
trasferimento (compresa l'autenticazione del destinatario) per proteggere le informazioni
in transito in qualsiasi forma (vedere 5.10).

Il trasferimento di informazioni può avvenire tramite trasferimento elettronico, di supporti
fisici di memorizzazione e orale.
Per tutti i tipi di trasferimento di informazioni, le regole, le procedure e gli accordi
dovrebbero includere:
a) controlli volti a proteggere dall'intercettazione le informazioni trasferite, dall'accesso
non autorizzato, dalla copia, dalla modifica, dal dirottamento, dalla distruzione e
dalla negazione del servizio, inclusi livelli di controllo degli accessi commisurati alla
classificazione delle informazioni coinvolte ed eventuali controlli speciali necessari
per proteggere le informazioni sensibili, come l'uso di tecniche crittografiche (vedere
8.24);
b) controlli per assicurare la tracciabilità e il non ripudio, compreso il mantenimento di
una catena di custodia delle informazioni durante il transito;
c) l’identificazione di contatti appropriati relativi al trasferimento, inclusi responsabili
delle informazioni, responsabili dei rischi, responsabili della sicurezza e custodi delle
informazioni, a seconda dei casi;
d) responsabilità e imputabilità in caso di incidenti relativi alla sicurezza delle
informazioni, come la perdita di dati o di supporti di memorizzazione fisici;
e) l’utilizzo di un sistema di etichettatura concordato per le informazioni sensibili o
critiche, assicurando che il significato delle etichette sia compreso immediatamente
e che le informazioni siano adeguatamente protette (vedere 5.13);
f) l’affidabilità e la disponibilità del servizio di trasferimento;
g) la politica specifica o le linee guida per l'uso accettabile delle strutture di
trasferimento delle informazioni (vedere 5.10);
h) linee guida per la conservazione e lo smaltimento di tutti i documenti di business,
compresi i messaggi;
Nota Possono esistere norme di legge e regolamenti locali per quanto riguarda la conservazione e l'eliminazione
dei documenti di business.
i) l'esame di ogni altro requisito legale, normativo, regolamentare e contrattuale
pertinente (vedere 5.31, 5.32, 5.33, 5.34) relativo al trasferimento di informazioni
(per esempio requisiti per la firma elettronica).
Trasferimento elettronico
Regole, procedure e accordi dovrebbero anche considerare i seguenti elementi quando si
utilizzano le strutture di comunicazione elettronica per il trasferimento delle informazioni:
a) rilevamento e protezione dal malware che può essere trasmesso attraverso l'uso di
comunicazioni elettroniche (vedere 8.7);
b) protezione delle informazioni elettroniche sensibili comunicate in forma di allegato;
c) prevenzione dall'invio di documenti e messaggi nelle comunicazioni all'indirizzo o
numero errato;
d) ottenimento dell'approvazione prima di utilizzare servizi pubblici esterni come
messaggistica istantanea, social networking, condivisione di file o memorizzazione
in cloud;
e) livelli più elevati di autenticazione nel trasferimento di informazioni tramite reti
accessibili al pubblico;
f) limitazioni relative ai mezzi di comunicazione elettronica (per esempio impedire
l'inoltro automatico della posta elettronica a indirizzi esterni);
g) avviso al personale e agli altri interessati di non inviare SMS o messaggi istantanei
con informazioni critiche in quanto possono essere letti in luoghi pubblici (e quindi da
persone non autorizzate) o memorizzati in dispositivi non adeguatamente protetti;
h) informazioni al personale e alle altre parti interessate in merito ai problemi di utilizzo
di apparecchi o servizi fax, ossia:
1) accesso non autorizzato alla memoria interna dell’apparato per recuperare i
messaggi;

2) programmazione intenzionale o accidentale di macchine per l'invio di messaggi
a numeri specifici.
Trasferimento di supporti di memorizzazione fisici
Quando si trasferiscono supporti di memorizzazione fisici (inclusa la carta), le regole, le
procedure e gli accordi dovrebbero includere anche:
a) responsabilità di controllo e notifica di trasmissione, invio e ricezione;
b) assicurazione sul corretto indirizzo e trasporto del messaggio;
c) imballi che proteggano il contenuto da eventuali danni fisici che potrebbero verificarsi
durante il trasporto e in conformità con le eventuali specifiche dei produttori, per
esempio proteggendoli da eventuali fattori ambientali che possano ridurre l'efficacia
del ripristino dei supporti di memorizzazione quali l'esposizione a calore, umidità o
campi elettromagnetici; utilizzo di standard tecnici minimi per l'imballaggio e la
trasmissione (per esempio uso di buste opache);
d) un elenco di corrieri affidabili autorizzati concordato dalla direzione;
e) standard di identificazione del corriere;
f) a seconda del livello di classificazione delle informazioni contenute nei supporti di
memorizzazione da trasportare, utilizzo di sigilli anti effrazione o a prova di
manomissione (per esempio sacchi, contenitori);
g) procedure per verificare l'identificazione dei corrieri;
h) elenco approvato di terzi che forniscono servizi di trasporto o corriere a seconda
della classificazione delle informazioni;
i) tenuta di registri per l'identificazione del contenuto del supporto di memorizzazione,
della protezione applicata nonché della registrazione dell'elenco dei destinatari
autorizzati, dei tempi di trasferimento ai custodi di transito e di ricezione a
destinazione.
Trasferimento orale
Per proteggere il trasferimento orale delle informazioni, si ricorda al personale e alle altre
parti interessate che dovrebbero:
a) non intrattenere conversazioni riservate in luoghi pubblici o su canali di
comunicazione non sicuri poiché possono essere ascoltate da persone non
autorizzate;
b) non lasciare messaggi contenenti informazioni riservate su segreterie telefoniche o
messaggi vocali in quanto possono essere riprodotti da persone non autorizzate,
memorizzati su sistemi a uso comune o memorizzati in modo errato a causa di errori
di composizione;
c) essere autorizzati al livello appropriato per ascoltare la conversazione;
d) assicurarsi che siano implementati idonei controlli nella stanza (per esempio
insonorizzazione, porte chiuse);
e) avviare eventuali conversazioni sensibili informando i presenti circa il livello di
classificazione e gli eventuali requisiti di trattamento di ciò che stanno per ascoltare.
Altre informazioni
5.15 Controllo degli accessi

#Preventive #Confidentiality #Protect #Identity_and_access_management #Protection
#Integrity
#Availability

Controllo
Le regole per controllare l'accesso fisico e logico alle informazioni e agli altri asset relativi
dovrebbero essere stabilite e implementate sulla base dei requisiti di business e di
sicurezza delle informazioni.
Finalità
Assicurare l'accesso autorizzato e impedire l'accesso non autorizzato alle informazioni e
agli altri asset relativi.
Guida
I responsabili delle informazioni e degli altri asset relativi dovrebbero determinare i
requisiti di business e di sicurezza delle informazioni relativi al controllo degli accessi.
Dovrebbe essere definita una politica specifica per il controllo degli accessi che tenga
conto di questi requisiti e che dovrebbe essere comunicata a tutte le parti interessate
pertinenti.
Questi requisiti e la politica specifica dovrebbero considerare quanto segue:
a) determinazione di quali entità richiedono quale tipo di accesso alle informazioni e
agli altri asset relativi;
b) sicurezza delle applicazioni (vedere 8.26);
c) accesso fisico, che dovrebbe essere supportato da idonei controlli fisici all'ingresso
(vedere 7.2, 7.3, 7.4);
d) diffusione delle informazioni e autorizzazione (per esempio il principio della
necessità di conoscere) e livelli di sicurezza e di classificazione delle informazioni
(vedere 5.10, 5.12, 5.13);
e) limitazione degli accessi privilegiati (vedere 8.2);
f) separazione dei compiti (vedere 5.3);
g) le norme di legge, i regolamenti e gli eventuali obblighi contrattuali concernenti la
limitazione degli accessi ai dati o ai servizi (vedere 5.31, 5.32, 5.33, 5.34, 8.3);
h) separazione delle funzioni di controllo accessi (per esempio richiesta di accesso,
autorizzazione all'accesso, amministrazione degli accessi);
i) formale autorizzazione delle richieste di accesso (vedere 5.16 e 5.18);
j) la gestione dei diritti di accesso (vedere 5.18);
k) logging (vedere 8.15).
Le regole di controllo degli accessi dovrebbero essere implementate definendo e
associando idonei diritti di accesso e limitazioni alle entità pertinenti (vedere 5.16).
Un'entità può rappresentare un utente umano così come un elemento tecnico o logico
(per esempio una macchina, un dispositivo o un servizio). Per semplificare la gestione del
controllo degli accessi, possono essere assegnati ruoli specifici a gruppi di entità.
Quando si definiscono e si implementano le regole di controllo degli accessi si dovrebbe
tenere conto di quanto segue:
a) coerenza tra i diritti di accesso e la classificazione delle informazioni;
b) coerenza tra i diritti di accesso e le esigenze e i requisiti di sicurezza perimetrale
fisica;
c) considerazione di tutti i tipi di connessioni disponibili negli ambienti distribuiti in modo
che le entità abbiano accesso solo alle informazioni e agli altri asset relativi,
comprese le reti e i servizi di rete, che sono autorizzate a utilizzare;
d) considerazione di come possono ripercuotersi elementi o fattori pertinenti per il
controllo dinamico degli accessi.

Altre informazioni
Nel contesto del controllo degli accessi sono spesso utilizzati principi generali. Due dei
principi più frequentemente utilizzati sono:
a) necessità di conoscere: a un'entità è concesso l'accesso solo alle informazioni che
l'entità richiede per svolgere i suoi compiti (diversi compiti o ruoli comportano diverse
informazioni da conoscere e quindi differenti profili di accesso);
b) necessità d'uso: a un'entità viene assegnato solo l'accesso all'infrastruttura
tecnologica laddove sia presente una evidente necessità.
Si dovrebbe prestare attenzione quando si specificano le regole di controllo degli accessi
al fine di considerare:
a) di stabilire regole fondate sul presupposto del minimo privilegio, “in generale tutto è
vietato a meno che non sia espressamente consentito”, piuttosto che la regola più
debole, “in generale tutto è permesso a meno che non sia espressamente vietato”;
b) i cambiamenti all’etichettatura delle informazioni (vedere 5.13) avviati
automaticamente dalle strutture di elaborazione delle informazioni e quelli avviati a
discrezione degli utenti;
c) i cambiamenti dei permessi degli utenti avviati automaticamente dal sistema
informativo e quelli avviati da un amministratore;
d) quando definire e riesaminare periodicamente l'approvazione.
Le regole di controllo degli accessi dovrebbero essere supportate da procedure
documentate (vedere 5.16, 5.17, 5.18, 8.2, 8.3, 8.4, 8.5, 8.18) e responsabilità definite
(vedere 5.2, 5.17).
Esistono diversi modi per implementare il controllo degli accessi, come MAC (controllo
degli accessi obbligatorio), DAC (controllo degli accessi discrezionale), RBAC (controllo
degli accessi basato sul ruolo) e ABAC (controllo degli accessi basato sugli attributi).
Le regole di controllo degli accessi possono contenere anche elementi dinamici (per
esempio una funzione che valuta gli accessi precedenti o valori specifici dell’ambiente. Le
regole di controllo degli accessi possono essere implementate con differenti granularità,
che vanno dalla copertura di intere reti o sistemi fino a specifici campi dati e possono
anche tener conto di proprietà come la localizzazione degli utenti o il tipo di connessione
di rete utilizzata per l'accesso. Questi principi e il modo in cui viene definito il controllo
granulare degli accessi possono avere un impatto significativo sui costi. Regole più
stringenti e maggiore granularità in genere portano a costi più elevati.
I requisiti di business e le considerazioni relative al rischio dovrebbero essere utilizzati per
definire quali regole di controllo degli accessi applicare e quale granularità richiedere.
5.16 Gestione delle identità

#Integrity
#Availability
Controllo
L'intero ciclo di vita delle identità dovrebbe essere gestito.
Finalità
Permettere l'identificazione univoca delle persone e dei sistemi che accedono alle
informazioni dell'organizzazione e agli altri asset relativi e consentire l'appropriata
assegnazione dei diritti di accesso.

Guida
I processi utilizzati nel contesto della gestione delle identità dovrebbero assicurare che:
a) per le identità assegnate a persone, un'identità specifica sia collegata solo a una
singola persona per poter ritenere la persona responsabile delle azioni compiute con
questa specifica identità;
b) le identità attribuite a più persone (per esempio identità condivise) siano consentite
solo dove necessarie per ragioni di business o operative e siano soggette ad
apposita approvazione e documentazione;
c) le identità assegnate a entità non riferite a persone siano soggette ad approvazione
opportunamente separata e a un controllo continuo e indipendente;
d) le identità siano disabilitate o rimosse tempestivamente se non sono più necessarie
(per esempio se le entità associate vengono cancellate o non più utilizzate, oppure
se la persona collegata a un'identità ha lasciato l'organizzazione o ha cambiato
ruolo);
e) in un dominio specifico, una singola identità sia mappata su una singola entità,
[ovvero si eviti la mappatura di più identità sulla stessa entità all'interno dello stesso
contesto (identità duplicate)];
f) siano conservate le registrazioni di tutti gli eventi significativi riguardanti l'uso e la
gestione delle identità degli utenti e delle informazioni di autenticazione.
Le organizzazioni dovrebbero disporre di un processo di supporto per gestire i
cambiamenti alle informazioni relative alle identità degli utenti. Questo processo può
includere la ripetizione della verifica dei documenti attendibili relativi alla persona.
Quando si utilizzano identità fornite o emesse da terze parti (per esempio credenziali di
social media), l'organizzazione dovrebbe assicurarsi che le identità di terze parti
forniscano il livello di fiducia richiesto e che i rischi associati siano noti e sufficientemente
trattati. Ciò può includere controlli relativi alle terze parti (vedere 5.19) nonché controlli
relativi alle informazioni di autenticazione associate (vedere 5.17).
Altre informazioni
Fornire o revocare l'accesso alle informazioni e agli altri asset relativi è solitamente una
procedura in più fasi:
a) confermare che i requisiti di business per un'identità siano stati stabiliti;
b) verificare l'identità di un'entità prima di attribuirgli un'identità logica;
c) stabilire un'identità;
d) configurare e attivare l'identità. Ciò include anche la configurazione e l’impostazione
iniziale dei relativi servizi di autenticazione;
e) fornire o revocare specifici diritti di accesso all'identità, sulla base di adeguate
decisioni di autorizzazione o abilitazione (vedere 5.18).
5.17 Informazioni di autenticazione
Tipo di Proprietà di sicurezza Concetti di Capacità operative Domini di sicurezza

controllo delle informazioni cybersecurity
#Integrity
#Disponibilità
Controllo
L'assegnazione e la gestione delle informazioni di autenticazione dovrebbero essere
controllate da un processo gestionale, che preveda di informare il personale in merito al
trattamento appropriato delle informazioni di autenticazione.
Finalità
Assicurare la corretta autenticazione dell'entità e prevenire errori dei processi di
autenticazione.

Guida
Assegnazione delle informazioni di autenticazione
Il processo di assegnazione e gestione dovrebbe assicurare che:
a) password personali o PIN generati automaticamente durante i processi di
registrazione, così come le informazioni segrete di autenticazione temporanee, non
siano intuibili e siano univoche per ciascuna persona e che gli utenti siano tenuti a
cambiarle dopo il primo utilizzo;
b) siano stabilite procedure per verificare l'identità di un utente prima di fornire nuove,
sostitutive o temporanee informazioni di autenticazione;
c) le informazioni di autenticazione, comprese le informazioni di autenticazione
temporanee, siano trasmesse agli utenti in modo sicuro (per esempio attraverso un
canale autenticato e protetto); si eviti l'uso di messaggi di posta elettronica non
protetti (con testo in chiaro);
d) gli utenti confermino di aver ricevuto le informazioni di autenticazione;
e) le informazioni di autenticazione predefinite o fornite dai fornitori vengano cambiate
immediatamente dopo l'installazione dei sistemi o del software;
f) siano conservate le registrazioni degli eventi significativi riguardanti l'assegnazione e
la gestione delle informazioni di autenticazione e ne sia assicurata la riservatezza, e
che il metodo di conservazione delle registrazioni sia approvato (per esempio
utilizzando password vault approvati).
Responsabilità degli utenti
Qualsiasi persona che abbia accesso o utilizzi le informazioni di autenticazione dovrebbe
essere informata di quanto segue:
a) le informazioni segrete di autenticazione, come le password, sono mantenute
riservate. Le informazioni segrete di autenticazione personali non dovrebbero
essere condivise con nessuno. Le informazioni segrete di autenticazione utilizzate
nel contesto di identità collegate a più utenti o collegate a entità non personali sono
condivise esclusivamente con le persone autorizzate;
b) le informazioni di autenticazione attaccate o compromesse vengono cambiate
immediatamente dopo la notifica o qualsiasi altra indicazione di compromissione;
c) quando le password sono utilizzate come informazioni di autenticazione, sono
selezionate password robuste in base alle raccomandazioni delle best practice, per
esempio:
1) le password non sono basate su qualcosa che qualcun altro può facilmente
indovinare o ottenere usando informazioni relative alla persona (per esempio
nomi, numeri di telefono e date di nascita);
2) le password non sono basate su parole del dizionario o loro combinazioni;
3) sono utilizzate passphrase facili da ricordare e si cerca di includere caratteri
alfanumerici e speciali;
4) le password hanno una lunghezza minima;
d) le stesse password non sono utilizzate su servizi e sistemi distinti;
e) l'obbligo di attenersi a tali regole è incluso anche nei termini e condizioni di impiego
(vedere 6.2).
Sistema di gestione delle password
Quando le password vengono utilizzate come informazioni di autenticazione, il sistema di
gestione delle password dovrebbe:
a) consentire agli utenti di selezionare e cambiare le proprie password e includere una
procedura di conferma per correggere gli errori di inserimento;
b) applicare password complesse secondo le raccomandazioni delle buone pratiche
[vedere c) di "Responsabilità degli utenti”];
c) obbligare gli utenti a cambiare le proprie password al primo accesso;

d) imporre il cambio della password se necessario, per esempio dopo un incidente di
sicurezza, o al termine o al cambio del rapporto di lavoro di un utente a conoscenza
di password relative a identità che rimangono attive (per esempio identità condivise);
e) impedire il riutilizzo delle password precedenti;
f) impedire l'uso di password di uso comune e nomi utente compromessi, combinazioni
di password da sistemi compromessi;
g) non visualizzare le password sullo schermo al momento dell'inserimento;
h) memorizzare e trasmettere le password in forma protetta.
La cifratura e l'hash delle password dovrebbero essere eseguite secondo tecniche di
crittografia approvate per le password (vedere 8.24).
Altre informazioni
Le password o le passphrase sono un tipo di informazioni di autenticazione comunemente
utilizzato e sono un mezzo comune per verificare l'identità di un utente. Altri tipi di
informazioni di autenticazione sono le chiavi crittografiche, i dati memorizzati su token
hardware (per esempio smart card) che producono codici di autenticazione e i dati
biometrici come scansioni dell'iride o impronte digitali. Ulteriori informazioni possono
essere trovate nelle norme della serie ISO/IEC 24760.
Richiedere un cambio frequente delle password può essere problematico perché gli utenti
possono essere infastiditi dai cambiamenti frequenti, dimenticare le nuove password,
annotarle in luoghi non sicuri o scegliere password non sicure. L'uso di strumenti di single
sign on (SSO) o altri di gestione dell'autenticazione (per esempio password vault) riduce
la quantità di informazioni di autenticazione che gli utenti dovrebbero proteggere e può
quindi aumentare l'efficacia di questo controllo. Tuttavia, questi strumenti possono anche
aumentare gli impatti conseguenti alla perdita di riservatezza delle informazioni di
autenticazione.
Alcune applicazioni richiedono che le password utente siano assegnate da un'autorità
indipendente. In tali casi non si applicano i punti a), c) e d) del paragrafo “Sistema di
gestione delle password”.
5.18 Diritti d’accesso

#Integrity
#Availability
Controllo
I diritti di accesso alle informazioni e agli altri asset relativi dovrebbero essere forniti,
riesaminati, modificati e rimossi in accordo con la politica specifica e le regole per il
controllo degli accessi dell'organizzazione.
Finalità
Assicurare che l'accesso alle informazioni e agli altri asset relativi sia definito e
autorizzato in accordo con i requisiti di business.
Guida
Assegnazione e revoca dei diritti di accesso
Il processo di assegnazione e revoca dei diritti di accesso fisico e logico concessi
all'identità autenticata di un'entità dovrebbe includere:
a) ottenere l'autorizzazione dal responsabile delle informazioni e degli altri asset relativi per
l'utilizzo delle informazioni e degli altri asset relativi (vedere 5.9). Può essere opportuna
anche un'approvazione separata, da parte dei manager, per i diritti di accesso;
b) considerare i requisiti di business e la politica specifica dell'organizzazione e le
regole per il controllo degli accessi;

c) considerare la separazione dei compiti, inclusa la separazione dei ruoli di
approvazione e implementazione dei diritti di accesso e la separazione dei ruoli
conflittuali;
d) assicurare che i diritti di accesso siano rimossi quando qualcuno non ha bisogno di
accedere alle informazioni e agli altri asset relativi, in particolare l’assicurare che i
diritti di accesso degli utenti che hanno lasciato l'organizzazione siano rimossi in
modo tempestivo;
e) considerare di concedere diritti di accesso temporaneo per un periodo di tempo
limitato e di revocarli alla data di scadenza, in particolare per il personale
temporaneo o per gli accessi temporanei richiesti dal personale;
f) verificare che il livello di accesso concesso sia conforme alle politiche specifiche per
il controllo degli accessi (vedere 5.15) e sia coerente con altri requisiti di sicurezza
delle informazioni quali la separazione dei compiti (vedere 5.3);
g) assicurare che i diritti di accesso siano attivati (per esempio da parte dei fornitori di
servizi) solo dopo che le procedure di autorizzazione siano state espletate con
successo;
h) mantenere un registro centrale dei diritti di accesso concessi a un ID utente (logico
o fisico) per accedere alle informazioni e agli altri asset relativi;
i) cambiare i diritti di accesso degli utenti che hanno cambiato ruolo o mansione;
j) rimuovere o adeguare i diritti di accesso fisico e logico; la rimozione o adeguamento
può avvenire mediante rimozione, revoca o sostituzione di chiavi, informazioni di
autenticazione, tessere identificative o sottoscrizioni;
k) mantenere un registro dei cambiamenti ai diritti di accesso logico e fisico degli utenti.
Riesame dei diritti di accesso
Riesami regolari dei diritti di accesso fisico e logico dovrebbero considerare quanto
segue:
a) i diritti di accesso degli utenti dopo qualsiasi cambiamento all'interno della stessa
organizzazione (per esempio cambio di lavoro, promozione, retrocessione) o
cessazione del rapporto di lavoro (vedere da 6.1 a 6.5);
b) le autorizzazioni per i diritti di accesso privilegiato.
Considerazione prima del cambiamento o della cessazione del rapporto di impiego
I diritti di accesso di un utente alle informazioni e agli altri asset relativi dovrebbero essere
riesaminati, adeguati o rimossi prima di qualsiasi cambiamento o cessazione del rapporto
di impiego in base alla valutazione di fattori di rischio quali:
a) se la cessazione o il cambiamento sono disposti dall'utente o dall’organizzazione e
il motivo della cessazione;
b) le attuali responsabilità degli utenti;
c) il valore degli asset attualmente accessibili.
Altre informazioni
Si dovrebbe considerare di stabilire i ruoli per l’accesso degli utenti basati sui requisiti di
business che riassumano un insieme di diritti di accesso in profili tipici di accesso degli
utenti. Le richieste di accesso e i riesami dei diritti di accesso sono gestiti più facilmente
a livello di tali ruoli che a livello di diritti particolari.
Dovrebbe essere presa in considerazione l'inclusione di clausole nei contratti con il
personale e nei contratti di servizio che specifichino sanzioni in caso di tentativo di
accesso non autorizzato da parte del personale (vedere 5.20, 6.2, 6.4, 6.6).
In caso di cessazione avviata dalla direzione, il personale scontento o gli utenti esterni
possono corrompere deliberatamente le informazioni o sabotare le strutture di
elaborazione delle informazioni. In caso di dimissioni o licenziamento, le persone possono
essere tentate di raccogliere informazioni per un uso futuro.

La clonazione è un modo efficiente per le organizzazioni per assegnare l'accesso agli
utenti. Tuttavia, dovrebbe essere fatto con attenzione sulla base di ruoli distinti identificati
dall'organizzazione piuttosto che semplicemente clonare un'identità con tutti i diritti di
accesso associati. La clonazione comporta il rischio intrinseco di avere come risultato
diritti di accesso eccessivi alle informazioni e agli altri asset relativi.
5.19 Sicurezza delle informazioni nelle relazioni con i fornitori
Tipo di Proprietà di Concetti di Capacità operative Domini di sicurezza

controllo sicurezza delle cybersecurity
informazioni
#Preventive #Confidentiality #Identify #Supplier_relationships_security #Governance_and_Ecosystem
#Availability
Controllo
Dovrebbero essere stabiliti e implementati processi e procedure per gestite i rischi della
sicurezza delle informazioni associati all’utilizzo di prodotti o servizi del fornitore.
Finalità
Mantenere nelle relazioni con i fornitori un livello concordato di sicurezza delle
informazioni.
Guida
L'organizzazione dovrebbe stabilire e comunicare una politica specifica per le relazioni
con i fornitori a tutte le parti interessate pertinenti.
L'organizzazione dovrebbe identificare e implementare processi e procedure per
affrontare i rischi relativi alla sicurezza associati all'uso di prodotti e servizi forniti da
fornitori. Ciò dovrebbe valere anche per l'utilizzo da parte dell'organizzazione delle risorse
di fornitori di servizi cloud. Tali processi e procedure dovrebbero includere quelli che
devono essere implementati dall'organizzazione, nonché quelli che l'organizzazione
richiede al fornitore di implementare per iniziare a usare i prodotti o i servizi di un fornitore
o per cessare di usare i prodotti e servizi di un fornitore, come:
a) identificare e documentare le tipologie di fornitori (per esempio servizi ICT, logistica,
infrastrutture, servizi economici, componenti di infrastrutture ICT) che possono
influire sulla riservatezza, sull'integrità e sulla disponibilità delle informazioni
dell'organizzazione;
b) stabilire come valutare e selezionare i fornitori in base alla sensibilità delle
informazioni, dei prodotti e dei servizi (per esempio con analisi di mercato, referenze
dei clienti, riesami di documenti, valutazioni in loco, certificazioni);
c) valutare e selezionare i prodotti o servizi del fornitore che dispongono di adeguati
controlli per la sicurezza delle informazioni e riesaminarli; in particolare,
l'accuratezza e la completezza dei controlli attuati dal fornitore che assicurano
l'integrità delle informazioni del fornitore e dell'elaborazione delle informazioni e
quindi la sicurezza delle informazioni dell'organizzazione;
d) definire le informazioni dell'organizzazione, i servizi ICT e l'infrastruttura fisica a cui i
fornitori possono accedere e che possono monitorare, controllare o utilizzare;
e) definire le tipologie dei componenti dell'infrastruttura ICT e dei servizi forniti dai
fornitori che possono influire sulla riservatezza, sull’integrità e sulla disponibilità
delle informazioni dell'organizzazione;
f) valutare e gestire i rischi relativi alla sicurezza delle informazioni connessi a:
1) l'uso da parte dei fornitori delle informazioni e degli altri asset relativi
dell'organizzazione, inclusi i rischi derivanti da eventuale personale
malintenzionato del fornitore;
2) malfunzionamenti o vulnerabilità dei prodotti (inclusi componenti e
sottocomponenti software utilizzati in tali prodotti) o servizi forniti dai fornitori;

g) monitorare la conformità ai requisiti di sicurezza delle informazioni stabiliti per
ciascun tipo di fornitore e tipo di accesso, includendo riesami di terze parti e
validazioni di prodotto;
h) mitigare le non conformità di un fornitore, se rilevate attraverso il monitoraggio o con
altri mezzi;
i) gestire gli incidenti e le situazioni di contingenza associati a prodotti e servizi dei
fornitori, comprese le responsabilità sia dell'organizzazione sia dei fornitori;
j) misure di resilienza e, se necessario, di ripristino e di contingenza per assicurare la
disponibilità delle informazioni del fornitore e l'elaborazione delle informazioni e
quindi la disponibilità delle informazioni dell'organizzazione;
k) consapevolezza e formazione per il personale dell'organizzazione che interagisce
con il personale del fornitore in merito a idonee regole di ingaggio, politiche
specifiche, processi e procedure specifiche e comportamenti basati sul tipo di
fornitore e sul livello di accesso del fornitore ai sistemi e alle informazioni
l) gestire il necessario trasferimento di informazioni, degli altri asset relativi e
quant'altro debba essere cambiato e assicurare che la sicurezza delle informazioni
sia mantenuta durante tutto il trasferimento;
m) requisiti per assicurare una conclusione sicura del rapporto con il fornitore, tra cui:
1) revoca dei diritti di accesso;
2) trattamento delle informazioni;
3) determinazione della titolarità della proprietà intellettuale di quanto sviluppato
durante l'incarico;
4) portabilità delle informazioni in caso di cambio del fornitore o internalizzazione;
6) gestione delle registrazioni;
7) restituzione degli asset;
8) dismissione sicura delle informazioni e degli altri asset relativi;
9) requisiti di riservatezza permanenti;
n) livello di sicurezza del personale e sicurezza fisica atteso da parte del personale e
dalle strutture del fornitore.
Dovrebbero essere considerate le procedure per proseguire l'elaborazione delle
informazioni nel caso in cui il fornitore non sia in grado di fornire i propri prodotti o servizi
(per esempio a causa di un incidente, perché il fornitore non svolge più quell’attività o non
fornisce più alcuni componenti a causa dei progressi tecnologici) per evitare qualsiasi
ritardo nell'organizzare la sostituzione di prodotti o servizi (per esempio identificare in
anticipo un fornitore alternativo o utilizzare sempre fornitori alternativi).
Altre informazioni
Nei casi in cui non sia possibile per un'organizzazione imporre requisiti a un fornitore,
l’organizzazione dovrebbe:
a) considerare la guida fornita nell’elenco precedente nel prendere decisioni sulla
scelta di un fornitore e del suo prodotto o servizio;
b) attuare, a seconda delle necessità, controlli compensativi sulla base di una
valutazione del rischio.
Le informazioni possono essere messe a rischio da fornitori con una gestione inadeguata
della sicurezza delle informazioni. I controlli dovrebbero essere determinati e applicati per
gestire l'accesso del fornitore alle informazioni e agli altri asset relativi. Per esempio, se vi
è una particolare esigenza di riservatezza delle informazioni, possono essere utilizzati
accordi di non divulgazione o tecniche crittografiche. Un altro esempio sono i rischi relativi
alla protezione dei dati personali quando l'accordo con il fornitore prevede il trasferimento
o l'accesso transfrontalieri a informazioni. L'organizzazione dovrebbe essere
consapevole che la responsabilità legale o contrattuale della protezione delle informazioni
rimane in capo all'organizzazione stessa.

I rischi possono anche essere causati da controlli inadeguati dei componenti
dell'infrastruttura ICT o dei servizi forniti dai fornitori. Componenti o servizi malfunzionanti
o vulnerabili possono causare violazioni relative alla sicurezza delle informazioni
nell'organizzazione o in un'altra entità (per esempio possono causare infezioni da
malware, attacchi o altri danni a entità diverse dall'organizzazione).
Vedere ISO/IEC 27036-2 per maggiori dettagli.
5.20 Sicurezza delle informazioni negli accordi con i fornitori

informazioni
#Availability
Controllo
I requisiti di sicurezza delle informazioni pertinenti dovrebbero essere stabiliti e concordati
con ciascun fornitore in base al tipo di rapporto con il fornitore.
Finalità
Nelle relazioni con i fornitori mantenere un livello concordato di sicurezza delle
informazioni.
Guida
Gli accordi con i fornitori dovrebbero essere stabiliti e documentati per assicurare che vi
sia una chiara comprensione tra l'organizzazione e il fornitore in merito agli obblighi di
entrambe le parti relativi al soddisfacimento dei pertinenti requisiti di sicurezza delle
informazioni.
I seguenti termini possono essere presi in considerazione per includerli negli accordi al
fine di soddisfare i requisiti di sicurezza delle informazioni individuati:
a) descrizione delle informazioni da fornire o alle quali accedere e le loro modalità di
fornitura o di accesso;
b) classificazione delle informazioni secondo lo schema di classificazione
dell'organizzazione (vedere 5.10, 5.12, 5.13);
c) mappatura tra lo schema di classificazione dell'organizzazione e lo schema di
classificazione del fornitore;
d) requisiti legali, statutari, regolamentari e contrattuali, che includono la protezione dei
dati, il trattamento dei dati personali, i diritti di proprietà intellettuale e il diritto
d'autore, e una descrizione di come sarà assicurato il loro rispetto;
e) obbligo di ciascuna parte contrattuale di attuare un insieme concordato di controlli,
inclusi il controllo degli accessi, il riesame delle prestazioni, il monitoraggio, la
rendicontazione e l'audit, e gli obblighi del fornitore di conformarsi ai requisiti di
sicurezza delle informazioni dell'organizzazione;
f) regole per l'uso accettabile delle informazioni e degli altri asset relativi, compreso
l'uso inaccettabile se necessario;
g) procedure o condizioni per l'autorizzazione e la revoca delle autorizzazioni all'utilizzo
delle informazioni dell'organizzazione e degli altri asset relativi da parte del
personale del fornitore (per esempio attraverso un elenco del personale del fornitore
esplicitamente autorizzato all'uso delle informazioni dell'organizzazione e degli altri
asset relativi);
h) requisiti di sicurezza delle informazioni riguardanti l'infrastruttura ICT del fornitore; in
particolare, requisiti minimi di sicurezza delle informazioni per ogni tipo di
informazione e tipo di accesso che servano come base per accordi individuali con i
fornitori in base alle esigenze di business e ai criteri di rischio dell'organizzazione;
i) risarcimenti e rimedi al mancato rispetto dei requisiti da parte del fornitore;

j) requisiti e procedure per la gestione degli incidenti (in particolare la notifica e la
collaborazione durante la risoluzione degli incidenti);
k) requisiti di formazione e di consapevolezza su procedure specifiche e requisiti di
sicurezza delle informazioni (per esempio per la risposta agli incidenti, procedure di
autorizzazione);
l) disposizioni pertinenti per il subappalto, compresi i controlli che dovrebbero essere
attuati, come l'accordo sull'utilizzo dei subfornitori (per esempio richiedendo che
siano soggetti agli stessi obblighi del fornitore, richiedendo di avere un elenco di
sub-fornitori e notifica prima di qualsiasi cambiamento);
m) contatti pertinenti, compreso un referente per questioni di sicurezza delle
informazioni;
n) eventuali requisiti di screening, ove legalmente consentito, per il personale del
fornitore, comprese le responsabilità per lo svolgimento delle procedure di screening
e di notifica se lo screening non è stato completato o se i risultati danno adito a dubbi
o preoccupazioni;
o) le evidenze e i meccanismi di garanzia delle attestazioni di terze parti per i requisiti
di sicurezza delle informazioni pertinenti relativi ai processi dei fornitori e un rapporto
indipendente sull'efficacia dei controlli;
p) diritto di effettuare audit di processi e di controlli del fornitore connessi all'accordo;
q) l'obbligo del fornitore di fornire periodicamente un rapporto sull'efficacia dei controlli
e l'accordo sulla tempestiva correzione delle questioni pertinenti sollevate nel
rapporto;
r) processi di risoluzione dei difetti e di risoluzione dei conflitti;
s) fornitura di backup allineati alle esigenze dell'organizzazione (in termini di
frequenza, tipologia e luogo di archiviazione);
t) assicurazione della disponibilità di una struttura alternativa (ossia un sito di disaster
recovery) non soggetta alle stesse minacce della struttura principale e
considerazioni sui controlli di riserva (controlli alternativi) in caso di fallimento dei
controlli primari;
u) messa a disposizione di un processo di gestione dei cambiamenti che assicuri la
notifica preventiva all'organizzazione e la possibilità per l'organizzazione di non
accettare i cambiamenti;
v) controlli per la sicurezza fisica commisurati alla classificazione delle informazioni;
w) controlli sul trasferimento delle informazioni per proteggere le informazioni durante il
trasferimento fisico o la trasmissione elettronica;
x) clausole risolutive alla conclusione del contratto, inclusa la gestione delle
registrazioni, la restituzione degli asset, lo smaltimento sicuro delle informazioni e
degli altri asset relativi e qualsiasi obbligo di riservatezza permanente;
y) fornitura di un metodo per distruggere in modo sicuro le informazioni
dell'organizzazione memorizzate dal fornitore non appena non sono più necessarie;
z) assicurazione, al termine del contratto, supporto per il passaggio di consegne ad
altro fornitore o all'organizzazione stessa.
Le organizzazioni dovrebbero stabilire e mantenere un registro degli accordi con parti
esterne (per esempio contratti, memorandum d'intesa, accordi di condivisione delle
informazioni) per tenere traccia di dove si trovano le loro informazioni. Le organizzazioni
dovrebbero inoltre riesaminare, convalidare e aggiornare regolarmente i loro accordi con
le parti esterne per assicurare che siano ancora necessari e idonei alle pertinenti clausole
di sicurezza delle informazioni.
Altre informazioni
Gli accordi possono variare considerevolmente per le diverse organizzazioni e tra i diversi
tipi di fornitori. Pertanto, occorre prestare attenzione affinché siano inclusi tutti i requisiti
pertinenti per affrontare i rischi relativi alla sicurezza delle informazioni.
Per i dettagli sugli accordi con i fornitori, vedere la serie ISO/IEC 27036. Per i contratti di
servizio del cloud, vedere la serie ISO/IEC 19086.

5.21 Gestione della sicurezza delle informazioni nella filiera di fornitura per l’ICT

informazioni
#Availability
Controllo
Dovrebbero essere definiti e attuati processi e procedure per gestire i rischi relativi alla
sicurezza delle informazioni associati alla filiera di fornitura di prodotti e servizi ICT.
Finalità
Mantenere, nelle relazioni con i fornitori, un livello concordato di sicurezza delle
informazioni.
Guida
In aggiunta ai requisiti generali di sicurezza delle informazioni nei rapporti con i fornitori, i
seguenti argomenti dovrebbero essere considerati per affrontare la sicurezza delle
informazioni nell'ambito della sicurezza nella filiera di fornitura per l’ICT:
a) definire i requisiti di sicurezza delle informazioni da applicare all'acquisizione di
prodotti o servizi ICT;
b) richiedere che i fornitori di servizi ICT propaghino i requisiti di sicurezza
dell'organizzazione lungo tutta la filiera di fornitura se subappaltano parti dei servizi
ICT forniti all'organizzazione;
c) richiedere che i fornitori di prodotti ICT propaghino pratiche di sicurezza adeguate
lungo tutta la filiera di fornitura se tali prodotti includono componenti acquistati o
acquisiti da altri fornitori o altri enti (per esempio sviluppatori software in sub-appalto
e fornitori di componenti hardware);
d) richiedere ai fornitori di prodotti ICT di fornire informazioni che descrivano i
componenti software utilizzati nei prodotti;
e) richiedere ai fornitori di prodotti ICT di fornire informazioni che descrivano le funzioni
di sicurezza attuate dal loro prodotto e la configurazione richiesta per il suo
funzionamento sicuro;
f) attuare un processo di monitoraggio e metodi accettabili per validare il fatto che i
prodotti e servizi ICT forniti sono conformi ai requisiti di sicurezza dichiarati. Esempi
di tali metodi di riesame dei fornitori possono includere penetration test e prove o
validazioni di attestazioni di terze parti per l’esercizio della sicurezza delle
informazioni del fornitore;
g) attuare un processo per identificare e documentare i componenti, di prodotti o
servizi, critici per mantenere la funzionalità e che pertanto richiedono maggiore
attenzione, esame e ulteriore verifica di controllo quando realizzati al di fuori
dell'organizzazione, soprattutto se il fornitore esternalizza componenti di prodotti o
servizi ad altri fornitori;
h) ottenere l'assicurazione che i componenti critici e la loro origine possano essere
rintracciati lungo tutta la filiera di fornitura;
i) ottenere l'assicurazione che i prodotti ICT consegnati funzionino come previsto
senza alcuna caratteristica imprevista o indesiderata;
j) attuare processi per assicurare che i componenti dei fornitori siano autentici e
inalterati rispetto alle loro specifiche. Esempi di misure includono etichette contro la
manomissione, verifiche attraverso hash crittografici o firme digitali. Il monitoraggio
di prestazioni al di fuori delle specifiche può essere un indicatore di manomissioni o
contraffazioni. La prevenzione e il rilevamento delle manomissioni dovrebbero
essere attuati in più fasi del ciclo di vita dello sviluppo del sistema, compresa la
progettazione, lo sviluppo, l'integrazione, l’esercizio e la manutenzione;

k) ottenere l'assicurazione che i prodotti ICT raggiungano i livelli di sicurezza richiesti,
per esempio attraverso una certificazione formale o uno schema di valutazione
come il Common Criteria Recognition Arrangement;
l) definire regole per la condivisione delle informazioni relative alla filiera di fornitura ed
eventuali questioni e compromessi tra l’organizzazione e i fornitori;
m) attuare processi specifici per la gestione del ciclo di vita e della disponibilità dei
componenti ICT e dei relativi rischi relativi alla sicurezza. Ciò include la gestione dei
rischi relativi ai componenti non più disponibili a causa del fatto che i fornitori non
sono più in attività o a causa di fornitori che non forniscono più questi componenti a
causa dei progressi tecnologici. Dovrebbero essere presi in considerazione
l'identificazione di un fornitore alternativo e il processo per trasferire software e
competenze al fornitore alternativo.
Altre informazioni
Le pratiche di gestione del rischio specifico relativo alla filiera di fornitura ICT si basano
sulla sicurezza delle informazioni generale, sulla qualità, sulla gestione dei progetti e sulle
pratiche di ingegneria dei sistemi, ma non le sostituiscono.
Si consiglia alle organizzazioni di collaborare con i fornitori per comprendere la filiera di
fornitura ICT e qualsiasi questione che abbia un effetto importante sui prodotti e servizi
forniti. L'organizzazione può influenzare le pratiche di sicurezza delle informazioni della
filiera di fornitura ICT chiarendo, negli accordi con i propri fornitori, le questioni che
dovrebbero essere affrontate da altri fornitori nella filiera di fornitura ICT.
I servizi e prodotti ICT dovrebbero essere acquisiti da fonti affidabili. L'affidabilità del
software e dell'hardware è un argomento che fa parte del controllo della qualità. Sebbene,
in genere, non sia possibile per un'organizzazione ispezionare i sistemi di controllo della
qualità dei propri fornitori, può esprimere giudizi affidabili basati sulla reputazione del
fornitore.
Le filiere di fornitura ICT qui trattate includono i servizi cloud.
Esempi di filiere di fornitura ICT sono:
a) fornitura di servizi cloud, laddove il fornitore di servizi cloud si affida a sviluppatori
software, fornitori di servizi di telecomunicazione, fornitori di hardware;
b) IoT, dove il servizio coinvolge i produttori di dispositivi, i fornitori di servizi cloud (per
esempio gli operatori di piattaforme IoT), gli sviluppatori di applicazioni mobili e web,
i fornitori di librerie software;
c) servizi di hosting, dove il fornitore si avvale di service desk esterni comprensivi di
primo, secondo e terzo livello di supporto.
Vedere ISO/IEC 27036-3 per maggiori dettagli, inclusa una guida alla valutazione del
rischio.
I tag di identificazione del software (SWID) possono anche aiutare a ottenere una migliore
sicurezza delle informazioni nella filiera di fornitura, fornendo informazioni sulla
provenienza del software. Vedere ISO/IEC 19770-2 per maggiori dettagli.
5.22 Monitoraggio, riesame e gestione dei cambiamenti dei servizi dei fornitori

informazioni
#Integrity #Information_security_assurance #Protection
#Availability #Defence
Controllo
L'organizzazione dovrebbe monitorare, riesaminare, valutare e gestire regolarmente i
cambiamenti nelle pratiche di sicurezza delle informazioni dei fornitori e nell'erogazione
dei servizi.

Finalità
Mantenere un livello concordato di sicurezza delle informazioni e di fornitura dei servizi in
linea con gli accordi con i fornitori.
Guida
Il monitoraggio, il riesame e la gestione dei cambiamenti dei servizi dei fornitori
dovrebbero assicurare che i termini e le condizioni degli accordi relativi alla sicurezza
delle informazioni siano rispettati, gli incidenti e i problemi di sicurezza delle informazioni
siano gestiti correttamente e i cambiamenti ai servizi dei fornitori o allo stato del business
non influiscano sull'erogazione dei servizi.
Ciò dovrebbe comportare un processo per gestire la relazione tra l'organizzazione e il
fornitore per:
a) monitorare i livelli di prestazione dei servizi per verificarne la conformità agli accordi;
b) monitorare i cambiamenti apportati dai fornitori tra cui:
1) potenziamenti degli attuali servizi offerti;
2) sviluppo di nuove applicazioni e sistemi;
3) cambiamenti o aggiornamenti delle politiche e procedure del fornitore;
4) controlli nuovi o cambiati per risolvere gli incidenti relativi alla sicurezza delle
informazioni e per migliorare la sicurezza delle informazioni;
c) monitorare i cambiamenti nei servizi dei fornitori, tra cui:
1) cambiamenti e potenziamento delle reti;
2) uso di nuove tecnologie;
3) adozione di nuovi prodotti o versioni o release più recenti;
4) nuovi strumenti e ambienti di sviluppo;
5) cambiamenti all'ubicazione fisica delle strutture usate per il servizio;
6) cambio di subfornitori;
7) subappalto ad altro fornitore;
d) riesaminare i rapporti di servizio prodotti dal fornitore e organizzare riunioni
periodiche di avanzamento come previsto dagli accordi;
e) condurre audit presso i fornitori e subfornitori, unitamente al riesame dei rapporti di
audit indipendenti, se disponibili, e controllo delle questioni individuate;
f) fornire informazioni sugli incidenti relativi alla sicurezza delle informazioni e
riesaminare tali informazioni come richiesto dagli accordi e da eventuali linee guida
e procedure di supporto;
g) riesaminare gli audit trail dei fornitori e le registrazioni di eventi relativi alla sicurezza
delle informazioni, problemi operativi, guasti, tracciamento di guasti e interruzioni
relativamente al servizio erogato;
h) rispondere e gestire qualsiasi evento o incidente relativo alla sicurezza delle
informazioni identificato;
i) identificare le vulnerabilità relative alla sicurezza delle informazioni e gestirle;
j) riesaminare gli aspetti di sicurezza delle informazioni nelle relazioni del fornitore con
i propri fornitori;
k) assicurare che il fornitore mantenga una capacità di servizio sufficiente, insieme a
piani attuabili volti ad assicurare che i livelli di continuità del servizio concordati siano
mantenuti a seguito di gravi guasti o disastri relativi al servizio (vedere 5.29, 5.30,
5.35, 5.36, 8.14);
l) assicurare che i fornitori assegnino responsabilità per la verifica della conformità e
l'applicazione dei requisiti degli accordi;
m) valutare periodicamente se i fornitori mantengono adeguati livelli di sicurezza delle
informazioni.

La responsabilità della gestione delle relazioni con i fornitori dovrebbe essere assegnata
a un individuo o un gruppo designato. Dovrebbero essere messe a disposizione
competenze e risorse tecniche sufficienti per controllare che i requisiti degli accordi, in
particolare i requisiti di sicurezza delle informazioni, siano soddisfatti. Quando si
osservano carenze nell'erogazione del servizio, dovrebbero essere intraprese le azioni
appropriate.
Altre informazioni
Vedere ISO/IEC 27036-3 per maggiori dettagli.
5.23 Sicurezza delle informazioni per l'utilizzo di servizi cloud

#Preventive #Confidentiality #Protect #Supplier_relationships_security #Governance_and_Ecosystem
#Availability
Controllo
I processi per l'acquisizione, l'utilizzo, la gestione e l'uscita dai servizi cloud dovrebbero
essere stabiliti in conformità con i requisiti di sicurezza delle informazioni
Finalità
Specificare e gestire la sicurezza delle informazioni per l'utilizzo dei servizi cloud.
Guida
L'organizzazione dovrebbe stabilire e comunicare una politica specifica per l'uso dei
servizi cloud a tutte le parti interessate pertinenti.
L'organizzazione dovrebbe definire e comunicare come intende gestire i rischi relativi alla
sicurezza delle informazioni e associati all'uso dei servizi cloud. Può essere
un'estensione o una parte dell'approccio già esistente e relativo al modo in cui
un'organizzazione gestisce i servizi forniti da soggetti esterni (vedere 5.21 e 5.22).
L'uso dei servizi cloud può comportare una responsabilità condivisa per la sicurezza delle
informazioni e uno sforzo collaborativo tra il fornitore di servizi cloud e l'organizzazione
che agisce come cliente del servizio cloud. È essenziale che le responsabilità sia del
fornitore di servizi cloud sia dell'organizzazione, che agisce in qualità di cliente del
servizio cloud, siano definite e attuate in modo appropriato.
L'organizzazione dovrebbe definire:
a) tutti i requisiti di sicurezza delle informazioni pertinenti e associati all'utilizzo dei
servizi cloud;
b) i criteri di selezione dei servizi cloud e l’ambito di utilizzo dei servizi cloud;
c) i ruoli e le responsabilità relativi all'utilizzo e alla gestione dei servizi cloud;
d) quali controlli per la sicurezza delle informazioni sono gestiti dal fornitore di servizi
cloud e quali sono gestiti dall'organizzazione in qualità di cliente dei servizi cloud;
e) come ottenere e utilizzare le funzionalità di sicurezza delle informazioni messe a
disposizione dal fornitore di servizi cloud;
f) come ottenere assicurazioni sui controlli per la sicurezza delle informazioni attuati
dai fornitori di servizi cloud;
g) come gestire i controlli, le interfacce e i cambiamenti ai servizi quando
un'organizzazione utilizza più servizi cloud, in particolare da diversi fornitori di servizi
cloud;
h) procedure per la gestione degli incidenti relativi alla sicurezza delle informazioni che
si verificano in relazione all'utilizzo dei servizi cloud;
i) il proprio approccio per monitorare, riesaminare e valutare l'uso nel tempo dei servizi
cloud per gestire i rischi relativi alla sicurezza delle informazioni;

j) come cambiare o interrompere l'utilizzo dei servizi cloud, comprendendo le strategie
di uscita per i servizi cloud.
I contratti per i servizi cloud sono spesso predefiniti e non negoziabili. Per tutti i servizi
cloud, l'organizzazione dovrebbe riesaminare i contratti per i servizi cloud con i fornitori di
servizi cloud. Un contratto per i servizi cloud dovrebbe soddisfare i requisiti di
riservatezza, integrità, disponibilità e trattamento delle informazioni dell'organizzazione,
con appropriati obiettivi per i livelli dei servizi cloud e obiettivi qualitativi dei servizi cloud.
L'organizzazione dovrebbe inoltre intraprendere pertinenti valutazioni del rischio per
identificare i rischi associati all'utilizzo dei servizi cloud. Eventuali rischi residui connessi
all'utilizzo dei servizi cloud dovrebbero essere chiaramente identificati e accettati dalla
direzione dell'organizzazione.
Un accordo tra il fornitore di servizi cloud e l'organizzazione, che agisce in qualità di
cliente del servizio cloud, dovrebbe includere le seguenti disposizioni per la protezione dei
dati dell'organizzazione e la disponibilità dei servizi:
a) fornire soluzioni basate su standard accettati dal settore per l'architettura e
l'infrastruttura;
b) gestire i controlli di accesso al servizio cloud per soddisfare i requisiti
c) attuare soluzioni di monitoraggio e protezione da malware;
d) elaborare e conservare le informazioni sensibili dell'organizzazione in luoghi
approvati (per esempio un particolare Paese o regione) o all'interno di o soggetti a
una particolare giurisdizione;
e) fornire un supporto dedicato in caso di incidenti relativi alla sicurezza delle
informazioni nell'ambiente del servizio cloud;
f) assicurare che i requisiti di sicurezza delle informazioni dell'organizzazione siano
soddisfatti in caso di ulteriore subappalto dei servizi cloud a un fornitore esterno (o
vietare il subappalto dei servizi cloud);
g) supportare l'organizzazione nella raccolta di prove digitali, tenendo conto delle leggi
e dei regolamenti per le prove digitali nelle diverse giurisdizioni;
h) fornire un adeguato supporto e la disponibilità dei servizi per un arco di tempo
adeguato quando l'organizzazione vuole uscire dal servizio cloud;
i) fornire il backup richiesto dei dati e delle informazioni di configurazione e gestire in
modo sicuro i backup ove applicabile, in base alle funzionalità del fornitore di servizi
cloud usate dall'organizzazione, che agisce in qualità di cliente del servizio cloud;
j) fornire e restituire informazioni, quali file di configurazione, codice sorgente e dati,
che sono di proprietà dell'organizzazione, in qualità di cliente del servizio cloud,
quando richiesto durante l'erogazione del servizio o alla cessazione del servizio.
L'organizzazione, in qualità di cliente del servizio cloud, dovrebbe valutare se l'accordo
dovrebbe richiedere ai fornitori di servizi cloud di fornire una notifica anticipata prima che
qualsiasi cambiamento sostanziale che incide sul cliente venga apportata al modo in cui
il servizio viene fornito all'organizzazione, tra cui:
a) cambiamenti all'infrastruttura tecnica (per esempio trasferimento fisico,
riconfigurazione o cambiamenti hardware o software) che influiscono o cambiano
l'offerta dei servizi cloud;
b) elaborazione o conservazione delle informazioni in una nuova giurisdizione
geografica o legale;
c) utilizzo di fornitori di servizi cloud partner o altri subappaltatori (inclusi i cambiamenti
ai soggetti esistenti o l'utilizzo di nuovi soggetti).
L'organizzazione che utilizza i servizi cloud dovrebbe mantenere uno stretto contatto con
i suoi fornitori di servizi cloud. Questi contatti consentono lo scambio reciproco di
informazioni sulla sicurezza delle informazioni per l'utilizzo dei servizi cloud, incluso un
meccanismo sia per il fornitore di servizi cloud sia per l'organizzazione, che agisce come
cliente del servizio cloud, per monitorare ciascuna caratteristica del servizio e segnalare
il mancato rispetto degli impegni contenuti negli accordi.

Altre informazioni
Questo controllo considera la sicurezza del cloud dal punto di vista del cliente del servizio
cloud.
Ulteriori informazioni relative ai servizi cloud sono disponibili nelle ISO/IEC 17788,
ISO/IEC 17789 e ISO/IEC 22123-1. Le specifiche relative alla portabilità del cloud a
supporto delle strategie di uscita possono essere trovate nella ISO/IEC 19941. Le
specifiche relative alla sicurezza delle informazioni e ai servizi cloud pubblici sono
descritte nella ISO/IEC 27017. Le specifiche relative alla protezione dei dati personali nei
cloud pubblici che agiscono come responsabili del trattamento di dati personali sono
descritte nella ISO/IEC 27018. I rapporti con i fornitori per i servizi cloud sono coperti
dalla ISO/IEC 27036-4 e gli accordi di servizio cloud e il loro contenuto sono trattati nella
serie ISO/IEC 19086, con sicurezza e privacy specificamente coperte dalla
ISO/IEC 19086-4.
5.24 Pianificazione e preparazione per la gestione degli incidenti relativi alla sicurezza delle
informazioni
Tipo di controllo Proprietà di Concetti di Capacità operative Domini di

sicurezza delle cybersecurity sicurezza
informazioni
#Corrective #Confidentiality #Respond #Governance #Defence
#Integrity #Recover #Information_security_event_management
#Availability
Controllo
L'organizzazione dovrebbe pianificare e prepararsi per la gestione degli incidenti relativi
alla sicurezza delle informazioni definendo, stabilendo e comunicando processi, ruoli e
responsabilità di gestione degli incidenti relativi alla sicurezza delle informazioni.
Finalità
Assicurare una risposta rapida, efficace, coerente e ordinata agli incidenti relativi alla
sicurezza delle informazioni, inclusa la comunicazione sugli eventi relativi alla sicurezza
delle informazioni.
Guida
Ruoli e responsabilità
L'organizzazione dovrebbe stabilire adeguati processi di gestione degli incidenti relativi
alla sicurezza delle informazioni. I ruoli e le responsabilità per svolgere le procedure di
gestione degli incidenti dovrebbero essere determinati e comunicati in modo efficace alle
parti interessate interne ed esterne pertinenti.
Occorre considerare quanto segue:
a) stabilire un metodo comune per segnalare gli eventi relativi alla sicurezza delle
informazioni, includendo il punto di contatto (vedere 6.8);
b) stabilire un processo di gestione degli incidenti per fornire all'organizzazione la
capacità di gestire gli incidenti relativi alla sicurezza delle informazioni, includendo
l’amministrazione, la documentazione, il rilevamento, il triage, la definizione delle
priorità, l’analisi, la comunicazione e il coordinamento delle parti interessate;
c) stabilire un processo di risposta agli incidenti per fornire all'organizzazione la
capacità di valutare, rispondere e imparare dagli incidenti relativi alla sicurezza delle
informazioni;
d) consentire solo al personale competente di gestire le questioni relative agli incidenti
relativi alla sicurezza delle informazioni all'interno dell'organizzazione. Tale
personale dovrebbe essere dotato di documentazione procedurale e formazione
periodica;
e) stabilire un processo per identificare la formazione richiesta, le certificazioni e lo
sviluppo professionale continuo per il personale di risposta agli incidenti.

Procedure di gestione degli incidenti
Gli obiettivi per la gestione degli incidenti relativi alla sicurezza delle informazioni
dovrebbero essere concordati con la direzione e dovrebbe essere assicurato che i
responsabili della gestione degli incidenti relativi alla sicurezza delle informazioni
comprendano le priorità dell'organizzazione per la gestione degli incidenti relativi alla
sicurezza delle informazioni, compresi i tempi di risoluzione basati sulle potenziali
conseguenze e gravità. Le procedure di gestione degli incidenti dovrebbero essere
attuate per raggiungere questi obiettivi e priorità.
La direzione dovrebbe assicurare che venga creato un piano di gestione degli incidenti
relativi alla sicurezza delle informazioni considerando diversi scenari e procedure
sviluppate e attuate per le seguenti attività:
a) valutazione degli eventi relativi alla sicurezza delle informazioni secondo criteri per
ciò che costituisce un incidente relativo alla sicurezza delle informazioni;
b) monitoraggio (vedere 8.15 e 8.16), rilevazione (vedere 8.16), classificazione (vedere
5.25), analisi e segnalazione (vedere 6.8) di eventi e incidenti relativi alla sicurezza
delle informazioni (con mezzi umani o automatici);
c) gestione degli incidenti relativi alla sicurezza delle informazioni fino alla conclusione,
compresa la risposta e l'escalation (vedere 5.26), in base al tipo e alla categoria
dell'incidente, eventuale attivazione della gestione della crisi e attivazione di piani di
continuità, recupero controllato da un incidente e comunicazione all'interno e ai
soggetti esterni interessati;
d) coordinamento con parti interessate interne ed esterne quali autorità, gruppi di
interesse esterni e forum, fornitori e clienti (vedere 5.5 e 5.6);
e) la registrazione delle attività di gestione degli incidenti;
f) trattamento delle prove digitali (vedere 5.28);
g) analisi della causa principale o procedure post mortem;
h) individuazione delle lezioni apprese ed eventuali miglioramenti alle procedure di
gestione degli incidenti o ai controlli per la sicurezza delle informazioni richiesti.
Procedure di segnalazione
Le procedure di segnalazione dovrebbero includere:
a) azioni da intraprendere in caso di un evento relativo alla sicurezza delle informazioni
(per esempio annotazione immediata di tutti i dettagli pertinenti come
malfunzionamenti che si verificano e messaggi sullo schermo, segnalazione
immediata al punto di contatto e solo azioni coordinate);
b) utilizzo di moduli di incidente per supportare il personale nell'esecuzione di tutte le
azioni necessarie durante la segnalazione di incidenti relativi alla sicurezza delle
informazioni;
c) adeguati processi di feedback per assicurare che le persone che segnalano eventi
relativi alla sicurezza delle informazioni siano informate, per quanto possibile, degli
esiti dopo che la questione è stata affrontata e chiusa;
d) creazione di rapporti di incidente.
Quando si attuano le procedure di gestione degli incidenti, dovrebbero essere presi in
considerazione eventuali requisiti esterni sulla segnalazione degli incidenti alle parti
interessate pertinenti entro il periodo di tempo definito (per esempio obblighi di notifica
delle violazioni alle autorità di regolamentazione).
Altre informazioni
Gli incidenti relativi alla sicurezza delle informazioni possono trascendere i confini
organizzativi e nazionali. Per rispondere a tali incidenti, è utile coordinare la risposta e
condividere le informazioni su questi incidenti con organizzazioni esterne, se del caso.
Una guida dettagliata sulla gestione degli incidenti relativi alla sicurezza delle informazioni
è fornita nella serie ISO/IEC 27035.

5.25 Valutazione e decisione sugli eventi relativi alla sicurezza delle informazioni
Tipo di Proprietà di sicurezza Concetti di Capacità operative Domini di

controllo delle informazioni cybersecurity sicurezza
#Detective #Confidentiality #Detect #Information_security_event_management #Defence
#Integrity #Respond
#Availability
Controllo
L'organizzazione dovrebbe valutare gli eventi relativi alla sicurezza delle informazioni e
decidere se devono essere classificati come incidenti relativi alla sicurezza delle
informazioni.
Finalità
Assicurare una categorizzazione e una prioritizzazione efficaci degli eventi relativi alla
Guida
Dovrebbe essere concordato uno schema di categorizzazione e prioritizzazione degli
incidenti relativi alla sicurezza delle informazioni per l'identificazione delle conseguenze e
della priorità di un incidente. Lo schema dovrebbe includere i criteri per classificare gli
eventi come incidenti relativi alla sicurezza delle informazioni. Il punto di contatto
dovrebbe valutare ogni evento relativo alla sicurezza delle informazioni utilizzando lo
schema concordato.
Il personale responsabile del coordinamento e della risposta agli incidenti relativi alla
sicurezza delle informazioni dovrebbe eseguire la valutazione e prendere una decisione
sugli eventi relativi alla sicurezza delle informazioni.
I risultati della valutazione e della decisione dovrebbero essere registrati in dettaglio a
scopo di riferimento e verifica futuri.
Altre informazioni
ISO/IEC 27035 fornisce ulteriori indicazioni sulla gestione degli incidenti.
5.26 Risposta agli incidenti relativi alla sicurezza delle informazioni
Tipo di controllo Proprietà di sicurezza Concetti di Capacità operative Domini di

delle informazioni cybersecurity sicurezza
#Corrective #Confidentiality #Respond #Information_security_event_management #Defence
#Integrity #Recover
#Availability
Controllo
Gli incidenti relativi alla sicurezza delle informazioni dovrebbero essere risolti secondo le
procedure documentate.
Finalità
Assicurare una risposta efficiente ed efficace agli incidenti relativi alla sicurezza delle
informazioni.
Guida
L'organizzazione dovrebbe stabilire e comunicare procedure sulla risposta agli incidenti
relativi alla sicurezza delle informazioni a tutte le parti interessate pertinenti.
Gli incidenti relativi alla sicurezza delle informazioni dovrebbero essere affrontati da un
gruppo designato con la competenza richiesta (vedere 5.24).
La risposta dovrebbe includere quanto segue:
a) contenere, se le conseguenze dell'incidente possono propagarsi, i sistemi
interessati dall'incidente;

b) raccogliere le prove (vedere 5.28) il prima possibile dopo il verificarsi dell’incidente;
c) escalation, se necessario, comprese le attività di gestione delle crisi ed
eventualmente invocando piani di continuità operativa (vedere 5.29 e 5.30);
d) assicurare che tutte le attività di risposta coinvolte siano adeguatamente registrate
per un'analisi successiva;
e) comunicare l'esistenza dell'incidente relativo alla sicurezza delle informazioni o
qualsiasi dettaglio pertinente dello stesso a tutte le parti interessate interne ed
esterne pertinenti secondo il principio della necessità di conoscere;
f) coordinarsi con soggetti interni ed esterni quali autorità, gruppi di interesse esterni e
forum, fornitori e clienti per migliorare l'efficacia della risposta e contribuire a ridurre
al minimo le conseguenze per altre organizzazioni;
g) una volta affrontato con successo l'incidente, chiuderlo formalmente e registrarlo;
h) condurre analisi forensi sulla sicurezza delle informazioni, come richiesto (vedere 5.28);
i) eseguire un’analisi post-incidente per identificare la causa principale. Assicurarsi
che sia documentata e comunicata secondo procedure definite (vedere 5.27);
j) identificare e gestire le vulnerabilità e i punti deboli della sicurezza delle informazioni,
compresi quelli relativi ai controlli che hanno causato, contribuito o non sono riusciti
a prevenire l'incidente.
Altre informazioni
ISO/IEC 27035 fornisce ulteriori indicazioni sulla gestione degli incidenti.
5.27 Apprendimento dagli incidenti relativi alla sicurezza delle informazioni
Tipo di controllo Proprietà di Concetti di Capacità operative Domini di

sicurezza delle cybersecurity sicurezza
informazioni
#Preventive #Confidentiality #Identify #Information_security_event_management #Defence
#Integrity #Protect
#Availability
Controllo
Le conoscenze acquisite dagli incidenti relativi alla sicurezza delle informazioni
dovrebbero essere utilizzate per rafforzare e migliorare i controlli di sicurezza delle
informazioni.
Finalità
Ridurre la probabilità o le conseguenze di incidenti futuri.
Guida
L'organizzazione dovrebbe stabilire procedure per quantificare e monitorare i tipi, i volumi
e i costi degli incidenti relativi alla sicurezza delle informazioni.
Le informazioni ottenute dalla valutazione degli incidenti relativi alla sicurezza delle
informazioni dovrebbero essere utilizzate per:
a) migliorare il piano di gestione degli incidenti, compresi gli scenari e le procedure
degli incidenti (vedere 5.24);
b) identificare gli incidenti ricorrenti o gravi e le loro cause per aggiornare la valutazione
del rischio relativo alla sicurezza delle informazioni dell'organizzazione e
determinare e attuare i controlli aggiuntivi necessari per ridurre la probabilità o le
conseguenze di futuri incidenti simili. I meccanismi per abilitare ciò includono la
raccolta, la quantificazione e il monitoraggio delle informazioni sui tipi di incidenti, i
volumi e i costi;
c) migliorare la formazione sulla consapevolezza degli utenti (vedere 6.3) fornendo
esempi di cosa può accadere, come rispondere a tali incidenti e come evitarli in
futuro.

Altre informazioni
La serie ISO/IEC 27035 fornisce ulteriori indicazioni.
5.28 Raccolta di prove
Tipo di controllo Proprietà di sicurezza delle Concetti di cybersecurity Capacità operative Domini di sicurezza
informazioni
#Corrective #Confidentiality #Detect #Information_security_event_management #Defence
#Integrity #Respond
#Availability
Controllo
L'organizzazione dovrebbe stabilire e attuare procedure per l'identificazione, la raccolta,
l'acquisizione e la conservazione delle prove relative agli eventi relativi alla sicurezza delle
informazioni.
Finalità
Assicurare una gestione coerente ed efficace delle prove relative agli incidenti relativi alla
sicurezza delle informazioni ai fini di azioni disciplinari e legali.
Guida
Dovrebbero essere sviluppate e seguite procedure interne per quando si trattano prove
relative a eventi relativi alla sicurezza delle informazioni ai fini di azioni disciplinari e legali.
I requisiti delle diverse giurisdizioni dovrebbero essere considerati per massimizzare le
possibilità di ammissione delle prove nelle giurisdizioni pertinenti.
In generale, queste procedure per la gestione delle prove dovrebbero fornire istruzioni per
l'identificazione, la raccolta, l'acquisizione e la conservazione delle prove in base ai diversi
tipi di supporti di memorizzazione, dispositivi e stato dei dispositivi (ossia accesi o spenti).
Le prove in genere dovrebbero essere raccolte in modo ammissibile nei tribunali nazionali
competenti o in un altro foro disciplinare. Dovrebbe essere possibile dimostrare che:
a) le registrazioni sono complete e non sono state in alcun modo manomesse;
b) le copie delle prove elettroniche sono verosimilmente identiche agli originali;
c) qualsiasi sistema informativo da cui sono state raccolte le prove funzionava
correttamente al momento della registrazione delle prove.
Ove disponibile, si dovrebbe richiedere la certificazione del personale o altri mezzi
pertinenti per dimostrare la qualificazione del personale e degli strumenti, in modo da
rafforzare il valore delle prove conservate.
Le prove digitali possono trascendere i confini organizzativi o giurisdizionali. In tali casi,
dovrebbe essere assicurato che l'organizzazione sia autorizzata a raccogliere le
informazioni richieste come prove digitali.
Altre informazioni
Quando un evento relativo alla sicurezza delle informazioni viene rilevato per la prima
volta, non è sempre ovvio se l'evento si tradurrà in un'azione legale. Pertanto esiste il
pericolo che le prove necessarie vengano distrutte intenzionalmente o accidentalmente
prima che si realizzi la gravità dell'incidente. È consigliabile coinvolgere una consulenza
legale o le forze dell'ordine all'inizio di qualsiasi azione legale contemplata e chiedere
consiglio in merito alle prove richieste.
ISO/IEC 27037 fornisce definizioni e linee guida per l'identificazione, la raccolta,
l'acquisizione e la conservazione delle prove digitali.
La serie ISO/IEC 27050 si occupa della ricerca di prove elettroniche, che implica
l'elaborazione di informazioni memorizzate elettronicamente come prove.

5.29 Sicurezza delle informazioni durante le interruzioni
informazioni
#Preventive #Confidentiality #Protect #Continuity #Protection
#Corrective #Integrity #Respond #Resilience
#Availability
Controllo
L'organizzazione dovrebbe pianificare come mantenere la sicurezza delle informazioni a
un livello appropriato durante le interruzioni.
Finalità
Proteggere le informazioni e gli altri asset relativi durante le interruzioni.
Guida
L'organizzazione dovrebbe determinare i propri requisiti per adattare i controlli per la
sicurezza delle informazioni durante le interruzioni. I requisiti di sicurezza delle
informazioni dovrebbero essere inclusi nei processi di gestione della continuità operativa.
Dovrebbero essere sviluppati, attuati, testati, riesaminati e valutati piani per mantenere o
ripristinare la sicurezza delle informazioni dei processi di business critici a seguito di
interruzioni o guasti. La sicurezza delle informazioni dovrebbe essere ripristinata al livello
richiesto e nei tempi richiesti.
L'organizzazione dovrebbe attuare e mantenere:
a) controlli per la sicurezza delle informazioni, sistemi e strumenti a supporto dei piani
di continuità operativa e di continuità ICT;
b) processi per mantenere i controlli per la sicurezza delle informazioni esistenti
durante le interruzioni;
c) controlli compensativi per i controlli per la sicurezza delle informazioni che non
possono essere mantenuti durante le interruzioni.
Altre informazioni
Nell'ambito della pianificazione della continuità operativa e della continuità ICT, può
essere necessario adeguare i requisiti di sicurezza delle informazioni a seconda del tipo
di interruzione, rispetto alle normali condizioni operative. Nell'ambito dell'analisi di impatto
operativo (BIA) e della valutazione del rischio svolta nell'ambito della gestione della
continuità operativa, le conseguenze della perdita di riservatezza e integrità delle
informazioni dovrebbero essere considerate e a tali conseguenze dovrebbero essere
assegnate priorità oltre alla necessità di mantenere la disponibilità.
Le informazioni sulla gestione della continuità operativa sono disponibili nelle ISO 22313
e ISO 22301. Un’ulteriore guida sull'analisi di impatto operativo (BIA) è disponibile nella
ISO/TS 22317.
5.30 Prontezza dell’ICT per la continuità operativa
informazioni
#Corrective #Availability #Respond #Continuity #Resilience
Controllo
La prontezza dell’ICT dovrebbe essere pianificata, attuata, mantenuta e testata sulla base
degli obiettivi di continuità operativa e dei requisiti di continuità dell’ICT.
Finalità
Assicurare la disponibilità delle informazioni dell'organizzazione e degli altri asset relativi
durante le interruzioni.

Guida
La preparazione dell’ICT per la continuità operativa è una componente importante nella
gestione della continuità operativa e nella gestione della sicurezza delle informazioni per
assicurare che gli obiettivi dell'organizzazione possano continuare a essere raggiunti
durante le interruzioni.
I requisiti di continuità ICT sono il risultato dell’analisi di impatto operativo (BIA). Il
processo di BIA dovrebbe utilizzare tipi e criteri di impatto per valutare gli impatti nel
tempo derivanti dall'interruzione delle attività di business che forniscono prodotti e servizi.
L'entità e la durata dell'impatto risultante dovrebbero essere utilizzate per identificare le
attività prioritarie a cui dovrebbe essere assegnato un obiettivo relativo al tempo di
recupero (RTO). La BIA dovrebbe quindi determinare quali risorse sono necessarie per
supportare le attività prioritarie. È inoltre necessario specificare un RTO per queste
risorse. Un sottoinsieme di queste risorse dovrebbe includere i servizi ICT.
La BIA che coinvolge i servizi ICT può essere ampliata per definire i requisiti di prestazioni
e capacità dei sistemi ICT e gli obiettivi relativi al punto di ripristino (RPO) delle
informazioni richieste per supportare le attività durante l'interruzione.
Sulla base dei risultati dell’analisi di impatto operativo (BIA) e della valutazione del rischio
che coinvolge i servizi ICT, l'organizzazione dovrebbe identificare e selezionare strategie
di continuità ICT che considerino le opzioni prima, durante e dopo l'interruzione. Le
strategie di continuità operativa possono comprendere una o più soluzioni. Sulla base
delle strategie, i piani dovrebbero essere sviluppati, attuati e testati per soddisfare il livello
di disponibilità richiesto dei servizi ICT e nelle tempistiche richieste in seguito
all'interruzione o al fallimento dei processi critici.
L'organizzazione dovrebbe assicurare che:
a) sia presente un'adeguata struttura organizzativa per prepararsi, mitigare e
rispondere a un'interruzione, che sia supportata da personale dotato delle
necessarie responsabilità, autorità e competenza;
b) i piani di continuità ICT, comprese le procedure di risposta e ripristino che descrivono
in dettaglio come l'organizzazione intende gestire un'interruzione del servizio ICT,
siano:
1) regolarmente valutati attraverso esercizi e prove;
2) approvati dalla direzione;
c) i piani di continuità ICT includano le seguenti informazioni sulla continuità ICT:
1) specifiche di prestazione e capacità per soddisfare i requisiti e gli obiettivi di
continuità operativa come specificato nella BIA;
2) RTO di ciascun servizio ICT prioritario e le procedure per il ripristino di tali
componenti;
3) RPO delle risorse ICT prioritarie definite come informazioni e le modalità di
ripristino delle informazioni.
Altre informazioni
La gestione della continuità ICT costituisce una parte fondamentale dei requisiti di
continuità operativa per quanto riguarda la disponibilità per essere in grado di:
a) rispondere e riprendersi dall'interruzione dei servizi ICT, indipendentemente dalla
causa;
b) assicurare che le attività prioritarie siano supportate dai servizi ICT richiesti;
c) rispondere prima che si verifichi un'interruzione dei servizi ICT e al rilevamento di
almeno un incidente che può comportare un'interruzione dei servizi ICT.
Ulteriori indicazioni sulla preparazione ICT per la continuità operativa sono disponibili
nella ISO/IEC 27031.
Ulteriori indicazioni sul sistema di gestione della continuità operativa sono disponibili nella
ISO 22301 e nella ISO 22313.
Ulteriori indicazioni sulla BIA sono disponibili nella ISO/TS 22317.

5.31 Identificazione dei requisiti legali, statutari, regolamentari e contrattuali
informazioni
#Preventive #Confidentiality #Identify #Legal_and_compliance #Governance_and_Ecosystem
#Availability
Controllo
I requisiti legali, statutari, regolamentari e contrattuali relativi alla sicurezza delle
informazioni e l'approccio dell'organizzazione per soddisfare tali requisiti dovrebbero
essere identificati, documentati e tenuti aggiornati.
Finalità
Assicurare il rispetto dei requisiti legali, statutari, regolamentari e contrattuali relativi alla
Guida
Generale
I requisiti esterni, inclusi i requisiti legali, statutari, regolamentari o contrattuali,
dovrebbero essere presi in considerazione quando:
a) si sviluppano politiche e procedure di sicurezza delle informazioni;
b) si progettano, attuano o cambiano i controlli di sicurezza delle informazioni;
c) si classificano le informazioni e gli altri asset relativi nell'ambito del processo di
impostazione dei requisiti di sicurezza delle informazioni per esigenze interne o per
accordi con i fornitori;
d) si eseguono valutazioni del rischio relativo alla sicurezza delle informazioni e si
determinano le attività di trattamento del rischio relativo alla sicurezza delle
informazioni;
e) si determinano i processi e i relativi ruoli e responsabilità in materia di sicurezza
delle informazioni;
f) si determinano i requisiti contrattuali con i fornitori relativi all'organizzazione e
all'ambito della fornitura di prodotti e servizi.
Norme di legge e regolamenti
L'organizzazione dovrebbe:
a) identificare tutte le norme di legge e i regolamenti relativi alla sicurezza delle
informazioni dell'organizzazione al fine di essere a conoscenza dei requisiti per il
proprio tipo di attività;
b) prendere in considerazione la conformità in tutti i Paesi interessati, se
l'organizzazione:
- svolge affari in altri Paesi;
- utilizza prodotti e servizi di altri Paesi in cui leggi e regolamenti possono avere
effetti sull'organizzazione;
- trasferisce informazioni oltre i confini giurisdizionali dove leggi e regolamenti
possono avere effetti sull'organizzazione;
c) riesaminare periodicamente le norme di legge e i regolamenti individuati al fine di
mantenersi aggiornata sui cambiamenti e identificare le nuove norme di legge;
d) definire e documentare i processi specifici e le responsabilità individuali per
soddisfare tali requisiti.

Crittografia
La crittografia è un'area che spesso ha requisiti legali specifici. Si dovrebbe prendere in
considerazione il rispetto degli accordi, delle leggi e dei regolamenti relativi ai seguenti
elementi:
a) limitazioni all'importazione o esportazione di hardware e software informatici per lo
svolgimento di funzioni crittografiche;
b) limitazioni all'importazione o esportazione di hardware e software per computer
progettati per l'aggiunta di funzioni crittografiche;
c) limitazioni all'uso della crittografia;
d) modalità obbligatorie o discrezionali di accesso da parte delle autorità nazionali alle
informazioni crittografate;
e) validità di firme, sigilli e certificati digitali.
Si consiglia di richiedere una consulenza legale per assicurare il rispetto delle norme di
legge e dei regolamenti pertinenti, in particolare quando le informazioni cifrate o gli
strumenti crittografici vengono spostati oltre i confini giurisdizionali.
Contratti
I requisiti contrattuali relativi alla sicurezza delle informazioni dovrebbero includere quelli
indicati nei:
a) contratti con i clienti;
b) contratti con fornitori (vedere 5.20);
c) contratti assicurativi.
Altre informazioni
5.32 Diritti di proprietà intellettuale
informazioni
#Integrity
#Availability
Controllo
L'organizzazione dovrebbe attuare procedure appropriate per proteggere i diritti di
proprietà intellettuale.
Finalità
Assicurare la conformità ai requisiti legali, statutari, regolamentari e contrattuali relativi ai
diritti di proprietà intellettuale e all'uso di prodotti proprietari.
Guida
Le seguenti linee guida dovrebbero essere prese in considerazione per proteggere
qualsiasi materiale che possa essere considerato proprietà intellettuale:
a) definire e comunicare una politica specifica per la tutela dei diritti di proprietà
intellettuale;
b) pubblicare procedure per il rispetto dei diritti di proprietà intellettuale e che
definiscano l'uso conforme di software e prodotti informatici;
c) acquisire software solo attraverso fonti conosciute e affidabili, per assicurare che il
diritto d'autore non venga violato;
d) mantenere adeguati registri degli asset e identificare tutti gli asset con requisiti di
tutela dei diritti di proprietà intellettuale;
e) mantenere prove ed evidenze della titolarità di licenze, manuali, ecc.;

f) assicurare che non venga superato il numero massimo di utenti o risorse (per
esempio CPU) consentito dalla licenza;
g) effettuare riesami per assicurare che siano installati solo software autorizzati e
prodotti concessi in licenza;
h) fornire procedure per il mantenimento delle adeguate condizioni di licenza;
i) fornire procedure per lo smaltimento o il trasferimento di software ad altri;
j) rispettare i termini e le condizioni per il software e per le informazioni ottenute da reti
pubbliche e fonti esterne;
k) non duplicare, convertire in altro formato o estrarre da registrazioni commerciali
(video, audio) in modo diverso da quello consentito dalla legge sul diritto d'autore o
dalle licenze applicabili;
l) non copiare, in tutto o in parte, norme (per esempio norme internazionali ISO/IEC),
libri, articoli, relazioni o altri documenti, diversi da quelli consentiti dalla legge sul
diritto d'autore o dalle licenze applicabili.
Altre informazioni
I diritti di proprietà intellettuale includono il diritto d’autore del software, dei documenti o
dei progetti, marchi, brevetti e licenze di codice sorgente.
I prodotti software proprietari sono generalmente forniti in base a un contratto di licenza
che specifica i termini e le condizioni della licenza, per esempio limitando l'uso dei prodotti
a macchine specifiche o limitando la copia alla sola creazione di copie di backup. Vedere
la serie ISO/IEC 19770 per i dettagli sulla gestione degli asset IT.
I dati possono essere acquisiti da fonti esterne. Generalmente si verifica il caso che tali
dati sono ottenuti in base ai termini di un accordo di condivisione dei dati o di uno
strumento giuridico simile. Tali accordi di condivisione dei dati dovrebbero chiarire quale
trattamento è consentito per i dati acquisiti. Si consiglia inoltre di indicare chiaramente la
provenienza dei dati. Vedere ISO/IEC 23751 per i dettagli sugli accordi di condivisione dei
dati.
Requisiti legali, statutari, regolamentari e contrattuali possono imporre limitazioni alla
copia di materiale proprietario. In particolare, possono richiedere che sia utilizzato solo il
materiale sviluppato dall'organizzazione o concesso in licenza oppure fornito dallo
sviluppatore all'organizzazione. La violazione del diritto d'autore può portare ad azioni
legali che possono comportare multe e procedimenti penali.
Oltre alla necessità che l'organizzazione adempia ai propri obblighi nei confronti dei diritti
di proprietà intellettuale di terzi, dovrebbero essere gestiti anche i rischi del personale e di
terzi che non rispettano i diritti di proprietà intellettuale dell'organizzazione.
5.33 Protezione delle registrazioni
informazioni
#Preventive #Confidentiality #Identify #Legal_and_compliance #Defence
#Integrity #Protect #Asset_management
#Availability #Information_protection
Controllo
Le registrazioni dovrebbero essere protette da perdita, distruzione, falsificazione, accesso
non autorizzato e rilascio non autorizzato.
Finalità
Assicurare la conformità ai requisiti legali, cogenti e contrattuali, nonché alle aspettative
della comunità o della società relative alla protezione e alla disponibilità delle
registrazioni.

Guida
L'organizzazione dovrebbe adottare i seguenti passi per proteggere l'autenticità,
l'affidabilità, l'integrità e l'usabilità delle registrazioni, poiché il contesto di business e i
requisiti per la loro gestione cambiano nel tempo:
a) emanare linee guida circa la conservazione, la gestione della catena di custodia e la
dismissione delle registrazioni, che includano la prevenzione dalla manipolazione
delle registrazioni. Tali linee guida dovrebbero essere allineate con la politica
specifica dell'organizzazione per la gestione delle registrazioni e per gli altri requisiti
relativi alle registrazioni;
b) redigere un programma di conservazione definendo le registrazioni e il periodo di
tempo per il quale dovrebbero essere conservate.
Il sistema di conservazione e trattamento dovrebbe assicurare l'identificazione delle
registrazioni e del loro periodo di conservazione, tenendo conto delle norme di legge o dei
regolamenti nazionali o regionali, nonché delle aspettative della comunità o della società,
se applicabili. Tale sistema dovrebbe consentire un'adeguata distruzione delle
registrazioni dopo tale periodo se queste ultime non sono necessarie all'organizzazione.
Quando si decide sulla protezione di specifiche registrazioni dell’organizzazione,
dovrebbe essere presa in considerazione la corrispondente classificazione di sicurezza
delle informazioni, sulla base dello schema di classificazione dell'organizzazione. Le
registrazioni dovrebbero essere raggruppate per tipologia (per esempio registrazioni
contabili, registrazioni di transazioni commerciali, registrazioni del personale, registrazioni
legali), ciascuna unitamente a dettagli sul periodo di conservazione e il tipo di supporto di
memorizzazione consentito che può essere fisico o elettronico.
I sistemi di memorizzazione dei dati dovrebbero essere scelti in modo tale che le
registrazioni richieste possano essere recuperate in un lasso di tempo e in un formato
accettabili, a seconda dei requisiti da soddisfare.
Laddove si scelgano supporti di memorizzazione elettronici, dovrebbero essere stabilite
procedure per assicurare la possibilità di accedere alle registrazioni (in termini di supporti
di memorizzazione e leggibilità del formato) durante tutto il periodo di conservazione per
tutelarsi da perdite dovute a futuri cambiamenti tecnologici. Anche eventuali chiavi
crittografiche e programmi correlati e associati ad archivi cifrati o firme digitali dovrebbero
essere conservate per consentire la decifratura delle registrazioni per l’intero periodo di
conservazione delle registrazioni stesse (vedere 8.24).
Le procedure di memorizzazione e trattamento dovrebbero essere attuate in conformità
con le raccomandazioni fornite dai produttori dei supporti di memorizzazione. Dovrebbe
essere presa in considerazione la possibilità di deterioramento dei supporti utilizzati per la
memorizzazione delle registrazioni.
Altre informazioni
Le registrazioni documentano singoli eventi o transazioni o possono formare insiemi
progettati per documentare processi di lavoro, attività o funzioni. Sono al contempo prova
dell'attività di business e asset informativi. Qualsiasi insieme di informazioni,
indipendentemente dalla sua struttura o forma, può essere gestito come registrazione.
Ciò comprende informazioni sotto forma di documento, raccolta di dati o altri tipi di
informazioni digitali o analogiche create, acquisite e gestite nel corso delle attività di
business.
Nella gestione delle registrazioni, i metadati sono dati che descrivono il contesto, il
contenuto e la struttura delle registrazioni, nonché la loro gestione nel tempo. I metadati
sono una componente essenziale di qualsiasi registrazione.
Può essere necessario conservare alcune registrazioni in modo sicuro per soddisfare
requisiti legali, cogenti o contrattuali, nonché per supportare attività essenziali di
business. Disposizioni legislative o regolamentari nazionali possono definire la durata e il
contenuto dei dati per la conservazione delle informazioni. Ulteriori informazioni sulla
gestione delle registrazioni sono disponibili nella ISO 15489.

5.34 Privacy e protezione dei dati personali
informazioni
#Preventive #Confidentiality #Identify #Information_protection #Protection
#Integrity #Protect #Legal_and_compliance
#Availability
Controllo
L'organizzazione dovrebbe identificare e soddisfare i requisiti relativi alla tutela della
privacy e alla protezione dei dati personali secondo le leggi e i regolamenti applicabili e i
requisiti contrattuali.
Finalità
Assicurare il rispetto dei requisiti legali, statutari, regolamentari e contrattuali relativi agli
aspetti di sicurezza delle informazioni nell’ambito della protezione dei dati personali.
Guida
L'organizzazione dovrebbe stabilire e comunicare una politica specifica per la privacy e la
protezione dei dati personali a tutte le parti interessate pertinenti.
L'organizzazione dovrebbe sviluppare e attuare procedure per la tutela della privacy e la
protezione dei dati personali. Queste procedure dovrebbero essere comunicate a tutte le
parti interessate coinvolte nel trattamento dei dati personali.
Il rispetto di tali procedure e di tutte le norme di legge e i regolamenti pertinenti in materia
di tutela della privacy e protezione dei dati personali, richiede ruoli, responsabilità e
controlli adeguati. Spesso ciò si ottiene al meglio con la nomina di una persona
responsabile, come un responsabile della privacy, che dovrebbe guidare il personale, i
fornitori di servizi e le altre parti interessate in merito alle loro responsabilità individuali e
alle procedure specifiche che dovrebbero essere seguite.
Le responsabilità per il trattamento dei dati personali dovrebbero essere affrontate
tenendo conto delle norme di legge e dei regolamenti pertinenti.
Dovrebbero essere attuate adeguate misure tecniche e organizzative per proteggere i dati
personali.
Altre informazioni
Un certo numero di Paesi ha introdotto norme di legge che prevedono controlli sulla
raccolta, l'elaborazione, la trasmissione e l'eliminazione dei dati personali. A seconda
delle norme di legge nazionali pertinenti, tali controlli possono imporre obblighi a coloro
che raccolgono, elaborano e diffondono i dati personali e possono anche limitare il diritto
di trasferire i dati personali in altri Paesi.
La ISO/IEC 29100 fornisce un quadro di riferimento di alto livello per la protezione dei dati
personali nell'ambito dei sistemi informatici. Ulteriori informazioni sui sistemi di gestione
per la privacy sono disponibili nella ISO/IEC 27701. Informazioni specifiche sulla gestione
della privacy nei cloud pubblici che agiscono come responsabili del trattamento dei dati
personali sono disponibili nella ISO/IEC 27018.
La ISO/IEC 29134 fornisce linee guida per la valutazione dell'impatto privacy (PIA) e
fornisce un esempio di struttura e contenuto di un rapporto di valutazione di impatto
privacy. Rispetto alla ISO/IEC 27005, questa è incentrata sull'elaborazione dei dati
personali ed è rivolta alle organizzazioni che elaborano dati personali. Questa norma può
aiutare a identificare i rischi relativi alla privacy e le possibili mitigazioni per ridurre questi
rischi a livelli accettabili.

5.35 Riesame indipendente della sicurezza delle informazioni
informazioni
#Preventive #Confidentiality #Identify #Information_security_assurance #Governance_and_Ecosystem
#Corrective #Integrity #Protect
#Availability
Controllo
L'approccio dell'organizzazione alla gestione della sicurezza delle informazioni e alla sua
attuazione, che include personale, processi e tecnologie, dovrebbe essere riesaminato in
modo indipendente a intervalli pianificati o quando si verificano cambiamenti significativi.
Finalità
Assicurare la continua idoneità, adeguatezza ed efficacia dell'approccio
dell'organizzazione alla gestione della sicurezza delle informazioni.
Guida
L'organizzazione dovrebbe disporre di processi per condurre riesami indipendenti.
La direzione dovrebbe pianificare e avviare riesami indipendenti periodici. I riesami
dovrebbero includere la valutazione delle opportunità di miglioramento e la necessità di
cambiamenti all'approccio alla sicurezza delle informazioni, compresa la politica per la
sicurezza delle informazioni, le politiche specifiche e altri controlli.
Tali riesami dovrebbero essere effettuati da soggetti indipendenti dall'area in esame (per
esempio la funzione di audit interno, un manager indipendente o un'organizzazione
esterna specializzata in tali riesami). Gli individui che effettuano questi riesami
dovrebbero avere la competenza appropriata. La persona che effettua i riesami non
dovrebbe essere nella linea di riporto per assicurare l'indipendenza necessaria per
effettuare una valutazione.
I risultati dei riesami indipendenti dovrebbero essere comunicati alla direzione che ha
avviato i riesami e, se del caso, all'alta direzione. Queste registrazioni dovrebbero essere
mantenute.
Se i riesami indipendenti identificano che l'approccio alla gestione della sicurezza delle
informazioni e l'attuazione da parte dell'organizzazione sono inadeguati [per esempio
obiettivi e requisiti documentati non sono soddisfatti o non sono conformi agli indirizzi per
la sicurezza delle informazioni dichiarata nella politica per la sicurezza delle informazioni
e nelle politiche specifiche (vedere 5.1)], la direzione dovrebbe avviare azioni correttive.
Oltre ai riesami indipendenti periodici, l'organizzazione dovrebbe prendere in
considerazione la possibilità di condurre riesami indipendenti quando:
a) leggi e regolamenti influiscono sui cambiamenti organizzativi;
b) si verificano incidenti significativi;
c) l'organizzazione avvia una nuova attività o cambia un'attività in corso;
d) l'organizzazione inizia a impiegare un nuovo prodotto o servizio, o cambia l'impiego
di un prodotto o di un servizio in uso;
e) l'organizzazione cambia in modo significativo i controlli e le procedure di sicurezza
delle informazioni.
Altre informazioni
La ISO/IEC 27007 e la ISO/IEC TS 27008 forniscono indicazioni per lo svolgimento di
riesami indipendenti.

5.36 Conformità alle politiche e alle norme per la sicurezza delle informazioni
informazioni
#Integrity #Protect #Information_security_assurance
#Availability
Controllo
La conformità alla politica per la sicurezza delle informazioni dell'organizzazione, alle
politiche specifiche, alle regole e agli standard dovrebbe essere riesaminata
regolarmente.
Finalità
Assicurare che la sicurezza delle informazioni sia attuata e condotta in conformità con la
politica per la sicurezza delle informazioni dell'organizzazione, con le politiche, le regole e
gli standard specifici.
Guida
I manager, i responsabili di servizi, prodotti o informazioni dovrebbero identificare come
riesaminare che i requisiti di sicurezza delle informazioni definiti nella politica per la
sicurezza per le informazioni, nelle politiche specifiche, nelle regole, negli standard e nelle
altre normative applicabili siano soddisfatte. Per un riesame periodico efficiente si
dovrebbero prendere in considerazione strumenti di misurazione e reporting automatici.
Se viene rilevata una non conformità a seguito del riesame, i gestori dovrebbero:
a) individuare le cause della non conformità;
b) valutare la necessità di azioni correttive per raggiungere la conformità;
c) attuare adeguate azioni correttive;
d) riesaminare le azioni correttive intraprese per verificarne l'efficacia e individuare
eventuali carenze o debolezze.
I risultati dei riesami e delle azioni correttive eseguite dai gestori, dai responsabili di
servizi, prodotti o informazioni dovrebbero essere registrati e tali registrazioni dovrebbero
essere mantenute. I gestori dovrebbero riferire i risultati alle persone che effettuano i
riesami indipendenti (vedere 5.35) quando si svolge un riesame indipendente nell'area di
loro responsabilità.
Le azioni correttive dovrebbero essere completate in modo tempestivo, a seconda del
rischio. Se non viene completato entro il prossimo riesame programmato, i progressi
dovrebbero almeno essere affrontati in quel riesame.
Altre informazioni
Il monitoraggio della operativo dell'uso del sistema è trattato in 8.15, 8.16, 8.17.
5.37 Procedure operative documentate
Tipo di controllo Proprietà di sicurezza Concetti di cybersecurity Capacità operative Domini di sicurezza
delle informazioni
#Preventive #Confidentiality #Protect #Asset_management #Governance_and_Ecosystem
#Corrective #Integrity #Recover #Physical_security #Protection
#Availability #System_and_network_security #Defence
#Application_security
#Secure_configuration
#Identity_and_access_management
#Threat_and_vulnerability_management
#Continuity
#Information_security_event_management

Controllo
Le procedure operative per le strutture di elaborazione delle informazioni dovrebbero
essere documentate e messe a disposizione del personale che ne ha bisogno.
Finalità
Assicurare il corretto e sicuro funzionamento delle strutture di elaborazione delle
informazioni.
Guida
Dovrebbero essere predisposte procedure documentate per le attività operative
dell'organizzazione relative alla sicurezza delle informazioni, per esempio:
a) quando l'attività deve essere svolta allo stesso modo da molte persone;
b) quando l'attività è svolta raramente e quando alla successiva esecuzione è probabile
che la procedura sia stata dimenticata;
c) quando l'attività è nuova e presenta un rischio se non svolta correttamente;
d) prima del passaggio dell'attività a nuovo personale.
Le procedure operative dovrebbero specificare:
a) i soggetti responsabili;
b) l'installazione e configurazione sicura dei sistemi;
c) l’elaborazione e il trattamento delle informazioni, in modo sia automatizzato sia
manuale;
d) backup (vedere 8.13) e resilienza;
e) i requisiti di pianificazione, comprese le interdipendenze con altri sistemi;
f) le istruzioni per la gestione degli errori o altre condizioni eccezionali [per esempio
limitazioni sull'uso dei programmi di utilità (vedere 8.18)] che possono verificarsi
durante l'esecuzione del lavoro;
g) i contatti di supporto ed escalation, inclusi contatti di supporto esterno in caso di
inattese difficoltà operative o tecniche;
h) le istruzioni per la gestione dei supporti di memorizzazione (vedere 7.10 e 7.14);
i) le procedure di riavvio e ripristino da utilizzare in caso di guasto del sistema;
j) la gestione degli audit trail e dei log di sistema (vedere 8.15 e 8.17) e dei sistemi di
monitoraggio video (vedere 7.4);
k) procedure di monitoraggio quali capacità, prestazioni e sicurezza (vedere 8.6 e
8.16);
l) istruzioni per la manutenzione.
Le procedure operative documentate dovrebbero essere riesaminate e aggiornate
quando necessario. I cambiamenti alle procedure operative documentate dovrebbero
essere autorizzati. Ove tecnicamente fattibile, i sistemi informativi dovrebbero essere
gestiti in modo coerente, utilizzando le stesse procedure, strumenti e utilità.
Altre informazioni

6 CONTROLLI SUL PERSONALE
6.1 Screening
informazioni
#Preventive #Confidentiality #Protect #Human_resource_security #Governance_and_Ecosystem
#Integrity
#Availability
Controllo
I controlli di verifica del background di tutti i candidati all’impiego dovrebbero essere
effettuati prima dell'ingresso nell'organizzazione e su base continuativa, tenendo conto
delle leggi, dei regolamenti e dell'etica applicabili ed essere proporzionati ai requisiti di
business, alla classificazione delle informazioni a cui si deve accedere e ai rischi percepiti.
Finalità
Assicurare che tutto il personale sia idoneo e adatto ai ruoli per i quali è considerato e
rimanga idoneo e adatto durante il proprio impiego.
Guida
Dovrebbe essere eseguito un processo di screening per tutto il personale, compreso il
personale a tempo pieno, part-time e temporaneo. Laddove questi soggetti siano
contrattualizzati tramite fornitori di servizi, i requisiti di screening dovrebbero essere
inclusi negli accordi contrattuali tra l'organizzazione e i fornitori.
Le informazioni su tutti i candidati presi in considerazione per posizioni all'interno
dell'organizzazione dovrebbero essere raccolte e trattate tenendo conto di ogni norma di
legge appropriata esistente nella giurisdizione pertinente. In alcune giurisdizioni,
l'organizzazione può essere legalmente obbligata a informare i candidati in anticipo sulle
attività di screening.
La verifica dovrebbe prendere in considerazione tutte le norme di legge pertinenti in
materia di privacy, di protezione dei dati personali e di impiego e, ove consentito, includere
quanto segue:
a) disponibilità di referenze soddisfacenti (per esempio referenze lavorative e
personali);
b) verifica (per completezza e accuratezza) del curriculum vitae del richiedente;
c) conferma dei titoli accademici e delle qualifiche professionali rivendicati;
d) verifica indipendente dell'identità (per esempio passaporto o altro documento
ammissibile rilasciato dalle autorità competenti);
e) verifiche più approfondite, quali il riesame del credito o il riesame del casellario
giudiziale se il candidato assume un ruolo critico.
Quando un individuo viene assunto per uno specifico ruolo di sicurezza delle
informazioni, le organizzazioni dovrebbero assicurarsi che il candidato:
a) abbia la necessaria competenza per svolgere il ruolo relativo alla sicurezza delle
informazioni;
b) sia affidabile per ricoprire il ruolo, specialmente se il ruolo è critico per
l'organizzazione.
Laddove un lavoro, sia su incarico iniziale che su promozione, prevede che la persona
abbia accesso a strutture di elaborazione delle informazioni e, in particolare, se queste
implicano il trattamento di informazioni riservate (per esempio informazioni economiche,
informazioni personali o informazioni sanitarie), l'organizzazione dovrebbe anche
considerare ulteriori verifiche più dettagliate.
Le procedure dovrebbero definire criteri e limiti per i riesami di verifica (per esempio chi è
idoneo a sottoporre a screening le persone e come, quando e perché vengono effettuati i
riesami di verifica).

Nelle situazioni in cui la verifica non può essere completata in modo tempestivo,
dovrebbero essere attuati controlli aggiuntivi fintanto che il riesame non sia terminato, per
esempio:
a) ritardato inserimento nel ruolo;
b) ritardata consegna degli asset dell’organizzazione;
c) inserimento con accesso ridotto;
d) cessazione del rapporto di lavoro.
Le verifiche per confermare la continua adeguatezza del personale, in relazione alla
criticità del ruolo della persona, dovrebbero essere ripetute periodicamente.
Altre informazioni
6.2 Termini e condizioni d’impiego
informazioni
#Integrity
#Availability
Controllo
Gli accordi contrattuali di lavoro dovrebbero indicare le responsabilità del personale e
dell'organizzazione relative alla sicurezza delle informazioni.
Finalità
Assicurare che il personale comprenda le proprie responsabilità in materia di sicurezza
delle informazioni per i ruoli per i quali è considerato.
Guida
Gli obblighi contrattuali per il personale dovrebbero prendere in considerazione la politica
per la sicurezza delle informazioni dell'organizzazione e le relative politiche specifiche.
Inoltre, possono essere chiariti e precisati i seguenti punti:
a) accordi di riservatezza o non divulgazione che il personale con accesso a
informazioni riservate dovrebbe firmare prima che gli venga dato accesso alle
informazioni e agli altri asset relativi (vedere 6.6);
b) responsabilità e diritti legali [per esempio per quanto riguarda le leggi sul diritto
d'autore o le norme di legge sulla protezione dei dati (vedere 5.32 e 5.34)];
c) responsabilità per la classificazione delle informazioni e per il trattamento delle
informazioni dell'organizzazione e degli altri asset relativi, delle strutture di
elaborazione delle informazioni e dei servizi informativi gestiti dal personale (vedere
da 5.9 a 5.13);
d) responsabilità relative al trattamento delle informazioni ricevute dagli interessati;
e) le azioni da intraprendere se il personale non rispetta i requisiti di sicurezza
dell'organizzazione (vedere 6.4).
I ruoli e le responsabilità relative alla sicurezza delle informazioni dovrebbero essere
comunicati ai candidati durante il processo di pre-assunzione.
L'organizzazione dovrebbe assicurare che il personale accetti i termini e le condizioni
riguardanti la sicurezza delle informazioni. Questi termini e condizioni dovrebbero essere
appropriati alla natura e all'estensione degli accessi che il personale avrà agli asset
dell'organizzazione associati ai sistemi e ai servizi informativi. I termini e le condizioni
relativi alla sicurezza delle informazioni dovrebbero essere riesaminati quando cambiano
le leggi, i regolamenti, la politica per la sicurezza delle informazioni o le politiche
specifiche.

Se del caso, le responsabilità contenute nei termini e nelle condizioni di lavoro dovrebbero
rimanere valide per un periodo definito successivo dopo il termine del rapporto di lavoro
(vedere 6.5).
Altre informazioni
Un codice di condotta può essere utilizzato per definire le responsabilità in materia di
sicurezza delle informazioni del personale in merito alla riservatezza, alla protezione dei
dati personali, all'etica, all'uso appropriato delle informazioni dell'organizzazione e degli
altri asset relativi, così come altre pratiche riconosciute e previste dall’organizzazione.
Una parte esterna che fornisce personale può essere tenuta a stipulare accordi
contrattuali al posto dei singoli individui.
Se l'organizzazione non è una persona giuridica e non ha dipendenti, l'equivalente di
accordi contrattuali e di termini e condizioni d’impiego può essere considerato come
oggetto di applicazione delle linee guida di questo controllo.
6.3 Consapevolezza, istruzione, formazione e addestramento sulla sicurezza delle

informazioni
informazioni
#Integrity
#Availability
Controllo
Il personale dell'organizzazione e le parti interessate pertinenti dovrebbero acquisire
adeguate consapevolezza, istruzione e formazione relative alla sicurezza delle
informazioni e aggiornamenti regolari della politica per la sicurezza delle informazioni
dell'organizzazione, delle politiche specifiche e delle procedure, secondo quanto
pertinente alla loro funzione lavorativa.
Finalità
Assicurare che il personale e le parti interessate pertinenti siano a conoscenza e
adempiano alle proprie responsabilità in materia di sicurezza delle informazioni.
Guida
Generale
Dovrebbe essere stabilito un programma delle attività relative alla consapevolezza,
all’istruzione e alla formazione sulla sicurezza delle informazioni in linea con la politica per
la sicurezza delle informazioni dell'organizzazione, le politiche specifiche e le procedure
pertinenti per la sicurezza delle informazioni, tenendo in considerazione le informazioni
dell'organizzazione da proteggere e i controlli per la sicurezza delle informazioni che sono
stati attuati per proteggere le informazioni.
Le attività relative a consapevolezza, istruzione e formazione sulla sicurezza delle
informazioni dovrebbero aver luogo periodicamente. L’acquisizione di consapevolezza
iniziale, l'istruzione e la formazione possono applicarsi al nuovo personale e a coloro che
passano a nuove posizioni o ruoli con requisiti di sicurezza delle informazioni
sostanzialmente diversi.
La comprensione da parte del personale dovrebbe essere valutata al termine di un'attività
di consapevolezza, istruzione o formazione per verificare il trasferimento delle
conoscenze e l'efficacia del programma di consapevolezza, istruzione e formazione.
Consapevolezza
Un programma di consapevolezza relativa alla sicurezza delle informazioni dovrebbe
mirare a rendere il personale consapevole delle proprie responsabilità in materia di
sicurezza delle informazioni e dei mezzi con cui tali responsabilità vengono assolte.

Il programma di consapevolezza dovrebbe essere pianificato tenendo in considerazione i
ruoli del personale nell'organizzazione, compreso il personale interno ed esterno (per
esempio consulenti esterni, personale dei fornitori). Le attività del programma di
consapevolezza dovrebbero essere programmate nel tempo, preferibilmente
regolarmente, in modo che le attività si ripetano e coinvolgano il nuovo personale. Il
programma dovrebbe anche basarsi sugli insegnamenti tratti dagli incidenti relativi alla
Il programma di consapevolezza dovrebbe comprendere una serie di attività di
consapevolezza attraverso adeguati canali fisici o virtuali come campagne, opuscoli,
poster, newsletter, siti web, sessioni informative, briefing, moduli di e-learning e posta
elettronica.
La consapevolezza relativa alla sicurezza delle informazioni dovrebbe coprire aspetti
generali quali:
a) l'impegno della direzione per la sicurezza delle informazioni in tutta l'organizzazione;
b) esigenze di familiarizzazione e conformità alle norme e agli obblighi applicabili in
materia di sicurezza delle informazioni, tenendo conto della politica per la sicurezza
delle informazioni e delle politiche specifiche, degli standard, delle leggi, degli statuti,
dei regolamenti, dei contratti e degli accordi;
c) responsabilità personale per le proprie azioni e omissioni, e responsabilità generali
verso la sicurezza o la protezione delle informazioni appartenenti all'organizzazione
e alle parti interessate;
d) procedure di base per la sicurezza delle informazioni (come la segnalazione degli
incidenti relativi alla sicurezza delle informazioni) e controlli di base [per esempio
relativi alla sicurezza delle password (5.17)];
e) punti di contatto e risorse per ulteriori informazioni e consigli in materia di sicurezza
delle informazioni, compreso ulteriore materiale per la consapevolezza relativa alla
Istruzione e formazione
L'organizzazione dovrebbe identificare, preparare e attuare un piano di formazione
appropriato per i gruppi tecnici i cui ruoli richiedono specifiche competenze ed
esperienze. I team tecnici dovrebbero avere le competenze per configurare e mantenere
il livello di sicurezza richiesto per dispositivi, sistemi, applicazioni e servizi. Se mancano le
competenze, l'organizzazione dovrebbe agire e acquisirle.
Il programma di istruzione e formazione dovrebbe considerare forme diverse [per
esempio lezioni frontali o auto-apprendimento, tutoraggio da parte di personale esperto o
consulenti (formazione sul lavoro), rotazione dei membri del personale per seguire attività
diverse, reclutamento di persone già qualificate e assunzione di consulenti].
L’organizzazione può utilizzare diverse modalità di erogazione tra cui formazione in aula,
apprendimento a distanza, formazione online, autoapprendimento e altri. Il personale
tecnico dovrebbe mantenere aggiornate le proprie conoscenze iscrivendosi a newsletter
e riviste o partecipando a convegni ed eventi volti al miglioramento tecnico e
professionale.
Altre informazioni
Quando si compone un programma di consapevolezza, è importante non solo
concentrarsi sul "cosa" e sul "come", ma anche sul "perché", quando possibile. È
importante che il personale comprenda l'obiettivo della sicurezza delle informazioni e il
potenziale effetto, positivo e negativo, del proprio comportamento sull'organizzazione.
La consapevolezza, l'istruzione e la formazione in materia di sicurezza delle informazioni
possono far parte o essere condotte insieme ad altre attività, per esempio relative a
gestione generale delle informazioni, ICT, sicurezza, privacy o formazione sulla sicurezza
delle persone.

6.4 Processo disciplinare
Tipo di controllo Proprietà di sicurezza Concetti di cybersecurity Capacità operative Domini di sicurezza
delle informazioni
#Availability
Controllo
Un processo disciplinare dovrebbe essere formalizzato e comunicato per intraprendere
azioni contro il personale e altre parti interessate pertinenti che hanno commesso una
violazione della politica per la sicurezza delle informazioni.
Finalità
Assicurare che il personale e le altre parti interessate pertinenti comprendano le
conseguenze delle violazioni della politica per la sicurezza delle informazioni, scoraggiare
e trattare in modo appropriato il personale che ha commesso una violazione.
Guida
Il processo disciplinare non dovrebbe essere avviato senza la previa verifica che si sia
verificata una violazione della politica per la sicurezza delle informazioni (vedere 5.28).
Il processo disciplinare formale dovrebbe prevedere una risposta graduale che tenga
conto di fattori quali:
a) la natura (chi, cosa, quando, come) e la gravità della violazione e le sue
conseguenze;
b) se il reato è stato intenzionale (doloso) o non intenzionale (accidentale);
c) se si tratta della prima volta in cui il reato è stato commesso o una ripetizione;
d) se il trasgressore è stato adeguatamente formato o meno.
La risposta dovrebbe prendere in considerazione i requisiti legali, statutari, normativi
contrattuali e di business pertinenti, nonché altri fattori, se necessario. Il processo
disciplinare dovrebbe essere utilizzato anche come deterrente per impedire al personale
di violare la politica per la sicurezza delle informazioni, le politiche specifiche e le
procedure relative alla sicurezza delle informazioni. Violazioni intenzionali delle politiche
di sicurezza delle informazioni possono richiedere azioni immediate.
Altre informazioni
Ove possibile, l'identità delle persone soggette ad azione disciplinare dovrebbe essere
tutelata in linea con i requisiti applicabili.
Quando le persone dimostrano un comportamento eccellente per quanto riguarda la
sicurezza delle informazioni, possono essere premiate per promuovere la sicurezza delle
informazioni e incoraggiare un buon comportamento.
6.5 Responsabilità dopo la cessazione o il cambio d’impiego
informazioni
#Integrity #Asset_management
#Availability
Controllo
Le responsabilità e gli obblighi in materia di sicurezza delle informazioni che rimangono
validi dopo la cessazione o il cambio d’impiego dovrebbero essere definiti, applicati e
comunicati al personale pertinente e alle altre parti interessate.

Finalità
Proteggere gli interessi dell'organizzazione come parte del processo di cambiamento o
cessazione dei rapporti di lavoro o dei contratti.
Guida
Il processo per la gestione della cessazione o del cambio d’impiego dovrebbe definire
quali responsabilità e doveri relativi alla sicurezza delle informazioni dovrebbero rimanere
validi dopo la cessazione o il cambio. Ciò può includere la riservatezza delle informazioni,
la proprietà intellettuale e altre conoscenze acquisite, nonché le responsabilità previste da
qualsiasi altro accordo di riservatezza (vedere 6.6). Le responsabilità e i doveri ancora
validi dopo la cessazione del rapporto di lavoro o del contratto dovrebbero essere riportati
dai termini e condizioni di lavoro (vedere 6.2), nel contratto o nell'accordo. Altri contratti o
accordi che continuano per un periodo definito dopo la fine dell’impiego di una singola
persona possono contenere responsabilità di sicurezza delle informazioni.
I cambiamenti di responsabilità o impiego dovrebbero essere gestiti come la cessazione
dell'attuale responsabilità o impiego combinata con l'inizio della nuova responsabilità o
impiego.
I ruoli e le responsabilità di sicurezza delle informazioni ricoperti da qualsiasi individuo
che lasci o cambi ruoli lavorativi dovrebbero essere identificati e trasferiti a un altro
individuo.
Dovrebbe essere stabilito un processo per la comunicazione dei cambiamenti e delle
procedure operative al personale, alle altre parti interessate e ai relativi referenti (per
esempio a clienti e fornitori).
Il processo per la cessazione o il cambio dell’impiego dovrebbe essere applicato anche al
personale esterno (per esempio fornitori) quando si verifica una cessazione del contratto
o del lavoro con l'organizzazione, o quando si verifica un cambio di lavoro all'interno
Altre informazioni
In molte organizzazioni, la funzione delle risorse umane è generalmente responsabile
dell'intero processo di cessazione e collabora con il superiore della persona che sta
cessando o cambiando l’impiego per gestire gli aspetti di sicurezza delle informazioni
delle procedure pertinenti. Nel caso di personale fornito tramite un soggetto esterno (per
esempio tramite un fornitore), questo processo di cessazione è intrapreso dal soggetto
esterno in accordo con il contratto tra l'organizzazione e il soggetto esterno.
6.6 Accordi di riservatezza o di non divulgazione
informazioni
#Information_protection
#Supplier_relationships_security
Controllo
Gli accordi di riservatezza o non divulgazione che riflettono le esigenze
dell'organizzazione per la protezione delle informazioni dovrebbero essere identificati,
documentati, riesaminati regolarmente e firmati dal personale e dalle altre parti
interessate pertinenti.
Finalità
Mantenere la riservatezza delle informazioni accessibili dal personale o da soggetti
esterni.

Guida
Gli accordi di riservatezza o non divulgazione dovrebbero soddisfare il requisito di
proteggere le informazioni riservate utilizzando termini con validità legale. Gli accordi di
riservatezza o non divulgazione sono applicabili alle parti interessate e al personale
dell'organizzazione. Sulla base dei requisiti di sicurezza delle informazioni di
un'organizzazione, i termini degli accordi dovrebbero essere determinati prendendo in
considerazione il tipo di informazioni che saranno trattate, il loro livello di classificazione,
il loro utilizzo e l'accesso consentito alla altre parti interessate. Per identificare i requisiti
degli accordi di riservatezza o non divulgazione, dovrebbero essere considerati i seguenti
elementi:
a) una definizione delle informazioni da proteggere (per esempio informazioni
riservate);
b) la durata prevista di un accordo, compresi i casi in cui può essere necessario
mantenere la riservatezza a tempo indeterminato o fino a quando le informazioni
non diventano pubblicamente disponibili;
c) le azioni richieste in caso di conclusione dell’accordo;
d) le responsabilità e le azioni dei firmatari per evitare la divulgazione non autorizzata di
informazioni;
e) chi è il responsabile delle informazioni, dei segreti commerciali e della proprietà
intellettuale e come questo si collega alla protezione delle informazioni riservate;
f) gli usi consentiti delle informazioni riservate e i diritti dei firmatari di utilizzare le
informazioni;
g) il diritto di controllare e monitorare le attività che comportano l’uso delle informazioni
riservate per circostanze altamente sensibili;
h) il processo di notifica e segnalazione di divulgazione non autorizzata o di fuga di
informazioni riservate;
i) le condizioni per la restituzione o la distruzione delle informazioni al termine
dell’accordo;
j) le azioni previste da intraprendere in caso di mancato rispetto dell'accordo.
L'organizzazione dovrebbe prendere in considerazione il rispetto degli accordi di
riservatezza e non divulgazione nelle giurisdizioni in cui si applicano (vedere 5.31, 5.32,
5.33, 5.34).
I requisiti per gli accordi di riservatezza e non divulgazione dovrebbero essere riesaminati
periodicamente e quando si verificano cambiamenti che influenzano tali requisiti.
Altre informazioni
Gli accordi di riservatezza e non divulgazione proteggono le informazioni
dell'organizzazione e informano i firmatari delle loro responsabilità nel proteggere,
utilizzare e divulgare le informazioni in modo responsabile e autorizzato.
6.7 Lavoro a distanza
informazioni
#Availability #Physical_security
#System_and_network_security

Controllo
Quando il personale lavora a distanza, dovrebbero essere attuate misure di sicurezza per
proteggere le informazioni a cui è possibile accedere o che sono elaborate o memorizzate
al di fuori dei locali dell'organizzazione.
Finalità
Assicurare la sicurezza delle informazioni quando il personale lavora a distanza.
Guida
Il lavoro a distanza si verifica ogni volta che il personale dell'organizzazione lavora da un
luogo al di fuori dei locali dell'organizzazione, accedendo alle informazioni in formato
cartaceo o elettronico con apparecchiature informatiche. Il lavoro a distanza comprende il
"telelavoro", i "luoghi di lavoro flessibile", gli "ambienti di lavoro virtuali" e la
"manutenzione a distanza".
Nota È possibile che non tutte le raccomandazioni di questa guida possano essere applicate a causa delle norme
di legge e dei regolamenti locali nelle diverse giurisdizioni.
Le organizzazioni che consentono il lavoro a distanza dovrebbero emanare una politica
specifica sul lavoro a distanza che definisca le condizioni e le limitazioni pertinenti. Ove
ritenuto applicabile, dovrebbero essere considerati i seguenti aspetti:
a) la sicurezza fisica esistente o proposta del sito di lavoro a distanza, tenendo conto
della sicurezza fisica del luogo e dell'ambiente specifico, comprese le diverse
giurisdizioni in cui si trova il personale;
b) regole e meccanismi di sicurezza per l'ambiente fisico a distanza come schedari con
serratura, trasporto sicuro tra luoghi e regole per l'accesso da distanza, scrivania
pulita, stampa e distruzione di informazioni e asset relativi e segnalazione di eventi
relativi alla sicurezza delle informazioni (vedere 6.8);
c) gli ambienti fisici previsti per il lavoro a distanza ;
d) i requisiti di sicurezza delle comunicazioni, tenendo conto della necessità di accesso
da distanza ai sistemi dell'organizzazione, della sensibilità delle informazioni a cui
accedere e da trasmettere attraverso il canale di comunicazione e della sensibilità
dei sistemi e delle applicazioni;
e) l'uso di strumenti di accesso da distanza, come l'accesso al desktop virtuale, che
supportino l’elaborazione e la conservazione delle informazioni su apparecchiature
personali;
f) la minaccia di accesso non autorizzato a informazioni o risorse da parte di altre
persone presenti sul luogo di lavoro a distanza (per esempio familiari e amici);
g) la minaccia di accesso non autorizzato a informazioni o risorse da parte di altre
persone in luoghi pubblici;
h) l'utilizzo delle reti domestiche e delle reti pubbliche, nonché i requisiti o le limitazioni
alla configurazione dei servizi di rete wireless;
i) utilizzo di misure di sicurezza, quali firewall e di protezione contro malware;
j) meccanismi sicuri per attivare e inizializzare i sistemi da distanza;
k) meccanismi sicuri per l'autenticazione e l'abilitazione dei privilegi di accesso,
tenendo conto della vulnerabilità dei meccanismi di autenticazione a fattore singolo
nei casi in cui è consentito l'accesso da distanza alla rete dell'organizzazione.
Le linee guida e le misure da considerare dovrebbero includere:
a) la fornitura di attrezzature idonee e archivi per le attività di lavoro a distanza, ove non
sia consentito l'uso di attrezzature personali che non siano sotto il controllo
b) una definizione del lavoro consentito, la classificazione delle informazioni che
possono essere tenute e i sistemi e servizi interni a cui il lavoratore a distanza è
autorizzato ad accedere;
c) la formazione per chi lavora a distanza e per chi fornisce supporto. Ciò dovrebbe
includere come svolgere le attività in modo sicuro mentre si lavora a distanza;

d) la fornitura di adeguate apparecchiature di comunicazione, compresi i metodi per
assicurare l'accesso a distanza, come i requisiti sul blocco dello schermo dei
dispositivi e sui tempi di inattività; l'abilitazione del rilevamento della posizione del
dispositivo; l’installazione di funzionalità di cancellazione remota;
e) sicurezza fisica;
f) regole e linee guida sull'accesso dei familiari e dei visitatori alle attrezzature e alle
informazioni;
g) la messa a disposizione di supporto e manutenzione hardware e software;
h) la messa a disposizione di assicurazioni;
i) le procedure di backup e di continuità operativa;
j) audit e monitoraggio della sicurezza;
k) le modalità di revoca delle autorizzazioni e dei diritti di accesso e di restituzione delle
attrezzature al termine delle attività di lavoro a distanza.
Altre informazioni
6.8 Segnalazione degli eventi relativi alla sicurezza delle informazioni
informazioni
#Integrity
#Availability
Controllo
L'organizzazione dovrebbe fornire un meccanismo che consenta al personale di
segnalare tempestivamente, attraverso canali appropriati, gli eventi relativi alla sicurezza
delle informazioni osservati o sospetti.
Finalità
Supportare la segnalazione tempestiva, coerente ed efficace degli eventi relativi alla
sicurezza delle informazioni che possono essere identificati dal personale.
Guida
Tutto il personale e gli utenti dovrebbero essere informati della loro responsabilità di
segnalare gli eventi relativi alla sicurezza delle informazioni il più rapidamente possibile al
fine di prevenire o ridurre al minimo gli effetti degli incidenti relativi alla sicurezza delle
informazioni. Dovrebbero inoltre essere a conoscenza della procedura per la
segnalazione degli eventi relativi alla sicurezza delle informazioni e del punto di contatto
a cui dovrebbero essere segnalati gli eventi. Il meccanismo di segnalazione dovrebbe
essere il più semplice, accessibile e disponibile possibile. Gli eventi relativi alla sicurezza
delle informazioni includono incidenti, violazioni e vulnerabilità.
Le situazioni da considerare per la segnalazione degli eventi relativi alla sicurezza delle
informazioni includono:
a) inefficace controllo della sicurezza delle informazioni;
b) violazione di riservatezza, integrità o disponibilità delle informazioni;
c) errori umani;
d) mancato rispetto della politica per la sicurezza delle informazioni, delle politiche
specifiche o delle norme applicabili;
e) violazioni delle misure di sicurezza fisica;
f) cambiamenti del sistema che non hanno seguito il processo di gestione dei
cambiamenti;
g) malfunzionamenti o altri comportamenti anomali dei sistemi software o hardware;

h) violazioni di accesso;
i) vulnerabilità;
j) sospetta infezione da malware.
Il personale e gli utenti dovrebbero essere avvisati di non tentare di sfruttare le
vulnerabilità sospette relative alla sicurezza delle informazioni. Un test delle vulnerabilità
può essere interpretato come un potenziale uso improprio del sistema e può anche
causare danni al sistema informativo o al servizio e può corrompere o oscurare le prove
digitali. In definitiva, ciò può comportare una responsabilità legale per l'individuo che
esegue i test.
Altre informazioni
Vedere la serie ISO/IEC 27035 per ulteriori informazioni.
7 CONTROLLI FISICI
7.1 Perimetro di sicurezza fisica
informazioni
#Preventive #Confidentiality #Protect #Physical_security #Protection
#Integrity
#Availability
Controllo
I perimetri di sicurezza dovrebbero essere definiti e utilizzati per proteggere le aree che
contengono le informazioni e gli altri asset relativi.
Finalità
Prevenire accessi fisici non autorizzati, danni e interferenze alle informazioni
dell'organizzazione e agli altri asset relativi.
Guida
Le seguenti linee guida dovrebbero essere considerate e attuate ove appropriato per i
perimetri di sicurezza fisica:
a) definire i perimetri di sicurezza e l'ubicazione e la robustezza di ciascuno dei
perimetri in conformità con i requisiti di sicurezza delle informazioni relativi agli asset
all'interno del perimetro;
b) avere perimetri fisicamente robusti per un edificio o un sito contenente strutture di
elaborazione delle informazioni (cioè non dovrebbero esserci discontinuità nel
perimetro o aree in cui può verificarsi facilmente un'effrazione). I tetti, i muri, i soffitti
e i pavimenti del sito dovrebbero essere di costruzione solida e tutte le porte esterne
dovrebbero essere adeguatamente protette contro l'accesso non autorizzato con
meccanismi di controllo (per esempio sbarre, allarmi, serrature). Porte e finestre
dovrebbero essere chiuse a chiave quando non presidiate e dovrebbe essere presa
in considerazione la protezione esterna per le finestre, in particolare a livello del
suolo; dovrebbero essere considerati anche i punti di ventilazione;
c) allarmare, monitorare e testare tutte le porte tagliafuoco di un perimetro di sicurezza
congiuntamente ai muri per stabilire il livello di resistenza richiesto secondo norme
adeguate. Dovrebbero operare in modo sicuro anche in caso di malfunzionamento.
Altre informazioni
La protezione fisica può essere ottenuta creando una o più barriere fisiche intorno ai locali
dell'organizzazione e alle strutture di elaborazione delle informazioni.

Un'area sicura può essere un ufficio chiudibile con serratura o più stanze circondate da
una barriera di sicurezza fisica interna continua. Possono essere necessarie barriere e
perimetri aggiuntivi per controllare l'accesso fisico tra aree con requisiti di sicurezza
diversi all'interno del perimetro di sicurezza. L'organizzazione dovrebbe prendere in
considerazione l'adozione di misure di sicurezza fisica che possono essere rafforzate in
caso di aumento delle minacce.
7.2 Controlli di accesso fisico
informazioni
#Integrity #Identity_and_Access_Management
#Availability
Controllo
Le aree sicure dovrebbero essere protette da adeguati controlli all’ingresso e ai punti di
accesso.
Finalità
Assicurare solo l'accesso fisico autorizzato alle informazioni dell'organizzazione e agli
altri asset relativi.
Guida
Generale
I punti di accesso, come le aree di consegna e carico e altri punti in cui persone non
autorizzate possono entrare nelle sedi, dovrebbero essere controllati e, se possibile,
isolati dalle strutture di elaborazione delle informazioni per evitare l'accesso non
autorizzato.
Le seguenti linee guida dovrebbero essere considerate:
a) limitare l'accesso ai siti e agli edifici al solo personale autorizzato. Il processo per la
gestione dei diritti di accesso alle aree fisiche dovrebbe comprendere l’attribuzione,
il riesame periodico, l'aggiornamento e la revoca delle autorizzazioni (vedere 5.18);
b) mantenere e monitorare in modo sicuro un registro fisico o un audit trail elettronico di
tutti gli accessi e proteggere tutti i log (vedere 5.33) e le informazioni sensibili di
autenticazione;
c) l'istituzione e l'attuazione di un processo e di meccanismi tecnici per la gestione degli
accessi alle aree in cui le informazioni sono trattate o conservate. I meccanismi di
autenticazione includono l'uso di carte di accesso, di dati biometrici o di
autenticazione a due fattori come una carta di accesso e un PIN segreto.
Dovrebbero essere prese in considerazione doppie porte di sicurezza per l'accesso
alle aree sensibili;
d) predisporre un'area di accoglienza sorvegliata da personale, o altro mezzo per
controllare l'accesso fisico al sito o all'edificio;
e) ispezionare ed esaminare gli effetti personali del personale e delle parti interessati
all'ingresso e all'uscita;
Nota Possono esistere norme di legge e regolamenti locali in merito alla possibilità di ispezionare gli effetti
personali.
f) richiedere a tutto il personale e alle parti interessate di indossare una qualche forma
di identificazione visibile e di avvisare immediatamente il personale di sicurezza se
incontra visitatori non accompagnati e chiunque non porti un'identificazione visibile.
Dovrebbero essere presi in considerazione badge facilmente distinguibili per
identificare meglio dipendenti, fornitori e visitatori permanenti;
g) concedere al personale dei fornitori un accesso limitato ad aree sicure o strutture di
elaborazione delle informazioni solo quando richiesto. Questo accesso dovrebbe
essere autorizzato e monitorato;

h) prestare particolare attenzione alla sicurezza degli accessi fisici nel caso di edifici
che detengono asset per più organizzazioni;
i) progettare misure di sicurezza fisica in modo che possano essere rafforzate quando
aumenta la probabilità di incidenti fisici;
j) proteggere altri punti di ingresso come uscite di emergenza da accessi non
autorizzati;
k) istituire un processo di gestione delle chiavi per assicurare la gestione delle chiavi
fisiche o delle informazioni di autenticazione (per esempio codici di chiusura,
serrature di uffici a combinazione, stanze e strutture come armadietti portachiavi) e
per assicurare la presenza di un registro o di un audit annuale delle chiavi e che
l'accesso alle chiavi fisiche o alle informazioni di autenticazione sia controllato
(vedere 5.17 per ulteriori indicazioni sulle informazioni di autenticazione).
Visitatori
a) autenticare l'identità dei visitatori con mezzi adeguati;
b) registrare la data e l'ora di ingresso e di partenza dei visitatori;
c) consentire l'accesso ai visitatori solo per scopi determinati e autorizzati e con
istruzioni sulle esigenze di sicurezza dell'area e sulle procedure di emergenza;
d) vigilare su tutti i visitatori, salvo espressa deroga.
Aree di consegna e carico e materiale in entrata
a) limitare l'accesso alle aree di consegna e carico dall'esterno dell'edificio al personale
identificato e autorizzato;
b) progettare le aree di consegna e carico in modo che le consegne possano essere
caricate e scaricate senza che il personale addetto alle consegne possa accedere
senza autorizzazione ad altre parti dell'edificio;
c) mettere in sicurezza le porte esterne delle aree di consegna e carico quando
vengono aperte le porte delle aree riservate;
d) ispezionare ed esaminare le consegne in arrivo alla ricerca di esplosivi, prodotti
chimici o altri materiali pericolosi prima che vengano spostate dalle aree di
consegna e carico;
e) registrare le consegne in entrata secondo le procedure di gestione degli asset
(vedere 5.9 e 7.10) all'ingresso del sito;
f) separare fisicamente le spedizioni in entrata e in uscita, ove possibile;
g) ispezionare le consegne in arrivo per rilevare eventuali manomissioni in itinere. Se
viene rilevata una manomissione, dovrebbe essere immediatamente segnalata al
personale di sicurezza.
Altre informazioni
7.3 Messa in sicurezza di uffici, locali e strutture
informazioni
#Availability
Controllo
La sicurezza fisica di uffici, stanze e strutture dovrebbe essere progettata e attuata.

Finalità
Prevenire accessi fisici non autorizzati, danni e interferenze alle informazioni
dell'organizzazione e agli asset relativi negli uffici, nei locali e nelle strutture.
Guida
Le seguenti linee guida dovrebbero essere prese in considerazione per proteggere uffici,
locali e strutture:
a) posizionamento delle strutture critiche per evitare l'accesso del pubblico;
b) assicurare, se del caso, che gli edifici non siano appariscenti e forniscano indicazioni
minime in merito al loro utilizzo, senza segni evidenti, all'esterno o all'interno
dell'edificio, che potrebbero segnalare la presenza di attività di elaborazione di
informazioni;
c) configurare strutture per impedire che informazioni o attività riservate siano visibili e
udibili dall'esterno. Anche la schermatura elettromagnetica dovrebbe essere
considerata come appropriata;
d) non mettere a disposizione di persone non autorizzate elenchi di persone, elenchi
telefonici interni e mappe accessibili online che identificano i luoghi dove si trovano
strutture di trattamento di informazioni riservate.
Altre informazioni
7.4 Monitoraggio della sicurezza fisica
informazioni
#Detective #Integrity #Detect #Defence
#Availability
Controllo
Le sedi dovrebbero essere costantemente monitorate per l'accesso fisico non autorizzato.
Finalità
Rilevare e scoraggiare accessi fisici non autorizzati.
Guida
Le sedi fisiche dovrebbero essere monitorate da sistemi di sorveglianza, che possono
includere guardie, allarmi anti-intrusione, sistemi di video sorveglianza, come televisioni a
circuito chiuso, e software di gestione delle informazioni di sicurezza fisica gestiti
internamente o da un fornitore di servizi di monitoraggio.
L'accesso agli edifici che ospitano sistemi critici dovrebbe essere costantemente
monitorato per rilevare accessi non autorizzati o comportamenti sospetti attraverso:
a) l'installazione di sistemi di video sorveglianza, come televisioni a circuito chiuso, per
visualizzare e registrare l'accesso ad aree sensibili all'interno e all'esterno delle sedi
di un'organizzazione;
b) l'installazione, secondo le norme applicabili pertinenti, e la conduzione periodica di
test dei rilevatori di contatto, suono o movimento che possono attivare allarmi di
intrusione come:
1) l’installazione di rilevatori di contatto che attivano un allarme quando un contatto
viene stabilito o interrotto in qualsiasi luogo in cui un contatto può essere stabilito
o interrotto (come finestre e porte e oggetti sottostanti) per attivare allarmi
anti-panico;
2) rilevatori di movimento basati su tecnologia a infrarossi che attivano un allarme
quando un oggetto passa nel loro campo visivo;

3) l’installazione di sensori sensibili al rumore di vetri infranti che possono essere
utilizzati per attivare un allarme per avvertire il personale di sicurezza;
c) l’utilizzo di tali allarmi per coprire tutte le porte esterne e le finestre accessibili. Le
aree non occupate dovrebbero essere sempre allarmate; la copertura dovrebbe
essere prevista anche per altre aree (per esempio sale informatiche o di
comunicazione).
La progettazione dei sistemi di monitoraggio dovrebbe essere mantenuta riservata
perché la divulgazione può facilitare intrusioni senza che siano rilevate.
I sistemi di monitoraggio dovrebbero essere protetti dall'accesso non autorizzato al fine di
impedire l'accesso alle informazioni di sorveglianza, come i collegamenti video, da parte
di persone non autorizzate o la disattivazione dei sistemi da distanza.
Il pannello di controllo del sistema di allarme dovrebbe essere collocato in una zona
allarmata e, per gli allarmi di sicurezza fisica delle persone, in un luogo che consenta una
facile evacuazione alla persona che configura gli allarmi. Il pannello di controllo e i
rivelatori dovrebbero essere dotati di meccanismi di antimanomissione. Il sistema
dovrebbe essere soggetto a test regolari per assicurarsi che funzioni come previsto, in
particolare se i suoi componenti sono alimentati a batteria.
I meccanismi di monitoraggio e registrazione dovrebbero essere utilizzati tenendo conto
delle leggi e dei regolamenti locali, incluse le norme di legge sulla protezione dei dati e dei
dati personali, in particolare per quanto riguarda il monitoraggio del personale e i periodi
di conservazione delle registrazioni video.
Altre informazioni
7.5 Protezione dalle minacce fisiche e ambientali
informazioni
#Integrity
#Availability
Controllo
Dovrebbe essere progettata e attuata la protezione contro le minacce fisiche e ambientali,
come i disastri naturali e altre minacce fisiche intenzionali o non intenzionali
all'infrastruttura.
Finalità
Prevenire o ridurre le conseguenze di eventi originati da minacce fisiche e ambientali.
Guida
Prima di iniziare le operazioni critiche in un sito fisico e a intervalli regolari dovrebbe
essere eseguita una valutazione del rischio per identificare le potenziali conseguenze
delle minacce fisiche e ambientali. Dovrebbero essere attuate le necessarie misure di
protezione e dovrebbero essere monitorati i cambiamenti alle minacce. Si dovrebbe
ottenere una consulenza specialistica su come gestire i rischi derivanti da minacce fisiche
e ambientali come incendi, inondazioni, terremoti, esplosioni, disordini civili, rifiuti tossici,
emissioni e altre forme di calamità naturali o disastri causati da esseri umani.
L'ubicazione fisica e la costruzione delle sedi dovrebbero tenere conto di:
a) topografia locale, come quota adeguata, masse d’acqua e faglie tettoniche;
b) minacce urbane, come luoghi ad alta attrattività di disordini politici, attività criminali o
attacchi terroristici.

Sulla base dei risultati della valutazione del rischio, dovrebbero essere identificate le
minacce fisiche e ambientali pertinenti e dovrebbero essere presi in considerazione
controlli appropriati nei seguenti contesti come per esempio:
a) incendio: installazione e configurazione di sistemi in grado di rilevare
tempestivamente incendi per inviare allarmi o attivare sistemi antincendio al fine di
prevenire danni da incendio ai supporti di memorizzazione e ai relativi sistemi di
elaborazione delle informazioni. L'estinzione degli incendi dovrebbe essere eseguita
utilizzando la sostanza più idonea rispetto all'ambiente circostante (per esempio gas
in spazi confinati);
b) allagamento: installazione di sistemi in grado di rilevare tempestivamente
l'allagamento sotto i pavimenti di aree contenenti supporti di memorizzazione o
sistemi informatici. Pompe dell'acqua o mezzi equivalenti dovrebbero essere
prontamente disponibili in caso di allagamento;
c) sovratensioni elettriche: adottare sistemi in grado di proteggere i sistemi informativi
dei server e dei client da sovratensioni o eventi simili per ridurre al minimo le
conseguenze di tali eventi;
d) esplosivi e armi: eseguire ispezioni casuali per rilevare la presenza di esplosivi o
armi su personale, veicoli o merci che entrano in strutture di elaborazione di
informazioni sensibili.
Altre informazioni
Casseforti o altri tipi di strutture di archiviazione sicura possono proteggere le
informazioni ivi memorizzate da disastri come incendi, terremoti, inondazioni o esplosioni.
Le organizzazioni, quando progettano i controlli per mettere in sicurezza il loro ambiente,
possono considerare i concetti relativi alla prevenzione del crimine e quindi ridurre le
minacce urbane. Per esempio, statue o giochi d'acqua possono fungere sia da elemento
decorativo che da barriera fisica invece dei dissuasori.
7.6 Lavoro in aree sicure
informazioni
#Integrity
#Availability
Controllo
Dovrebbero essere progettate e attuate misure di sicurezza per lavorare in aree sicure.
Finalità
Proteggere le informazioni e gli altri asset relativi in aree sicure da danni e interferenze
non autorizzate da parte del personale che lavora in queste aree.
Guida
Le misure di sicurezza per il lavoro in aree sicure dovrebbero applicarsi a tutto il personale
e coprire tutte le attività che si svolgono nelle aree sicure.
a) sulla base della necessità di conoscere, informare il personale solo dell'esistenza o
delle attività all'interno di un'area sicura;
b) evitare il lavoro non sorvegliato in aree sicure sia per motivi di sicurezza sia per
ridurre le possibilità di attività malevole;
c) bloccare fisicamente e ispezionare periodicamente le aree sicure non occupate;
d) non consentire l’uso di apparecchiature di registrazione fotografiche, video, audio o
di altro tipo, come telecamere negli endpoint degli utenti, a meno che non siano
autorizzate;

e) controllare adeguatamente il trasporto e l'uso degli endpoint degli utenti in aree
sicure;
f) affiggere le procedure di emergenza in modo facilmente visibile o accessibile.
Altre informazioni
7.7 Schermo e scrivania puliti
informazioni
Controllo
Dovrebbero essere definite e opportunamente applicate regole chiare relative ai
documenti cartacei e ai supporti di memorizzazione rimovibili e, per le strutture di
elaborazione delle informazioni, regole chiare relative allo schermo.
Finalità
Ridurre i rischi di accesso non autorizzato, perdita e danneggiamento delle informazioni
trattate su scrivanie, a schermo e in altri luoghi accessibili durante e al di fuori del normale
orario di lavoro.
Guida
L'organizzazione dovrebbe stabilire e comunicare a tutte le parti interessate pertinenti
una politica specifica per la “scrivania pulita” e per lo “schermo pulito”.
a) bloccare le informazioni di business sensibili o critiche (per esempio su carta o su
supporti di memorizzazione elettronici) (idealmente in una cassaforte, in un
armadietto o in un altro tipo di mobilio di sicurezza) quando non sono richieste,
soprattutto quando nell'ufficio non vi sono persone;
b) proteggere gli endpoint degli utenti mediante lucchetti o altri mezzi di sicurezza
quando non utilizzati o non presidiati;
c) lasciare gli endpoint degli utenti disconnessi o protetti con un meccanismo di blocco
dello schermo o della tastiera controllato da un meccanismo di autenticazione degli
utenti quando non presidiato. Tutti i computer e i sistemi dovrebbero essere
configurati con una funzione di time-out o logout automatico;
d) fare in modo che l'originatore raccolga immediatamente gli output dalle stampanti o
dai dispositivi multifunzione. Usare stampanti con funzione di autenticazione, in
modo che gli originatori siano gli unici che possono ottenere le loro stampe e solo
stando accanto alla stampante;
e) conservare in sicurezza documenti e supporti di memorizzazione rimovibili
contenenti informazioni sensibili e, quando non più necessari, eliminarli mediante
meccanismi di smaltimento sicuro;
f) stabilire e comunicare regole e linee guida per la configurazione dei pop-up sugli
schermi (per esempio disattivazione dei pop-up di nuovi messaggi, se possibile,
durante le presentazioni, la condivisione dello schermo o in un'area pubblica);
g) cancellare le informazioni sensibili o critiche da lavagne e altri tipi di strumenti di
visualizzazione quando non più necessarie.
L'organizzazione dovrebbe disporre di procedure in occasione dello sgombero delle
strutture, che includano lo svolgimento di una pulizia finale prima della partenza per
assicurare che gli asset dell'organizzazione non vengano lasciati (per esempio documenti
caduti dietro cassetti o mobili).
Altre informazioni

7.8 Disposizione delle apparecchiature e loro protezione
informazioni
#Availability
Controllo
Le apparecchiature dovrebbero essere posizionate in modo sicuro e protetto.
Finalità
Ridurre i rischi derivanti da minacce fisiche e ambientali e da accessi non autorizzati e
danni.
Guida
Le seguenti linee guida dovrebbero essere considerate per proteggere le
apparecchiature:
a) disporre le apparecchiature in modo da ridurre al minimo gli accessi non necessari
alle aree di lavoro ed evitare accessi non autorizzati;
b) posizionare con cura le strutture di elaborazione delle informazioni che trattano dati
sensibili per ridurre il rischio che le informazioni vengano visualizzate da persone
non autorizzate durante il loro utilizzo;
c) adottare controlli per ridurre al minimo il rischio di potenziali minacce fisiche e
ambientali [per esempio furto, incendio, esplosivi, fumo, acqua (o mancanza di
alimentazione idrica), polvere, vibrazioni, effetti chimici, interferenze
nell'alimentazione elettrica, interferenze nelle comunicazioni, radiazioni
elettromagnetiche e atti vandalici];
d) stabilire linee guida in merito al mangiare, bere e fumare in prossimità di strutture di
elaborazione delle informazioni;
e) monitorare le condizioni ambientali, quali la temperatura e l'umidità, per quelle che
possono influire negativamente sul funzionamento delle strutture di elaborazione
delle informazioni;
f) applicare la protezione contro i fulmini a tutti gli edifici e installare filtri antifulmine su
tutte le linee in ingresso elettriche e di comunicazione;
g) considerare l'utilizzo di particolari metodi di protezione, quali membrane per tastiere,
per le strutture in ambienti industriali;
h) proteggere le apparecchiature che elaborano informazioni riservate per ridurre al
minimo il rischio di fuga di informazioni a causa di emanazioni elettromagnetiche;
i) separare fisicamente le strutture informatiche gestite dall'organizzazione da quelle
non gestite dall'organizzazione.
Altre informazioni
7.9 Sicurezza degli asset all’esterno delle sedi
informazioni
#Availability
Controllo
Gli asset al di fuori delle sedi dovrebbero essere protetti.

Finalità
Prevenire la perdita, il danneggiamento, il furto o la compromissione degli asset al di fuori
delle sedi e l'interruzione delle operazioni dell'organizzazione.
Guida
Tutti i dispositivi utilizzati al di fuori dei locali dell'organizzazione che memorizzano o
elaborano informazioni (per esempio dispositivi mobili), inclusi i dispositivi di proprietà
dell'organizzazione e i dispositivi di proprietà personale e utilizzati per conto
dell'organizzazione (BYOD), necessitano di protezione. L'uso di questi dispositivi
dovrebbe essere autorizzato dalla direzione.
Le seguenti linee guida dovrebbero essere prese in considerazione per la protezione
delle apparecchiature che memorizzano o elaborano informazioni al di fuori dei locali
dell'organizzazione:
a) non lasciare le apparecchiature e i supporti di memorizzazione, quando portati fuori
dalle sedi, incustoditi in luoghi pubblici e insicuri;
b) osservare sempre le istruzioni del produttore per la protezione delle apparecchiature
(per esempio protezione contro l'esposizione a forti campi elettromagnetici, acqua,
calore, umidità, polvere);
c) in caso di trasferimento di apparecchiature fuori sede tra diversi soggetti o parti
interessate, tenere un registro che definisca la catena di custodia delle
apparecchiature e che includa almeno i nomi e le organizzazioni che hanno la
responsabilità delle apparecchiature. Le informazioni che non dovrebbero essere
trasferite con l'asset dovrebbero essere cancellate in modo sicuro prima del
trasferimento;
d) ove necessario e pratico, richiedere l'autorizzazione allo spostamento di
apparecchiature e supporti al di fuori dalle sedi dell'organizzazione e tenere un
registro di tali spostamenti al fine di mantenere un audit trail (vedere 5.14);
e) proteggere dalla visualizzazione delle informazioni da un dispositivo (per esempio
cellulare o laptop) sui mezzi pubblici e dai rischi associati alla visualizzazione da
dietro alle spalle;
f) attuare il tracciamento della posizione e la cancellazione a distanza dei dispositivi.
L'installazione permanente di apparecchiature al di fuori delle sedi dell'organizzazione
[come antenne e sportelli automatici (ATM)] può essere soggetta a un rischio maggiore di
danneggiamento, furto o intercettazione. Questi rischi possono variare
considerevolmente tra luoghi diversi e dovrebbero essere presi in considerazione nel
determinare le misure più appropriate. Le seguenti linee guida dovrebbero essere prese
in considerazione quando si colloca un’apparecchiatura al di fuori dei locali
a) monitoraggio della sicurezza fisica (vedere 7.4);
b) protezione contro le minacce fisiche e ambientali (vedere 7.5);
c) controlli di accesso fisico e antimanomissione;
d) controlli di accesso logico.
Altre informazioni
Ulteriori informazioni su altri aspetti della protezione delle apparecchiature che
memorizzano ed elaborano informazioni e degli endpoint degli utenti sono disponibili in
8.1 e 6.7.

7.10 Supporti di memorizzazione
informazioni
#Availability
Controllo
I supporti di memorizzazione dovrebbero essere gestiti lungo tutto il loro ciclo di vita di
acquisizione, uso, trasporto e smaltimento in conformità con lo schema di classificazione
dell'organizzazione e con i requisiti di trattamento.
Finalità
Assicurare solo la divulgazione, la modifica, la rimozione o la distruzione autorizzate delle
informazioni sui supporti di memorizzazione.
Guida
Supporti di memorizzazione rimovibili
Si dovrebbero considerare le seguenti linee guida per la gestione dei supporti di
memorizzazione rimovibili:
a) stabilire una politica specifica per la gestione dei supporti di memorizzazione
rimovibili e comunicare tale politica specifica a chiunque utilizza o tratta supporti di
memorizzazione rimovibili;
b) ove necessario e pratico, richiedere l'autorizzazione allo spostamento dei supporti di
memorizzazione al di fuori dell'organizzazione e tenere un registro di tali
spostamenti al fine di mantenere un audit trail;
c) conservare tutti i supporti di memorizzazione in un ambiente sicuro a seconda di
come sono state classificate le loro informazioni e proteggerli dalle minacce
ambientali (quali calore, acqua, umidità, campi elettrici e invecchiamento), secondo
le specifiche dei produttori;
d) se la riservatezza o l'integrità delle informazioni sono considerate importanti,
utilizzare tecniche crittografiche per proteggere le informazioni sui supporti di
memorizzazione rimovibili;
e) mitigare il rischio di degrado dei supporti di memorizzazione quando le informazioni
memorizzate sono ancora necessarie, trasferendo le informazioni su nuovi supporti
di memorizzazione prima che diventino illeggibili;
f) memorizzare più copie delle informazioni di valore su supporti di memorizzazione
distinti per ridurre ulteriormente il rischio di danni o perdite accidentali di
informazioni;
g) considerare la registrazione dei supporti di memorizzazione rimovibili per limitare la
possibilità di perdita di informazioni;
h) abilitare le porte per supporti di memorizzazione rimovibili (per esempio slot per
schede SD e porte USB) solo se esiste una ragione dettata dall’organizzazione per
il loro utilizzo;
i) ove vi sia la necessità di utilizzare supporti di memorizzazione rimovibili, monitorare
il trasferimento delle informazioni su tali supporti di memorizzazione;
j) le informazioni possono essere vulnerabili ad accesso non autorizzato, uso
improprio o danneggiamento durante il trasporto fisico, per esempio durante l'invio di
supporti di memorizzazione tramite il servizio postale o tramite corriere.
In questo controllo, i supporti includono i documenti cartacei. Quando si trasferiscono
supporti fisici di memorizzazione, applicare le misure di sicurezza in 5.14.

Riutilizzo e smaltimento sicuro
Dovrebbero essere stabilite procedure per il riutilizzo sicuro e lo smaltimento dei supporti
di memorizzazione per ridurre al minimo il rischio di fuga di informazioni riservate a
persone non autorizzate. Le procedure per il riutilizzo sicuro e lo smaltimento dei supporti
di memorizzazione contenenti informazioni riservate dovrebbero essere proporzionate
alla sensibilità di tali informazioni. Dovrebbero essere considerati i seguenti elementi:
a) se i supporti di memorizzazione contenenti informazioni riservate devono essere
riutilizzati all'interno dell'organizzazione, eliminare in modo sicuro i dati o formattare
i supporti di memorizzazione prima del riutilizzo (vedere 8.10);
b) smaltire in modo sicuro i supporti di memorizzazione contenenti informazioni
riservate quando non sono più necessari (per esempio distruggendo, triturando o
eliminando in modo sicuro il contenuto);
c) disporre di procedure per identificare gli elementi che possono richiedere uno
smaltimento sicuro;
d) molte organizzazioni offrono servizi di raccolta e smaltimento dei supporti di
memorizzazione. Occorre prestare attenzione nella selezione di un fornitore esterno
idoneo con controlli ed esperienza adeguati;
e) registrare lo smaltimento di oggetti sensibili al fine di mantenere un audit trail;
f) quando si accumulano supporti di memorizzazione per lo smaltimento, tenere conto
dell'effetto di aggregazione, che può far diventare sensibile una grande quantità di
informazioni non sensibili.
Dovrebbe essere eseguita una valutazione del rischio sui dispositivi danneggiati
contenenti dati sensibili per determinare se gli oggetti devono essere distrutti fisicamente
piuttosto che inviati per la riparazione o scartati (vedere 7.14).
Altre informazioni
Quando le informazioni riservate sui supporti di memorizzazione non sono crittografate,
dovrebbe essere presa in considerazione una protezione fisica aggiuntiva dei supporti di
memorizzazione.
7.11 Infrastrutture di supporto
informazioni
#Preventive #Integrity #Protect #Physical_security #Protection
#Detective #Availability #Detect
Controllo
Le strutture di elaborazione delle informazioni dovrebbero essere protette da interruzioni
di corrente e altre interruzioni causate da guasti nelle infrastrutture di supporto.
Finalità
Prevenire la perdita, il danneggiamento o la compromissione di informazioni e degli altri
asset relativi, o l'interruzione delle operazioni dell'organizzazione a causa di guasti o di
interruzioni delle infrastrutture di supporto.
Guida
Le organizzazioni dipendono dai servizi di pubblica utilità (per esempio elettricità,
telecomunicazioni, approvvigionamento idrico, gas, fognature, ventilazione e aria
condizionata) per supportare le proprie strutture di elaborazione delle informazioni.
Pertanto, l'organizzazione dovrebbe:
a) assicurare che le apparecchiature a supporto delle infrastrutture siano configurate,
gestite e mantenute in conformità con le specifiche del produttore pertinente;
b) assicurare che le infrastrutture siano valutate regolarmente per la loro capacità di
soddisfare la crescita del business e le interazioni con altre infrastrutture di supporto;

c) assicurare che le apparecchiature a supporto delle infrastrutture siano regolarmente
ispezionate e siano condotti regolarmente test per assicurarne il corretto
funzionamento;
d) se necessario, attivare allarmi per rilevare malfunzionamenti delle infrastrutture;
e) se necessario, assicurarsi che le infrastrutture dispongano di più alimentazioni con
instradamento fisico diverso;
f) assicurare che, se collegate a una rete informatica, le apparecchiature a supporto
delle infrastrutture si trovino su una rete separata dalle strutture di elaborazione delle
informazioni;
g) assicurare che le apparecchiature a supporto delle infrastrutture siano connesse a
Internet solo quando necessario e solo in modo sicuro.
Dovrebbero essere previste illuminazione e segnalazioni di emergenza. Gli interruttori di
emergenza e le valvole per interrompere l'alimentazione, l'acqua, il gas o altre
infrastrutture dovrebbero essere posizionati vicino alle uscite di emergenza o ai locali
tecnici. I contatti di emergenza dovrebbero essere registrati e resi disponibili al personale
in caso di interruzione di corrente.
Altre informazioni
È possibile ottenere ridondanza aggiuntiva per la connettività di rete tramite percorsi
multipli da più di un fornitore di servizi pubblici.
7.12 Sicurezza dei cablaggi
informazioni
#Availability
Controllo
I cavi che trasportano alimentazione, dati o servizi informativi di supporto dovrebbero
essere protetti da intercettazioni, interferenze o danni.
Finalità
Prevenire la perdita, il danneggiamento, il furto o la compromissione di informazioni e
degli altri asset relativi e l'interruzione delle operazioni dell'organizzazione dovuti ai cavi di
alimentazione e comunicazione.
Guida
Si dovrebbero considerare le seguenti linee guida per la sicurezza del cablaggio:
a) nelle strutture di elaborazione delle informazioni, avere le linee elettriche e di
telecomunicazione interrate, ove possibile, o soggette ad adeguate protezioni
alternative, quali pedane passacavi sul pavimento e colonne multipresa; se i cavi
sono interrati, proteggerli da tagli accidentali (per esempio con condutture blindate o
segnali di presenza);
b) separare i cavi di alimentazione dai cavi di comunicazione per prevenire le
interferenze;
c) per i sistemi sensibili o critici, ulteriori controlli da considerare includono:
1) installazione di condutture blindate e locali o cassette chiuse e allarmi nei punti
di ispezione e terminazione;
2) utilizzo di schermature elettromagnetiche a protezione dei cavi;
3) controlli tecnici periodici e ispezioni fisiche per rilevare dispositivi non autorizzati
attaccati ai cavi;
4) accesso controllato ai quadri d'interconnessione e alle cabine di cablaggio (per
esempio con chiavi meccaniche o PIN);
5) utilizzo di cavi in fibra ottica;

d) etichettatura dei cavi a ciascuna estremità con sufficienti dettagli sull’origine e sulla
destinazione per consentire l'identificazione fisica e l'ispezione del cavo.
Si dovrebbe richiedere una consulenza specialistica su come gestire i rischi derivanti da
incidenti al cablaggio o malfunzionamenti.
Altre informazioni
A volte i cavi di alimentazione e telecomunicazione sono risorse condivise per più
organizzazioni che occupano locali in comune.
7.13 Manutenzione delle apparecchiature
informazioni
#Integrity #Asset_management #Resilience
#Availability
Controllo
Le apparecchiature dovrebbero essere mantenute correttamente per assicurare la
disponibilità, l'integrità e la riservatezza delle informazioni.
Finalità
Prevenire la perdita, il danneggiamento, il furto o la compromissione di informazioni e
degli altri asset relativi e l'interruzione delle operazioni dell'organizzazione causate dalla
mancanza di manutenzione.
Guida
Dovrebbero essere considerate le seguenti linee guida per la manutenzione delle
apparecchiature:
a) mantenere le apparecchiature in conformità alla frequenza e alle specifiche di
servizio raccomandate dal fornitore;
b) attuare e monitorare, da parte dell'organizzazione, un programma di manutenzione;
c) far effettuare riparazioni e manutenzioni sulle apparecchiature solo al personale di
manutenzione autorizzato;
d) tenere traccia di tutti i guasti sospetti o reali e di tutte le manutenzioni preventive e
correttive;
e) attuare adeguati controlli quando è programmata la manutenzione delle
apparecchiature, considerando se tale manutenzione è eseguita da personale
interno o esterno all'organizzazione; sottoporre il personale addetto alla
manutenzione a un adeguato accordo di riservatezza;
f) supervisionare il personale addetto alla manutenzione durante l'esecuzione della
manutenzione in loco;
g) autorizzare e controllare l'accesso per la manutenzione da distanza;
h) applicare le misure di sicurezza per gli asset all’esterno delle sedi (vedere 7.9) se,
per manutenzione, le apparecchiature contenenti informazioni vengono spostate al
di fuori della sede;
i) adempiere a tutti i requisiti relativi alla manutenzione imposti dall'assicurazione;
j) prima di rimettere in funzione l'apparecchiatura dopo la manutenzione, ispezionarla per
verificare che l'apparecchiatura non sia stata manomessa e funzioni correttamente;
k) applicare misure per lo smaltimento e il riutilizzo sicuro delle apparecchiature
(vedere 7.14) quando si stabilisce che le apparecchiature vanno smaltite.
Altre informazioni
Le apparecchiature includono: componenti tecnici di strutture di elaborazione delle informazioni,
UPS e batterie, generatori di corrente, alternatori e convertitori di potenza, sistemi di rilevamento
delle intrusioni fisiche e allarme, rilevatori di fumo, estintori, aria condizionata e ascensori.

7.14 Dismissione sicura o riutilizzo delle apparecchiature
informazioni
#Asset_management
Controllo
Prima del loro smaltimento o riutilizzo, gli elementi delle apparecchiature contenenti
supporti di memorizzazione dovrebbero essere verificati per assicurare che tutti i dati
sensibili e il software in licenza siano stati rimossi o sovrascritti in modo sicuro.
Finalità
Prevenire la perdita di informazioni dalle apparecchiature da smaltire o riutilizzare.
Guida
Le apparecchiature dovrebbero essere verificate per accertare la presenza o meno di
supporti di memorizzazione prima dello smaltimento o del riutilizzo.
I supporti di memorizzazione contenenti informazioni riservate o sottoposte a diritto
d’autore dovrebbero essere fisicamente distrutti oppure le informazioni dovrebbero
essere distrutte, cancellate o sovrascritte utilizzando tecniche per rendere le informazioni
originali non recuperabili e non utilizzando la funzione di eliminazione standard. Vedere
7.10 per indicazioni dettagliate sullo smaltimento sicuro dei supporti di memorizzazione e
8.10 per indicazioni sull'eliminazione delle informazioni.
Le etichette e i contrassegni che identificano l'organizzazione o indicano la
classificazione, il responsabile, il sistema o la rete dovrebbero essere rimossi prima dello
smaltimento (che include anche la rivendita e la donazione in beneficenza).
Al termine del contratto di locazione o quando l’apparecchiatura lascia la sede fisica,
l'organizzazione dovrebbe prendere in considerazione la rimozione dei controlli per la
sicurezza come i controlli di accesso o le apparecchiature di sorveglianza. Questo
dipende da fattori quali:
a) gli accordi, nell’ambito della locazione, per riportare le strutture alle condizioni
originali;
b) la riduzione al minimo del rischio di lasciare i sistemi con informazioni sensibili su di
essi per il successivo locatario (per esempio elenchi degli utenti con diritti di
accesso, file video o immagini);
c) la possibilità di riutilizzare i controlli presso la nuova struttura.
Altre informazioni
Le apparecchiature danneggiate contenenti supporti di memorizzazione possono
richiedere una valutazione del rischio per determinare se gli elementi devono essere
fisicamente distrutti o inviati per la riparazione o scartati. Le informazioni possono essere
compromesse da uno smaltimento incauto o dal riutilizzo delle apparecchiature.
Oltre alla cancellazione sicura del disco, la crittografia dell'intero disco riduce il rischio di
divulgazione di informazioni riservate quando le apparecchiature vengono eliminate o
riassegnate, a condizione che:
a) il processo di crittografia sia sufficientemente robusto e copra l'intero disco (incluso
lo slack space e i file di swap);
b) le chiavi crittografiche siano sufficientemente lunghe da resistere agli attacchi di
forza bruta;
c) le chiavi crittografiche stesse siano mantenute riservate (per esempio mai
memorizzate sullo stesso disco).
Per ulteriori consigli sulla crittografia, vedere 8.24.

Le tecniche per sovrascrivere in modo sicuro i supporti di memorizzazione differiscono in
base alla tecnologia dei supporti di memorizzazione e al livello di classificazione delle
informazioni sui supporti di memorizzazione. Gli strumenti di sovrascrittura dovrebbero
essere riesaminati per assicurarsi che siano applicabili alla tecnologia del supporto di
memorizzazione.
Vedere la ISO/IEC 27040 per dettagli sulle modalità di sanitizzazione dei supporti di
memorizzazione.
8 CONTROLLI TECNOLOGICI
8.1 Endpoint degli utenti
informazioni
#Availability
Controllo
Le informazioni memorizzate, elaborate o accessibili tramite gli endpoint degli utenti
dovrebbero essere protette.
Finalità
Proteggere le informazioni dai rischi introdotti con l’utilizzo degli endpoint degli utenti.
Guida
Generale
L'organizzazione dovrebbe stabilire una politica specifica per la configurazione e la
gestione sicura degli endpoint degli utenti. Tale politica dovrebbe essere comunicata a
tutto il personale interessato e considerare quanto segue:
a) il tipo di informazioni e il livello di classificazione che gli endpoint degli utenti possono
trattare, elaborare, memorizzare o supportare;
b) registrazione degli endpoint degli utenti;
c) requisiti di protezione fisica;
d) limitazione all'installazione di software (per esempio controllata a distanza dagli
amministratori di sistema);
e) requisiti per il software degli endpoint degli utenti (incluse le versioni software) e per
l'applicazione degli aggiornamenti (per esempio aggiornamento automatico attivo);
f) regole per la connessione ai servizi informatici, alle reti pubbliche o a qualsiasi altra
rete fuori sede (per esempio richiedere l'utilizzo di personal firewall);
g) controlli di accesso;
h) cifratura del dispositivo di memorizzazione;
i) protezione da malware;
j) disabilitazione, cancellazione o blocco a distanza;
k) backup;
l) utilizzo di servizi web e applicazioni web;
m) analisi del comportamento degli utenti finali (vedere 8.16);
n) l'utilizzo di dispositivi rimovibili, compresi i dispositivi di memoria rimovibili, e la
possibilità di disabilitare le porte fisiche (per esempio porte USB);
o) l'uso di funzionalità di partizionamento, se supportate dall’endpoint, che possono
separare in modo sicuro le informazioni dell'organizzazione e gli altri asset relativi
(per esempio software) da altre informazioni e gli altri asset relativi sul dispositivo.

È opportuno valutare se determinate informazioni sono così sensibili da essere solo
accessibili tramite gli endpoint degli utenti, ma non memorizzate su tali dispositivi. In
questi casi, possono essere richieste ulteriori misure di sicurezza sul dispositivo. Per
esempio, assicurarsi che siano disabilitati il download di file per il lavoro offline e la
memorizzazione locale come per esempio su scheda SD.
Per quanto possibile, le raccomandazioni di questo controllo dovrebbero essere applicate
attraverso la gestione della configurazione (vedere 8.9) o strumenti automatizzati.
Responsabilità degli utenti
Tutti gli utenti dovrebbero essere informati dei requisiti e delle procedure di sicurezza per
la protezione degli endpoint degli utenti, nonché delle loro responsabilità nell'attuazione di
tali misure di sicurezza. Gli utenti dovrebbero essere consigliati di:
a) disconnettere le sessioni attive e terminare i servizi quando non sono più necessari;
b) proteggere gli endpoint degli utenti dall'uso non autorizzato con un controllo fisico
(per esempio blocco tasti o blocchi speciali) e un controllo logico (per esempio
accesso tramite password) quando non sono in uso; non lasciare incustoditi i
dispositivi che trasportano informazioni di business importanti, sensibili o critiche;
c) utilizzare i dispositivi con particolare attenzione in luoghi pubblici, uffici open space,
luoghi di incontro e altre aree non protette (per esempio evitare di leggere
informazioni riservate se le persone possono leggere da dietro alle spalle, utilizzare
filtri privacy screen);
d) proteggere fisicamente gli endpoint degli utenti contro i furti (per esempio in
automobili e altri mezzi di trasporto, camere d'albergo, centri congressi e luoghi di
incontro).
Dovrebbe essere stabilita una procedura specifica che tenga conto dei requisiti legali,
statutari, normativi, contrattuali (inclusa l'assicurazione) e degli altri requisiti di sicurezza
dell'organizzazione per i casi di furto o smarrimento degli endpoint degli utenti.
Utilizzo di dispositivi personali
Laddove l'organizzazione consente l'uso di dispositivi personali (a volte noto come
BYOD), oltre alle indicazioni fornite in questo controllo, si dovrebbe considerare quanto
segue:
a) separazione dell'uso personale e di business dei dispositivi, compreso l'utilizzo di
software per supportare tale separazione e protezione dei dati di business su un
dispositivo privato;
b) fornire l'accesso alle informazioni di business solo dopo che gli utenti hanno
riconosciuto i propri doveri (protezione fisica, aggiornamento software, ecc.),
rinunciando alla proprietà dei dati di business, consentendo la cancellazione a
distanza dei dati da parte dell'organizzazione in caso di furto o smarrimento del
dispositivo o quando non più autorizzato a utilizzare il servizio. In tali casi,
dovrebbero essere prese in considerazione le norme di legge sulla protezione dei
dati personali;
c) politiche e procedure specifiche per prevenire controversie sui diritti di proprietà
intellettuale sviluppata su apparecchiature di proprietà privata;
d) l'accesso ad apparecchiature di proprietà privata (per verificare la sicurezza della
macchina o durante un'indagine), che può essere impedito dalle norme di legge;
e) accordi di licenza software tali che le organizzazioni possano diventare responsabili
della licenza per i software client su endpoint degli utenti di proprietà privata del
personale o di utenti esterni.
Connessioni wireless
L'organizzazione dovrebbe stabilire procedure per:
a) la configurazione delle connessioni wireless sui dispositivi (per esempio
disabilitazione dei protocolli vulnerabili);
b) utilizzare connessioni wireless o cablate con larghezza di banda adeguata in
conformità alle politiche specifiche (per esempio perché sono necessari backup o
aggiornamenti software).

Altre informazioni
I controlli per proteggere le informazioni sugli endpoint degli utenti dipendono dal fatto che
gli endpoint degli utenti vengono utilizzati solo all'interno dei locali protetti
dell'organizzazione e delle connessioni di rete o se sono esposti a maggiori minacce
fisiche e correlate alla rete al di fuori dell'organizzazione.
Le connessioni wireless per gli endpoint degli utenti sono simili ad altri tipi di connessioni
di rete, ma presentano differenze importanti che dovrebbero essere considerate quando
si identificano i controlli. In particolare, il backup delle informazioni memorizzate sugli
endpoint degli utenti a volte può non riuscire a causa della larghezza di banda di rete
limitata o perché gli endpoint degli utenti non sono collegati negli orari in cui sono
pianificati i backup.
Per alcune porte USB, come USB-C, non è possibile disabilitare la porta USB perché
viene utilizzata per altri scopi (per esempio erogazione di potenza e uscita del display).
8.2 Diritti di accesso privilegiato
informazioni
#Integrity
#Availability
Controllo
L'assegnazione e l'uso dei diritti di accesso privilegiato dovrebbero essere limitati e
gestiti.
Finalità
Assicurare che solo agli utenti, ai componenti software e ai servizi autorizzati, vengano
forniti diritti di accesso privilegiato.
Guida
L'assegnazione dei diritti di accesso privilegiato dovrebbe essere controllata attraverso un
processo di autorizzazione in conformità con la specifica politica per il controllo degli
accessi (vedere 5.15). Occorre considerare quanto segue:
a) identificare gli utenti che necessitano di diritti di accesso privilegiato per ciascun
sistema o processo (per esempio sistemi operativi, sistemi di gestione di database e
applicazioni);
b) attribuire i diritti di accesso privilegiato agli utenti secondo necessità ed evento per
evento, in linea con la politica per il controllo degli accessi (vedere 5.15) (ossia solo
a soggetti con le competenze necessarie per svolgere le attività che richiedono
l’accesso privilegiato e sulla base dei requisiti minimi per i loro ruoli funzionali);
c) mantenere un processo di autorizzazione (ossia determinare chi può approvare i
diritti di accesso privilegiato o non concedere diritti di accesso privilegiato fino al
completamento del processo di autorizzazione) e un registro di tutti i privilegi
assegnati;
d) definire e attuare i requisiti per la scadenza dei diritti di accesso privilegiato;
e) adottare misure per assicurare che gli utenti siano a conoscenza dei propri diritti di
accesso privilegiato e quando si trovano in modalità di accesso privilegiato. Le
possibili misure includono l'uso di identità utente specifiche, impostazioni
dell'interfaccia utente o persino apparecchiature specifiche;
f) i requisiti di autenticazione per i diritti di accesso privilegiato possono essere
superiori ai requisiti per i normali diritti di accesso. Prima di lavorare con diritti di
accesso privilegiato può essere necessaria una nuova autenticazione o un
incremento di autenticazione;

g) riesaminare regolarmente, e dopo ogni cambiamento organizzativo, gli utenti che
lavorano con diritti di accesso privilegiato al fine di verificare se i loro compiti, ruoli,
responsabilità e competenze li abilitano ancora a lavorare con diritti di accesso
privilegiato (vedere 5.18);
h) stabilire regole specifiche al fine di evitare l'utilizzo di user ID di amministrazione
generiche (come per esempio “root”), in funzione delle capacità di configurazione dei
sistemi. Gestire e proteggere le informazioni di autenticazione di tali identità (vedere
5.17);
i) concedere un accesso privilegiato temporaneo solo per la finestra temporale
necessaria all'attuazione di cambiamenti o attività approvate (per esempio per
attività di manutenzione o alcuni cambiamenti critici), anziché concedere
permanentemente diritti di accesso privilegiato. Questa è spesso indicata come
procedura di emergenza ed è spesso automatizzata con tecnologie per la gestione
degli accessi privilegiati;
j) registrare tutti gli accessi privilegiati al sistema a fini di audit;
k) non condividere o collegare identità con diritti di accesso privilegiato a più persone,
attribuendo a ciascuna persona un'identità separata che consenta di assegnare
specifici diritti di accesso privilegiato. Le identità possono essere raggruppate (per
esempio definendo un gruppo di amministratori) in modo da semplificare la gestione
dei diritti di accesso privilegiato;
l) utilizzare solo identità con diritti di accesso privilegiato per svolgere compiti
amministrativi e non per attività quotidiane generali [per esempio controllo della
posta elettronica, accesso al web (gli utenti dovrebbero avere un'identità di rete
normale separata per queste attività)].
Altre informazioni
I diritti di accesso privilegiato sono diritti di accesso forniti a un'identità, un ruolo o un
processo che consente l'esecuzione di attività che utenti o processi tipicamente non
possono eseguire. I ruoli di amministratore di sistema in genere richiedono diritti di
accesso privilegiato.
L'uso inappropriato dei privilegi di amministratore di sistema (qualsiasi funzione o
struttura di un sistema informativo che consente all'utente di ignorare i controlli del
sistema o dell'applicazione) è un fattore che contribuisce in modo determinante ai guasti
o alle violazioni dei sistemi.
Maggiori informazioni relative alla gestione degli accessi e alla gestione sicura degli
accessi alle informazioni e alle risorse delle tecnologie dell'informazione e della
comunicazione sono disponibili nella ISO/IEC 29146.
8.3 Limitazione degli accessi alle informazioni
informazioni
#Integrity
#Availability
Controllo
Gli accessi alle informazioni e agli altri asset relativi dovrebbero essere limitati in
conformità con la politica specifica per il controllo degli accessi.
Finalità
Assicurare solo gli accessi autorizzati e impedire gli accessi non autorizzati alle
informazioni e agli altri asset relativi.

Guida
Gli accessi alle informazioni e agli altri asset relativi dovrebbero essere limitati in
conformità con le politiche specifiche stabilite. Al fine di supportare i requisiti di limitazione
degli accessi, si dovrebbe considerare quanto segue:
a) non consentire gli accessi a informazioni sensibili da parte di utenti sconosciuti o in
forma anonima. Gli accessi pubblici o anonimi dovrebbero essere concessi solo
nelle aree di memorizzazione che non contengono informazioni sensibili;
b) fornire meccanismi di configurazione per controllare gli accessi alle informazioni nei
sistemi, nelle applicazioni e nei servizi;
c) controllare a quali dati può accedere un determinato utente;
d) controllare quali identità o gruppo di identità hanno accesso, in lettura, scrittura,
cancellazione ed esecuzione;
e) fornire controlli di accesso fisico o logico per l'isolamento di applicazioni, dati
applicativi o sistemi sensibili.
Inoltre, le tecniche e i processi di gestione degli accessi dinamici per proteggere le
informazioni sensibili che hanno un valore elevato per l'organizzazione, dovrebbero
essere presi in considerazione quando l'organizzazione:
a) necessita di un controllo granulare su chi può accedere a tali informazioni, in quale
periodo e in che modo;
b) desidera condividere tali informazioni con persone esterne all'organizzazione e
mantenere il controllo su chi può accedervi;
c) vuole gestire dinamicamente, in tempo reale, l'utilizzo e la distribuzione di tali
informazioni;
d) vuole proteggere tali informazioni da cambiamenti, copie e distribuzioni (inclusa la
stampa) non autorizzate;
e) vuole monitorare l'utilizzo delle informazioni;
f) desidera registrare eventuali cambiamenti a tali informazioni che intervengono nel
caso in cui sia necessaria un'indagine futura.
Le tecniche di gestione dinamica degli accessi dovrebbero proteggere le informazioni
durante tutto il loro ciclo di vita (cioè creazione, elaborazione, memorizzazione,
trasmissione e smaltimento) e includono:
a) stabilire regole sulla gestione degli accessi dinamici sulla base di casi d'uso specifici
considerando:
1) concedere autorizzazioni di accesso in base a identità, dispositivo, posizione o
applicazione;
2) sfruttare lo schema di classificazione per determinare quali informazioni
dovrebbero essere protette con tecniche di gestione dinamica degli accessi;
b) stabilire processi operativi, di monitoraggio e di rendicontazione e supportare
l'infrastruttura tecnica.
I sistemi dinamici di gestione degli accessi dovrebbero proteggere le informazioni
attraverso:
a) richiedere l'autenticazione, credenziali idonee o un certificato per accedere alle
informazioni;
b) limitare gli accessi, per esempio in un determinato arco di tempo (per esempio dopo
una data determinata o fino a una data particolare);
c) utilizzare la crittografia per proteggere le informazioni;
d) definire i permessi di stampa delle informazioni;
e) registrare chi accede alle informazioni e come le informazioni vengono utilizzate;
f) allertare se vengono rilevati tentativi di uso improprio delle informazioni.

Altre informazioni
Le tecniche di gestione dinamica degli accessi e altre tecnologie di protezione dinamica
delle informazioni possono supportare la protezione delle informazioni anche quando i
dati sono condivisi al di fuori dell'organizzazione di origine, dove i tradizionali controlli di
accesso non possono essere applicati. Può essere applicato a documenti, messaggi di
posta elettronica o altri file contenenti informazioni per limitare chi può accedere al
contenuto e in che modo. Può essere a livello granulare ed essere adattato durante il ciclo
di vita delle informazioni.
Le tecniche di gestione dinamica degli accessi non sostituiscono la classica gestione
degli accessi [per esempio utilizzando le liste di controllo degli accessi (ACL)], ma
possono aggiungere ulteriori fattori per la condizionalità, la valutazione in tempo reale, la
riduzione dei dati just-in-time e altri miglioramenti che possono essere utili per le
informazioni più sensibili. Offre un modo per controllare l'accesso al di fuori dell'ambiente
dell'organizzazione. La risposta agli incidenti può essere supportata da tecniche di
gestione dinamica degli accessi poiché le autorizzazioni possono essere modificate o
revocate in qualsiasi momento.
Ulteriori informazioni su un quadro di riferimento per la gestione degli accessi sono fornite
8.4 Accesso al codice sorgente
informazioni
#Integrity #Application_security
#Availability #Secure_configuration
Controllo
L'accesso in lettura e scrittura al codice sorgente, agli strumenti di sviluppo e alle librerie
software dovrebbe essere gestito in modo appropriato.
Finalità
Prevenire l'introduzione di funzionalità non autorizzate, evitare cambiamenti non
intenzionali o dannosi e mantenere la riservatezza della proprietà intellettuale di valore.
Guida
L'accesso al codice sorgente e agli elementi associati (come progetti, specifiche, piani di
verifica e piani di validazione) e agli strumenti di sviluppo (per esempio compilatori,
builders, strumenti di integrazione, piattaforme e ambienti di test) dovrebbe essere
rigorosamente controllato.
Per il codice sorgente, ciò può essere ottenuto controllando la memorizzazione centrale di
tale codice, preferibilmente nel sistema di gestione del codice sorgente.
L'accesso in lettura e l'accesso in scrittura al codice sorgente può variare in base al ruolo
del personale. Per esempio, l'accesso in lettura al codice sorgente può essere
ampiamente fornito all'interno dell'organizzazione, ma l'accesso in scrittura al codice
sorgente è reso disponibile solo al personale privilegiato o ai responsabili designati.
Laddove i componenti del codice vengono utilizzati da più sviluppatori all'interno di
un'organizzazione, si dovrebbe attuare l'accesso in lettura a un repository di codice
centralizzato. Inoltre, se all'interno di un'organizzazione vengono utilizzati codice open
source o componenti di codice di terze parti, l'accesso in lettura a tali repository esterni di
codice può essere ampiamente fornito. Tuttavia, l'accesso in scrittura dovrebbe
comunque essere limitato.
Le seguenti linee guida dovrebbero essere prese in considerazione per controllare
l'accesso alle librerie di sorgenti dei programmi al fine di ridurre la possibilità di corruzione
dei programmi per computer:
a) gestire l'accesso al codice sorgente dei programmi e alle librerie dei sorgenti dei
programmi secondo procedure stabilite;

b) concedere l'accesso in lettura e scrittura al codice sorgente in base alle esigenze di
business e gestirlo per far fronte ai rischi di alterazione o uso improprio e secondo
procedure stabilite;
c) aggiornare il codice sorgente e gli elementi relativi e concedere gli accessi al codice
sorgente secondo le procedure di controllo dei cambiamenti (vedere 8.32) ed
effettuarli solo dopo aver ricevuto idonea autorizzazione;
d) non concedere agli sviluppatori l'accesso diretto al repository del codice sorgente,
ma attraverso strumenti di sviluppo che controllano le attività e le autorizzazioni sul
codice sorgente;
e) tenere gli elenchi dei programmi in un ambiente sicuro, in cui l'accesso in lettura e
scrittura dovrebbe essere gestito e assegnato in modo appropriato;
f) mantenere un registro di controllo di tutti gli accessi e di tutti i cambiamenti al codice
sorgente.
Se il codice sorgente dei programmi è destinato alla pubblicazione, dovrebbero essere
presi in considerazione ulteriori controlli per assicurare la sua integrità (per esempio firma
digitale).
Altre informazioni
Se l'accesso al codice sorgente non è adeguatamente controllato, il codice sorgente può
essere modificato o alcuni dati nell'ambiente di sviluppo (per esempio copie dei dati di
produzione, dettagli di configurazione) possono essere recuperati da persone non
autorizzate.
8.5 Autenticazione sicura
informazioni
#Integrity
#Availability
Controllo
Le tecnologie e le procedure di autenticazione sicura dovrebbero essere attuate in base
alle limitazioni degli accessi alle informazioni e alla politica specifica per il controllo degli
accessi.
Finalità
Assicurare che un utente o un'entità sia autenticata in modo sicuro quando viene
concesso l'accesso a sistemi, applicazioni e servizi.
Guida
Dovrebbe essere scelta una tecnica di autenticazione adeguata per comprovare l'identità
dichiarata di un utente, di un software, di messaggi e di altre entità.
La robustezza dell'autenticazione dovrebbe essere adeguata alla classificazione delle
informazioni a cui accedere. Laddove sia richiesta l'autenticazione forte e la verifica
dell'identità, dovrebbero essere utilizzati metodi di autenticazione alternativi alle
password, come certificati digitali, smart card, token o mezzi biometrici.
Le informazioni di autenticazione dovrebbero essere accompagnate da ulteriori fattori di
autenticazione per l'accesso ai sistemi informativi critici (nota anche come autenticazione
a più fattori). L'utilizzo di una combinazione di più fattori di autenticazione, come ciò che si
sa, ciò che si ha e ciò che si è, riduce le possibilità di accessi non autorizzati.
L'autenticazione a più fattori può essere combinata con altre tecniche per richiedere fattori
aggiuntivi in circostanze specifiche, in base a regole e schemi predefiniti, come l'accesso
da una posizione insolita, da un dispositivo insolito o in un momento insolito.

Le informazioni di autenticazione biometrica dovrebbero essere invalidate se mai
venissero compromesse. L'autenticazione biometrica può non essere disponibile a
seconda delle condizioni d'uso (per esempio umidità o invecchiamento). Per prepararsi a
questi problemi, l'autenticazione biometrica dovrebbe essere accompagnata da almeno
una tecnica di autenticazione alternativa.
La procedura per l'accesso a un sistema o a un'applicazione dovrebbe essere progettata
per ridurre al minimo il rischio di accesso non autorizzato. Le procedure e le tecnologie di
accesso dovrebbero essere attuate tenendo conto di quanto segue:
a) non visualizzare informazioni sensibili di sistema o dell’applicazione fino a quando il
processo di accesso non è stato completato con successo al fine di evitare di fornire
assistenza non necessaria a un utente non autorizzato;
b) visualizzare un avviso generale con l'avvertenza che l'accesso al sistema o
all'applicazione o al servizio è riservato agli utenti autorizzati;
c) non fornire messaggi di aiuto durante la procedura di accesso che possano aiutare
un utente non autorizzato (per esempio se si verifica una condizione di errore, il
sistema non dovrebbe indicare quale parte dei dati è corretta o non corretta);
d) convalidare le informazioni di accesso solo al completamento di tutti i dati inseriti;
e) proteggere contro i tentativi di accesso a forza bruta su username e password (per
esempio utilizzando CAPTCHA, richiedendo il ripristino della password dopo un
numero predefinito di tentativi falliti o bloccando l'utente dopo un numero massimo di
errori);
f) registrare i tentativi falliti e riusciti;
g) segnalare un evento relativo alla sicurezza se viene rilevata una possibile violazione
tentata o riuscita dei controlli di accesso (per esempio invio di un avviso all'utente e
agli amministratori di sistema dell'organizzazione quando è stato raggiunto un certo
numero di tentativi di password errati);
h) visualizzare o inviare le seguenti informazioni su un canale separato al
completamento di un accesso riuscito:
1) data e ora del precedente login riuscito;
2) dettagli di eventuali tentativi di accesso non andati a buon fine dall'ultimo
accesso riuscito;
i) non visualizzare la password in chiaro al momento dell'inserimento; in alcuni casi
può essere richiesta la disattivazione di tale funzionalità per facilitare il log-on degli
utenti (per esempio per motivi di accessibilità o per evitare di bloccare gli utenti a
causa di errori ripetuti);
j) non trasmettere le password in chiaro su una rete per evitare che siano catturate da
un programma "sniffer" di rete;
k) terminare le sessioni inattive dopo un periodo di inattività definito, soprattutto in
luoghi ad alto rischio come aree pubbliche o esterne al di fuori della gestione della
sicurezza dell'organizzazione o sugli endpoint degli utenti;
l) limitare i tempi di durata della connessione per fornire ulteriore sicurezza per le
applicazioni ad alto rischio e ridurre la finestra di opportunità per l'accesso non
autorizzato.
Altre informazioni
Ulteriori informazioni sull'assicurazione di autenticazione delle entità possono essere
trovate nella ISO/IEC 29115.
8.6 Gestione della capacità
informazioni
#Preventive #Integrity #Identify #Protect #Continuity #Governance_and_Ecosystem
#Detective #Availability #Detect #Protection

Controllo
L'uso delle risorse dovrebbe essere monitorato e adeguato in linea con i requisiti di
capacità attuali e previsti.
Finalità
Assicurare la capacità richiesta delle strutture di elaborazione delle informazioni, delle
risorse umane, degli uffici e di altre strutture.
Guida
I requisiti di capacità per le strutture di elaborazione delle informazioni, le risorse umane,
gli uffici e le altre strutture dovrebbero essere identificati, tenendo conto della criticità per
il business dei sistemi e dei processi interessati.
I metodi di ottimizzazione e monitoraggio del sistema dovrebbero essere applicati per
assicurare e, ove necessario, migliorare la disponibilità e l'efficienza dei sistemi.
L'organizzazione dovrebbe eseguire prove di stress dei sistemi e dei servizi per
confermare che è disponibile una capacità dei sistemi sufficiente per soddisfare i requisiti
di prestazione nei momenti di picco.
Dovrebbero essere messi in atto controlli per segnalare i problemi a tempo debito.
Le proiezioni dei requisiti futuri di capacità dovrebbero tenere conto dei nuovi requisiti di
business e di sistema e delle tendenze attuali e previste nelle capacità di elaborazione
delle informazioni dell'organizzazione.
Particolare attenzione dovrebbe essere prestata a tutte le risorse con tempi di
approvvigionamento lunghi o costi elevati. Pertanto, i gestori, i responsabili di servizi o
prodotti dovrebbero monitorare l'utilizzo delle risorse chiave di sistema.
I manager dovrebbero utilizzare le informazioni sulla capacità per identificare ed evitare
potenziali limitazioni delle risorse e dipendenza da personale chiave che può
rappresentare una minaccia per la sicurezza dei sistemi o per i servizi e pianificare le
azioni appropriate.
È possibile ottenere una capacità sufficiente aumentando la capacità o riducendo la
domanda. Per aumentare la capacità si dovrebbe considerare quanto segue:
a) assumere nuovo personale;
b) ottenere nuove strutture o spazi;
c) acquisire sistemi di elaborazione, memoria e storage più potenti;
d) avvalersi del cloud computing, che ha caratteristiche intrinseche che affrontano
direttamente problematiche di capacità. Il cloud computing ha elasticità e scalabilità
che consentono una rapida espansione su richiesta e la riduzione delle risorse
disponibili per particolari applicazioni e servizi.
Quanto segue dovrebbe essere considerato per ridurre la domanda di risorse
a) cancellazione dei dati obsoleti (spazio su disco);
b) smaltimento delle registrazioni cartacee che hanno raggiunto il periodo previsto di
conservazione (liberare spazio sugli scaffali);
c) dismissione di applicazioni, sistemi, database o ambienti;
d) ottimizzazione dei processi batch e delle loro tempistiche;
e) ottimizzazione del codice delle applicazioni o delle query dei database;
f) negazione o limitazione della larghezza di banda per i servizi che richiedono più
risorse se questi non sono critici (per esempio flussi video).
Per i sistemi di importanza critica dovrebbe essere preso in considerazione un piano
documentato di gestione della capacità.
Altre informazioni
Per maggiori dettagli sull'elasticità e la scalabilità del cloud computing, vedere
ISO/IEC TS 23167.

8.7 Protezione dal malware
informazioni
#Preventive #Confidentiality #Protect #System_and_network_security #Protection
#Detective #Integrity #Detect #Information_protection #Defence
#Corrective #Availability
Controllo
La protezione dal malware dovrebbe essere attuata e supportata da un'adeguata
consapevolezza degli utenti.
Finalità
Assicurare che le informazioni e gli altri asset relativi siano protetti dal malware.
Guida
La protezione contro il malware dovrebbe basarsi sulla rilevazione del malware e sul
software di ripristino, sulla consapevolezza della sicurezza delle informazioni,
sull'appropriato accesso ai sistemi e sui controlli di gestione dei cambiamenti. L'impiego
del solo software di rilevamento e di ripristino dal malware non è generalmente adeguato.
Dovrebbero essere considerate le seguenti linee guida:
a) attuare regole e controlli che impediscano o rilevino l'uso di software non autorizzato
[per esempio allowlisting di applicazioni (ossia utilizzare un elenco delle applicazioni
consentite)] (vedere 8.19 e 8.32);
b) attuare controlli che impediscano o rilevino l'uso di siti web dannosi noti o sospetti
(per esempio blocklisting);
c) ridurre le vulnerabilità che possono essere sfruttate dal malware [per esempio
attraverso la gestione delle vulnerabilità tecniche (vedi 8.8 e 8.19)];
d) condurre una regolare validazione automatizzata del software e dei dati contenuti
nei sistemi, in particolare per i sistemi che supportano i processi di business critici;
indagare sulla presenza di eventuali file non approvati o modifiche non autorizzate;
e) stabilire misure di protezione contro i rischi connessi all'ottenimento di file e software
da o tramite reti esterne o qualsiasi altro supporto;
f) installare e aggiornare regolarmente il software di rilevamento e di ripristino dal
malware per scansionare computer e supporti di memorizzazione elettronica.
Eseguire scansioni regolari che includano:
1) scansione, prima dell'uso, di ogni dato ricevuto attraverso reti o tramite qualsiasi
altra forma di supporto elettronico di memorizzazione, alla ricerca di malware;
2) scansione, prima dell'uso, degli allegati dei messaggi di posta elettronica e alla
messaggistica istantanea e dei download alla ricerca di malware. Effettuare
questa scansione in posti diversi (per esempio server di posta elettronica,
computer desktop) e quando si accede alla rete dell'organizzazione;
3) scansione, durante l'accesso, delle pagine web alla ricerca di malware;
g) determinare il posizionamento e la configurazione degli strumenti di rilevamento e
riparazione dal malware sulla base dei risultati della valutazione del rischio e
considerando:
1) i principi di difesa in profondità dove sarebbero più efficaci. Per esempio, ciò può
portare al rilevamento di malware in un gateway di rete (in vari protocolli
applicativi come email, trasferimento file e web) nonché gli endpoint degli utenti
e i server;
2) le tecniche evasive degli aggressori (per esempio l'uso di file cifrati) per fornire
malware o l'uso di protocolli di crittografia per trasmettere malware;
h) avere cura di proteggere dall'introduzione di malware durante le procedure di
manutenzione e di emergenza, che possono aggirare i normali controlli contro i
malware;

i) attuare un processo per autorizzare la disabilitazione temporanea o permanente di
alcune o tutte le misure contro il malware, comprendendo le autorità di approvazione
delle eccezioni, le giustificazioni documentate e le date di riesame. Ciò può essere
necessario quando la protezione contro il malware causa l'interruzione delle normali
attività operative;
j) preparare adeguati piani di continuità operativa per il ripristino da attacchi malware,
compresi tutti i dati necessari e il backup del software (incluso il backup online e
offline) e le misure di ripristino (vedere 8.13);
k) isolare gli ambienti in cui possono verificarsi conseguenze catastrofiche;
l) definire le procedure e le responsabilità per affrontare la protezione contro il malware
sui sistemi, compresa la formazione sul loro utilizzo, la segnalazione e il recupero da
attacchi di malware;
m) fornire consapevolezza o formazione (vedere 6.3) a tutti gli utenti su come
identificare e potenzialmente mitigare la ricezione, l'invio o l'installazione di email, file
o programmi infetti da malware [le informazioni raccolte in n) e o) possono essere
utilizzate per assicurare che la consapevolezza e la formazione vengano mantenute
aggiornate];
n) attuare procedure per raccogliere regolarmente informazioni sui nuovi malware,
come l'iscrizione a mailing list o il riesame di siti web significativi;
o) verificare che le informazioni relative al malware, come i bollettini informativi,
provengano da fonti qualificate e attendibili (per esempio siti Internet affidabili o
fornitori di software di rilevamento del malware) e siano accurate e complete.
Altre informazioni
Non sempre è possibile installare software che protegga dal malware su alcuni sistemi
(per esempio alcuni sistemi di controllo industriale). Alcune forme di malware infettano i
sistemi operativi del computer e il firmware del computer in modo tale che i controlli
malware comuni non possano ripulire il sistema e sia necessario un ripristino completo
del software del sistema operativo e talvolta del firmware del computer per tornare a uno
stato sicuro.
8.8 Gestione delle vulnerabilità tecniche
#Preventive #Confidentiality #identify #Threat_and_vulnerability_management #Governance_and_Ecosystem
#Integrity #Protect #Protection #Defence
#Availability
Controllo
Si dovrebbero ottenere informazioni sulle vulnerabilità tecniche dei sistemi informativi in
uso, valutare l'esposizione dell'organizzazione a tali vulnerabilità e adottare misure
appropriate.
Finalità
Prevenire lo sfruttamento delle vulnerabilità tecniche.
Guida
Identificazione delle vulnerabilità tecniche
L'organizzazione dovrebbe disporre di un accurato inventario degli asset (vedere da 5.9 a
5.14) come prerequisito per un'efficace gestione tecnica delle vulnerabilità; l'inventario
dovrebbe includere il fornitore del software, il nome del software, le versioni, lo stato
attuale di distribuzione (per esempio quale software è installato su quali sistemi) e la(e)
persona(e) all'interno dell'organizzazione responsabile(i) del software.

Per identificare le vulnerabilità tecniche, l'organizzazione dovrebbe considerare:
a) definire e stabilire i ruoli e le responsabilità associati alla gestione delle vulnerabilità
tecniche, compreso il monitoraggio delle vulnerabilità, la valutazione del rischio di
vulnerabilità, l'aggiornamento, il tracciamento degli asset e le eventuali
responsabilità di coordinamento richieste;
b) per il software e le altre tecnologie (sulla base dell’inventario degli asset, vedere 5.9),
identificare le risorse informative che verranno utilizzate per identificare le
vulnerabilità tecniche pertinenti e mantenere la consapevolezza su di esse.
Aggiornare l'elenco delle risorse informative in base ai cambiamenti nell'inventario o
quando vengono trovate altre risorse nuove o utili;
c) richiedere ai fornitori di sistemi informativi (inclusi i loro componenti) di assicurare la
segnalazione, la gestione e la divulgazione delle vulnerabilità, anche attraverso
requisiti nei contratti applicabili (vedere 5.20);
d) utilizzare strumenti di scansione delle vulnerabilità adeguati alle tecnologie in uso
per identificare le vulnerabilità e verificare se l’installazione delle patch delle
vulnerabilità ha avuto successo;
e) condurre penetration test o vulnerability assessment pianificati, documentati e
ripetibili da parte di soggetti competenti e autorizzati a supporto dell'identificazione
delle vulnerabilità. Esercitare cautela in quanto tali attività possono portare a una
compromissione della sicurezza dei sistemi;
f) tenere traccia, per le vulnerabilità, dell'utilizzo di librerie di terze parti e del codice
sorgente. Questo dovrebbe essere incluso nella codifica sicura (vedi 8.28).
L'organizzazione dovrebbe sviluppare procedure e capacità per:
a) rilevare l'esistenza di vulnerabilità nei propri prodotti e servizi, inclusi tutti i
componenti esterni utilizzati in questi;
b) ricevere segnalazioni di vulnerabilità da fonti interne o esterne.
L'organizzazione dovrebbe fornire un punto di contatto pubblico come parte di una politica
specifica per la divulgazione delle vulnerabilità in modo che i ricercatori e altri soggetti
siano in grado di segnalare problemi. Le organizzazioni dovrebbero stabilire procedure di
segnalazione delle vulnerabilità, moduli di segnalazione online e utilizzare appropriati
forum di threat intelligence o di condivisione delle informazioni. Le organizzazioni
dovrebbero anche prendere in considerazione programmi di bug bounty in cui vengono
offerti premi come incentivo per aiutare le organizzazioni a identificare le vulnerabilità al
fine di porvi rimedio in modo appropriato. L'organizzazione dovrebbe inoltre condividere le
informazioni con gli organismi del settore competenti o altre parti interessate.
Valutazione delle vulnerabilità tecniche
Per valutare le vulnerabilità tecniche identificate, dovrebbero essere prese in
considerazione le seguenti linee guida:
a) analizzare e verificare i rapporti di segnalazione per determinare quale attività di
risposta e di remediation è necessaria;
b) una volta individuata una potenziale vulnerabilità tecnica, individuare i rischi
connessi e le azioni da intraprendere. Tali azioni possono comportare
l'aggiornamento di sistemi vulnerabili o l'applicazione di altri controlli.
Adottare misure adeguate per fronteggiare le vulnerabilità tecniche
Si dovrebbe attuare un processo di gestione degli aggiornamenti software per assicurare
che le patch più aggiornate approvate e gli aggiornamenti delle applicazioni siano
installati per tutto il software autorizzato. Se sono necessari cambiamenti, il software
originale dovrebbe essere conservato e i cambiamenti applicati a una copia designata.
Tutti i cambiamenti dovrebbero essere completamente testati e documentati, in modo che
possano essere riapplicati, se necessario, a futuri aggiornamenti del software. Se
necessario, le modifiche dovrebbero essere verificate e convalidate da un organismo di
valutazione indipendente.

Le seguenti linee guida dovrebbero essere prese in considerazione per fronteggiare le
vulnerabilità tecniche:
a) intraprendere azioni adeguate e tempestive in risposta all'identificazione di
potenziali vulnerabilità tecniche; definire una sequenza temporale per reagire alle
notifiche di vulnerabilità tecniche potenzialmente pertinenti;
b) a seconda dell'urgenza con cui deve essere affrontata una vulnerabilità tecnica,
effettuare l'azione secondo i controlli di gestione dei cambiamenti (vedi 8.32) o
seguendo procedure di risposta agli incidenti relativi alla sicurezza delle informazioni
(vedi 5.26);
c) utilizzare solo aggiornamenti da fonti legittime (che possono essere interne o
esterne all'organizzazione);
d) testare e valutare gli aggiornamenti prima della loro installazione per assicurare che
siano efficaci e non determinino effetti collaterali non tollerabili [ossia, se è
disponibile un aggiornamento, valutare i rischi associati all'installazione
dell'aggiornamento (i rischi posti dalla vulnerabilità dovrebbero essere confrontati
con il rischio relativo all'installazione dell'aggiornamento)];
e) affrontare in primo luogo i sistemi ad alto rischio;
f) sviluppare delle remediation (tipicamente sotto forma di aggiornamenti software o di
patch);
g) condurre test per confermare se la remediation o la mitigazione sono efficaci;
h) fornire meccanismi per verificare l'autenticità della remediation;
i) se nessun aggiornamento è disponibile o l'aggiornamento non può essere installato,
considerare altri controlli, quali:
1) applicare qualsiasi soluzione alternativa suggerita dal fornitore del software o da
altre fonti pertinenti;
2) disattivare servizi o funzionalità legate alla vulnerabilità;
3) adattare o aggiungere controlli di accesso (per esempio firewall) ai confini della
rete (vedi da 8.20 a 8.22);
4) proteggere i sistemi, i dispositivi o le applicazioni vulnerabili dagli attacchi tramite
la configurazione di filtri di traffico adeguati (a volte chiamati patch virtuali);
5) aumentare il monitoraggio per rilevare gli attacchi effettivi;
6) aumentare la consapevolezza della vulnerabilità.
Per il software acquistato, se i fornitori rilasciano regolarmente informazioni sugli
aggiornamenti di sicurezza per il loro software e forniscono un sistema per installare tali
aggiornamenti automaticamente, l'organizzazione dovrebbe decidere se utilizzare o
meno l'aggiornamento automatico.
Altre considerazioni
Dovrebbe essere conservato un log per tutte le fasi intraprese nella gestione delle
vulnerabilità tecniche.
Il processo di gestione delle vulnerabilità tecniche dovrebbe essere regolarmente
monitorato e valutato al fine di assicurarne l'efficacia e l'efficienza.
Un efficace processo di gestione delle vulnerabilità tecniche dovrebbe essere allineato con le
attività di gestione degli incidenti, per comunicare i dati sulle vulnerabilità alla funzione di
risposta agli incidenti e fornire procedure tecniche da seguire in caso di incidente.
Laddove l'organizzazione utilizzi un servizio cloud fornito da un fornitore di servizi cloud di
terze parti, la gestione delle vulnerabilità tecniche delle risorse del fornitore di servizi
cloud dovrebbe essere assicurata dal fornitore di servizi cloud. Le responsabilità del
fornitore di servizi cloud per la gestione delle vulnerabilità tecniche dovrebbero essere
parte degli accordi di servizio cloud e ciò dovrebbe includere i processi per segnalare le
azioni del fornitore di servizi cloud relative alle vulnerabilità tecniche (vedere 5.23). Per
alcuni servizi cloud, esistono responsabilità rispettivamente per il fornitore di servizi cloud
e per il cliente del servizio cloud. Per esempio, il cliente del servizio cloud è responsabile
della gestione della vulnerabilità dei propri asset utilizzati per i servizi cloud.

Altre informazioni
La gestione delle vulnerabilità tecniche può essere vista come un sotto-processo della
gestione dei cambiamenti e come tale può trarre vantaggio dai processi e dalle procedure
di gestione dei cambiamenti (vedi 8.32).
Esiste la possibilità che un aggiornamento non risolva il problema in modo adeguato e
abbia effetti collaterali negativi. Inoltre, in alcuni casi, la disinstallazione di un
aggiornamento non può essere eseguita facilmente una volta che l'aggiornamento è stato
applicato.
Se non è possibile un'adeguata verifica degli aggiornamenti (per esempio a causa di costi
o mancanza di risorse) si può considerare un ritardo nell'aggiornamento per valutare i
rischi relativi, sulla base dell'esperienza riportata da altri utenti. L'uso di ISO/IEC 27031
può essere utile.
Laddove vengono prodotte patch o aggiornamenti software, l'organizzazione può
prendere in considerazione l'idea di fornire un processo di aggiornamento automatizzato
in cui questi aggiornamenti vengono installati sui sistemi o sui prodotti interessati senza
che sia necessario l'intervento del cliente o dell'utente. Se viene offerto un processo di
aggiornamento automatico, può consentire al cliente o all'utente di scegliere un'opzione
per disattivare l'aggiornamento automatico o controllare i tempi di installazione
dell'aggiornamento.
Laddove il fornitore fornisce un processo di aggiornamento automatizzato e gli
aggiornamenti possono essere installati sui sistemi o sui prodotti interessati senza la
necessità di intervento, l'organizzazione determina se applicare o meno il processo
automatizzato. Uno dei motivi per non scegliere l'aggiornamento automatico è mantenere
il controllo su quando viene eseguito l'aggiornamento. Per esempio, un software utilizzato
per un'operazione di business non può essere aggiornato fino al completamento
dell’attività operativa.
Un punto debole delle scansioni di vulnerabilità è che potrebbero non tenere pienamente
conto della difesa in profondità: due contromisure che vengono sempre attivate in
sequenza possono avere vulnerabilità mascherate l’una dall'altra. La contromisura
risultante non è vulnerabile, mentre uno scanner di vulnerabilità potrebbe segnalare che
entrambe le contromisure sono vulnerabili. Le organizzazioni dovrebbero quindi prestare
attenzione nell'esaminare e nell'intraprendere azioni a partire dalle segnalazioni di
vulnerabilità.
Molte organizzazioni forniscono software, sistemi, prodotti e servizi non solo all'interno
dell'organizzazione ma anche a parti interessate come clienti, partner o altri utenti. Questi
software, sistemi, prodotti e servizi possono presentare vulnerabilità relative alla
sicurezza delle informazioni che influiscono sulla sicurezza degli utenti.
Le organizzazioni possono rilasciare delle remediation e divulgare informazioni sulle
vulnerabilità agli utenti (in genere tramite un avviso pubblico) e fornire informazioni
appropriate ai database delle vulnerabilità del software. Per ulteriori informazioni relative
alla gestione delle vulnerabilità tecniche quando si utilizza il cloud computing, consultare
la serie ISO/IEC 19086 e ISO/IEC 27017.
La ISO/IEC 29147 fornisce informazioni dettagliate sulla ricezione di segnalazioni di
vulnerabilità e sulla pubblicazione di avvisi di vulnerabilità. ISO/IEC 30111 fornisce
informazioni dettagliate sulla gestione e sulla risoluzione delle vulnerabilità segnalate.
8.9 Gestione delle configurazioni
informazioni
#Preventive #Confidentiality #Protect #Secure_configuration #Protection
#Integrity
#Availability

Controllo
Le configurazioni, comprese le configurazioni di sicurezza, di hardware, software, servizi
e reti dovrebbero essere stabilite, documentate, attuate, monitorate e riesaminate.
Finalità
Assicurare che hardware, software, servizi e reti funzionino correttamente con le
impostazioni di sicurezza richieste e che la configurazione non venga alterata da
cambiamenti non autorizzati o errati.
Guida
Generale
L'organizzazione dovrebbe definire e attuare processi e strumenti per applicare le
configurazioni definite (incluse le configurazioni di sicurezza) per hardware, software,
servizi (per esempio servizi cloud) e reti, per i sistemi appena installati e per i sistemi nel
corso della loro vita.
Ruoli, responsabilità e procedure dovrebbero essere predisposte per assicurare un
controllo soddisfacente di tutti i cambiamenti alla configurazione.
Modelli standard
Dovrebbero essere definiti modelli standard per la configurazione sicura di hardware,
software, servizi e reti:
a) utilizzando linee guida pubblicamente disponibili (per esempio modelli predefiniti di
fornitori e organizzazioni indipendenti di sicurezza);
b) considerando il livello di protezione necessario per determinare un livello di
sicurezza sufficiente;
c) supportando la politica per la sicurezza delle informazioni dell'organizzazione, le
politiche specifiche, gli standard e gli altri requisiti di sicurezza;
d) considerando la fattibilità e l'applicabilità delle configurazioni di sicurezza nel
contesto dell'organizzazione.
I modelli dovrebbero essere riesaminati periodicamente e aggiornati quando è necessario
affrontare nuove minacce o vulnerabilità o quando vengono introdotte nuove versioni di
software o hardware.
Per stabilire modelli standard per la configurazione sicura di hardware, software, servizi e
reti si dovrebbe considerare quanto segue:
a) ridurre al minimo il numero di identità con diritti di accesso privilegiati o di
amministrazione;
b) disabilitare le identità non necessarie, non utilizzate o insicure;
c) disabilitare o limitare funzioni e servizi non necessari;
d) limitare l'accesso a programmi di utilità con ampi poteri e alle impostazioni dei
parametri del dispositivo;
e) sincronizzare gli orologi;
f) cambiare le informazioni di autenticazione predefinite del fornitore, come le
password predefinite, immediatamente dopo l'installazione e riesaminare altri
importanti parametri predefiniti relativi alla sicurezza;
g) invocare strutture di time-out che disconnettono automaticamente i dispositivi
informatici dopo un predeterminato periodo di inattività;
h) verificare il rispetto dei requisiti di licenza (vedere 5.32).
Gestione delle configurazioni
Le configurazioni stabilite di hardware, software, servizi e reti dovrebbero essere
registrate e dovrebbe essere mantenuto un registro di tutti i cambiamenti alle
configurazioni. Queste registrazioni dovrebbero essere memorizzate in modo sicuro. Ciò
può essere ottenuto in vari modi, per esempio attraverso database di configurazione o
modelli di configurazione.
I cambiamenti alle configurazioni dovrebbero seguire il processo di gestione dei
cambiamenti (vedere 8.32).

Le registrazioni di configurazione possono contenere, se pertinente:
a) informazioni aggiornate sul responsabile o sul punto di contatto dell’asset;
b) data dell'ultimo cambiamento della configurazione;
c) versione del modello di configurazione;
d) relazioni con le configurazioni di altri asset.
Monitoraggio delle configurazioni
Le configurazioni dovrebbero essere monitorate con un insieme completo di strumenti di
gestione dei sistemi (per esempio strumenti di manutenzione, supporto da distanza,
strumenti gestionali, software di backup e ripristino) e dovrebbero essere riesaminate
regolarmente per verificare le impostazioni di configurazione, valutare la robustezza delle
password e valutare le attività eseguite. Le configurazioni effettive possono essere
confrontate con i modelli definiti. Eventuali scostamenti dovrebbero essere affrontati,
mediante l'applicazione automatica della configurazione definita o mediante un'analisi
manuale della deviazione seguita da azioni correttive.
Altre informazioni
La documentazione usata per i sistemi registra spesso dettagli sulla configurazione sia
dell'hardware sia del software.
L’hardening dei sistemi è una parte tipica della gestione delle configurazioni.
La gestione delle configurazioni può essere integrata con i processi di gestione degli
asset e gli strumenti associati.
L'automazione è generalmente più efficace per gestire le configurazioni di sicurezza (per
esempio utilizzando l'infrastructure as code).
I modelli di configurazione possono essere informazioni riservate e, di conseguenza,
dovrebbero essere protetti da accessi non autorizzati.
8.10 Cancellazione delle informazioni
informazioni
#Preventive #Confidentiality #Protect #Information_protection #Protection
#Legal_and_compliance
Controllo
Le informazioni memorizzate nei sistemi informatici, nei dispositivi o in qualsiasi altro
supporto di memorizzazione dovrebbero essere cancellate quando non sono più
necessarie.
Finalità
Prevenire l'esposizione non necessaria di informazioni sensibili e conformarsi ai requisiti
legali, statutari, normativi e contrattuali di cancellazione delle informazioni.
Guida
Generale
Al fine di ridurre il rischio di divulgazione indesiderata, le informazioni sensibili non
dovrebbero essere conservate più a lungo di quanto necessario.
Quando si eliminano informazioni su sistemi, applicazioni e servizi, si dovrebbe
considerare quanto segue:
a) selezionare un metodo di cancellazione (per esempio sovrascrittura elettronica o
cancellazione crittografica) in conformità con i requisiti di business e tenendo conto
delle leggi e dei regolamenti pertinenti;
b) registrare i risultati della cancellazione come prova;
c) quando si ricorre a fornitori di servizi di cancellazione delle informazioni, ottenere
dagli stessi prove della cancellazione delle informazioni.

Laddove terze parti memorizzano le informazioni per conto di un’organizzazione, questa
dovrebbe considerare l'inclusione di requisiti sulla cancellazione delle informazioni negli
accordi con le terze parti e farli rispettare durante e dopo la cessazione di tali servizi.
Metodi di cancellazione
In conformità con la politica specifica dell'organizzazione per la conservazione dei dati e
tenendo conto delle norme di legge e dei regolamenti pertinenti, le informazioni sensibili
dovrebbero essere cancellate quando non più necessarie, attraverso:
a) la configurazione di sistemi per la distruzione sicura delle informazioni quando non
più necessarie (per esempio dopo un periodo definito soggetto alla politica per la
conservazione dei dati o tramite richiesta di accesso del soggetto);
b) la cancellazione delle versioni, copie e file temporanei obsoleti ovunque si trovino;
c) l’utilizzo di un software di cancellazione sicura e approvato per eliminare in modo
permanente le informazioni al fine di assicurare che le informazioni non possano
essere recuperate utilizzando strumenti di recupero specialistici o forensi;
d) l’impiego di fornitori approvati e certificati di servizi di smaltimento sicuri;
e) utilizzando meccanismi di smaltimento adeguati al tipo di supporto di
memorizzazione da smaltire (per esempio smagnetizzazione di dischi rigidi e altri
supporti di memorizzazione magnetici).
Laddove vengono utilizzati servizi cloud, l'organizzazione dovrebbe verificare se il metodo
di eliminazione fornito dal fornitore di servizi cloud è accettabile e, in tal caso,
l'organizzazione dovrebbe utilizzarlo o richiedere al fornitore di servizi cloud di eliminare
le informazioni. Questi processi di eliminazione dovrebbero essere automatizzati in
conformità con le politiche specifiche, quando disponibili e applicabili. A seconda della
sensibilità delle informazioni eliminate, i registri possono tenere traccia o verificare che
questi processi di eliminazione siano avvenuti.
Per evitare l'esposizione involontaria di informazioni riservate quando le apparecchiature
vengono restituite ai loro fornitori, le informazioni riservate dovrebbero essere protette
rimuovendo gli archivi ausiliari (per esempio i dischi rigidi) e la memoria prima che le
apparecchiature lascino i locali dell'organizzazione.
Considerato che la cancellazione sicura di alcuni dispositivi (per esempio smartphone)
può essere ottenuta solo attraverso la distruzione o utilizzando le funzioni integrate in tali
dispositivi (per esempio “ripristino delle impostazioni di fabbrica”), l'organizzazione
dovrebbe scegliere il metodo appropriato in base alla classificazione delle informazioni
trattate da tali dispositivi.
Le misure di controllo descritte in 7.14 dovrebbero essere applicate per distruggere
fisicamente il dispositivo di memorizzazione e contemporaneamente eliminare le
informazioni in esso contenute.
Un registro ufficiale della cancellazione delle informazioni è utile quando si analizza la
causa di un possibile evento di diffusione di informazioni.
Altre informazioni
Informazioni sull'eliminazione dei dati degli utenti nei servizi cloud sono disponibili nella
ISO/IEC 27017.
Informazioni sulla cancellazione dei dati personali possono essere trovate nella
ISO/IEC 27555.
8.11 Mascheramento dei dati

Controllo
Il mascheramento dei dati dovrebbe essere utilizzato in conformità con la politica specifica
dell'organizzazione per il controllo degli accessi e con gli altri requisiti specifici e di
business correlati, tenendo in considerazione le norme di legge applicabili.
Finalità
Limitare l'esposizione di dati sensibili, compresi i dati personali, e rispettare i requisiti
legali, i requisiti cogenti e contrattuali.
Guida
Laddove la protezione dei dati sensibili (per esempio dati personali) è un problema, le
organizzazioni dovrebbero considerare di nascondere tali dati utilizzando tecniche come
il mascheramento dei dati, la pseudonimizzazione o l'anonimizzazione.
Le tecniche di pseudonimizzazione o anonimizzazione possono nascondere i dati
personali, mascherare la vera identità degli interessati dei dati personali o altre
informazioni sensibili e disconnettere il collegamento tra i dati personali e l'identità
dell’interessato o il collegamento tra altre informazioni sensibili.
Quando si utilizzano tecniche di pseudonimizzazione o anonimizzazione, si dovrebbe
verificare che i dati siano stati adeguatamente pseudonimizzati o resi anonimi. Per essere
efficace, l'anonimizzazione dei dati dovrebbe considerare tutti gli elementi delle
informazioni sensibili. A titolo esemplificativo, se non correttamente considerati, una
persona può essere identificata anche se i dati che possono identificarla direttamente
sono resi anonimi, a causa della presenza di ulteriori dati che consentono di identificare
indirettamente la persona.
Tecniche aggiuntive per il mascheramento dei dati includono:
a) crittografia (che richiede agli utenti autorizzati di avere una chiave);
b) occultamento o eliminazione di caratteri (impedendo agli utenti non autorizzati di
vedere i messaggi completi);
c) numeri e date variabili;
d) sostituzione (cambiamento di un valore con un altro per nascondere dati sensibili);
e) sostituzione di valori con il loro hash.
Quando si attuano le tecniche di mascheramento dei dati, si dovrebbe considerare quanto
segue:
a) non concedere a tutti gli utenti l'accesso a tutti i dati, progettando quindi query e
maschere in modo da mostrare all'utente solo i dati minimi richiesti;
b) ci sono casi in cui alcuni dati non dovrebbero essere visibili all'utente per alcuni
record di un insieme di dati; in questo caso, progettare e attuare un meccanismo per
l'offuscamento dei dati (per esempio se un paziente non desidera che il personale
ospedaliero sia in grado di vedere tutti i propri record, anche in caso di emergenza,
al personale ospedaliero vengono presentati dati parzialmente offuscati e i dati sono
accessibili al personale con ruoli specifici solo se contengono informazioni utili per
un trattamento appropriato);
c) quando i dati sono offuscati, dare all’interessato dei dati personali la possibilità di
richiedere che gli utenti non possano vedere se i dati sono offuscati (offuscamento
dell'offuscamento; questo viene utilizzato nelle strutture sanitarie, per esempio se il
paziente non vuole che il personale veda che informazioni sensibili, quali gravidanze
o risultati di esami del sangue, sono state offuscate);
d) eventuali requisiti legali o regolamentari (per esempio richiedere il mascheramento
delle informazioni delle carte di pagamento durante l'elaborazione o la
memorizzazione).
Quando si utilizza il mascheramento dei dati, la pseudonimizzazione o l'anonimizzazione,
si dovrebbe considerare quanto segue:
a) livello di efficacia del mascheramento, pseudonimizzazione o anonimizzazione dei
dati in base all'utilizzo dei dati trattati;
b) controlli di accesso ai dati trattati;

c) accordi o limitazioni all'utilizzo dei dati trattati;
d) vietare di confrontare i dati trattati con altre informazioni al fine di identificare
l’interessato dei dati personali;
e) tenere traccia del conferimento e della ricezione dei dati trattati.
Altre informazioni
L'anonimizzazione altera irreversibilmente i dati personali in modo tale che l'interessato
non possa più essere identificato direttamente o indirettamente.
La pseudonimizzazione sostituisce le informazioni di identificazione con un alias. La
conoscenza dell'algoritmo (a volte indicato come "informazioni aggiuntive") utilizzato per
eseguire la pseudonimizzazione consente almeno una qualche forma di identificazione
dell’interessato. Tali “informazioni aggiuntive” dovrebbero pertanto essere mantenute
separate e protette.
Sebbene la pseudonimizzazione sia quindi più debole dell'anonimizzazione, i dati
pseudonimizzati possono essere più utili nella ricerca statistica.
Il mascheramento dei dati è un insieme di tecniche per camuffare, sostituire o offuscare
elementi di dati sensibili. Il mascheramento dei dati può essere statico (quando elementi
di dati sono mascherati nel database originale), dinamico (utilizzando l'automazione e le
regole per proteggere i dati in tempo reale) o al volo (con i dati mascherati nella memoria
di un'applicazione).
Le funzioni hash possono essere utilizzate per rendere anonimi i dati personali. Per
prevenire attacchi di enumerazione, dovrebbero sempre essere combinati con una
funzione di salt.
Negli identificatori di risorse e nei loro attributi [per esempio nomi di file, URL (Uniform
Resource Locator)], i dati personali dovrebbero essere evitati o resi adeguatamente
anonimi.
Ulteriori controlli per la protezione dei dati personali nei cloud pubblici sono forniti nella
ISO/IEC 27018.
Ulteriori informazioni sulle tecniche di anonimizzazione sono disponibili nella
ISO/IEC 20889.
8.12 Prevenzione di leakage delle informazioni
informazioni
#Detective #Detect #Defence
Controllo
Le misure di prevenzione di leakage dei dati dovrebbero essere applicate a sistemi, reti e
qualsiasi altro dispositivo che elabora, memorizza o trasmette informazioni sensibili.
Finalità
Rilevare e prevenire la divulgazione e l'estrazione non autorizzate di informazioni da parte
di individui o sistemi.
Guida
L'organizzazione dovrebbe considerare quanto segue per ridurre il rischio di leakage dei
dati:
a) identificare e classificare le informazioni per la protezione contro il leakage (per
esempio dati personali, modelli di prezzo e progetti dei prodotti);
b) monitoraggio dei canali di leakage dei dati (per esempio email, trasferimenti di file,
dispositivi mobili e dispositivi di memorizzazione portatili);
c) azioni per prevenire leakage delle informazioni (per esempio mettere in quarantena
email contenenti informazioni sensibili).

Gli strumenti di prevenzione del leakage di dati dovrebbero essere utilizzati per:
a) identificare e monitorare le informazioni sensibili a rischio di divulgazione non
autorizzata (per esempio in dati non strutturati sul sistema di un utente);
b) rilevare la divulgazione di informazioni sensibili (per esempio quando le informazioni
vengono caricate su servizi cloud di terze parti non attendibili o inviate tramite email);
c) bloccare le azioni degli utenti o le trasmissioni di rete che espongono informazioni
sensibili (per esempio impedendo la copia di voci di database in un foglio di calcolo).
L'organizzazione dovrebbe determinare se è necessario limitare la capacità di un utente
di copiare e incollare o caricare dati su servizi, dispositivi e supporti di memorizzazione al
di fuori dell'organizzazione. In tal caso, l'organizzazione dovrebbe attuare tecnologie
come strumenti di prevenzione di leakage di dati o la configurazione di strumenti esistenti
che consentono agli utenti di visualizzare e manipolare i dati conservati a distanza, ma
impediscono il copia e incolla al di fuori del controllo dell'organizzazione.
Se è richiesta l'esportazione dei dati, il responsabile dei dati dovrebbe essere autorizzato
ad approvare l'esportazione e considerare gli utenti responsabili delle loro azioni.
L'acquisizione di schermate o fotografie dello schermo dovrebbe essere affrontata
attraverso i termini e le condizioni di utilizzo, la formazione e gli audit.
Quando viene eseguito il backup dei dati, occorre prestare attenzione per assicurare che
le informazioni sensibili siano protette mediante misure quali la crittografia, il controllo
degli accessi e la protezione fisica del supporto di memorizzazione che contiene il
backup.
La prevenzione di leakage dei dati dovrebbe anche essere considerata per la protezione
dalle azioni di intelligence di un avversario volte a ottenere informazioni riservate o
segrete (geopolitiche, umane, finanziarie, commerciali, scientifiche o di altro tipo) che
possono essere di interesse per lo spionaggio o possono essere critiche per la comunità.
Le azioni di prevenzione di leakage dei dati dovrebbero essere orientate a confondere le
decisioni dell'avversario, per esempio sostituendo le informazioni autentiche con
informazioni false, sia come azione indipendente o come risposta alle azioni di
intelligence dell'avversario. Esempi di questo tipo di azioni sono il reverse social
engineering o l'uso di honeypot per attirare gli aggressori.
Altre informazioni
Gli strumenti di prevenzione di leakage dei dati sono progettati per identificare i dati,
monitorare l'utilizzo e il movimento dei dati e intraprendere azioni per prevenire leakage
dei dati (per esempio avvisando gli utenti del loro comportamento rischioso e bloccando
il trasferimento dei dati su dispositivi di memorizzazione portatili).
La prevenzione di leakage dei dati implica intrinsecamente il monitoraggio delle
comunicazioni del personale e delle attività online e, per estensione, dei messaggi di parti
esterne, il che solleva problemi legali che dovrebbero essere presi in considerazione
prima di impiegare strumenti di prevenzione di data leakage. Esistono diverse norme di
legge relative alla privacy, alla protezione dei dati, ai rapporti di lavoro, all'intercettazione
dei dati e alle telecomunicazioni applicabili al monitoraggio e all'elaborazione dei dati nel
contesto della prevenzione di leakage dei dati.
La prevenzione di leakage dei dati può essere supportata da controlli per la sicurezza
standard, come politiche specifiche per il controllo degli accessi e per la gestione sicura
dei documenti (vedere 5.12 e 5.15).
8.13 Backup delle informazioni
informazioni
#Corrective #Integrity #Recover #Continuity #Protection
#Availability

Controllo
Le copie di backup di informazioni, software e sistemi dovrebbero essere mantenute e
testate regolarmente secondo quanto stabilito dalla politica specifica per il backup.
Finalità
Consentire il ripristino dalla perdita di dati o sistemi.
Guida
Dovrebbe essere stabilita una politica specifica per il backup per affrontare i requisiti di
conservazione dei dati e di sicurezza delle informazioni dell'organizzazione.
Dovrebbero essere fornite adeguate strutture di backup per assicurare che tutte le
informazioni e il software essenziali possano essere recuperati a seguito di un incidente o
di un guasto o della perdita dei supporti di memorizzazione.
Dovrebbero essere sviluppati e attuati piani per il modo in cui l'organizzazione eseguirà il
backup di informazioni, software e sistemi, affinché se ne occupi la politica specifica per il
backup.
Quando si progetta un piano di backup, si dovrebbero prendere in considerazione i
seguenti elementi:
a) produrre registrazioni accurate e complete delle operazioni di copia di backup e
procedure di ripristino documentate;
b) rispecchiare, nell’estensione (per esempio backup completo o differenziale) e nella
frequenza dei backup, i requisiti di business dell'organizzazione (per esempio RPO,
vedere 5.30), i requisiti relativi alla sicurezza delle informazioni coinvolte e la criticità
delle informazioni per la continuità delle attività operative dell'organizzazione;
c) conservare i backup in un luogo a distanza sicuro e protetto, a una distanza
sufficiente per evitare eventuali danni causati da un disastro nel sito principale;
d) fornire alle informazioni di backup un adeguato livello di protezione fisica e
ambientale (vedere capitolo 7 e 8.1), coerente con le norme applicate presso il sito
principale;
e) testare regolarmente i supporti di backup per assicurare che ci si possa fare
affidamento per l'uso in emergenza quando necessario. Testare la capacità di
ripristinare i dati di backup su un sistema di test, non sovrascrivendo il supporto di
memorizzazione originale nel caso in cui il processo di backup o ripristino fallisca e
causi danni o perdite irreparabili dei dati;
f) proteggere i backup mediante crittografia in base ai rischi individuati (per esempio in
situazioni in cui la riservatezza è importante);
g) assicurarsi che venga rilevata una perdita involontaria di dati prima dell'esecuzione
del backup.
Le procedure operative dovrebbero monitorare l'esecuzione dei backup e occuparsi degli
errori dei backup pianificati per assicurare la completezza dei backup in base alla politica
specifica per i backup.
Le misure di backup per i sistemi e servizi singoli dovrebbero essere regolarmente testate
per assicurare che soddisfino gli obiettivi di risposta agli incidenti e i piani di continuità
operativa (vedere 5.30). Questo dovrebbe essere combinato con un test delle procedure
di ripristino e confrontato con i tempi di ripristino richiesti dal piano di continuità operativa.
Nel caso di sistemi e servizi critici, le misure di backup dovrebbero coprire tutte le
informazioni di sistema, le applicazioni e i dati necessari per ripristinare l'intero sistema in
caso di disastro.
Quando l'organizzazione utilizza un servizio cloud, dovrebbero essere fatte copie di
backup delle informazioni, delle applicazioni e dei sistemi dell'organizzazione
nell'ambiente del cloud. L'organizzazione dovrebbe determinare se e come vengono
soddisfatti i requisiti per il backup quando si utilizza il servizio di backup delle informazioni
fornito come parte del servizio cloud.

Il periodo di conservazione delle informazioni di business essenziali dovrebbe essere
determinato, tenendo conto di eventuali requisiti per la conservazione delle copie
d'archivio. L'organizzazione dovrebbe prendere in considerazione la cancellazione delle
informazioni (vedere 8.10) nei supporti di memorizzazione utilizzati per il backup al
termine del periodo minimo di conservazione delle informazioni e dovrebbe prendere in
considerazione le norme di legge e i regolamenti.
Altre informazioni
Per ulteriori informazioni sulla sicurezza della memorizzazione, comprese le
considerazioni sulla conservazione, vedere ISO/IEC 27040.
8.14 Ridondanza delle strutture di elaborazione delle informazioni
informazioni
#Preventive #Availability #Protect #Continuity #Protection
#Asset_management #Resilience
Controllo
Le strutture di elaborazione delle informazioni dovrebbero essere attuate con una
ridondanza sufficiente a soddisfare i requisiti di disponibilità.
Finalità
Assicurare la continuità delle attività operative delle strutture di elaborazione delle
informazioni.
Guida
L'organizzazione dovrebbe identificare i requisiti per la disponibilità dei servizi di business
e dei sistemi informativi. L'organizzazione dovrebbe progettare e attuare un'architettura di
sistema con ridondanza adeguata per soddisfare questi requisiti.
La ridondanza può essere introdotta duplicando le strutture di elaborazione delle
informazioni in parte o nella loro interezza (per esempio componenti di scorta o avendone
due di tutto). L'organizzazione dovrebbe pianificare e attuare procedure per l'attivazione
dei componenti ridondanti e delle strutture di elaborazione. Le procedure dovrebbero
stabilire se i componenti ridondanti e le attività di elaborazione sono sempre attivate o, in
caso di emergenza, attivate automaticamente o manualmente. I componenti ridondanti e
le strutture di elaborazione delle informazioni dovrebbero assicurare lo stesso livello di
sicurezza di quelli primari.
Dovrebbero essere in atto meccanismi per avvisare l'organizzazione di qualsiasi
malfunzionamento nelle strutture di elaborazione delle informazioni, consentire
l'esecuzione della procedura pianificata e consentire la disponibilità continua mentre le
strutture di elaborazione delle informazioni vengono riparate o sostituite.
L'organizzazione dovrebbe considerare quanto segue durante l'attuazione di sistemi
ridondanti:
a) stipulare contratti con due o più fornitori di reti e strutture di elaborazione delle
informazioni critiche come i fornitori di servizi Internet;
b) utilizzare reti ridondanti;
c) utilizzare due data center geograficamente separati con sistemi replicati;
d) utilizzare alimentatori o fonti di alimentazione fisicamente ridondanti;
e) utilizzare più istanze parallele di componenti software, con bilanciamento automatico
del carico tra di esse (tra istanze nello stesso data centre o in data centre diversi);
f) avere componenti duplicati nei sistemi (per esempio CPU, hard disk, memorie) o
nelle reti (per esempio firewall, router, switch).
Ove applicabile, preferibilmente in produzione, i sistemi informativi ridondanti dovrebbero
essere testati per assicurare che il failover da un componente all'altro funzioni come
previsto.

Altre informazioni
Esiste una forte relazione tra ridondanza e disponibilità dell’ICT per la continuità operativa
(vedere 5.30) soprattutto se sono richiesti tempi di ripristino brevi. Molte delle misure di
ridondanza possono far parte delle strategie e soluzioni di continuità ICT.
L'attuazione di ridondanze può introdurre rischi relativi all'integrità (per esempio i processi
di copia dei dati su componenti duplicati possono introdurre errori) o la riservatezza (per
esempio un controllo per la sicurezza debole dei componenti duplicati può portare alla
compromissione) delle informazioni e dei sistemi informativi, che dovrebbero essere presi
in considerazione in fase di progettazione dei sistemi informativi.
La ridondanza nelle strutture di elaborazione delle informazioni di solito non risolve
l'indisponibilità dell'applicazione causata da errori all'interno dell’applicazione stessa.
Con l'uso del cloud computing pubblico, è possibile avere più versioni live di strutture di
elaborazione delle informazioni, esistenti in più posizioni fisiche separate con failover
automatico e bilanciamento del carico tra di loro.
Alcune delle tecnologie e delle tecniche per fornire ridondanza e failover automatico nel
contesto dei servizi cloud sono discusse nella ISO/IEC TS 23167.
8.15 Raccolta di log
informazioni
#Detective #Confidentiality #Detect #Information_security_event_management #Protection
#Integrity #Defence
#Availability
Controllo
I log che registrano attività, eccezioni, guasti e altri eventi significativi dovrebbero essere
prodotti, memorizzati, protetti e analizzati.
Finalità
Registrare eventi, generare prove, assicurare l'integrità delle informazioni di log, prevenire
l'accesso non autorizzato, identificare eventi relativi alla sicurezza delle informazioni che
possono portare a un incidente relativo alla sicurezza delle informazioni e supportare le
indagini.
Guida
Generale
L'organizzazione dovrebbe determinare le finalità per cui vengono creati i log, quali dati
vengono raccolti e registrati e qualsiasi requisito specifico per la protezione e il
trattamento dei dati di log. Questo dovrebbe essere documentato in una politica specifica
per i log.
I log degli eventi dovrebbero includere per ogni evento, a seconda dei casi:
a) ID utente;
b) attività di sistema;
c) date, orari e dettagli degli eventi significativi (per esempio log-on e log-off);
d) identità del dispositivo, identificatore di sistema e posizione;
e) indirizzi e protocolli di rete.
Per i log dovrebbero essere presi in considerazione i seguenti eventi:
a) tentativi riusciti e rifiutati di accesso ai sistemi;
b) tentativi riusciti e rifiutati di accesso a dati e altre risorse;
c) cambiamenti alla configurazione del sistema;
d) uso dei privilegi;
e) utilizzo di programmi e applicazioni di utilità;

f) i file a cui si accede e il tipo di accesso, inclusa la cancellazione di file importanti;
g) allarmi lanciati dal sistema di controllo accessi;
h) attivazione e disattivazione di sistemi di sicurezza, quali sistemi antivirus e intrusion
detection system;
i) creazione, modifica o cancellazione di identità;
j) transazioni eseguite dagli utenti nelle applicazioni. In alcuni casi, le applicazioni
sono un servizio o un prodotto fornito o operato da terzi.
È importante che tutti i sistemi dispongano di riferimenti temporali tra loro sincronizzati
(vedere 8.17) poiché ciò consente la correlazione dei log dei sistemi per le analisi, gli
allarmi e le indagini relative a un incidente.
Protezione dei log
Gli utenti, compresi quelli con diritti di accesso privilegiati, non dovrebbero avere
l'autorizzazione per eliminare o disattivare i log delle proprie attività. Essi possono
potenzialmente manipolare i log delle strutture di elaborazione delle informazioni sotto il
loro diretto controllo. Pertanto si dovrebbero proteggere e riesaminare i log per mantenere
responsabilizzati gli utenti privilegiati.
I controlli dovrebbero mirare a proteggere da cambiamenti non autorizzati ai log e da
problemi operativi dei sistemi di log, tra cui:
a) alterazioni dei tipi di messaggi registrati;
b) file di log modificati o eliminati;
c) mancata registrazione degli eventi o sovrascrittura di eventi passati in caso di
superamento della capacità del supporto di memorizzazione che contiene un file di log.
Per la protezione dei log, dovrebbe essere preso in considerazione l'uso delle seguenti
tecniche: hashing crittografico, registrazione in un file che permette solo le aggiunte e la
sola lettura, registrazione in un file reso pubblico per trasparenza.
Potrebbe essere necessario archiviare alcuni log a causa di requisiti sulla conservazione
dei dati o di requisiti sulla raccolta e la conservazione delle prove (vedere 5.28).
Laddove l'organizzazione deve inviare log di sistema o applicativi a un fornitore per
ottenere assistenza attraverso il debug o la risoluzione di errori, i log, prima dell'invio al
venditore, dovrebbero essere anonimizzati ove possibile utilizzando tecniche di
mascheramento dei dati (vedere 8.11) per informazioni quali nomi utente, indirizzi IP, nomi
host o nome dell'organizzazione.
I log degli eventi possono contenere dati sensibili e dati personali. Dovrebbero essere
adottate adeguate misure di protezione della privacy (vedere 5.34).
Analisi dei log
L'analisi dei log dovrebbe includere l'analisi e l'interpretazione degli eventi relativi alla
sicurezza delle informazioni, per aiutare a identificare attività insolite o comportamenti
anomali o che possono rappresentare indicatori di compromissione.
L'analisi degli eventi dovrebbe essere eseguita tenendo conto:
a) delle competenze necessarie agli esperti che effettuano l'analisi;
b) della procedura di analisi dei log;
c) degli attributi richiesti per ciascun evento relativo alla sicurezza;
d) delle eccezioni individuate attraverso l'utilizzo di regole predeterminate (per esempio
regole del SIEM o del firewall e signature dell’IDS o del sistema anti-malware);
e) dei modelli di comportamento noti e del normale traffico di rete rispetto ad attività e
comportamenti anomali (UEBA);
f) dei risultati delle analisi dei trend o dei pattern (per esempio risultati di data analytics,
di tecniche sui big data e di strumenti di analisi specializzati);
g) dei dati di threat intelligence disponibili.

L'analisi dei log dovrebbe essere supportata da attività di monitoraggio specifiche per
aiutare a identificare e analizzare i comportamenti anomali, che includono:
a) l’esame dei tentativi riusciti e falliti di accesso a risorse protette (per esempio server
DNS, portali web e servizi di file sharing);
b) il controllo dei log del DNS per identificare le connessioni di rete in uscita verso
server dannosi, come quelli associati ai server di command and control di botnet;
c) l’esame di rapporti di utilizzo ricevuti dai fornitori di servizi (per esempio fatture o
rapporti di servizio) relativi ad attività insolite all'interno dei sistemi e delle reti (per
esempio attraverso il riesame di modelli di attività);
d) l’inclusione di log degli eventi di monitoraggio fisico come l'ingresso e l'uscita per
assicurare un rilevamento più accurato e un'analisi degli incidenti;
e) la correlazione dei log per consentire analisi efficienti e altamente accurate.
Gli incidenti relativi alla sicurezza delle informazioni, sospetti e realmente accaduti,
dovrebbero essere identificati (per esempio infezioni da malware o analisi dei firewall) ed
essere oggetto di ulteriori indagini (per esempio come parte di un processo di gestione
degli incidenti relativi alla sicurezza delle informazioni, vedere 5.25).
Altre informazioni
I log di sistema contengono spesso un grande volume di informazioni, molte delle quali
estranee al monitoraggio della sicurezza delle informazioni. Per aiutare a identificare
eventi significativi ai fini del monitoraggio della sicurezza delle informazioni, è possibile
prendere in considerazione l'uso di programmi di utilità o strumenti di audit per
l'interrogazione dei file.
La raccolta dei log degli eventi costituisce la base per sistemi di monitoraggio
automatizzati (vedere 8.16) in grado di generare report consolidati e allarmi relativi alla
sicurezza dei sistemi.
È possibile utilizzare uno strumento SIEM o un servizio equivalente per memorizzare,
correlare, normalizzare e analizzare le informazioni di log e per generare allarmi. I SIEM
tendono a richiedere un'attenta configurazione per ottimizzarne i vantaggi. Le
configurazioni da considerare includono l'identificazione e la selezione di fonti di log
appropriate, l'ottimizzazione e il test delle regole e lo sviluppo di casi d'uso.
I file resi pubblici per trasparenza per la registrazione dei log vengono utilizzati, per
esempio, nei sistemi di trasparenza dei certificati. Tali file possono fornire un meccanismo
di rilevamento aggiuntivo utile per la protezione contro la manomissione dei log.
Negli ambienti cloud, le responsabilità di gestione dei log possono essere condivise tra il
cliente del servizio cloud e il fornitore del servizio cloud. Le responsabilità variano a
seconda del tipo di servizio cloud utilizzato. Ulteriori indicazioni possono essere trovate
8.16 Attività di monitoraggio
informazioni
#Availability
Controllo
Reti, sistemi e applicazioni dovrebbero essere monitorati relativamente a comportamenti
anomali e dovrebbero essere intraprese azioni appropriate per valutare potenziali
incidenti relativi alla sicurezza delle informazioni.
Finalità
Rilevare comportamenti anomali e potenziali incidenti relativi alla sicurezza delle
informazioni.

Guida
L'ambito e il livello di monitoraggio dovrebbero essere determinati in accordo con il
business e ai requisiti di sicurezza delle informazioni e tenendo conto delle leggi e dei
regolamenti pertinenti. Le registrazioni del monitoraggio dovrebbero essere conservate
per periodi di conservazione definiti.
I seguenti elementi dovrebbero essere considerati per l'inclusione nel sistema di
monitoraggio:
a) traffico, in uscita e in entrata, di rete, dei sistemi e delle applicazioni;
b) accesso a sistemi, server, apparecchiature di rete, sistema di monitoraggio,
applicazioni critiche, ecc.
c) file di configurazione di rete e di sistema di livello critico o di amministrazione degli
stessi;
d) log da strumenti di sicurezza [per esempio antivirus, IDS, sistemi di prevenzione
delle intrusioni (IPS), filtri web, firewall, data leakage prevention];
e) log degli eventi relativi alle attività del sistema e della rete;
f) verifica che il codice in esecuzione sia autorizzato a funzionare nel sistema e che
non sia stato manomesso (per esempio mediante ricompilazione per aggiungere
ulteriore codice indesiderato);
g) utilizzo delle risorse (per esempio CPU, hard disk, memoria, banda) e loro
prestazioni.
L'organizzazione dovrebbe stabilire una baseline del comportamento normale e
monitorare le anomalie rispetto a questa baseline. Quando si stabilisce una baseline, si
dovrebbe considerare quanto segue:
a) il riesame dell'utilizzo dei sistemi nei periodi normali e di punta;
b) l’orario abituale di accesso, il luogo di accesso, la frequenza di accesso per ciascun
utente o gruppo di utenti.
Il sistema di monitoraggio dovrebbe essere configurato rispetto alla baseline stabilita per
identificare comportamenti anomali, come per esempio:
a) cessazione non pianificata di processi o applicazioni;
b) attività tipicamente associate a malware o traffico originato da indirizzi IP o domini di
rete notoriamente dannosi (per esempio quelli associati a server di command and
control di botnet);
c) caratteristiche note dell'attacco (per esempio denial of service e buffer overflow);
d) comportamenti insoliti dei sistemi (per esempio key logging, process injection e
deviazioni nell'uso previsto dei protocolli);
e) colli di bottiglia e sovraccarichi (per esempio code di rete, livelli di latenza e instabilità
di rete);
f) accessi non autorizzati (effettivi o tentati) a sistemi o informazioni;
g) scansioni non autorizzate di applicazioni, sistemi e reti;
h) tentativi, falliti e riusciti, di accedere a risorse protette (per esempio server DNS,
portali web e file system);
i) comportamenti insoliti degli utenti e dei sistemi rispetto al comportamento atteso.
Dovrebbe essere condotto un monitoraggio continuo tramite uno strumento di
monitoraggio. Il monitoraggio dovrebbe essere effettuato in tempo reale o a intervalli
periodici, in base alle esigenze e capacità organizzative. Gli strumenti di monitoraggio
dovrebbero trattare grandi quantità di dati, adattarsi a un panorama di minacce in continua
evoluzione e inviare notifiche in tempo reale. Gli strumenti dovrebbero anche essere in
grado di riconoscere le signature specifiche e i modelli di comportamento dei dati, della
rete o delle applicazioni.

Il software di monitoraggio automatizzato dovrebbe essere configurato per generare
avvisi (per esempio tramite console di gestione, messaggi di email o sistemi di
messaggistica istantanea) in base a soglie predefinite. Per ridurre al minimo i falsi positivi,
il sistema di allerta dovrebbe essere ottimizzato e addestrato in base a baseline
dell'organizzazione. Dovrebbe esserci personale dedicato a rispondere agli avvisi e
dovrebbe essere adeguatamente formato per interpretare accuratamente potenziali
incidenti. Dovrebbero essere presenti sistemi e processi ridondanti per ricevere e
rispondere agli avvisi.
Gli eventi anomali dovrebbero essere comunicati alle parti interessate al fine di migliorare
le seguenti attività: audit, valutazioni della sicurezza, scansioni e monitoraggi delle
vulnerabilità (vedere 5.25). Dovrebbero essere predisposte procedure per rispondere
tempestivamente alle indicazioni del sistema di monitoraggio, al fine di ridurre al minimo
l'effetto di eventi avversi (vedere 5.26) sulla sicurezza delle informazioni. Dovrebbero
inoltre essere stabilite procedure per identificare e affrontare i falsi positivi e questo
include la messa a punto del software di monitoraggio per ridurre il numero di falsi positivi
nel futuro.
Altre informazioni
Il monitoraggio della sicurezza può essere migliorato da:
a) uso di sistemi di threat intelligence (vedere 5.7);
b) uso di funzionalità di machine learning e intelligenza artificiale;
c) uso di liste di blocco (blocklist) o di autorizzazione (allowlist);
d) conduzione di una serie di valutazioni tecniche di sicurezza (per esempio
vulnerability assessment, penetraton test, simulazioni di attacchi informatici ed
esercitazioni di reazione agli attacchi informatici) e uso dei risultati di tali valutazioni
per aiutare a determinare baseline o comportamenti accettabili;
e) uso di sistemi di monitoraggio delle prestazioni per aiutare a stabilire e rilevare
comportamenti anomali;
f) uso dei log in combinazione con i sistemi di monitoraggio.
Le attività di monitoraggio sono spesso condotte utilizzando software specialistici, come
gli intrusion detection system. Questi possono essere configurati considerando baseline
basate su attività normali, accettabili e previste della rete e dei sistemi.
Il monitoraggio delle comunicazioni anomale aiuta nell'identificazione delle botnet (ovvero
degli insiemi di dispositivi sotto il controllo malevolo del proprietario della botnet,
solitamente utilizzati per condurre attacchi di tipo denial of service distribuiti su altri
computer di altre organizzazioni). Se un computer è controllato da un dispositivo esterno,
c'è una comunicazione tra il dispositivo infetto e il controller. L'organizzazione dovrebbe
quindi impiegare tecnologie per monitorare le comunicazioni anomale e intraprendere le
azioni necessarie.
8.17 Sincronizzazione degli orologi
informazioni
#Detective #Integrity #Protect #Information_security_event_management #Protection
#Detect #Defence
Controllo
Gli orologi dei sistemi di elaborazione delle informazioni utilizzati dall'organizzazione
dovrebbero essere sincronizzati con origini temporali approvate.
Finalità
Consentire la correlazione e l'analisi di eventi relativi alla sicurezza e altri dati registrati e
supportare le indagini sugli incidenti relativi alla sicurezza delle informazioni.

Guida
I requisiti esterni e interni per la rappresentazione dell'ora, la sincronizzazione affidabile e
l'accuratezza dovrebbero essere documentati e attuati. Tali requisiti possono provenire da
esigenze legali, statutarie, regolamentari, contrattuali, di standard e di monitoraggio
interno. Dovrebbe essere definito e preso in considerazione un tempo di riferimento
standard per l'uso all'interno dell'organizzazione per tutti i sistemi, inclusi i sistemi di
gestione degli edifici, i sistemi di ingresso e uscita e altri che possono essere utilizzati per
facilitare le indagini.
Un orologio collegato a un'ora radiotrasmessa da un orologio atomico nazionale o da un
sistema di posizionamento globale (per esempio GPS) dovrebbe essere utilizzato come
orologio di riferimento per i sistemi di logging; una fonte di data e ora coerente e affidabile
per assicurare timestamp accurati. Protocolli come il network time protocol (NTP) o il
precision time protocol (PTP) dovrebbero essere utilizzati per mantenere tutti i sistemi
collegati in rete sincronizzati con un orologio di riferimento.
L'organizzazione può utilizzare contemporaneamente due sorgenti orarie esterne al fine
di migliorare l'affidabilità degli orologi esterni e gestire opportunamente eventuali
variazioni.
La sincronizzazione degli orologi può essere difficile quando si utilizzano più servizi cloud
o quando si utilizzano servizi sia cloud sia locali. In questo caso, è opportuno monitorare
l'orologio di ciascun servizio e registrarne la differenza al fine di mitigare i rischi derivanti
dalle discrepanze.
Altre informazioni
La corretta impostazione degli orologi dei computer è importante per assicurare
l'accuratezza dei log degli eventi, che possono essere richiesti per le indagini o come
prova in casi legali e disciplinari. Audit log imprecisi possono ostacolare tali indagini e
danneggiare la credibilità di tali prove.
8.18 Utilizzo di programmi di utilità privilegiati
informazioni
#Integrity #Secure_configuration
#Availability #Application_security
Controllo
L'uso di programmi di utilità che possono essere in grado di ignorare i controlli del sistema
e delle applicazioni dovrebbe essere limitato e strettamente controllato.
Finalità
Assicurare che l'uso di programmi di utilità non danneggi i controlli dei sistemi e delle
applicazioni per la sicurezza delle informazioni.
Guida
Dovrebbero essere prese in considerazione le seguenti linee guida per l'uso di programmi
di utilità che possono essere in grado di ignorare i controlli dei sistemi e delle applicazioni:
a) uso dei programmi di utilità limitato al numero minimo pratico di utenti fidati e
autorizzati (vedere 8.2);
b) utilizzo di procedure di identificazione, autenticazione e autorizzazione dei
programmi di utilità, inclusa l'identificazione univoca della persona che utilizza il
programma di utilità;
c) definizione e documentazione dei livelli di autorizzazione per i programmi di utilità;
d) autorizzazione per l'utilizzo ad hoc di programmi di utilità;
e) non rendere disponibili programmi di utilità agli utenti che hanno accesso ad
applicazioni su sistemi dove è richiesta la separazione dei compiti;

f) rimuovere o disabilitare tutti i programmi di utilità non necessari;
g) come minimo, la separazione logica dei programmi di utilità dal software applicativo.
Ove possibile, separare le comunicazioni di rete per tali programmi dal traffico
dell'applicazione;
h) limitazione della disponibilità dei programmi di utilità (per esempio per la durata di un
cambiamento autorizzato);
i) registrazione di tutti gli utilizzi dei programmi di utilità.
Altre informazioni
La maggior parte dei sistemi informativi dispone di uno o più programmi di utilità che
possono essere in grado di sovrascrivere i controlli dei sistemi e delle applicazioni, per
esempio diagnostica, patch, antivirus, deframmentazione dischi, debugger, backup e
strumenti di rete.
8.19 Installazione del software sui sistemi in esercizio
informazioni
#Integrity #Application_security
#Availability
Controllo
Dovrebbero essere attuate procedure e misure per gestire in modo sicuro l'installazione
del software sui sistemi in esercizio.
Finalità
Assicurare l'integrità dei sistemi in esercizio e prevenire lo sfruttamento delle vulnerabilità
tecniche.
Guida
Si dovrebbero considerare le seguenti linee guida per gestire in modo sicuro i
cambiamenti e l'installazione del software sui sistemi in esercizio:
a) eseguire gli aggiornamenti del software in uso solo da parte di amministratori formati
e previa apposita autorizzazione del management (vedere 8.5);
b) assicurare che sui sistemi in produzione sia installato solo codice eseguibile
approvato e non codice in fase di sviluppo o compilatori;
c) installare e aggiornare il software solo dopo test approfonditi e con esito positivo
(vedere 8.29 e 8.31);
d) aggiornare tutte le corrispondenti librerie di sorgenti di programma;
e) utilizzare un sistema di controllo della configurazione per mantenere il controllo di
tutto il software in esercizio e della documentazione relativa ai sistemi;
f) definire una strategia di rollback prima dell'attuazione dei cambiamenti;
g) mantenere un audit log di tutti gli aggiornamenti del software in esercizio;
h) archiviare le vecchie versioni del software, insieme a tutte le informazioni e parametri
richiesti, alle procedure, ai dettagli di configurazione e al software di supporto come
misura di emergenza, e per tutto il tempo in cui il software è necessario per leggere
o elaborare i dati archiviati.
Qualsiasi decisione di aggiornare a una nuova versione dovrebbe tenere conto dei
requisiti di business per il cambiamento e della sicurezza della versione (per esempio
l'introduzione di nuove funzionalità di sicurezza delle informazioni o il numero e la gravità
delle vulnerabilità relative alla sicurezza delle informazioni che interessano la versione
corrente). Le patch del software dovrebbero essere applicate quando possono aiutare a
rimuovere o ridurre le vulnerabilità relative alla sicurezza delle informazioni (vedere 8.8 e
8.19).

Il software per computer può fare affidamento su software e pacchetti forniti dall'esterno
(per esempio programmi software che utilizzano moduli ospitati su siti esterni), che
dovrebbero essere monitorati e controllati per evitare cambiamenti non autorizzati, poiché
possono introdurre vulnerabilità relative alla sicurezza delle informazioni.
Il software fornito da fornitori e utilizzato nei sistemi di produzione dovrebbe essere
mantenuto a un livello supportato dal fornitore. Nel tempo, i fornitori di software
cesseranno di supportare le versioni precedenti del software. L'organizzazione dovrebbe
considerare i rischi derivanti dal fare affidamento su software non supportato. La versione
del software open source utilizzato nei sistemi di produzione dovrebbe essere l'ultima
appropriata. Nel tempo, il codice open source può cessare di essere mantenuto ma è
ancora disponibile in un archivio di software open source. L'organizzazione dovrebbe
anche considerare i rischi derivanti dal fare affidamento su software open source non
mantenuto e utilizzato nei sistemi in esercizio.
Quando i fornitori sono coinvolti nell'installazione o nell'aggiornamento di software,
l'accesso fisico o logico dovrebbe essere concesso solo quando necessario e con le
appropriate autorizzazioni. Le attività del fornitore dovrebbero essere monitorate (vedere
5.22).
L'organizzazione dovrebbe definire e applicare regole rigorose sui tipi di software che gli
utenti possono installare.
Il principio del privilegio minimo dovrebbe essere applicato all'installazione di software sui
sistemi in esercizio. L'organizzazione dovrebbe identificare quali tipologie di installazione
software sono consentite (per esempio aggiornamenti e patch di sicurezza al software
esistente) e quali tipologie di installazione sono vietate (per esempio software che è solo
per uso personale e software di cui sono sconosciute o sospette le referenze relative alla
possibilità che sia dannoso). Questi privilegi dovrebbero essere concessi in base ai ruoli
degli utenti coinvolti.
Altre informazioni
8.20 Sicurezza delle reti
informazioni
#Detective #Integrity #Detect
#Availability
Controllo
Le reti e i dispositivi di rete dovrebbero essere protetti, gestiti e controllati per proteggere
le informazioni nei sistemi e nelle applicazioni.
Finalità
Proteggere dalla compromissione tramite la rete le informazioni nelle reti e nelle strutture
di supporto di elaborazione delle informazioni.
Guida
Dovrebbero essere attuati controlli per assicurare la sicurezza delle informazioni nelle reti
e per proteggere i servizi connessi da accessi non autorizzati. In particolare vanno
considerati i seguenti elementi:
a) i tipi e i livelli di classificazione delle informazioni che la rete può supportare;
b) stabilire responsabilità e procedure per la gestione delle apparecchiature e dei
dispositivi di rete;
c) mantenere aggiornata la documentazione, inclusi gli schemi di rete e i file di
configurazione dei dispositivi (per esempio router, switch);
d) separare la responsabilità relativa all’esercizio delle reti dall’esercizio dei sistemi ICT
ove appropriato (vedere 5.3);

e) istituire controlli per salvaguardare la riservatezza e l'integrità dei dati che transitano
su reti pubbliche, reti di terzi o su reti wireless e per proteggere i sistemi e le
applicazioni connessi a queste reti (vedere 5.22, 8.24, 5.14 e 6.6). Possono inoltre
essere richiesti controlli aggiuntivi per mantenere la disponibilità dei servizi di rete e
dei computer collegati alla rete;
f) raccogliere log e monitorare adeguatamente per consentire la registrazione e il
rilevamento di azioni che possono influenzare o sono significative per la sicurezza
delle informazioni (vedere 8.16 e 8.15);
g) coordinare da vicino le attività di gestione della rete sia per ottimizzare il servizio
all'organizzazione sia per assicurare che i controlli siano applicati in modo coerente
attraverso l'infrastruttura di elaborazione delle informazioni;
h) autenticare i sistemi sulla rete;
i) limitare e filtrare le connessioni dei sistemi alla rete (per esempio utilizzo di firewall);
j) rilevare, limitare e autenticare le connessioni di apparecchiature e dispositivi alla
rete;
k) configurare in modo sicuro, con tecniche di hardening, i dispositivi di rete;
l) separare i canali di amministrazione della rete dall'altro traffico di rete;
m) isolare temporaneamente le sottoreti critiche (per esempio con “ponti levatoi”) se la
rete è sotto attacco;
n) disabilitare i protocolli di rete vulnerabili.
L'organizzazione dovrebbe assicurare che vengano applicati controlli per la sicurezza
adeguati all'uso delle reti virtualizzate. Le reti virtualizzate includono anche le reti
software-defined (SDN, SD-WAN). Le reti virtualizzate possono essere desiderabili dal
punto di vista della sicurezza, poiché possono consentire la separazione logica delle
comunicazioni che avvengono su reti fisiche, in particolare per i sistemi e le applicazioni
realizzati utilizzando tecniche di distributed computing.
Altre informazioni
Ulteriori informazioni sulla sicurezza della rete sono disponibili nella serie ISO/IEC 27033.
Maggiori informazioni sulle reti virtualizzate sono disponibili nella norma ISO/IEC TS 23167.
8.21 Sicurezza dei servizi di rete
informazioni
#Integrity
#Availability
Controllo
I meccanismi di sicurezza, i livelli di servizio e i requisiti dei servizi di rete dovrebbero
essere identificati, attuati e monitorati.
Finalità
Assicurare la sicurezza nell'uso dei servizi di rete.
Guida
Le misure di sicurezza necessarie per servizi particolari, come le caratteristiche di
sicurezza, i livelli di servizio e i requisiti di servizio, dovrebbero essere identificate e
attuate (da fornitori di servizi di rete interni o esterni). L'organizzazione dovrebbe
assicurare che i fornitori di servizi di rete attuino queste misure.
La capacità del fornitore di servizi di rete di gestire i servizi concordati in modo sicuro
dovrebbe essere determinata e monitorata regolarmente. Il diritto di audit dovrebbe
essere concordato tra l'organizzazione e il fornitore. L'organizzazione dovrebbe anche
prendere in considerazione le attestazioni di terze parti fornite dai fornitori di servizi per
dimostrare che mantengono adeguate misure di sicurezza.

Le regole sull'uso delle reti e dei servizi di rete dovrebbero essere formulate e attuate per
coprire:
a) le reti e i servizi di rete a cui è consentito l'accesso;
b) i requisiti di autenticazione per l'accesso ai vari servizi di rete;
c) le procedure di autorizzazione per determinare chi è autorizzato ad accedere a quali
reti e servizi in rete;
d) i controlli di rete, gestionali e tecnologici, e le procedure per proteggere l'accesso alle
connessioni di rete e ai servizi di rete;
e) i mezzi utilizzati per accedere alle reti e ai servizi di rete [per esempio possono
essere utilizzate reti private virtuali (VPN) o reti wireless];
f) ora, luogo e altri attributi dell'utente al momento dell'accesso;
g) il monitoraggio dell'utilizzo dei servizi di rete.
Si dovrebbero considerare le seguenti caratteristiche di sicurezza dei servizi di rete:
a) le tecnologie applicate per la sicurezza dei servizi di rete, quali autenticazione,
crittografia e controllo delle connessioni di rete;
b) i parametri tecnici necessari per la connessione protetta ai servizi di rete secondo le
regole di sicurezza e di connessione alla rete;
c) il mantenimento in cache (per esempio in una rete di distribuzione di contenuti) e i
suoi parametri che consentono agli utenti di scegliere come usarlo in base ai requisiti
prestazionali, di disponibilità e di riservatezza;
d) le procedure per l'utilizzo dei servizi di rete per limitare l'accesso ai servizi o alle
applicazioni di rete, ove necessario.
Altre informazioni
I servizi di rete includono la fornitura di connessioni, servizi di rete privata e soluzioni di
gestione della sicurezza della rete come firewall e intrusion detection system. Questi
servizi possono variare dalla semplice connettività a complesse offerte a valore aggiunto.
Ulteriori indicazioni su un quadro di riferimento per la gestione degli accessi sono fornite
8.22 Segregazione delle reti
informazioni
#Integrity
#Availability
Controllo
I gruppi di servizi informativi, di utenti e di sistemi informativi dovrebbero essere segregati
nelle reti dell'organizzazione.
Finalità
Dividere la rete in domini di sicurezza e controllare il traffico tra di loro in base alle
esigenze di business.
Guida
L'organizzazione dovrebbe prendere in considerazione la gestione della sicurezza delle
reti di grandi dimensioni suddividendole in domini di rete separati e separandoli dalla rete
pubblica (per esempio Internet). I domini possono essere scelti in base a livelli di fiducia,
criticità e sensibilità (per esempio dominio di accesso pubblico, dominio desktop, dominio
server, sistemi a basso e alto rischio), alle unità organizzative (per esempio risorse
umane, contabilità, marketing) o a una loro combinazione (per esempio dominio dei
server che si connettono a più unità organizzative). La segregazione può essere ottenuta
utilizzando reti fisicamente diverse o utilizzando reti logiche diverse.

Il perimetro di ogni dominio dovrebbe essere ben definito. Se l'accesso tra i domini di rete
è consentito, dovrebbe essere controllato al perimetro tramite un gateway (per esempio
firewall, router di filtraggio). I criteri per la segregazione delle reti in domini e gli accessi
consentiti attraverso i gateway dovrebbero basarsi su una valutazione dei requisiti di
sicurezza di ciascun dominio. La valutazione dovrebbe essere conforme alla politica
specifica per il controllo degli accessi (vedere 5.15), i requisiti di accesso, il valore e la
classificazione delle informazioni trattate e tenere conto degli impatti in termini di costi e
prestazioni dell'incorporazione di una tecnologia gateway adeguata.
Le reti wireless richiedono un trattamento speciale a causa del perimetro di rete poco
definito. Occorre considerare la possibilità di adeguare la copertura radio per la
segregazione delle reti wireless. Per gli ambienti sensibili, si dovrebbe considerare di
trattare tutti gli accessi wireless come connessioni esterne e di separare questo accesso
dalle reti interne fino a quando l'accesso non è passato attraverso un gateway in
conformità con i controlli di rete (vedere 8.20) prima di concedere l'accesso ai sistemi
interni. La rete wireless per gli ospiti dovrebbe essere separata da quella per il personale
se il personale utilizza solo endpoint controllati e conformi alle politiche specifiche
dell'organizzazione. Il Wi-Fi per gli ospiti dovrebbe avere almeno le stesse limitazioni del
Wi-Fi per il personale, al fine di scoraggiare l'uso del Wi-Fi per gli ospiti da parte del
personale.
Altre informazioni
Le reti spesso si estendono oltre i confini dell'organizzazione, poiché si formano
partnership commerciali che richiedono l'interconnessione o la condivisione di strutture di
elaborazione delle informazioni e di rete. Tali estensioni possono aumentare il rischio di
accesso non autorizzato ai sistemi informativi dell'organizzazione che utilizzano la rete,
alcuni dei quali richiedono protezione da altri utenti della rete a causa della loro sensibilità
o criticità.
8.23 Web filtering
informazioni
#Integrity
#Availability
Controllo
L'accesso a siti web esterni dovrebbe essere gestito per ridurre l'esposizione a contenuti
dannosi.
Finalità
Proteggere i sistemi in modo che non siano compromessi dal malware e impedire
l'accesso a risorse web non autorizzate.
Guida
L'organizzazione dovrebbe ridurre i rischi relativi all’accesso del proprio personale a siti
web che contengono informazioni illegali o che sono noti per contenere virus o materiale
di phishing. Una tecnica per ottenere ciò consiste nel blocco dell'indirizzo IP o del dominio
dei siti web interessati. Alcuni browser e tecnologie anti-malware lo fanno
automaticamente o possono essere configurati per farlo.
L'organizzazione dovrebbe identificare i tipi di siti web a cui il personale dovrebbe o non
dovrebbe avere accesso. L'organizzazione dovrebbe prendere in considerazione il blocco
degli accessi ai seguenti tipi di siti web:
a) siti web che hanno una funzione di caricamento delle informazioni se non consentiti
per validi motivi di business;
b) siti web dannosi noti o sospetti (per esempio quelli che distribuiscono malware o
contenuti di phishing);
c) server di comando e controllo;

d) siti web dannosi secondo quanto acquisito dalla threat intelligence (vedere 5.7);
e) siti web che permettono la condivisione di contenuti illegali.
Prima di attuare questo controllo, le organizzazioni dovrebbero stabilire regole per un uso
sicuro e appropriato delle risorse online, inclusa qualsiasi limitazione a siti e applicazioni
web indesiderati o inappropriati. Le regole dovrebbero essere mantenute aggiornate.
Dovrebbe essere impartita formazione al personale sull'uso sicuro e appropriato delle
risorse online, compreso l'accesso al web. La formazione dovrebbe includere le regole
dell'organizzazione, il punto di contatto per segnalare problemi di sicurezza e il processo
di gestione delle eccezioni quando è necessario, per motivi di business legittimi, accedere
a risorse web con limitazioni. La formazione dovrebbe anche essere impartita al
personale per assicurarsi che non ignori gli avvisi del browser che segnalano siti web non
sicuri ma che consentono all'utente di procedere.
Altre informazioni
Il filtraggio web può basarsi su una serie di tecniche tra cui l’identificazione di
caratteristiche specifiche, l’euristica, elenchi di siti web o domini accettabili, elenchi di siti
web o domini vietati e configurazioni su misura per impedire che software dannoso e altre
attività dannose attacchino la rete e i sistemi dell'organizzazione.
8.24 Uso della crittografia
informazioni
#Integrity
#Availability
Controllo
Per l'uso efficace della crittografia dovrebbero essere definite e attuate regole, inclusa la
gestione delle chiavi crittografiche.
Finalità
Assicurare un uso corretto ed efficace della crittografia per proteggere la riservatezza,
l'autenticità o l'integrità delle informazioni in base ai requisiti di business e di sicurezza
delle informazioni e tenendo conto dei requisiti legali, statutari, normativi e contrattuali
relativi alla crittografia.
Guida
Generale
Quando si utilizza la crittografia, si dovrebbe considerare quanto segue:
a) la politica specifica per la crittografia definita dall'organizzazione, inclusi i principi
generali per la protezione delle informazioni. È necessaria una politica specifica per
l'uso della crittografia per massimizzare i benefici e ridurre al minimo i rischi con l'uso
di tecniche crittografiche ed evitare un uso inappropriato o scorretto;
b) identificare il livello di protezione richiesto e la classificazione delle informazioni e
conseguentemente stabilire il tipo, la robustezza e la qualità degli algoritmi
crittografici richiesti;
c) l'uso della crittografia per la protezione delle informazioni conservate sugli endpoint
mobili degli utenti o nei supporti di memorizzazione e trasmesse su reti a tali
dispositivi o supporti di memorizzazione;
d) l'approccio alla gestione delle chiavi, comprese le modalità per gestire la
generazione e protezione delle chiavi crittografiche e il recupero delle informazioni
cifrate in caso di chiavi perse, compromesse o danneggiate;
e) ruoli e responsabilità per:
1) l'attuazione delle regole per l'uso efficace della crittografia;
2) la gestione delle chiavi, inclusa la generazione delle chiavi (vedi 8.24);

f) gli standard da adottare, nonché gli algoritmi crittografici, la robustezza della
cifratura, le soluzioni crittografiche e le pratiche di impiego approvate o richieste per
l'uso nell'organizzazione;
g) l'impatto dell'utilizzo di informazioni cifrate sui controlli che si basano sull'ispezione
dei contenuti (per esempio rilevamento di malware o filtraggio dei contenuti).
Nell'attuare le regole dell'organizzazione per un uso efficace della crittografia, dovrebbero
essere presi in considerazione i regolamenti e le limitazioni nazionali applicabili all'uso
delle tecniche crittografiche in diverse parti del mondo, così come le questioni relative al
flusso transfrontaliero di informazioni crittografate (vedere 5.31).
Il contenuto degli accordi sui livelli di servizio o dei contratti con fornitori esterni di servizi
crittografici (per esempio con un'autorità di certificazione) dovrebbe includere questioni di
responsabilità, affidabilità dei servizi e tempi di risposta per la fornitura dei servizi (vedere
5.22).
Gestione delle chiavi
Un'appropriata gestione delle chiavi richiede processi sicuri per la generazione,
l'archiviazione, la memorizzazione, il recupero, la distribuzione, il ritiro e la distruzione
delle chiavi crittografiche.
Un sistema di gestione delle chiavi dovrebbe essere basato su una serie concordata di
norme, procedure e metodi sicuri per:
a) generare chiavi per diversi sistemi crittografici e diverse applicazioni;
b) rilasciare e ottenere certificati a chiave pubblica;
c) distribuire le chiavi alle entità previste, comprese le modalità di attivazione delle
chiavi una volta ricevute;
d) conservare le chiavi, comprese le modalità con cui gli utenti autorizzati ottengono
l'accesso alle chiavi;
e) cambiare o aggiornare le chiavi, comprese le regole su quando cambiare le chiavi e
come farlo;
f) gestire le chiavi compromesse;
g) revocare le chiavi, comprese le modalità per ritirare o disattivare le chiavi [per
esempio quando le chiavi sono state compromesse o quando un utente lascia
un'organizzazione (in tal caso le chiavi dovrebbero anche essere archiviate)];
h) recuperare le chiavi perse o danneggiate;
i) effettuare il backup o l’archiviazione delle chiavi;
j) distruggere le chiavi;
k) raccogliere in un log e sottoporre ad audit le attività pertinenti alla gestione delle
chiavi;
l) definire le date di attivazione e disattivazione delle chiavi in modo che le chiavi
possano essere utilizzate solo per il periodo di tempo in accordo con le regole sulla
gestione delle chiavi dell'organizzazione;
m) gestire le richieste legali per l'accesso alle chiavi crittografiche (per esempio, le
informazioni cifrate possono essere richieste in forma non cifrata come prova in un
procedimento giudiziario).
Tutte le chiavi crittografiche dovrebbero essere protette da modifiche e perdite. Inoltre, le
chiavi segrete e private necessitano di protezione contro l'uso non autorizzato e la
divulgazione. Le apparecchiature utilizzate per generare, archiviare e memorizzare le
chiavi devono essere protette fisicamente.
Oltre all'integrità, per molti casi d'uso, dovrebbe essere considerata anche l'autenticità
delle chiavi pubbliche.
Altre informazioni
Dell'autenticità delle chiavi pubbliche se ne occupano solitamente i processi di gestione
delle chiavi pubbliche che impiegano autorità di certificazione e certificati a chiave
pubblica, ma è anche possibile occuparsene utilizzando tecnologie come l'applicazione di
processi manuali per un numero ridotto di chiavi.

La crittografia può essere utilizzata per raggiungere diversi obiettivi per la sicurezza delle
informazioni, per esempio:
a) riservatezza: utilizzo di cifratura delle informazioni per proteggere le informazioni
sensibili o critiche, sia memorizzate che trasmesse;
b) integrità o autenticità: utilizzo di firme digitali o codici di autenticazione dei messaggi
per verificare l'autenticità o l'integrità di informazioni sensibili o critiche memorizzate
o trasmesse. Utilizzo di algoritmi ai fini del controllo dell'integrità dei file;
c) non ripudio: utilizzo di tecniche crittografiche per fornire evidenza del verificarsi o
meno di un evento o di un'azione;
d) autenticazione: utilizzo di tecniche crittografiche per autenticare utenti e altre entità
del sistema che richiedono l'accesso o effettuano transazioni con utenti, entità e
risorse del sistema.
La serie ISO/IEC 11770 fornisce ulteriori informazioni sulla gestione delle chiavi.
8.25 Ciclo di vita dello sviluppo sicuro
informazioni
#Preventive #Confidentiality #Protect #Application_security #Protection
#Integrity #System_and_network_security
#Availability
Controllo
Dovrebbero essere stabilite e applicate regole per lo sviluppo sicuro di software e sistemi.
Finalità
Assicurare che la sicurezza delle informazioni sia progettata e attutata all'interno del ciclo
di vita dello sviluppo sicuro di software e sistemi.
Guida
Lo sviluppo sicuro è un requisito per creare un servizio, un'architettura, un software e un
sistema sicuri. Per raggiungere questo obiettivo, si dovrebbero considerare i seguenti
aspetti:
a) separazione degli ambienti di sviluppo, test e produzione (vedere 8.31);
b) fornitura di guide sulla sicurezza nel ciclo di vita dello sviluppo del software:
1) sicurezza nella metodologia di sviluppo del software (vedere 8.28 e 8.27);
2) linee guida per la codifica sicura per ogni linguaggio di programmazione
utilizzato (vedere 8.28);
c) requisiti di sicurezza in fase di specifica e progettazione (vedere 5.8);
d) verifiche di sicurezza nel corso dei progetti (vedere 5.8);
e) test di sistema e di sicurezza, come test di regressione, scansione del codice e
penetration test (vedere 8.29);
f) archivi sicuri per il codice sorgente e le configurazioni (vedere 8.4 e 8.9);
g) sicurezza nel controllo delle versioni (vedere 8.32);
h) conoscenze e formazione richieste e relative alla sicurezza delle applicazioni
(vedere 8.28);
i) capacità degli sviluppatori di prevenire, trovare e correggere le vulnerabilità (vedere
8.28);
j) requisiti di licenza e alternative per assicurare la scelta di soluzioni convenienti
evitando al contempo problemi futuri in materia di licenze (vedere 5.32).
Se lo sviluppo è esternalizzato, l'organizzazione dovrebbe ottenere l'assicurazione che il
fornitore è conforme alle regole dell'organizzazione per lo sviluppo sicuro (vedere 8.30).

Altre informazioni
Lo sviluppo può avvenire anche all'interno di applicazioni, come applicazioni per ufficio,
scripting, browser e database.
8.26 Requisiti di sicurezza delle applicazioni
informazioni
#Integrity #System_and_network_security #Defence
#Availability
Controllo
I requisiti di sicurezza delle informazioni devono essere identificati, specificati e approvati
durante lo sviluppo o l'acquisizione di applicazioni.
Finalità
Assicurare che tutti i requisiti di sicurezza delle informazioni siano identificati e affrontati
durante lo sviluppo o l'acquisizione di applicazioni.
Guida
Generale
I requisiti di sicurezza delle applicazioni dovrebbero essere identificati e specificati. Questi
requisiti sono generalmente determinati attraverso una valutazione del rischio. I requisiti
dovrebbero essere sviluppati con il supporto di specialisti della sicurezza delle informazioni.
I requisiti di sicurezza delle applicazioni possono coprire un'ampia gamma di argomenti, a
seconda delle finalità delle applicazioni.
I requisiti di sicurezza delle applicazioni dovrebbero includere, a seconda dei casi:
a) livello di fiducia nell'identità delle entità [per esempio tramite autenticazione (vedere
5.17, 8.2 e 8.5)];
b) identificare il tipo di informazioni e il livello di classificazione che dovrebbero essere
trattati dall’applicazione;
c) necessità di separazione degli accessi e livello di accesso ai dati e alle funzioni nelle
applicazioni;
d) resilienza contro attacchi dannosi o interruzioni non intenzionali [per esempio
protezione da buffer overflow o structured query language (SQL) injections];
e) requisiti legali, statutari e regolamentari nella giurisdizione in cui la transazione è
generata, elaborata, completata o memorizzata;
f) necessità di privacy associata a tutte le parti coinvolte;
g) i requisiti di protezione di eventuali informazioni riservate;
h) protezione dei dati in corso di elaborazione, in transito o a riposo;
i) necessità di crittografare in modo sicuro le comunicazioni tra tutte le parti coinvolte;
j) controlli sugli input, compresi i controlli di integrità e la convalida degli input;
k) controlli automatizzati (per esempio limiti di approvazione o doppia approvazione);
l) controlli sugli output, anche in considerazione di chi può accedere agli output e della
relativa autorizzazione;
m) limitazioni sul contenuto dei campi "testo libero", in quanto possono portare alla
memorizzazione incontrollata di dati riservati (per esempio dati personali);
n) i requisiti derivati dal processo di business, come la registrazione e il monitoraggio
delle transazioni, i requisiti di non ripudio;
o) requisiti imposti da altri controlli per la sicurezza (per esempio interfacce per sistemi
di registrazione e monitoraggio o rilevamento di fughe di dati);
p) gestione dei messaggi di errore.

Servizi transazionali
Inoltre, per le applicazioni che offrono servizi transazionali tra l'organizzazione e un
partner, si dovrebbe considerare quanto segue quando si identificano i requisiti di
sicurezza delle informazioni:
a) il livello di fiducia che ogni parte richiede nell'identità dichiarata dall'altra;
b) il livello di fiducia richiesto per l'integrità delle informazioni scambiate o trattate e i
meccanismi per l'identificazione della mancanza di integrità (per esempio controllo di
ridondanza ciclica, hashing, firme digitali);
c) processi autorizzativi associati a chi può approvare contenuti, emettere o firmare
documenti relativi a transazioni pertinenti;
d) la riservatezza, l'integrità, la prova dell'invio e della ricezione dei documenti chiave e
il non ripudio (per esempio contratti relativi a gare e procedure contrattuali);
e) la riservatezza e l'integrità delle eventuali operazioni (per esempio ordini, indirizzo di
consegna e conferma di ricezione);
f) requisiti su quanto tempo mantenere riservata la transazione;
g) assicurazioni e altri requisiti contrattuali.
Ordini elettronici e applicazioni di pagamento
Inoltre, per le applicazioni che coinvolgono ordini e pagamenti elettronici, si dovrebbe
considerare quanto segue:
a) requisiti per mantenere la riservatezza e l'integrità delle informazioni relative
all'ordine;
b) il grado di verifica idoneo a verificare le informazioni di pagamento fornite da un
cliente;
c) evitare la perdita o la duplicazione delle informazioni sull'operazione;
d) memorizzare i dettagli delle transazioni al di fuori di qualsiasi ambiente accessibile al
pubblico (per esempio su una piattaforma di memorizzazione esistente nella intranet
dell'organizzazione e non conservati ed esposti su supporti di memorizzazione
elettronici direttamente accessibili da Internet);
e) laddove venga utilizzata un'autorità di fiducia (per esempio ai fini del rilascio e del
mantenimento di firme digitali o certificati digitali), la sicurezza è integrata e
incorporata durante l'intero processo end-to-end di gestione del certificato o della
firma.
Molte delle considerazioni di cui sopra possono essere affrontate mediante l'applicazione
della crittografia (vedere 8.24), tenendo in considerazione i requisiti legali (vedere da 5.31
a 5.36, in particolare vedere 5.31 per le norme di legge sulla crittografia).
Altre informazioni
Le applicazioni accessibili tramite le reti sono soggette a una serie di minacce legate alla
rete, come attività fraudolente, controversie contrattuali o divulgazione di informazioni al
pubblico; trasmissione incompleta, instradamento errato, alterazione non autorizzata del
messaggio, duplicazione o riproduzione. Pertanto, sono indispensabili valutazioni
dettagliate dei rischi e un'attenta determinazione dei controlli. I controlli richiesti spesso
includono metodi crittografici per l'autenticazione e la protezione del trasferimento dei
dati.
Ulteriori informazioni sulla sicurezza delle applicazioni sono disponibili nella serie
ISO/IEC 27034.

8.27 Sicurezza dell’architettura dei sistemi e dei principi di ingegnerizzazione
#Availability
Controllo
I principi per l'ingegnerizzazione di sistemi sicuri dovrebbero essere stabiliti, documentati,
mantenuti e applicati a qualsiasi attività di sviluppo dei sistemi informativi.
Finalità
Assicurare che i sistemi informativi siano progettati, attuati e gestiti in modo sicuro
durante il ciclo di vita dello sviluppo.
Guida
I principi di ingegnerizzazione sicura dovrebbero essere stabiliti, documentati e applicati
alle attività di ingegnerizzazione dei sistemi informativi. La sicurezza dovrebbe essere
progettata in tutti i livelli dell'architettura (business, dati, applicazioni e tecnologia). Una
nuova tecnologia dovrebbe essere analizzata in merito ai rischi relativi alla sicurezza e il
progetto dovrebbe essere riesaminato rispetto ai modelli di attacco noti.
I principi di ingegnerizzazione sicura forniscono indicazioni sulle tecniche di
autenticazione degli utenti, sul controllo di sessione sicura e sulla convalida e
sanitizzazione dei dati.
I principi di ingegnerizzazione sicura dei sistemi dovrebbero includere l'analisi di:
a) l'intera gamma di controlli per la sicurezza necessari per proteggere le informazioni
e i sistemi dalle minacce identificate;
b) le capacità dei controlli per la sicurezza di prevenire, rilevare o rispondere a eventi
relativi alla sicurezza;
c) specifici controlli per la sicurezza richiesti da particolari processi di business (per
esempio crittografia di informazioni sensibili, verifica dell'integrità e firma digitale
delle informazioni);
d) dove e come dovrebbero essere applicati i controlli per la sicurezza (per esempio
integrandosi con un'architettura di sicurezza e con l'infrastruttura tecnica);
e) come interagiscono i singoli controlli per la sicurezza (manuali e automatizzati) per
produrre un insieme integrato di controlli.
I principi di ingegnerizzazione sicura dovrebbero tenere conto di:
a) la necessità di integrarsi con un'architettura di sicurezza;
b) infrastruttura di sicurezza tecnica [per esempio infrastruttura a chiave pubblica (PKI),
gestione delle identità e degli accessi (IAM), prevenzione della fuga di dati e
gestione dinamica degli accessi];
c) capacità dell'organizzazione di sviluppare e supportare la tecnologia scelta;
d) costo, tempo e complessità per soddisfare i requisiti di sicurezza;
e) le attuali buone pratiche.
L’ingegnerizzazione sicura dei sistemi dovrebbe comprendere:
a) l'uso dei principi relativi alla sicurezza dell'architettura, come "sicurezza fin dalla
progettazione", "difesa in profondità", "sicurezza per impostazione predefinita",
"divieto predefinito", "fail securely", " diffidare degli input provenienti da applicazioni
esterne", "sicurezza nello sviluppo”, “supporre una violazione”, “privilegio minimo”,
“usabilità e gestibilità” e “funzionalità minima”;
b) un riesame della progettazione orientata alla sicurezza per aiutare a identificare le
vulnerabilità relative alla sicurezza delle informazioni, assicurare che i controlli per la
sicurezza siano specificati e soddisfino i requisiti di sicurezza;

c) documentazione e riconoscimento formale dei controlli per la sicurezza che non
soddisfano pienamente i requisiti (per esempio a causa di requisiti di sicurezza
relativa alle persone che hanno la precedenza);
d) hardening dei sistemi.
L'organizzazione dovrebbe considerare i principi di "zero trust" come:
a) presumere che i sistemi informativi dell'organizzazione siano già violati e quindi non
fare affidamento solo sulla sicurezza perimetrale della rete;
b) adottare un approccio “mai fidarsi e verificare sempre” per l'accesso ai sistemi
informativi;
c) assicurare che le richieste ai sistemi informativi siano crittografate end-to-end;
d) verificare ogni richiesta a un sistema informativo come se provenisse da una rete
esterna aperta, anche se tali richieste provengono dall'interno dell'organizzazione
(non fidarsi automaticamente di tutto ciò che si trova all'interno o all'esterno dei suoi
perimetri);
e) utilizzare tecniche di "privilegio minimo" e di controllo dinamico degli accessi (vedere
5.15, 5.18 e 8.2). Ciò include l'autenticazione e l'autorizzazione di richieste di
informazioni o a sistemi sulla base di informazioni contestuali come informazioni di
autenticazione (vedere 5.17), identità degli utenti (vedere 5.16), dati sull'endpoint
utente e classificazione dei dati (vedere 5.12);
f) autenticare sempre i richiedenti e convalidare sempre le richieste di autorizzazione
ai sistemi informativi sulla base di informazioni che includono le informazioni di
autenticazione (vedere 5.17) e le identità degli utenti (5.16), i dati sull'endpoint degli
utenti e la classificazione dei dati (vedere 5.12), per esempio imponendo
l’autenticazione forte (per esempio multifattore, vedere 8.5).
I principi di ingegnerizzazione sicura stabiliti dovrebbero essere applicati, ove possibile,
allo sviluppo in outsourcing dei sistemi informativi attraverso i contratti e altri accordi
vincolanti tra l'organizzazione e il fornitore a cui l'organizzazione esternalizza.
L'organizzazione dovrebbe assicurare che le pratiche di ingegnerizzazione sicura dei
fornitori siano in linea con le esigenze dell'organizzazione.
I principi di ingegnerizzazione sicura e le procedure di ingegnerizzazione stabilite devono
essere riesaminati regolarmente per garantire che contribuiscano effettivamente a
migliorare gli standard di sicurezza all'interno del processo di ingegnerizzazione.
Dovrebbero inoltre essere riesaminati regolarmente per assicurare che rimangano
aggiornati in termini di lotta contro qualsiasi nuova potenziale minaccia e per rimanere
applicabili ai progressi nelle tecnologie e soluzioni applicate.
Altre informazioni
I principi di ingegnerizzazione sicura possono essere applicati alla progettazione o alla
configurazione di una gamma di tecniche, come per esempio:
- tolleranza ai guasti e altre tecniche di resilienza;
- segregazione (per esempio tramite virtualizzazione o uso di container);
- resistenza alla manomissione.
È possibile utilizzare tecniche di virtualizzazione sicura per prevenire interferenze tra le
applicazioni in esecuzione sullo stesso dispositivo fisico. Se un'istanza virtuale di
un'applicazione viene compromessa da un utente malintenzionato, solo quell'istanza è
interessata. L'attacco non ha effetto su altre applicazioni o dati.
Le tecniche di resistenza alla manomissione possono essere utilizzate per rilevare la
manomissione di contenitori di informazioni, sia fisici (per esempio un allarme antifurto)
sia logici (per esempio un file di dati). Una caratteristica di tali tecniche è che esiste una
registrazione del tentativo di manomissione del contenitore. Inoltre, il controllo può
impedire la corretta estrazione dei dati attraverso la loro distruzione (per esempio la
memoria del dispositivo può essere cancellata).

8.28 Sviluppo sicuro
informazioni
#Availability
Controllo
I principi di sviluppo sicuro dovrebbero essere applicati allo sviluppo del software.
Finalità
Assicurare che il software sia scritto in modo sicuro, riducendo così il numero di potenziali
vulnerabilità del software relative alla sicurezza delle informazioni.
Guida
Generale
L'organizzazione dovrebbe stabilire processi a livello di organizzazione per fornire un
buona governance dello sviluppo sicuro. Dovrebbe essere stabilita e applicata una
baseline minima di sicurezza. Inoltre, tali processi e governance dovrebbero essere estesi
per coprire i componenti software di terze parti e il software open source.
L'organizzazione dovrebbe monitorare le minacce del mondo reale e gli avvisi e le
informazioni aggiornate sulle vulnerabilità del software per guidare i principi di sviluppo
sicuro dell'organizzazione attraverso il miglioramento e l'apprendimento continuo. Ciò può
aiutare ad assicurare l'attuazione di pratiche di sviluppo sicuro efficaci per combattere il
panorama delle minacce in rapida evoluzione.
Progettazione e prima dello sviluppo
I principi di sviluppo sicuro dovrebbero essere utilizzati nel caso sia di nuovi sviluppi sia di
riutilizzo. Questi principi dovrebbero essere applicati alle attività di sviluppo sia all'interno
dell'organizzazione sia per prodotti e servizi forniti dall'organizzazione ad altri. La
pianificazione e i prerequisiti prima dello sviluppo dovrebbero includere:
a) aspettative specifiche dell'organizzazione e principi approvati per lo sviluppo sicuro
da utilizzare sia per lo sviluppo del codice interno sia per quello esterno;
b) pratiche e difetti di sviluppo comuni e storici che portano a vulnerabilità relative alla
sicurezza delle informazioni;
c) configurazione di strumenti di sviluppo, come ambienti di sviluppo integrati (IDE), per
aiutare a rafforzare la creazione di codice sicuro;
d) seguire le linee guida emesse dai fornitori di strumenti, a seconda dei casi, di
sviluppo e di ambienti di esecuzione;
e) manutenzione e utilizzo di strumenti di sviluppo aggiornati (per esempio
compilatori);
f) qualifica degli sviluppatori nella scrittura di codice sicuro;
g) progettazione e architettura sicure, compresa la modellazione delle minacce;
h) standard di sviluppo sicuro e, se del caso, imporre il loro uso;
i) utilizzo di ambienti controllati per lo sviluppo.
Durante lo sviluppo
Le considerazioni durante lo sviluppo dovrebbero includere:
a) pratiche di sviluppo sicuro specifiche per i linguaggi e le tecniche di programmazione
utilizzati;
b) utilizzare tecniche di programmazione sicure, come il pair programming, il
refactoring, il riesame tra pari, le iterazioni di sicurezza e lo sviluppo basato su test;
c) utilizzare tecniche di programmazione strutturata;

d) documentare il codice e rimuovere i difetti di programmazione, che possono
consentire di sfruttare le vulnerabilità relative alla sicurezza delle informazioni;
e) vietare l'uso di tecniche di progettazione non sicure (per esempio l'uso di password
codificate, esempi di codice non approvati e servizi web non autenticati).
I test dovrebbero essere condotti durante e dopo lo sviluppo (vedere 8.29). I processi di
test statici di sicurezza delle applicazioni (SAST) possono identificare le vulnerabilità
relative alla sicurezza nel software.
Prima di avere il software in esercizio, si dovrebbe valutare quanto segue:
a) superficie di attacco e principio del privilegio minimo;
b) condurre un'analisi degli errori di programmazione più comuni e documentare che gli
stessi sono stati mitigati.
Riesame e manutenzione
Dopo che il codice è stato reso in esercizio:
a) gli aggiornamenti dovrebbero essere impacchettati e distribuiti in modo sicuro;
b) dovrebbero essere gestite le vulnerabilità segnalate per la sicurezza delle
informazioni (vedere 8.8);
c) gli errori e gli attacchi sospetti dovrebbero essere registrati e i registri dovrebbero
essere regolarmente riesaminati per apportare gli aggiustamenti necessari al
codice;
d) il codice sorgente dovrebbe essere protetto contro l'accesso non autorizzato e la
manomissione (per esempio utilizzando strumenti di gestione della configurazione,
che in genere forniscono funzionalità come il controllo degli accessi e il controllo
della versione).
Se si utilizzano strumenti e librerie esterni, le organizzazioni dovrebbero considerare:
a) assicurare che le librerie esterne siano gestite (per esempio mantenendo un
inventario delle librerie utilizzate e delle loro versioni) e regolarmente aggiornate con
i cicli di rilascio;
b) selezione, autorizzazione e riutilizzo di componenti ben controllati, in particolare
componenti di autenticazione e crittografici;
c) la licenza, la sicurezza e la storia dei componenti esterni;
d) assicurare che il software sia mantenibile, tracciabile e provenga da fonti comprovate
e affidabili;
e) disponibilità sufficientemente a lungo termine di risorse e manufatti di sviluppo.
Quando un pacchetto software deve essere modificato, dovrebbero essere considerati i
seguenti punti:
a) il rischio di compromissione dei controlli interni e dei processi di integrità;
b) se ottenere il consenso del venditore;
c) la possibilità di ottenere dal venditore i cambiamenti richiesti come aggiornamenti
standard del programma;
d) l'impatto se l'organizzazione diventa responsabile della futura manutenzione del
software a seguito di cambiamenti;
e) compatibilità con altri software in uso.
Altre informazioni
Un principio guida è assicurare che il codice significativo per la sicurezza venga invocato
quando necessario e sia a prova di manomissione. Anche i programmi installati dal codice
binario compilato hanno queste proprietà, ma solo per i dati contenuti nell'applicazione.
Per i linguaggi interpretati, il concetto funziona solo quando il codice viene eseguito su un
server altrimenti inaccessibile agli utenti e ai processi che lo utilizzano e dove i suoi dati
sono conservati in un database protetto in modo simile. Per esempio, il codice interpretato
può essere eseguito su un servizio cloud in cui l'accesso al codice stesso richiede
privilegi di amministratore. Tale accesso da amministratore dovrebbe essere protetto da
meccanismi di sicurezza come i principi di amministrazione just-in-time e l’autenticazione

forte. Se il responsabile dell'applicazione può accedere agli script tramite accesso da
distanza diretto al server, in linea di principio può farlo anche un utente malintenzionato. I
server web dovrebbero essere configurati per impedire l'esplorazione delle directory in
questi casi.
Il codice dell'applicazione è progettato al meglio partendo dal presupposto che sia
sempre soggetto ad attacchi, a causa di errori o azioni dannose. Inoltre, le applicazioni
critiche possono essere progettate per essere tolleranti ai guasti interni. Per esempio,
l'output di un algoritmo complesso può essere verificato per assicurarsi che rientri entro
certi limiti di sicurezza prima che i dati vengano utilizzati da un'applicazione come
un'applicazione critica per la sicurezza o per la contabilità. Il codice che esegue i controlli
dei limiti è semplice e quindi è molto più facile da dimostrarne la correttezza.
Alcune applicazioni web sono soggette a una serie di vulnerabilità introdotte da una
progettazione e una codifica scadenti, come gli attacchi di database injection e di
cross-site scripting. In questi attacchi, le richieste possono essere manipolate per
abusare delle funzionalità del server web.
Maggiori informazioni sulla valutazione della sicurezza ICT possono essere trovate nella
serie ISO/IEC 15408.
8.29 Test di sicurezza in fase di sviluppo e di accettazione
informazioni
#Preventive #Confidentiality #Identify #Application_security #Protection
#Integrity #Information_security_assurance
#Availability #System_and_network_security
Controllo
I processi di test di sicurezza dovrebbero essere definiti e attuati nel ciclo di vita dello
sviluppo.
Finalità
Convalidare se i requisiti di sicurezza delle informazioni sono soddisfatti quando le
applicazioni o il codice vengono distribuiti nell'ambiente di produzione.
Guida
Nuovi sistemi informativi, aggiornamenti e nuove versioni dovrebbero essere testati e
verificati a fondo durante i processi di sviluppo. I test di sicurezza dovrebbero essere parte
integrante dei test per i sistemi o i componenti.
I test di sicurezza dovrebbero essere condotti rispetto a una serie di requisiti, che possono
essere espressi come funzionali o non funzionali. I test di sicurezza dovrebbero includere
i test di:
a) funzioni di sicurezza, [per esempio autenticazione dell'utente (vedere 8.5),
limitazione degli accessi (vedere 8.3) e uso della crittografia (vedere 8.24)];
b) codifica sicura (vedere 8.28);
c) configurazioni sicure (vedere 8.9, 8.20 e 8.22) incluse quelle dei sistemi operativi,
dei firewall e degli altri componenti di sicurezza.
I piani di test dovrebbero essere determinati utilizzando una serie di criteri. L'estensione
dei test dovrebbe essere proporzionata all'importanza, alla natura del sistema e al
potenziale impatto del cambiamento introdotto. Il piano di test dovrebbe includere:
a) programma dettagliato delle attività e dei test;
b) input e output attesi in una serie di condizioni;
c) criteri di valutazione dei risultati;
d) decisione per ulteriori azioni se necessario.

L'organizzazione può sfruttare strumenti automatizzati, come strumenti di analisi del
codice o scanner di vulnerabilità, e dovrebbe verificare la correzione dei difetti relativi alla
sicurezza.
Per gli sviluppi interni, tali test dovrebbero essere inizialmente eseguiti dal team di
sviluppo. Dovrebbero quindi essere effettuati test di accettazione indipendenti per
assicurare che il sistema funzioni come previsto e solo come previsto (vedere 5.8).
Occorre considerare quanto segue:
a) svolgere attività di riesame del codice come elemento pertinente per testare le falle
di sicurezza, inclusi input e condizioni imprevisti;
b) eseguire scansioni delle vulnerabilità per identificare le configurazioni non sicure e le
vulnerabilità del sistema;
c) eseguire penetration test per identificare codice e progetti non sicuri.
Per lo sviluppo in outsourcing e l'acquisto di componenti, dovrebbe essere seguito un
processo di acquisizione. I contratti con il fornitore dovrebbero indicare i requisiti di
sicurezza identificati (vedere 5.20). Prodotti e servizi dovrebbero essere valutati in base a
questi criteri prima dell'acquisizione.
I test dovrebbero essere eseguiti in un ambiente di test che corrisponda il più possibile
all'ambiente di produzione di destinazione per assicurare che il sistema non introduca
vulnerabilità nell'ambiente dell'organizzazione e che i test siano affidabili (vedere 8.31).
Altre informazioni
È possibile creare più ambienti di test, che possono essere utilizzati per diversi tipi di test
(per esempio test funzionali e delle prestazioni). Questi diversi ambienti possono essere
virtuali, con configurazioni individuali per simulare una varietà di ambienti operativi.
Anche i test e il monitoraggio di ambienti, strumenti e tecnologie di test dovrebbero essere
presi in considerazione per assicurare test efficaci. Le stesse considerazioni valgono per
il monitoraggio dei sistemi di monitoraggio utilizzati nelle impostazioni di sviluppo, test e
produzione. È necessario un giudizio, guidato dalla sensibilità dei sistemi e dei dati, per
determinare quanti livelli di meta-test sono utili.
8.30 Sviluppo affidato all’esterno
informazioni
#Preventive #Confidentiality #Identify #System_and_network_security #Governance_and_Ecosystem
#Detective #Integrity #Protect #Detect #Application_security #Protection
#Availability #Supplier_relationships_security
Controllo
L'organizzazione dovrebbe dirigere, monitorare e riesaminare le attività di sviluppo dei
sistemi affidate all’esterno.
Finalità
Assicurare che le misure di sicurezza delle informazioni richieste dall'organizzazione
siano attuate nello sviluppo dei sistemi affidato all’esterno.
Guida
Laddove lo sviluppo dei sistemi è esternalizzato, l'organizzazione dovrebbe comunicare e
concordare i requisiti e le aspettative e monitorare e riesaminare continuamente se la
consegna del lavoro affidato all’esterno soddisfa queste aspettative. I seguenti punti
dovrebbero essere considerati lungo l'intera filiera di fornitura esterna rispetto
all'organizzazione:
a) accordi di licenza, proprietà del codice e diritti di proprietà intellettuale relativi ai
contenuti esternalizzati (vedere 5.32);
b) requisiti contrattuali per le attività di progettazione, codifica e collaudo sicure (vedere
da 8.25 a 8.29);

c) messa a disposizione di una mappatura delle minacce da considerare da parte degli
sviluppatori esterni;
d) test di accettazione per la qualità e l'accuratezza di quanto consegnato (vedere 8.29);
e) fornitura di prove che siano stabiliti livelli minimi accettabili di funzionalità di
sicurezza e privacy (per esempio relazioni per fornire l’opportuna assicurazione);
f) fornitura di prove che sono stati applicati test sufficienti per prevenire la presenza di
contenuti dannosi (sia intenzionali che non intenzionali) al momento della consegna;
g) fornitura di prove che sono stati applicati test sufficienti per prevenire la presenza di
vulnerabilità note;
h) accordi relativi al deposito in garanzia del codice sorgente del software (per esempio
se il fornitore cessa l'attività);
i) clausole contrattuali sul diritto di audit per i processi e i controlli di sviluppo;
j) requisiti di sicurezza per l'ambiente di sviluppo (vedere 8.31);
k) presa in carico delle norme di legge applicabili (per esempio in materia di protezione
dei dati personali).
Altre informazioni
Ulteriori informazioni sui rapporti con i fornitori possono essere trovate nella serie
ISO/IEC 27036.
8.31 Separazione degli ambienti di sviluppo, test e produzione
informazioni
#Availability
Controllo
Gli ambienti di sviluppo, test e produzione dovrebbero essere separati e protetti.
Finalità
Proteggere l'ambiente e i dati di produzione da compromissioni causate da attività di
sviluppo e test.
Guida
Dovrebbe essere identificato e attuato il livello di separazione tra gli ambienti di
produzione, test e sviluppo necessario per prevenire problemi in produzione.
Dovrebbero essere considerati i seguenti elementi:
a) separare adeguatamente i sistemi di sviluppo e di produzione e farli funzionare in
domini distinti (per esempio in ambienti fisici o virtuali separati);
b) definire, documentare e attuare regole e autorizzazioni per il rilascio del software
dallo sviluppo alla produzione;
c) testare i cambiamenti ai sistemi di produzione e alle applicazioni in un ambiente di
test o di staging prima della loro applicazione ai sistemi di produzione (vedere 8.29);
d) non effettuare test in ambienti di produzione se non in circostanze già definite ed
approvate;
e) non lasciare a disposizione compilatori, editor e altri strumenti di sviluppo o
programmi di utilità sui sistemi di produzione quando non richiesti;
f) per ridurre il rischio di errore, esporre idonee etichette di identificazione
dell'ambiente nei menu;
g) non copiare informazioni sensibili negli ambienti di sviluppo e di test, a meno che
non siano previsti controlli equivalenti a quelli di produzione.

In ogni caso, gli ambienti di sviluppo e test dovrebbero essere protetti tenendo conto di:
a) patching e aggiornamento di tutti gli strumenti di sviluppo, integrazione e test (inclusi
builder, integratori, compilatori, sistemi di configurazione e librerie);
b) configurazione sicura dei sistemi e del software;
c) controllo degli accessi agli ambienti;
d) monitoraggio dei cambiamenti agli ambiente e al codice in essi memorizzato;
e) monitoraggio sicuro degli ambienti;
f) esecuzione dei backup degli ambienti.
Una singola persona non dovrebbe avere la possibilità di apportare cambiamenti sia allo
sviluppo che alla produzione senza previo riesame e approvazione. Ciò può essere
ottenuto per esempio attraverso la segregazione dei diritti di accesso o tramite regole,
oggetto di monitoraggio. In situazioni eccezionali dovrebbero essere attuate misure
aggiuntive come il logging dettagliato e il monitoraggio in tempo reale per rilevare e agire
sui cambiamenti non autorizzati.
Altre informazioni
Senza misure e procedure adeguate, sviluppatori e tester che hanno accesso ai sistemi di
produzione possono introdurre rischi significativi (per esempio modifica indesiderata di file
o dell’ambiente di sistema, avarie al sistema, esecuzione di codice non autorizzato e non
testato sui sistemi di produzione, divulgazione di dati riservati, problemi di integrità e
disponibilità dei dati). Bisognerebbe mantenere un ambiente noto e stabile su cui
eseguire test significativi e impedire gli accessi non appropriati degli sviluppatori
all'ambiente di produzione.
Tali misure e procedure includono ruoli attentamente progettati congiuntamente ai
requisiti di separazione dei compiti e all'adozione di adeguati processi di monitoraggio.
Anche il personale addetto allo sviluppo e ai test rappresenta una minaccia per la
riservatezza dei dati di produzione. Le attività di sviluppo e test possono causare
cambiamenti indesiderati al software o alle informazioni se condividono lo stesso
ambiente di elaborazione. È pertanto auspicabile separare gli ambienti di sviluppo, test e
produzione per ridurre il rischio di cambiamenti accidentali o di accesso non autorizzato ai
software di produzione e ai dati di business (vedere 8.33 per la protezione dei dati di test).
In alcuni casi, la distinzione tra ambienti di sviluppo, test e produzione può essere
deliberatamente sfumata e il test può essere effettuato in un ambiente di sviluppo o
attraverso rilasci controllati a utenti o server di produzione (per esempio una piccola
popolazione di utenti pilota). In alcuni casi, i test possono avvenire usando il prodotto negli
ambienti di esercizio all'interno dell'organizzazione. Inoltre, per ridurre i tempi di
indisponibilità dovuti ai rilasci, è possibile mantenere due ambienti di produzione identici
di cui solo uno alla volta è live.
Sono necessari processi di supporto per l'utilizzo dei dati di produzione negli ambienti di
sviluppo e test (vedere 8.33).
Le organizzazioni possono anche prendere in considerazione le linee guida fornite in
questa sezione per gli ambienti utilizzati per la formazione degli utenti finali.
8.32 Gestione dei cambiamenti
informazioni
#Availability
Controllo
I cambiamenti alle strutture di elaborazione delle informazioni e ai sistemi informativi
dovrebbero essere soggetti a procedure di gestione dei cambiamenti.

Finalità
Preservare la sicurezza delle informazioni durante l'esecuzione dei cambiamenti.
Guida
L'introduzione di nuovi sistemi e i cambiamenti sostanziali ai sistemi esistenti dovrebbero
seguire regole concordate e un processo formale di documentazione, specifica, test,
controllo di qualità e attuazione gestita. Responsabilità manageriali e procedure di
gestione dovrebbero assicurare un controllo soddisfacente di tutti i cambiamenti.
Le procedure di controllo dei cambiamenti dovrebbero essere documentate e applicate
per assicurare la riservatezza, l'integrità e la disponibilità delle informazioni nelle strutture
di elaborazione delle informazioni e nei sistemi informativi per l'intero ciclo di vita dello
sviluppo del sistema, dalle prime fasi di progettazione fino a tutte le attività di
manutenzione.
Ove possibile, le procedure di controllo dei cambiamenti per l'infrastruttura ICT e per il
software dovrebbero essere integrate.
Le procedure di controllo dei cambiamenti dovrebbero includere:
a) pianificazione e valutazione del potenziale impatto dei cambiamenti considerando
tutte le dipendenze;
b) autorizzazione dei cambiamenti;
c) comunicazione dei cambiamenti alle parti interessate pertinenti;
d) test e accettazione dei test per i cambiamenti (vedere 8.29);
e) attuazione dei cambiamenti, compresi i piani di rilascio;
f) considerazioni in merito all’emergenza e alla contingenza, comprese le procedure di
fall-back;
g) mantenimento di registrazioni dei cambiamenti che includano quanto di cui sopra;
h) assicurazione del fatto che la documentazione operativa (vedere 5.37) e le
procedure per l'utente siano cambiate se necessario per rimanere appropriate;
i) assicurare che i piani di continuità ICT e le procedure di risposta e ripristino (vedere
5.30) siano cambiate se necessario per rimanere appropriati.
Altre informazioni
Un controllo inadeguato dei cambiamenti alle strutture di elaborazione delle informazioni
e ai sistemi informativi è causa comune di malfunzionamenti dei sistemi o della sicurezza.
I cambiamenti all'ambiente di produzione, in particolare durante il trasferimento del
software dall'ambiente di sviluppo a quello di produzione, possono influire sull'integrità e
sulla disponibilità delle applicazioni.
Cambiare il software può influire sull'ambiente di produzione e viceversa.
Le buone prassi includono i test dei componenti ICT in un ambiente separato sia
dall'ambiente di produzione che da quello di sviluppo (vedere 8.31). Ciò fornisce un
mezzo per avere il controllo sul nuovo software e consentire una protezione aggiuntiva dei
dati di produzione utilizzati per scopi di test. Ciò dovrebbe includere patch, service pack e
altri aggiornamenti.
L'ambiente di produzione include sistemi operativi, database e piattaforme middleware. Il
controllo dovrebbe essere applicato per i cambiamenti delle applicazioni e delle
infrastrutture.
8.33 Dati di test
#Integrity

Controllo
I dati di test dovrebbero essere scelti, protetti e gestiti opportunamente.
Finalità
Assicurare la pertinenza dei test e la protezione dei dati di produzione utilizzati per i test.
Guida
I dati di test dovrebbero essere scelti per assicurare l'affidabilità dei risultati dei test e la
riservatezza delle informazioni di produzione pertinenti. Le informazioni sensibili
(compresi i dati personali) non dovrebbero nemmeno essere copiate negli ambienti di
sviluppo e test (vedere 8.31).
Le seguenti linee guida dovrebbero essere applicate per proteggere le copie dei dati di
produzione, quando utilizzate a scopo di test, indipendentemente dal fatto che l'ambiente
di test sia ospitato internamente o su un servizio in cloud:
a) applicare agli ambienti di test le stesse procedure di controllo degli accessi applicate
agli ambienti di produzione;
b) disporre di un'autorizzazione separata ogni volta che i dati di produzione vengono
copiati in un ambiente di test;
c) registrare la copia e l'utilizzo di dati di produzione per fornire un audit trail;
d) proteggere le informazioni sensibili mediante rimozione o mascheramento (vedere
8.11) se utilizzate per i test;
e) eliminare correttamente (vedere 8.10) i dati di produzione da un ambiente di test
immediatamente dopo il completamento dei test per impedire l'uso non autorizzato
dei dati di test.
I dati di test dovrebbero essere memorizzati in modo sicuro (per evitare manomissioni,
che potrebbero altrimenti portare a risultati non validi) e utilizzati solo per scopi di test.
Altre informazioni
I test di sistema e di accettazione possono richiedere volumi sostanziali di dati di test che
siano il più vicino possibile ai dati di produzione.
8.34 Protezione dei sistemi informativi durante i test di audit
#Preventive #Confidentiality #Protect #System_and_network_security #Governance_and_Ecosystem
#Integrity #Information_protection #Protection
#Availability
Controllo
I test di audit e le altre attività di garanzia che prevedono la valutazione dei sistemi di
produzione dovrebbero essere pianificati e concordati tra chi li effettua e l’appropriato
livello manageriale.
Finalità
Minimizzare l'impatto delle attività di audit e delle altre attività di garanzia sui sistemi di
produzione e sui processi di business.
Guida
Si dovrebbero osservare le seguenti linee guida:
a) concordare le richieste di audit per l'accesso ai sistemi e ai dati con l’appropriato
livello manageriale;
b) concordare e controllare l'ambito dei test tecnici di audit;
c) limitare i test di audit all'accesso in sola lettura a software e dati. Se l'accesso in sola
lettura non è sufficiente a ottenere le informazioni necessarie, far eseguire il test da
un amministratore esperto che disponga dei diritti di accesso necessari per conto
dell’auditor;

d) se viene concesso un accesso, stabilire e verificare i requisiti di sicurezza (per
esempio riguardo antivirus e patching) dei dispositivi utilizzati per accedere ai
sistemi (per esempio laptop o tablet) prima di permettere l'accesso;
e) consentire un accesso diverso da quello in sola lettura solo per specifiche copie dei
file di sistema, cancellandole al termine dell'audit o fornendo loro un'adeguata
protezione se esiste l'obbligo di conservare tali file in base ai requisiti di
documentazione dell'audit;
f) identificare e concordare le richieste di elaborazioni speciali o aggiuntive, come
l'esecuzione di strumenti di audit;
g) eseguire al di fuori dell'orario lavorativo i test di audit che possono influenzare la
disponibilità del sistema;
h) monitorare e registrare tutti gli accessi effettuati per finalità di audit e test.
Altre informazioni
I test di audit e le altre attività di garanzia possono essere anche eseguiti su sistemi di
sviluppo e test, laddove tali test possono influire, per esempio, sull'integrità del codice o
portare alla divulgazione di informazioni sensibili conservate in tali ambienti.

APPENDICE A UTILIZZO DEGLI ATTRIBUTI
(informativa)
A.1 Generale
Questa appendice fornisce un prospetto per dimostrare l'uso degli attributi come un modo
per creare viste diverse dei controlli. I cinque esempi di utilizzo di questi attributi (vedere
4.2) sono i seguenti:
a) Tipi di controllo (#Preventive, #Detective, #Corrective)
b) Proprietà di sicurezza delle informazioni (#Confidentiality, #Integrity, #Availability)
c) Concetti di cybersecurity (#Identify, #Protect, #Detect, #Respond, #Recover)
d) Capacità operative (#Governance, #Asset_management, #Information_protection,
#Human_resource_security, #Physical_security, #System_and_network_security,
#Application_security, #Secure_configuration, #Identity_and_access_management,
#Threat_and_vulnerability_management, #Continuity, #Supplier_relationships_security,
#Legal_and_compliance, #Information_security_event_management,
#Information_security_assurance
e) Domini di sicurezza (#Governance_and_Ecosystem, #Protection, #Defence,
#Resilience)
Il prospetto A.1 riporta una matrice di tutti i controlli di questo documento con i valori di
attributo assegnati.
Un filtro od ordinamento della matrice può essere ottenuto utilizzando uno strumento
come un semplice foglio di calcolo o un database, che può contenere più informazioni
quali il testo relativo al controllo, le linee guida, le linee guida specifiche
dell'organizzazione o gli attributi specifici dell'organizzazione (vedere A.2).

prospetto A.1 Matrice dei controlli e valori degli attributi
ISO/IEC 27002 Titolo del controllo Tipo di controllo Proprietà di sicurezza Concetti di Capacità operative Domini di sicurezza
identificatore di delle informazioni cybersecurity
controllo
5.1 Politiche per la #Preventive #Confidentiality #Identify #Governance #Governance_and_Ecosy
sicurezza delle #Integrity #Availability stem #Resilience
informazioni
5.2 Ruoli e responsabilità #Preventive #Confidentiality #Identify #Governance #Governance_and_Ecosy
per la sicurezza delle #Integrity #Availability stem #Protection
informazioni #Resilience
5.3 Separazione dei #Preventive #Confidentiality #Protect #Governance #Governance_and_Ecosy
compiti #Integrity #Availability #Identity_and_access_ma stem
nagement
Identity_and_access_man
agement
5.4 Responsabilità della #Preventive #Confidentiality #Identify #Governance #Governance_and_Ecosy
direzione #Integrity #Availability stem
5.5 Contatti con le autorità #Preventive #Confidentiality #Identify #Governance #Defence #Resilience
#Corrective #Integrity #Availability #Protect#Respond
#Recover
5.6 Contatti con gruppi #Preventive #Confidentiality #Protect#Respond #Governance #Defence
specialistici #Corrective #Integrity #Availability #Recover
5.7 Threat intelligence #Preventive #Confidentiality #Identify #Detect #Threat_and_vulnerability #Defence #Resilience
#Detective #Integrity #Availability #Respond _management
#Corrective Threat_and_vulnerability_
management
5.8 Sicurezza delle #Preventive #Confidentiality #Identify #Protect #Governance #Governance_and_Ecosy
informazioni nella #Integrity #Availability stem #Protection
gestione dei progetti
5.9 Inventario di #Preventive #Confidentiality #Identify #Asset_management #Governance_and_Ecosy
informazioni e degli #Integrity #Availability stem #Protection
altri asset relativi
5.10 Uso accettabile delle #Preventive #Confidentiality #Protect #Asset_management #Governance_and_Ecosy
informazioni e degli #Integrity #Availability #Information_protection stem #Protection
altri asset relativi
5.11 Restituzione degli #Preventive #Confidentiality #Protect #Asset_management #Protection
asset #Integrity #Availability
5.12 Classificazione delle #Preventive #Confidentiality #Identify #Information_protection #Protection #Defence
informazioni #Integrity #Availability
5.13 Etichettatura delle #Preventive #Confidentiality #Protect #Information_protection #Defence #Protection
informazioni #Integrity #Availability
5.14 Trasferimento delle #Preventive #Confidentiality #Protect #Asset_management #Protection
informazioni #Integrity #Availability #Information_protection
5.15 Controllo degli accessi #Preventive #Confidentiality #Protect #Identity_and_access_ma #Protection
#Integrity #Availability nagement
5.16 Gestione delle identità #Preventive #Confidentiality #Protect #Identity_and_access_ma #Protection
5.17 Informazioni di #Preventive #Confidentiality #Protect #Identity_and_access_ma #Protection
autenticazione #Integrity #Availability nagement
5.18 Diritti d’accesso #Preventive #Confidentiality #Protect #Identity_and_access_ma #Protection
5.19 Sicurezza delle #Preventive #Confidentiality #Identify #Supplier_relationships_s #Governance_and_Ecosy
informazioni nelle #Integrity #Availability ecurity stem #Protection
relazioni con i fornitori
5.20 Sicurezza delle #Preventive #Confidentiality #Identify #Supplier_relationships_s #Governance_and_Ecosy
informazioni negli #Integrity #Availability ecurity stem #Protection
accordi con i fornitori
5.21 Gestione della sicurezza #Preventive #Confidentiality #Identify #Supplier_relationships_s #Governance_and_Ecosy
delle informazioni nella #Integrity #Availability ecurity stem #Protection
filiera di fornitura per
l’ICT

prospetto A.1 Matrice dei controlli e valori degli attributi (Continua)
controllo
5.22 Monitoraggio riesame #Preventive #Confidentiality #Identify #Supplier_relationships_s #Governance_and_Ecosy
e gestione dei #Integrity #Availability ecurity stem #Protection
cambiamenti dei #Information_security_as #Defence
servizi dei fornitori surance
5.23 Sicurezza delle #Preventive #Confidentiality #Protect #Supplier_relationships_s #Governance_and_Ecosy
informazioni per l'utilizzo #Integrity #Availability ecurity stem #Protection
di servizi cloud
5.24 Pianificazione e #Corrective #Confidentiality #Respond #Recover #Governance #Defence
preparazione per la #Integrity #Availability #Information_security_ev
gestione degli incidenti ent_management
relativi alla sicurezza
delle informazioni
5.25 Valutazione e #Detective #Confidentiality #Detect #Respond #Information_security_ev #Defence
decisione sugli eventi #Integrity #Availability ent_management
delle informazioni
5.26 Risposta agli incidenti #Corrective #Confidentiality #Respond #Recover #Information_security_ev #Defence
relativi alla sicurezza #Integrity #Availability ent_management
delle informazioni
5.27 Apprendimento dagli #Preventive #Confidentiality #Identify #Protect #Information_security_ev #Defence
incidenti relativi alla #Integrity #Availability ent_management
sicurezza delle
informazioni
5.28 Raccolta di prove #Corrective #Confidentiality #Detect #Respond #Information_security_ev #Defence
#Integrity #Availability ent_management
5.29 Sicurezza delle #Preventive #Confidentiality #Proteggi #Respond #Continuity #Protection #Resilience
informazioni durante #Corrective #Integrity #Availability
le interruzioni
5.30 Prontezza dell’ICT per #Corrective #Availability #Respond #Continuity #Resilience
la continuità operativa
5.31 Identificazione dei #Preventive #Confidentiality #Identify #Lega_and_Compliance #Governance_and_Ecosy
requisiti legali, statutari, #Integrity #Availability stem #Protection
regolamentari e
contrattuali
5.32 Diritti di proprietà #Preventive #Confidentiality #Identify #Lega_and_Compliance #Governance_and_Ecosy
intellettuale #Integrity #Availability stem
5.33 Protezione delle #Preventive #Confidentiality #Identify #Protect #Lega_and_Compliance #Defence
registrazioni #Integrity #Availability #Asset_management
#Information_protection
5.34 Privacy e protezione #Preventive #Confidentiality #Identify #Protect #Information_protection #Protection
dei dati personali #Integrity #Availability #Legal_and_Compliance
5.35 Riesame indipendente #Preventive #Confidentiality #Identify #Protect #Information_security_as #Governance_and_Ecosy
della sicurezza delle #Corrective #Integrity #Availability surance stem
informazioni
5.36 Conformità alle politiche #Preventive #Confidentiality #Identify #Protect #Lega_and_Compliance #Governance_and_Ecosy
e alle norme per la #Integrity #Availability #Information_security_as stem
sicurezza delle surance
informazioni
5.37 Procedure operative #Preventive #Confidentiality #Protect #Recover #Asset_management #Governance_and_Ecosy
documentate #Corrective #Integrity #Availability #Physical_security stem #Protection
#System_and_network_sec #Defence
urity #Application_security
#Identity_and_access_man
agement
#Threat_and_vulnerability_
management #Continuity
#Information_security_event
_management

controllo
6.1 Screening #Preventive #Confidentiality #Protect #Human_resource_securi #Governance_and_Ecosy
#Integrity #Availability ty stem
6.2 Termini e condizioni #Preventive #Confidentiality #Protect #Human_resource_securi #Governance_and_Ecosy
d’impiego #Integrity #Availability ty stem
6.3 Consapevolezza, #Preventive #Confidentiality #Protect #Human_resource_securi #Governance_and_Ecosy
istruzione e #Integrity #Availability ty stem
addestramento sulla
sicurezza delle
informazioni
6.4 Processo disciplinare #Preventive #Confidentiality #Protect #Respond #Human_resource_securi #Governance_and_Ecosy
#Corrective #Integrity #Availability ty stem
6.5 Responsabilità dopo #Preventive #Confidentiality #Protect #Human_resource_securi #Governance_and_Ecosy
la cessazione o il #Integrity #Availability ty #Asset_management stem
cambio d'impiego
6.6 Accordi di #Preventive #Confidentiality #Protect #Human_resource_securi #Governance_and_Ecosy
riservatezza o di non ty #Information_protection stem
divulgazione #Supplier_relationships_s
ecurity
6.7 Lavoro a distanza #Preventive #Confidentiality #Protect #Asset_management #Protection
#Integrity #Availability #Information_protection
#Physical_security
#System_and_network_s
ecurity
6.8 Segnalazione di eventi #Detective #Confidentiality #Detect #Information_security_ev #Defence
delle informazioni
7.1 Perimetro di sicurezza #Preventive #Confidentiality #Protect #Physical_security #Protection
fisica #Integrity #Availability
7.2 Controlli di accesso #Preventive #Confidentiality #Protect #Physical_security #Protection
fisico #Integrity #Availability #Identity_and_access_ma
nagement
7.3 Messa in sicurezza di #Preventive #Confidentiality #Protect #Physical_security #Protection
uffici, locali e strutture #Integrity #Availability #Asset_management
7.4 Monitoraggio della #Detective #Confidentiality #Protect #Detect #Physical_security #Protection #Defence
sicurezza fisica #Preventive #Integrity #Availability
7.5 Protezione dalle #Preventive #Confidentiality #Protect #Physical_security #Protection
minacce fisiche e #Integrity #Availability
ambientali
7.6 Lavoro in aree sicure #Preventive #Confidentiality #Protect #Physical_security #Protection
#Integrity #Availability
7.7 Schermo e scrivania #Preventive #Confidentiality #Protect #Physical_security #Protection
puliti
7.8 Disposizione delle #Preventive #Confidentiality #Protect #Physical_security #Protection
apparecchiature e loro #Integrity #Availability #Asset_management
protezione
7.9 Sicurezza degli asset #Preventive #Confidentiality #Protect #Physical_security #Protection
all’esterno delle sedi #Integrity #Availability #Asset_management
7.10 Supporti di #Preventive #Confidentiality #Protect #Physical_security #Protection
memorizzazione #Integrity #Availability #Asset_management
7.11 Infrastrutture di #Detective #Integrity #Availability #Protect #Detect #Physical_security #Protection
supporto #Preventive
7.12 Sicurezza dei cablaggi #Preventive #Confidentiality #Protect #Physical_security #Protection
#Availability
7.13 Manutenzione delle #Preventive #Confidentiality #Protect #Physical_security #Protection #Resilience
apparecchiature #Integrity #Availability #Asset_management

controllo
7.14 Dismissione sicura o #Preventive #Confidentiality #Protect #Physical_security #Protection
riutilizzo delle #Asset_management
apparecchiature
8.1 Endpoint degli utenti #Preventive #Confidentiality #Protect #Asset_management #Protection
#Integrity #Availability #Information_protection
8.2 Diritti di accesso #Preventive #Confidentiality #Protect #Identity_and_access_ma #Protection
privilegiato #Integrity #Availability nagement
8.3 Limitazione degli #Preventive #Confidentiality #Protect #Identity_and_access_ma #Protection
accessi alle #Integrity #Availability nagement
informazioni
8.4 Accesso al codice #Preventive #Confidentiality #Protect #Identity_and_access_ma #Protection
sorgente #Integrity #Availability nagement
8.5 Autenticazione sicura #Preventive #Confidentiality #Protect #Identity_and_access_ma #Protection
8.6 Gestione della #Detective #Integrity #Availability #Identify #Protect #Continuity #Governance_and_Ecosy
capacità #Preventive #Detect stem #Protection
8.7 Protezione dal #Preventive #Confidentiality #Protect #Detect #System_and_network_s #Protection #Defence
malware #Detective #Integrity #Availability ecurity
#Corrective #Information_protection
8.8 Gestione delle #Preventive #Confidentiality #Identify #Protect #Threat_and_vulnerability #Governance_and_Ecosy
vulnerabilità tecniche #Integrity #Availability _management stem #Protection
#Defence
8.9 Gestione delle #Preventive #Confidentiality #Protect #Secure_configuration #Protection
configurazioni #Integrity #Availability
8.10 Cancellazione delle #Preventive #Confidentiality #Protect #Information_protection #Protection
informazioni #Legal_and_Compliance
8.11 Mascheramento dei #Preventive #Confidentiality #Protect #Information_protection #Protection
dati
8.12 Prevenzione di #Detective #Confidentiality #Protect #Detect #Information_protection #Protection #Defence
leakage delle #Preventive
informazioni
8.13 Backup delle #Corrective #Integrity #Availability #Recover #Continuity #Protection
informazioni
8.14 Ridondanza delle #Preventive #Availability #Protect #Continuity #Protection #Resilience
strutture di #Asset_management
elaborazione delle
informazioni
8.15 Raccolta di log #Detective #Confidentiality #Detect #Information_security_ev #Protection #Defence
8.16 Attività di #Detective #Confidentiality #Detect #Respond #Information_security_ev #Defence
monitoraggio #Corrective #Integrity #Availability ent_management
8.17 Sincronizzazione degli #Detective #Integrity #Protect #Detect #Information_security_ev #Protection #Defence
orologi ent_management
8.18 Utilizzo di programmi #Preventive #Confidentiality #Protect #System_and_network_s #Protection
di utilità privilegiati #Integrity #Availability ecurity
#Sicurezza_configurazion
e #Application_security
8.19 Installazione del #Preventive #Confidentiality #Protect #Secure_configuration #Protection
software su sistemi in #Integrity #Availability #Application_security
esercizio
8.20 Sicurezza delle reti #Detective #Confidentiality #Protect #Detect #System_and_network_s #Protection
#Preventive #Integrity #Availability ecurity
8.21 Sicurezza dei servizi #Preventive #Confidentiality #Protect #System_and_network_s #Protection
di rete #Integrity #Availability ecurity

controllo
8.22 Segregazione delle #Preventive #Confidentiality #Protect #System_and_network_s #Protection
reti #Integrity #Availability ecurity
8.23 Web filtering #Preventive #Confidentiality #Protect #System_and_network_s #Protection
#Integrity #Availability ecurity
8.24 Uso della crittografia #Preventive #Confidentiality #Protect #Secure_configuration #Protection
#Integrity #Availability
8.25 Ciclo di vita dello #Preventive #Confidentiality #Protect #Application_security #Protection
sviluppo sicuro #Integrity #Availability #System_and_network_s
ecurity
8.26 Requisiti di sicurezza #Preventive #Confidentiality #Protect #Application_security #Protection #Defence
delle applicazioni #Integrity #Availability #System_and_network_s
ecurity
8.27 Sicurezza #Preventive #Confidentiality #Protect #Application_security #Protection
dell’architettura dei #Integrity #Availability #System_and_network_s
sistemi e dei principi di ecurity
ingegnerizzazione
8.28 Sviluppo sicuro #Preventive #Confidentiality #Protect #Application_security #Protection
#Integrity #Availability #System_and_network_s
ecurity
8.29 Test di sicurezza in #Preventive #Confidentiality #Identify #Application_security #Protection
fase di sviluppo e di #Integrity #Availability #Information_protection
accettazione #System_and_network_s
ecurity
8.30 Sviluppo affidato #Detective #Confidentiality #Identify #Protect #System_and_network_s #Governance_and_Ecosy
all’esterno #Preventive #Integrity #Availability #Detect ecurity stem #Protection
#Supplier_relationships_s
ecurity
8.31 Separazione degli #Preventive #Confidentiality #Protect #Application_security #Protection
ambienti di sviluppo, #Integrity #Availability #System_and_network_s
test e produzione ecurity
8.32 Gestione dei #Preventive #Confidentiality #Protect #Application_security #Protection
cambiamenti #Integrity #Availability #System_and_network_s
ecurity
8.33 Dati di test #Preventive #Confidentiality #Protect #Information_protection #Protection
#Integrity
8.34 Protezione dei sistemi #Preventive #Confidentiality #Protect #System_and_network_s #Governance_and_Ecosy
informativi durante i #Integrity #Availability ecurity stem #Protection
test di audit #Information_protection
La tabella A.2 mostra un esempio di come creare una vista filtrando in base a un
particolare valore di attributo, in questo caso #Correttiva.

prospetto A.2 Vista dei controlli #correttivi
controllo
5.5 Contatti con le autorità #Preventive #Confidentiality #Identify #Protect #Governance #Defence #Resilience
#Corrective #Integrity #Availability #Respond #Recover
5.6 Contatti con gruppi #Preventive #Confidentiality #Protect #Respond #Governance #Defence
specialistici #Corrective #Integrity #Availability #Recover
5.7 Threat intelligence #Preventive #Confidentiality #Identify #Detect #Threat_and_vulnerability #Defence #Resilience
#Detective #Integrity #Availability #Respond _management
#Corrective
5.24 Pianificazione e #Corrective #Confidentiality #Respond #Recover #Governance #Defence
preparazione per la #Integrity #Availability #Information_security_ev
gestione degli incidenti ent_management
delle informazioni
5.26 Risposta agli incidenti #Corrective #Confidentiality #Respond #Recover #Information_security_ev #Defence
delle informazioni
5.28 Raccolta di prove #Corrective #Confidentiality #Detect #Respond #Information_security_ev #Defence
5.29 Sicurezza delle #Preventive #Confidentiality #Protect #Respond #Continuity #Protection #Resilience
informazioni durante #Corrective #Integrity #Availability
le interruzioni
5.30 Prontezza dell’ICT per #Corrective #Availability #Respond #Continuity #Resilience
la continuità operativa
5.35 Riesame indipendente #Preventive #Confidentiality #Identify #Protect #Information_security_as #Governance_and_Ecosy
della sicurezza delle #Corrective #Integrity #Availability surance stem
informazioni
5.37 Procedure operative #Preventive #Confidentiality #Protect #Recover #Asset_management #Governance_and_Ecosy
documentate #Corrective #Integrity #Availability #Physical_security stem #Protection
#System_and_network_s #Defence
ecurity
#Identity_and_access_ma
nagement
#Threat_and_vulnerability
_management #Continuity
#Information_security_ev
ent_management
6.4 Processo disciplinare #Preventive #Confidentiality #Protect #Respond #Human_resource_securi #Governance_and_Ecosy
#Corrective #Integrity #Availability ty stem
8.7 Protezione dal #Preventive #Confidentiality #Protect #Detect #System_and_network_s #Protection #Defence
malware #Detective #Integrity #Availability ecurity
#Corrective #Information_protection
8.13 Backup delle #Corrective #Integrity #Availability #Recover #Continuity #Protection
informazioni
8.16 Attività di #Detective #Confidentiality #Detect #Respond #Information_security_ev #Defence
monitoraggio #Corrective #Integrity #Availability ent_management
A.2 Viste dell’organizzazione

Poiché gli attributi sono usati per creare diverse viste dei controlli, l’organizzazione può
scartare gli esempi di attributi proposti in questo documento e creare i propri attributi con
diversi valori per affrontare specifiche necessità nell’organizzazione. Inoltre, i valori
assegnati a ciascun attributo possono differire tra organizzazioni, poiché le organizzazioni
possono avere diversi punti di vista sull’uso o sull’applicabilità dei controlli o dei valori
associati agli attributi (quando i valori sono specifici per il contesto dell’organizzazione). Il
primo passo è capire perché è desiderabile un attributo specifico per l'organizzazione. Per

esempio, se un'organizzazione ha elaborato i propri piani di trattamento del rischio
[vedere UNI CEI EN ISO/IEC 27001 : 2017, 6.1.3 e)] in base agli eventi, può voler
associare un attributo di scenario di rischio a ciascun controllo in questo documento.
Il vantaggio di tale attributo è di accelerare l’adempimento al requisito della UNI CEI EN
ISO/IEC 27001 relativo al trattamento del rischio, che consiste nel confrontare i controlli
determinati attraverso il processo di trattamento del rischio (definiti come controlli
“necessari”) con quelli dell’Appendice A della UNI CEI EN ISO/IEC 27001:2017, (che
sono ricavati da questo documento) per assicurare che nessun controllo necessario sia
stato tralasciato.
Una volta che la finalità e i vantaggi sono noti, il passaggio successivo consiste nel
determinare i valori degli attributi. Per esempio, l'organizzazione potrebbe identificare 9
eventi:
1) perdita o furto di dispositivi portatili;
2) perdite o furti dai locali dell'organizzazione;
3) eventi di forza maggiore, atti vandalici e terrorismo;
4) guasti a software, hardware, all’alimentazione elettrica, alla connettività a Internet e
alle comunicazioni;
5) frode;
6) hacking;
7) divulgazione;
8) violazione di leggi;
9) social engineering.
Il secondo passaggio può quindi essere realizzato assegnando degli identificatori a
ciascun evento (per esempio E1, E2,..., E9).
Il terzo passaggio consiste nel copiare gli identificatori del controllo e i nomi del controllo
di questo documento in un foglio di calcolo o in un database e associare i valori degli
attributi a ciascun controllo, ricordando che ogni controllo può avere più di un valore per
ogni attributo.
Il passaggio finale consiste nell'ordinare il foglio di calcolo o interrogare il database per
estrarre le informazioni richieste.
Altri esempi di attributi dell’organizzazione (e possibili valori) includono:
a) maturità (valori dalla serie ISO/IEC 33000 o da altri modelli di maturità);
b) stato di attuazione (da fare, in corso, parzialmente attuato, pienamente attuato);
c) priorità (1, 2, 3, ecc.);
d) aree dell’organizzazione coinvolte (sicurezza, ICT, risorse umane, top management,
ecc.);
e) eventi;
f) asset coinvolti;
e) progettazione ed esercizio, per differenziare i controlli utilizzati nelle diverse fasi del
ciclo di vita del servizio;
g) altri framework con cui l'organizzazione lavora o lavorava.

APPENDICE B CORRISPONDENZA CON LA ISO/IEC 27002:2013
(informativa)
Lo scopo di questa appendice è fornire retrocompatibilità con la ISO/IEC 27002:2013 per
le organizzazioni che attualmente utilizzano tale norma e desiderano ora passare a
questa edizione.
Il prospetto B.1 fornisce la corrispondenza dei controlli specificati nei punti da 5 a 8 con
quelli nella ISO/IEC 27002:2013.
prospetto B.1 Corrispondenza tra i controlli di questo documento e i controlli della ISO/IEC 27002:2013
Identificatore di Identificatore di controllo Titolo del controllo

controllo della della ISO/IEC 27002:2013
ISO/IEC 27002:2022
5.1 05.1.1, 05.1.2 Politiche per la sicurezza delle informazioni
5.2 06.1.1 Ruoli e responsabilità per la sicurezza delle informazioni
5.3 06.1.2 Separazione dei compiti
5.4 07.2.1 Responsabilità della direzione
5.5 06.1.3 Contatti con le autorità
5.6 06.1.4 Contatti con gruppi specialistici
5.7 Nuovo Threat intelligence
5.8 06.1.5, 14.1.1 Sicurezza delle informazioni nella gestione dei progetti
5.9 08.1.1, 08.1.2 Inventario delle informazioni e degli altri asset relativi
5.10 08.1.3, 08.2.3 Uso accettabile delle informazioni e degli altri asset relativi
5.11 08.1.4 Restituzione degli asset
5.12 08.2.1 Classificazione delle informazioni
5.13 08.2.2 Etichettatura delle informazioni
5.14 13.2.1, 13.2.2, 13.2.3 Trasferimento delle informazioni
5.15 09.1.1, 09.1.2 Controllo degli accessi
5.16 09.2.1 Gestione delle identità
5.17 09.2.4, 09.3.1, 09.4.3 Informazioni di autenticazione
5.18 09.2.2, 09.2.5, 09.2.6 Diritti d’accesso
5.19 15.1.1 Sicurezza delle informazioni nelle relazioni con i fornitori
5.20 15.1.2 Sicurezza delle informazioni negli accordi con i fornitori
5.21 15.1.3 Gestione della sicurezza delle informazioni nella filiera di fornitura per l’ICT
5.22 15.2.1, 15.2.2 Monitoraggio, riesame e gestione dei cambiamenti dei servizi dei fornitori
5.23 Nuovo Sicurezza delle informazioni per l'utilizzo di servizi cloud
5.24 16.1.1 Pianificazione e preparazione per la gestione degli incidenti relativi alla sicurezza delle
informazioni
5.25 16.1.4 Valutazione e decisione sugli eventi relativi alla sicurezza delle informazioni
5.26 16.1.5 Risposta agli incidenti relativi alla sicurezza delle informazioni
5.27 16.1.6 Apprendimento dagli incidenti relativi alla sicurezza delle informazioni
5.28 16.1.7 Raccolta di prove
5.29 17.1.1, 17.1.2, 17.1.3 Sicurezza delle informazioni durante le interruzioni
5.30 Nuovo Prontezza dell’ICT per la continuità operativa
5.31 18.1.1, 18.1.5 Identificazione dei requisiti legali, statutari, regolamentari e contrattuali
5.32 18.1.2 Diritti di proprietà intellettuale
5.33 18.1.3 Protezione delle registrazioni
5.34 18.1.4 Privacy e protezione dei dati personali

prospetto B.1 Corrispondenza tra i controlli di questo documento e i controlli della ISO/IEC 27002:2013 (Continua)

ISO/IEC 27002:2022
5.35 18.2.1 Riesame indipendente della sicurezza delle informazioni
5.36 18.2.2, 18.2.3 Conformità a politiche, regole e standard per la sicurezza delle informazioni
5.37 12.1.1 Procedure operative documentate
6.1 07.1.1 Screening
6.2 07.1.2 Termini e condizioni d’impiego
6.3 07.2.2 Consapevolezza, istruzione, formazione e addestramento sulla sicurezza delle informazioni
6.4 07.2.3 Processo disciplinare
6.5 07.3.1 Responsabilità dopo la cessazione o il cambio d’impiego
6.6 13.2.4 Accordi di riservatezza o di non divulgazione
6.7 06.2.2 Lavoro a distanza
6.8 16.1.2, 16.1.3 Segnalazione di eventi relativi alla sicurezza delle informazioni
7.1 11.1.1 Perimetro di sicurezza fisica
7.2 11.1.2, 11.1.6 Controlli di accesso fisico
7.3 11.1.3 Messa in sicurezza di uffici, locali e strutture
7.4 Nuovo Monitoraggio della sicurezza fisica
7.5 11.1.4 Protezione dalle minacce fisiche e ambientali
7.6 11.1.5 Lavoro in aree sicure
7.7 11.2.9 Schermo e scrivania puliti
7.8 11.2.1 Disposizione delle apparecchiature e loro protezione
7.9 11.2.6 Sicurezza degli asset all’esterno delle sedi
7.10 08.3.1, 08.3.2, 08.3.3, 11.2.5 Supporti di memorizzazione
7.11 11.2.2 Infrastrutture di supporto
7.12 11.2.3 Sicurezza dei cablaggi
7.13 11.2.4 Manutenzione delle apparecchiature
7.14 11.2.7 Dismissione sicura o riutilizzo delle apparecchiature
8.1 06.2.1, 11.2.8 Endpoint degli utenti
8.2 09.2.3 Diritti di accesso privilegiato
8.3 09.4.1 Limitazione degli accessi alle informazioni
8.4 09.4.5 Accesso al codice sorgente
8.5 09.4.2 Autenticazione sicura
8.6 12.1.3 Gestione della capacità
8.7 12.2.1 Protezione dal malware
8.8 12.6.1, 18.2.3 Gestione delle vulnerabilità tecniche
8.9 Nuovo Gestione delle configurazioni
8.10 Nuovo Cancellazione delle informazioni
8.11 Nuovo Mascheramento dei dati
8.12 Nuovo Prevenzione di leakage delle informazioni
8.13 12.3.1 Backup delle informazioni
8.14 17.2.1 Ridondanza delle strutture di elaborazione delle informazioni
8.15 12.4.1, 12.4.2, 12.4.3 Raccolta di log
8.16 Nuovo Attività di monitoraggio

prospetto B.1 Corrispondenza tra i controlli di questo documento e i controlli della ISO/IEC 27002:2013 (Continua)

ISO/IEC 27002:2022
8.17 12.4.4 Sincronizzazione degli orologi
8.18 09.4.4 Utilizzo di programmi di utilità privilegiati
8.19 12.5.1, 12.6.2 Installazione di software sui sistemi in esercizio
8.20 13.1.1 Sicurezza delle reti
8.21 13.1.2 Sicurezza dei servizi di rete
8.22 13.1.3 Segregazione delle reti
8.23 Nuovo Web filtering
8.24 10.1.1, 10.1.2 Uso della crittografia
8.25 14.2.1 Ciclo di vita dello sviluppo sicuro
8.26 14.1.2, 14.1.3 Requisiti di sicurezza delle applicazioni
8.27 14.2.5 Sicurezza dell’architettura dei sistemi sicura e dei principi di ingegnerizzazione
8.28 Nuovo Sviluppo sicuro
8.29 14.2.8, 14.2.9 Test di sicurezza in fase di sviluppo e accettazione
8.30 14.2.7 Sviluppo affidato all’esterno
8.31 12.1.4, 14.2.6 Separazione degli ambienti di sviluppo, test e produzione
8.32 12.1.2, 14.2.2, 14.2.3, Gestione dei cambiamenti
14.2.4
8.33 14.3.1 Dati di test
8.34 12.7.1 Protezione dei sistemi informativi durante i test di audit
Il prospetto B.2 fornisce la corrispondenza dei controlli specificati nella

ISO/IEC 27002:2013 con quelli di questo documento.
prospetto B.2 Corrispondenza tra i controlli nella ISO/IEC 27002:2013 e i controlli di questo documento
Identificatore di Identificatore di controllo Titolo del controllo secondo la ISO/IEC 27002:2013

ISO/IEC 27002:2013
5 Politiche per la sicurezza delle informazioni
5.1 Indirizzi della direzione per la sicurezza delle informazioni
5.1.1 5.1 Politiche per la sicurezza delle informazioni
5.1.2 5.1 Riesame delle politiche per la sicurezza delle informazioni
6 Organizzazione della sicurezza delle informazioni
6.1 Organizzazione interna
6.1.1 5.2 Ruoli e responsabilità per la sicurezza delle informazioni
6.1.2 5.3 Separazione dei compiti
6.1.3 5.5 Contatti con le autorità
6.1.4 5.6 Contatti con gruppi specialistici
6.1.5 5.8 Sicurezza delle informazioni nella gestione dei progetti
6.2 Dispositivi portatili e telelavoro
6.2.1 8.1 Politica sui dispositivi portatili
6.2.2 6.7 Telelavoro
7 Sicurezza delle risorse umane
7.1 Prima dell'impiego
7.1.1 6.1 Screening

prospetto B.2 Corrispondenza tra i controlli nella ISO/IEC 27002:2013 e i controlli di questo documento (Continua)

ISO/IEC 27002:2013
7.1.2 6.2 Termini e condizioni di impiego
7.2 Durante l’impiego
7.2.1 5.4 Responsabilità della direzione
7.2.2 6.3 Consapevolezza, istruzione, formazione e addestramento sulla sicurezza delle informazioni
7.2.3 6.4 Processo disciplinare
7.3 Cessazione e variazione del rapporto di lavoro
7.3.1 6.5 Cessazione o variazione delle responsabilità durante il rapporto di lavoro
8 Gestione degli asset
8.1 Responsabilità per gli asset
8.1.1 5.9 Inventario degli asset
8.1.2 5.9 Responsabilità degli asset
8.1.3 5.10 Utilizzo accettabile degli asset
8.1.4 5.11 Restituzione degli asset
8.2 Classificazione delle informazioni
8.2.1 5.12 Classificazione delle informazioni
8.2.2 5.13 Etichettatura delle informazioni
8.2.3 5.10 Trattamento degli asset
8.3 Trattamento dei supporti
8.3.1 7.10 Gestione dei supporti rimovibili
8.3.2 7.10 Dismissione dei supporti
8.3.3 7.10 Trasporto dei supporti fisici
9 Controllo degli accessi
9.1 Requisiti di business per il controllo degli accessi
9.1.1 5.15 Politica di controllo degli accessi
9.1.2 5.15 Accesso alle reti e ai servizi di rete
9.2 Gestione degli accessi degli utenti
9.2.1 5.16 Registrazione e de-registrazione degli utenti
9.2.2 5.18 Provisioning degli accessi degli utenti
9.2.3 8.2 Gestione dei diritti di accesso privilegiato
9.2.4 5.17 Gestione delle informazioni segrete di autenticazione degli utenti
9.2.5 5.18 Riesame dei diritti di accesso degli utenti
9.2.6 5.18 Rimozione o adattamento dei diritti di accesso
9.3 Responsabilità dell'utente
9.3.1 5.17 Utilizzo delle informazioni segrete di autenticazione
9.4 Controllo degli accessi ai sistemi e alle applicazioni
9.4.1 8.3 Limitazione dell’accesso alle informazioni
9.4.2 8.5 Procedure di log-on sicure
9.4.3 5.17 Sistema di gestione delle password
9.4.4 8.18 Uso di programmi di utilità privilegiati
9.4.5 8.4 Controllo degli accessi al codice sorgente dei programmi
10 Crittografia
10.1 Controlli crittografici


ISO/IEC 27002:2013
10.1.1 8.24 Politica sull'uso dei controlli crittografici
10.1.2 8.24 Gestione delle chiavi
11 Sicurezza fisica e ambientale
11.1 Aree sicure
11.1.1 7.1 Perimetro di sicurezza fisica
11.1.2 7.2 Controlli di accesso fisico
11.1.3 7.3 Rendere sicuri uffici, locali e strutture
11.1.4 7.5 Protezione contro minacce esterne ed ambientali
11.1.5 7.6 Lavoro in aree sicure
11.1.6 7.2 Aree di carico e scarico
11.2 Apparecchiature
11.2.1 7.8 Disposizione e protezione delle apparecchiature
11.2.2 7.11 Infrastrutture di supporto
11.2.3 7.12 Sicurezza dei cablaggi
11.2.4 7.13 Manutenzione delle apparecchiature
11.2.5 7.10 Trasferimento degli asset
11.2.6 7.9 Sicurezza delle apparecchiature e degli asset fuori sede
11.2.7 7.14 Dismissione sicura o riutilizzo delle apparecchiature
11.2.8 8.1 Apparecchiature incustodite degli utenti
11.2.9 7.7 Politica di schermo e scrivania puliti
12 Sicurezza delle attività operative
12.1 Procedure operative e responsabilità
12.1.1 5.37 Procedure operative documentate
12.1.2 8.32 Gestione dei cambiamenti
12.1.3 8.6 Gestione della capacità
12.1.4 8.31 Separazione degli ambienti di sviluppo, test e produzione
12.2 Protezione dal malware
12.2.1 8.7 Controlli contro il malware
12.3 Backup
12.3.1 8.13 Backup delle informazioni
12.4 Raccolta di log e monitoraggio
12.4.1 8.15 Raccolta di log degli eventi
12.4.2 8.15 Protezione delle informazioni di log
12.4.3 8.15 Log di amministratori e operatori
12.4.4 8.17 Sincronizzazione degli orologi
12.5 Controllo del software di produzione
12.5.1 8.19 Installazione del software su sistemi di produzione
12.6 Gestione delle vulnerabilità tecniche
12.6.1 8.8 Gestione delle vulnerabilità tecniche
12.6.2 8.19 Limitazioni all'installazione del software
12.7 Considerazioni sull'audit dei sistemi informativi


ISO/IEC 27002:2013
12.7.1 8.34 Controlli per l’audit dei sistemi informativi
13 Sicurezza delle comunicazioni
13.1 Gestione della sicurezza della rete
13.1.1 8.20 Controlli di rete
13.1.2 8.21 Sicurezza dei servizi di rete
13.1.3 8.22 Segregazione nelle reti
13.2 Trasferimento delle informazioni
13.2.1 5.14 Politiche e procedure per il trasferimento delle informazioni
13.2.2 5.14 Accordi per il trasferimento di informazioni
13.2.3 5.14 Messaggistica elettronica
13.2.4 6.6 Accordi di riservatezza o di non divulgazione
14 Acquisizione, sviluppo e manutenzione dei sistemi
14.1 Requisiti di sicurezza dei sistemi informativi
14.1.1 5.8 Analisi e specifica dei requisiti per la sicurezza delle informazioni
14.1.2 8.26 Sicurezza dei servizi applicativi su reti pubbliche
14.1.3 8.26 Protezione delle transazioni dei servizi applicativi
14.2 Sicurezza nei processi di sviluppo e supporto
14.2.1 8.25 Politica per lo sviluppo sicuro
14.2.2 8.32 Procedure per il controllo dei cambiamenti di sistema
14.2.3 8.32 Riesame tecnico delle applicazioni in seguito a cambiamenti nelle piattaforme operative
14.2.4 8.32 Limitazioni ai cambiamenti ai pacchetti software
14.2.5 8.27 Principi per l’ingegnerizzazione sicura dei sistemi
14.2.6 8.31 Ambiente di sviluppo sicuro
14.2.7 8.30 Sviluppo affidato all’esterno
14.2.8 8.29 Test di sicurezza dei sistemi
14.2.9 8.29 Test di accettazione dei sistemi
14.3 Dati di test
14.3.1 8.33 Protezione dei dati di test
15 Relazioni con i fornitori
15.1 Sicurezza delle informazioni nelle relazioni con i fornitori
15.1.1 5.19 Politica per la sicurezza delle informazioni nei rapporti con i fornitori
15.1.2 5.20 Indirizzare la sicurezza all'interno degli accordi con i fornitori
15.1.3 5.21 Filiera di fornitura per l’ICT
15.2 Gestione dell'erogazione dei servizi dei fornitori
15.2.1 5.22 Monitoraggio e riesame dei servizi dei fornitori
15.2.2 5.22 Gestione dei cambiamenti ai servizi dei fornitori
16 Gestione degli incidenti relativi alla sicurezza delle informazioni
16.1 Gestione degli incidenti relativi alla sicurezza delle informazioni e dei miglioramenti
16.1.1 5.24 Responsabilità e procedure
16.1.2 6.8 Segnalazione di eventi relativi alla sicurezza delle informazioni
16.1.3 6.8 Segnalazione dei punti di debolezza relativi alla sicurezza delle informazioni


ISO/IEC 27002:2013
16.1.4 5.25 Valutazione e decisione sugli eventi relativi alla sicurezza delle informazioni
16.1.5 5.26 Risposta agli incidenti relativi alla sicurezza delle informazioni
16.1.6 5.27 Apprendimento dagli incidenti relativi alla sicurezza delle informazioni
16.1.7 5.28 Raccolta di evidenze
17 Aspetti relativi alla sicurezza delle informazioni nella gestione della continuità operativa
17.1 Continuità della sicurezza delle informazioni
17.1.1 5.29 Pianificazione della continuità della sicurezza delle informazioni
17.1.2 5.29 Attuazione della continuità della sicurezza delle informazioni
17.1.3 5.29 Verifica, riesame e valutazione della continuità della sicurezza delle informazioni
17.2 Ridondanze
17.2.1 8.14 Disponibilità delle strutture per l'elaborazione delle informazioni
18 Conformità
18.1 Conformità ai requisiti cogenti e contrattuali
18.1.1 5.31 Identificazione della legislazione applicabile e dei requisiti contrattuali
18.1.2 5.32 Diritti di proprietà intellettuale
18.1.3 5.33 Protezione delle registrazioni
18.1.4 5.34 Privacy e protezione dei dati personali
18.1.5 5.31 Regolamentazione sui controlli crittografici
18.2 Riesami della sicurezza delle informazioni
18.2.1 5.35 Riesame indipendente della sicurezza delle informazioni
18.2.2 5.36 Conformità alle politiche e alle norme per la sicurezza
18.2.3 5.36, 8.8 Verifica tecnica della conformità

BIBLIOGRAFIA
[1] ISO 9000 Quality management systems - Fundamentals and
vocabulary
[2] ISO 55001 Asset management - Management systems -
Requirements
[3] ISO/IEC 11770 (tutte le parti) Information security - Key management
[4] ISO/IEC 15408 (tutte le parti) Information technology - Security techniques
-Evaluation criteria for IT security
[5] ISO 15489 (tutte le parti) Information and documentation - Records
management
[6] ISO/IEC 17788 Information technology - Cloud computing -
Overview and vocabulary
Reference architecture
[8] ISO/IEC 19086 (tutte le parti) Cloud computing - Service level agreement (SLA)
framework
[9] ISO/IEC 19770 (tutte le parti) Information technology - IT asset management
Interoperability and portability
[11] ISO/IEC 20889 Privacy enhancing data de-identification
terminology and classification of techniques
[12] ISO 21500 Project, programme and portfolio management
-Context and concepts
[13] ISO 21502 Project, programme and portfolio management -
Guidance on project management
[14] ISO 22301 Security and resilience - Business continuity
management systems - Requirements
[15] ISO 22313 Security and resilience - Business continuity
management systems - Guidance on the use of
ISO 22301
[16] ISO/TS 22317 Societal security - Business continuity
management systems - Guidelines for business
impact analysis (BIA)
[17] ISO 22396 Security and resilience - Community resilience -
Guidelines for information exchange between
organizations
[18] ISO/IEC/TS 23167 Information technology - Cloud computing -
Common technologies and techniques
[19] ISO/IEC 23751:-1) Information technology - Cloud computing and
distributed platforms - Data sharing agreement
(DSA) framework
[20] ISO/IEC 24760 (tutte le parti) IT Security and Privacy - A framework for identity
management
[21] ISO/IEC 27001:2013 Information technology - Security techniques -
Information security management systems -
Requirements
[22] ISO/IEC 27005 Information technology - Security techniques -
Information security risk management
[23] ISO/IEC 27007 Information security, cybersecurity and privacy
protection - Guidelines for information security
management systems auditing
1) Sotto preparazione. Fase al momento della pubblicazione: ISO/IEC DIS 23751:2021.

[24] ISO/IEC/TS 27008 Information technology - Security techniques -
Guidelines for the assessment of information
security controls
Code of practice for Information security
controls based on ISO/IEC 27002 for
telecommunications organizations
[26] ISO/IEC/TR 27016 Information technology - Security techniques -
Information security management -
Organizational economics
Code of practice for information security
controls based on ISO/IEC 27002 for cloud
services
Code of practice for protection of personally
identifiable information (PII) in public clouds
acting as PII processors
Information security controls for the energy
utility industry
Guidelines for information and communication
technology readiness for business continuity
[31] ISO/IEC 27033 (tutte le parti) Information technology - Security techniques -
Network security
[32] ISO/IEC 27034 (tutte le parti) Information technology - Application security
Information security incident management
Information security for supplier relationships
Guidelines for identification, collection,
acquisition and preservation of digital
evidence
Storage security
[37] ISO/IEC 27050 (tutte le parti) Information technology - Electronic discovery
[38] ISO/IEC/TS 27110 Information technology, cybersecurity and
privacy protection - Cybersecurity framework
development guidelines
[39] ISO/IEC 27701 Security techniques - Extension to ISO/IEC
27001 and ISO/IEC 27002 for privacy
information management - Requirements and
guidelines
[40] ISO 27799 Health informatics - Information security
management in health using ISO/IEC 27002
Privacy framework
Entity authentication assurance framework
Guidelines for privacy impact assessment
A framework for access management

Vulnerability disclosure
[46] ISO 30000 Ships and marine technology - Ship recycling
management systems - Specifications for
management systems for safe and
environmentally sound ship recycling facilities
Vulnerability handling processes
[48] ISO 31000:2018 Risk management - Guidelines
[49] IEC 31010 Risk management - Risk assessment
techniques
[50] ISO/IEC 22123 (tutte le parti), Information technology - Cloud computing
[51] ISO/IEC 27555 Information security, cybersecurity and privacy protection -
Guidelines on personally identifiable information deletion
[52] Information Security Forum (ISF). The ISF Standard of Good Practice for
Information Security 2020, August 2018. Available at
https:/www.securityforum.org/tool/standard-of -good-practice-for-information-security-2020/
[53] ITIL® Foundation, ITIL 4 edition, AXELOS, February 2019, ISBN: 9780113316076
[54] National Institute of Standards and Technology (NIST), SP 800-37, Risk
Management Framework for Information Systems and Organizations: A System
Life Cycle Approach for Security and Privacy, Revision 2. December 2018 [viewed
2020-07-31]. Available at https://doi.org/10.6028/NIST.SP.800-37r2
[55] Open Web Application Security Project (OWASP). OWASP Top Ten - 2017, The
Ten Most Critical Web Application Security Risks, 2017 [viewed 2020-07-31].
Available at https://owasp.org/www-project-top-ten/OWASP_Top_Ten_2017/
[56] Open Web Application Security Project (OWASP). OWASP Developer Guide,
[online] [viewed 2020-10-22]. Available at https://github.com/OWASP/DevGuide
[57] National Institute of Standards and Technology (NIST), SP 800-63B, Digital Identity
Guidelines; Authentication and Lifecycle Management. February 2020 [viewed
2020-07-31]. Available at https://doi.org/10.6028/NIST.SP.800-63b
[58] OASIS, Structured Threat Information Expression. Available at
https://www.oasis-open.org/standards#stix2.0
[59] OASIS, Trusted Automated Exchange of Indicator Information. Available at
https://www.oasis-open.org/standards#taxii2.0

NORMA TECNICA CEI UNI EN ISO/IEC 27002
La presente Norma è stata compilata dal Comitato Elettrotecnico Italiano e beneficia del
riconoscimento di cui alla legge 1° Marzo 1968, n. 186.
Editore CEI, Comitato Elettrotecnico Italiano, Milano vP-wyV
Stampa in proprio
Autorizzazione del Tribunale di Milano N. 4093 del 24 Luglio 1956
Direttore Responsabile: Ing. G. Molina
Comitato Tecnico Elaboratore

CT 700-Elettrotecnica - Argomenti correlati
Altre Norme di possibile interesse sull’argomento
156
Via Saccardo, 9
20134 Milano
Tel. 02.21006.1
Fax 02.21006.210
cei@ceinorme.it
www.ceinorme.it

Iso 27002-2022 Ita

Caricato da

Informazioni sul documento

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Iso 27002-2022 Ita

Caricato da

Copyright:

Formati disponibili

N O R M A I T A L I A N A C E I

Norma Italiana Data Pubblicazione

CEI UNI EN ISO/IEC 27002 2023-04

Sicurezza delle informazioni, cybersecurity e protezione della privacy -

Information security, cybersecurity and privacy protection - Information

© CEI COMITATO ELETTROTECNICO ITALIANO - Milano 2023. Riproduzione vietata

Norma italiana CEI UNI EN ISO/IEC 27002

COLLEGAMENTI/RELAZIONI TRA DOCUMENTI

Europei (IDT) EN ISO/IEC 27002:2022-11;

Pubblicazione Norma Tecnica

Approvata da Presidente del CEI In data 13-02-2023

CENELEC In data 30-10-2022

Sottoposta a Chiusura in data

1 SCOPO E CAMPO DI APPLICAZIONE 5

3 TERMINI, DEFINIZIONI E ABBREVIAZIONI 6

4 STRUTTURA DEL DOCUMENTO 10

UNI CEI EN ISO/IEC 27002:2023 © UNI Pagina III

6 CONTROLLI SUL PERSONALE 60

UNI CEI EN ISO/IEC 27002:2023 © UNI Pagina IV

APPENDICE A UTILIZZO DEGLI ATTRIBUTI 132

APPENDICE B CORRISPONDENZA CON LA ISO/IEC 27002:2013 140

UNI CEI EN ISO/IEC 27002:2023 © UNI Pagina V

UNI CEI EN ISO/IEC 27002:2023 © UNI Pagina 1

UNI CEI EN ISO/IEC 27002:2023 © UNI Pagina 2

0.1 Scenario e contesto

0.2 Requisiti di sicurezza delle informazioni

UNI CEI EN ISO/IEC 27002:2023 © UNI Pagina 3

0.4 Determinazione dei controlli

0.5 Sviluppo di linee guida specifiche per l'organizzazione

UNI CEI EN ISO/IEC 27002:2023 © UNI Pagina 4

0.7 Norme correlate

1 SCOPO E CAMPO DI APPLICAZIONE

UNI CEI EN ISO/IEC 27002:2023 © UNI Pagina 5

3.1 Termini e definizioni

3.1.2 asset: Qualsiasi cosa cha ha valore per l’organizzazione.

3.1.6 catena di custodia: Possesso, movimento, trattamento e localizzazione dimostrabili di

3.1.8 controllo: Misura che mantiene e/o modifica il rischio.

UNI CEI EN ISO/IEC 27002:2023 © UNI Pagina 6

3.1.11 entità: Elemento pertinente all’operatività di un dominio che ha un'esistenza distinta

3.1.12 struttura di elaborazione delle informazioni: Qualsiasi sistema di elaborazione delle

3.1.20 personale: Persone che lavorano sotto la direzione dell'organizzazione.

UNI CEI EN ISO/IEC 27002:2023 © UNI Pagina 7

3.1.22 interessato: Persona fisica a cui i dati personali si riferiscono.

3.1.26 procedura: Modalità designata per svolgere un'attività o un processo (3.1.27).

3.1.31 affidabilità: Proprietà di coerenza del comportamento e dei risultati attesi.

3.1.32 regola: Principio accettato o istruzione che afferma le aspettative dell'organizzazione su

UNI CEI EN ISO/IEC 27002:2023 © UNI Pagina 8

3.1.36 utente: Stakeholder (3.1.18) con accesso ai sistemi informativi (3.1.17)

UNI CEI EN ISO/IEC 27002:2023 © UNI Pagina 9

4 STRUTTURA DEL DOCUMENTO

UNI CEI EN ISO/IEC 27002:2023 © UNI Pagina 10

UNI CEI EN ISO/IEC 27002:2023 © UNI Pagina 11

4.3 Schema dei controlli

5.1 Politiche per la sicurezza delle informazioni

Tipo di controllo Proprietà di sicurezza Concetti di Capacità operative Domini di sicurezza

UNI CEI EN ISO/IEC 27002:2023 © UNI Pagina 12

UNI CEI EN ISO/IEC 27002:2023 © UNI Pagina 13

Politica per la sicurezza delle informazioni Politica specifica

5.2 Ruoli e responsabilità per la sicurezza delle informazioni

Tipo di controllo Proprietà di sicurezza Concetti di Capacità Domini di sicurezza

UNI CEI EN ISO/IEC 27002:2023 © UNI Pagina 14

5.3 Separazione dei compiti

Tipo di controllo Proprietà di Concetti di Capacità operative Domini di sicurezza