4 Capitolato tecnico

Gara VA / PT
CAPITOLATO TECNICO
Servizi professionali volti ad analizzare la sicurezza
informatica dei Sistemi Informativi delle Società del
Gruppo Ferrovie dello Stato
Gara VA / PT
INDICE
1. 2. 3. 4. Premessa e obiettivi ........................................................... 3 Oggetto
........................................................................ 4 Glossario ........................................................................ 5 Servizi professionali ........................................................... 7 4.1 Vulnerability Assessment & Penetration Test
7 4.1.1 Fasi delle attività di VA / PT
9 4.1.2 Documentazione a corredo delle attività di Vulnerability Assessment
9 4.1.3 Documentazione a corredo delle attività di Penetration Test
10 4.2 Analisi del codice sorgente per l’individuazione delle vulnerabilità12 4.2.1 Documentazione a corredo delle attività di analisi del codice
12 4.3 Audit di processi, procedure e metodologie
14 4.3.1 Documentazione a corredo delle attività di audit
14 4.4 Composizione dei team professionali per le attività
15 4.4.1 Project Manager
16 4.4.2 Team per Vulnerability Assessment & Penetration Test
16 4.4.3 Team per l’analisi del codice sorgente
17 4.4.4 Team per gli audit di sicurezza
18 pag. 2
Gara VA / PT
1.
PREMESSA E OBIETTIVI
L’infrastruttura tecnologica e informatica delle Società del Gruppo Ferrovie dello Stato
(nel seguito Gruppo FS) eroga servizi di estrema rilevanza.
Pertanto l’obiettivo della Gara a cui è annesso il presente Capitolato Tecnico, è quello
di individuare un’Impresa in grado di erogare servizi professionali di elevato profilo, in
grado di analizzare la sicurezza informatica dei sistemi informativi delle Società del
Gruppo FS e formulare adeguate soluzioni e procedure in grado di elevare i livelli di
sicurezza dei Sistemi.
pag. 3
Gara VA / PT
2.
OGGETTO
Il presente Capitolato ha ad oggetto l’erogazione di servizi professionali effettuati da
n. 3 (tre) Team di Lavoro strutturati coordinati da n. 1 (uno) Project Manager:
1.
Team per Vulnerability Assesment / Penetration Test,
2.
Team per Analisi del codice sorgente,
3.
Team per Audit di sicurezza.
nei seguenti 4 (quattro) ambiti di attività:
1)
Vulnerability Assesment: identificare le vulnerabilità informatiche presenti nei
sistemi informativi/informatici e redigere piani di rientro e di mitigazione del
rischio.
2)
Penetration Test & simulazione/effettuazione di attacchi informatici:
Effettuare attacchi mirati ai sistemi, onde produrre dettagliati report su ciò che è
stato identificato e sviluppare piani di rientro con metodologie di mercato e
tempistiche di massima;
3)
Analisi del codice sorgente: fornire servizi di analisi del codice sorgente volti
all’identificazione di vulnerabilità informatiche.
4)
Audit di metodologie, procedure e processi: analizzare procedure, processi e
metodologie al fine di:
a.
valutarne l’efficienza e l’efficacia per quello che concerne la sicurezza ICT,
b.
verificarne la rispondenza con standard di riferimento,
c.
produrre piani di rientro mirati.
pag. 4
Gara VA / PT
3.
GLOSSARIO
Di seguito si fornisce un glossario dei principali termini utilizzati nel presente
documento e del significato a loro attribuito:
VA/PT
DoS -Denial of
Service
DDoS –
Distributed
Denial of Service
OWASP- Open
Web Application
Security Project
LAN- Local Area
Network
Deliverable
Milestone
Template
KPI – Key
Performance
Indicators
Seven Pernicious
Kingdom
ISECOM
Vulnerability Assessment & Penetration Test
Si tratta di un attacco che una macchina porta ad un altra facendole
consumare le risorse a disposizione in modo che non ne restino per
gli utenti regolari. In generale si fa in modo che la macchina
obiettivo venga sommersa da richieste fasulle che la costringono ad
allocare memoria temporaneamente. Se queste richieste giungono
in numero sufficiente da esaurire le risorse, quelle che provengono
dall'utenza non potranno essere soddisfatte.
A differenza del DoS, in questo caso l'attacco viene portato da piu'
macchine (chiamate in genere zombie) in contemporanea contro un
singolo bersaglio. Il risultato, in questo caso, e' il consumo della
banda a disposizione della macchina/vittima in modo tale che le
richieste di utenti leciti non possano essere soddisfatte.
È un progetto il cui scopo è quello di raccogliere e distribuire
documenti, metodologie, strumenti e tecnologie votate allo
sviluppo ed alla gestione sicura delle applicazioni web.
Reti locali di interscambio dati
Documento prodotto come risultato di un’attività di progetto.
utilizzato nella pianificazione e gestione di progetti complessi per
indicare il raggiungimento di obiettivi stabiliti in fase di definizione
del progetto stesso.
Un documento o programma dove, come in un foglio
semicompilato cartaceo, su una struttura generica o standard
esistono spazi temporaneamente "bianchi" da riempire
successivamente (template).
Sono indici che monitorano l'andamento di un processo aziendale.
Metodologie di classificazione delle vulnerabilità informatiche del
codice sorgente.
Institute for Security and Open Methodologies fondata da Pete
Herzog nel 2001 con una filosofia orientatA all’open source, no
profit e vendor indipendet. Il suo obiettivo primario è la diffusione
della consapevolezza della sicurezza.
pag. 5
Gara VA / PT
OSSTMM
OPSA
OPST
OPSE
OWSE
(ISC)2
CISSP
CSSLP
ISACA
CISM
CISA
PMI
PMP
PRINCE2
Open Source Security Testing Methodology Manual.
È la metodologia di riferimento per l’esecuzione e misurazione
delle verifiche tecniche di sicurezza.
OSSTMM Professional Security Analyst.
OSSTMM Professional Security Tester
OSSTMM Professional Security Expert
OSSTMM Wireless Security Expert
International Information System Security Certification
Consortium.
Certified Information Systems Security Professional
Certified Secure Software Lifecycle Professional.
Information Systems Audit and Control Association
Certified Information Security Manager
Certified Information Systems Auditor
Project Management Institute
Project Management Professional - certificazione di project
management rilascita dal Project Management Institute (PMI).
(Projects IN Controlled Environment) – certificazione di project
management .
pag. 6
Gara VA / PT
4.
4.1
SERVIZI PROFESSIONALI
Vulnerability Assessment & Penetration Test
L’Impresa si impegna ad effettuare delle attività di Vulnerability Assessment &
Penetration Test aventi le caratteristiche sotto esposte.
L’Impresa dovrà essere in grado di effettuare l’attività agendo direttamente dalla sede
dell’azienda del Gruppo FS interessata da VA/PT o dalla propria sede. L’ubicazione
del test verrà concordata di volta in volta con la singola Società del Gruppo.
L’Impresa dovrà dare la disponibilità ad effettuare le attività in orari compatibili con
l’esercizio dei target, ovvero anche in orari notturni e/o extra lavorativi.
Sarà richiesta all’Impresa la registrazione completa di tutte le attività oggetto delle
analisi di VA/PT.
L’Impresa dovrà essere in grado di effettuare, durante la fase di PT, attacchi da internet
o dalla intranet di tipologia DDoS o DoS. Questi attacchi potranno essere di tre nature
principali:
•
Saturazione delle risorse di rete.
•
Saturazione delle risorse computazionali e prestazionali dei target.
•
Misto delle due opzioni sopra citate.
Per quello che concerne gli attacchi Dos e DDoS effettuati da internet si richiede di
fornire una banda aggregata almeno di almeno 50 MBit/sec.
Il servizio Vulnerability Assessment dovrà essere erogato tramite l’impiego di
strumenti aggiornati con le informazioni relative a vulnerabilità e minacce più recenti
(lo scarto massimo tra informazioni presenti sul sistema di Vulnerability Assessement e
vulnerabilità note deve essere di 10 giorni), che tengano in considerazione la
localizzazione prevalente dei sistemi in esercizio: italiano e inglese.
Il servizio deve prevedere la produzione di report che forniscano indicazioni circa
l’andamento dello stato di sicurezza per ciascun sistema analizzato. Il servizio di
Vulnerability Assessment deve essere erogato in modo tale da garantire che i dati e le
informazioni acquisite durante l’esecuzione delle attività, rimangano confinati
all’interno di un’area indicata nel perimetro di rete del Gruppo FS.
Le informazioni ed i dati acquisiti dovranno essere conservati utilizzando delle tecniche
di custodia che prevedano l’impiego di crittografia forte (3DES, AES, e simili).
Il servizio di Penetration Test dovrà essere erogato tramite l’impiego di strumenti che
consentano di ricostruire le attività effettuate nel corso delle simulazioni d’attacco. Il
pag. 7
Gara VA / PT
servizio potrà essere erogato, secondo le modalità concordate nella fase di start-up, sia
in modalità remota che in modalità on-site.
I dati e le informazioni acquisite durante l’esecuzione delle attività devono essere
conservati e/o inviati utilizzando tecniche di custodia che prevedano l’impiego di
crittografia forte (3DES, AES, e simili). Le informazioni ed i dati acquisiti devono
essere custoditi dall’Impresa solo per il tempo strettamente necessario alla redazione del
report conclusivo dell’attività, e comunque non oltre i 40 giorni solari dalla loro
acquisizione.
Le vulnerabilità individuate nel corso dell’erogazione dei servizi di Vulnerability
Assessment e Penetration Test, dovranno essere classificate per mezzo della
metodologia “CVSS 2”. È possibile utilizzare anche altri standard di classificazione
delle vulnerabilità, purché siano concordati preventivamente con il personale del
Gruppo FS.
I servizi di Vulnerability Assessment e Penetration Test devono essere erogati
garantendo la continuità operativa dei sistemi, servizi e infrastrutture oggetto di test.
Nel caso in cui le simulazioni d’attacco comportino disservizi o danneggiamenti,
l’Impresa dovrà provvedere ad evidenziarne preventivamente l’impatto al personale del
Gruppo FS, il quale provvederà ad autorizzare o meno la prosecuzione dell’attacco,
pianificando eventualmente il fermo o il disservizio programmato.
Il personale del Gruppo FS potrà partecipare alle attività effettuate nell’ambito
dell’erogazione dei servizi di Vulnerability Assessment e Penetration Test in qualità di
osservatore. Il personale del Gruppo FS dovrà avere accesso in sola lettura alle
informazioni presenti sul sistema di Vulnerability Assessment, e sulle informazioni
acquisite nel corso delle attività di Penetration Test.
L’Impresa dovrà effettuare le attività secondo le best practice internazionali, con
particolare attenzione alle metodologie OSSTMM e OWASP.
L’Impresa dovrà avere competenze in ambienti SCADA.
A fronte della richiesta da parte una Società del Gruppo FS, l’Impresa si mobilita
mettendo a disposizione il team descritto al paragrafo 3.3.1. che in concerto con il
referente dell’Azienda definisce:
•
Perimetro dell’attività,
•
Target di riferimento,
•
Tempistica,
•
Metodologia utilizzata.
pag. 8
Gara VA / PT
4.1.1 Fasi delle attività di VA / PT
Ogni attività di VA/PT, dovrà essere corredata da un’attività di progettazione e relativo
diagramma di GANTT particolareggiato. Avrà - al minimo - le seguenti macro fasi:
1)
Riunione di apertura di presentazione dell’attività con relativa formazione dei referenti
delle Società del Gruppo FS riguardo le azioni da porre in essere entro e non oltre 5
giorni lavorativi dalla richiesta della Società del Gruppo;
2)
Produzione del GANTT contenente le attività pianificate entro e non oltre 3 giorni
lavorativi dalla data del kick-off di cui al punto 1.
3)
Inizio del Vulnerability assessment entro e non oltre 7 giorni lavorativi
dall’approvazione del GANTT di cui al punto 2;
4)
Presentazione dei risultati del vulnerability assessment che indichi un piano di rientro
di massima e, ove possibile, di dettaglio;
5)
Qualificazione degli obiettivi del PT a fronte di quanto scoperto dal VA;
6)
Effettuazione del PT,
a.
7)
Effettuazione dei test DDoS/DoS se pianificati dal Committente;
Presentazione dei risultati del PT con proposte di piani di rientro ed eventuali followup.
Entro 7 giorni lavorativi dal termine di ogni sessione di Vulnerability Assessment e
Penetration Test, dovrà essere prodotta la documentazione a corredo delle attività così
come descritta nei paragrafi seguenti.
4.1.2 Documentazione a corredo delle attività di Vulnerability Assessment
Al termine di ciascuna sessione di Vulnerability Assessment dovranno essere prodotti tre
documenti:
1.
l’executive summary,
2.
il report di dettaglio delle vulnerabilità individuate,
3.
il piano di rientro.
1) L’executive summary deve illustrare brevemente con un linguaggio non tecnico le
vulnerabilità individuate sul perimetro d’analisi, fornendo al management di
riferimento le informazioni necessarie per:
•
•
evincere l’andamento delle vulnerabilità nella storia delle attività effettuate sui
sistemi oggetto di analisi;
valutare rispetto alle attività pregresse, il livello di rischio dei sistemi, dei servizi e
delle infrastrutture analizzate;
pag. 9
Gara VA / PT
•
pianificare, prioritizzare e coordinare gli interventi correttivi da attuare sui sistemi,
sui servizi e sulle infrastrutture analizzate a fronte degli indici riportati nel
documento.
2) Report di dettaglio delle vulnerabilità individuate deve illustrare, per ciascuna delle
vulnerabilità individuate, almeno:
•
•
•
•
•
•
la descrizione della vulnerabilità individuata e la relativa classificazione in
conformità di standard di rilievo internazionale quale “Common Weakness
Enumeration” (CWE), Open Web Application Security Project (OWASP) e simili.
Lo standard di riferimento adottato deve essere indicato all’interno del report;
la valutazione della vulnerabilità sul sistema, calcolato per mezzo del sistema di
rating “CVSS 2” (o altro preventivamente concordato col personale della Società
del Gruppo FS coinvolta);
la prova dell’esistenza della vulnerabilità o le informazioni particolareggiate che ne
hanno reso possibile la deduzione;
le modalità, le indicazioni, gli strumenti ed i passi necessari da attuare per la
verifica manuale della vulnerabilità individuata;
le modalità di risoluzione o le tecniche di mitigazione della vulnerabilità
individuata;
eventuali scenari presenti di mitigazione delle vulnerabilità.
3) Il piano di rientro deve indicare, per ciascuna vulnerabilità individuata almeno le
modalità per sanarla e le best practice per fare in modo che altri sistemi, in futuro,
possano esserne esentati.
Qualora richiesto il report deve contenere una matrice di rispondenza fra la
vulnerabilità ed il controllo dell’Annex A della norma ISO/IEC 27001:06 impattato.
4.1.3 Documentazione a corredo delle attività di Penetration Test
Al termine di ciascuna sessione di Penetration Test, qualora effettuata, dovranno essere
prodotti tre documenti:
1.
l’executive summary,
2.
il report tecnico di dettaglio delle vulnerabilità individuate e degli attacchi effettuati,
3.
il piano di rientro particolareggiato.
1) L’executive summary deve illustrare brevemente con un linguaggio non tecnico le
metodologie impiegate per l’esecuzione delle attività ed i risultati conseguiti sul
pag. 10
Gara VA / PT
perimetro d’analisi, fornendo al management di riferimento le informazioni necessarie
per:
•
•
•
valutare il livello di rischio dei sistemi, dei servizi e delle infrastrutture analizzate a
fronte degli interventi e delle indicazioni derivanti dalle attività di gestione
ordinaria della sicurezza informatica;
valutare la solidità delle misure di sicurezza impiegate per la protezione dei sistemi,
dei servizi e delle infrastrutture analizzate;
pianificare, prioritizzare e coordinare gli interventi correttivi da attuare sui sistemi,
sui servizi e sulle infrastrutture analizzate a fronte degli indici riportati nel
documento.
2) Il report tecnico di dettaglio delle vulnerabilità individuate e degli attacchi
effettuati deve illustrare, per ciascuna delle vulnerabilità individuate e per ciascun
attacco portato a termine, almeno:
•
•
•
•
•
•
•
la descrizione della vulnerabilità individuata e la relativa classificazione in
conformità di standard di rilievo internazionale quale “Common Weakness
Enumeration” (CWE), Open Web Application Security Project (OWASP) e simili.
Lo standard di riferimento adottato deve essere indicato all’interno del report;
la valutazione della vulnerabilità sul sistema, calcolato per mezzo del sistema di
rating “CVSS 2” (o altro preventivamente concordato col personale della Società
del Gruppo FS coinvolta);
le evidenze degli attacchi sotto la forma che si ritiene più opportuna, per far
meglio comprendere il livello di pericolosità dell’attacco effettuato;
le modalità di esecuzione degli attacchi e le condizioni necessarie affinché possa
essere effettuato, corredate da un Proof Of Concept (PoC) e dalle istruzioni; gli
strumenti ed i passi necessari da compiere per la riproduzione dell’attacco portato
a termine;
ogni informazione accessoria ritenuta utile per meglio valutare l’attacco effettuato
e l’impatto sul servizio, sistema o infrastruttura analizzata;
le modalità e le tecniche di mitigazione o risoluzione del problema di sicurezza
individuato;
eventuali scenari presenti di mitigazione delle vulnerabilità.
3) Il piano di rientro particolareggiato deve illustrare, per ciascuna delle vulnerabilità
individuate e per ciascun attacco portato a termine almeno:
•
•
informazioni di dettaglio per la soluzione definitiva della vulnerabilità, adducendo
anche esempi di configurazione e/o codice sorgente per la sua risoluzione;
metodologie e best practice di sviluppo software ed esercizio dei sistemi che
facciano in modo che la vulnerabilità sia prevenuta in casi futuri.
pag. 11
Gara VA / PT
Qualora richiesto il report deve contenere una matrice di rispondenza fra la vulnerabilità ed
il controllo dell’Annex A della norma ISO/IEC 27001:06 impattato.
Qualora richiesto verrà allegato al report il listato del codice sorgente di tutti gli strumenti
utilizzati per effettuare gli attacchi.
4.2
Analisi del codice sorgente per l’individuazione delle vulnerabilità
Il servizio di analisi del codice sorgente dovrà essere erogato tramite l’impiego di
strumenti automatizzati o tramite l’intervento di analisti di comprovata esperienza nel
settore.
Il servizio dovrà essere erogato esclusivamente presso la sede del Cliente. In nessun
caso il codice sorgente verrà consegnato all’Impresa.
L’analisi verrà condotta su codici redatti in linguaggi largamente diffusi (ad es.: C++,
Java, ASP, …) ed in framework di sviluppo normalmente utilizzati.
I dati e le informazioni acquisite durante l’esecuzione delle attività devono essere
conservati e/o inviati utilizzando tecniche di custodia che prevedano l’impiego di
crittografia forte (3DES, AES, e simili). Le informazioni devono essere custodite
dall’Impresa solo per il tempo strettamente necessario alla redazione del report
conclusivo dell’attività, e comunque non oltre i 60 giorni solari dalla loro acquisizione.
Le vulnerabilità individuate nel corso dell’erogazione dei servizi di analisi del codice,
dovranno essere classificate per mezzo delle metodologie “Seven Pernicious Kingdom”
o “Owasp”.
È possibile utilizzare anche altri standard di classificazione delle vulnerabilità, purché
siano concordati preventivamente con il personale della Società del Gruppo FS
coinvolta.
L’attività a fronte della richiesta dell’azienda del Gruppo, dovrà partire entro 7 giorni
lavorativi.
Entro 7 giorni lavorativi dal termine di ogni sessione di analisi del codice, dovrà essere
prodotta la documentazione a corredo delle attività così come descritta nei paragrafi
seguenti.
4.2.1 Documentazione a corredo delle attività di analisi del codice
Al termine di ciascuna sessione di analisi del codice dovranno essere prodotti tre
documenti:
1.
l’executive summary,
pag. 12
Gara VA / PT
2.
il report tecnico di dettaglio delle vulnerabilità individuate e degli attacchi effettuati,
3.
il piano di rientro particolareggiato.
1) L’executive summary deve illustrare brevemente con un linguaggio non tecnico le
metodologie impiegate per l’esecuzione delle attività ed i risultati conseguiti sul
perimetro d’analisi, fornendo al management di riferimento le informazioni necessarie
per:
•
•
•
valutare il livello di rischio dei sistemi, dei servizi e delle infrastrutture analizzate a
fronte degli interventi e delle indicazioni derivanti dalle attività di gestione
ordinaria della sicurezza informatica;
valutare la solidità delle misure di sicurezza impiegate per la protezione dei sistemi,
dei servizi e delle infrastrutture analizzate;
pianificare, prioritizzare e coordinare gli interventi correttivi da attuare sui sistemi,
sui servizi e sulle infrastrutture analizzate a fronte degli indici riportati nel
documento.
2) Il report tecnico di dettaglio delle vulnerabilità individuate e degli attacchi
effettuati deve illustrare, per ciascuna delle vulnerabilità individuate e per ciascun
attacco portato a termine almeno:
•
•
•
•
•
•
la descrizione della vulnerabilità individuata e la relativa classificazione in
conformità di standard di rilievo internazionale quale Seven Pernicious Kingdom,
Open Web Application Security Project (OWASP) e simili. Lo standard di
riferimento adottato deve essere indicato all’interno del report;
le evidenze degli eventuali attacchi che si potrebbero configurare sotto la forma
che si ritiene più opportuna;
le modalità di esecuzione degli attacchi e le condizioni necessarie affinché possa
essere effettuato, corredate da un Proof Of Concept (PoC) e dalle istruzioni; gli
strumenti ed i passi necessari da compiere per la riproduzione dell’attacco portato
a termine;
ogni informazione accessoria ritenuta utile per meglio valutare l’attacco effettuato
e l’impatto sul servizio, sistema o infrastruttura analizzata;
le modalità e le tecniche di mitigazione o risoluzione del problema di sicurezza
individuato;
eventuali scenari presenti di mitigazione delle vulnerabilità.
3) Il piano di rientro particolareggiato deve illustrare, per ciascuna delle vulnerabilità del
codice individuata:
•
informazioni di dettaglio per la soluzione definitiva della vulnerabilità, adducendo
anche esempi di configurazione e/o codice sorgente per la sua risoluzione;
pag. 13
Gara VA / PT
•
metodologie e best practice di sviluppo software ed esercizio dei sistemi che
facciano in modo che la vulnerabilità sia prevenuta in casi futuri.
Qualora richiesto il report deve contenere una matrice di rispondenza fra la vulnerabilità ed
il controllo dell’Annex A della norma ISO/IEC 27001:06 impattato.
4.3
Audit di processi, procedure e metodologie
Con questo servizio il Gruppo FS vuole dotarsi di specialisti che verifichino l’efficienza
e l’efficacia della sicurezza ICT in procedure, processi e metodologie applicate
internamente e presso gli Outsourcer.
Di volta in volta, di concerto con i referenti delle Società del Gruppo FS verranno
definiti:
•
•
•
•
Metodologia utilizzata per effettuare l’audit,
Obiettivi dell’audit,
Perimetro,
Tempi.
L’attività a fronte della richiesta dell’azienda del Gruppo, dovrà partire entro 7 giorni
lavorativi.
Entro 7 giorni lavorativi dal termine di ogni audit, dovrà essere prodotta la
documentazione a corredo delle attività così come descritta nei paragrafi seguenti.
4.3.1 Documentazione a corredo delle attività di audit
Al termine di ciascuna sessione di audit dovranno essere prodotti due documenti:
1.
l’executive summary,
2.
il report di dettaglio delle evidenze individuate.
1) L’executive summary deve illustrare brevemente con un linguaggio non tecnico le
metodologie impiegate per l’esecuzione delle attività ed i risultati conseguiti sul
perimetro d’analisi, fornendo al management di riferimento le informazioni necessarie
per:
•
•
•
valutare il livello di rischio dei sistemi, dei servizi e delle infrastrutture analizzate a
fronte degli interventi e delle indicazioni derivanti dalle attività di gestione
ordinaria della sicurezza informatica;
valutare la solidità delle misure di sicurezza impiegate per la protezione dei sistemi,
dei servizi e delle infrastrutture analizzate;
valutare l’efficienza e l’efficacia delle misure di sicurezza implementate;
pag. 14
Gara VA / PT
•
pianificare, prioritizzare e coordinare gli interventi correttivi da attuare sui sistemi,
sui servizi e sulle infrastrutture analizzate a fronte degli indici riportati nel
documento.
2) Il report di dettaglio delle evidenze individuate deve illustrare, per ciascuna area
dell’audit:
•
•
•
•
•
4.4
i documenti che hanno portato alla produzione delle evidenze;
le informazioni relative ad eventuali audit sul campo;
in termini specifici l’efficienza e l’efficacia delle misure di sicurezza implementate
nel perimetro dell’audit in termini di:
o
Policy,
o
Procedure,
o
Metodologie,
o
Tecnologie implementate,
o
Configurazioni in esercizio;
ove richiesto una matrice relativa al SOA (State of Applicability) dei maggiori
standard ISO (o punti specifici delle norme) relativi alla sicurezza o best practice
internazionali, almeno:
o
ISO/IEC 27001:06,
o
ISO/IEC 20000-1:05, almeno per i punti della norma: 6.3, 6.6, 8.1, 8.2 e
9.2.,
o
CMMI-RSKM;
ogni informazione accessoria ritenuta utile per meglio valutare l’esposizione al
rischio.
Composizione dei team professionali per le attività
I team professionali per l’erogazione dei servizi professionali nell’ambito delle n. 4
(quattro) attività sono n. 3 (tre) coordinati da n. 1 (uno) Project Manager e sono così
composti:
A) Team per i Vulnerability Assessment & Penetration Test
•
1 Security Analyst Senior,
•
2 Security Analyst,
•
1 Remediation Analyst.
B) Team per l’Analisi del codice sorgente
pag. 15
Gara VA / PT
•
n. 1 Security Analyst Senior,
•
2 Security Analyst,
•
1 Remediation Analyst.
C) Team per gli Audit di sicurezza
•
1 Security Auditor Senior,
•
2 Security Auditor.
4.4.1 Project Manager
Il Project Manager è il professionista che pianifica e coordina le attività di tutti i 3 (tre)
team professionali. Deve possedere i seguenti requisiti:
o
almeno 4 anni di esperienza del settore della sicurezza ICT,
o
laurea in disciplina tecnica,
o
capacità di analisi degli scenari tecnico/organizzativi complessi,
o
capacità di pianificare, progettare e contribuire alla realizzazione delle attività,
o
capacità di impostazione e redazione di report consulenziali in grado di fornire al
management del Gruppo FS adeguati supporti alla presa di decisione e
all’impostazione di processi di gestione.
Sarà oggetto di conseguimento di punteggio tecnico il possesso di certificazioni
professionali relative il project management, ovvero il PMP oppure la Prince2.
4.4.2 Team per Vulnerability Assessment & Penetration Test
L’Impresa si impegna ad utilizzare per le attività oggetto del presente Capitolato un
team di specialisti composto almeno dalle seguenti figure professionali:
•
n. 1 Security Analyst Senior, di almeno 4 anni di esperienza nel settore
informatico, orientato ad attività di Vulnerability Assessment & Penetration Test,
avente almeno le seguenti e comprovabili capacità:
o
pianificare, in concerto con il PM, le attività di VA/PT applicative ed
infrastrutturali,
o
analizzare il perimetro del test al fine di individuare i vettori e le metodologie
d’attacco migliori,
o
redigere, conformemente a quanto richiesto dal Gruppo, la reportistica di
riferimento;
pag. 16
Gara VA / PT
sarà oggetto di conseguimento di punteggio tecnico il possedimento di
certificazioni professionali inerenti la conoscenza della sicurezza informatica CISSP
o CISM e delle metodologie di assessment relative, ovvero OPSA, OPST o OWSE
dell’ISECOM;
•
almeno n. 2 Security Analyst, con minimo 2 anni di esperienza, che abbiano
comprovabile competenza specifica sia nel test infrastrutturale che in quello
applicativo. In particolare queste figure professionali dovranno avere le seguenti
caratteristiche:
o
capacità di eseguire attività di VA/PT secondo gli standard e le metodologie
internazionali quali: OSSTMM e simili,
o
capacità di eseguire Penetration Test sull’infrastruttura e sulle tecnologie che
compongono il sistema informativo del Gruppo FS,
o
avere competenze specifiche sulle tecnologie oggetto dei test,
sarà oggetto di conseguimento di punteggio tecnico il possedimento, da parte di
almeno uno dei Security Analyst, di certificazioni professionali inerenti la
conoscenza della sicurezza informatica e delle metodologie di assessment relative,
ovvero OPSA, OWSE o OPST dell’ISECOM.
•
almeno n. 1 Remediation Analyst, che abbia comprovabile competenza specifica
nell’analisi delle contromisure in particolar modo dal punto di vista applicativo.
Questa figura professionale dovrà avere le seguenti caratteristiche:
o
capacità di eseguire analisi sulle vulnerabilità emerse, in particolare quelle
applicative, e di proporre contromisure adeguate per mitigare e risolvere i
problemi,
o
avere competenze specifiche sulle tecnologie oggetto dei test;
sarà oggetto di conseguimento di punteggio tecnico il possedimento di
certificazioni professionali inerenti la sicurezza nel ciclo di vita del software ovvero
la CSSLP.
Il Remediation Analyst con il profilo sopra delineato potrà essere la stessa persona che
fa parte del Team per l’analisi del codice sorgente, descritto nel paragrafo successivo.
4.4.3 Team per l’analisi del codice sorgente
L’Impresa si impegna ad utilizzare per le attività oggetto del presente documento, pena
l’esclusione, un team di specialisti composto almeno dalle seguenti figure professionali:
•
n. 1 Security Analyst Senior, di almeno 4 (quattro) anni di esperienza, che
abbiano comprovabile competenza specifica in analisi di sistemi, nelle tecniche di
programmazione e di identificazione delle vulnerabilità all’interno del codice
pag. 17
Gara VA / PT
sorgente. In particolare queste figure professionali dovranno avere le seguenti
caratteristiche:
o pianificare, in concerto con il PM, le attività di analisi di sistema e del codice,
•
•
o
definire lo scoping del test al fine di individuare le metodologie di analisi più
appropriate alla circostanza,
o
coordinare, conformemente a quanto richiesto dal Committente, la reportistica
di riferimento;
almeno n 2 Security Analyst, di almeno 2 anni di esperienza, che abbiano
comprovabile competenza specifica nelle tecniche di programmazione e di
identificazione delle vulnerabilità all’interno del codice sorgente. In particolare
queste figure professionali dovranno avere le seguenti caratteristiche:
o
capacità di eseguire analisi secondo gli standard e le metodologie
internazionali,
o
ampia conoscenza di OWASP e del Seven Pernicious Kingdom,
o
avere competenze specifiche sulle tecnologie oggetto dei test;
almeno n 1 Remediation Analyst, che abbia comprovabile competenza specifica
nell’analisi delle contromisure in particolar modo dal punto di vista applicativo.
Questa figura professionale dovrà avere le seguenti caratteristiche:
o
capacità di eseguire analisi sulle vulnerabilità emerse, in particolare quelle
applicative, e di proporre contromisure adeguate per mitigare e risolvere i
problemi,
o
avere competenze specifiche sulle tecnologie oggetto dei test.
Sarà oggetto di conseguimento di punteggio tecnico il possedimento di certificazioni
professionali inerenti la sicurezza nel ciclo di vita del software ovvero la CSSLP.
Il Remediation Analyst con il profilo sopra delineato potrà essere la stessa persona che
fa parte del Team VA/PT descritto nel paragrafo precedente.
4.4.4 Team per gli audit di sicurezza
L’Impresa si impegna a mettere a disposizione delle attività oggetto del presente
documento, pena l’esclusione, un team di specialisti composto almeno dalle seguenti
figure professionali:
•
n 1 Security Auditor Senior, con almeno 4 anni di esperienza nel settore,
orientato ad attività di analisi ed audit di sistemi e processi, avente almeno le
seguenti caratteristiche:
o
laurea in discipline tecniche,
pag. 18
Gara VA / PT
•
o
ampia conoscenza della ISO 20000, ITIL e CMMI,
o
ampia esperienza in analisi e gestione del rischio informatico,
o
ampia esperienza di audit interni su tematiche di sicurezza,
o
ampia conoscenza della norma UNI EN ISO 19011:03,
o
Possesso di certificazione Auditor/Lead Auditor ISO 27001,
o
Possesso di certificazione CISA o CISM.
N 2 due Security Auditor, di almeno 2 anni di esperienza, che abbia comprovabile
competenza specifica sia nel test infrastrutturale che in quello applicativo. In
particolare questa figura professionale dovrà avere le seguenti caratteristiche:
o
ampia conoscenza di ISO 20000, ITIL e CMMI,
o
ampia conoscenza della norma UNI EN ISO 19011:03,
o
Possesso di certificazione Auditor/Lead Auditor ISO 27001,
o
Possesso di certificazione CISA o CISM.
pag. 19