Procedura per la gestione del ciclo di vita dei

Transcript

TECHNICAL STANDARDS
PROCEDURA PER LA GESTIONE DEL CICLO DI VITA DEI
SERVIZI E DEI SISTEMI
VERSIONE:
1.0
DATA:
EMISSIONE:
Direzione Produzione, Sistemi informativi e Servizi generali (DPSS)
Febbraio 2016
TABELLA DELLE REVISIONI
N° Rev.
Data
Causale Revisione
0.1
Dicembre 2014
Bozza di discussione
1.0
Febbraio 2016
Prima emissione
GELE - Procedura per la gestione del ciclo di vita dei servizi e
dei sistemi_v1.0.docx
Note
Gruppo Editoriale l’Espresso S.p.A.
Pagina 1 di 19
TECHNICAL STANDARD:
Procedura per la gestione del ciclo di vita dei servizi e dei sistemi
Emissione: DPSS
Versione 1.0
Data: Febbraio 2016
INDICE
1.
Scopo del documento e campo di applicazione ............................................................................. 3
2.
Acronimi e definizioni ........................................................................................................................ 4
3.
Riferimenti e documenti collegati ..................................................................................................... 5
4.
Ruoli e responsabilità ........................................................................................................................ 6
5.
Descrizione della Procedura Generale ............................................................................................. 7
5.1.
Requisiti di Sicurezza .................................................................................................................... 7
5.2.
Progettazione .................................................................................................................................. 8
5.2.1.
Raccolta e formalizzazione dei requisiti .................................................................................. 9
5.2.2.
Stesura delle specifiche progettuali ........................................................................................ 9
5.2.3.
Specifiche Infrastrutturali ....................................................................................................... 10
5.2.4.
Specifiche funzionali e dell’architettura applicativa ............................................................ 10
5.3.
Realizzazione - Sviluppo.............................................................................................................. 11
5.4.
Test e Integrazione ....................................................................................................................... 12
5.5.
Passaggio in produzione ............................................................................................................. 13
5.6.
Gestione in produzione ............................................................................................................... 13
5.6.1.
Gestione dell’infrastruttura tecnologica ................................................................................ 14
5.6.2.
Controllo Accessi .................................................................................................................... 14
5.6.3.
Capacity Management ............................................................................................................. 15
5.6.4.
Protezione da software dannosi ............................................................................................. 15
5.6.5.
Configuration Management .................................................................................................... 16
5.6.6.
Change Management ............................................................................................................... 17
5.6.7.
Gestione dei Backup ............................................................................................................... 18
5.6.8.
Gestione dei servizi ................................................................................................................. 18
5.6.9.
Verifiche tecniche e tracciamento .......................................................................................... 19
5.7.
Dismissione .................................................................................................................................. 19
Pagina 2 di 19
TECHNICAL STANDARD:
Emissione: DPSS
Versione 1.0
Data: Febbraio 2016
1. Scopo del documento e campo di applicazione
Il presente documento ha l’obiettivo di prescrivere le misure che devono essere adottate per integrare gli
aspetti di sicurezza delle informazioni in tutte le fasi del ciclo di vita dei sistemi e dei servizi IT progettati,
sviluppati, utilizzati o gestiti dal Gruppo Editoriale L’Espresso S.p.A. (di seguito anche GELE) o da terze parti
per suo conto.
La presente Procedura Specifica si applica a tutti i sistemi e servizi IT progettati, sviluppati, utilizzati o gestiti
da GELE o da terze parti per suo conto.
In particolare si applica a tutto il personale delle funzioni che si occupano di progettare, sviluppare e gestire
prodotti e servizi e di gestire l’infrastruttura a supporto degli stessi, in quanto responsabili per GELE di tutti gli
aspetti legati ai sistemi e servizi offerti.
Pagina 3 di 19
TECHNICAL STANDARD:
Emissione: DPSS
Versione 1.0
Data: Febbraio 2016
2. Acronimi e definizioni
Committente – Funzione/Area di GELE che indirizza lo sviluppo e l’evoluzione di un sistema, rappresentando
le esigenze funzionali, di sicurezza e di conformità dei processi di business supportati dal sistema stesso; è
colui che autorizza e trasmette alla Funzione IT i requisiti per gli interventi sul software sull’hardware e
sull’infrasruttura in genere.
Dati personali - Ai sensi del D.Lgs 196/2003 (Codice in materia di protezione dei dati personali) con tale
termine si intende “qualunque informazione relativa a persona fisica, persona giuridica, ente od associazione,
identificati o identificabili, anche indirettamente, mediante riferimento a qualsiasi altra informazione, ivi
compreso un numero di identificazione personale”;
DPSS - Direzione Produzione, Sistemi informativi e Servizi generali di GELE;
Virus - Programma in grado di danneggiare, anche irreversibilmente, i dati e le applicazioni di un computer.
Sovente può essere introdotto da un messaggio di posta elettronica o scaricando dei file non sicuri da Internet.
Pagina 4 di 19
TECHNICAL STANDARD:
Emissione: DPSS
Versione 1.0
Data: Febbraio 2016
3. Riferimenti e documenti collegati

D.Lgs 196 del 30/06/2003 “Codice in materia di protezione dei
dati personali”

D.Lgs 231/2001 “Disciplina della responsabilità amministrativa
delle persone giuridiche, delle società e delle associazioni anche
prive di personalità giuridica, a norma dell'articolo 11 della legge
29 settembre 2000, n. 300"”

L. 547/93 “Modificazioni ed integrazioni delle norme del codice
penale in tema di criminalità informatica”

Legge 248/00 “Nuove norme di tutela del diritto d’autore”

D.L.518/92 “attuazione della direttiva 91/250/CEE relativa alla
tutela giuridica dei programmi per elaboratore”
Standard di Riferimento

ISO\IEC 27001:2005 “Information Technology — Security
techniques — Information Security Management Systems”
Documenti emessi da GELE

Codice Etico

Modello di Gestione, Organizzazione e Controllo – parte
generale

Modello di Gestione, Organizzazione e Controllo – parte speciale


Politica Generale per la Sicurezza delle Informazioni di GELE
Norme comportamentali per la gestione sicura delle risorse
aziendali
Norme di legge
Documenti Collegati
Pagina 5 di 19
TECHNICAL STANDARD:
Emissione: DPSS
Versione 1.0
Data: Febbraio 2016
4. Ruoli e responsabilità
In base alle indicazioni riportate nella presente procedura la Direzione DPSS, in quanto responsabile per il
mantenimento e miglioramento del sistema di Sicurezza delle Informazioni di GELE, ha la responsabilità di:

supportare le funzioni aziendali preposte nella definizione delle specifiche di sicurezza;

supportare le funzioni nella definizione di contromisure sulla base delle risultanze dell’analisi dei
rischi;

partecipare alla valutazione dei rischi connessi all’introduzione di nuove funzionalità;

ricevere rapporti periodici sulle potenziali situazioni di pericolo;

collaborare alla predisposizione di piani formativi per il personale e per gli amministratori dei sistemi
di sicurezza.
Pagina 6 di 19
TECHNICAL STANDARD:
Emissione: DPSS
Versione 1.0
Data: Febbraio 2016
5. Descrizione della Procedura Generale
Per tutti i sistemi e i servizi IT è possibile identificare uno specifico ciclo di vita, vale a dire una sequenza di
fasi nell’ambito delle quali diverse sono le logiche ed i principi di gestione cui occorre rifarsi. Nello specifico, le
fasi del ciclo di vita risultano essere le seguenti:

progettazione;

realizzazione - sviluppo;

test e integrazione;

gestione del passaggio in produzione;

gestione in produzione;

dismissione.
I sistemi e servizi IT di GELE (propri/in uso), cui fa riferimento la presente procedura aziendale, comprendono
in particolare:

hardware per elaborazione dati e voce (computer, centralini, router ecc.);

software (sviluppato in GELE, acquisito o in uso);

architetture complesse costituite da hardware e software.
L’applicazione delle opportune misure di sicurezza in ogni sopraelencata fase consente la protezione ottimale
dei sistemi e dei servizi IT nonché delle informazioni e dei dati trattati.
A tutela e prevenzione dalle frodi o da errori su sistemi e reti di GELE, deve essere implementata una formale
separazione dei compiti.
Devono essere a tal proposito redatte opportune procedure specifiche che assicurino che le funzioni che
svolgono attività di sviluppo di sistemi e reti e quelle che svolgono attività relative alla gestione in esercizio
sono svolte da personale diverso. Qualora tale separazione non fosse possibile, dovranno essere implementati
controlli di sicurezza aggiuntivi con l’obiettivo di ridurre il rischio di incidenti. Tali controlli o procedure a
supporto dovranno essere revisionati annualmente.
5.1. Requisiti di Sicurezza
Nell’ambito della gestione dell’intero ciclo di vita dei sistemi e dei servizi IT, occorre riferirsi ad un insieme di
requisiti di sicurezza generali, nel seguito elencati:

nell’ambito di tutte le attività deve essere tenuta in considerazione la necessità di preservare la
riservatezza, l’integrità e la disponibilità delle informazioni gestite, in accordo con il loro livello di
importanza e criticità;
Pagina 7 di 19
TECHNICAL STANDARD:
Emissione: DPSS

Versione 1.0
Data: Febbraio 2016
deve essere assicurata la disponibilità di capacità e di risorse adeguate per ottenere le prestazioni
richieste;

devono essere mantenuti, per quanto possibile, separati gli ambienti fisici e logici utilizzati nelle varie
fasi del ciclo di vita;

devono essere segregate le attività e le aree di responsabilità per ridurre le opportunità di modifiche
non autorizzate o non intenzionali delle risorse aziendali o il loro uso improprio;

tutte le applicazioni (sviluppate e mantenute in esercizio) devono rispondere alle previsioni legislative
e normative vigenti, con particolare attenzione a quanto richiesto dal D.Lgs 196/03 concernente la
protezione dei dati personali e al provvedimento del Garante Privacy del 27/11/2008 concernente
l’operato degli amministratori di sistema;

nello sviluppo di applicazioni, nel caso in cui si utilizzi software di terze parti, la società deve affidarsi
solo a fornitori che sono in grado di garantire elevati livelli di efficienza ed affidabilità;

tutte le clausole contrattuali disciplinanti il rapporto con le terze parti devono essere note e rispettate
nell’ambito della conduzione delle diverse attività.
Nei paragrafi successivi viene illustrato un dettaglio dei requisiti per ciascuna fase del ciclo di vita dei
sistemi/servizi:

progettazione;

realizzazione/sviluppo;

test e integrazione;

passaggio in produzione;

gestione;

dismissione.
5.2. Progettazione
Nell’ambito dell’attività di progettazione, di nuovi sistemi e servizi IT o di evoluzione degli stessi, sono previste
due attività principali:
la raccolta e formalizzazione dei requisiti definiti dal Committente;
la stesura delle specifiche di progettazione.
In tale contesto bisogna prestare attenzione ai seguenti requisiti:

tutte le attività di miglioramento/modifica di sistemi e servizi IT devono essere precedute dalla
definizione dei requisiti necessari a soddisfare le esigenze del Committente;
Pagina 8 di 19
TECHNICAL STANDARD:
Emissione: DPSS

Versione 1.0
Data: Febbraio 2016
nell’ambito dell’attività di progettazione bisogna prestare attenzione alla coerenza tra requisiti di
sicurezza previsti e ambito di utilizzo dei sistemi e dei servizi da realizzare (in termini di criticità, natura
delle informazioni da gestite etc.);

quanto definito nell’ambito delle attività di raccolta e formalizzazione dei requisiti deve essere
mantenuto coerente con quanto definito nella successiva fase di stesura delle specifiche progettuali.
5.2.1. Raccolta e formalizzazione dei requisiti
Le funzioni responsabili dell’interfacciamento con il Committente devono recepire le esigenze dello stesso e
tradurle in requisiti. Nell’ambito dell’attività di formalizzazione dei requisiti occorre prestare attenzione ai
seguenti aspetti:

i requisiti devono essere riportati formalmente in un documento di progetto, evidenziando gli aspetti
funzionali, architetturali, di sicurezza, ecc… Nel documento devono essere riportati anche gli eventuali
rischi derivanti dall’implementazione dei servizi necessari per rispondere alle esigenze espresse dal
Committente;

i requisiti devono comprendere le esigenze in materia di protezione, controllo e verifica dei dati, delle
informazioni, dei processi elaborativi e delle attività operative ad esse correlate. Qualora il
Committente non li esprima formalmente, è compito di chi dovrà occuparsi della realizzazione/sviluppo
esplicitarli per favorire la definizione delle specifiche;

la richiesta di introduzione di nuovi elementi in ambienti già esistenti deve essere chiaramente definita
e sottoposta ad attenta analisi da parte della Direzione DPSS per valutare gli eventuali rischi associati;

il documento contenente i requisiti deve essere formalmente approvato nel rispetto delle logiche di
lavoro adottate da GELE e comunicato alle funzioni responsabili della progettazione.
5.2.2. Stesura delle specifiche progettuali
Le specifiche progettuali devono recepire e contestualizzare in direttive tecniche ed operative i requisiti
espressi. Le specifiche devono essere riportate in uno o più documenti al cui interno devono essere
identificabili le specifiche infrastrutturali, le specifiche funzionali e dell’architettura applicativa, nonché le
specifiche di gestione del servizio.
Nell’ambito dell’attività occorre prendere in considerazione almeno i seguenti aspetti:

i vincoli normativi vigenti;

le procedure e le disposizioni aziendali;

gli aspetti di sicurezza fisica (se applicabili);

la formalizzazione e completezza della documentazione;
Pagina 9 di 19
TECHNICAL STANDARD:
Emissione: DPSS
Versione 1.0
Data: Febbraio 2016

la necessità di prevedere un’adeguata formazione del personale;

l’aderenza alle best practice nazionali e internazionali in merito alla progettazione e gestione sicura di
sistemi informativi ed informatici.
Nel seguito sono elencate le principali specifiche, attinenti alla sicurezza delle informazioni, che devono essere
inserite nella documentazione progettuale di sistemi e servizi. Si precisa che l’elenco non può essere sempre
integralmente applicato, ma deve essere contestualizzato alla tipologia del sistema o servizio in fase di
progettazione.
5.2.3. Specifiche Infrastrutturali
Tra le specifiche infrastrutturali da inserire nella documentazione rientrano:

la descrizione delle tecnologie utilizzate, che devono essere per quanto possibile note e di comprovata
affidabilità;

gli aspetti di continuità del business che vengono garantiti, quali ad esempio:
o
i livelli di ridondanza/difesa in profondità (minimizzazione dei Single Point of Failure);
o
la capacità di ripristino da errori/fallimenti del sistema;
o
la distribuzione dei componenti su siti differenti (se applicabile);

i livelli di modularità;

la disponibilità di elementi di difesa specifica (ad es. difese perimetrali)
5.2.4. Specifiche funzionali e dell’architettura applicativa
Nel seguito vengono riportate le principali specifiche funzionali che devono essere inserite nella
documentazione progettuale:
Specifiche utenti e degli input/output:

validazione di ogni dato in input e output;

garanzia dei livelli di riservatezza (classificazione delle informazioni) per i dati;

controllo accessi (identificazione, autenticazione e autorizzazione);

modalità di trattamento degli errori (sia a livello operativo che di processo).
Specifiche di prestazione:

specifiche di elaborazione;

specifiche di input/output.
Specifiche di interfacciamento:
Pagina 10 di 19
TECHNICAL STANDARD:
Emissione: DPSS

Versione 1.0
Data: Febbraio 2016
specifiche di interfaccia nei riguardi di sistemi/servizi già esistenti, con la definizione delle loro
caratteristiche e criteri;

specifiche di conversione, con la individuazione degli archivi (compresi i database), delle procedure
di controllo, dei programmi che devono essere adattati e di eventuali strumenti da predisporre.
Specifiche di verifica, controllo e collaudo:

disponibilità di componenti che permettano di verificare la correttezza delle operazioni compiute
dall’applicazione;

generazione delle tracce di audit (log);

controlli automatici da attuare durante le elaborazioni dati (per es. quadrature, ecc.);

individuazione degli eventuali controlli manuali ad integrazione o in sostituzione di quelli automatici;

specifiche di backup e collaudo.
Specifiche dell’architettura applicativa:

specifiche dell’architettura applicativa e basi dati coerente con le linee d’indirizzo aziendali.
Specifiche di gestione del servizio:
Nell’ambito della documentazione di progetto devono essere inserite le seguenti specifiche relative al servizio:

le modalità di gestione del servizio;

i livelli di servizio che occorre garantire e di conseguenza monitorare;

i criteri base cui attenersi per l’erogazione delle attività di assistenza e monitoraggio.
5.3. Realizzazione - Sviluppo
L’attività di sviluppo e realizzazione dei sistemi e servizi IT deve tenere in considerazione i seguenti requisiti:

deve essere condotta solo a seguito di una formale accettazione delle specifiche definite in fase di
progettazione;

deve ispirarsi alle principali best practice in materia di sicurezza IT (ad. esempio quelle per lo sviluppo
sicuro del codice) verificando in corso di realizzazione/sviluppo l’implementazione di tali practice;
Le attività cui occorre prestare attenzione sono nel seguito riportate:

nell’ambito dell’attività di realizzazione del software:
o
devono essere impiegati sistemi specifici per la gestione sicura e la validazione del codice
sorgente;
o
devono essere predisposte le release note di sviluppo;
Pagina 11 di 19
TECHNICAL STANDARD:
Emissione: DPSS
o
Versione 1.0
Data: Febbraio 2016
deve essere definita la documentazione per la predisposizione della manualistica utente
(formazione) ed i documenti operativi di gestione (dell’infrastruttura e del servizio);
o
devono essere condotte attività di testing di quanto sviluppato; i test devono riguardare anche
le caratteristiche di sicurezza e la verifica di eventuali vulnerabilità applicative;
o
devono essere rispettate le procedure formali di accettazione nel passaggio fra ambienti
definite in GELE.

nell’ambito della realizzazione di servizi o sistemi complessi occorre verificare gli aspetti di sicurezza
logica per tutti i componenti, in particolare per quelli deputati alla trasmissione di dati.
5.4. Test e Integrazione
Le applicazioni, sviluppate internamente o acquistate, devono essere verificate prima del rilascio in ambiente
di produzione, controllando in particolare l’adeguatezza delle funzionalità implementate rispetto ai requisiti di
sicurezza.
Le indicazioni che devono essere rispettate sono nel seguito elencate:

il rilascio delle applicazioni dall’ambiente di sviluppo a quello di integrazione deve essere pianificato e
formalmente autorizzato;

le attività di testing delle funzionalità delle applicazioni devono essere condotte:
o
sulla base di una pianificazione formale ed utilizzando apposite checklist;
o
in un ambiente separato ma allineato, in termini di contromisure di sicurezza, a quello di
produzione;

o
ponendo particolare attenzione alla profilatura e ai diritti di accesso degli utenti;
o
utilizzando dati coerenti con quelli di produzione;
le modalità per effettuare le verifiche ed i controlli, l'analisi dei risultati e la loro approvazione devono
essere formalizzate;

nell’ambito dei test devono essere effettuate delle verifiche di performance, volte a verificare la
capacità dell’applicazione di sopportare picchi di utilizzo sia in termini di attività contemporanee degli
utenti, che in termini di mole di dati trattati;

tutte le verifiche ed i controlli effettuati, nonché i relativi esiti, devono risultare documentati;

devono essere implementati e tracciati tutti gli interventi correttivi emersi a fronte delle anomalie
rilevate.
Pagina 12 di 19
TECHNICAL STANDARD:
Emissione: DPSS
Versione 1.0
Data: Febbraio 2016
5.5. Passaggio in produzione
Le indicazioni che devono essere rispettate nella gestione del passaggio in produzione sono nel seguito
elencate:

l’attività di rilascio deve essere formalmente pianificata: in particolare, deve essere prevista una
dichiarazione di presa in carico del rilascio/servizio;

prima di procedere ai rilasci, occorre:
o
verificare la presenza di un back-up dei dati consistente;
o
predisporre e pianificare tutte le procedure di restore e regressione in caso di problemi
conseguenti all’attività;
o
predisporre un tracciamento e monitoraggio intensificato dei nuovi sistemi in produzione per
un tempo opportuno;
o
predisporre adeguati piani formativi per gli operatori al fine di consentire il corretto utilizzo dei
sistemi.

qualora la tipologia del servizio lo renda necessario, devono essere pianificate delle attività di
“collaudo” su un campione di utenti prima di esporre il servizio alla totalità dell’utenza;

tutta la documentazione a corredo del servizio deve essere attentamente verificata per determinarne
completezza e coerenza; in particolare, occorre che vi siano opportune procedure per:

o
il monitoraggio del sistema e l’analisi dei relativi log;
o
la verifica dei dati relativi alle prestazioni delle applicazioni;
o
la gestione delle credenziali di autenticazione e dei profili di accesso degli utenti;
o
il salvataggio dei dati secondo le modalità stabilite;
o
la gestione delle attività di assistenza.
occorre definire un processo che disciplini la copia e l’utilizzo dei programmi applicativi presenti in
produzione; in particolare è necessario:
o
definire norme per effettuare copie di programmi e per il loro utilizzo stabilendo le
responsabilità, i livelli autorizzativi necessari e le procedure operative;
o
assicurare che i sistemi sui quali le copie sono ripristinate garantiscano lo stesso livello di
protezione dei sistemi originali.
5.6. Gestione in produzione
I sistemi ed i servizi in produzione devono essere gestiti mantenendo i livelli di sicurezza previsti dalla
normativa vigente e dalle procedure emesse da GELE. Nel seguito vengono descritte le principali attività in
materia di sicurezza che occorre rispettare.
Pagina 13 di 19
TECHNICAL STANDARD:
Emissione: DPSS
Versione 1.0
Data: Febbraio 2016
5.6.1. Gestione dell’infrastruttura tecnologica
Tutte le attività attinenti la gestione in esercizio dell’hardware, del software e della rete devono essere condotte
nel rispetto di una serie di regole di sicurezza coerenti con le principali best practice nazionali e internazionali.
In particolare è necessario predisporre procedure documentate almeno per le seguenti attività:

avvio e arresto e riavvio dei sistemi;

backup, restore e recovery dei sistemi, includendo la gestione dei supporti di

memorizzazione: il trasporto verso e da i siti di stoccaggio e il personale autorizzato al richiamo del
supporto dal sito di stoccaggio;

schedulazione dei job (compresi i requisiti e le eventuali interdipendenze con altri sistemi e con terze
parti);

manutenzione ordinaria e straordinaria (incluso l’aggiornamento dei sistemi): finestre temporali per la
manutenzione e migrazione;

salvataggi delle informazioni e loro gestione;

implementazione di specifici controlli per garantire la sicurezza del transito dati attraverso le reti
(pubbliche ed in particolare su reti wireless);

registrazione (logging) degli eventi e monitoraggio degli stessi;

gestione degli incidenti, degli errori o altre condizioni anomale, gestione dei failover automatici e
forzati;

riavvio e ripristino dei sistemi e delle operazioni;

implementazione di specifici automatismi di verifica e controllo sulla correttezza delle operazioni;

gestione dei rifiuti per carta, elettronica e supporti elettronici;

supporto e manutenzione dei contatti di business, inclusi i contatti relativi ai contact center per il
supporto dei vendor e i passi di escalation;

controllo delle modifiche (change control)

gestione delle eccezioni e delle comunicazioni;

cifratura dei dati e gestione delle chiavi di cifratura.
Nel seguito vengono riportati alcuni approfondimenti relativi ad aspetti di primaria importanza.
5.6.2. Controllo Accessi
Il controllo accessi per i sistemi in produzione deve essere allineato con i contenuti della procedura specifica
“GELE - Procedura per la gestione del ciclo di vita delle utenze e degli accessi logici”.
Pagina 14 di 19
TECHNICAL STANDARD:
Emissione: DPSS
Versione 1.0
Data: Febbraio 2016
Devono essere definite e mantenute le eventuali connesse procedure e istruzioni di lavoro relative ai sistemi
in produzione.
Particolare attenzione deve essere posta all’applicazione delle regole generali per la gestione delle utenze
con riferimento a quelle di amministrazione.
5.6.3. Capacity Management
Per prevenire anomalie o malfunzionamenti determinati dal sovraccarico di capacità, si devono controllare
periodicamente le prestazioni dei sistemi (memoria, processori, spazio disco occupato, traffico di rete, ecc.).
Pertanto le funzioni interessate devono:

stabilire quali sistemi e funzioni sottoporre a misurazione;

definire e documentare un processo di raccolta dei dati e definizione dei parametri di accettabilità,
relativi ai livelli di prestazione;

definire e documentare un processo di analisi delle prestazioni;

operare delle proiezioni sulle necessità future delle risorse, sulla base dei risultati delle analisi
prestazionali condotte e tenendo conto delle evoluzioni che interesseranno l’intero sistema informativo
dell’Azienda;

comunicare eventuali decadimenti delle prestazioni.
L’analisi dei dati raccolti deve consentire:

l’adeguato dimensionamento dei sistemi, anche al variare della configurazione, del tempo di utilizzo e
della capacità degli stessi;

la definizione delle esigenze future;

l’adozione delle opportune azioni correttive per il miglioramento delle performance;

la valutazione sull’opportunità di introdurre nuove applicazioni o cambiamenti di quelle esistenti;

l’individuazione di sistemi obsoleti o non più sufficienti nel supporto alle applicazioni.
5.6.4. Protezione da software dannosi
Per la rilevazione e prevenzione della diffusione di malware (software dannosi, quali ad esempio virus,
spyware ecc.) nei sistemi informativi, devono essere attivate delle procedure e implementate specifiche
contromisure tecniche e organizzative.
In particolare devono essere considerati i seguenti controlli:

a tutti i livelli architetturali deve essere previsto l’utilizzo di software antivirus;
Pagina 15 di 19
TECHNICAL STANDARD:
Emissione: DPSS

Versione 1.0
Data: Febbraio 2016
gli unici software antivirus utilizzabili devono essere quelli espressamente previsti e autorizzati da
GELE;

i software antivirus utilizzati devono essere scelti tenendo in considerazione che gli stessi devono
garantire:
o
un adeguato livello di protezione da virus informatici;
o
una modalità di funzionamento non intrusiva nei confronti del sistema ospite;
o
possibilità di ottimizzare l’occupazione di risorse;
o
una percentuale limitata di falsi allarmi – i sistemi antivirus devono essere periodicamente
aggiornati e distribuiti con la massima celerità garantendo la verifica dell’effettiva distribuzione;

devono essere condotte regolari verifiche (scansioni) del software e dei dati contenuti all’interno dei
sistemi critici di supporto ai processi di business di GELE;

deve essere garantito il controllo dei messaggi di posta elettronica a più livelli: server di posta, servizi
di rete e postazioni locali;

deve essere realizzata un’opportuna reportistica e condotte delle analisi statistiche con riferimento agli
attacchi virali subiti.
Devono inoltre essere predisposte opportune procedure per gestire l’installazione di sistemi antivirus a livello
di file server, web server, DB server, application server, internet e mail gateway, proxy, postazioni di lavoro
fisse e mobili e assicurarsi che le postazioni delle risorse esterne siano allineate alle policy GELE. Qualora ciò
non fosse possibile devono essere formalizzate e giustificate le motivazioni che hanno portato all’esclusione
dell’installazione sottoponendo la documentazione a DPSS.
5.6.5. Configuration Management
I sistemi IT devono essere configurati in modo completo e sicuro. Al fine di garantire adeguati livelli di tutela
della sicurezza delle informazioni aziendali, occorre però che siano definiti anche dei criteri per la salvaguardia
delle diverse versioni. In particolare:

devono essere definiti i criteri e gli strumenti di supporto per la gestione delle diverse configurazioni;

gli strumenti di configuration management devono essere, per quanto possibile, gli stessi nei diversi
ambiti di lavoro;

devono essere formalmente definite le procedure per il ripristino di versioni precedenti del software,
in caso si verificassero malfunzionamenti nel corso delle attività di passaggio in produzione delle
nuove versioni;

al fine di garantire efficienza e livelli di sicurezza stingenti ai sistemi utilizzati occorre prevedere con
cadenza periodica:
o
attività di hardening;
Pagina 16 di 19
TECHNICAL STANDARD:
Emissione: DPSS

o
attività di patching;
o
test funzionali;
o
vulnerability assessment e penetration test.
Versione 1.0
Data: Febbraio 2016
Le attività di hardening, patching, i test funzionali ed i vulnerability assessment devono essere condotti
in base a quanto definito all’interno di formali procedure.
5.6.6. Change Management
Al fine di mantenere adeguati livelli di tutela della sicurezza delle informazioni aziendali, occorre garantire un
controllo nei change ai sistemi informativi e alle reti che hanno impatti sulla sicurezza delle informazioni.
Le attività di modifica possono essere:

realizzate proattivamente per cercare di raggiungere livelli richiesti di efficienza ed efficacia, o per
attuare iniziative a supporto del business, o, infine, per rispondere ad esigenze di programmi, progetti
o iniziative per il miglioramento dei servizi;

la conseguenza di una reazione attuata in risposta ad un problema o ad un incidente;

imposte esternamente (ad es. per cambiamenti legislativi).
Tali modifiche possono riguardare:

aggiornamenti hardware e software dei sistemi;

riorganizzazione di database;

modifica dei parametri di configurazione degli asset;

variazione o definizione di interconnessioni di rete (interne o esterne);

sostituzione e/o potenziamento hardware;

modifica alle regole dei sistemi di protezione (firewall, IDS, antivirus, etc.);

modifica ai servizi/ applicazioni che prevedono il trattamento di nuove tipologie di dati.
Il processo di Change Management viene attivato in base ad esigenze di modifica e/o adeguamento dei servizi,
delle applicazioni, dell’infrastruttura del Gruppo oppure del livello di protezione dell’infrastruttura informatica
gestita dal Gruppo.
L’esigenza di cambiamento può essere rilevata:

dal personale della sturttura IT durante le attività di esercizio delle piattaforme e dei sistemi (ad
esempio in fase di Capacity Planning);

dall’Owner di sistema, tramite la struttura responsabile per lo sviluppo delle applicazioni, per esigenze
di miglioramento del servizio, per esigenze di business, per esigenze di compliance normativa, o a
Pagina 17 di 19
TECHNICAL STANDARD:
Emissione: DPSS
Versione 1.0
Data: Febbraio 2016
seguito dell’evoluzione dei sistemi e dei servizi e/o per l’espletamento delle attività relative alla
sicurezza (ad esempio, risoluzione di incidenti)
Il processo di gestione delle change dovrà contenere tutte le informazioni necessarie affinché un cambiamento
possa essere valutato, approvato ed implementato.
A valle dell’implementazione, prima del rilascio in esercizio, dovranno essere eseguiti dei test appropriati per
confermare che tutti i criteri di accettazione di sicurezza siano completamente soddisfatti.
5.6.7. Gestione dei Backup
L’Azienda deve prevedere una corretta e completa attività di backup e restore dei dati e degli applicativi, con
modalità documentate e collaudate.
Devono essere definiti i requisiti di conservazione in luoghi sicuri in base alla tipologia e classificazione dei
dati/informazioni trattati.
5.6.8. Gestione dei servizi
I servizi in esercizio devono essere gestiti in modo da garantire il mantenimento di adeguati livelli di efficienza
e preservando al meglio le informazioni che vengono trattate per il loro tramite. Pertanto, occorre tenere in
considerazione i seguenti aspetti:

per tutti i servizi devono essere garantite le attività di assistenza; in particolare:
o
devono essere definite delle procedure operative per la gestione delle attività di assistenza;
o
tutti gli interventi di assistenza devono essere formalizzati attraverso la compilazione di
apposita documentazione, al cui interno devono essere riportate, quando possibile, anche le
evidenze che comprovino la necessità dell’intervento;
o
periodicamente devono essere realizzati dei report di sintesi che favoriscano l’indirizzamento
e l’organizzazione delle future attività di assistenza.
o
devono essere adottate adeguate metodologie e strumenti idonei al controllo ed al
monitoraggio del servizio. In particolare:
o
devono essere definite formalmente delle procedure operative per le attività di monitoraggio
funzionale;

le attività di monitoraggio devono favorire l’identificazione delle anomalie e delle necessità di
intervento, sulla base di indicatori coerenti con i livelli di servizio garantiti contrattualmente;

con cadenza periodica devono essere stilati dei report dell’attività di monitoraggio condotta.
Pagina 18 di 19
TECHNICAL STANDARD:
Emissione: DPSS

Versione 1.0
Data: Febbraio 2016
a fronte delle informazioni raccolte nel corso delle attività di assistenza e monitoraggio, devono essere
definite le eventuali esigenze di intervento e stabilite le opportune azioni correttive per il miglioramento
o il mantenimento dei livelli di efficienza/efficacia del servizio.
5.6.9. Verifiche tecniche e tracciamento
I sistemi devono essere correttamente configurati e devono poter tracciare ogni evento rilevante.
5.7. Dismissione
La dismissione di sistemi e servizi deve essere effettuata senza compromettere i livelli di sicurezza
dell’Azienda e nel rispetto della classificazione e gestione degli asset effettuata in base alla classificazione
delle informazioni da essi trattate.
In particolare, prima di procedere alla disattivazione di un sistema o servizio occorre:

rispettare l’iter di autorizzazione aziendale;

verificare la presenza di eventuali vincoli di natura contrattuale;

definire puntualmente un piano di disattivazione;

garantire, se necessario, tutte le adeguate comunicazioni verso le terze parti.
Pagina 19 di 19

Procedura per la gestione del ciclo di vita dei

Transcript

Documenti analoghi

Politica Generale per la Sicurezza Informatica

CONDIZIONI DI VENDITA

Regolamento_CAMPIONATO STUDENTI DI

2013 Autorizzazione genitori studenti_10.09.2013

REGOLAMENTO CAMPIONATO NAZIONALE DELLE SCUOLE DI

Editoriale Sometti

Caro Studente, Caro Genitore, Vi ringraziamo innanzitutto per aver

Milano, 15 settembre 2016 Alle strutture sindacali locali A

Ecco la nuova Provincia di Catania

Editoriale